[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #16 from hjl at lucon dot org 2006-04-13 13:48 --- Created an attachment (id=11257) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11257&action=view) A patch to nullify pointers in local variables Tonto 1.0 has many local variables with uninitialized pointers. This patch fixes them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #17 from hjl at lucon dot org 2006-04-13 13:49 --- Created an attachment (id=11258) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11258&action=view) Another patch This is another patch to initialize local variable and fix a typo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug target/27253] New: [4.1/4.2 regression]: Gcc -m64 -m32 passes --32 --64 to assembler
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gcc -m64 -m32 y.s -c -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060411 (experimental) [trunk revision 112854 clean] as -V -Qy --32 --64 -o y.o y.s GNU assembler version 2.17.50.0.1 (x86_64-unknown-linux-gnu) using BFD version 2.17.50.0.1 20060420 [EMAIL PROTECTED] tmp]$ /usr/gcc-4.1/bin/gcc -m64 -m32 y.s -c -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-4.1/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --disable-checking --prefix=/usr/gcc-4.1 --with-local-prefix=/usr/local Thread model: posix gcc version 4.1.0 20060119 (prerelease) [gcc-4_1-branch revision 109972 clean] as -V -Qy --32 --64 -o y.o y.s GNU assembler version 2.17.50.0.1 (x86_64-unknown-linux-gnu) using BFD version 2.17.50.0.1 20060420 [EMAIL PROTECTED] tmp]$ [EMAIL PROTECTED] tmp]$ /usr/gcc-4.0/bin/gcc -m64 -m32 y.s -c -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-4.0/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --disable-checking --prefix=/usr/gcc-4.0 --with-local-prefix=/usr/local Thread model: posix gcc version 4.0.3 20060213 (prerelease) as -V -Qy --32 -o y.o y.s GNU assembler version 2.17.50.0.1 (x86_64-unknown-linux-gnu) using BFD version 2.17.50.0.1 20060420 -- Summary: [4.1/4.2 regression]: Gcc -m64 -m32 passes --32 --64 to assembler Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27253
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #6 from hjl at lucon dot org 2006-04-22 15:33 --- [EMAIL PROTECTED] stage1-gcc]$ ./xgcc -B./ -c -g -v /tmp/x.s -gstabs -gdwarf-2 Reading specs from ./specs Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060421 (experimental) [trunk revision 113135 clean] ./as --gstabs -V -Qy -o x.o /tmp/x.s GNU assembler version 2.17.50.0.1 (x86_64-unknown-linux-gnu) using BFD version 2.17.50.0.1 20060417 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug testsuite/27274] execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU
--- Comment #2 from hjl at lucon dot org 2006-04-24 16:24 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00917.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27274
[Bug fortran/27351] New: [4.2 Regression]: -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
I got [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gcc -ffixed-form -ffixed-line-length-132 -O2 bifoag.f90 -c bifoag.f90: In function âbifoagâ: bifoag.f90:127: internal compiler error: in gfc_conv_array_transpose, at fortran/trans-array.c:726 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gcc --version gcc (GCC) 4.2.0 20060425 (experimental) [trunk revision 113259 clean] -- Summary: [4.2 Regression]: -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=27351
[Bug fortran/27351] [4.2 Regression]: -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
--- Comment #2 from hjl at lucon dot org 2006-04-28 17:52 --- Failed: gcc version 4.2.0 20060417 (experimental) [trunk revision 113003 clean] Worked: gcc version 4.2.0 20060416 (experimental) [trunk revision 112982 clean] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] [4.2 Regression]: -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
--- Comment #3 from hjl at lucon dot org 2006-04-28 18:32 --- This patch http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00537.html causes this regression. But galgel doesn't fail on ia64 nor x86-64. -- hjl at lucon dot org changed: What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] [4.2 Regression]: -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
--- Comment #4 from hjl at lucon dot org 2006-04-28 18:38 --- Even more interesting, gcc -m32 works fine on x86-64: [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran-ffixed-form -ffixed-line-length-132 -m32 -O2 bifoag.f90 -S [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060425 (experimental) [trunk revision 113259 clean] [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran-ffixed-form -ffixed-line-length-132 -m32 -O2 bifoag.f90 -S bifoag.f90: In function bifoag: bifoag.f90:127: internal compiler error: in gfc_conv_array_transpose, at fortran/trans-array.c:726 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060425 (experimental) [trunk revision 113259 clean] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
--- Comment #6 from hjl at lucon dot org 2006-04-28 21:28 --- It looks that either the Fortran patch has a memory leak or it triggers a memory leak since gfc_add_modify_expr (&se->pre, gfc_conv_descriptor_dtype (dest), gfc_conv_descriptor_dtype (src)); around line 719 in trans-array.c causes ggc_alloc_stat to reuse memory used by src_ss->data.info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] -ffixed-line-length-132 ICE on 178.galgel in SPEC CPU 2K
--- Comment #7 from hjl at lucon dot org 2006-04-28 22:01 ---
I am not sure if I can post galgel source. I can't find a small testcase.
In gfc_conv_array_transpose, we first got
708 gfc_conv_expr_descriptor (&src_se, expr, src_ss);
(gdb) p src_ss
$40 = (gfc_ss *) 0x9871e10
(gdb) c
Continuing.
Breakpoint 13, gfc_free (p=0x9871e10)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/misc.c:56
56 {
(gdb) bt
#0 gfc_free (p=0x9871e10)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/misc.c:56
#1 0x080a69dd in gfc_free_ss (ss=0x9871e10)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/trans-array.c:376
#2 0x080a6a15 in gfc_cleanup_loop (loop=0xbff5f03c)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/trans-array.c:393
#3 0x080acb8e in gfc_conv_expr_descriptor (se=0xbff5f1c4, expr=0xb7cee750,
ss=0x9871e10)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/trans-array.c:4284
#4 0x080ad315 in gfc_conv_array_transpose (se=0xbff5f870, expr=0x9870410)
at /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/fortran/trans-array.c:708
Then we accssed the freed src_ss at
726 gcc_assert (src_info->dimen == 2);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] Memory leak in gfc_conv_array_transpose
--- Comment #10 from hjl at lucon dot org 2006-04-28 22:47 --- Does f951 call make_relative_prefix? -- hjl at lucon dot org changed: What|Removed |Added Summary|-ffixed-line-length-132 ICE |Memory leak in |on 178.galgel in SPEC CPU 2K|gfc_conv_array_transpose http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug fortran/27351] Use variable after free in gfc_conv_array_transpose
--- Comment #13 from hjl at lucon dot org 2006-04-29 14:45 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug other/27364] New: Gcc 4.2 miscompiles binutils
Gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64. When gcc 4.2 is used, "make check" in binutils from CVS will have one failure in gas. The problem is more_than_enough_bits_for_digits = (number_of_digits_to_use * 3321928 / 100 + 1); around line 347 in gas/atof-generic.c is computed as 4 when -O2 is used. -- Summary: Gcc 4.2 miscompiles binutils Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #5 from hjl at lucon dot org 2006-04-30 14:25 --- Andrew, I tried my best to find a testcase. The best I can do so far is to put a testcase in binutils so that when you build binutils with gcc 4.2 on Linux/x86 and Linux/x86-64, you will get an "make check" failure in gas. I don't think anyone should have serious problems to get binutils from CVS. If you don't think I should open this bug, just let me know. I will close it and open a new one when I find a small testcase. BTW, there was a typo in my email, it is when number_of_digits_to_use == 11, gcc 4.2 gets 4 for (number_of_digits_to_use * 3321928 / 100 + 1) when -O2 is used. From assembler code, it always gets 4 no matter what number_of_digits_to_use is. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #6 from hjl at lucon dot org 2006-04-30 15:33 --- Hi Jeff, It looks like your patch http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01386.html causes gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64. -- hjl at lucon dot org changed: What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #8 from hjl at lucon dot org 2006-04-30 17:55 --- Created an attachment (id=11350) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11350&action=view) A testcase [EMAIL PROTECTED] gas]$ /export/build/gnu/gcc-last/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-last/build-x86_64-linux/./prev-gcc/ -O2 foo.c [EMAIL PROTECTED] gas]$ ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
-- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-04-30 18:11:21 |2006-04-30 18:11:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug rtl-optimization/27437] New: [4.2 Regression]: -O3 regression due to SEE
The new SEE pass is turned on by -O3, which introduces several regressions on Linux/x86 and probably on Linux/x86-64: http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00171.html shows FAIL: gcc.c-torture/compile/pr20539-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr20539-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/20050121-1.c compilation, -O3 -fomit-frame-pointer UNRESOLVED: gcc.c-torture/execute/20050121-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/20050121-1.c compilation, -O3 -g UNRESOLVED: gcc.c-torture/execute/20050121-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/930603-3.c compilation, -O3 -fomit-frame-pointer UNRESOLVED: gcc.c-torture/execute/930603-3.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/930603-3.c compilation, -O3 -g UNRESOLVED: gcc.c-torture/execute/930603-3.c execution, -O3 -g FAIL: gcc.c-torture/execute/arith-rand-ll.c compilation, -O3 -fomit-frame-pointer UNRESOLVED: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/arith-rand-ll.c compilation, -O3 -g UNRESOLVED: gcc.c-torture/execute/arith-rand-ll.c execution, -O3 -g FAIL: gcc.c-torture/unsorted/udivmod4.c, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/unsorted/udivmod4.c, -O3 -g which aren't in http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00073.html -- Summary: [4.2 Regression]: -O3 regression due to SEE Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #5 from hjl at lucon dot org 2006-05-05 13:01 ---
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE:
(note:HI 17 14 18 2
("/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c")
18)
(insn:HI 18 17 19 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:18
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0))) 118 {extendhisi2}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:SI 72 [ start ])
(nil)))
(note:HI 19 18 20 2
("/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c")
19)
(insn:HI 20 19 22 2
/net/gnu-13/export/gnu/src/gcc-see/gcc/gcc/testsuite/gcc.c-torture/execute/20010224-1.c:19
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ]))) 115 {extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 18 (nil))
(nil))
Those notes may be added between insns because -g. NEXT_INSN/PREV_INSN
won't get you the adjacent insn in this case.
2. Not all zero_extend patterns are available for x86/x86-64. For
example:
(insn 137 0 0 (set (reg:SI 60 [ prephitmp.115 ])
(zero_extend:SI (subreg:QI (reg:SI 60 [ prephitmp.115 ]) 0)))
-1 (nil)
(nil))
may not be used on x86/x86-64. i386.md has
(define_expand "zero_extendqisi2"
[(parallel
[(set (match_operand:SI 0 "register_operand" "")
(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "")))
(clobber (reg:CC FLAGS_REG))])]
""
"")
This is case for all extensions for i386. For x86-64, only
zero_extendsidi2 won't clobber CC. But SEE doesn't provide a way for a backend
to deal with it.
3. When the original insns were
set (dest_extension_reg1) (sign_extend (source_extension_reg1))
set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
We created
ref: set (dest_extension_reg1) (sign_extend (source_extension_reg1))
def_se: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
and
use_se: set (dest_extension_reg1) (sign_extend (dest_extension_reg1))
ref: set (dest_extension_reg2) (sign_extend (dest_extension_reg1))
When def merge failed, def_se was deleted. Now use_se had a deleted
ref.
Basically, SEE doesn't handle
(set (reg/v:SI 70 [ j ])
(sign_extend:SI (subreg:HI (reg:SI 72 [ start ]) 0)))
(set (reg:DI 73 [ j ])
(sign_extend:DI (reg/v:SI 70 [ j ])))
correctly.
4. SEE also failed to handle
set (dest_extension_reg1) (zero_extend (source_extension_reg1))
set (reg) (..dest_extension_reg1..)
set (dest_extension_reg2) (sign_extend (source_extension_reg1))
(insn:HI 28 26 30 2 x.c:1201 (set (reg:DI 534 [ mode ])
(zero_extend:DI (reg/v:SI 264 [ mode ]))) 111
{zero_extendsidi2_rex64}
(insn_list:REG_DEP_TRUE 11 (nil))
(nil))
(insn:HI 30 28 269 2 x.c:1201 (set (reg:QI 261 [ D.24257 ])
(mem/s/u:QI (plus:DI (reg:DI 534 [ mode ])
(symbol_ref:DI ("mode_class") [flags 0x40] )) [0 mode_class S1 A8])) 55 {*movqi_1}
(insn_list:REG_DEP_TRUE 28 (nil))
(nil))
(insn:HI 269 30 270 2 x.c:1273 (set (reg:DI 546)
(sign_extend:DI (reg/v:SI 264 [ mode ]))) 115
{extendsidi2_rex64} (nil)
(nil))
#3 and #4 may happen since SEE uses NEXT_INSN/PREV_INSN to check
the adjacent insn. When -g is used, SEE may see the note instead of
the real adjacent insn and reaches wrong conclusion. It may lead to
compiler crash or wrong code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
-- hjl at lucon dot org changed: What|Removed |Added CC||denis dot nagorny at intel ||dot com Severity|critical|normal Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug rtl-optimization/27437] [4.2 Regression]: -O3 regression due to SEE
--- Comment #7 from hjl at lucon dot org 2006-05-05 15:49 --- (In reply to comment #6) > (In reply to comment #5) > > There are several problems with the current SEE implementation: > > > > 1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE > > is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE: > > > > That one is easy to fix. Please post a patch to using > next_nonnote_insn/prev_nonnote_insn instead. > > And then the -O3 (without -g) is a different issue. > You are right. Using next_nonnote_insn/prev_nonnote_insn won't solve -O3 (without -g). One real problem is SEE can't determine if SEE is safe by just looking at next_nonnote_insn/prev_nonnote_insn. The relevant insn may be a few more insns away. Denis, do you have a patch to address this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug target/24879] [4.1]: SSE3 monitor intrinsic doesn't work in 64bit
--- Comment #6 from hjl at lucon dot org 2006-05-08 14:00 --- It isn't fixed in 4.1. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug other/27576] New: The .eh_frame section in crtend.o has wrong aligment
In gcc/unwind-dw2-fde.h
/* The first few fields of a CIE. The CIE_id field is 0 for a CIE,
to distinguish it from a valid FDE. FDEs are aligned to an addressing
unit boundary, but the fields within are unaligned. */
struct dwarf_cie
{
uword length;
sword CIE_id;
ubyte version;
unsigned char augmentation[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
/* The first few fields of an FDE. */
struct dwarf_fde
{
uword length;
sword CIE_delta;
unsigned char pc_begin[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
It indicates that CIE/FDE should be aligned at the pointer size. But crtstuff.c
has:
STATIC EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
__attribute__((section(EH_FRAME_SECTION_NAME), aligned(4)))
= { };
STATIC EH_FRAME_SECTION_CONST int32 __FRAME_END__[]
__attribute__ ((unused, section(EH_FRAME_SECTION_NAME),
aligned(sizeof(int32
= { 0 };
This leads to the corrupted .eh_frame section on x86-64:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2655
--
Summary: The .eh_frame section in crtend.o has wrong aligment
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 --- Hi Mark, I realized that I had an updated patch http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00090.html to address a concern from http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00050.html Can I update gcc/doc/invoke.texi? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #14 from hjl at lucon dot org 2006-05-16 17:37 --- I didn't see -fno-common in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. I am using: ../configure \ \ --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.2 \ --with-local-prefix=/usr/local to configure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug fortran/27633] New: Fortran accesses char array as integer
I got unaligned access on ia64 for
gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90
For
96subroutine test3 (ch1, ch2, ch3, clen)
97 integer clen
98 character(8) :: ch1(:)
99 character(*) :: ch2(2)
100 character(clen) :: ch3(2)
101 character(8) :: cntrl(2) = (/"lmnoPQRS","LMNOpqrs"/)
102 integer(8) :: ic(2)
103 ic = transfer (cntrl, ic)
Gfortran generates code like
(insn 1785 1391 2163 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(plus:DI (high:DI (symbol_ref:DI ("cntrl.1064") [flags 0x2] ))
(reg:DI 1 r1))) 76 {*load_symptr_high} (nil)
(nil))
...
(insn 1786 2163 2164 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(lo_sum:DI (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(symbol_ref:DI ("cntrl.1064") [flags 0x2] ))) 77 {*load_symptr_low} (nil)
(nil))
...
(insn 1395 2164 2165 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg:DI 15 r15 [1139])
(mem/s/j:DI (post_inc:DI (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])) [0
S8 A64])) 5 {*movdi_internal} (insn_list:REG_DEP_TRUE 1392 (nil))
(expr_list:REG_INC (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(nil)))
So cntrl is read as 64bit integer.
--
Summary: Fortran accesses char array as integer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27633
[Bug fortran/27652] New: Array list-directed output isn't human friendly
[EMAIL PROTECTED] tmp]$ cat x.f90 program foo integer, dimension (1:20):: a a= 0 print *,a end [EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gfortran -static x.f90 [EMAIL PROTECTED] tmp]$ ./a.out 0 0 0 0 0 00 0 0 0 0 0 00 0 0 0 0 0 0 [EMAIL PROTECTED] tmp]$ /opt/intel/fc/9.0/bin/ifort x.f90 [EMAIL PROTECTED] tmp]$ ./a.out 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [EMAIL PROTECTED] tmp]$ -- Summary: Array list-directed output isn't human friendly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27652
[Bug libfortran/27652] Array output does not self wrap
--- Comment #3 from hjl at lucon dot org 2006-05-18 04:56 --- The testcase only have 20 elements of 0. The real array has more than 800 elements of complex with different values. I am debugging a gfortran bug. Since gdb isn't really useful, I am using "print *," to see what are in the array. Gfortran outputs a very long line. It is very hard to exam/compare what are in the array. It will be nice for "print *" to break the line if the line is over 80 chars. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27652
[Bug fortran/27662] New: Transpose doesn't work on function return
[EMAIL PROTECTED] tmp]$ cat x.f90 program foo implicit none real(kind=kind(1.0d0)), dimension (2, 2):: x, y, z; integer i, j open (10, status="scratch") write (10, *) "0.10E+010.00E+00" write (10, *) "0.00E+000.10E+01" rewind (10) read (10,*) x print "(2(e20.10))", x print * z = matmul (x, transpose (test ())) print "(2(e20.10))", z do i = 1, size (x, 1) do j = 1, size (x, 2) if (x (i, j) .ne. z (i, j)) call abort () end do end do close (10) contains function test () result (res) real(kind=kind(1.0d0)), dimension(2,2) :: res rewind (10) read (10,*) res print "(2(e20.10))", res print * end function end [EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gfortran -static x.f90 [EMAIL PROTECTED] tmp]$ ./a.out 0.10E+010.00E+00 0.00E+000.10E+01 0.10E+010.00E+00 0.00E+000.10E+01 0.10E+010.00E+00 0.10E+010.00E+00 Aborted [EMAIL PROTECTED] tmp]$ -- Summary: Transpose doesn't work on function return Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27662] Transpose doesn't work on function return
--- Comment #1 from hjl at lucon dot org 2006-05-18 18:24 --- This testcase is derived from Tonto in SPEC CPU 2006. -- hjl at lucon dot org changed: What|Removed |Added OtherBugsDependingO||15502 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27662] Transpose doesn't work on function return
--- Comment #3 from hjl at lucon dot org 2006-05-18 21:22 --- I got atmp.17.dtype = 538; atmp.17.dim[0].stride = 2; atmp.17.dim[0].lbound = 0; atmp.17.dim[0].ubound = 1; atmp.17.dim[1].stride = 0; <- Shouldn't it be 1? atmp.17.dim[1].lbound = 0; atmp.17.dim[1].ubound = 1; atmp.17.data = &A.16; atmp.17.offset = 0; _gfortran_matmul_r8 (&parm.13, &parm.14, &atmp.17); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27662] Transpose doesn't work on function return
--- Comment #4 from hjl at lucon dot org 2006-05-18 21:54 --- Also atmp.6.dtype = 538; atmp.6.dim[0].stride = 1; atmp.6.dim[0].lbound = 0; atmp.6.dim[0].ubound = 1; atmp.6.dim[1].stride = 2; atmp.6.dim[1].lbound = 0; atmp.6.dim[1].ubound = 1; atmp.6.data = (void *) &A.7; atmp.6.offset = 0; atmp.6.dim[0].stride = 0; <-- That causes the problem. test (&atmp.6); atmp.8.dtype = atmp.6.dtype; atmp.8.dim[0].stride = atmp.6.dim[1].stride; atmp.8.dim[0].lbound = atmp.6.dim[1].lbound; atmp.8.dim[0].ubound = atmp.6.dim[1].ubound; atmp.8.dim[1].stride = atmp.6.dim[0].stride; atmp.8.dim[1].lbound = atmp.6.dim[0].lbound; atmp.8.dim[1].ubound = atmp.6.dim[0].ubound; atmp.8.data = atmp.6.data; atmp.8.offset = atmp.6.offset; _gfortran_matmul_r8 (&parm.4, &parm.5, &atmp.8); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27662] Transpose doesn't work on function return
--- Comment #5 from hjl at lucon dot org 2006-05-18 22:21 --- There are 2042 /* Zero the first stride to indicate a temporary. */ 2043 tmp = gfc_conv_descriptor_stride (info->descriptor, gfc_rank_cst[0]); 2044 gfc_add_modify_expr (&se->pre, tmp, 2045convert (TREE_TYPE (tmp), integer_zero_node)); in gfc_conv_function_call. Later transpose is called on it. But we never restore the first stride. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug fortran/27662] Transpose doesn't work on function return
--- Comment #6 from hjl at lucon dot org 2006-05-18 23:02 ---
This hack works for the testcase. But I don't know if it is the correct fix
or not.
2006-05-17 H.J. Lu <[EMAIL PROTECTED]>
PR fortran/27662
* trans-expr.c (gfc_conv_function_call) Restore the first
stride after the function call.
--- gcc/fortran/trans-expr.c.transpose 2006-04-16 11:18:33.0 -0700
+++ gcc/fortran/trans-expr.c2006-05-18 15:55:30.0 -0700
@@ -2022,6 +2022,8 @@ gfc_conv_function_call (gfc_se * se, gfc
retargs = gfc_chainon_list (retargs, se->expr);
else if (sym->result->attr.dimension)
{
+ tree stride;
+
gcc_assert (se->loop && info);
/* Set the type of the array. */
@@ -2039,14 +2041,17 @@ gfc_conv_function_call (gfc_se * se, gfc
false, !sym->attr.pointer,
callee_alloc);
/* Zero the first stride to indicate a temporary. */
- tmp = gfc_conv_descriptor_stride (info->descriptor, gfc_rank_cst[0]);
- gfc_add_modify_expr (&se->pre, tmp,
- convert (TREE_TYPE (tmp), integer_zero_node));
+ stride = gfc_conv_descriptor_stride (info->descriptor,
gfc_rank_cst[0]);
+ gfc_add_modify_expr (&se->pre, stride,
+ convert (TREE_TYPE (stride),
integer_zero_node));
/* Pass the temporary as the first argument. */
tmp = info->descriptor;
tmp = build_fold_addr_expr (tmp);
retargs = gfc_chainon_list (retargs, tmp);
+
+ /* Restore the first stride after the function call. */
+ gfc_add_modify_expr (&post, stride, info->stride [0]);
}
else if (ts.type == BT_CHARACTER)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug bootstrap/27673] New: Gcc failed to bootstrap on Linux
With revision 113891, I got
[EMAIL PROTECTED] libiberty]$ cat foo.c
typedef int __io_write_fn (void *__cookie, __const char *__buf,
int __n);
int
main ()
{
return 0;
}
[EMAIL PROTECTED] libiberty]$
/export/build/gnu/gcc/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-4.2/x86_64-unknown-linux-gnu/bin/ -g -O2foo.c
foo.c:6: error: [*] not allowed in other than function prototype scope
--
Summary: Gcc failed to bootstrap on Linux
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27673
[Bug bootstrap/27673] [4.2 Regression] Gcc failed to bootstrap on Linux
--- Comment #4 from hjl at lucon dot org 2006-05-19 01:14 --- Gcc is configured with /net/gnu-13/export/gnu/src/gcc/gcc/configure \ \ --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.2 \ --with-local-prefix=/usr/local The stage1 compiler failed. -- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |NEW Component|c |bootstrap Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-19 01:14:40 date|| Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27673
[Bug fortran/27662] [gcc 4.1]: Transpose doesn't work on function return
--- Comment #10 from hjl at lucon dot org 2006-05-20 22:21 --- I applied the same patch to gcc 4.1 redhat. Now I can build and run SPEC CPU 2006 successfully with gcc for the first time. The only issue is I have to apply 2 patches to tonto in SPEC CPU 2006. I am not 100% sure that if tonto in SPEC CPU 2006 conforms to Fortan standard. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|Transpose doesn't work on |[gcc 4.1]: Transpose doesn't |function return |work on function return Version|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug middle-end/27694] New: C++ dynamic cast is incorrect
After this patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00057.html C++ dynamic cast code on x86-64 changes to call__dynamic_cast testb %al, %al and stops working for some cases. The previous working version on x86-64 is call__dynamic_cast testq %rax, %rax -- Summary: C++ dynamic cast is incorrect Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27694
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #5 from hjl at lucon dot org 2006-05-21 00:16 --- This bug only shows up after this patch http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00057.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #8 from hjl at lucon dot org 2006-05-21 00:48 --- This patch does pass my initial test. I will rebuild the whole benckmark to double check it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug fortran/27633] Fortran accesses char array as integer with transfer
--- Comment #4 from hjl at lucon dot org 2006-05-21 06:58 --- It is the same as PR 27449. *** This bug has been marked as a duplicate of 27449 *** -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27633
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #3 from hjl at lucon dot org 2006-05-21 06:58 --- *** Bug 27633 has been marked as a duplicate of this bug. *** -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #4 from hjl at lucon dot org 2006-05-21 06:59 --- It also happens on Linux/ia64. -- hjl at lucon dot org changed: What|Removed |Added GCC host triplet|hppa64-hp-hpux11.11 | GCC target triplet|STRICT_ALGINED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #8 from hjl at lucon dot org 2006-05-21 16:57 --- The proposed patch works Linux/ia64: http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01188.html The visual inspection shows memcpy is used instead of ld8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #9 from hjl at lucon dot org 2006-05-21 17:42 --- I have verified that the proposed patch fixes the C++ run-time problem on Linux/x86, Linux/x86-64 and Linux/ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return
--- Comment #12 from hjl at lucon dot org 2006-05-23 17:15 --- Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0 on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like integer, pointer :: d ... if (associated(d)) call abort() But nullify is never called on d before. Tonto compiled by gfortran may return TRUE and abort. I checked Fortran standard. It isn't very clear if it is valid Fortran code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug other/27774] New: "make install-info" no longer works
true; fi; rm -f ../release/usr/gcc-4.2/info/gcj.info if [ -f doc/gcj.info ]; then \ for f in doc/gcj.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /usr/bin/install -c -m 644 $f ../release/usr/gcc-4.2/info/$realfile; \ chmod a-x ../release/usr/gcc-4.2/info/$realfile; \ done; \ else true; fi if /bin/sh -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f ../release/usr/gcc-4.2/info/gcj.info ]; then \ install-info --dir-file=../release/usr/gcc-4.2/info/dir ../release/usr/gcc-4.2/info/gcj.info; \ else true; fi; \ else true; fi; make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/gcc' Doing info in intl make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/intl' make[2]: Nothing to be done for `info'. make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' Doing install-info in intl make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/intl' make[2]: *** No rule to make target `install-info'. Stop. make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' make[1]: *** [install-info-intl] Error 1 make[1]: Leaving directory `/export/build/gnu/gcc/build-i686-linux' make: *** [do-install-info] Error 2 [EMAIL PROTECTED] build-i686-linux]$ -- Summary: "make install-info" no longer works Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug bootstrap/27774] "make install-info" no longer works
--- Comment #2 from hjl at lucon dot org 2006-05-26 17:57 --- "make install-info" doesn't work in gcc/intl in 3.4, 4.0, 4.1. But it used to work in src/intl. After merging intl from gcc to src, "make install-info" no longers in src/intl. -- hjl at lucon dot org changed: What|Removed |Added URL||http://sources.redhat.com/bu ||gzilla/show_bug.cgi?id=2701 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug bootstrap/27774] "make install-info" no longer works
--- Comment #4 from hjl at lucon dot org 2006-05-26 18:49 --- I didn't see intl in my gcc 3.3. My gcc is configured with /net/gnu-13/export/gnu/src/gcc/gcc/configure \ \ --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.2 \ --with-local-prefix=/usr/local I never used "make install-info" in gcc. I only used it in binutils. It used to work until int from gcc was copied over. I am using: 2006-05-26 H.J. Lu <[EMAIL PROTECTED]> PR binutils/2701 PR gcc/27774 * Makefile.in (install-info): Put it back. --- intl/Makefile.in.info 2006-05-24 09:01:37.0 -0700 +++ intl/Makefile.in2006-05-26 10:36:01.0 -0700 @@ -116,6 +116,7 @@ DEFS-relocatable.o = -DINSTALLDIR="\"$(l all: [EMAIL PROTECTED]@ all-yes: libintl.a libintl.h config.intl all-no: # nothing +install-info: # nothing libintl.a: $(OBJECTS) rm -f $@ to work around it. -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-05-26 18:49:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto correctly
--- Comment #22 from hjl at lucon dot org 2006-05-30 16:08 --- Tonto in SPEC CPU 2006 should work now with gcc 4.1 and 4.2. -- hjl at lucon dot org changed: What|Removed |Added BugsThisDependsOn||27662 Status|NEW |RESOLVED Resolution||FIXED Summary|[meta-bug] Gfortran can't |[meta-bug] Gfortran can't |compile tonto |compile tonto correctly Bug 26106 depends on bug 27662, which changed state. Bug 27662 Summary: [4.1 only]: Transpose doesn't work on function return http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||FIXED Status|RESOLVED|REOPENED Resolution|FIXED | Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return
--- Comment #17 from hjl at lucon dot org 2006-05-30 16:10 --- Yes, tonto-1.0-nullify-1.patch in PR 26106 is the one. -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug rtl-optimization/27437] -O2 -fsee failures on x86
--- Comment #18 from hjl at lucon dot org 2006-05-31 17:31 --- Last time when I tried it on x86 and x86-64 with SPEC CPU 2000, it didn't do anything useful. I will try it again with SPEC CPU 2000 and 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #5 from hjl at lucon dot org 2006-06-07 15:51 ---
This testcase doesn't use -Os on SSE registers:
[EMAIL PROTECTED] stack]$ cat m.c
#include
extern char *e1 (void);
int
main ()
{
printf ("%s\n", e1 ());
return 0;
}
[EMAIL PROTECTED] stack]$ cat x.c
#include
extern char *e1 (void);
char *e1 (void)
{
volatile __m128 dummy = _mm_set_ps1(0.f);
return "OK";
}
[EMAIL PROTECTED] stack]$ make
gcc -Os -c -o m.o m.c
gcc -O -msse2 -c -o x.o x.c
gcc -o m m.o x.o
./m
make: *** [all] Segmentation fault
[EMAIL PROTECTED] stack]$
It calls a function which uses SSE registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug target/28074] New: -mstackrealign generates very inefficient code
[EMAIL PROTECTED] xmm]$ cat x.c
#include
extern char *e1 (void);
char *e1 (void)
{
volatile __m128 dummy = _mm_set_ps1(0.f);
return "OK";
}
[EMAIL PROTECTED] xmm]$ /usr/gcc-4.2/bin/gcc -m32 -O -msse2 -S -mstackrealign
x.c
[EMAIL PROTECTED] xmm]$ cat x.s
.file "x.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "OK"
.text
.globl e1
.type e1, @function
e1:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
subl$20, %esp
xorps %xmm0, %xmm0
movaps %xmm0, -24(%ebp)
movl$.LC0, %eax
addl$20, %esp
popl%ecx
popl%ebp
leal-4(%ecx), %esp
ret
.size e1, .-e1
.ident "GCC: (GNU) 4.2.0 20060613 (experimental) [trunk revision
114620 clean]"
.section.note.GNU-stack,"",@progbits
[EMAIL PROTECTED] xmm]$
Icc 9.1 generates:
.globl e1
e1:
..B1.1: # Preds ..B1.0
pushl %ebp #4.1
movl %esp, %ebp#4.1
andl $-16, %esp#4.1
subl $16, %esp #4.1
xorps %xmm0, %xmm0 #5.27
movaps%xmm0, (%esp) #5.19
movl $__STRING.0, %eax #6.10
movl %ebp, %esp#6.10
popl %ebp #6.10
ret #6.10
It doesn't waste ecx to align the stack.
--
Summary: -mstackrealign generates very inefficient code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
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=28074
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #27 from hjl at lucon dot org 2006-06-29 02:32 --- Created an attachment (id=11777) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11777&action=view) An integer loop I changed the loop from double to long long. The 64bit code generated by gcc 4.0 is 10% slower than gcc 3.4 on Nocona: /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -o xmm_gcc mmbench.o gemm_atlas.o rm -f *.o /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -o xmm_gc4 mmbench.o gemm_atlas.o rm -f *.o echo "GCC 3.x performance:" GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60250 0.381 283.51 echo "GCC 4.x performance:" GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60250 0.389 277.68 gnu-16:pts/2[5]> make ~/bugs/gcc/27827/loop /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xmm_gcc mmbench.o gemm_atlas.o rm -f *.o /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xmm_gc4 mmbench.o gemm_atlas.o rm -f *.o echo "GCC 3.x performance:" GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.172 2512.01 echo "GCC 4.x performance:" GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.193 2238.68 So the problem may be also loop related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/24738] New: [4.0]: Message typos in i386 backend
In i386.h, there are
{ "push-args",-MASK_NO_PUSH_ARGS, \
N_("Use push instructions to save outgoing arguments") }, \
{ "no-push-args", MASK_NO_PUSH_ARGS,\
N_("Do not use push instructions to save outgoing arguments") }, \
{ "accumulate-outgoing-args", MASK_ACCUMULATE_OUTGOING_ARGS,\
N_("Use push instructions to save outgoing arguments") }, \
{ "no-accumulate-outgoing-args",-MASK_ACCUMULATE_OUTGOING_ARGS, \
N_("Do not use push instructions to save outgoing arguments") },
The messages for "accumulate-outgoing-args" and "no-accumulate-outgoing-args"
are cut-and-paste errors.
--
Summary: [4.0]: Message typos in i386 backend
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24738
[Bug target/24764] New: TARGET_MEMORY_MISMATCH_STALL is never used
TARGET_MEMORY_MISMATCH_STALL introduced in http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00600.html is never used. -- Summary: TARGET_MEMORY_MISMATCH_STALL is never used Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24764
[Bug target/24765] New: TARGET_USE_BIT_TEST is never used
TARGET_USE_BIT_TEST introduced in http://gcc.gnu.org/ml/gcc-patches/1998-08/msg00197.html is never used. -- Summary: TARGET_USE_BIT_TEST is never used Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24765
[Bug target/24766] New: Unused TARGET_DECOMPOSE_LEA
This patch http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01574.html removed the last usage of TARGET_DECOMPOSE_LEA. -- Summary: Unused TARGET_DECOMPOSE_LEA Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24766
[Bug target/24879] New: SSE3 intrinsic bug
It seems that SSE3 _mm_monitor instrinsic doesn't work too well with
64bit.
[EMAIL PROTECTED] function]$ cat x.c
#include
#include
static void
foo (char *p)
{
_mm_monitor(p, 0, 0);
}
main()
{
char *p = (char *)&foo;
int fail = 1;
int i;
for (i = 0; i < 20; i++) {
if (p[i] == 0x0f) {
fail = 0;
break;
}
}
printf ("failed: %d\n", fail);
return 0;
}
[EMAIL PROTECTED] function]$ make
/usr/gcc-4.1/bin/gcc -O2 -msse3x.c -o x
x.c: In function \u\u\ufoo\u\u\u:
x.c:8: error: unrecognizable insn:
(insn 11 10 12 1 (unspec_volatile [
(reg/v/f:DI 58 [ p ])
(reg:SI 59)
(reg:SI 60)
] 8) -1 (nil)
(nil))
x.c:8: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [x] Error 1
[EMAIL PROTECTED] function]$ /usr/gcc-4.1/bin/gcc -O2 -msse3x.c -o x -m32
[EMAIL PROTECTED] function]$ ./x
failed: 0
--
Summary: SSE3 intrinsic bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug target/24879] SSE3 monitor intrinsic doesn't work in 64bit
--- Comment #3 from hjl at lucon dot org 2005-11-16 17:35 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01195.html -- hjl at lucon dot org changed: What|Removed |Added Keywords||patch Summary|SSE3 intrinsic bug |SSE3 monitor intrinsic ||doesn't work in 64bit http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
[Bug libfortran/24927] New: libfortran isn't parallel build safe
Makefile in libgfortran has selected_int_kind.lo: intrinsics/selected_int_kind.f90 $(LIBTOOL) --mode=compile $(FC) $(AM_FCFLAGS) $(FCFLAGS) -c -o selected_int_kind.lo `test -f 'intrinsics/selected_int_kind.f90' || echo '$(srcdir)/'`intrinsics/selected_int_kind.f90 But it doesn't depend on selected_int_kind.inc. With "make -j 4", I got /export/build/gnu/gcc/build-ia64-linux/./gcc/gfortran -B/export/build/gnu/gcc/build-ia64-linux/./gcc -B/usr/gcc-4.1/ia64-unknown-linux-gnu/bin/ -B/usr/gcc-4.1/ia64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.1/ia64-unknown-linux-gnu/include -isystem /usr/gcc-4.1/ia64-unknown-linux-gnu/sys-include -Wall -fno-repack-arrays -fno-underscoring -g -O2 -c /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o checking pwd.h presence... Error: Can't open included file 'selected_int_kind.inc' In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:36 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:37 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:39 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:35 selected_real_kind.lo has the same problem and I suspect there are more than those 2. -- Summary: libfortran isn't parallel build safe Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24927
[Bug target/25303] New: [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K
Gcc 4.0 20051113 and 4.120051207 miscompiled eon in SPEC CPU 2K with -O2. I got Running Benchmarks Running 252.eon ref base o2 default *** Miscompare of pixels_out.kajiya, see /export/spec/src/2000/spec/benchspec/CINT2000/252.eon/run/0002/pixels_out.kajiya.mis x86-64 seems OK. Gcc 4.2 20051203 is OK. -- Summary: [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=25303
[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K
--- Comment #3 from hjl at lucon dot org 2005-12-07 21:49 --- It could be. After adding -ffast-math to gcc 4.1, eon is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
[Bug target/25305] New: [4.0]: -O2 miscompiled fma3d in SPEC CPU 2K
Gcc 4.0.3 20051207 miscompiles fma3d in SPEC CPU 2K when -O2 on i686 and x86-64. I got Running Benchmarks Running 191.fma3d ref base o2 default Child returned with invalid return code(0) *** Miscompare of fma3d.out, see /export/spec/src/2000/spec/benchspec/CFP2000/191.fma3d/run/0002/fma3d.out.mis Gcc 4.1 and 4.2 are OK. -- Summary: [4.0]: -O2 miscompiled fma3d in SPEC CPU 2K Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org 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=25305
[Bug target/25303] [4.0/4.1] -O2 miscompiled eon in SPEC CPU 2K
--- Comment #5 from hjl at lucon dot org 2005-12-08 01:46 --- -ffloat-store fixed eon for gcc 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #1 from hjl at lucon dot org 2005-12-08 01:56 --- It looks like a regression. Gcc 4.0.2 20050912 works fine. -- hjl at lucon dot org changed: What|Removed |Added Summary|[4.0]: -O2 miscompiled fma3d|[4.0 regression]: -O2 |in SPEC CPU 2K |miscompiled fma3d in SPEC ||CPU 2K http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #2 from hjl at lucon dot org 2005-12-08 02:04 --- Gcc 4.0.3 20051007 is also OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #3 from hjl at lucon dot org 2005-12-08 02:11 --- Gcc 4.0.3 20051103 is also OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #4 from hjl at lucon dot org 2005-12-08 03:16 --- Gcc 4.0.3 20051108 is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #5 from hjl at lucon dot org 2005-12-08 03:28 --- Gcc 4.0.3 2005 is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25305] [4.0 regression]: -O2 miscompiled fma3d in SPEC CPU 2K
--- Comment #6 from hjl at lucon dot org 2005-12-08 03:30 --- Gcc 4.0.3 20051113 is bad. So this regression was introduced between 2005 and 20051113. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #7 from hjl at lucon dot org 2005-12-08 06:55 --- I have verified that http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00874.html is the cause. Since gcc 4.1 and 4.2 are OK, the problem may be in the backport. -- hjl at lucon dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Component|target |libfortran Summary|[4.0 regression]: -O2 |[4.0 regression]: libfortran |miscompiled fma3d in SPEC |failed fma3d in SPEC CPU 2K |CPU 2K | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #8 from hjl at lucon dot org 2005-12-08 07:32 ---
Revert
@@ -293,7 +292,7 @@ write_block (int length)
{
char *dest;
- if (!is_internal_unit() && current_unit->bytes_left < length)
+ if (current_unit->bytes_left < length)
{
generate_error (ERROR_EOR, NULL);
return NULL;
which wasn't even mentioned in ChangeLog, fixed this regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug java/25330] New: A race condition in write_classfile
MP @lists/java-net-protocol.list
echo timestamp > lists/java-net-protocol.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-nio-channels.deps -MT lists/java-nio-channels.stamp
-MP @lists/java-nio-channels.list
echo timestamp > lists/java-nio-channels.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-nio-charset.deps -MT lists/java-nio-charset.stamp
-MP @lists/java-nio-charset.list
echo timestamp > lists/java-nio-charset.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-nio.deps -MT lists/java-nio.stamp -MP
@lists/java-nio.list
echo timestamp > lists/java-nio.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-rmi-activation.deps -MT
lists/java-rmi-activation.stamp -MP @lists/java-rmi-activation.list
echo timestamp > lists/java-rmi-activation.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-rmi-dgc.deps -MT lists/java-rmi-dgc.stamp -MP
@lists/java-rmi-dgc.list
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In class
'java.net.VMNetworkInterface':
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In method
'java.net.VMNetworkInterface.getInterfaces()':
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java:1: fatal error:
can't create ./java/rmi/activation/ActivationMonitor.class: No such file or
directory
compilation terminated.
make[10]: *** [lists/gnu-src-gcc.stamp] Error 1
make[10]: *** Waiting for unfinished jobs
echo timestamp > lists/java-rmi-dgc.stamp
write_classfile in jcf-write.c:
/* The .class file is initially written to a ".tmp" file so that
if multiple instances of the compiler are running at once
they do not see partially formed class files. */
temporary_file_name = concat (class_file_name, ".tmp", NULL);
stream = fopen (temporary_file_name, "wb");
...
if (rename (temporary_file_name, class_file_name) == -1)
{
remove (temporary_file_name);
fatal_error ("can't create %s: %m", class_file_name);
}
There are at least 2 problems:
1. All processes use the same temporary_file_name. If 2 processes try to write
to the same class file, we are in trouble.
2. errno returned from rename is accessed after remove call which
may change errno.
--
Summary: A race condition in write_classfile
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25330
[Bug java/25330] A race condition in write_classfile
--- Comment #1 from hjl at lucon dot org 2005-12-10 01:48 --- I got another one: /export/build/gnu/gcc/build-x86_64-linux/gcc/gcj -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/ -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated --encoding=UTF-8 --bootclasspath '' --classpath ..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.: -C -d . -MD -MF lists/java-rmi-dgc.deps -MT lists/java-rmi-dgc.stamp -MP @lists/java-rmi-dgc.list /net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In class 'java.net.VMNetworkInterface': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In method 'java.net.VMNetworkInterface.getInterfaces()': /net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java:1: fatal error: can't create ./java/rmi/activation/ActivationSystem.class: No such file or directory compilation terminated. make[8]: *** [lists/gnu-src-gcc.stamp] Error 1 make[8]: *** Waiting for unfinished jobs echo timestamp > lists/java-rmi-dgc.stamp This time, there wass no "java/rmi/activation" directory under libjava: [EMAIL PROTECTED] build-x86_64-linux]$ ls x86_64-unknown-linux-gnu/libjava/java/ io lang net nio text util -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25330
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #10 from hjl at lucon dot org 2005-12-12 15:04 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00594.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug java/25330] A race condition in write_classfile
--- Comment #2 from hjl at lucon dot org 2005-12-12 15:05 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00794.html -- hjl at lucon dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25330
[Bug target/25397] New: Bootstrap failed
With gcc 4.2 revision 108480 on x86-64, I got ./xgcc -B./ -B/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/sys-include -L/export/build/gnu/gcc-blended/build-x86_64-linux/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/export/gnu/src/gcc-blended/gcc/gcc -I/export/gnu/src/gcc-blended/gcc/gcc/. -I/export/gnu/src/gcc-blended/gcc/gcc/../include -I/export/gnu/src/gcc-blended/gcc/gcc/../libcpp/include -I/export/gnu/src/gcc-blended/gcc/gcc/../libdecnumber -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c /export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o /export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.c: In function execute_stack_op: /export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.c:740: internal compiler error: in rtx_equiv_p, at struct-equiv.c:372 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [libgcc/./unwind-dw2.o] Error 1 -- Summary: Bootstrap failed Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug bootstrap/25397] Bootstrap failed
--- Comment #1 from hjl at lucon dot org 2005-12-13 21:03 --- Backout http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00899.html seems to fix this failure. -- hjl at lucon dot org changed: What|Removed |Added CC||joern dot rennecke at st dot ||com Component|target |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug bootstrap/25397] Bootstrap failed
--- Comment #3 from hjl at lucon dot org 2005-12-13 21:33 --- I believe so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug bootstrap/25397] Bootstrap failed
--- Comment #6 from hjl at lucon dot org 2005-12-13 22:12 --- Created an attachment (id=10477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10477&action=view) A testcase I got gnu-13:pts/7[26]> ./xgcc -B./ unwind-dw2.i -S -fPIC -O2 /export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.c: In function execute_stack_op: /export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.c:740: internal compiler error: in rtx_equiv_p, at struct-equiv.c:372 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug bootstrap/25435] New: stage build no longer works
I used to be able to do # cd gcc # make unstage1 # make restage1 But now ./prev-gcc/xgcc is used to rebuild stage 1 compiler, not the system compiler. -- Summary: stage build no longer works Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug bootstrap/25435] stage build no longer works
--- Comment #1 from hjl at lucon dot org 2005-12-16 07:22 --- It is very very annoying now. I can no longer do # cd gcc # make restage3 I got ... + echo stage3_build make LANGUAGES="c gcov gcov-dump c++ fortran java objc" BOOT_CFLAGS="-g -O2" stage3_build make[1]: Entering directory `/export/build/gnu/gcc-blended/build-x86_64-linux/stage3-gcc' make CC="/export/build/gnu/gcc-blended/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-blended/build-x86_64-linux/./prev-gcc/ -B/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/bin/" libdir=/usr/gcc-4.2-blended/lib LANGUAGES="c " \ CFLAGS="-g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING" \ MAKEINFO="makeinfo --split-size=500 --split-size=500" MAKEINFOFLAGS="--no-split" \ ... /export/build/gnu/gcc-blended/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-blended/build-x86_64-linux/./prev-gcc/ -B/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/bin/ -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -DHAVE_CONFIG_H -I. -I. -I/export/gnu/src/gcc-blended/gcc/gcc -I/export/gnu/src/gcc-blended/gcc/gcc/. -I/export/gnu/src/gcc-blended/gcc/gcc/../include -I/export/gnu/src/gcc-blended/gcc/gcc/../libcpp/include -I/export/gnu/src/gcc-blended/gcc/gcc/../libdecnumber\ /export/gnu/src/gcc-blended/gcc/gcc/config/i386/i386.c -o i386.o ... main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libbackend.a(i386.o): In function `VEC_edge_base_index':/export/gnu/src/gcc-blended/gcc/gcc/basic-block.h:147: undefined reference to `vec_assert_fail' collect2: ld returned 1 exit status make[2]: *** [cc1-dummy] Error 1 The wrong CFLAGS was used. -- hjl at lucon dot org changed: What|Removed |Added CC||bonzini at gnu dot org Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug bootstrap/25435] stage build no longer works
--- Comment #2 from hjl at lucon dot org 2005-12-16 07:37 --- I made a change to i386.c. I just want to rebuild the final compiler with the stage 2 compiler. I don't want to rebootstrap the whole gcc. What should I do? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #12 from hjl at lucon dot org 2005-12-19 14:40 --- Can you tell me which check in fixes this bug for 4.0? -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #19 from hjl at lucon dot org 2005-12-20 06:22 --- Shouldn't that case also be added to 4.1 and mainline to prevent this bug from happening there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #21 from hjl at lucon dot org 2005-12-20 14:44 --- Steven, see comment #1. I was talking about the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25585] New: [4.2 regression]: unaligned access in SPEC CPU 2K
I got apsi_base.o2(3621): unaligned access to 0x6fffb03c, ip=0x4002b0a0 apsi_base.o2(3621): unaligned access to 0x6fffb03c, ip=0x4002b361 apsi_base.o2(3621): unaligned access to 0x6fffb03c, ip=0x4001bbe1 apsi_base.o2(3621): unaligned access to 0x6fffb03c, ip=0x40020ae1 during SPEC CPU 2K run. I didn't get those with gcc 4.2.0 20051221. -- Summary: [4.2 regression]: unaligned access in SPEC CPU 2K Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25585] [4.2 regression]: unaligned access in SPEC CPU 2K
--- Comment #2 from hjl at lucon dot org 2005-12-29 01:01 --- I have identified that http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01261.html causes the unaligned access in SPEC CPU 2K on ia64. We are working on a small testcase. -- hjl at lucon dot org changed: What|Removed |Added CC||grigory_zagorodnev at linux ||dot intel dot com Last reconfirmed|-00-00 00:00:00 |2005-12-29 01:01:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25585] [4.2 regression]: unaligned access in SPEC CPU 2K
--- Comment #3 from hjl at lucon dot org 2005-12-29 01:18 --- The difference between good and bad assembly outputs are --- good.s 2005-12-28 17:06:29.0 -0800 +++ bad.s 2005-12-28 17:16:11.0 -0800 @@ -37339,11 +37339,11 @@ uvset_: .mmi mov r1 = r71 nop 0 - adds r16 = 96, r12 + adds r14 = 96, r12 ;; .mmi nop 0 - ld4 r15 = [r16] + ld4 r15 = [r14] nop 0 ;; .mib @@ -37494,11 +37494,11 @@ uvset_: .mmi mov r1 = r71 nop 0 - adds r16 = 96, r12 + adds r14 = 96, r12 ;; .mmi nop 0 - ld4 r15 = [r16] + ld4 r15 = [r14] nop 0 ;; .mib @@ -61983,7 +61983,7 @@ pset_: mov r20 = b0 ;; .mmi - adds r15 = 1392, r12 + adds r24 = 1040, r12 mov r19 = ar.unat addl r14 = @gprel(.LC338), gp .mmi @@ -62105,7 +62105,7 @@ pset_: adds r32 = 488, r12 ;; .mmi - ld8 r24 = [r18], 8 + ld8 r15 = [r18], 8 setf.sig f7 = r19 sxt4 r14 = r19 .mmi @@ -62114,54 +62114,54 @@ pset_: cmp4.le p6, p7 = r19, r20 ;; .mmi + adds r18 = 1392, r12 setf.sig f8 = r14 - st8 [r15] = r24 sxt4 r14 = r20 .mmi - adds r15 = 8, r40 - ld8 r18 = [r18] - adds r24 = 1040, r12 - .mmi (p6) mov r21 = r20 (p7) mov r21 = r19 shladd r23 = r19, 1, r0 - .mmi - shladd r22 = r20, 1, r0 - setf.sig f5 = r34 - adds r34 = 504, r12 ;; .mmi + st8 [r18] = r15 + adds r15 = 8, r40 cmp4.le p6, p7 = r16, r21 - adds r23 = 15, r23 - adds r22 = 15, r22 .mmi - setf.sig f2 = r37 - setf.sig f17 = r35 - adds r33 = 496, r12 + ld8 r18 = [r18] + shladd r22 = r20, 1, r0 + adds r23 = 15, r23 ;; .mmi (p7) mov r21 = r16 - setf.sig f16 = r36 nop 0 + adds r22 = 15, r22 .mmi - setf.sig f18 = r38 + setf.sig f5 = r34 + setf.sig f2 = r37 + adds r34 = 504, r12 + .mmi + setf.sig f17 = r35 + setf.sig f16 = r36 + adds r33 = 496, r12 + .mmf adds r35 = 512, r12 adds r36 = 520, r12 - .mmf - nop 0 - nop 0 xmpy.l f6 = f6, f7 .mmi + setf.sig f18 = r38 setf.sig f19 = r39 adds r38 = 536, r12 - adds r39 = 544, r12 - .mfi + .mmf nop 0 - fcvt.xf f7 = f8 nop 0 - .mmf + fcvt.xf f7 = f8 + .mmi setf.sig f8 = r16 + nop 0 + adds r39 = 544, r12 ;; + .mmf + nop 0 getf.sig r17 = f6 fnorm.d f7 = f7 .mmf @@ -74427,4 +74427,4 @@ var.1107: .common lake_#,112,16 .common source_#,152,16 .common strch_#,104,16 - .ident "GCC: (GNU) 4.2.0 20051222 (experimental) [trunk revision 108984 clean]" + .ident "GCC: (GNU) 4.2.0 20051222 (experimental) [trunk revision 108985 clean]" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25585] [4.2 regression]: unaligned access in SPEC CPU 2K
--- Comment #4 from hjl at lucon dot org 2005-12-29 02:23 --- For my case, the unaligned access happens in HORDFC. -- hjl at lucon dot org changed: What|Removed |Added CC||denis dot nagorny at intel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25603] New: [4.1/4.2 Regression]: Miscompiled FORTRAN program
I have identified that http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01261.html causes FORTRAN program to generate wrong result on ia64 -- Summary: [4.1/4.2 Regression]: Miscompiled FORTRAN program Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug target/25603] [4.1/4.2 Regression]: Miscompiled FORTRAN program
--- Comment #1 from hjl at lucon dot org 2005-12-30 17:40 --- Created an attachment (id=10571) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10571&action=view) A testcase I got /usr/gcc-4.2/bin/gfortran -O -fschedule-insns -o bar bar.f ./bar PROGRAM XSTART 201. BAR1 XSTART 0.00 make: *** [bar] Aborted make: *** Deleting file `bar' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug target/25585] [4.2 regression]: unaligned access in SPEC CPU 2K
--- Comment #6 from hjl at lucon dot org 2005-12-30 18:41 --- Reopen it. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25585] [4.2 regression]: unaligned access in SPEC CPU 2K
--- Comment #7 from hjl at lucon dot org 2005-12-30 18:42 --- *** This bug has been marked as a duplicate of 25603 *** -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25585
[Bug target/25603] [4.1/4.2 Regression]: Miscompiled FORTRAN program
--- Comment #2 from hjl at lucon dot org 2005-12-30 18:42 --- *** Bug 25585 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug libfortran/25604] New: libgfortran.so in 4.2 is incompatible with 4.1, but soname is the same
libgfortran.so in 4.2 is incompatible with 4.1. But they use the same soname. In binutils, we bump up the soname whenever the libfd ABI is changed. I think We should bump the library file's version number. -- Summary: libgfortran.so in 4.2 is incompatible with 4.1, but soname is the same Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25604
[Bug libfortran/25604] libgfortran.so in 4.2 is incompatible with 4.1, but soname is the same
--- Comment #2 from hjl at lucon dot org 2005-12-30 18:55 --- See http://gcc.gnu.org/ml/gcc/2005-12/msg00057.html -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25604
