[Bug libstdc++/43877] container declaration disables standard output
--- Comment #5 from nico at josuttis dot de 2010-04-25 07:03 --- I gues with move.exe you mean my generated exe file. I have three versions here: cygcheck for the full buggy program (including vector declaration): --- D:\buecher\libbook2\book\code\cont\try\hello.exe P:\gcc4\bin\cyggcc_s-sjlj-1.dll P:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll cygcheck for the working program (without vector declaration): -- D:\buecher\libbook2\book\code\cont\try\hello.exe P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll P:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll cygcheck for a working program with g++4.4.3(with vector declaration): -- D:\buecher\libbook2\book\code\cont\try\hello.exe P:\gcc4\bin\cyggcc_s-sjlj-1.dll P:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll Hmm, looks probably not correct that the cygwin libs are used: P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll which would mean that options such as --prefix=/cygdrive/p/gcc4 --program-suffix=4 --with-gxx-include-dir=/cygdrive/p/gcc4-include would not work properly or be enough. Attached you also get the exe file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #6 from nico at josuttis dot de 2010-04-25 07:06 --- Created an attachment (id=20480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20480action=view) hello.exe for the buggy 4.5.0 version (with declared vector) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug c++/43884] New: Performance degradation of the simple example (fibonacci) 4.3.3-4.5.0
I ran this simple example with the argument 45 through various versions of gcc
(option -O3):
#include stdlib.h
#include stdio.h
int fib(int AnArg) {
if (AnArg = 2) return (1);
return (fib(AnArg-1)+fib(AnArg-2));
}
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
printf(fib(%i)=%i\n, n, fib(n));
}
Here are the average runtimes I got:
versiontime
4.3.1 3.930s
4.3.2 3.500s
4.3.3 3.470s
4.4.1 3.930s
4.4.3 3.940s
4.5.0 3.860s
I ran ~10 samples so values are approximate, but it's quite obvious that 4.5.0
has very significant degradation compared to 4.3.3.
Is there a performance suite for gcc that is ran for each release, are results
available online?
This case is pretty simple, basic. I would expect gcc to produce quite optimal
code for it.
--
Summary: Performance degradation of the simple example
(fibonacci) 4.3.3-4.5.0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #7 from nico at josuttis dot de 2010-04-25 07:25 --- compiling with -static also fixes the problem, which also supports the theory of using wrong DLL's. The only question is, why are the wrong libs used without -static. Any idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #2 from ubizjak at gmail dot com 2010-04-25 07:37 --- The attached source does not fail for x86_64-linux target. Can you try to run the compilation through the debugger to provide a backtrace? Follow this procedure: gdb --args /path/to/gcc/cc1 [...flags...] -quiet source.i [...] (gdb) break fancy_abort [...] (gdb) run [...] (gdb) bt It looks that the failure is solaris specific, CC added. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug bootstrap/43870] ICE in gcc/config/soft-fp/divtf3.c
--- Comment #3 from gcc-tgc at jupiterrise dot com 2010-04-25 09:34 --- $ gdb --args /export/home/tgc/build/gcc450_all_native/./gcc/cc1 -fpreprocessed divtf3.i -quiet -dumpbase divtf3.c -mtune=generic -march=pentium4 -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -o divtf3.s GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-pc-solaris2.8... (gdb) break fancy_abort Breakpoint 1 at 0x84c5bc4: file /export/home/tgc/source/gcc-4.5.0/gcc/diagnostic.c, line 763. (gdb) run Starting program: /export/home/tgc/build/gcc450_all_native/gcc/cc1 -fpreprocessed divtf3.i -quiet -dumpbase divtf3.c -mtune=generic -march=pentium4 -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -o divtf3.s warning: Temporarily disabling breakpoints for unloaded shared library /usr/lib/ld.so.1 GNU C (GCC) version 4.5.0 (i386-pc-solaris2.8) compiled by GNU C version 4.3.4, GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 (i386-pc-solaris2.8) compiled by GNU C version 4.3.4, GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 69cf92c491c71b15695da53015b23e3b /export/home/tgc/source/gcc-4.5.0/libgcc/../gcc/config/soft-fp/divtf3.c: In function '__divtf3': /export/home/tgc/source/gcc-4.5.0/libgcc/../gcc/config/soft-fp/divtf3.c:38:169: warning: 'R_e' may be used uninitialized in this function Program received signal SIGSEGV, Segmentation fault. 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 2357 if (DF_REF_CLASS (ref1) != DF_REF_CLASS (ref2)) (gdb) bt #0 0x084bd3c5 in df_ref_compare (r1=0xa3278a4, r2=0xa3278ac) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2357 #1 0xdf89b889 in qsort () from /usr/lib/libc.so.1 #2 0x084bd8e2 in df_sort_and_compress_refs (ref_vec=0x8047678) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2449 #3 0x084be0cb in df_canonize_collection_rec (collection_rec=0x8047674) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:2581 #4 0x084bfd2b in df_insn_refs_collect (collection_rec=0x8047674, bb=0xdf5f7e40, insn_info=0xa2b93ec) at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:3589 #5 0x084c035a in df_bb_refs_record (bb_index=89, scan_insns=1 '\001') at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:3728 #6 0x084b9dce in df_scan_blocks () at /export/home/tgc/source/gcc-4.5.0/gcc/df-scan.c:702 #7 0x08497012 in rest_of_handle_df_initialize () at /export/home/tgc/source/gcc-4.5.0/gcc/df-core.c:739 #8 0x0898b161 in execute_one_pass (pass=0xa137580) at /export/home/tgc/source/gcc-4.5.0/gcc/passes.c:1568 #9 0x0898b340 in execute_pass_list (pass=0xa137580) at /export/home/tgc/source/gcc-4.5.0/gcc/passes.c:1623 #10 0x0898b360 in execute_pass_list (pass=0xa1c40c0) at /export/home/tgc/source/gcc-4.5.0/gcc/passes.c:1624 #11 0x08e5878c in tree_rest_of_compilation (fndecl=0xdf7bb880) at /export/home/tgc/source/gcc-4.5.0/gcc/tree-optimize.c:413 #12 0x0965ac8e in cgraph_expand_function (node=0xdf7cc170) at /export/home/tgc/source/gcc-4.5.0/gcc/cgraphunit.c:1548 #13 0x0965aeec in cgraph_expand_all_functions () at /export/home/tgc/source/gcc-4.5.0/gcc/cgraphunit.c:1627 #14 0x0965b4da in cgraph_optimize () at /export/home/tgc/source/gcc-4.5.0/gcc/cgraphunit.c:1875 #15 0x09659584 in cgraph_finalize_compilation_unit () at /export/home/tgc/source/gcc-4.5.0/gcc/cgraphunit.c:1096 #16 0x0811c18b in c_write_global_declarations () at /export/home/tgc/source/gcc-4.5.0/gcc/c-decl.c:9519 #17 0x08c28bb5 in compile_file () at /export/home/tgc/source/gcc-4.5.0/gcc/toplev.c:1065 #18 0x08c2abea in do_compile () at /export/home/tgc/source/gcc-4.5.0/gcc/toplev.c:2417 #19 0x08c2acb7 in toplev_main (argc=29, argv=0x8047948) at /export/home/tgc/source/gcc-4.5.0/gcc/toplev.c:2459 #20 0x0829301f in main (argc=Cannot access memory at address 0x2 ) at /export/home/tgc/source/gcc-4.5.0/gcc/main.c:35 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43870
[Bug bootstrap/43885] New: [4.6 Regression] Ada bootstrap fails with STORAGE_ERROR
raised STORAGE_ERROR : stack overflow (or erroneous memory access) make[3]: *** [ada/treeprs.ads] Fehler 1 make[3]: *** Warte auf noch nicht beendete Prozesse... make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc' make[2]: *** [all-stage1-gcc] Fehler 2 make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin' make[1]: *** [stage1-bubble] Fehler 2 make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin' make: *** [all] Fehler 2 The bootstrapping compiler is i...@linux-fd1f:~/Gcc/trunk-bin gcc -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 --enable-languages=all,ada --with-mpc=/usr/local Thread-Modell: posix gcc-Version 4.6.0 20100412 (experimental) (GCC) -- Summary: [4.6 Regression] Ada bootstrap fails with STORAGE_ERROR Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
[Bug bootstrap/43885] [4.6 Regression] Ada bootstrap fails with STORAGE_ERROR
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-04-25 11:16 --- Created an attachment (id=20481) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20481action=view) Build log (with script) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
[Bug c++/43884] Performance degradation of the simple example (fibonacci) 4.3.3-4.5.0
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-25 11:42 --- You can compare the code if you compile with -S (output .s assembler file). Or you can compile with -S and attach the output of both compilers here, so someone else can have a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug c++/43884] [4.4/4.5 Regression] Performance degradation for simple fibonacci numbers calculation
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-25 12:13 --- Confirmed on x86_64-linux by comparing gcc 4.3.3 vs. gcc 4.6.0 (r158482). The average of 10 runs on each is 5.1s with gcc 4.3.3 vs. 5.7s for gcc 4.4.2, gcc 4.5.0 and gcc 4.6.0. One interesting difference is that GCC 4.5 does not inline fib. But that shouldn't have a big impact on performance. The generated code for fib is completely different (maybe an IRA thing??), so it's hard to tell where the slow-down comes from. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-25 12:13:24 date|| Summary|Performance degradation of |[4.4/4.5 Regression] |the simple example |Performance degradation for |(fibonacci) 4.3.3-4.5.0|simple fibonacci numbers ||calculation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #8 from davek at gcc dot gnu dot org 2010-04-25 12:14 --- P:\gcc4\bin\cyggcc_s-sjlj-1.dll This is the source of all your problems. Sorry, I should have been able to work this out just from seeing your configure line earlier. The SJLJ and DW2 EH models are incompatible. This is a copy of the shared libgcc dll built using sjlj exceptions, and it won't be compatible with any of the other DLLs in your system. In particular: D:\buecher\libbook2\book\code\cont\try\hello.exe P:\gcc4\bin\cyggcc_s-sjlj-1.dll P:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll ... note how you have *two* different kinds of incompatible libgcc_s DLL loaded into the same application, one directly from the app, one that libstdc++ itself is using. They're not going to get along well! In order to build GCC so that the newly-generated DLLs (and hence the exes that link to them) are compatible with the DLLs in the Cygwin distro, it's always necessary to configure with --disable-sjlj-exceptions. (Yes, this should become the default now that 1.7 is out.) It's also probably the case that your app would work if you got rid of the standard distro versions of the libstdc++ and libgcc_s DLLs and made sure your executable consistently used the newly-built ones; part of the problem is caused becuase on windows we can't embed full paths to libraries in an application when linking, meaning that we can't build the exes so that they know which of your two libstdc++ DLLs they actually want to link to. So your app, which was built by a gcc that knows it wants to use SJLJ EH, links against libgcc_s-sjlj; but because this naming scheme isn't (yet) extended to the other language runtimes, it links against any-old-libstdc-that-comes-first-in-the-path. In general, if you're building and using a custom GCC in a different --prefix setting, make sure to put that $prefix/bin first in your path at all times, so that your applications always load the freshly-built versions of the DLLs when they run. I'm guessing you've got it somewhere late in your path, so that when you launch your app the windows OS loader finds the standard libstdc++ DLL first. This should hopefully also make it clear why you don't see any problems with -static; your code gets linked by gcc against the static libraries that came with that particular gcc; it's only when using DLLs, where the windows OS loader doesn't know anything about which DLL to use so it chooses the first in the path, that this kind of mixup can happen. (As general advice, when you're building GCC on any system, always run gcc -v on the existing system compiler and take a look at how it was configured; try and follow the existing options whenever they relate to important code-generation stuff like exception handling methods.) -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug c++/43886] New: [C++0x] name lookup failure on un-used local variable in lambda compound-statement
The following code (reduced for context) is taken from n3092
[expr.prim.lambda], 5.1.2/13, where it states:
A lambda expression appearing in a default argument shall not implicitly or
explicitly capture and entity.
/cygdrive/d/CPPProjects/nano/gcc_bugs $cat _5_1_2_13.cpp
// file: _5_1_2_13.cpp
void f2() {
int i = 1;
// ...
void g5(int = ([]{ return sizeof i; })());
}
gcc-4.5.0 fails this code with the following error messages.
12:51:47 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $i686-pc-cygwin-gcc-4.5.0 -Wall
-save-temps -std=c++0x -c _5_1_2_13.cpp
_5_1_2_13.cpp: In lambda function:
_5_1_2_13.cpp:6:37: error: local variable i may not appear in this context
_5_1_2_13.cpp:6:40: error: return-statement with a value, in function returning
'void'
_5_1_2_13.cpp: In function void f2():
_5_1_2_13.cpp:6:44: error: default argument for int anonymous has type
void
_5_1_2_13.cpp:4:8: warning: unused variable i
Appearance of the local variable i in this context is valid on the grounds
that, in the first instance, the operand to sizeof is an unevaluated operand
(as per 5.3.3./1 [expr.sizeof]) and hence (as per 3.2/2 [basic.def.odr]) its
presence here does not constitute a use (which would otherwise require it to be
explicitly or implicitly captured, the latter according to 5.1.2/11). However,
5.1.2/7 should still apply - The lambda-expression's compound-statement yields
the function body (8.4) of the function call operator, but for the purposes of
name lookup (3.4), [...] the compound-statement is considered in the context of
the lambda-expression.
12:54:21 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $i686-pc-cygwin-gcc-4.5.0 -v
Using built-in specs.
COLLECT_GCC=i686-pc-cygwin-gcc-4.5.0
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.5.0 --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as
--with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++
--disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix
--with-arch-i686 --with-tune=generic
Thread model: posix
gcc version 4.5.0 (GCC)
--
Summary: [C++0x] name lookup failure on un-used local variable in
lambda compound-statement
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot bibbings at gmail dot com
GCC host triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43886
[Bug bootstrap/43885] [4.6 Regression] Ada bootstrap fails with STORAGE_ERROR
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-04-25 12:51 --- Bootstrap succeeds when the first-stage compiler is 4.4.0. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
[Bug ada/43885] [4.6 Regression] build failure using self
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:07 --- Please try with a more recent version (or avoid bootstrapping with mainline at all, it's in constant flux). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|bootstrap |ada Summary|[4.6 Regression] Ada|[4.6 Regression] build |bootstrap fails with|failure using self |STORAGE_ERROR | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43885
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #9 from nico at josuttis dot de 2010-04-25 14:15 --- Subject: Re: container declaration disables standard output Thanks a lot, Paolo and Dave. The explanation makes total sense to me and putting gcc 4.5.0 in front of the path fixes the problem. I would have searched very long (especially as I didn't know cygcheck and the history of exception handling models). Best regards Nico davek at gcc dot gnu dot org schrieb/wrote: --- Comment #8 from davek at gcc dot gnu dot org 2010-04-25 12:14 --- P:\gcc4\bin\cyggcc_s-sjlj-1.dll This is the source of all your problems. Sorry, I should have been able to work this out just from seeing your configure line earlier. The SJLJ and DW2 EH models are incompatible. This is a copy of the shared libgcc dll built using sjlj exceptions, and it won't be compatible with any of the other DLLs in your system. In particular: D:\buecher\libbook2\book\code\cont\try\hello.exe P:\gcc4\bin\cyggcc_s-sjlj-1.dll P:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll ... note how you have *two* different kinds of incompatible libgcc_s DLL loaded into the same application, one directly from the app, one that libstdc++ itself is using. They're not going to get along well! In order to build GCC so that the newly-generated DLLs (and hence the exes that link to them) are compatible with the DLLs in the Cygwin distro, it's always necessary to configure with --disable-sjlj-exceptions. (Yes, this should become the default now that 1.7 is out.) It's also probably the case that your app would work if you got rid of the standard distro versions of the libstdc++ and libgcc_s DLLs and made sure your executable consistently used the newly-built ones; part of the problem is caused becuase on windows we can't embed full paths to libraries in an application when linking, meaning that we can't build the exes so that they know which of your two libstdc++ DLLs they actually want to link to. So your app, which was built by a gcc that knows it wants to use SJLJ EH, links against libgcc_s-sjlj; but because this naming scheme isn't (yet) extended to the other language runtimes, it links against any-old-libstdc-that-comes-first-in-the-path. In general, if you're building and using a custom GCC in a different --prefix setting, make sure to put that $prefix/bin first in your path at all times, so that your applications always load the freshly-built versions of the DLLs when they run. I'm guessing you've got it somewhere late in your path, so that when you launch your app the windows OS loader finds the standard libstdc++ DLL first. This should hopefully also make it clear why you don't see any problems with -static; your code gets linked by gcc against the static libraries that came with that particular gcc; it's only when using DLLs, where the windows OS loader doesn't know anything about which DLL to use so it chooses the first in the path, that this kind of mixup can happen. (As general advice, when you're building GCC on any system, always run gcc -v on the existing system compiler and take a look at how it was configured; try and follow the existing options whenever they relate to important code-generation stuff like exception handling methods.) -- Nicolai M. Josuttis SOA in Practice http://soa-in-practice.com IT communication http://it-communication.com Solutions in Time http://www.josuttis.de +49 (0)531 / 129 88 86 +49 (0)700 / 5678 +49 (0)700 / JOSUTTIS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-25 14:31 --- can you provide a backtrace of this crash ? Putting a breakpoint at fancy_abort is not enough to get a backtrace: [karma] gcc/darwin_buildw% gdb /opt/gcc/darwin_buildw/./gcc/xgcc GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009) ... a lot of warning: Could not find object file ... ... .. done (gdb) b fancy_abortBreakpoint 1 at 0x47d8 (gdb) run -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include -O1 -g conftest.c Starting program: /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include -O1 -g conftest.c ... a lot of warning: Could not find object file ... ... .+.. done cc1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program exited with code 01. What is the version of the system compiler used for that build ? gcc version 4.0.1 (Apple Inc. build 5493) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-25 14:32 ---
Created an attachment (id=20482)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs (hopefully). However, (at least) the following
regressions are left (all including generic TBPs):
* dynamic_dispatch_{1-3,5,7}.f03 in the testsuite
* comment #8 example 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:39 --- Putting a breakpoint at fancy_abort is not enough to get a backtrace: Because you aren't debugging the right executable (xgcc instead of cc1). Pass -v to the driver to get the command line involving cc1 and feed it to cc1 directly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug target/43869] ms_abi - sysv_abi passing float arguments incorrectly
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2010-04-25 14:41 --- Created an attachment (id=20483) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20483action=view) Patch that fixes the testcase It appears that SSE_REGPARM_MAX will change based on ix86_cfun_abi(), so using SSE_REGPARM_MAX will cause sse regparm max to be 4, if calling a sysv function from a ms_abi function. The attached patch will clean up some of the issues. setup_incoming_varargs_64 will also assume the sysv abi now, since setup_incoming_varargs_ms_64 is a separate function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #18 from janus at gcc dot gnu dot org 2010-04-25 14:42 --- Here is a maximally reduced version of comment #8 example 2, which still fails with the patch in comment #17: module m type :: t1 contains procedure :: make_integer generic :: extract = make_integer end type contains integer function make_integer (arg) class(t1), intent(in) :: arg make_integer = 3 end function end module use m class(t1), allocatable :: a allocate(a) print *, a%extract () end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #19 from janus at gcc dot gnu dot org 2010-04-25 14:56 ---
Created an attachment (id=20484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:
* dynamic_dispatch_{1-3}.f03
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-25 15:39 --- Because you aren't debugging the right executable (xgcc instead of cc1). Pass -v to the driver to get the command line involving cc1 and feed it to cc1 directly. Thanks for the tip. The backtrace is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0005 0x0054f754 in read_integral_parameter () (gdb) bt #0 0x0054f754 in read_integral_parameter () #1 0x00485700 in decode_options () #2 0x00551278 in toplev_main () #3 0x1c44 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug web/43887] New: stable anchors needed
The anchors created by makeinfo --html are not stable. This means that links to anchors become outdated quickly. For example, the links to options in http://gcc.gnu.org/gcc-4.5/changes.html are already broken. -- Summary: stable anchors needed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43887
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #20 from pault at gcc dot gnu dot org 2010-04-25 16:27 --- (In reply to comment #19) Janus, When I got up this morning, I made a start on documenting the fortran-dev version of gfc_find_derived_vtab with a view to understand the code flow and to understand why the original patch was failing. My suspicion, which is strengthened by the remaining regressions for version 3 of your fix, is that the generic components of the vtab should not be marked as ppc. I have been tempted to apply it blind but have been trying to analyse first :-) That does not mean that you should not give it a shot, though! Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-25 16:38 ---
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:
* dynamic_dispatch_{1-3}.f03
I also have
[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03: In function
'check_in_module':
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0: internal
compiler error: Segmentation fault
[macbook] f90/bug% gfc pr43199.f90
pr43199.f90: In function 'char_less_equal_string':
pr43199.f90:162:0: internal compiler error: Segmentation fault
Note that this may be due to some interference between the patch in comment #19
and other ones I have in my tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #22 from janus at gcc dot gnu dot org 2010-04-25 16:43 ---
(In reply to comment #21)
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0:
internal
compiler error: Segmentation fault
Yes, I can confirm that: typebound_operator_{3,4}.f03 both fail with an ICE.
Thanks for pointing that out. I haven't checked the full testsuite yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #23 from janus at gcc dot gnu dot org 2010-04-25 17:09 ---
Created an attachment (id=20485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #24 from janus at gcc dot gnu dot org 2010-04-25 17:16 --- (In reply to comment #20) My suspicion, which is strengthened by the remaining regressions for version 3 of your fix, is that the generic components of the vtab should not be marked as ppc. I have been tempted to apply it blind but have been trying to analyse first :-) That does not mean that you should not give it a shot, though! Well, in the light of today's progress I am quite optimistic that it should be possible to have everything working with all the 'ppc' attributes in place. Note that many cases of generic TBPs are working already. The remaining failures seem to be related to generic TBPs with overriding. The following is a reduced version of the runtime failure in dynamic_dispatch_1.f03: module m type :: t1 integer :: i = 42 contains procedure, pass :: make_integer generic, public :: extract = make_integer end type t1 type, extends(t1) :: t2 integer :: j = 99 contains procedure, pass :: make_integer_2 generic, public :: extract = make_integer_2 end type t2 contains integer function make_integer (arg, arg2) class(t1), intent(in) :: arg integer :: arg2 make_integer = arg%i * arg2 end function make_integer integer function make_integer_2 (arg, arg2) class(t2), intent(in) :: arg integer :: arg2 make_integer_2 = arg%j * arg2 end function make_integer_2 end module m use m class(t1), pointer :: a type(t2), target :: c a = c print *,a%extract(3) if (a%extract (3) .ne. 297) call abort! FAIL end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #25 from janus at gcc dot gnu dot org 2010-04-25 18:23 ---
I just did a full testsuite run, verifying that dynamic_dispatch_{1-3}.f03
are indeed the only failures with the patch in comment #23.
This means that, if we can fix the failure in comment #24, the branch will most
probably be clean, and we can finally merge back to trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #26 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:28 --- Subject: Re: [fortran-dev Regression] ICE: segmentation fault Dear Janus, I thought that I would lend a helping hand, so I applied your latest patch to my fortran-dev. Since I had left some of my array reference development in place, it failed to apply on *** *** 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); - gfc_trans_assign_vtab_procs (parmse-pre, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); --- 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); + gfc_trans_assign_vtab_procs (parmse-pre, e-ts.u.derived, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); Since this was a compilable source, even with the failure, I decided to build it anyway. Lo and behold, the regressions have gone :-) It's just now regtesting. Please find the whole diff attached. I hope that this helps. Cheers Paul --- Comment #27 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:28 --- Created an attachment (id=20486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug target/43888] New: FAIL: gcc.dg/alias-7.c execution test
Here's what the alias-7.c test looks like, after preprocessing:
int foo __asm__ (_ foo) __attribute__((nocommon));
extern __typeof (foo) bar __attribute__ ((weak, alias (foo)));
int
main (void)
{
if (foo != bar || foo || bar)
abort ();
return bar;
}
But here's how it compiles down using 4.5.0 on i686-pc-cygwin:
alias-7.c.003t.original:
;; Function main (null)
;; enabled by -tree-original
{
if (1)
{
abort ();
}
return bar;
}
I've established that fold_comparison is returning (integer_cst 1) for the
foo != bar test. In this clause,
/* For non-equal bases we can simplify if they are addresses
of local binding decls or constants. */
else if (indirect_base0 indirect_base1
/* We know that !operand_equal_p (base0, base1, 0)
because the if condition was false. But make
sure two decls are not the same. */
base0 != base1
TREE_CODE (arg0) == ADDR_EXPR
TREE_CODE (arg1) == ADDR_EXPR
(((TREE_CODE (base0) == VAR_DECL
|| TREE_CODE (base0) == PARM_DECL)
(targetm.binds_local_p (base0)
|| CONSTANT_CLASS_P (base1)))
|| CONSTANT_CLASS_P (base0))
(((TREE_CODE (base1) == VAR_DECL
|| TREE_CODE (base1) == PARM_DECL)
(targetm.binds_local_p (base1)
|| CONSTANT_CLASS_P (base0)))
|| CONSTANT_CLASS_P (base1)))
{
if (code == EQ_EXPR)
return omit_two_operands_loc (loc, type, boolean_false_node,
arg0, arg1);
else if (code == NE_EXPR)
return omit_two_operands_loc (loc, type, boolean_true_node,
arg0, arg1);
}
it seems that i386_pe_binds_local_p is incorrectly returning true even for the
weak symbol. I have a patch.
--
Summary: FAIL: gcc.dg/alias-7.c execution test
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: davek at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43888
[Bug target/43888] FAIL: gcc.dg/alias-7.c execution test
-- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-25 18:33:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43888
[Bug target/43888] FAIL: gcc.dg/alias-7.c execution test
--- Comment #1 from davek at gcc dot gnu dot org 2010-04-25 18:36 --- Created an attachment (id=20487) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20487action=view) Simple fix. Maybe a bit verbose; I only made it a separate if clause so it could have its own comment, but should probably just integrate it into the preceding if. This resolves the failing testcase mentioned in the title, and also IIRC fixed g++.dg/eh/weak1.C. I'm testing it against the release of 4.5.0 that I'm currently preparing for the cygwin distro and posting it here so I don't forget to backport it upstream. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43888
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #28 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:59 --- Subject: Re: [fortran-dev Regression] ICE: segmentation fault Janus, Forget all of our last exchanges - I screwed up somehow with the patch. This has nothing to do with your problem Sorry Paul On Sun, Apr 25, 2010 at 8:27 PM, Paul Richard Thomas paul.richard.tho...@gmail.com wrote: Dear Janus, I thought that I would lend a helping hand, so I applied your latest patch to my fortran-dev. Since I had left some of my array reference development in place, it failed to apply on *** *** 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); - gfc_trans_assign_vtab_procs (parmse-pre, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); --- 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); + gfc_trans_assign_vtab_procs (parmse-pre, e-ts.u.derived, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); Since this was a compilable source, even with the failure, I decided to build it anyway. Lo and behold, the regressions have gone :-) It's just now regtesting. Please find the whole diff attached. I hope that this helps. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #13 from jb at gcc dot gnu dot org 2010-04-25 19:01 --- Subject: Bug 40539 Author: jb Date: Sun Apr 25 19:01:06 2010 New Revision: 158707 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158707 Log: PR fortran/40539 Document LOGICAL representation Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #14 from jb at gcc dot gnu dot org 2010-04-25 19:04 --- The GFortran behavior is now documented on 4.4, 4.5, and trunk. Closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #29 from sfilippone at uniroma2 dot it 2010-04-25 19:16 --- (In reply to comment #27) Created an attachment (id=20486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) [edit] Tried this patch: compilation goes past the previous point, so we made progress. My library build stops later with psb_ssymbmm.f90: In function 'psb_ssymbmm': psb_ssymbmm.f90:88:0: error: statement makes a memory store, but has no VDEFS c_7.a.$data = 0B; psb_ssymbmm.f90:88:0: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [psb_ssymbmm.o] Error 1 Does it ring a bell ? If this is not an obvious duplicate of some other issue, I'll open a PR (tomorrow) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #30 from janus at gcc dot gnu dot org 2010-04-25 19:50 --- (In reply to comment #29) (In reply to comment #27) Created an attachment (id=20486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) [edit] Tried this patch: compilation goes past the previous point, so we made progress. My library build stops later with Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try the patch in comment #23, which is clean (except for a small regression) and fixes your original problem. Does this give the same error on your code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-25 20:03 --- Well, the innermost loop with current trunk is .L3: leal-1(%ebx), %eax subl$2, %ebx movl%eax, (%esp) callfib addl%eax, %esi cmpl$2, %ebx jg .L3 which is pretty much optimal. The intel compiler doesn't detect the tail-recursion (huh) but has multiple entry-points into the function and uses register passing conventions for the recursions. With -fwhole-program GCC does the same (or with static fib), and we then end up with a program faster than what ICC produces (16s) A 4.3 compiled version is indeed a bit faster (as fast as 4.4 on i?86, 15.4s). A 4.1 compiled version is even faster (14.1s), the 3.4 baseline is 21.5s. That's on i?86-linux, all -O2. 4.1 assembly, fib is not inlined: fib: pushl %esi pushl %ebx movl%eax, %ebx cmpl$2, %ebx movl$1, %eax jle .L5 xorl%esi, %esi .p2align 4,,7 .L6: leal-1(%ebx), %eax subl$2, %ebx callfib addl%eax, %esi cmpl$2, %ebx jg .L6 leal1(%esi), %eax .L5: popl%ebx popl%esi ret trunk assembler: fib: pushl %esi pushl %ebx movl%eax, %ebx subl$4, %esp cmpl$2, %ebx movl$1, %eax jle .L2 xorl%esi, %esi .p2align 4,,7 .p2align 3 .L3: leal-1(%ebx), %eax subl$2, %ebx callfib addl%eax, %esi cmpl$2, %ebx jg .L3 leal1(%esi), %eax .L2: addl$4, %esp popl%ebx popl%esi ret where the only difference is different loop alignment and keeping the stack 16-bytes aligned. Indeed we get the same speed as 4.1 when building with -mpreffered-stack-boundary=2. Why do we bother to keep the stack aligned for leaf functions? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org, ||hubicka at gcc dot gnu dot ||org Component|c++ |target GCC target triplet||i?86-*-* Keywords||missed-optimization Known to work||4.1.3 Summary|[4.4/4.5 Regression]|[4.4/4.5/4.6 Regression] |Performance degradation for |Performance degradation for |simple fibonacci numbers|simple fibonacci numbers |calculation |calculation due to extra ||stack alignment Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-25 20:06 --- Btw, with the optimal options -O2 -fwhole-program -fomit-frame-pointer -mpreferred-stack-boundary=2 GCC 4.3 and 4.4 are slower than 4.1 and 4.5 (14.3s vs. 13.8s). The extra stack alignment drops us to 16.4s(!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug target/43883] missed optimization of constant __int128_t modulus
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-25 20:09 --- There isn't any pattern for the TImode variant. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43883
[Bug c++/43881] warning attached to a function is emitted even though the function is not being called
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-25 20:13 --- (In reply to comment #4) (In reply to comment #2) It is called directly because safe_close's value is replaced in the indirect call. Since safe_close is static and not changed in the code at all, it is marked as read only and the initialized value can be used directly. This is an explanation why gcc behaves like this, but not a justification. 1) GCC should try to make warnings independent of optimization settings. 2) GCC warns about a line of code that calls 'safe_close', which it should not warn about. Only calls of 'close' should be warned about, and there are no such calls in the source program. I can see that other people will exactly requrest the opposite (that is, current behavior). 1) is always good, but unfortunately not possible (and in fact people request that with more knowledge available from an optimized program they should get improved warnings). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-25 20:13 --- Well. Mine then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-24 21:44:56 |2010-04-25 20:13:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #31 from janus at gcc dot gnu dot org 2010-04-25 20:17 ---
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:
--- c24.dump.unpatched 2010-04-25 22:03:44.418204091 +0200
+++ c24.dump.patched2010-04-25 21:55:50.500619202 +0200
@@ -27,7 +27,7 @@ MAIN__ ()
if (vtab$t2.make_integer == 0B)
{
vtab$t2.make_integer = (integer(kind=4) (*T434) (void)) make_integer;
- vtab$vtype$t2$extract.make_integer = make_integer_2;
+ vtab$vtype$t2$extract.make_integer = (integer(kind=4) (*T43f) (struct
.class.t2 restrict, integer(kind=4) restrict)) make_integer;
vtab$t2.extract = vtab$vtype$t2$extract;
vtab$t2.make_integer_2 = (integer(kind=4) (*T434) (void))
make_integer_2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #32 from sfilippone at uniroma2 dot it 2010-04-25 20:20 --- (In reply to comment #30) Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try the patch in comment #23, which is clean (except for a small regression) and fixes your original problem. Does this give the same error on your code? Actually I tried both, and both give the same error. The obvious question is whether this is related to the patch or not. I really look forward to the merge into trunk, and I would prefer reporting the new bug against trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-25 20:31 --- (In reply to comment #5) It really was picking up the default libstdc++.so from the OS installation. I used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out that -L/path/to/4.5.0/libstdc++.so is also required in addition to this, otherwise the default libstdc++.so is looked up by linker. Maybe this is a bug in linker, don't know. No, that's the expected behaviour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #33 from janus at gcc dot gnu dot org 2010-04-25 21:44 ---
Created an attachment (id=20488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of regressions in class_*, dynamic_* and
typebound_*. Will do a full testsuite run now.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #20482|0 |1
is obsolete||
Attachment #20484|0 |1
is obsolete||
Attachment #20485|0 |1
is obsolete||
Attachment #20486|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-25 22:01 --- (In reply to comment #4) Btw, with the optimal options -O2 -fwhole-program -fomit-frame-pointer -mpreferred-stack-boundary=2 GCC 4.3 and 4.4 are slower than 4.1 and 4.5 (14.3s vs. 13.8s). The extra stack alignment drops us to 16.4s(!). The slowdown also happens on x86-64. Stack alignment checks leaf function. But I am sure if it detects tail-recursion. Is such information available to ix86_finalize_stack_realign_flags? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|hjl at gcc dot gnu dot org |hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug middle-end/43889] New: [4.6/4.5 Regression]: mmix-knuth-mmixware gcc.c-torture/execute/arith-rand.c -O3 -fomit-frame-pointer -funroll-loops
I've triaged the following regressions to be introduced at revision r154688: FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/arith-rand.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/arith-rand.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions Looking through other reports, that revision (including follow-ups) exposed latent bugs in other ports, so it's not unlikely the case here as well. Still, I think it's reasonable to CC the author of that revision and marking this PR as middle-end, at least until I've looked closer. -- Summary: [4.6/4.5 Regression]: mmix-knuth-mmixware gcc.c- torture/execute/arith-rand.c -O3 -fomit-frame-pointer - funroll-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43889
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #34 from janus at gcc dot gnu dot org 2010-04-25 22:26 --- (In reply to comment #33) Will do a full testsuite run now. The testsuite completed cleanly, without any failures. Paul, if you agree that this patch is ok, I can commit it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug middle-end/43889] [4.6/4.5 Regression]: mmix-knuth-mmixware gcc.c-torture/execute/arith-rand.c -O3 -fomit-frame-pointer -funroll-loops
-- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-25 22:29:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43889
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #6 from hubicka at ucw dot cz 2010-04-25 23:42 --- Subject: Re: [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment where the only difference is different loop alignment and keeping the stack 16-bytes aligned. Indeed we get the same speed as 4.1 when building with -mpreffered-stack-boundary=2. Why do we bother to keep the stack aligned for leaf functions? We should not. Probably fallout of stack alignment patches? I will check out later. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #7 from hubicka at ucw dot cz 2010-04-25 23:43 --- Subject: Re: [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment The slowdown also happens on x86-64. Stack alignment checks leaf function. But I am sure if it detects tail-recursion. Is such information available to ix86_finalize_stack_realign_flags? Tail recursion is recognized at gimple level, so rtl code should not be at all bothered here. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug tree-optimization/41835] ICE with -flto -O3 (BB N can not throw but has an EH edge)
--- Comment #4 from hubicka at ucw dot cz 2010-04-25 23:44 --- Subject: Re: ICE with -flto -O3 (BB N can not throw but has an EH edge) Seems to work for me, even with the 4.5.0 release. Note that on mainline the code removing wpa fixup should help here too. There clearly was bugs. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41835
[Bug c++/43890] New: invalid uninitialized reference in class
Compiling with:
g++ uninit_reference.cpp -o uninit_reference.o -std=gnu++0x -c
class Outer
{
public:
Outer()
: i(*this)
{
}
class Inner
{
public:
Inner(Outer o)
: o(o)
{
}
private:
Outer o;
};
private:
Inner i;
};
class A {
Outer o;
};
int main()
{
A *a = new A;
return 0;
}
uninit_reference.cpp: In function int main():
uninit_reference.cpp:31:14: error: uninitialized reference member in class A
using new
uninit_reference.cpp:18:12: note: Outer::Inner::o should be initialized
Configured with: ../gcc-svn/configure --prefix=/home/jarryd/gcc-latest-install
--enable-languages=c,c++ : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion : (reconfigured) ../gcc-svn/configure
--prefix=/home/jarryd/gcc-latest-install --enable-languages=c,c++ --no-create
--no-recursion
Thread model: posix
gcc version 4.6.0 20100425 (experimental) (GCC)
--
Summary: invalid uninitialized reference in class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jarrydb at cse dot unsw dot edu dot au
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug target/43889] [4.6/4.5 Regression]: mmix-knuth-mmixware gcc.c-torture/execute/arith-rand.c -O3 -fomit-frame-pointer -funroll-loops
--- Comment #1 from hp at gcc dot gnu dot org 2010-04-26 02:36 --- The regrename change renamed registers so the destination overlapped a clobber in the div (or mod) insns. That in turn can be blamed on missing earlyclobbers for those alternatives in the patterns, thus changing component to target. Bernd, sorry for the noise. Feel free to re-add yourself as CC. :-) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC|bernds at gcc dot gnu dot | |org | Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43889
[Bug tree-optimization/43791] [4.6 Regression] kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
--- Comment #20 from justinmattock at gmail dot com 2010-04-26 02:41 --- Created an attachment (id=20489) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20489action=view) dmesg with 4.6.0 and latest kernel(good boot). I compiled the kernel with the -01 option and ended up hitting another error: net/netfilter/ipvs/ip_vs_xmit.c: At top level: net/netfilter/ipvs/ip_vs_xmit.c:931:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [net/netfilter/ipvs/ip_vs_xmit.o] Error 1 make[2]: *** [net/netfilter/ipvs] Error 2 make[1]: *** [net/netfilter] Error 2 make: *** [net] Error 2 after turning off ip_vs the kernel compiles all the way through. attached is dmesg of running the kernel compiled with 4.6.0 (no freezes like before for whatever that was). BTW I was too lazy to find the right command to pass to the kernel so I just changed the Makefile: diff --git a/Makefile b/Makefile index 9754615..530d87c 100644 --- a/Makefile +++ b/Makefile @@ -527,9 +527,9 @@ endif # $(dot-config) all: vmlinux ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE -KBUILD_CFLAGS += -Os +KBUILD_CFLAGS += -O1 else -KBUILD_CFLAGS += -O2 +KBUILD_CFLAGS += -O1 endif other than the ip_vs(not even sure if I use this)everything seems o.k. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-26 04:45 --- Created an attachment (id=20490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20490action=view) First attempt a a patch to allow reading inf and NaN with parens This patch implements a filter to extract the inf, infinity, and nan () forms. I am still testing and post it here for others to try if they want. I may use a case statement in the final patch. At the moment it is a toss up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
