bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63556: 29.0.90; Use of _Generic breaks Emacs build on GCC <4.9


From: Paul Eggert
Subject: bug#63556: 29.0.90; Use of _Generic breaks Emacs build on GCC <4.9
Date: Thu, 18 May 2023 07:40:47 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]