[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #39 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-09-20 06:30 --- The updated patch fixes align-counterexample1.c, but not align-counterexample2.c. Note that you must align the stack for all functions that have some SSE operations, because you never know if t

[Bug middle-end/41413] New: Bootstrap fails with ICE on i686

Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function ‘__powisf2’: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug c++/41412] SEGFAULT when declaring two 724 x 724 matrices of doubles in class

--- Comment #2 from maltusan at gmail dot com 2009-09-20 04:13 --- Oh. I'm sorry. As it didn't happen when I declared the variables outside a class, I didn't think it was a memory issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41412

[Bug c++/41412] SEGFAULT when declaring two 724 x 724 matrices of doubles in class

--- Comment #1 from hjl dot tools at gmail dot com 2009-09-20 02:33 --- You are allocating 8MB on stack. You need to raise your stack limit. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

--- Comment #12 from cgd at gcc dot gnu dot org 2009-09-20 01:57 --- (In reply to comment #11) > Gack, sorry, looks like I screwed this up. > > When I retested after updating, I only compared test results > before/after, and saw what I was expecting, I didn't actually recheck > all of t

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

--- Comment #11 from cgd at google dot com 2009-09-20 01:34 --- Subject: Re: -MMD vs not found system header (included from a system header) Gack, sorry, looks like I screwed this up. When I retested after updating, I only compared test results before/after, and saw what I wa

[Bug c++/41412] New: SEGFAULT when declaring two 724 x 724 matrices of doubles in class

