[Bug c/40255] New: internal compiler error: in root_var_init, at tree-ssa-live.c:1034
When compiling the Cuba library from http://www.feynarts.de/cuba/ version 1.6 with gcc 4.2.4 I get: ./src/divonne/Explore.c: In function 'Explore': ./src/divonne/Explore.c:17: internal compiler error: in root_var_init, at tree-ssa-live.c:1034 The problem is specific to gcc 4.2.4 (it does not appear with 4.1.2, 4.3.3, or 4.4.0). When -O2 is ommitted from the command line, there is no internal compiler error. -- Summary: internal compiler error: in root_var_init, at tree-ssa- live.c:1034 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40255
[Bug c/40255] internal compiler error: in root_var_init, at tree-ssa-live.c:1034
--- Comment #1 from sliwa at cft dot edu dot pl 2009-05-26 11:08 --- Created an attachment (id=17918) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17918action=view) Divonne_preprocessed.c Compiler input that causes the internal error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40255
[Bug c++/40186] floating point comparison is wrong ( !(a b) (b a) is true )
--- Comment #7 from sliwa at cft dot edu dot pl 2009-05-18 14:52 --- The case (a b) (b a) shows that not discarding the extra precision before performing a comparison leads to serious problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #21 from sliwa at cft dot edu dot pl 2009-03-18 13:25 --- Yes, yes, using gcc has to be pain in the neck. You are reluctant to fix an obvious mistake and instead of saying sorry are keeping it broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug fortran/36072] New: missing symbols in gfortran
When linking a program build with gfortran 4.3.0 to lapack, I get /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r8_i4' /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r4_i4' -- Summary: missing symbols in gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in gfortran
--- Comment #1 from sliwa at cft dot edu dot pl 2008-04-28 14:47 --- See http://forums.amd.com/devforum/messageview.cfm?catid=217threadid=90399messid=881726parentid=856116FTVAR_FORUMVIEWTMP=Branch for a similar complaint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in libgfortran
--- Comment #2 from sliwa at cft dot edu dot pl 2008-04-28 15:02 --- OK, the LAPACK library was probably compiled with 4.1.2. -- sliwa at cft dot edu dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/33001] New: error with hexadecimal DATA
d1mach.f:90.43: DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' / 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) -- Summary: error with hexadecimal DATA Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:03 --- Created an attachment (id=14028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14028action=view) sample source that does not compile This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect
Statements like: DATA DMACH(1) / Z'0010' / DATA DMACH(2) / Z'7FEF' / DATA DMACH(3) / Z'3CA0' / DATA DMACH(4) / Z'3CB0' / DATA DMACH(5) / Z'3FD34413509F79FF' / generate incorrect data. -- Summary: 64-bit hexadecimal DATA incorrect Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linu GCC host triplet: x86_64-redhat-linu GCC target triplet: x86_64-redhat-linu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:15 --- Created an attachment (id=14029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029action=view) sample source that demonstrates the problem This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #2 from sliwa at cft dot edu dot pl 2007-08-06 11:18 --- There is also bug #33001. Both the bugs together make life difficult. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 11:21 --- Now I see that 32-bit data is incorrect also. DATA RMACH(1) / Z'0080' / DATA RMACH(2) / Z'7F7F' / DATA RMACH(3) / Z'3380' / DATA RMACH(4) / Z'3400' / DATA RMACH(5) / Z'3E9A209B' / -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #4 from sliwa at cft dot edu dot pl 2007-08-06 12:45 --- With -fno-range-check I get: d1mach.f: In function 'd1mach': d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables compilation terminated. See also bug #33002. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 12:41 --- 1. The attached d1mach.f works fine with g77. 2. The numbers are 32-bit, so why an overflow? Maybe the number is extended as a signed number (padded with ones), and the conversion is unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/32976] New: lapack 3.1.1 test major failure
There are major failures in the lapack 3.1.1 tests with gcc 2.95.3 and in the full range up to gcc 4.2.1. The problem seems to appear on 32-bit i386, when the routines chgeqz and zhgeqz are compiled with -O2. With 2.95.3 I get: cgd.out: Matrix order=8, type=15, seed=2866, 214, 1,1861, result 5 is 8.389E+06 Matrix order= 10, type=15, seed= 362, 860,1065,1109, result 5 is 8.389E+06 Matrix order= 12, type=15, seed=2619,3620,1934,2301, result 5 is 8.389E+06 Matrix order= 20, type=15, seed=1185,3266, 461, 701, result 5 is 8.389E+06 CGV drivers: 4 out of 1092 tests failed to pass the threshold zgd.out: Matrix order=8, type=15, seed=2866, 214, 1,1861, result 5 is 4.504E+15 Matrix order= 10, type=15, seed= 362, 860,1065,1109, result 5 is 4.504E+15 Matrix order= 12, type=15, seed=2619,3620,1934,2301, result 5 is 4.504E+15 Matrix order= 20, type=15, seed=1185,3266, 461, 701, result 5 is 4.504E+15 ZGV drivers: 4 out of 1092 tests failed to pass the threshold (notice that the failing cases are the same) With 4.2.1: CGV drivers: 65 out of 1092 tests failed to pass the threshold ZGV drivers: 66 out of 1092 tests failed to pass the threshold This may be similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1645 -- Summary: lapack 3.1.1 test major failure Product: gcc Version: 2.95.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl 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=32976
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #98 from sliwa at cft dot edu dot pl 2007-08-03 12:09 --- *** Bug 32976 has been marked as a duplicate of this bug. *** -- sliwa at cft dot edu dot pl changed: What|Removed |Added CC||sliwa at cft dot edu dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/32976] lapack 3.1.1 test major failure
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-03 12:09 --- *** This bug has been marked as a duplicate of 323 *** -- sliwa at cft dot edu dot pl changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32976
