GNU bug report logs - #63556
29.0.90; Use of _Generic breaks Emacs build on GCC <4.9

Previous Next

Full log

Message #26 received at 63556 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63556 <at> debbugs.gnu.org
Subject: Re: bug#63556: 29.0.90; Use of _Generic breaks Emacs build on GCC <4.9
Date: Thu, 18 May 2023 07:40:47 -0700

On 5/18/23 04:11, Po Lu wrote:

> Would anyone mind if I made configure check for that?

There would be problems in doing that. GCC and Clang both have problems 
with _Generic (suggested by this original bug report), and some of them 
have to do with which warnings you've enabled. The configure-time check 
would run without the warnings whereas the build would run with them.

This is partly why intprops-internal.h has given up on _Generic with GCC 
and Clang; see its ifdefs. I assumed that these problems didn't apply to 
their simple use in elogb, but apparently I assumed incorrectly.


> Btw, couldn't the macro be defined to something along the lines of this
> when the compiler only supports C99?
> 
>    #define foo(expression)			  \
>      (sizeof (expression) == sizeof (signed char)  \

That wouldn't work on unusual platforms that have padding bits. Of 
course we could simply refuse to port to targets like that; still, I'd 
be reluctant to do that just for this little issue.


> The problem of using `long long' on systems with less than 64
> significant bits in their words.  I don't think that's a particularly
> good idea -- once such uses pile up, Emacs will gradually become slower
> and slower on such systems.

I couldn't measure the slowdown in this case. Until it's measurable I 
wouldn't worry about it. To some extent I put in that _Generic 
originally more as documentation than as an actual attempt to speed 
things up.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.