When two matrices of the type double, sized [724][724] or more are declared, as private variables of a class, the program crashes as soon as this class constructor is called. 724 is the magic number; 723 does not trigger the bug. The type has to be double also, no other built-in does the job. Th

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:37 --- I should also point out that --save-temps produces identical conftest.s files whether xgcc compiles from conftest.c or conftest.i. Only it errors when starting from conftest.c but not conftest.i (which was

[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

--- Comment #5 from spop at gcc dot gnu dot org 2009-09-19 23:36 --- Subject: Re: -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156 Actually I can see what is going wrong: the number of iterat

[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

--- Comment #4 from sebpop at gmail dot com 2009-09-19 23:31 --- Subject: Re: -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156 Could you run gdb and report the backtrace? # gdb build-gcc/gcc

Re: [Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

Could you run gdb and report the backtrace? # gdb build-gcc/gcc/cc1 (gdb) run -O3 -floop-strip-mine ... aes.i (gdb) bt Thanks, Sebastian

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:26 --- Created an attachment (id=18614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18614&action=view) assembly file for conftest.c created with --save-temps on x86_64-apple-darwin10 -- http://gcc.gnu

[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

--- Comment #3 from t7 at gmail dot com 2009-09-19 23:25 --- (In reply to comment #2) > What version of gcc do you use? > I cannot reproduce the error on amd64-linux with the current trunk at > rev.151881. > I used the cross compiler I compiled from gcc trunk svn revision 151878. T

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:24 --- Created an attachment (id=18613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18613&action=view) preprocessed source for conftest.c created on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzill

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:23 --- Created an attachment (id=18612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18612&action=view) conftest.c file created on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:22 --- This seems strange to me. If I create the offending conftest.c test file and execute... /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919

[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

--- Comment #2 from spop at gcc dot gnu dot org 2009-09-19 23:18 --- What version of gcc do you use? I cannot reproduce the error on amd64-linux with the current trunk at rev.151881. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:14 --- Same problem on x86_64-apple-darwin10 with current gcc trunk... onfigure:5749: checking size of long long configure:5754: /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-09-19 22:47 --- The patch... Index: gcc/config/darwin.h === --- gcc/config/darwin.h (revision 151890) +++ gcc/config/darwin.h (working copy) @@ -372,7 +372,

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2009-09-19 22:45 --- just checked; powerpc-apple-darwin9 [at 151880] this also fails. looking through the error log there do seem to be a large number of garbage strings in the informational messages; e.g. ../../../gcc-4-

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #21 from hubicka at ucw dot cz 2009-09-19 22:15 --- Subject: Re: expr.c undefined reference while linking jc1 > What's your timescale for this if you were to do it? If it's likely to take > a few days, should we maybe commit something roughly like the patch from > commen

[Bug middle-end/41411] [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616

--- Comment #3 from hubicka at ucw dot cz 2009-09-19 22:20 --- Subject: Re: [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616 This is because mem_loc_descriptor gets called on: (high:SI (symbol_ref/u:SI ("*.LLC6") [flags 0x2])) Jakub, this is yours code, but it seems to m

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-19 22:04 --- Yes, probably the apple tools barf on the new dwarf opcodes. Please report the issue to them. A GCC side fix would be to add an option to restrict dwarf to dwarf2 and turn that option on by default for darwin. --

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

--- Comment #10 from hjl dot tools at gmail dot com 2009-09-19 21:47 --- All new tests are failing. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

--- Comment #9 from hjl dot tools at gmail dot com 2009-09-19 21:47 --- On Linux/ia32, Linux/ia64 and Linux/Intel64, I got FAIL: gcc.dg/cpp/missing-header-MD.c (test for errors, line 5) FAIL: gcc.dg/cpp/missing-header-MD.c (test for excess errors) FAIL: gcc.dg/cpp/missing-header-MMD.c

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

--- Comment #10 from hjl dot tools at gmail dot com 2009-09-19 21:42 --- (In reply to comment #9) > Created an attachment (id=18608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18608&action=view) [edit] > sse & 32bit -> -mstackrealign (example only!) > > Previous my ideas too h

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #38 from hjl dot tools at gmail dot com 2009-09-19 21:40 --- (In reply to comment #32) > Created an attachment (id=18578) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578&action=view) [edit] > A bug example for 4.4 patch > > Shows a bug in 4.4 patch > Please try

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-19 21:40 --- When bootstrapping r151807 will finish (couple hours from now). I am planning to bootstrap r151815. What is the estimated likelihood that the problem is triggered by * dwarf2out.c (loc_descriptor): Emit DW_OP

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #37 from hjl dot tools at gmail dot com 2009-09-19 21:38 --- (In reply to comment #33) > Created an attachment (id=18579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579&action=view) [edit] > Another bug in 4.4 patch > > Another bug in 4.4 patch. > This one does

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #36 from hjl dot tools at gmail dot com 2009-09-19 21:38 --- Created an attachment (id=18611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18611&action=view) An updated patch for gcc trunk -- hjl dot tools at gmail dot com changed: What|Removed

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #35 from hjl dot tools at gmail dot com 2009-09-19 21:37 --- Created an attachment (id=18610) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18610&action=view) An updated patch for gcc 4.4 -- hjl dot tools at gmail dot com changed: What|Removed

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-19 21:31 --- > this means this is a darwin bug, dsymutil abort()s. Please report to apple > instead. What should I report to apple? gcc 4.5.0 is working probably at least up to revision 151807 (currently building libjava) then

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

--- Comment #14 from ubizjak at gmail dot com 2009-09-19 21:21 --- Checking is not a problem here, see Comments #9 and #10. -- ubizjak at gmail dot com changed: What|Removed |Added ---

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #20 from davek at gcc dot gnu dot org 2009-09-19 21:20 --- (In reply to comment #19) > Subject: Re: expr.c undefined reference while linking jc1 > > > :-( There must be one more latent bug in the code; after applying both the > > patches you sent today and rebuilding dwarf2

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-19 20:44 --- Assertion failed: (!"Unknown one-operand"), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 157 1. xgcc: Internal error: Abort trap (program dsymutil) this mean

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap with checking disabled

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|[4.5 regression] Revision |[4.5 regression] R

[Bug tree-optimization/41377] [4.5 Regression] Revision 151696 caused ICE in unsplit_eh

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41377

[Bug middle-end/41411] [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot |

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

--- Comment #8 from cgd at gcc dot gnu dot org 2009-09-19 19:26 --- Fixed in trunk in rev 151879. -- cgd at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/41411] ICE: mem_loc_descriptor, at dwarf2out.c:11616

--- Comment #2 from joel at gcc dot gnu dot org 2009-09-19 18:59 --- This is the command I used to generate the ICE on the attached test case. Dropping the -g got rid of the ICE. /users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-sparc/./gcc/ -B/users/joel/test-

[Bug c/41411] ICE: mem_loc_descriptor, at dwarf2out.c:11616

--- Comment #1 from joel at gcc dot gnu dot org 2009-09-19 18:58 --- Created an attachment (id=18609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18609&action=view) Preprocessed code to generate bug dropping -g from the command line fixes it. Full command in next comment. --

[Bug middle-end/41403] miscompilation of goto/label using code

--- Comment #6 from jv244 at cam dot ac dot uk 2009-09-19 18:54 --- and smaller C testcase: main() { void * i1; int icon01; int ivfail; int D1545; ivfail = 0; i1 = &&label_001263; if (i1 == &&label_001262) goto label_001262; if (i1 == &&label_001263) goto label_001263;

[Bug middle-end/41403] miscompilation of goto/label using code

--- Comment #5 from jv244 at cam dot ac dot uk 2009-09-19 18:48 --- and also fails in C #include main() { int i; int i0; void * i1; int icon01; int ivfail; int ivpass; int D1545; ivfail = 0; i0 = -1; i1 = &&label_001263; if (i1 == &&label_001262) goto label_00126

[Bug c/41411] New: ICE: mem_loc_descriptor, at dwarf2out.c:11616

Using native gcc to compile sparc of same source. The offending file belongs to newlib. Preprocessed output shortly. $ gcc --version gcc (GCC) 4.5.0 20090919 (experimental) [trunk revision 151882] /users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc

[Bug middle-end/41403] Optimization: NIST test FM013.f fails at -O1 and above

--- Comment #4 from jv244 at cam dot ac dot uk 2009-09-19 18:27 --- further reduced, looks more like a middle end issue to me: IVFAIL=0 ASSIGN 1263 TO I GO TO I, (1262,1263,1264) 1262 ICON01 = 1262 GO TO 1265 1263 ICON01 = 1263 GO TO 1265 1264 ICON01 = 1

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #19 from hubicka at ucw dot cz 2009-09-19 18:24 --- Subject: Re: expr.c undefined reference while linking jc1 > :-( There must be one more latent bug in the code; after applying both the > patches you sent today and rebuilding dwarf2out.o and cc1.exe, no difference > in >

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #18 from davek at gcc dot gnu dot org 2009-09-19 17:59 --- (In reply to comment #17) > (In reply to comment #16) > > > Patch I sent to improve tree_loc code also has code to lookup constants > > in constant pool. For strings in particular this has pretty good chance > > of

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

--- Comment #13 from hjl dot tools at gmail dot com 2009-09-19 17:50 --- *** Bug 41410 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395

[Bug middle-end/41410] Bootstrap fails with ICE on i686

--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 17:50 --- Why do you open 3 bug reports for the same problem? *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)

--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:35 --- Fixed on 4.4, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/39886] [4.5 Regression] Revision 145283 caused ICE in purge_dead_edges, at cfgrtl.c:2274

--- Comment #8 from hjl dot tools at gmail dot com 2009-09-19 17:29 --- It is caused by revision 145283: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00790.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)

--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:24 --- Subject: Bug 41328 Author: jvdelisle Date: Sat Sep 19 17:23:43 2009 New Revision: 151884 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151884 Log: 2009-09-19 Jerry DeLisle PR libgfortran/413

[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)

--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:21 --- Subject: Bug 41328 Author: jvdelisle Date: Sat Sep 19 17:21:20 2009 New Revision: 151883 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151883 Log: 2009-09-19 Jerry DeLisle Backport from main

[Bug target/41358] correct types for OpenBSD targets

--- Comment #3 from jsg at openbsd dot org 2009-09-19 17:11 --- http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01269.html inclusive of stdint bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41358

[Bug middle-end/41410] New: Bootstrap fails with ICE on i686

Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function ‘__powisf2’: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug rtl-optimization/40987] Wrong optimization with if-conversion

--- Comment #9 from mikpe at it dot uu dot se 2009-09-19 16:57 --- Seems like an if-conversion bug, in particular noce_try_store_flag_constants() appears to break on HWI32 platforms when long long literals are involved. In this test case, noce_t_s_f_c() is invoked with an IF where a (th

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-09-19 16:31 --- The solution we want to implement is described below... --- I dug into this. Based on the .s files in bugzilla, the latest gcc is now adding dwarf un

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #17 from davek at gcc dot gnu dot org 2009-09-19 16:25 --- (In reply to comment #16) > Patch I sent to improve tree_loc code also has code to lookup constants > in constant pool. For strings in particular this has pretty good chance > of success. I see you wrote: " Th

[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

--- Comment #9 from mahatma at eu dot by 2009-09-19 16:12 --- Created an attachment (id=18608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18608&action=view) sse & 32bit -> -mstackrealign (example only!) Previous my ideas too heavy. :) IMHO native solution for this problem is "-

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #16 from hubicka at ucw dot cz 2009-09-19 16:10 --- Subject: Re: expr.c undefined reference while linking jc1 > Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm > afraid we can't do anything for it, unless we can find such string in the > rodat

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

--- Comment #12 from hjl dot tools at gmail dot com 2009-09-19 15:59 --- *** Bug 41407 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395

[Bug middle-end/41407] Bootstrap fails with ICE on i686

--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 15:59 --- *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug middle-end/41409] Bootstrap fails with ICE on i686

--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 15:58 --- *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

--- Comment #11 from hjl dot tools at gmail dot com 2009-09-19 15:58 --- *** Bug 41409 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added -

[Bug middle-end/41398] can't resolve .LFE1408 {*UND* section} - .Ltext0 {.text section}

--- Comment #6 from pluto at agmk dot net 2009-09-19 15:52 --- current head of 4.4 branch is fixed by r150797. -- pluto at agmk dot net changed: What|Removed |Added

[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran

--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-09-19 15:01 --- Lets keep this bug open while you are hunting so we don't forget. Waiting -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran

--- Comment #2 from lanceb at k-state dot edu 2009-09-19 14:48 --- Subject: Re: Segmentation fault calling DGETRF from gfortran Well, that's an embarrassing mistake. My apologies. For some reason the example code does run correctly for G95. In my (much larger) program I do call DGETR

[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c

--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-19 14:32 --- (In reply to comment #7) > I recompile the whole toolchain using today's newest code, the same result, > cross compiler runs fine, native compiler runs crash. > I retested your example with current trunk as native c

[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran

--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-19 14:01 --- Have a look at http://linux.die.net/man/l/dgetrf for the calling convention. The following works for me: program det_test implicit none integer, parameter :: p15=selected_real_kind(15) integer :: ipiv(2) real

[Bug middle-end/41409] New: Bootstrap fails with ICE on i686

Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function ‘__powisf2’: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug fortran/41408] New: Segmentation fault calling DGETRF from gfortran

I get a segmentation fault while calling LAPACK function DGETRF. The same program works the way it is supposed to (ie runs without error and gives the expected output) using either g95 or Sun Studio. I am running 32-bit Ubuntu 9.04. I've confirmed the error on a Slackware 12.1 box as well, and als

[Bug middle-end/41407] New: Bootstrap fails with ICE on i686

Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function ‘__powisf2’: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #15 from davek at gcc dot gnu dot org 2009-09-19 13:13 --- (In reply to comment #14) > (In reply to comment #13) > > Thanks for taking the time to explain that. > > I think the implication of what you're saying is that we can in fact handle > strings and just giving up on t

[Bug bootstrap/41348] Bootstrap fails with --with-arch=i686

--- Comment #2 from aanisimov at inbox dot ru 2009-09-19 12:32 --- > that one is expected and doesn't fail the build. What's the output after > that? Indeed, I've messed up a bit last time. Rev. 151361 builds fine, but with rev. 151362 I get Comparing stages 2 and 3 warning: gcc/cc1-

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #14 from davek at gcc dot gnu dot org 2009-09-19 12:32 --- (In reply to comment #13) Thanks for taking the time to explain that. I think the implication of what you're saying is that we can in fact handle strings and just giving up on them is too severe, but we need to deci

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-19 12:12 --- Consider: __attribute__((noinline)) int bar (void) { const char *foo = "foo"; asm volatile ("nop" : : : "memory"); foo = "bar"; asm volatile ("nop" : : : "memory"); return 16; } int main (void) { bar ();

[Bug c/41406] internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

--- Comment #1 from t7 at gmail dot com 2009-09-19 11:55 --- Created an attachment (id=18607) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18607&action=view) Preprocessed test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406

[Bug c/41406] New: internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156

x86_64-w64-mingw32-gcc -DHAVE_AV_CONFIG_H -I. -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -std=c99 -Wall -O3 -floop-strip-mine -MMD -MF libavutil/aes.d -MT libavutil/aes.o -save-temps -c -o libavutil/aes.o libavutil/aes.c libavutil/aes.c: In function 'subshi

[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script

-- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org

[Bug fortran/31447] set intent(out) arguments to uninitialized

--- Comment #3 from jv244 at cam dot ac dot uk 2009-09-19 11:37 --- I've also run into this issue, it would be great if there would be a flag like -finit-undefined-intentout (?), so that intent(out) variable would first be undefined by the compiler (in a way that valgrind notices this wi

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #12 from davek at gcc dot gnu dot org 2009-09-19 11:34 --- (In reply to comment #10) > we can't do anything for it, unless we can find such string in the > rodata section of the compilation unit. > .LASF74 is a label in .debug_str section, which isn't > allocated, so I wond

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #11 from davek at gcc dot gnu dot org 2009-09-19 11:17 --- (In reply to comment #10) > Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm > afraid we can't do anything for it, unless we can find such string in the > rodata section of the compilatio

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-19 11:04 --- Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm afraid we can't do anything for it, unless we can find such string in the rodata section of the compilation unit. .byte 0x3

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #9 from davek at gcc dot gnu dot org 2009-09-19 10:56 --- (In reply to comment #8) > The "ret" string is shared between some attribute and a value from > CONST_STRING. Sorry, as I just figured out I was off by one on that: (gdb) fin Run till exit from #0 gen_label_for_in

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-19 10:50 --- The "ret" string is shared between some attribute and a value from CONST_STRING. But prune_unused_types_walk_attribs resets the count to 0: /* Set the string's refcount to 0 so that prune_unused_types_mark

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #7 from davek at gcc dot gnu dot org 2009-09-19 10:44 --- Was off-by-one on the rtx, it's actually "ret" not "goto". The refcount of the indirect_string_node goes to zero here, in prune_unused_types_walk_attribs(): (gdb) c Continuing. Hardware watchpoint 5: ((struct indirec

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #6 from davek at gcc dot gnu dot org 2009-09-19 09:56 --- heh, it's my old friend add_location_or_const_value_attribute() from pr41357 (gdb) up #5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58, decl=0x7f004bc0, attr=DW_AT_location) at /gnu/gcc/

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #5 from davek at gcc dot gnu dot org 2009-09-19 09:49 --- Created an attachment (id=18606) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18606&action=view) unreduced preprocessed source. compile this with: /gnu/gcc/obj.no.pr41357/./stage1-gcc/cc1.exe -fpreprocessed ex

[Bug bootstrap/41405] New: [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

Bootstrap fails at revision 151873 on *-apple-darwin9 with ... checking for long long... yes checking size of long long... configure: error: in `/opt/gcc/darwin_buildw/gcc': configure: error: cannot compute sizeof (long long) See `config.log' for more details. make[2]: *** [configure-stage3-gcc] E

[Bug middle-end/41398] can't resolve .LFE1408 {*UND* section} - .Ltext0 {.text section}

--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-19 09:48 --- Please try http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151753 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41398

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #4 from davek at gcc dot gnu dot org 2009-09-19 09:44 --- Fortunately it even happens when using the stage1 compiler, which has usable debug info: (gdb) c 73 Will ignore next 72 crossings of breakpoint 1. Continuing. Hardware watchpoint 1: dw2_string_counter Old value = 73

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-19 09:43 --- Please attach preprocessed source. -- jakub at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:33 --- This is where the subsequently-undefined reference is being generated: Will ignore next 72 crossings of breakpoint 1. Continuing. Hardware watchpoint 1: {} 14169456 Old value = 73 New value = 74 0x004c5fe2 in mem_l

[Bug bootstrap/41404] expr.c undefined reference while linking jc1

--- Comment #1 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/

[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option

--- Comment #3 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- (In reply to comment #2) > Unsurprisingly, Oops, sorry, wrong PR! I was on the wrong browser tab. Apologies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340

[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option

--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:20 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/

[Bug bootstrap/41404] New: expr.c undefined reference while linking jc1

Bootstrap fails with: > java/expr.o:expr.c:(.debug_loc+0x7d61): undefined reference to `LASF74' Configured tr...@151860 with: /gnu/gcc/gcc-unpatched/configure '--prefix=/opt/gcc-tools' '-v' '--with-gmp=/usr' '--with-mpfr=/usr' '--enable-bootstrap' '--enable-version-specific-runtime-libs' '--enab

[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir

--- Comment #33 from rwild at gcc dot gnu dot org 2009-09-19 08:33 --- Fixed on trunk. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Known to fail|

[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir

--- Comment #32 from rwild at gcc dot gnu dot org 2009-09-19 08:30 --- Subject: Bug 35619 Author: rwild Date: Sat Sep 19 08:29:58 2009 New Revision: 151880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151880 Log: Fix long-standing in-tree build include-fixed bug. gcc/:

  1   2   >