[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-12 15:31 --- Revision 141780 is the case. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||burnus at net-b dot de Summary|gfortran.dg/private_type_4.f|[4.4 regression] |90 -O doesn't work |gfortran.dg/private_type_4.f ||90 -O doesn't work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38094] New: gfortran.dg/private_type_4.f90 -O doesn't work
On Linux/ia32, revision 141781 gave FAIL: gfortran.dg/private_type_4.f90 -O (test for errors, line 14) -- Summary: gfortran.dg/private_type_4.f90 -O doesn't work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-12 21:30 --- Revision 141798 gave: FAIL: gfortran.dg/private_type_4.f90 -O (test for errors, line 17) FAIL: gfortran.dg/private_type_4.f90 -O (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-14 03:45 --- This patch: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00593.html caused: Running target unix FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_x_tst.o-c_compat_y_tst.o link UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t012 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_main_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_x_tst.o compile FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_y_tst.o compile UNRESOLVED: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_x_tst.o
[Bug fortran/38138] New: [4.4 Regression] Revision 141890 caused gfortran.dg/proc_decl_18.f90
On Linux/Intel64, revision 141890 caused: Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran -B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90 -O3 -g -pedantic-errors -L/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libgfortran/.libs -L/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libgfortran/.libs -L/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libiberty -lm -m32 -o ./proc_decl_18.exe(timeout = 300) /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90:21: internal compiler error: Segmentation fault^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 -- Summary: [4.4 Regression] Revision 141890 caused gfortran.dg/proc_decl_18.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38138
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:06 --- (In reply to comment #3) > i tried to run the benchmark with -fno-ira, which turned out to be about 20% > slower than without the flag. > Can you try "-O3 -march=core2 -mtune=generic" and "-O3 -march=core2 -mtune=generic -fno-ira" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-16 00:08 --- (In reply to comment #3) > anyway, i found, that the preprocessed source generated by gcc-4.3 cannot be > compiled with gcc-4.4 ... the specific file can be found here > http://tim.klingt.org/git?p=nova-server.git;a=blob;f=benchmarks/simd_tan_benchmarks.cpp;h=c575996de0dc916a8e654af7a36350be9c22327e;hb=844d3cf991cbbbe74b34277696dda0b940769b28 > Please upload both preprocessed sources generated by gcc 4.3 and gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug libstdc++/38128] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:17 --- It is a bug in libstdc++. *** This bug has been marked as a duplicate of 37144 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38128
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-16 00:17 --- *** Bug 38128 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-16 19:21 --- (In reply to comment #7) > I am not convinced that PR 38128 is a duplicate of this bug. The test > doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu. > In debugging, there also seems to be an exception in the eh code causing a > loop. > ext/pb_ds/regression/trie_data_map_rand.cc fails on Linux/Intel64 at random. Can you disable the use of CFI directives and add -D_GLIBCXX_DEBUG to run it on hppa-unknown-linux-gnu by hand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libgcj/38162] New: [4.4 Regression] FAIL: gctest
On Linux/Intel64, revision 141928 gave
make[8]: Entering directory
`/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Lost a node at level 7 - collector is broken
Test failed
/bin/sh: line 4: 26509 Aborted LD_LIBRARY_PATH=../../gcc
${dir}$tst
FAIL: gctest
===
1 of 1 tests failed
===
make[8]: *** [check-TESTS] Error 1
Revision 141923 is OK.
--
Summary: [4.4 Regression] FAIL: gctest
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug rtl-optimization/37397] IRA performance impact on SPEC CPU 2K/2006
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-17 14:31 --- Revision 141860 caused 30% slowdown on 454.calculix in SPEC CPU 2006 with -O2 -ffast-math on Linux/Intel64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37397
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #28 from hjl dot tools at gmail dot com 2008-11-18 14:42 --- (In reply to comment #27) > Isn't this a regression? > The warning is new. But the same code won't compile with -Wall while gcc 4.1 has no problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug boehm-gc/38162] [4.4 Regression] FAIL: gctest
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-18 14:39 --- It is gone now. It may be a timing issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-19 18:09 --- I think we need to break OVERRIDE_OPTIONS into 2 parts: 1. Execute only once for a given input. 2. Execute every time after all optimization options are processed. with things like OVERRIDE_OPTIONS_ONCE and OVERRIDE_OPTIONS_ALWAYS. Then OVERRIDE_OPTIONS can be defined as #define OVERRIDE_OPTIONS \ OVERRIDE_OPTIONS_ALWAYS; \ OVERRIDE_OPTIONS_ONCE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug target/38201] New: -mfma/-mavx and -msse5/-msse4a don't work together
Both Intel FMA and AMD SSE5 support FMA. For -mfma, which enables
Intel FMA and is a dummy at the moment, or -msse5, we will
generate FMA instructions for
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
What FMA should "-mfma -msse5" generate? Also currently, with
"-O2 -mavx -msse5", we generate
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
which won't run on any machines. For "-mfma -msse5" and
"-mavx -msse5",
1. Should these combinations be allowed? If allowed,
2. Should the last option turn off the first one?
--
Summary: -mfma/-mavx and -msse5/-msse4a don't work together
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug c++/15795] No way to teach operator new anything about alignment requirements
--- Comment #41 from hjl dot tools at gmail dot com 2008-11-20 16:44 --- You may want to take a look at PR 36159. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-20 16:57 --- (In reply to comment #1) > 1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions). > So having "-msse5 -mfma" is same as having just "msse5", though you can just > have -fma (without -msse5). Please look closely. I added -mfma to i386.opt: --- mfma Target Report Mask(ISA_FMA) Var(ix86_isa_flags) VarExists Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX and FMA built-in functions and code generation --- It has nothing to with SSE5. SSE5 never implies TARGET_FMA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-20 18:52 ---
Since -mfma implies -mavx, we got
[EMAIL PROTECTED] gcc]$ cat f.c
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 -mfma -msse5 f.c -S
-fno-asynchronous-unwind-tables
[EMAIL PROTECTED] gcc]$ cat f.s
.file "f.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
.size foo, .-foo
.comm f,8,8
.ident "GCC: (GNU) 4.4.0 20081120 (experimental) [trunk revision
142045]"
.section.note.GNU-stack,"",@progbits
[EMAIL PROTECTED] gcc]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-20 19:46 --- (In reply to comment #4) > Yes, you are right. "-mfma -msse5" does not make sense. I mistook -mfma for > -mfused-madd and hence the confusion. > > Hence these combinations (1 and 2) does not make sense. > Should we disallow such combinations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-20 21:29 --- We have the same issue with -m3dnow, -m3dnowa and -msse4a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38208] New: [4.4 Regression] gcc.c-torture/compile/20080806-1.c
On Linux/x86, revision 142072 gave: Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ -O3 -fomit-frame-pointer -funroll-loops -w -c -m32 -o 20080806-1.o /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/compile/20080806-1.c (timeout = 300) /tmp/ccuL0Iug.s: Assembler messages:^M /tmp/ccuL0Iug.s:9: Warning: 65544 shortened to 8^M +FAIL: gcc.c-torture/compile/20080806-1.c -O3 -fomit-frame-pointer (test for excess errors) +FAIL: gcc.c-torture/compile/20080806-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) +FAIL: gcc.c-torture/compile/20080806-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) Revision 142058 is OK. -- Summary: [4.4 Regression] gcc.c-torture/compile/20080806-1.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
[Bug target/38208] [4.4 Regression] gcc.c-torture/compile/20080806-1.c
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-21 05:22 --- Revision 142061 is bad. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com, ||ubizjak at gmail dot com Summary|[4.4 Regression] gcc.c- |[4.4 Regression] gcc.c- |torture/compile/20080806-1.c|torture/compile/20080806-1.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
[Bug target/38208] [4.4 Regression] gcc.c-torture/compile/20080806-1.c
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-21 05:39 --- Revision 142061: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01051.html is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-21 13:35 ---
(In reply to comment #8)
> In short, set A={-favx, -ffma}, set B={-f3dnow, -f3dnowa, -fsse4a, -fsse5}.
> Any
It is -mXXX, not -fXXX.
> option combination from both sets should be prohibited.
>
That is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38208] [4.4 Regression] gcc.c-torture/compile/20080806-1.c
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-21 17:04 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-21 17:36 --- __sync_synchronize isn't specified for IA32/Intel64. You can check out Intel Memory Ordering White Paper: www.intel.com/products/processor/manuals/318147.pdf to see what is the most appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-21 17:37 --- The Intel Memory Ordering White Paper is at http://www.intel.com/products/processor/manuals/318147.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-21 23:14 --- GNU assembler supports both popcntl %edx, %eax popcnt %edx, %eax I guess we can just generate popcnt %edx, %eax The same goes for popcnt %cx,%bx popcnt %rcx,%rbx popcntw %cx,%bx popcntq %rcx,%rbx -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-21 23:38 --- I think it is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #11 from hjl dot tools at gmail dot com 2008-11-22 15:09 --- (In reply to comment #10) > We should have -mfma to enable a fused multiply-add instruction that is > available > when enabling either -msse5 or -mavx. -mfma should not itself enable any > of the instruction set enabling features. > > HJ, why did you need -mfma and could not have used -mfused-madd for this? > IMHO -mfma is confusing and should be removed. > Intel FMA is a separate instruction set with its own feature bit in CPUID. Using -mfused-madd -mavx to enable an instruction set doesn't look appropriate to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-22 15:15 --- Richard asked: Why should it (-mavx -msse5) be disallowed if a user asks for it? Do we disallow -msse4a -mssse4? Reply: -msse4a -mssse4 can generate code which runs if you check the feature bit in CPUID before calling an appropriate function. But -mavx -msse5 will generate codes which won't run on any machines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38254] New: [4.4 Regression] Revision 142160 causes PR27908 -O3
On Linux/ia32 SMP, revision 142160 http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01194.html causes FAIL: PR27908 -O3 execution - source compiled test FAIL: PR27908 -O3 -findirect-dispatch execution - source compiled test -- Summary: [4.4 Regression] Revision 142160 causes PR27908 -O3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug tree-optimization/38261] [4.4 Regression] gcc.dg/torture/ipa-pta-1.c & gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-25 16:37 --- Can you use ./contrib/gcc_update to update your gcc source tree so that we can tell which revisions you are using? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug rtl-optimization/38272] New: [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
On Linux/ia32, revision 142207 caused FAIL: libgomp.fortran/threadprivate2.f90 -O1 execution test -- Summary: [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-26 05:38 --- I don't think sibcall work on Darwin. Can you skip them on Darwin? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug libgomp/38270] libgomp test failures due to missing memory barrier
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-26 15:46 --- This may be related to PR 37938. You may try similar fix for Linux/ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38270
[Bug rtl-optimization/38280] New: [4.3 Regression] Revision 142207 breaks 416.gamess/481.wrf/ in SPEC CPU 2006
On Linux/ia32, revision 142207 caused:
gfortran -m32 -c -o mctwo.fppized.o-O2 -mfpmath=sse -mssse3
-ffixed-form mctwo.fppized.f
bad allocation for 2046 and 3100
mctwo.fppized.f: In function 'lh2ddi':
mctwo.fppized.f:3996: internal compiler error: in check_allocation, at
ira.c:1568
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [mctwo.fppized.o] Error 1
Stop make command: Wed Nov 26 18:11:07 2008 (1227694267)
Elapsed time for make command: 00:03:08 (188)
Error with make 'specmake build': check file
'/home/wlin5/cpu2006/benchspec/CPU2006/416.gamess/run/build_base_lnx32.0001/make.err'
gfortran -m32 -c -o module_ra_gfdleta.fppized.o -I. -I./netcdf/include -O2
-mfpmath=sse -mssse3 -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG
-DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4
module_ra_gfdleta.fppized.f90
module_ra_gfdleta.fppized.f90: In function 'spa88':
module_ra_gfdleta.fppized.f90:4713: internal compiler error: in
push_allocno_to_stack, at ira-color.c:882
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [module_ra_gfdleta.fppized.o] Error 1
Stop make command: Wed Nov 26 18:25:42 2008 (1227695142)
Elapsed time for make command: 00:01:33 (93)
Error with make 'specmake build': check file
'/home/wlin5/cpu2006/benchspec/CPU2006/481.wrf/run/build_base_lnx32./make.err'
Gcc is configured with --enable-checking.
--
Summary: [4.3 Regression] Revision 142207 breaks
416.gamess/481.wrf/ in SPEC CPU 2006
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-28 08:42 --- (In reply to comment #4) > 142250 doesn't fix this regression. 416.gamess and 481.wrf still fail. > Revision 142250 is for ira-merge branch. Please try http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01428.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-28 15:20 --- (In reply to comment #6) > Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01428.html fixed this > regression. > 481.wrf also failed on Intel64. Does this patch fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-28 17:49 --- Created an attachment (id=16789) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16789&action=view) A smaller testcase bash-3.2$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -B/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/ -I/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp -I/export/gnu/src/gcc-test/gcc/libgomp/testsuite/.. -march=i486 -fmessage-length=0 -fopenmp -O1 -L/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/.libs -lgomp -L/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -m32-g -Wl,-rpath,/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/.libs /tmp/foo.f90 bash-3.2$ ./a.out Segmentation fault bash-3.2$ ./a.out Aborted bash-3.2$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-28 18:01 ---
Revision 142206 generates:
Reloads for insn # 49
Reload 0: reload_in (SI) = (reg:SI 0 ax)
reload_out (SI) = (reg:SI 1 dx [orig:62 D.2019 ] [62])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:SI 63 [ D.2018 ])
reload_out_reg: (reg:SI 1 dx [orig:62 D.2019 ] [62])
reload_reg_rtx: (reg:SI 1 dx [orig:62 D.2019 ] [62])
Reload 1: reload_in (SI) = (reg:SI 65 [ ivtmp.93 ])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
reload_in_reg: (reg:SI 65 [ ivtmp.93 ])
(insn 49 168 50 3 /tmp/foo.f90:6 (parallel [
(set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mult:SI (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-24
S4 A32])))
(clobber (reg:CC 17 flags))
]) 333 {*mulsi3_1} (nil))
407 movl[EMAIL PROTECTED], %edx
408 movl%gs:(%edx), %eax
409 movl%eax, -60(%ebp)
410 movl%gs:4(%edx), %ecx
411 movl%gs:16(%edx), %edi
412 movl%gs:20(%edx), %ebx
413 movl%gs:28(%edx), %eax
414 movl%gs:32(%edx), %esi
415 movl%esi, -64(%ebp)
416 movl%gs:12(%edx), %esi
417 addl$16, %esp
418 cmpl-64(%ebp), %eax
419 jg .L53
420 movl%eax, -48(%ebp)
421 movl%gs:24(%edx), %eax
422 movl%eax, -56(%ebp)
423 movl%eax, %edx
424 imull -48(%ebp), %edx
Revision 142207:
Reloads for insn # 49
Reload 0: reload_in (SI) = (reg:SI 63 [ D.2018 ])
reload_out (SI) = (reg:SI 1 dx [orig:62 D.2019 ] [62])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:SI 63 [ D.2018 ])
reload_out_reg: (reg:SI 1 dx [orig:62 D.2019 ] [62])
reload_reg_rtx: (reg:SI 1 dx [orig:62 D.2019 ] [62])
Reload 1: reload_in (SI) = (reg:SI 65 [ ivtmp.93 ])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
reload_in_reg: (reg:SI 65 [ ivtmp.93 ])
reload_reg_rtx: (reg:SI 2 cx [80])
(insn 49 168 50 3 /tmp/foo.f90:6 (parallel [
(set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mult:SI (reg:SI 1 dx [orig:62 D.2019 ] [62])
(reg:SI 2 cx [80])))
(clobber (reg:CC 17 flags))
]) 333 {*mulsi3_1} (nil))
Somehow IRA forgot ECX is used in insn 49 and used to load
__threadprivate2_MOD_foo:
407 movl[EMAIL PROTECTED], %ecx
408 movl%gs:(%ecx), %eax
409 movl%eax, -60(%ebp)
410 movl%gs:4(%ecx), %eax
411 movl%gs:16(%ecx), %edi
412 movl%gs:20(%ecx), %ebx
413 movl%gs:28(%ecx), %edx
414 movl%gs:32(%ecx), %esi
415 movl%esi, -64(%ebp)
416 movl%gs:12(%ecx), %esi
417 addl$16, %esp
418 cmpl-64(%ebp), %edx
419 jg .L53
420 movl%edx, -48(%ebp)
421 movl%gs:24(%ecx), %edx
422 movl%edx, -56(%ebp)
423 imull %ecx, %edx <<< ECX doesn't have content at address
-48(%ebp)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-28 19:01 ---
With patch for PR 38280:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01428.html
IRA generates:
Reloads for insn # 151
Reload 0: reload_in (SI) = (mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI
("__threadprivate2_MOD_foo") [flags 0x60] )
] 8)) [0 S4 A8])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI
("__threadprivate2_MOD_foo") [flags 0x60] )
] 8)) [0 S4 A8])
reload_reg_rtx: (reg:SI 2 cx [80])
Reloads for insn # 48
Reload 0: reload_out (SI) = (reg:SI 63 [ D.2018 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg:SI 63 [ D.2018 ])
reload_reg_rtx: (reg:SI 1 dx)
Reload 1: reload_in (SI) = (mem/s/j:SI (plus:SI (plus:SI (unspec:SI [
(const_int
0 [0x0])
] 18)
(reg:SI 1 dx [87]))
(const_int 24 [0x18]))
[0 .stride+0 S4 A32])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/s/j:SI (plus:SI (plus:SI (unspec:SI [
(const_int
0 [0x0])
] 18)
(reg:SI 1 dx [87]))
(const_int 24 [0x18]))
[0 .stride+0 S4 A32])
Reloads for insn # 49
Reload 0: reload_in (SI) = (reg:SI 63 [ D.2018 ])
reload_out (SI) = (reg:SI 1 dx [orig:62 D.2019 ] [62])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:SI 63 [ D.2018 ])
reload_out_reg: (reg:SI 1 dx [orig:62 D.2019 ] [62])
reload_reg_rtx: (reg:SI 1 dx [orig:62 D.2019 ] [62])
Reload 1: reload_in (SI) = (reg:SI 65 [ ivtmp.93 ])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
reload_in_reg: (reg:SI 65 [ ivtmp.93 ])
reload_reg_rtx: (reg:SI 2 cx [80])
...
(insn 151 47 48 3 /tmp/foo.f90:6 (set (reg:SI 1 dx [87])
(reg:SI 2 cx [80])) 47 {*movsi_1} (expr_list:REG_EQUIV (mem/u/c:SI
(const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags
0x60] )
] 8)) [0 S4 A8])
(nil)))
(insn 48 151 167 3 /tmp/foo.f90:6 (set (reg:SI 1 dx)
(mem/s/j:SI (plus:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 18)
(reg:SI 1 dx [87]))
(const_int 24 [0x18])) [0 .stride+0 S4 A32])) 47
{*movsi_1} (nil))
(insn 167 48 168 3 /tmp/foo.f90:6 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -56 [0xffc8])) [0 %sfp+-32 S4 A32])
(reg:SI 1 dx)) 47 {*movsi_1} (nil))
(insn 168 167 49 3 /tmp/foo.f90:6 (set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -56 [0xffc8])) [0 %sfp+-32 S4 A32])) 47
{*movsi_1} (nil))
(insn 49 168 50 3 /tmp/foo.f90:6 (parallel [
(set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mult:SI (reg:SI 1 dx [orig:62 D.2019 ] [62])
(reg:SI 2 cx [80])))
(clobber (reg:CC 17 flags))
]) 333 {*mulsi3_1} (nil))
Something is wrong here. ECX can't be both
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags 0x60] )
and (reg:SI 65 [ ivtmp.93 ]) at the same time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-28 21:11 ---
do_input_reload has
if (optimize && reload_inherited[j] && rl->in
&& MEM_P (rl->in)
&& MEM_P (rl->in_reg)
&& reload_spill_index[j] >= 0
&& TEST_HARD_REG_BIT (reg_reloaded_valid, reload_spill_index[j]))
rl->in = regno_reg_rtx[reg_reloaded_contents[reload_spill_index[j]]];
(gdb) call debug_rtx (insn)
(insn 151 47 48 3 /tmp/foo.f90:6 (set (reg:SI 1 dx [87])
(mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags
0x60] )
] 8)) [0 S4 A8])) 47 {*movsi_1} (expr_list:REG_EQUIV
(mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags
0x60] )
] 8)) [0 S4 A8])
(nil)))
(gdb) p *rl
$6 = {in = 0x77e959c0, out = 0x0, rclass = GENERAL_REGS, inmode = SImode,
outmode = VOIDmode, mode = SImode, nregs = 1, inc = 0,
in_reg = 0x77e959c0, out_reg = 0x0, regno = -1,
reg_rtx = 0x77e819c0, opnum = 1, secondary_in_reload = -1,
secondary_out_reload = -1, secondary_in_icode = CODE_FOR_nothing,
secondary_out_icode = CODE_FOR_nothing, when_needed = RELOAD_FOR_INPUT,
optional = 1, nocombine = 0, secondary_p = 0, nongroup = 0}
(gdb) call debug_rtx (rl->in)
(mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags 0x60]
)
] 8)) [0 S4 A8])
(gdb) call debug_rtx (rl->in_reg)
(mem/u/c:SI (const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags 0x60]
)
] 8)) [0 S4 A8])
(gdb) call debug_rtx (rl->reg_rtx)
(reg:SI 2 cx [80])
(gdb) p reload_spill_index[j]
$7 = 1
(gdb)
It replaces rl->in with an reg_rtx different from rl->reg_rtx and confused
IRA. I don't know if it is a reload or IRA bug. This patch fixes the testcase.
--- reload1.c.foo 2008-11-21 06:06:55.0 -0800
+++ reload1.c 2008-11-28 12:56:54.0 -0800
@@ -7508,6 +7508,8 @@ do_input_reload (struct insn_chain *chai
&& MEM_P (rl->in)
&& MEM_P (rl->in_reg)
&& reload_spill_index[j] >= 0
+ && (rl->reg_rtx == 0
+ || REGNO (rl->reg_rtx) == (unsigned int) reload_spill_index[j])
&& TEST_HARD_REG_BIT (reg_reloaded_valid, reload_spill_index[j]))
rl->in = regno_reg_rtx[reg_reloaded_contents[reload_spill_index[j]]];
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-28 22:28 ---
(In reply to comment #6)
> I think, H.J., that is one more latent bug (i already saw several of them) in
> reload inheritance optimization triggered by IRA which allocates dx for p69
> and
> p87 in subsequent insns
>
> 47:p65<-p69
> 151:p87<-mem[...].
>
With my patch, I got
(insn 47 46 151 3 /tmp/foo.f90:53 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-24 S4 A32])
(reg:SI 1 dx [orig:69 S.10 ] [69])) 47 {*movsi_1} (nil))
(insn 151 47 48 3 /tmp/foo.f90:6 (set (reg:SI 1 dx [87])
(reg:SI 2 cx [80])) 47 {*movsi_1} (expr_list:REG_EQUIV (mem/u/c:SI
(const:SI (unspec:SI [
(symbol_ref:SI ("__threadprivate2_MOD_foo") [flags
0x60] )
] 8)) [0 S4 A8])
(nil)))
(insn 48 151 167 3 /tmp/foo.f90:6 (set (reg:SI 1 dx)
(mem/s/j:SI (plus:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 18)
(reg:SI 1 dx [87]))
(const_int 24 [0x18])) [0 .stride+0 S4 A32])) 47
{*movsi_1} (nil))
(insn 167 48 168 3 /tmp/foo.f90:6 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -56 [0xffc8])) [0 %sfp+-32 S4 A32])
(reg:SI 1 dx)) 47 {*movsi_1} (nil))
(insn 168 167 49 3 /tmp/foo.f90:6 (set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -56 [0xffc8])) [0 %sfp+-32 S4 A32])) 47
{*movsi_1} (nil))
(insn 49 168 50 3 /tmp/foo.f90:6 (parallel [
(set (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mult:SI (reg:SI 1 dx [orig:62 D.2019 ] [62])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-24
S4 A32])))
(clobber (reg:CC 17 flags))
]) 333 {*mulsi3_1} (nil))
DX (r69) is dead at insn 47. DX (r87) at insn 151 is a different register.
It looks OK to me.
> I am not sure that your patch is right but you can commit it for a review to
> get some comments.
>
I will submit it for comments after I finish tests on Linux/ia32, Linux/ia64
and Linux/Intel64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-28 23:26 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01463.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||uweigand at de dot ibm dot ||com, bernds at gcc dot gnu ||dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01463.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:10 --- It isn't totally fixed: FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[t ]*foo FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[t ]*foo I only checked in x86 backend change since no one has reviewed the middle-end change: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01309.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2008- |patches/2008- |11/msg00180.html|11/msg01309.html Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug target/38320] missed movd opcode (32bits mm -> r/m32).
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 00:51 --- You need -mtune=core to generate "movd %xmm0, %rax". Gcc 4.4 works. -- hjl dot tools at gmail dot com changed: What|Removed |Added Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38320
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 15:00 --- Can you try -fno-ira to see if it fixes the problem? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #27 from hjl dot tools at gmail dot com 2008-11-30 20:52 --- (In reply to comment #26) > Resurrecting regmove is not an option. Time is better spent on figuring out > what regmove does, that makes a difference, and see if IRA can be taught to do > the same. > x86 has (define_insn "*movdi_1_rex64" [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym") (match_operand:DI 1 "general_operand" "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r ,m ,C ,*x,*Yi,*x,r ,m ,*Ym,*x"))] "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))" The alternative with * is available for regmove, but not for IRA/reload. I don't know how you can resolve it without a different pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-01 15:35 --- It is caused by either revision 142115 or 142116. Revision 142116: http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00617.html is my first guess. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-01 15:37 ---
-fno-ira also failed:
[EMAIL PROTECTED] rrs]$ ./142116/usr/bin/gcc -fPIC -m32 -S y.c -fno-ira
y.c: In function âapply_charâ:
y.c:11: error: unable to find a register to spill in class âQ_REGSâ
y.c:11: error: this is the insn:
(insn 3 2 7 2 y.c:8 (set (mem/c/i:QI (plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])) [0 data+0 S1 A8])
(subreg:QI (reg:SI 4 si [63]) 0)) 62 {*movqi_1} (expr_list:REG_DEAD
(reg:SI 4 si [63])
(nil)))
y.c:11: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] rrs]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-02 18:46 --- Fixed as of revision 142345. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #15 from hjl dot tools at gmail dot com 2008-12-03 16:50 --- Simulator is fine. AVX executable can only run on simulator. If there is a simulator which can run SSE5 and AVX, we will add a new switch for it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-12-03 16:50:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-03 21:28 ---
(In reply to comment #5)
> (In reply to comment #4)
> > 4.3:
> > -O3 -march=native -funroll-loops -ffast-math ==> 4.376
> > -O3 -march=native -funroll-loops -ffast-math -fschedule-insns ==> 3.372
>
> strangely:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Optimize-Options.html#Optimize-Options
> suggests -fschedule-insns is enabled by default at -O3 ?
>
This may be related to PR 37565. i386.c has
void
optimization_options (int level, int size ATTRIBUTE_UNUSED)
{
/* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
make the problem with not enough registers even worse. */
#ifdef INSN_SCHEDULING
if (level > 1)
flag_schedule_insns = 0;
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/38402] New: Undocumented Yz constraint
x86 has ;; We use the Y prefix to denote any number of conditional register sets: ;; z First SSE register. ;; 2 SSE2 enabled ;; i SSE2 inter-unit moves enabled ;; m MMX inter-unit moves enabled Most of them are internal to gcc. But some instructions use the fixed XMM0 register. We may need the Yz constraint for asm statement. Shouldn't it be documented? -- Summary: Undocumented Yz constraint Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: x86-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
[Bug middle-end/38406] New: [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-aliasing-converted-assigned.c
On Linux/x86-64, revision 142437 gave
Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c
-O2 -Wstrict-aliasing -fstrict-aliasing -S -m32 -o
Wstrict-aliasing-converted-assigned.s(timeout = 300)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c:
In function 'foo':^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c:8:
warning: dereferencing type-punned pointer will break strict-aliasing rules^M
output is:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c:
In function 'foo':^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c:8:
warning: dereferencing type-punned pointer will break strict-aliasing rules^M
PASS: gcc.dg/Wstrict-aliasing-converted-assigned.c (test for warnings, line 8)
FAIL: gcc.dg/Wstrict-aliasing-converted-assigned.c (test for warnings, line 8)
FAIL: gcc.dg/Wstrict-aliasing-converted-assigned.c (test for warnings, line 8)
PASS: gcc.dg/Wstrict-aliasing-converted-assigned.c (test for excess errors)
--
Summary: [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-
aliasing-converted-assigned.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38406
[Bug tree-optimization/38405] Regression (silent failure) handling bitfield in ternary
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-04 20:35 --- It is caused by revision 140288: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01925.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Summary|Regression (silent failure) |[4.4 Regression] (silent |handling bitfield in ternary|failure) handling bitfield ||in ternary Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug libstdc++/38411] New: [4.4 Regression] 22_locale/locale/cons/7.cc execution test
On Linux/ia64, revision 142442 has +FAIL: 22_locale/locale/cons/7.cc execution test +FAIL: 22_locale/numpunct/members/char/2.cc execution test +FAIL: 22_locale/numpunct/members/char/wrapped_env.cc execution test +FAIL: 22_locale/numpunct/members/char/wrapped_locale.cc execution test +FAIL: 22_locale/numpunct/members/wchar_t/2.cc execution test +FAIL: 22_locale/numpunct/members/wchar_t/wrapped_env.cc execution test +FAIL: 22_locale/numpunct/members/wchar_t/wrapped_locale.cc execution test Revision 142437 is OK. -- Summary: [4.4 Regression] 22_locale/locale/cons/7.cc execution test Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] 22_locale/locale/cons/7.cc execution test
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-05 03:08 --- Revision 142439: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00264.html is the possible cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com Summary|[4.4 Regression]|[4.4 Regression] |22_locale/locale/cons/7.cc |22_locale/locale/cons/7.cc |execution test |execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-05 05:25 --- Revision 142439 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression]|[4.4 Regression] Revision |22_locale/locale/cons/7.cc |142439 caused |execution test |22_locale/locale/cons/7.cc ||execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-05 05:34 --- Jakub, there was a similar problem with locale on Linux before. Do you remember it? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug testsuite/38420] New: gcc.target/i386/pr37248-2.c doesn't work on ia32
I got
+FAIL: gcc.target/i386/pr37248-2.c scan-tree-dump optimized "& 3758096391[^
+FAIL: gcc.target/i386/pr37248-3.c scan-tree-dump optimized "& 3766484487[^
on Fedora 9/ia32. I saw
;; Function foo (foo)
Analyzing Edge Insertions.
foo (struct S x)
{
:
return (BIT_FIELD_REF & 0x0e007) == 0x0e007;
}
0x0e007 is the same as 3758096391.
--
Summary: gcc.target/i386/pr37248-2.c doesn't work on ia32
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38420
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-06 07:47 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #5 from hjl dot tools at gmail dot com 2008-12-07 01:11 --- See PR 36792. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-07 01:13 --- Those 3 still aren't fixed: FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 See http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00654.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-07 16:17 --- This bug disappeared between revision 142341 and revision 142508. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-07 17:17 --- It is fixed by revision 142483: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00341.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
--- Comment #11 from hjl dot tools at gmail dot com 2008-12-07 17:39 --- Oops. It is revision 142484: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00340.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug testsuite/38420] gcc.target/i386/pr37248-2.c doesn't work on ia32
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-09 19:33 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38420
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #16 from hjl dot tools at gmail dot com 2008-12-09 21:58 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00585.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg00585.html Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2008-12-03 16:50:15 |2008-12-09 21:58:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-09 22:34 --- Created an attachment (id=16868) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16868&action=view) An updated patch This patch adds some comments to middle-end change. It also replaces _Decimal128 with __m128 in gcc.target/i386/pr37843-3.c so that it can run for all ia32 targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #22 from hjl dot tools at gmail dot com 2008-12-09 22:36 --- (In reply to comment #20) > HJ -- > > As Richard says, you should not have checked in the new testcases without > XFAILs and without having fixed the bug. > > Furthermore, your patch to the middle-end is without explanation. What is the > problem? How does your patch fix the problem? > Hi Mark, Thanks for looking into this. I uploaded a new patch at http://gcc.gnu.org/bugzilla/attachment.cgi?id=16868 with comments to middle-end changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug fortran/37469] invalid GMP usage on gfortran.dg/parameter_array_init_3.f90
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-10 00:13 --- Fixed as of revision 142610. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37469
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-10 05:02 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-10 22:44 --- testsuite/util/regression/rand/assoc/container_rand_regression_test.tcc has value_type v = test_traits::generate_value(m_g, m_m); m_alloc.set_throw_prob(m_tp); const_key_reference r_k = test_traits::extract_key(v); typename cntnr::const_point_iterator found_it = m_p_c->find(r_k); It looks like test_traits::extract_key returns something on stack and r_k references a value on deallocated stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-10 23:07 --- (gdb) f 0 #0 __gnu_pbds::test::detail::container_rand_regression_test<__gnu_pbds::trie<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, (char)97, (char)100, false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::pat_trie_tag, __gnu_pbds::null_trie_node_update, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> > >::insert (this=0x7fffc990) at /export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/util/regression/rand/assoc/container_rand_regression_test.tcc:1086 1086 typename cntnr::const_point_iterator found_it = m_p_c->find(r_k); (gdb) p/x $rsp $14 = 0x7fffc710 (gdb) p/x &r_k $15 = 0x7fffc6c0 (gdb) p &v $16 = ( std::pair *) 0x7fffc750 (gdb) p r_k._M_dataplus._M_p $17 = 0x7e2d28 "dbcabab" (gdb) p v.first._M_dataplus._M_p $18 = 0x7e2d28 "dbcabab" (gdb) r_k references a value on deallocated stack. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|danglin at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/17789] [4.2/4.3/4.4 Regression] Cannot 'make check' inside libstdc++-v3
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-10 23:16 --- (In reply to comment #12) > This one is really old. HJ, do you know if this is still an issue? What > happened with your patch? > I don't know. All my machines have libunwind.so.7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789
[Bug java/37900] [4.4 Regression] StringBuffer_1 failures
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-10 23:20 --- Fixed as of revision 142637. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37900
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #11 from hjl dot tools at gmail dot com 2008-12-11 00:46
---
testsuite/util/regression/trait/assoc/type_trait.hpp has
static const_key_reference
extract_key_imp(pair_type_const_reference r_val)
{ return r_val.first; }
It may create a temporary on stack and return a reference to
the stack temporary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #12 from hjl dot tools at gmail dot com 2008-12-11 01:17
---
This program shows the problem:
[EMAIL PROTECTED] 37144]$ cat x.cc
#include
#include
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 &x) { i = x.i; }
T1&
operator=(T1 & __p)
{
i = __p.i;
return *this;
}
};
struct pair
{
T1 first;
T1 second;
pair() : first(), second() { }
pair(const T1 & __a, const T1 & __b) : first(__a), second(__b) { }
pair&
operator=(pair& __p)
{
first = __p.first;
second = __p.second;
return *this;
}
};
typedef const T1& const_T1_reference;
typedef const pair & const_pair_reference;
const_T1_reference
extract_key_imp(const_pair_reference r_val)
{ return r_val.first; }
const_T1_reference
extract_key_imp(const_T1_reference r_val)
{ return r_val; }
int
main ()
{
T1 t1 (21), t2 (3);
pair p (t1, t2);
const_T1_reference x = extract_key_imp (p);
const_T1_reference y = extract_key_imp (t1);
if (y.i != t1.i)
abort ();
if (&y.i != &t1.i)
abort ();
if (x.i != t1.i)
abort ();
if (&x.i != &t1.i)
{
printf ("&x.i != &t1.i\n");
abort ();
}
return 0;
}
[EMAIL PROTECTED] 37144]$ g++ x.cc
[EMAIL PROTECTED] 37144]$ ./a.out
&x.i != &t1.i
Aborted
[EMAIL PROTECTED] 37144]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-11 15:41
---
(In reply to comment #13)
> Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler
> bug?!?
>
I can't say if C++ standard requires
const_T1_reference
extract_key_imp(const_pair_reference r_val)
{ return r_val.first; }
creates a temporary and returns a reference to it. On the other
hand, I can't tell returning a reference to r_val.first directly will
cause any harm.
FWIW, icc 10.0 also creates a temporary and returns a reference to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #18 from hjl dot tools at gmail dot com 2008-12-11 16:46 --- (In reply to comment #17) > In any case, I don't really understand your snippet: you are comparing &x.i to > &t1.i, but x comes from p, and p *copies* t1 at construction time, in other > terms &p.first.i != &t1.i to begin with. > You are right. My testcase is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #19 from hjl dot tools at gmail dot com 2008-12-11 16:49
---
1081{
1082 m_alloc.set_throw_prob(0);
1083 value_type v = test_traits::generate_value(m_g, m_m);
1084 m_alloc.set_throw_prob(m_tp);
1085 const_key_reference r_k = test_traits::extract_key(v);
1086 typename cntnr::const_point_iterator found_it = m_p_c->find(r_k);
1087 const bool existed = (found_it != m_p_c->end());
1088 const std::pair ins_ret =
m_p_c->insert(v);
1089
1090 if (ins_ret.second)
(gdb) p &r_k
$3 = (const __gnu_pbds::test::basic_type *) 0x7fffc6c0
(gdb) p &v.first
$4 = (const __gnu_pbds::test::basic_type *) 0x7fffc750
(gdb) p $rsp
$5 = (void *) 0x7fffc710
(gdb)
For some reason, test_traits::extract_key doesn't return the reference
to v.first directly and returns a reference to a stack temporary instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug c++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-11 17:20 --- It is fixed by revision 133519: http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00738.html http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01285.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #20 from hjl dot tools at gmail dot com 2008-12-11 17:33 --- We created a temporary because (gdb) bt #0 pair ( this=0x7fffc6c0, _...@0x7fffc750) at /export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:106 #1 0x00420a26 in __gnu_pbds::test::detail::regression_test_type_traits<__gnu_pbds::trie<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, (char)97, (char)100, false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::pat_trie_tag, __gnu_pbds::null_trie_node_update, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> > >::extract_key (r_v...@0x7fffc750) at /export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/util/regression/trait/assoc/type_trait.hpp:82 #2 0x00413cef in __gnu_pbds::test::detail::regression_test_traits<__gnu_pbds::trie<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, (char)97, (char)100, false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::pat_trie_tag, __gnu_pbds::null_trie_node_update, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> > >::extract_key (r_v...@0x7fffc750) at /export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/util/regression/trait/assoc/trait.hpp:164 #3 0x0040cdfb in __gnu_pbds::test::detail::container_rand_regression_test<__gnu_pbds::trie<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, (char)97, ---Type to continue, or q to quit---q Quit (gdb) p &__p $13 = ( const std::pair *) 0x7fffc750 (gdb) p this $14 = ( class std::pair<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type> * const) 0x7fffc6c0 (gdb) Those 2 types are slightly different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-11 17:57
---
Here is a new testcase:
[...@gnu-6 37144]$ cat y.cc
#include
#include
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 &x) { i = x.i; }
T1&
operator=(T1 & __p)
{
i = __p.i;
return *this;
}
};
template
struct pair
{
T1 first;
T2 second;
pair() : first(), second() { }
pair(const T1 & __a, const T1 & __b) : first(__a), second(__b) { }
template
pair(const pair<_U1, _U2>& a) : first(a.first), second(a.second) { }
pair&
operator=(pair& __p)
{
first = __p.first;
second = __p.second;
return *this;
}
};
typedef const T1& const_T1_reference;
#ifdef BAD
typedef const pair& const_pair_reference;
#else
typedef const pair& const_pair_reference;
#endif
const_T1_reference
extract_key_imp(const_pair_reference r_val)
{ return r_val.first; }
const_T1_reference
extract_key_imp(const_T1_reference r_val)
{ return r_val; }
int
main ()
{
T1 t1 (21), t2 (3);
pair p (t1, t2);
const_T1_reference x = extract_key_imp (p);
const_T1_reference y = extract_key_imp (t1);
if (y.i != t1.i)
abort ();
if (&y.i != &t1.i)
abort ();
if (x.i != p.first.i)
abort ();
if (&x.i != &p.first.i)
{
printf ("&x.i != &p.first.i\n");
abort ();
}
return 0;
}
[...@gnu-6 37144]$ g++ y.cc
[...@gnu-6 37144]$ ./a.out
[...@gnu-6 37144]$ g++ y.cc -DBAD
[...@gnu-6 37144]$ ./a.out
&x.i != &p.first.i
Aborted
[...@gnu-6 37144]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #23 from hjl dot tools at gmail dot com 2008-12-11 18:32 --- I am testing this patch: Index: testsuite/util/regression/trait/assoc/type_trait.hpp === --- testsuite/util/regression/trait/assoc/type_trait.hpp(revision 142654) +++ testsuite/util/regression/trait/assoc/type_trait.hpp(working copy) @@ -87,7 +87,7 @@ namespace __gnu_pbds typedef typename basic_type_rebind::const_reference basic_type_const_reference; - typedef typename cntnr::allocator_type::template rebind >::other pair_type_rebind; + typedef typename cntnr::allocator_type::template rebind >::other pair_type_rebind; typedef typename pair_type_rebind::const_reference pair_type_const_reference; template -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #24 from hjl dot tools at gmail dot com 2008-12-11 18:39 --- Created an attachment (id=16886) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16886&action=view) A patch John, can you try this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #26 from hjl dot tools at gmail dot com 2008-12-11 18:49 --- (In reply to comment #22) > Therefore, are you coming to the conclusion that something in the testing > infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code > itself? > include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp has 212 --child_i; 213 _GLIBCXX_DEBUG_ASSERT(child_i > 1); ^^^ When I used -D_GLIBCXX_DEBUG, I got abort for child_i == 1 after my patch is applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #28 from hjl dot tools at gmail dot com 2008-12-11 18:58 --- (In reply to comment #27) > Ah, yes, that, I saw it some time ago. Thus, the patch you and John are > testing > (which makes sense, first blush) avoids failures in normal mode, but in fact > another, latent, issue is uncovered in DEBUG_MODE? > That is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug c++/38490] stack overflow with -O2 for legal C++ code
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:17 --- I can't reproduce it with gcc 4.4 revision 142654 on Linux/x86-64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38490
[Bug libgcj/38006] Incorrect proplist on inherit.png
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:59 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38006
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-12 01:05 ---
(In reply to comment #8)
>
> This is a link where people mention that fact that gcc is behaving
> non-standardly, so people who want to interoperate with gcc better adopt their
> non-standard behavior. How do you like it when MS does that? It seems
> incredibly foolish to me that just because gcc doesn't want to do some trivial
> bit twiddling in the function prologue, you've decided to break the ABI, all
> so
> that you can lose performance when people need ABI compliance, as well as
> making interoperation much harder for everyone.
>
It was a very unfortunate oversight to require 16byte stack alignment
while ABI only specifies 4 byte. This problem has been fixed in gcc
4.4 and above. You can safely use -mpreferred-stack-boundary=2 with
gcc 4.4 and all stack variables will be properly aligned. However,
we can't change the default back to 4 byte since it will break the
existing libraries/applications which expect 16byte aligned incoming
stack.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC| |hjl dot tools at gmail dot
||com
OtherBugsDependingO||33721
nThis||
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38402] Undocumented Yz constraint
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 14:36 --- Fixed -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
[Bug regression/38505] [4.4 Regression] Revision142061 may cause __builtin_memcpy to segfault
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-12 17:11 --- It is very likely caused by revision 142061: http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00562.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-12 17:11:04 date|| Summary|internal compiler error:|[4.4 Regression] |Segmentation fault |Revision142061 may cause ||__builtin_memcpy to segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug regression/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-12 17:20 --- Revision 142061 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression]|[4.4 Regression] Revision |Revision142061 may cause|142061 caused ICE on |__builtin_memcpy to segfault|__builtin_memcpy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug middle-end/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 17:22 --- It happens on ia32, x86-64 and ia64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|regression |middle-end 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=38505
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #31 from hjl dot tools at gmail dot com 2008-12-13 02:02 --- Created an attachment (id=16902) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902&action=view) A patch to add -D_GLIBCXX_DEBUG to dg-options I am testing this patch to see if it can trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
