[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #5 from jon_y at users dot sourceforge dot net 2010-01-24 07:59 --- Ping, We need to get this fixed ASAP. Probably involving the libtool devs as well. I propose the following naming scheme. libw64stdc++-6.dll (64bit mingw-w64) libw32stdc++-6.dll (32bit mingw-w64) libstdc++-6.dll (mingw.org) libtool can check -dumpmachine for the vendor key. Comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-24 08:13 --- Subject: Bug 39304 Author: burnus Date: Sun Jan 24 08:10:47 2010 New Revision: 156195 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156195 Log: 2010-01-24 Tobias Burnus bur...@net-b.de PR fortran/39304 * array.c (gfc_array_dimen_size): Use correct specific function in the check. 2010-01-24 Tobias Burnus bur...@net-b.de PR fortran/39304 * gfortran.dg/generic_20.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug tree-optimization/42846] GCC sometimes ignores information about pointer target alignment
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 --- *** This bug has been marked as a duplicate of 41464 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42846
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 --- *** Bug 42846 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bredelin at ucla dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-24 12:08 --- In the testcase from PR42846 one issue is that base_address: p__3(D) offset from base address: 0 constant offset from base address: 0 step: 4 aligned to: 128 base_object: *(const aligned_real * restrict) p__3(D) only in the base object we see the cast to the aligned pointer, but it is stripped for the base address in the innermost loop. So in the end all this boils down to the Frontend / middle-end issue of weak handling of aligned types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #5 from aanisimov at inbox dot ru 2010-01-24 12:11 --- (In reply to comment #4) This looks like a bug in gold rather then in GCC. Try the latest development version of gold http://sourceware.org/binutils/. If it still fails, please file a bug report with more details at http://sourceware.org/bugzilla/enter_bug.cgi?product=binutils. GCC builds successfully with gold from binutils 2.20.51. However, the first bug described here still remains -- in my opinion, it's necessary that the build scripts specify all library directories explicitely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug bootstrap/41348] Bootstrap fails with --with-arch=i686
--- Comment #3 from aanisimov at inbox dot ru 2010-01-24 12:12 --- No longer fails. -- aanisimov at inbox dot ru changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41348
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
--- Comment #12 from burnus at gcc dot gnu dot org 2010-01-24 12:54 --- (In reply to comment #10) I think there are actually two issues - one is the SPAN/array descriptor issue, which causes an ICE if one calls the specific function directly, cf. PR 42851 for the ICE I get there. I have fixed the generic interface issue which gave the ICE. The subpointer issue is still unsolved - and probably needs the fix of PR 38471 (i.e. a new array descriptor). -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42851 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug c++/42853] omp private vector
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 13:16 --- Works for me with GCC 4.3.4 and 4.4.2. GCC 4.2 is no longer maintained. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42853
[Bug java/42524] gcc-4.4.2 build fails on gcj with unrecognized option '-Wl,-rpath'
--- Comment #2 from bjg at gnu dot org 2010-01-24 13:47 --- same error occurs with gcc-4.4.3 -- bjg at gnu dot org changed: What|Removed |Added CC||bjg at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42524
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #7 from hubicka at ucw dot cz 2010-01-24 13:55 --- Subject: Re: [4.5 Regression] another GCC 4.5 ICE on C++ templated code I think it was an accident as this is a P1 bug anyways. That was accident (i meant to update different PR). I tought I fixed that already. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug testsuite/42854] New: [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
Since revision 155920 (see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01286.html or http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02004.html ) there are the following failures on *-apple-darwin*: FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler-not weak_[a-z \\t]*_b FAIL: gcc.dg/darwin-weakimport-3.c scan-assembler-not coalesced [karma] f90/bug% gcc45 -S /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/darwin-weakimport-1.c [karma] f90/bug% grep weak darwin-weakimport-1.s .weak_definition _b .weak_reference _a [karma] f90/bug% gcc45 -S /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/darwin-weakimport-3.c [karma] f90/bug% grep coalesced darwin-weakimport-3.s .section __TEXT,__textcoal_nt,coalesced,pure_instructions The tests pass at revision: 155908 (see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01246.html ). Likely due to revision 155919: Author: jakub Date: Thu Jan 14 22:41:02 2010 UTC (9 days, 15 hours ago) Changed paths: 4 Log Message: PR c++/42608 * varasm.c (declare_weak): Add weak attribute to decl if it doesn't have one already. (assemble_external): Only add decls to weak_decls if they also have weak attribute. * g++.dg/template/instantiate11.C: New test. This is also seen on 4.4.3 (see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02202.html or http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02196.html ), this seems a regression since gcc4.4.2 gives: [karma] f90/bug% gcc-4 -S /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/darwin-weakimport-1.c [karma] f90/bug% grep weak darwin-weakimport-1.s .weak_reference _a .weak_reference _a [karma] f90/bug% gcc-4 -S /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/darwin-weakimport-3.c [karma] f90/bug% grep coalesced darwin-weakimport-3.s -- Summary: [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport- [13].c scan-assembler-not * Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
--- Comment #2 from danglin at gcc dot gnu dot org 2010-01-24 14:59 --- The failure also occurs on hppa2.0w-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug target/42850] [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-24 15:00 --- Subject: Re: [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test Probably related to PR42837. The failure started before the failure of g++.dg/abi/packed1.C. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42850
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #1 from mikpe at it dot uu dot se 2010-01-24 16:04 --- I'm now seeing failures in StackTrace2 and Throw_3 on arm-linux-gnueabi with gcc-4.3 branch which I didn't use to see. gcc-4.4 branch doesn't fail for me on these two, but both 4.4 and 4.3 fail (as always) on Throw_2. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug testsuite/42855] New: FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
On powerpc*-*-* gcc.dg/tree-ssa/pr42585.c fails with: FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr _ans 0 FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr _T2 0 (see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02116.html or http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02115.html ): [karma] f90/bug% gcc45 -c -O1 -fdump-tree-optimized /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c [karma] f90/bug% grep struct pr42585.c.139t.optimized Cyc_string_ungetc (int ignore, struct _fat_ptr * sptr) struct _fat_ptr _ans; struct _fat_ptr _T2; This has probably started with Author: jamborm Date: Thu Jan 21 16:18:06 2010 New Revision: 156156 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156156 Log: 2010-01-21 Martin Jambor mjam...@suse.cz PR tree-optimization/42585 * tree-sra.c (struct access): New field grp_total_scalarization. (dump_access): Dump the new field. (should_scalarize_away_bitmap): New variable. (cannot_scalarize_away_bitmap): Likewise. (sra_initialize): Allocate new bitmaps. (sra_deinitialize): Free new bitmaps. (create_access_1): New function. (create_access): Parts moved to create_access_1. (type_consists_of_records_p): New function. (completely_scalarize_record): Likewise. (build_access_from_expr): Set bit in cannot_scalarize_away_bitmap. (build_accesses_from_assign): Set bits in should_scalarize_away_bitmap. (sort_and_splice_var_accesses): Hint groups with a total_scalarization access. (analyze_all_variable_accesses): Completely scalarize small eligible records. * testsuite/gcc.dg/tree-ssa/pr42585.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- Summary: FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized * Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 16:58 --- It's a new test. Probably MOVE_RATIO is not defined for your target and thus the default of 2 applies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug fortran/41167] ICE with PACK() and string concatenation
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-24 17:00 --- Subject: Bug 41167 Author: pault Date: Sun Jan 24 16:59:51 2010 New Revision: 156197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197 Log: 2010-01-24 Paul Thomas pa...@gcc.gnu.org PR fortran/41044 PR fortran/41167 * expr.c (remove_subobject_ref): If the constructor is NULL use the expression as the source. (simplify_const_ref): Change the type of expression if there are component references. Allow for substring to be at the end of an arbitrarily long chain of references. If an element is found that is not in an EXPR_ARRAY, assume that this is scalar initialization of array. Call remove_subobject_ref in this case with NULL second argument. 2010-01-24 Paul Thomas pa...@gcc.gnu.org PR fortran/41044 * gfortran.dg/parameter_array_ref_2.f90 : New test. PR fortran/41167 * gfortran.dg/char_array_arg_1.f90 : New test. * gfortran.dg/pr25923.f90 : Remove XFAIL. Added: trunk/gcc/testsuite/gfortran.dg/char_array_arg_1.f90 trunk/gcc/testsuite/gfortran.dg/parameter_array_ref_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr25923.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41167
[Bug fortran/41044] internal compiler error: in gfc_conv_intrinsic_function
--- Comment #11 from pault at gcc dot gnu dot org 2010-01-24 17:00 --- Subject: Bug 41044 Author: pault Date: Sun Jan 24 16:59:51 2010 New Revision: 156197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197 Log: 2010-01-24 Paul Thomas pa...@gcc.gnu.org PR fortran/41044 PR fortran/41167 * expr.c (remove_subobject_ref): If the constructor is NULL use the expression as the source. (simplify_const_ref): Change the type of expression if there are component references. Allow for substring to be at the end of an arbitrarily long chain of references. If an element is found that is not in an EXPR_ARRAY, assume that this is scalar initialization of array. Call remove_subobject_ref in this case with NULL second argument. 2010-01-24 Paul Thomas pa...@gcc.gnu.org PR fortran/41044 * gfortran.dg/parameter_array_ref_2.f90 : New test. PR fortran/41167 * gfortran.dg/char_array_arg_1.f90 : New test. * gfortran.dg/pr25923.f90 : Remove XFAIL. Added: trunk/gcc/testsuite/gfortran.dg/char_array_arg_1.f90 trunk/gcc/testsuite/gfortran.dg/parameter_array_ref_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr25923.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41044
[Bug testsuite/42856] New: FAIL: gcc.dg/torture/pr41555.c -O0 (test for excess errors)
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c -O0 -std=c99 -lm -o ./p r41555.exe(timeout = 300) /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c:4:20: error: stdint.h: N o such file or directory /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'safe_div_func_uint64_t_u_u' ... -- Summary: FAIL: gcc.dg/torture/pr41555.c -O0 (test for excess errors) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42 --- Richard, I'm sorry, I realize now that I'm confused about an important point: does your analysis of function::swap mean that we are *already* miscompiling it? Or, are we going to commit patches which will lead to miscompilations in 4.5? Because otherwise, I don't really think it makes sense to have an interim version of the code using std::memcpy (at least not for the C+0x version): for 4.6.0 we could as well move directly to the optimized but correct solution - in other terms we didn't really understand each other the last week, and this issue should not depend on 42834, on your 42845 instead and should be targeted to 4.6.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42857] New: std::istream::ignore(std::streamsize n) calls unnecessary underflow
When ignoring the number of bytes available in a streambuf using
std::istream::ignore, ignore calls underflow. This should not happen. I feel
the easiest way to reproduce it is to look at strace output when ignoring bytes
from ifstream:
#include iostream
#include fstream
int main(int argc, char* argv[])
{
std::ifstream in(argv[0]);
in.get(); // trigger filling of input buffer by calling underflow
in.ignore(in.rdbuf()-in_avail()); // this triggers another underflow
}
The strace output shows, that 2 calls to read with 8191 bytes occures. When
ignoring one byte less and then another byte, only one read is done:
#include iostream
#include fstream
int main(int argc, char* argv[])
{
std::ifstream in(argv[0]);
in.get(); // trigger filling of input buffer
in.ignore(in.rdbuf()-in_avail() - 1);
in.ignore(1); // this does not trigger underflow
}
--
Summary: std::istream::ignore(std::streamsize n) calls
unnecessary underflow
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tommi at tntnet dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #3 from rguenther at suse dot de 2010-01-24 20:50 --- Subject: Re: Revisit std::function for aliasing issues On Sun, 24 Jan 2010, paolo dot carlini at oracle dot com wrote: --- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42 --- Richard, I'm sorry, I realize now that I'm confused about an important point: does your analysis of function::swap mean that we are *already* miscompiling it? I did not yet observe miscompilations - it for now is a latent issue only. Or, are we going to commit patches which will lead to miscompilations in 4.5? No, I planned to - but after the analysis I decided to postpone them. The issue is the patches only improve RTL analysis - I see nothing that blocks the issue to show up on the tree level, but we seem to be lucky there. On RTL we do instruction scheduling which does include unusual movement of instructions, like sinking loads or hoisting stores - that might be the reason we are lucky on the tree level. Because otherwise, I don't really think it makes sense to have an interim version of the code using std::memcpy (at least not for the C+0x version): for 4.6.0 we could as well move directly to the optimized but correct solution - in other terms we didn't really understand each other the last week, and this issue should not depend on 42834, on your 42845 instead and should be targeted to 4.6.0. Well - that's up to you. libstdc++ violates aliasing rules, and I expect that sooner or later there will be a testcase that is miscompiled with the existing 4.5 codebase. A fix using memcpy certainly depends on fixing 42834, thus the dependency. It blocks PR42617 whose fixes expose this bug, that bug isn't marked as regression though it is (heh - nobody besides me noticed that). Thus, it is up to you - if you want to fix this for 4.5 then I have to fix PR42834 (because you do not consider a fix not using memcpy). PR42834 isn't a regression either - 4.4 was much less compliant wrt C++ dynamic types. Hope this helps and doesn't add more confusion ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug testsuite/42856] [4.4 Regression] FAIL: gcc.dg/torture/pr41555.c -O0 (test for excess errors)
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 21:20 ---
Needs /* { dg-require-effective-target stdint_types } */
HJ, you backported this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hjl at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.4.3
Known to work||4.4.1
Last reconfirmed|-00-00 00:00:00 |2010-01-24 21:20:48
date||
Summary|FAIL: |[4.4 Regression] FAIL:
|gcc.dg/torture/pr41555.c - |gcc.dg/torture/pr41555.c -
|O0 (test for excess errors)|O0 (test for excess errors)
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 21:22 --- Blocks improvement/regression fix for PR42617 (has patches attached to reproduce this bug). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||42617 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c++/42820] [4.5 Regression] ICE in tree-check, accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9868
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-21 10:51:19 |2010-01-24 22:20:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42820
[Bug fortran/42858] New: [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
Between svn rev. 156083 and 156198 the following ICE started to occur with the attached testcase: f951: internal compiler error: Segmentation fault Running gdb on the testcase: (gdb) run gfcbug102.f90 Starting program: /opt/gfortran/4.5/libexec/gcc/i686-pc-linux-gnu/4.5.0/f951 gfcbug102.f90 Program received signal SIGSEGV, Segmentation fault. 0x080d61f8 in gfc_array_dimen_size (array=0x8bf2380, dimen=0, result=0xbfffe868) at ../../trunk/gcc/fortran/array.c:2063 2063 else if (spec_dimen_size (array-symtree-n.sym-as, dimen, result) -- Summary: [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #1 from anlauf at gmx dot de 2010-01-24 22:36 --- Created an attachment (id=19697) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19697action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-24 23:15 --- Confirmed. I think this is due to revision 156195. I also see the same ICE for the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418#c1 (with the comments removed). For both cases the backtrace is: (gdb) run pr42858.f90 Starting program: /opt/gcc/gcc4.5c/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951 pr42858.f90 Reading symbols for shared libraries .. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0098 0x000183d4 in gfc_array_dimen_size (array=0x141817620, dimen=0, result=0x7fff5fbfe620) at ../../_clean/gcc/fortran/array.c:2059 2059 if (spec_dimen_size (array-value.function.esym-as, dimen, result) (gdb) bt #0 0x000183d4 in gfc_array_dimen_size (array=0x141817620, dimen=0, result=0x7fff5fbfe620) at ../../_clean/gcc/fortran/array.c:2059 #1 0x00010002a71c in gfc_check_conformance (op1=0x141815fd0, op2=value temporarily unavailable, due to optimizations, optype_msgid=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/expr.c:2879 #2 0x00010002a8fb in gfc_check_assign (lvalue=0x141815fd0, rvalue=0x141817620, conform=1) at ../../_clean/gcc/fortran/expr.c:3032 #3 0x000100080e1a in resolve_code (code=value temporarily unavailable, due to optimizations, ns=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/resolve.c:7926 #4 0x0001000813bc in gfc_resolve_blocks (b=0x141815f20, ns=0x142079000) at ../../_clean/gcc/fortran/resolve.c:7764 #5 0x00010007f682 in resolve_code (code=0x141816bb0, ns=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/resolve.c:7985 #6 0x000100081546 in resolve_codes (ns=0x142079000) at ../../_clean/gcc/fortran/resolve.c:12337 #7 0x000100081458 in resolve_codes (ns=0x142077200) at ../../_clean/gcc/fortran/resolve.c:12323 #8 0x00010007445e in gfc_resolve (ns=0x142077200) at ../../_clean/gcc/fortran/resolve.c:12364 #9 0x000100068c13 in gfc_parse_file () at ../../_clean/gcc/fortran/parse.c:4201 #10 0x0001000a1c1c in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/f95-lang.c:239 #11 0x0001006d0cda in toplev_main (argc=2, argv=0x7fff5fbfed18) at ../../_clean/gcc/toplev.c:1053 #12 0x000112a4 in start () -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||burnus at net-b dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-24 23:31 --- I think the patch in comment #11 caused pr42858. Also the tests in comment #1 and #4 give a segmentation fault: (gdb) run pr39304_1.f90 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /opt/gcc/gcc4.5c/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951 pr39304_1.f90 matmul_k21 sd_one sd_matrix_one Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0018 0x0001000c8b8a in gfc_trans_pointer_assignment (expr1=0x14181cf70, expr2=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/trans-expr.c:4675 4675 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp); (gdb) bt #0 0x0001000c8b8a in gfc_trans_pointer_assignment (expr1=0x14181cf70, expr2=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/trans-expr.c:4675 #1 0x0001000a6ad6 in gfc_trans_code (code=0x14181db10) at ../../_clean/gcc/fortran/trans.c:1097 #2 0x0001000c2be7 in gfc_generate_function_code (ns=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/trans-decl.c:4373 #3 0x0001000a6e2b in gfc_generate_module_code (ns=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/trans.c:1363 #4 0x0001000694bf in gfc_parse_file () at ../../_clean/gcc/fortran/parse.c:4212 #5 0x0001000a1c1c in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../_clean/gcc/fortran/f95-lang.c:239 #6 0x0001006d0cda in toplev_main (argc=2, argv=0x7fff5fbfed18) at ../../_clean/gcc/toplev.c:1053 #7 0x000112a4 in start () The test in comment #10 gives pr39304_3.f90:19.4: res = x(1,1)%xx 1 Error: Different ranks in pointer assignment at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug c++/42859] New: [4.5 regression] ICE in verify_flow_info
Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --enable-interpreter --disable-sjlj-exceptions --enable-load-library --enable-java-awt=gtk Thread model: posix gcc version 4.5.0 20100120 (experimental) (GCC) COLLECT_GCC_OPTIONS='-nostdinc' '-v' '-shared-libgcc' '-mtune=generic' /usr/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe -fpreprocessed pthread.ii -quiet -dumpbase pthread.ii -mtune=generic -auxbase pthread -version -o /cygdrive/d/Temp/cache/ccycFNGG.s GNU C++ (GCC) version 4.5.0 20100120 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.5.0 20100119 (experimental), GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.5.0 20100120 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.5.0 20100119 (experimental), GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 797829d91662cb6a9eac7b21dd4c8ffc In file included from private.c:48:0, from pthread.c:44: ptw32_threadStart.c: In function ¡®unsigned int ptw32_threadStart(void*)¡¯: ptw32_threadStart.c:256:45: warning: exception of type ¡®ptw32_exception¡¯ will be caught ptw32_threadStart.c:256:7: warning:by earlier handler for ¡®ptw32_exception¡¯ ptw32_threadStart.c:263:7: warning: exception of type ¡®ptw32_exception¡¯ will be caught ptw32_threadStart.c:256:45: warning:by earlier handler for ¡®ptw32_exception¡¯ ptw32_threadStart.c:286:41: warning: exception of type ¡®ptw32_exception_cancel¡¯ will be caught ptw32_threadStart.c:286:3: warning:by earlier handler for ¡®ptw32_exception¡¯ ptw32_threadStart.c:293:41: warning: exception of type ¡®ptw32_exception_exit¡¯ will be caught ptw32_threadStart.c:293:3: warning:by earlier handler for ¡®ptw32_exception¡¯ In file included from private.c:48:0, from pthread.c:44: ptw32_threadStart.c:125:1: error: case labels not sorted: case 1: is greater than case 1: but comes before it. ptw32_threadStart.c:125:1: error: case labels not sorted: case 1: is greater than case 1: but comes before it. ptw32_threadStart.c:125:1: error: case labels not sorted: case 1: is greater than case 1: but comes before it. ptw32_threadStart.c:125:1: error: case labels not sorted: case 1: is greater than case 1: but comes before it. ptw32_threadStart.c:125:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.5 regression] ICE in verify_flow_info Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com 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=42859
[Bug c++/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #1 from jojelino at gmail dot com 2010-01-25 00:11 --- Created an attachment (id=19698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19698action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug c++/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #2 from jojelino at gmail dot com 2010-01-25 00:23 --- Created an attachment (id=19699) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19699action=view) testcase other testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-25 01:18
---
This appears to fix this: regression tested on x86-64
Index: array.c
===
--- array.c (revision 156201)
+++ array.c (working copy)
@@ -2053,10 +2053,11 @@
return SUCCESS;
}
- if (array-symtree-n.sym-attr.generic
+ if (dimen array-symtree-n.sym-attr.generic
!array-symtree-n.sym-attr.intrinsic)
{
- if (spec_dimen_size (array-value.function.esym-as, dimen, result)
+ if (array-value.function.esym
+ spec_dimen_size (array-value.function.esym-as, dimen,
result)
== FAILURE)
return FAILURE;
}
Tobias, please feel free to run with this or another fix as suitable.
--
jvdelisle 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-01-25 01:18:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug testsuite/42856] [4.4 Regression] FAIL: gcc.dg/torture/pr41555.c -O0 (test for excess errors)
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-25 03:11 --- Created an attachment (id=19700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19700action=view) A patch Please test this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
[Bug c/42860] New: ICE in gcc-4.4.3
I've just upgraded to 4.4.3 and tried a fresh build of mesa's git/master. I get an ICE as: /usr/bin/gcc -I../../include -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS clip.c -L../../lib -lglut -lGLU -lGL -lm -o clip checker.c: In function 'main': checker.c:129: internal compiler error: in expand_scalar_variables_expr, at graphite.c:4295 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gmake[2]: *** [checker] Error 1 gmake[2]: *** Waiting for unfinished jobs gmake[2]: Leaving directory `/home/ronis/Project/notar/X/mesa/progs/redbook' I recompiled with --save-temps and will upload the .i file. Removing the -floop-interchange -floop-strip-mine -floop-block flags fixes the problem Finally, I'm quite sure that I reported something similar to this in the past, and that it was supposedly fixed (I can't find it in bugzilla though). -- Summary: ICE in gcc-4.4.3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-01-25 03:14 --- Subject: Bug 42748 Author: mmitchel Date: Mon Jan 25 03:14:25 2010 New Revision: 156202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156202 Log: PR c++/42748 * config/arm/arm.c (arm_mangle_type): Do not warn about changes to mangling of va_list in system headers. PR c++/42748 * g++.dg/abi/arm_va_list2.C: New test. * g++.dg/abi/arm_va_list2.h: Companion header file. Added: trunk/gcc/testsuite/g++.dg/abi/arm_va_list2.C trunk/gcc/testsuite/g++.dg/abi/arm_va_list2.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c/42860] ICE in gcc-4.4.3
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2010-01-25 03:15 --- Created an attachment (id=19701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19701action=view) Preprocessed source file causing the ICE This is the first source file that triggers the ICE; there are others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-01-25 03:16 --- Fixed. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug middle-end/42860] ICE in gcc-4.4.3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |middle-end Version|unknown |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug debug/37022] internal compiler error: in compute_barrier_args_size
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-25 06:58 --- Jakub, what to do with this PR? It is still marked blocker although it seems to have blocked nothing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
[Bug gcov-profile/22324] profiling gcc build produces Overflow merging
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-25 07:35 --- 3.x isn't supported anymore. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22324
[Bug bootstrap/39968] Should plugins use shared library?
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug fortran/41044] internal compiler error: in gfc_conv_intrinsic_function
--- Comment #12 from pault at gcc dot gnu dot org 2010-01-25 07:53 --- I just posted the patch for this, so could take it with some advantage. Will correct 4.4 in a few days. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-16 16:15:29 |2010-01-25 07:53:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41044
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #3 from frank dot braun at rz dot uni-regensburg dot de 2010-01-25 07:57 --- Today I am not able to reproduce the error. The compiler is working. Where exactly does the file m.mod reside? In the user directory or in a compiler directory? Frank Braun (In reply to comment #2) Tobias, If we ask a bug submitter for more information, or to confirm our suspicions, we put the bug report in WAITING. Note to submitter: bug reports with status WAITING will be closed if not replied to within 3 months. Kind regards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
