[Bug tree-optimization/34265] Missed optimizations
--- Comment #16 from dominiq at lps dot ens dot fr 2007-11-29 08:06 --- A quick report of the comparison between the regression results for revision 130500 + patch in comment #5 + Tobias' patch for pr34262 and revision 130489 + some patches applied to rev. 130500. I have the following new failures: ERROR: gcc.dg/tree-ssa/loop-1.c: error executing dg-final: no files matched glob pattern loop-1.c.[0-9][0-9][0-9]t.cunroll UNRESOLVED: gcc.dg/tree-ssa/loop-1.c: error executing dg-final: no files matched glob pattern loop-1.c.[0-9][0-9][0-9]t.cunroll FAIL: gcc.dg/tree-ssa/loop-17.c scan-tree-dump sccp set_nb_iterations_in_loop = 1 ERROR: gcc.dg/tree-ssa/loop-23.c: error executing dg-final: no files matched glob pattern loop-23.c.[0-9][0-9][0-9]t.cunroll UNRESOLVED: gcc.dg/tree-ssa/loop-23.c: error executing dg-final: no files matched glob pattern loop-23.c.[0-9][0-9][0-9]t.cunroll FAIL: gcc.dg/vect/vect-105.c scan-tree-dump-times vect vectorized 1 loops 1 ERROR: gcc.dg/vect/vect-11a.c: error executing dg-final: no files matched glob pattern vect-11a.c.[0-9][0-9][0-9]t.vect UNRESOLVED: gcc.dg/vect/vect-11a.c: error executing dg-final: no files matched glob pattern vect-11a.c.[0-9][0-9][0-9]t.vect FAIL: gcc.dg/vect/vect-66.c scan-tree-dump-times vect vectorized 3 loops 1 FAIL: gcc.dg/vect/vect-76.c scan-tree-dump-times vect vectorized 3 loops 1 FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vect vectorized 1 loops 3 FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vect Alignment of access forced using peeling 3 FAIL: gcc.dg/vect/vect-outer-1.c scan-tree-dump-times vect strided access in outer loop 1 FAIL: gcc.dg/vect/vect-outer-6.c scan-tree-dump-times vect OUTER LOOP VECTORIZED 1 FAIL: gcc.dg/vect/vect-outer-6.c scan-tree-dump-times vect zero step in outer loop. 1 ERROR: gcc.dg/vect/vect-shift-1.c: error executing dg-final: no files matched glob pattern vect-shift-1.c.[0-9][0-9][0-9]t.vect UNRESOLVED: gcc.dg/vect/vect-shift-1.c: error executing dg-final: no files matched glob pattern vect-shift-1.c.[0-9][0-9][0-9]t.vect FAIL: gcc.dg/vect/no-section-anchors-vect-66.c scan-tree-dump-times vect vectorized 3 loops 1 FAIL: gcc.dg/vect/no-section-anchors-vect-66.c scan-tree-dump-times vect Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect vectorized 4 loops 1 FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect Alignment of access forced using peeling 2 ERROR: gcc.target/i386/vectorize1.c: error executing dg-final: no files matched glob pattern vectorize1.c.[0-9][0-9][0-9]t.vect UNRESOLVED: gcc.target/i386/vectorize1.c: error executing dg-final: no files matched glob pattern vectorize1.c.[0-9][0-9][0-9]t.vect FAIL: gfortran.dg/array_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/array_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/array_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/array_1.f90 -O3 -g execution test I am waiting for directives on how I can investigate further these problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #1 from ubizjak at gmail dot com 2007-11-29 08:09 --- (In reply to comment #0) b) gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 induct.f90: 61.41 [100%] vs 46.94 [ 76%] test2.f90: 5.45 [100%] vs 4.54 [ 83%] I have run the test compiled with above options, with and without -fvect-cost-model, but on Xeon 3.2G in 32bit mode: w/o -fvect-cost-model: user1m40.906s w/ -fvect-cost-model: user0m46.439s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec
--- Comment #1 from irar at il dot ibm dot com 2007-11-29 09:31 --- I can't reproduce this failure with the same flags with revision 130403 on ppc64-redhat-linux. (Some loops indeed get vectorized in reload.c and reload1.c: reload1.c.104t.vect:reload1.c:2433: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:3968: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:3749: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:784: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:697: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:3623: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:3617: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:2447: note: LOOP VECTORIZED. reload1.c.104t.vect:reload1.c:474: note: LOOP VECTORIZED. reload.c.104t.vect:reload.c:3231: note: LOOP VECTORIZED. reload.c.104t.vect:reload.c:3257: note: LOOP VECTORIZED. reload.c.104t.vect:reload.c:2352: note: LOOP VECTORIZED.) Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34038
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #13 from ek dot kato at gmail dot com 2007-11-29 09:08 --- Oops, I noticed the diff sent yesterday was broken. Here is the correct one for the workaround. Index: libgcc/Makefile.in === --- libgcc/Makefile.in (revision 130508) +++ libgcc/Makefile.in (working copy) @@ -100,8 +100,17 @@ # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. $(MAKE) install DESTDIR=$(gcc_objdir) \ - slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) + slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR) + objdir=$(gcc_objdir)/$(slibdir); \ + if test -d $$objdir; then \ + for file in $$objdir/libgcc_s*; do\ + if test -f $$file -o -L $$file; then\ + mv -f $$file $(gcc_objdir)/; \ + fi; \ + done; \ + fi + .PHONY: all-multi all-multi: # If this is the top-level multilib, build all the other -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
Simple Ada bug?
Here is my program inspired by Barnes' Ada 95 2nd book page 158: --bug1.ads package bug1 is I : Integer := 0; A: array(1.. 10) of Integer := (others = 0); procedure Silly(X: in out Integer); end bug1; --bug1.adb with Ada.Integer_Text_Io; use Ada.Integer_Text_Io; package body bug1 is procedure Silly(X: in out Integer) is begin I := I+1; X := X+1; end; begin A(5) := 1; I := 5; Silly(A(I)); Put(I, 0); --I should be 6 here I := I+1; Put(I, 0); --I should be 7 here end bug1; According to Barnes, and my understanding, 'I' should be 7 at the end of the elaboration. Calling gnatmake -z bug1 I get on Windows XP, with gcc version 4.1.3 20070403 for GNAT GPL 2007 (20070402) I get I is 5 after the Silly call (wrong) and I is 6 at the end of the elaboration on Windows XP, with gcc version 3.4.1 (mingw special) I get I is 6 after the Silly call (correct) and I is 6 (!!) at the end of the elaboration Both versions seem erroneous. Can others confirm this bug? Best Regards to the gcc community chris
[Bug c++/34270] [4.3 regression] ICE applying __decltype to ternary expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 10:07:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
[Bug c++/34275] [4.1/4.2/4.3 regression] Broken diagnostic: 'obj_type_ref' not supported by dump_expr
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 09:47:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34275
[Bug ada/34284] New: Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
Hi, * Detailed description: === The file gcc/trunk/gnattools/configure.ac contains the definition of the variable TOOLS_TARGET_PAIRS for each supported target. The x86-darwin case is missing which results in using the default file mlib-tgt-specific.adb when building GNAT for this platform. This file does not implement dynamic library support. The patch given at the end of this report solves the problem. * How to reproduce the bug: === I did not succeed to attach files to this bug report, thus I will give them here as plain text. They are very short: SPEC (p.ads): = package P is procedure Dummy; end P; BODY (p.adb): = package body P is --- -- Dummy -- --- procedure Dummy is begin null; end Dummy; end P; PROJECT FILE (not_working_project.gpr): === project Not_Working_Project is for Source_Files use (p.ads, p.adb); for Library_Name use my_lib; for Library_Dir use ./libs; for Object_Dir use ./objects; for Library_Kind use relocatable; end Not_Working_Project; COMMAND LINE: = gnatmake -p -P not_working_project.gpr EXPECTED BEHAVIOR: == object directory /Volumes/Stock/Dev/gnat_bug_report/./objects created library directory /Volumes/Stock/Dev/gnat_bug_report/./libs created gcc -c -fPIC -I- -gnatA /Volumes/Stock/Dev/gnat_bug_report/p.adb building relocatable library for project not_working_project /usr/local/gnat-430/bin/gcc -dynamiclib -o /Volumes/Stock/Dev/gnat_bug_report/libs/libmy_lib.dylib -L/usr/local/gnat-430/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -fPIC -L/usr/local/gnat-430/lib/gcc/i686-apple-darwin8/4.3.0/adalib/ -lgnat-4.3 -Wl,-flat_namespace -shared-libgcc /Volumes/Stock/Dev/gnat_bug_report/objects/p.o If we do an ls libs, we should get: libmy_lib.dylib p.ali ACTUAL BEHAVIOR: object directory /Volumes/Stock/Dev/gnat_bug_report/./objects created library directory /Volumes/Stock/Dev/gnat_bug_report/./libs created not_working_project.gpr:4:25: warning: libraries are not supported on this platform gcc -c -I- -gnatA /Volumes/Stock/Dev/gnat_bug_report/p.adb And there the 'libs' directory is empty Here is my system configuration: * the exact version of GCC, as shown by gcc -v; Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local Thread model: posix gcc version 4.3.0 20071119 (experimental) (GCC) * the system type (uname -a); Darwin x..xx 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 * the options when GCC was configured/built; ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local * Patchfile that solves the problem (produced using svn diff from gcc/trunk/gcc): --- 2007-11-29 Bechir Zalila [EMAIL PROTECTED] * gnattools/configure.ac: Added a missing switch case for *86-*-darwin* when defining the value of TOOLS_TARGET_PAIRS. * gnattools/configure: regenerated = Index: gnattools/configure === --- gnattools/configure (revision 130291) +++ gnattools/configure (working copy) @@ -1667,7 +1667,7 @@ indepsw.adbindepsw-mingw.adb EXTRA_GNATTOOLS='../../gnatdll$(exeext)' ;; - powerpc-*-darwin*) + powerpc-*-darwin* | *86-*-darwin*) TOOLS_TARGET_PAIRS=mlib-tgt-specific.adbmlib-tgt-darwin.adb ;; *-*-lynxos) Index: gnattools/configure.ac === --- gnattools/configure.ac (revision 130291) +++ gnattools/configure.ac (working copy) @@ -150,7 +150,7 @@ indepsw.adbindepsw-mingw.adb EXTRA_GNATTOOLS='../../gnatdll$(exeext)' ;; - powerpc-*-darwin*) + powerpc-*-darwin* | *86-*-darwin*) TOOLS_TARGET_PAIRS=mlib-tgt-specific.adbmlib-tgt-darwin.adb ;; *-*-lynxos) -- Summary: Missing dynamic library support for GNAT 4.3.0 on x86-*- Darwin8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bechir dot zalila at gmail dot com GCC build triplet: i686-apple-darwin8 GCC host triplet: i686-apple-darwin8 GCC target triplet: i686-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug ada/33994] wrong code for indexed component when index subtype has 'Size 32
--- Comment #4 from bauhaus at futureapps dot de 2007-11-29 10:25 --- I expect that in the case described in the report (#0) the compiler does not produce wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
[Bug ada/33994] wrong code for indexed component when index subtype has 'Size 32
--- Comment #5 from bauhaus at futureapps dot de 2007-11-29 10:27 --- BTW, I have named the procedure Too_Big for a reason ... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
[Bug c++/34270] [4.2/4.3 regression] ICE applying __decltype to ternary expression
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 10:28 --- With __typeof__ instead of __decltype this ICEs already in 4.2. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] ICE|[4.2/4.3 regression] ICE |applying __decltype to |applying __decltype to |ternary expression |ternary expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
[Bug middle-end/34282] Unnecessary load from volatile var
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-29 10:29 --- I think return z is an access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34282
[Bug c/34285] New: buffer overflow incorrectly detected
A construct with char arrays within a struct incorrectly triggers a buffer overflow warning. testcase attached. -- Summary: buffer overflow incorrectly detected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: ppc-linux-gnu GCC host triplet: ppc-linux-gnu GCC target triplet: ppc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug c/34285] buffer overflow incorrectly detected
--- Comment #1 from marcus at jet dot franken dot de 2007-11-29 10:37 --- Created an attachment (id=14664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14664action=view) xx.i gcc -O2 -Wall -c xx.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug tree-optimization/34265] Missed optimizations
--- Comment #18 from dominiq at lps dot ens dot fr 2007-11-29 10:22 --- I have had a look at what's happening for kepler.f90 (from the 2004 polyhedron test suite?) and it looks like another missed vectorization: if I count the mulpd in the kepler.s files, I find 24 before the patch and none after. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug tree-optimization/34265] Missed optimizations
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-29 10:11 --- Doh, not only I missed to diff the chunk mentioned in comment #6, but I also added the original unrolling pass, not the one only supposed to unroll inner loops #) So, change the passes.c hunk to Index: gcc/passes.c === --- gcc/passes.c(revision 130511) +++ gcc/passes.c(working copy) @@ -570,6 +570,9 @@ init_optimization_passes (void) NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); NEXT_PASS (pass_dce); + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_complete_unrolli); + NEXT_PASS (pass_tree_loop_done); NEXT_PASS (pass_cselim); NEXT_PASS (pass_dominator); /* The only const/copy propagation opportunities left after that should fix some of the testsuite failures. Some thing also to experiment with (to maybe fix some of the compile-time problems) is in the tree-lssa-loop-ivcanon.c hunk change the condition to if (!unroll_outer loop-inner) continue; to only unroll innermost loops, not all-but-outermost loops. As of pass placement another thing to look at is if it works as part of early optimizations around NEXT_PASS (pass_early_inline); NEXT_PASS (pass_cleanup_cfg); NEXT_PASS (pass_rename_ssa_copies); here NEXT_PASS (pass_ccp); NEXT_PASS (pass_forwprop); NEXT_PASS (pass_update_address_taken); or here NEXT_PASS (pass_simple_dse); NEXT_PASS (pass_sra_early); because this may enable SRA of variables in the loop body. Most of the compile-time impact is actually from doing loop discovery, but as we preserve loops now maybe we do not need pass_tree_loop_done after the early unrolling and as well not pass_tree_loop_init before the rest of loop optimizations anymore? Zdenek, can you confirm this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #1 from bechir dot zalila at gmail dot com 2007-11-29 10:09 --- Created an attachment (id=14660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14660action=view) Ada spec -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #2 from bechir dot zalila at gmail dot com 2007-11-29 10:09 --- Created an attachment (id=14661) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14661action=view) Ada package body -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #3 from bechir dot zalila at gmail dot com 2007-11-29 10:10 --- Created an attachment (id=14662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14662action=view) Ada library project file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #4 from bechir dot zalila at gmail dot com 2007-11-29 10:11 --- Created an attachment (id=14663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14663action=view) Patch to solve the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #5 from bechir dot zalila at gmail dot com 2007-11-29 10:17 --- I did not know that the attaching file to a bug report comes after the commit. I reattached the files I gave as plain text in the bug report body. Sorry :-) -- bechir dot zalila at gmail dot com changed: What|Removed |Added CC||bechir dot zalila at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug middle-end/34282] Unnecessary load from volatile var
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 10:33 --- Yes, I also think 'return z' is a load from z which cannot be optimized away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34282
[Bug tree-optimization/34265] Missed optimizations
--- Comment #19 from dominiq at lps dot ens dot fr 2007-11-29 10:40 --- Richard, I am not sure to understand your patch in comment #17. I have already in gcc/passes.c (after your patch in comment #5): NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); NEXT_PASS (pass_dce); NEXT_PASS (pass_tree_loop_init); NEXT_PASS (pass_complete_unroll); NEXT_PASS (pass_tree_loop_done); NEXT_PASS (pass_cselim); NEXT_PASS (pass_dominator); /* The only const/copy propagation opportunities left after do you mean that I should change NEXT_PASS (pass_complete_unroll); to NEXT_PASS (pass_complete_unrolli); ? I am assuming my interpretation is correct and rebuild gcc right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-29 10:42 --- __builtin___strncpy_chk (foo.a[0], line, 19, 10) The issue comes down to folding of (char*)foo into foo.a[0], we should not be doing that folding. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c |middle-end GCC build triplet|ppc-linux-gnu | GCC host triplet|ppc-linux-gnu | GCC target triplet|ppc-linux-gnu | Keywords||diagnostic Summary|buffer overflow incorrectly |[4.3 Regression] buffer |detected|overflow incorrectly ||detected Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #3 from mueller at gcc dot gnu dot org 2007-11-29 10:47 --- fortify_source=2 is supposed to reject it (only sizeof the struct member, not the whole struct is allowed). use fortify_source=1 or fix your broken code. -- mueller at gcc dot gnu dot org changed: What|Removed |Added CC||mueller at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug ada/17985] GNAT accepts extension aggregate where expexted type is not extension
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-06-14 20:34:06 |2007-11-29 10:49:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17985
[Bug c++/34286] New: Segmentation fault in exit when loading oracle client in a dynamically loaded library
When we compile an application loading Oracle client 9.2.0.4 from a dynamically (dlopen) loaded library, we get a segmentation fault in teh exit method, at the very end of the application. This does not happen when loading libclntsh.so dynamically directly from teh main method, before starting the application. This does not happen with oracle 10g client, which must have been compiled with a more recent compiler... -- Summary: Segmentation fault in exit when loading oracle client in a dynamically loaded library Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dvt at isoft dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34286
[Bug c++/34238] [4.3 regression] static data member used, but not defined error on member definition
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-29 11:07 --- Fix has been already posted 3 days ago: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01419.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01419.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug tree-optimization/34265] Missed optimizations
--- Comment #20 from dominiq at lps dot ens dot fr 2007-11-29 11:00 --- I have applied my interpretation of the first two changes in comment #17. gfortran.dg/array_1.f90 still abort and induct.v3.f90 is still not vectorized. The good news are that induct.f90 is still properly unrolled and vectorized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug c++/34238] [4.3 regression] static data member used, but not defined error on member definition
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-29 11:00 ---
Yes, this looks invalid - but can we diagnose this at compile-time?
Also, from decl2.c:
/* Error on
namespace { struct A { static int i; }; }
int foo () { return A::i; }
without A::i definition (which can't be defined in
a different CU because of the anonymous namespace).
Don't do this if DECL_INITIAL is set, because for
namespace { struct A { static const int i = 4; } };
decl_needed_p won't reliably detect whether it was
really needed. */
if (DECL_IN_AGGR_P (decl) DECL_INITIAL (decl) == NULL_TREE)
error (%Jstatic data member %qD used, but not defined,
decl, decl);
it suggests that we do not want to error in this case. But for some reason
we do not have DECL_INITIAL set for a, but only in its
template_decl-DECL_TEMPLATE_RESULT we can find it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug c++/34286] Segmentation fault in exit when loading oracle client in a dynamically loaded library
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 11:11 --- Is this really a GCC issue? Where is the crash? Use a debugger and see where the crash is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34286
[Bug tree-optimization/34265] Missed optimizations
--- Comment #21 from rguenther at suse dot de 2007-11-29 11:13 --- Subject: Re: Missed optimizations On Thu, 29 Nov 2007, dominiq at lps dot ens dot fr wrote: Richard, I am not sure to understand your patch in comment #17. I have already in gcc/passes.c (after your patch in comment #5): NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); NEXT_PASS (pass_dce); NEXT_PASS (pass_tree_loop_init); NEXT_PASS (pass_complete_unroll); NEXT_PASS (pass_tree_loop_done); NEXT_PASS (pass_cselim); NEXT_PASS (pass_dominator); /* The only const/copy propagation opportunities left after do you mean that I should change NEXT_PASS (pass_complete_unroll); to NEXT_PASS (pass_complete_unrolli); ? I am assuming my interpretation is correct and rebuild gcc right now. Yes, that's correct - I did too much copypaste there :) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-29 11:14 --- (In reply to comment #3) use fortify_source=1 or fix your broken code. The code is not broken as the person is accessing via the array via char and not via a different type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug tree-optimization/34265] Missed optimizations
--- Comment #22 from dominiq at lps dot ens dot fr 2007-11-29 11:16 --- In top of the first two patches of comment #17, I have MOVED + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_complete_unrolli); + NEXT_PASS (pass_tree_loop_done); to the first suggested place. Now gfortran.dg/array_1.f90 pass the test, induct is no longer unrolled/vectorized, but induct.v3 is: back to before the patch at least on these quick tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-29 11:25 --- It is invalid for -D_FORTIFY_SOURCE=2. -D_FORTIFY_SOURCE=1 allows all standard conforming code, -D_FORTIFY_SOURCE=2 imposes further restrictions (one is e.g. that %n for *printf arguments must be only used in strings which can't be written into, one is that the str*/stp* family of functions not only can't overflow into some other object, but can't overflow from one struct field into another, etc.). So, either rewrite the code using mem* functions (which even with -D_FORTIFY_SOURCE=2 can cross field boundaries), or rewrite it to initialize the fields individually, not in one call, or use -D_FORTIFY_SOURCE=1 instead of -D_FORTIFY_SOURCE=2. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug fortran/34186] dump-parse-tree: ICE for ts-cl-length, if ts-cl == NULL
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 11:24:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34186
[Bug fortran/34228] -std=f* should diagnose used but later typed variables
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 11:24:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34228
[Bug preprocessor/34288] New: ssize_t used in libcpp/files.c without autoconf detection
Overview: While trying to compile GCC with an old release of Mingw headers (2.4), I got a stop in libcpp, trying to use ssize_t which was not typedef'd. Steps to reproduce: - grab an old-fashionned, non-POSIX, environment - ./configure ./make all-gcc - go out for lunch if the hardware matches the software :-) Actual results: While building, one can notice (this is inside gcc/gcc): ... Configuring in ./gcc ... checking for putc_unlocked... no checking whether mbstowcs works... yes checking for ssize_t... no checking for uid_t in sys/types.h... no checking type of array argument to getgroups... int ... Configuring in ./libcpp ... gcc -I/l/src/gcc/libcpp -I. -I/l/src/gcc/libcpp/../include -I/l/src/gcc/libcpp/include -D__USE_MINGW_ACCESS -O2 -g0 -s -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I/l/src/gcc/libcpp -I. -I/l/src/gcc/libcpp/../include -I/l/src/gcc/libcpp/include -c -o files.o -MT files.o -MMD -MP -MF .deps/files.Po /l/src/gcc/libcpp/files.c l:/src/gcc/libcpp/files.c: In function `read_file_guts': l:/src/gcc/libcpp/files.c:568: error: `ssize_t' undeclared (first use in this function) ... make[1]: *** [files.o] Error 1 make[1]: Leaving directory `/home/ANTOINE/gcc/libcpp' make: *** [all-libcpp] Error 2 Expected Results: no such error :-) Build Date Platform: GCC from SVN (130488) Build env. is Mingw 2.4 inside Msys 1.10, GCC 3.4.2, a few prebuilt toolslibraries like bison/GMP/MPFR System: MINGW32_NT-5.0 ANTOINE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown Host tools (for reference) are binutils 2.18.50, the target include/ are from SVN of mingw-w64.sf.net (220) Additional Builds and Platforms: Does not occur for not-so-old (I can't decently write recent :-)) versions of MingW: ssize_t was added to sys/types.h around mid-2004 Possible fix: Perhaps adding AC_CHECK_TYPE(ssize_t, int) to libcpp/configure.ac does the job, but I am not fluent enough with autoconf to be sure (and autoconf|perl does not work correctly on my machine, sorry for that). Additional comments: The most surprising part was when I started looking at it: the problem was obvious, yet the first seek of ssize_t through the compilation log got the above point (about checking for ssize_t... no): what would be the point to auto-check for ssize_t and then fail to provide any workaround? Later I realize that the check was implemented (a looong time ago; ChangeLog says 2000-05-27 from Zack W.) inside GCC, and it was not replicated/moved_along into the semi-independent libcpp when developped; according to the additionnal comments #12 in PR/15491 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15491#c12), the problem came in 2004, probably when the libcpp/ tree was moved. I do not know if the right fix is to include some more bloating code to libcpp/files.c (copying it from whatever survives of the infrastructure in system.h put in by Zack in May 2000), or rather drop the test in gcc/configure.ac. -- Summary: ssize_t used in libcpp/files.c without autoconf detection Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: antoine64leca at hotmail dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
[Bug ada/34287] New: Simple Ada bug [Barnes' Silly]
[Already posted on gcc-bugs mailing list sorry] Here is my program inspired by Barnes' Ada 95 2nd book page 158: --bug1.ads package bug1 is I : Integer := 0; A: array(1.. 10) of Integer := (others = 0); procedure Silly(X: in out Integer); end bug1; --bug1.adb with Ada.Integer_Text_Io; use Ada.Integer_Text_Io; package body bug1 is procedure Silly(X: in out Integer) is begin I := I+1; X := X+1; end; begin A(5) := 1; I := 5; Silly(A(I)); Put(I, 0); --I should be 6 here I := I+1; Put(I, 0); --I should be 7 here end bug1; According to Barnes, and my understanding, 'I' should be 7 at the end of the elaboration. Calling gnatmake -z bug1 I get on Windows XP, with gcc version 4.1.3 20070403 for GNAT GPL 2007 (20070402) I get I is 5 after the Silly call (wrong) and I is 6 at the end of the elaboration on Windows XP, with gcc version 3.4.1 (mingw special) I get I is 6 after the Silly call (correct) and I is 6 (!!) at the end of the elaboration Both versions seem erroneous. Can others confirm this bug? Best Regards to the gcc community chris -- Summary: Simple Ada bug [Barnes' Silly] Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meudecc at itcarlow dot ie http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34287
[Bug c++/34268] [4.3 regression] ICE applying __decltype to destructor
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01619.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 11:19:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-11-29 11:25:01 |2007-11-29 11:25:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-29 11:29 --- (In reply to comment #5) family of functions not only can't overflow into some other object, but can't overflow from one struct field into another HUH There is no overflow from one struct field to another here. The assignment is for the full struct. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
--- Comment #12 from bonzini at gnu dot org 2007-11-29 11:43 --- I think this should use find_comparison_args. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
[Bug middle-end/34285] [4.3 Regression] buffer overflow incorrectly detected
--- Comment #7 from mueller at gcc dot gnu dot org 2007-11-29 11:47 --- Andrew, read the comments or stop reopening. the behaviour is documented that way even. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #17 from aldyh at gcc dot gnu dot org 2007-11-29 11:56 --- I am testing this patch, and will post to gcc-patches when they finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug ada/34289] New: Systematic recompilation of up-to-date object files when using the -s gnatmake option GNAT 4.3.0 on x86-*-Darwin8
Hi, When recompiling an Ada file (attachements p.ads p.adb) using -s option for gnatmake. The object file is systemtically rebuild even if it is up-to-date and if even the compiler flags have not changed. * How to reproduce the bug: === INPUT FILES: Attached p.ads and p.adb COMMAND LINE: = Two successive executions of: gnatmake -s p.adb EXPECTED BEHAVIOR: == first: gnatmake -s p.adb gcc -c p.adb second: gnatmake -s p.adb nothing (object file is up to date, thus it is not recompiled) ACTUAL BEHAVIOR: first: gnatmake -s p.adb gcc -c p.adb second: gnatmake -s p.adb gcc -c p.adb Object file is recompiled systematically at each execution MINI DIAGNOSTIC: If we use the -v flag of gnatmake, we get the following output: GNATMAKE 4.3.0 20071119 (experimental) Copyright (C) 1995-2007, Free Software Foundation, Inc. p.ali being checked ... - p.adb different number of switches -mmacosx-version-min=10.4 gcc -c p.adb End of compilation The command line option '-mmacosx-version-min=10.4' is added automatically by gcc when calling gnat1. Passing -v to gcc (gcc -v -c p.adb) gives the following (truncated) output: Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local Thread model: posix gcc version 4.3.0 20071119 (experimental) (GCC) ... .../gnat1 -quiet -dumpbase p.adb -mmacosx-version-min=10.4 -mtune=generic -fPIC p.adb -o /var/tmp//ccqsMDI3.s ... There are indeed several options added by gcc to gnat1 (especially -mmacosx-version-min=10.4 and -mtune=generic). But for some reason, only -mmacosx-version-min=10.4 causes the problem. Here is my system configuration: * the exact version of GCC, as shown by gcc -v; Using built-in specs. Target: i686-apple-darwin8 Configured with: ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local Thread model: posix gcc version 4.3.0 20071119 (experimental) (GCC) * the system type (uname -a); Darwin x..xx 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 * the options when GCC was configured/built; ../gcc_trunk/configure --disable-nls --prefix=/Volumes/Stock/dev/gcc-4.3_trunk --host=i686-apple-darwin8 --target=i686-apple-darwin8 --build=i686-apple-darwin8 --enable-languages=c,ada --with-gmp=/opt/local -- Summary: Systematic recompilation of up-to-date object files when using the -s gnatmake option GNAT 4.3.0 on x86-*- Darwin8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bechir dot zalila at gmail dot com GCC build triplet: i686-apple-darwin8 GCC host triplet: i686-apple-darwin8 GCC target triplet: i686-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the -s gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #1 from bechir dot zalila at gmail dot com 2007-11-29 12:01 --- Created an attachment (id=14665) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14665action=view) Ada package spec -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the -s gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #2 from bechir dot zalila at gmail dot com 2007-11-29 12:01 --- Created an attachment (id=14666) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14666action=view) Ada package body -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug ada/34290] New: Problem with procedure visibility at the prefixed view call
Hello, I have following compiler crash: gcc -c main_windows-constructors.adb +===GNAT BUG DETECTED==+ | 4.3.0 20071129 (experimental) (i686-pc-linux-gnu) Assert_Failure exp_disp.adb:| | Error detected at main_windows-constructors.adb:10:57| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ After redefinition of Q_Frame as just limited interface without any progenitor interfaces compiler output following error: gcc -c main_windows-constructors.adb main_windows-constructors.adb:10:57: no selector Set_Central_Widget for type Main_Window_Impl defined at main_windows-impl.ads:6 This bug is absent in the 129029 revision. -- Summary: Problem with procedure visibility at the prefixed view call Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vgodunko at rostel dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
--- Comment #1 from vgodunko at rostel dot ru 2007-11-29 12:02 --- Created an attachment (id=14667) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14667action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
-- vgodunko at rostel dot ru changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug tree-optimization/34265] Missed optimizations
--- Comment #23 from dominiq at lps dot ens dot fr 2007-11-29 12:24 --- In top of the first two patches of comment #17, I have MOVED + NEXT_PASS (pass_tree_loop_init); + NEXT_PASS (pass_complete_unrolli); + NEXT_PASS (pass_tree_loop_done); to the second suggested place. Same result as in comment #22. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug libfortran/34291] New: Uninitialized variable is used in io/list_read.c which causes segfault
In next_char() of libgfortran/io/list_read.c, dtp-u.p.line_buffer_enabled is not initialized properly and this may cause segfault while accessing dtp-u.p.line_buffer[dtp-u.p.item_count] even dtp-u.p.linebuffer is NULL. I think it can be solved with initializing in namelist_read() as follows. Tested with gcc version 4.3.0 20071129 (experimental) (GCC) on Mac OS X 10.4.11 intel. Index: libgfortran/io/list_read.c === --- libgfortran/io/list_read.c (revision 130508) +++ libgfortran/io/list_read.c (working copy) @@ -2646,6 +2646,7 @@ dtp-u.p.namelist_mode = 1; dtp-u.p.input_complete = 0; dtp-u.p.expanded_read = 0; + dtp-u.p.line_buffer_enabled = 0; dtp-u.p.eof_jump = eof_jump; if (setjmp (eof_jump)) -- Summary: Uninitialized variable is used in io/list_read.c which causes segfault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ek dot kato at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug c++/34267] [4.3 regression] ICE applying __decltype to name of template class
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01623.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 13:04:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
[Bug libfortran/34291] Uninitialized variable is used in io/list_read.c which causes segfault
--- Comment #1 from ek dot kato at gmail dot com 2007-11-29 13:18 --- It turns out that my explanation and assumption about uninitialization was wrong, but the real cause of the segmentation fault is that some functions call free_line(dtp) without resetting line_buffer_enabled. Here is the revised patch to avoid crash. Index: list_read.c === --- list_read.c (revision 130508) +++ list_read.c (working copy) @@ -125,6 +125,7 @@ free_mem (dtp-u.p.line_buffer); dtp-u.p.line_buffer = NULL; + dtp-u.p.line_buffer_enabled = 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug libfortran/34291] Uninitialized variable is used in io/list_read.c which causes segfault
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-29 13:27 --- Can you please provide a testcase for the testsuite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug fortran/34292] New: fortran initialization code does not compile
Hi, the following program does not compile. Omiting the data statement leads to a compile without notice. program bsp INTEGER :: I,J REAL ::X(2,2)=0. !code compiles, if the following line is commented out. DATA (( X(I,J), I=1,2), J=1,2) / 4*0. / end program bsp Output on my machine: $ f95 -v bsp.f95 Driving: f95 -v bsp.f95 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) /usr/lib/gcc/i486-linux-gnu/4.1.2/f951 bsp.f95 -quiet -dumpbase bsp.f95 -mtune=generic -auxbase bsp -version -fstack-protector -o /tmp/cch4S83a.s GNU F95 version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (i486-linux-gnu) compiled by GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4). GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113084 bsp.f95:0: internal compiler error: in gfc_assign_data_value, at fortran/data.c:274 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. -- Summary: fortran initialization code does not compile Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pspftf-bugzilla at yahoo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34292
[Bug ada/34284] Missing dynamic library support for GNAT 4.3.0 on x86-*-Darwin8
--- Comment #6 from sam at gcc dot gnu dot org 2007-11-29 13:48 --- Patch looks fine to me. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 13:48:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34284
[Bug c++/34293] New: Hang because of extreme inlining
In some of our methods, that are very long and fully inlined, we experience hangs (infinite loops), that are automatically solved when we add a real (non-inlined) call to any other function. -- Summary: Hang because of extreme inlining Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dvt at isoft dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34293
[Bug c++/34294] New: Strange transmission of symbols between dynamically opened libs
We have several libraries that we load dynamically (dlopen), and from which we use only one symbol, in which we use the same variable (char **) in the cpp files. These symbols are never shared between libraries, but on this version (4.2.1) of gcc, we experience big problems, because these homonym variables are shared between the libraries : it looks like is we get the value of the first dlopened library in all other libraries. This behaviour did not happen in gcc3, neither does it on other compilers (MSDEV, IBM XLC, ...). To solve it, we had to give a unique name to our variables : this works but is very dangerous, since we are never sure that there will not be a side effect between normally independant libraries. -- Summary: Strange transmission of symbols between dynamically opened libs Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dvt at isoft dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34294
[Bug fortran/34262] MVBITS does not work for arrays
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 14:57 --- Subject: Bug 34262 Author: burnus Date: Thu Nov 29 14:56:48 2007 New Revision: 130513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130513 Log: 2007-11-29 Tobias Burnus [EMAIL PROTECTED] PR fortran/34262 * intrinsic.c (gfc_get_intrinsic_sub_symbol): Add comment. (gfc_intrinsic_sub_interface): Copy elemental state if needed. * iresolve.c (gfc_resolve_mvbits): Mark procedure as elemental. 2007-11-29 Tobias Burnus [EMAIL PROTECTED] PR fortran/34262 * gfortran.dg/mvbits_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34262
[Bug libfortran/34291] Uninitialized variable is used in io/list_read.c which causes segfault
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 15:01 --- Jerry, libgfortran IO is your domain... -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug fortran/34262] MVBITS does not work for arrays
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-29 15:00 --- Fixed on the trunk (4.3.0). I do not intent to backport the patch to 4.2.x and 4.1.x, but I can be convinced to do so. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34262
[Bug fortran/34292] fortran initialization code does not compile
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-29 15:08 --- This is an internal compiler error on invalid code. REAL ::X(2,2)=0. DATA (( X(I,J), I=1,2), J=1,2) / 4*0. / You initialize the variable X twice, which is not allowed according to the Fortran standard (although some compiler accept it using the default options). You have to use either: REAL :: X(2,2) = 0.0 or REAL :: X(2,2) DATA (( X(I,J), I=1,2), J=1,2) / 4*0. / Either of the two versions work here with gfortran 4.1.x, 4.2.x and 4.3.0. The internal compiler error is fixed in gfortran 4.3.0, which shows the following error message: aaa.f90:5.17: DATA (( X(I,J), I=1,2), J=1,2) / 4*4. / 1 aaa.f90:3.23: REAL ::X(2,2) =0. 2 Error: 'x' at (1) already is initialized at (2) I therefore close this bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34292
[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-29 15:14 --- Created an attachment (id=14668) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14668action=view) gcc43-pr33984.patch I've tried to fix this by the attached patch. standard_conversion also uses is_bitfield_expr_with_lowered_type, but reference_binding was not. Additionally, I've noticed that the 2006 change in layout_class_type dropped all qualifiers from the bitfield's type if c_build_bitfield_integer_type needs to be used. Unfortunately this causes a regression on g++.old-deja/g++.robertl/eb5.C - to type in this case is also the lowered bitfield type, so it fails. Mark, any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
[Bug c++/34293] Hang because of extreme inlining
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-29 15:31 --- Testcase? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34293
[Bug tree-optimization/34265] Missed optimizations
--- Comment #24 from dominiq at lps dot ens dot fr 2007-11-29 15:49 --- I think I have now a partial understanding of what is happening for the induct variants that do not vectorize with the patch in comment #5: they do not contain any loop inside the k loop. If I replace rot_q_vector(1) = rot_c_vector(1) - rot_qk_vector(k,1) rot_q_vector(2) = rot_c_vector(2) - rot_qk_vector(k,2) rot_q_vector(3) = rot_c_vector(3) - rot_qk_vector(k,3) by rot_q_vector(:) = rot_c_vector(:) - rot_qk_vector(k,:) Then the loop is vectorized again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug c++/34295] New: Bad optimization in an inlined method
In an inlined method, we cast a double argument into an INT64 : with gcc4.2.1 (not with other versions or compilers), this gives a completely false result that leads to a crash. To avoid this, we had to create an INT64 on the stach and to memcpy the double into it, which is much less optimized... Of course, we compile with full (O3) optimization. With O0, this works. -- Summary: Bad optimization in an inlined method Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dvt at isoft dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34295
[Bug fortran/34296] New: Intent(out) and character functions with RESULT: Value-not-set warning
The following code does not give a warning: CHARACTER(2) FUNCTION ctbgt() RESULT(ctab) END function ctbgt Only if one removes either the RESULT or changes CHARACTER in, e.g., INTEGER a warning is shown. w/ RESULT and INTEGER: warning: Function return value not set w/o RESULT: warning: Function does not return a value * * * Similarly for INTENT(OUT) arguments of procedures: SUBROUTINE ctbgt(ctab) INTEGER, intent(out) :: ctab END SUBROUTINE ctbgt -- Summary: Intent(out) and character functions with RESULT: Value- not-set warning Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34296
[Bug fortran/34296] Intent(out) and character functions with RESULT: Value-not-set warning
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-29 16:05 --- I wanted to add that a possible reason for the character FUNCTION problem is that the value is returned as argument and not as function return value: test (__result, .__result) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34296
[Bug target/32130] [4.3 Regression] linking problems: multiple definition of `__DTOR_END__'
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-29 16:21 --- Subject: Bug 32130 Author: jakub Date: Thu Nov 29 16:21:18 2007 New Revision: 130516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130516 Log: PR target/32130 * config/rs6000/eabi-cn.asm (__DTOR_END__): Make it weak. * config/rs6000/sol-cn.asm (__DTOR_END__): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/eabi-cn.asm trunk/gcc/config/rs6000/sol-cn.asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
[Bug c++/34293] Hang because of extreme inlining
--- Comment #2 from dvt at isoft dot fr 2007-11-29 16:26 --- (In reply to comment #1) Testcase? No : As I said, this is a very big method. It is in a template and includes other inlined template and non-template methods : it contains only inlined functions. Thus, it is very difficult for us to extract the problem from our application code. For information, it works well with gcc3 and other compilers like MSDEV. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34293
[Bug target/32130] [4.3 Regression] linking problems: multiple definition of `__DTOR_END__'
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-29 16:28 --- Tested today on x86_64-linux - powerpc-eabisim combined tree cross. While without the patch, e.g. neither libgfortran nor libstdc++-v3 configures successfully, with this patch it builds just fine. E.g. for make check-g++, none of the failures: === g++ tests === Running target powerpc-sim FAIL: g++.dg/conversion/simd1.C (test for excess errors) XPASS: g++.dg/cpp0x/decltype4.C GCC gets the actual type of this expression wrong (test for bogus messages, line 73) FAIL: g++.dg/ext/altivec-3.C execution test FAIL: g++.dg/ext/attribute-test-1.C (test for excess errors) FAIL: g++.dg/ext/attribute-test-2.C (test for excess errors) FAIL: g++.dg/ext/attribute-test-3.C (test for excess errors) FAIL: g++.dg/ext/attribute-test-4.C (test for excess errors) FAIL: g++.dg/ext/spe1.C (test for excess errors) FAIL: g++.dg/other/opaque-2.C (test for excess errors) FAIL: g++.dg/other/opaque-3.C (test for excess errors) FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not ivopts offset: (4294967292|0x0f+fc) XPASS: g++.old-deja/g++.mike/empty.C suggest (test for bogus messages, line 19) XPASS: g++.old-deja/g++.mike/empty.C suggest (test for bogus messages, line 20) XPASS: g++.old-deja/g++.other/init19.C execution test FAIL: g++.old-deja/g++.pt/static11.C execution test FAIL: g++.old-deja/g++.robertl/eb5.C (test for excess errors) === g++ Summary === # of expected passes16840 # of unexpected failures12 # of unexpected successes 4 # of expected failures 82 # of unsupported tests 144 seem to be related to this. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
gcc-4.2 bug, optimizer optimized strings away
Hi, if you publish this email, please remove my email address from the posting. Problem description: gcc versions = 4.0 seem to optimize away strings. Older versions seem to work. For a more detailed description see below. exact gcc versions containing the bug: --- $ gcc-4.0 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.4 20060904 (prerelease) (Debian 4.0.3-7) $ gcc-4.1 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20071019 (prerelease) (Debian 4.1.2-17) $ gcc-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) --- the system type: Linux phyrex 2.6.22-3-k7 #1 SMP Mon Nov 12 09:12:50 UTC 2007 i686 GNU/Linux the options given when GCC was configured/built: see above the complete command line that triggers the bug: see Makefile the compiler output (error messages, warnings, etc.): no compiler output with -Wall and -pedantic, no errors, no warnings additional problem description: http://pastebin.com/m1aab58d7 detailed problem description: The attached code uses inline assembler to directly use x86-32 linux-2.6 system calls. Without optimization, the generated assembly code is correct and the generated binary works. With optimization (thus with the -O1 flag), the generated optimized assembler code does not contain the string at all. Obviously, the generated binary code does not work as expected. The attachment also includes the generated assembly code. As you can see in print_hi_there_no_opt.s, the code contains the string hi there!\n in the .rodata section. The label .LC0 points to the arrording position. It is used in the .text segment code lateron. --- .file print_hi_there.c .section.rodata .LC0: .string hi there !\n ... movl.LC0, %eax movl%eax, -16(%ebp) movl.LC0+4, %eax movl%eax, -12(%ebp) movl.LC0+8, %eax movl%eax, -8(%ebp) --- The optimized assembly file (print_hi_there_opt.s) does not contain the string at all and neither has a .rodata section. sincerly, markus kammerstetter bad_gcc_optimizer.tar.bz2 Description: application/bzip
[Bug c++/34293] Hang because of extreme inlining
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 16:52 --- We cannot do anything about such a report then. Sorry. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34293
[Bug c/21920] aliasing violations
--- Comment #123 from rguenth at gcc dot gnu dot org 2007-11-29 16:54 --- *** Bug 34295 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dvt at isoft dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/34295] Bad optimization in an inlined method
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-29 16:54 --- You are violating C aliasing rules. Use memcpy (as you did) or a union to guard the type punning. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34295
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #7 from andreasmeier80 at gmx dot de 2007-11-29 17:05 --- It fails in 128121, works in 128079 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug c++/34295] Bad optimization in an inlined method
--- Comment #2 from dvt at isoft dot fr 2007-11-29 17:09 --- (In reply to comment #1) You are violating C aliasing rules. Use memcpy (as you did) or a union to guard the type punning. *** This bug has been marked as a duplicate of 21920 *** Are-you sure? Were is the rule that forbids to do this? And even if this is the case, this is for us a crucial matter of optimization: other compilers allow that, and optimize this cast. If gcc cannot do that (which also means that you (double*)(void*)(d) should not work too), it should at least provide a way to do such an operation more efficiently that doing a memcpy! An how do-you explain that without optimization it works, then? For us, it is a big problem, and this means that we cannot really rely on gcc! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34295
[Bug c++/34295] Bad optimization in an inlined method
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-29 17:21 ---
The recommended (and optimized) way to do this is:
union {
INT64 i;
double d;
} x;
x.d = arg;
return x.i;
you can also make your way work optimized by specifying -fno-strict-aliasing.
That it works without optimization is because with that or with -O1
-fno-strict-aliasing is default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34295
[Bug c++/34295] Bad optimization in an inlined method
--- Comment #4 from steven at gcc dot gnu dot org 2007-11-29 17:23 --- Try compiling with -fno-strict-aliasing. This is only automatically enabled at -O2 or higher. See the fine manual. I'm not sure what you mean with more efficient than memcpy. If you mean more efficient as in producing better code: Have you actually checked what comes out of the compiler if you do this? If you mean more elegant from a coding style point of view: The language provides the means, it is called union. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34295
[Bug fortran/34248] ICE on assumed length character function
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-29 17:41 --- Subject: Bug 34248 Author: burnus Date: Thu Nov 29 17:41:37 2007 New Revision: 130517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130517 Log: 2007-11-29 Tobias Burnus [EMAIL PROTECTED] PR fortran/34248 * trans-decl.c (generate_dependency_declarations): Check for NULL pointers before accessing the string length. 2007-11-29 Tobias Burnus [EMAIL PROTECTED] PR fortran/34248 * gfortran.dg/result_in_spec_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/result_in_spec_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34248
[Bug fortran/34248] ICE on assumed length character function
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-29 17:43 --- FIXED on the trunk (4.3.0). I do not intent to backport the fix to 4.2.x or 4.1.x, but I can be convinced to do so. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC build triplet|20071126 (experimental) | |[trunk revision 130423] | GCC host triplet|i686 linux | GCC target triplet|GNU Fortran (GCC) 4.3.0 | Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34248
[Bug c++/34294] Strange transmission of symbols between dynamically opened libs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 18:08 --- Testcase? It might be because you are using global bindings for the shared libraries. Note this really cannot be a GCC bug as GCC does not do dynamic loading. MSDEV, IBM XLC, have you tried GCC on Windows or AIX before? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34294
[Bug c++/34294] Strange transmission of symbols between dynamically opened libs
--- Comment #2 from dvt at isoft dot fr 2007-11-29 18:16 --- (In reply to comment #1) Testcase? It might be because you are using global bindings for the shared libraries. Note this really cannot be a GCC bug as GCC does not do dynamic loading. MSDEV, IBM XLC, have you tried GCC on Windows or AIX before? In fact, our application is compiled on a lot of systems with gcc (4 for all others) : linux (fedora5), solaris (sparc and sparcv9), HP-UX (PA-RISSC 32 and 32 bits) and we never had this problem before. So, on this linux system (centos4), it works when compiled with gcc 3.4, but not with gcc 4.2.1, that is why we are sure it must come from gcc 4.2.1! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34294
[Bug preprocessor/34288] ssize_t used in libcpp/files.c without autoconf detection
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-29 18:20 --- The check in gcc/configure.ac defaults ssize_t to int if it isn't found. But, we also need to do this in libcpp/configure.ac. If I send you a patch, can you test it? I will send a patch for configure as well. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 18:20:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
[Bug tree-optimization/33434] [4.3 Regression] inlining miscompilation
--- Comment #19 from jakub at gcc dot gnu dot org 2007-11-29 18:39 --- Have a modified patch which cures this, testing... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-29 19:01 --- I can reproduce the failure with revision 130507 on a p970 system. I compile 176.gcc with -m32 -O3 -maltivec and execute that benchmark program with test input. My list of vectorized loops is the same except that reload1.c:2433 is reported twice: elm3b145% fgrep 'LOOP VECTORIZED' reload.c.104t.vect reload.c:3231: note: LOOP VECTORIZED.(get_loop_exit_condition reload.c:3257: note: LOOP VECTORIZED.(get_loop_exit_condition reload.c:2352: note: LOOP VECTORIZED. elm3b145% fgrep 'LOOP VECTORIZED' reload1.c.104t.vect reload1.c:2433: note: LOOP VECTORIZED. reload1.c:3968: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:3749: note: LOOP VECTORIZED. reload1.c:784: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:697: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:3623: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:3617: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:2447: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:2433: note: LOOP VECTORIZED.(get_loop_exit_condition reload1.c:474: note: LOOP VECTORIZED. It shouldn't make any difference, of course, but I normally build GCC using --with-cpu=default32 and I think you don't do that; I'll try without it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34038
[Bug middle-end/34285] buffer overflow incorrectly detected
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-29 19:27 --- I still say GCC is incorrect here, even if I was drinking last night. This should work as the whole struct is touched and not even looked at the one field. Even if the documentation says that, it is still bad behavior. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|[4.3 Regression] buffer |buffer overflow incorrectly |overflow incorrectly|detected |detected| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34285
[Bug c++/34268] [4.3 regression] ICE applying __decltype to destructor
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 21:04 --- Subject: Bug 34268 Author: jakub Date: Thu Nov 29 21:04:04 2007 New Revision: 130519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130519 Log: PR c++/34267 PR c++/34268 * parser.c (cp_parser_decltype): Don't call finish_id_expression on ~type. * semantics.c (finish_decltype_type): Issue error on types, TYPE_DECLs and ~type early. * g++.dg/cpp0x/decltype7.C: New test. * g++.dg/cpp0x/decltype8.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype7.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
[Bug c++/34267] [4.3 regression] ICE applying __decltype to name of template class
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-29 21:04 --- Subject: Bug 34267 Author: jakub Date: Thu Nov 29 21:04:04 2007 New Revision: 130519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130519 Log: PR c++/34267 PR c++/34268 * parser.c (cp_parser_decltype): Don't call finish_id_expression on ~type. * semantics.c (finish_decltype_type): Issue error on types, TYPE_DECLs and ~type early. * g++.dg/cpp0x/decltype7.C: New test. * g++.dg/cpp0x/decltype8.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype7.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
[Bug c++/34270] [4.2/4.3 regression] ICE applying __decltype to ternary expression
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:06 --- Subject: Bug 34270 Author: jakub Date: Thu Nov 29 21:06:18 2007 New Revision: 130520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130520 Log: PR c++/34270 * tree.c (lvalue_p_1) case COND_EXPR: Handle x ?: y in templates. * typeck.c (is_bitfield_expr_with_lowered_type) case COND_EXPR: Likewise. * g++.dg/template/cond7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/cond7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
[Bug c++/34270] [4.2 regression] ICE applying __decltype to ternary expression
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-29 21:07 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE |applying __decltype to |applying __decltype to |ternary expression |ternary expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
[Bug c++/34267] [4.3 regression] ICE applying __decltype to name of template class
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
[Bug c++/34268] [4.3 regression] ICE applying __decltype to destructor
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-29 21:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
[Bug tree-optimization/33434] [4.3 Regression] inlining miscompilation
--- Comment #20 from jakub at gcc dot gnu dot org 2007-11-29 21:57 --- Subject: Bug 33434 Author: jakub Date: Thu Nov 29 21:57:38 2007 New Revision: 130521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130521 Log: PR tree-optimization/33434 * tree-inline.c (setup_one_parameter): If the value passed to a parameter is never used, don't set it up. * gcc.dg/pr33434-1.c: New test. * gcc.dg/pr33434-2.c: New test. * gcc.dg/pr33434-3.c: New test. * gcc.dg/pr33434-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33434-1.c trunk/gcc/testsuite/gcc.dg/pr33434-2.c trunk/gcc/testsuite/gcc.dg/pr33434-3.c trunk/gcc/testsuite/gcc.dg/pr33434-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug tree-optimization/33434] [4.3 Regression] inlining miscompilation
--- Comment #21 from jakub at gcc dot gnu dot org 2007-11-29 21:58 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-29 23:26 --- Confirmed on SVN trunk +===GNAT BUG DETECTED==+ | 4.3.0 20071129 (experimental) (i686-pc-linux-gnu) Assert_Failure exp_disp.adb:| | Error detected at main_windows-constructors.adb:10:57| -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-29 23:26:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug c++/34297] static linking with pthreads stl runtime error
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 23:59 --- This is really a bug in glibc and not GCC. Static linking never worked correctly with pthreads anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34297
[Bug libfortran/34291] Uninitialized variable is used in io/list_read.c which causes segfault
--- Comment #4 from ek dot kato at gmail dot com 2007-11-30 01:11 --- I can't provide a simple test case sorry, but I now realized that it seems to be related that READ() for a namelist file ended with END instead of / causes the problem. I use a library which creates namelist file by itself, and it puts END. If I replace the END with /, libgfortran doesn't seem to crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
