[Bug c/112972] ambiguity in specification for cast to union types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112972 Stephan Stiller changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Stephan Stiller --- I disagree; the documentation overall is contradictory with respect to whether reading from a different member with the same type is also considered "type punning". Given the example of union datum p, it wouldn't make sense for any compiler to not produce code with the intended effect for something like the following: p.height = 3.4; double d = p.weight; However, the point is that this is not explicitly documented for the case of different members having identical types. For the example from the GCC webpage, if union foo were replaced by union datum, it would be unclear what the "equivalence" would be. (The choice of latitute/longitude/height/weight as the designated member of type double wouldn't matter in practice, but again, this needs to be said explicitly.)
[Bug web/112972] New: ambiguity in specification for cast to union types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112972
Bug ID: 112972
Summary: ambiguity in specification for cast to union types
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: stephan.stiller at outlook dot com
Target Milestone: ---
On this page of the GCC documentation
https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html
the statement that
the following assignments
z = (union foo) x;
z = (union foo) y;
are shorthand equivalents of these
z = (union foo) { .i = x };
z = (union foo) { .d = y };
doesn't give the full picture.
While the statement is accurate about
union foo
x
y
z
as defined just above, unions with multiple members of the same type would lead
to a potential ambiguity. For example, for Richard Stallman's example of a
union
union datum {
double latitude;
double longitude;
double height;
double weight;
int continent;
}
(taken from: "GNU C Language Introduction and Reference Manual", Edition 0.0,
section 15.14 (Unions)), casting to this union would be indeterminate with
respect to which of the 4 members of type double is being assigned to.
That is, either (1) first writing to and then reading from identically typed
but differently named members is *not* undefined behavior (and this should be
stated somewhere in the documentation) or (2) a simple "equivalence" between
assignments of the form
p = (union foo) q;
and assignments of the form
p = (union foo) { .m = q };
can't exist (due to the ambiguity of which m applies in the case of there being
multiple members of type typeof(q)).
[Bug web/112960] omission in documentation: complex numbers can also have uppercase I and J suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960 --- Comment #1 from Stephan Stiller --- name of document (forgotten in original bug report text): "GNU C Language Introduction and Reference Manual"
[Bug web/112960] New: omission in documentation: complex numbers can also have uppercase I and J suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960 Bug ID: 112960 Summary: omission in documentation: complex numbers can also have uppercase I and J suffixes Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: stephan.stiller at outlook dot com Target Milestone: --- Created attachment 56849 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56849=edit example for the 4 different complex number suffixes denoting the imaginary part This page https://gcc.gnu.org/onlinedocs/gcc/Complex.html doesn't mention uppercase 'I' and 'J' as legal suffixes denoting the imaginary part of a complex number, both equivalent to 'i' and 'j'. These suffixes are described in Richard Stallman's document "": https://www.gnu.org/software/c-intro-and-ref/ https://www.gnu.org/software/c-intro-and-ref/manual/ (Edition 0.0, section 12.4 Imaginary Constants)
[Bug preprocessor/111953] New: stringify operator # rejects "\" but not "\ \" as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111953 Bug ID: 111953 Summary: stringify operator # rejects "\" but not "\ \" as input Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: stephan.stiller at outlook dot com Target Milestone: --- The code #define str(s) # s str(\ \) (full source file) should lead to UB (the result "\ \" is not a valid string literal) but doesn't. For a slightly different second line str(\) GCC does in fact give a warning warning: invalid string literal, ignoring final '\' for both C17 (with warnings enabled) gcc -E -std=c17 -pedantic -Wall -Wextra and "gnu17"-C: gcc -E # Here is some technical data (output of "gcc -v"): Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev10, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Rev10, Built by MSYS2 project)
