https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #9 from joseph at codesourcery dot com ---
A portability issue producing a compile failure is often better than one
where there is no error but the code misbehaves at runtime on some
platforms (a lot of code does not have good test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #8 from Martin Uecker ---
There are certainly other similar portability issues, e.g.:
enum : long { X = 0xUL };
https://godbolt.org/z/hKsqPe9c1
BTW: Are there better examples where we have similar build failures also in
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #7 from joseph at codesourcery dot com ---
I think it's reasonable for such a portability issue to be detected only
when building for i386, much like a portability issue from code that
assumes long is 64-bit would only be detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #6 from Martin Uecker ---
Adding a note is a good idea, but it doesn't really solve the issue. The
problem I see is that somebody developing on x86-64 does not get a warning that
the code is not strictly conforming and then it fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #5 from joseph at codesourcery dot com ---
We could add a "note: initializer represented with excess precision" or
similar for the case where the required error might be surprising because
the semantic types are the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Laurent Rineau changed:
What|Removed |Added
CC||Laurent.Rineau__gcc@normale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #3 from Jakub Jelinek ---
Excess precision changes behavior in lots of significant ways, and I don't
really see how we could warn for this, there are different kinds of excess
precision, the i386 one of promoting float/double to long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #2 from Martin Uecker ---
On i386 1. / 3. is computed with higher precision than double and then the
initializer changes the value which is a contraint violation in C23. But
whether this happens or not depends on the architecture,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
