[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=19701&action=view) Preprocessed source file causing the ICE This is the first source file that triggers

[Bug c/42860] New: ICE in gcc-4.4.3

MED 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 java/42849] New: 4.4.3 build failure: jar: internal error:

r --version gives jar (GNU Classpath) 0.98. Any chance this is related to bug 41472? -- Summary: 4.4.3 build failure: jar: internal error: Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: critical Priority: P3

[Bug tree-optimization/41798] internal compiler error: in expand_scalar_variables_expr, at graphite.c:4295

--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22 17:33 --- removing -floop- flags hides/removes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41798

[Bug c/41798] internal compiler error: in expand_scalar_variables_expr, at graphite.c:4295

--- Comment #2 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22 17:28 --- Created an attachment (id=18868) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18868&action=view) Resulting .s file This is basically empty. -- http://gcc.gnu.org/bugzilla/show_bug

[Bug c/41798] internal compiler error: in expand_scalar_variables_expr, at graphite.c:4295

--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22 17:27 --- Created an attachment (id=18867) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18867&action=view) Preprocessed file leading to ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41798

[Bug c/41798] New: internal compiler error: in expand_scalar_variables_expr, at graphite.c:4295

Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca GCC host triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41798

[Bug libgcj/41768] [regression] build failue in java component.

--- Comment #2 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-20 18:06 --- Shouldn't gjar be built (and used) by the bootstrap build? It seems that it was: find -name gjar -ls 41083574 -rwxr-xr-x 1 ronisronis2048 Oct 20 02:27 ./i686-pc-linux-gnu/li

[Bug libgcj/41768] New: [regression] build failue in java component.

[regression] build failue in java component. Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41768

[Bug java/41472] New: gcj -C Test.java fails in glib-java 0.4.2

ny problems. -- Summary: gcj -C Test.java fails in glib-java 0.4.2 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org Rep

[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction

--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 19:45 --- Turns out that the problem isn't in lapack/gfortran at all; rather the tests link to blas (here atlas) and one of my blas libs was corrupted. I rebuilt/reinstalled atlas and the problem goes

[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction

--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 18:45 --- As per comment #1, I compiled with '-O -pipe' (lapack added -fimplicit-none). I get the same behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673

[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction

--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 18:41 --- As per comment 2, here's my /proc/cupinfo. As to finding a minimized testcase, this is nontrivial as I don't know if the problem is in a lapack routine or in the testsuite routine its

[Bug fortran/40673] New: Lapack-3.2.1 testsuite fails with illegal instruction

1 testsuite fails with illegal instruction Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc d

[Bug c++/40074] Compile failure in ocrad-0.18

--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2009-05-08 20:16 --- Created an attachment (id=17832) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17832&action=view) Preprocessed source of source that triggers ICE -- http://gcc.gnu.org/bugzilla/show_

[Bug c++/40074] New: Compile failure in ocrad-0.18

-- Summary: Compile failure in ocrad-0.18 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronis

[Bug c/40064] New: gcc-4.4.0 fails to compile svn trunk mplayer.

1 Here are config.h and config.mak (I don't see a place to include an attachement): -- Summary: gcc-4.4.0 fails to compile svn trunk mplayer. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/38249] read(*,*) seems to have broken

--- Comment #8 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:36 --- I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build with -malign-double, not just fortran programs, then IMHO the flag is useless and should be removed. I've

[Bug fortran/38249] read(*,*) seems to have broken

--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:29 --- It works without -malign-double, but has worked with it for years. I understand that all modules (even thouse in MY libraries) have to be compiled with the same flags, but nothing seems to imply that

[Bug fortran/38249] read(*,*) seems to have broken

--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:08 --- Created an attachment (id=16764) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16764&action=view) sample source and makefile Running make or make DEBUG=x will generate the program. When

[Bug fortran/38249] read(*,*) seems to have broken

--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:07 --- OK, here's the information you requested: gfortran -v: Target: i686-pc-linux-gnu Configured with: ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr --with-gnu-as --enable-shared --with-g

[Bug fortran/38249] New: read(*,*) seems to have broken

ned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249

[Bug middle-end/37236] [4.3/4.4 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242

--- Comment #7 from ronis at ronispc dot chem dot mcgill dot ca 2008-08-25 21:45 --- As per the suggestions, I replaced the all instances of array declarations like X(1) to X(*) and the problem goes away. Whether it is the current standard or not, it was legal years ago, and tons of

[Bug fortran/37236] New: internal compiler error: in mark_operand_necessary, at tree-ssa-dce.c:242

ompiler error: in mark_operand_necessary, at tree-ssa-dce.c:242 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org Repo

[Bug fortran/24993] New: LAPACK builds but dies in the testsuite

s in the testsuite Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24993