[Bug bootstrap/61764] New: gcc fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 Bug ID: 61764 Summary: gcc fails to build Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: us15 at os dot inf.tu-dresden.de Created attachment 33096 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33096action=edit Full build log The build process fails at this point: echo timestamp s-options-h /gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/xg++ -B/gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/ -B/usr/x86_64-slackware-linux/bin/ build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a /gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/xg++ -B/gcc-631efe2fd9a431796b41b24641a87a15/gcc.build.lnx/./prev-gcc/ -B/usr/x86_64-slackware-linux/bin/ build/genmodes.o build/errors.o .././libiberty/libiberty.a build/gengenrtl tmp-genrtl.h /bin/sh ../../gcc-4.10.0/gcc/../move-if-change tmp-genrtl.h genrtl.h echo timestamp s-genrtl-h build/genmodes -m tmp-min-modes.c build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set make[3]: *** [s-modes-m] Error 1 make[3]: *** Waiting for unfinished jobs
[Bug bootstrap/61764] gcc fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 --- Comment #1 from Udo Steinberg us15 at os dot inf.tu-dresden.de --- This is with SVN version 212406.
[Bug c++/61660] New: static_assert triggering when it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61660 Bug ID: 61660 Summary: static_assert triggering when it should not Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: us15 at os dot inf.tu-dresden.de Created attachment 33034 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33034action=edit Test case In the attached test case, for each compile-time constant value x, only one static_assert in the switch statement should be checked. Looks like all four of them are checked every time. Compile with: g++ -std=gnu++11 foo.cc -o foo
[Bug c++/61660] static_assert triggering when it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61660 --- Comment #3 from Udo Steinberg us15 at os dot inf.tu-dresden.de --- Created attachment 33035 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33035action=edit Testcase 2 Then, similar to this new test case, I would expect something like the following: g++ -std=gnu++11 foo.cc -o foo foo.cc: In function 'void check_type(unsigned int, unsigned int)': foo.cc:10:17: error: non-constant condition for static assertion case 0: static_assert (s == sizeof (uint16), must use 16bit type); break; ^ foo.cc:10:17: error: 's' is not a constant expression If the compiler does not treat 'x' in the first test case as a constant, it would be good to issue a warning like it does for 's' in the second test case.
[Bug c++/61660] static_assert triggering when it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61660 --- Comment #5 from Udo Steinberg us15 at os dot inf.tu-dresden.de --- (In reply to Andrew Pinski from comment #4) That is still correct s is not a constant expression. Yes, I'm saying a similar warning should be emitted for x.
[Bug tree-optimization/55044] New: Compile error in tree-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55044 Bug #: 55044 Summary: Compile error in tree-ssa Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de gcc svn revision 192745 fails to compile here: gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-4.8.0/gcc/../libbacktrace ../../gcc-4.8.0/gcc/tree-ssa-threadedge.c -o tree-ssa-threadedge.o ../../gcc-4.8.0/gcc/tree-ssa-threadedge.c:583:1: error: unused parameter 'n' [-Werror=unused-parameter] cond_arg_set_in_bb (edge e, basic_block bb, int n) ^ cc1plus: all warnings being treated as errors make[3]: *** [tree-ssa-threadedge.o] Error 1 make[3]: Leaving directory `/gcc-7e5bb7de84c28d9296f5e4fd9f4a9a4a/gcc.build.lnx/gcc' make[2]: *** [all-stage2-gcc] Error 2
[Bug c++/51290] Bogus warning: zero as null pointer constant with static_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290 --- Comment #4 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2011-11-24 12:04:58 UTC --- Confirmed to be fixed.
[Bug c++/51290] New: Bogus warning: zero as null pointer constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290 Bug #: 51290 Summary: Bogus warning: zero as null pointer constant Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de Created attachment 25906 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25906 Testcase When compiling the attached testcase: gcc -std=gnu++11 -c -W -Wall -Wzero-as-null-pointer-constant testcase.cc -o testcase.o gcc emits the following bogus warning: testcase.cc: In static member function 'static void C::bar(B*)': testcase.cc:16:38: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]
[Bug rtl-optimization/47698] New: CMOV accessing volatile memory with read side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698 Summary: CMOV accessing volatile memory with read side effect Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de In the attached testcase, the variable mmio is a memory-mapped device register with read side effects. It must only be accessed if cond is true. When compiling the testcase: gcc -Os -c testcase.cc -o testcase.o the following output is generated: foo(): 0: 31 c0 xor%eax,%eax 2: 48 83 3d 00 00 00 00cmpq $0x0,0x0(%rip)# a foo()+0xa 9: 00 a: 48 0f 45 05 00 00 00cmovne 0x0(%rip),%rax# 12 foo()+0x12 11: 00 12: c3 retq Due to the use of CMOV, gcc is reading the memory location regardless of cond being true, even though mmio is casted to volatile. Reading mmio through a volatile pointer, as in return *static_castvolatile unsigned long *(mmio); does not get rid of the CMOV either. What is the correct way to ensure mmio is read if and only if cond is true? My gcc version is: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.6.0/lto-wrapper Target: x86_64-slackware-linux Configured with: ../gcc-svn/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=c,c++,lto --enable-threads=posix --enable-checking=release --with-system-zlib --with-python-dir=/lib64/python2.6/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix gcc version 4.6.0 20110211 (experimental) (GCC)
[Bug rtl-optimization/47698] CMOV accessing volatile memory with read side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698 --- Comment #1 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2011-02-11 15:40:27 UTC --- Created attachment 23308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23308 Testcase
[Bug rtl-optimization/47698] CMOV accessing volatile memory with read side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698 Udo Steinberg us15 at os dot inf.tu-dresden.de changed: What|Removed |Added Attachment #23308|0 |1 is obsolete|| --- Comment #2 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2011-02-11 15:42:30 UTC --- Created attachment 23309 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23309 Testcase
[Bug c++/46682] New: __sync_bool_compare_and_swap generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46682 Summary: __sync_bool_compare_and_swap generates wrong code Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de Created attachment 22544 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22544 Testcase Compile testcase with: gcc-4.5.1 -MP -MMD -pipe -m32 -Os -march=i686 -mpreferred-stack-boundary=2 -mregparm=3 -fdata-sections -ffunction-sections -fomit-frame-pointer -freg-struct-return -freorder-blocks -funit-at-a-time -fno-exceptions -fno-rtti -fno-stack-protector -fvisibility-inlines-hidden -Wall -Wextra -Waggregate-return -Wcast-align -Wcast-qual -Wconversion -Wdisabled-optimization -Wformat=2 -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wshadow -Wwrite-strings -Wabi -Wctor-dtor-privacy -Wno-non-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wframe-larger-than=64 -Wlogical-op -Wstrict-null-sentinel -Wstrict-overflow=5 -Wvolatile-register-var -c testcase.cc -o testcase.o This results in: Ec::generate_wrong_code(): 0: 53 push %ebx 1: b8 01 00 00 00 mov$0x1,%eax 6: e8 fc ff ff ff call 7 Ec::generate_wrong_code()+0x7 b: 31 d2 xor%edx,%edx d: 31 c9 xor%ecx,%ecx f: 6a 00 push $0x0 11: 6a 00 push $0x0 13: 6a 00 push $0x0 15: 89 c3 mov%eax,%ebx 17: e8 fc ff ff ff call 18 Ec::generate_wrong_code()+0x18 1c: 8b 15 00 00 00 00 mov0x0,%edx 22: 31 c0 xor%eax,%eax 24: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 28: 83 c4 0cadd$0xc,%esp 2b: 74 07 je 34 Ec::generate_wrong_code()+0x34 2d: b8 01 00 00 00 mov$0x1,%eax 32: eb 02 jmp36 Ec::generate_wrong_code()+0x36 34: 31 c0 xor%eax,%eax 36: e8 fc ff ff ff call 37 Ec::generate_wrong_code()+0x37 The add at offset 28 is messing up the flags for the je at offset 2b.
[Bug target/46187] New: Invalid instruction suffix generated by %z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46187 Summary: Invalid instruction suffix generated by %z Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de Created attachment 22163 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22163 Testcase The testcase compiled with -Os should produce something like the following: 4004cc: f0 80 6c 24 ff 01 lock subb $0x1,-0x1(%rsp) 4004d5: f0 66 83 6c 24 fc 02lock subw $0x2,-0x4(%rsp) 4004df: f0 48 83 6c 24 f0 03lock subq $0x3,-0x10(%rsp) This works correctly on 4.5.1 and 4.6.0. Older compilers fail as shown below. The code is supposed to emit the correct instruction suffix for SUB using %z when n is an immediate value that does not give the operand size away. Is there another way to achieve the same effect? g++-gcc-4.1.2 -Os testcase.cc -o testcase testcase.cc: In function 'int main()': testcase.cc:20: internal compiler error: in print_operand, at config/i386/i386.c:7226 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. g++-gcc-4.2.4 -Os testcase.cc -o testcase testcase.cc: In function 'int main()': testcase.cc:20: internal compiler error: in print_operand, at config/i386/i386.c:7791 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. g++-gcc-4.3.5 -Os testcase.cc -o testcase testcase.cc: Assembler messages: testcase.cc:5: Error: invalid instruction suffix for `sub' testcase.cc:5: Error: no such instruction: `subll $3,-16(%rsp)' g++-gcc-4.4.5 -Os testcase.cc -o testcase testcase.cc: Assembler messages: testcase.cc:5: Error: invalid instruction suffix for `sub' testcase.cc:5: Error: no such instruction: `subll $3,-16(%rsp)'
[Bug target/46187] Invalid instruction suffix generated by %z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46187 --- Comment #1 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2010-10-26 15:03:01 UTC --- Bug #31768 is probably related.
[Bug other/45996] -falign-functions=X does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45996 --- Comment #2 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2010-10-13 12:06:32 UTC --- Created attachment 22029 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22029 Testcase gcc -Os -falign-functions=32 foo.cc -o foo nm foo | c++filt | grep func_ 004004f6 T func_bar() 00400500 T func_baz() 004004ec T func_foo() gcc -falign-functions=32 foo.cc -o foo nm foo | c++filt | grep func_ 00400520 T func_bar() 00400540 T func_baz() 00400500 T func_foo() So it seems to be related to the -Os option. My gcc is configured as follows: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.6.0/lto-wrapper Target: x86_64-slackware-linux Configured with: ../gcc-svn/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix gcc version 4.6.0 20101005 (experimental) (GCC)
[Bug other/45996] -falign-functions=X does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45996 --- Comment #3 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2010-10-13 12:19:57 UTC --- According to the gcc manpage: -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version But this is what actually happens: gcc -Os -Q --help=optimizers | grep align-functions -falign-functions [enabled] gcc -Os -falign-functions -Q --help=optimizers | grep align-functions -falign-functions [enabled] gcc -Os -falign-functions=32 -Q --help=optimizers | grep align-functions -falign-functions [disabled]
[Bug other/45996] New: -falign-functions=X does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45996 Summary: -falign-functions=X does not work Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de According to the gcc manpage, specifying -falign-functions=X should align functions on an X-byte boundary. This works correctly with 4.1.2, 4.2.4, and 4.3.5. It does not work with 4.4.5, 4.5.1, 4.6.0 (svn) and will instead cause function aligning to be completely disabled. This can be observed both in generated code and in gcc --help=optimizers
