[Bug c/40255] New: internal compiler error: in root_var_init, at tree-ssa-live.c:1034

: 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

[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

[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

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

[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

[Bug fortran/33001] New: error with hexadecimal DATA

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

[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

[Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect

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

[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

[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

[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

[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

[Bug fortran/32976] New: lapack 3.1.1 test major failure

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

[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