[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

2020-03-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

2020-03-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980 --- Comment #4 from H.J. Lu --- This linker patch: iff --git a/ld/plugin.c b/ld/plugin.c index 47c053e5a0a..5960df65243 100644 --- a/ld/plugin.c +++ b/ld/plugin.c @@ -1242,6 +1242,8 @@ plugin_object_p (bfd *ibfd) ibfd->plugin_format = bfd

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

2020-03-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also|

[Bug lto/93966] [9/10 Regression] -fcf-protection -flto -g don't work togeter

2020-03-02 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93966 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug lto/93966] [9/10 Regression] -fcf-protection -flto -g don't work togeter

2020-03-02 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93966 --- Comment #8 from H.J. Lu --- (In reply to rguent...@suse.de from comment #7) > > > > It is because GCC 8 doesn't have early LTO debug. > > It does but section copying has been made more explicit about notes > only in GCC 9 it seems. GCC 8 h

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

2020-03-04 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 --- Comment #13 from H.J. Lu --- (In reply to H.J. Lu from comment #12) > Fixed for GCC 10, GCC 9.3 and GCC 8.4. The fix is in GCC 8.5, not GCC 8.4.

[Bug lto/93966] [9/10 Regression] -fcf-protection -flto -g don't work togeter

2020-03-04 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93966 H.J. Lu changed: What|Removed |Added Target Milestone|9.3 |8.5 --- Comment #10 from H.J. Lu --- Also fix

[Bug target/56200] queens benchmark is faster with -O0 than with any other optimization level

2013-02-05 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200 H.J. Lu changed: What|Removed |Added CC||areg.melikadamyan at gmail

[Bug rtl-optimization/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2013-02-07 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2012-04-05 00:0

[Bug sanitizer/56245] New: -fsanitize=address miscompiles GCC

2013-02-07 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 Bug #: 56245 Summary: -fsanitize=address miscompiles GCC Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Prio

[Bug sanitizer/56245] -fsanitize=address miscompiles GCC

2013-02-07 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 --- Comment #1 from H.J. Lu 2013-02-07 23:00:53 UTC --- It is caused by revision 195404: http://gcc.gnu.org/ml/gcc-cvs/2013-01/msg00659.html

[Bug sanitizer/56245] -fsanitize=address miscompiles GCC

2013-02-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug sanitizer/56245] -fsanitize=address miscompiles GCC

2013-02-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|NEW Component|other

[Bug bootstrap/56327] New: [4.8 Regression] Revision 196009 breaks bootstrap on x32

2013-02-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56327 Bug #: 56327 Summary: [4.8 Regression] Revision 196009 breaks bootstrap on x32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

2013-02-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #8 from H.J. Lu 2013-02-14 18:47:12 UTC --- -O3 and -fprofile-use turn on optimizations like -funroll-loops which trigger false positive warnings.

[Bug libgcj/56353] New: libgcj should be listed on command line for libjava.jni/invocation/PR16923.c

2013-02-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56353 Bug #: 56353 Summary: libgcj should be listed on command line for libjava.jni/invocation/PR16923.c Classification: Unclassified Product: gcc Version: 4.8.0

[Bug libgcj/56353] libgcj should be listed on command line for libjava.jni/invocation/PR16923.c

2013-02-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56353 --- Comment #2 from H.J. Lu 2013-02-15 23:59:30 UTC --- The command line is /export/gnu/import/git/gcc-test-intel64/bld/gcc/xgcc -B/export/gnu/import/git/gcc-test-intel64/bld/gcc/ /export/gnu/import/git/gcc-test-intel64/src-trunk/libjav

[Bug go/56431] New: -lpthread should be added to -lgo

2013-02-22 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 Bug #: 56431 Summary: -lpthread should be added to -lgo Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Prior

[Bug go/56431] -lpthread should be added to -lgo

2013-02-27 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #2 from H.J. Lu 2013-02-27 16:59:17 UTC --- The new GNU ld is complaining about an undefined weak reference because it sees libpthread.so from DT_NEEDED in libgo.so. The old GNU ld just silently adds libpthread.so from DT_NEEDE

[Bug go/56431] -lpthread should be added to -lgo

2013-02-27 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #4 from H.J. Lu 2013-02-27 19:36:07 UTC --- (In reply to comment #3) > Object OBJ has a weak reference to SYM. > > OBJ is linked against shared library S1. S1 does not define SYM. > > S1 happens to be linked against share

[Bug go/56431] -lpthread should be added to -lgo

2013-02-27 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #6 from H.J. Lu 2013-02-27 21:20:53 UTC --- (In reply to comment #5) > I see. Interesting. I wonder if that is a bug in gold. I wonder what other I think this is related to the gold bug: http://sourceware.org/bugzilla/s

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

2013-03-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 --- Comment #4 from H.J. Lu 2013-03-08 17:21:18 UTC --- The caller info is lost by (gdb) bt #0 init_cumulative_args (cum=0x7fffc3f0, fntype=0x71472e70, libname=0x0, fndecl=0x0, caller=1) at /export/gnu/import/git/gcc-

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

2013-03-11 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 --- Comment #6 from H.J. Lu 2013-03-11 19:34:29 UTC --- Created attachment 29645 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29645 A patch This patch adds expand_args to track library calls to expend arguments. We add vzeroupp

[Bug target/56603] New: Different _MM_HINT_TX values from ICC

2013-03-12 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56603 Bug #: 56603 Summary: Different _MM_HINT_TX values from ICC Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal P

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

2013-03-12 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 H.J. Lu changed: What|Removed |Added Attachment #29645|0 |1 is obsolete|

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

2013-03-25 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

2013-03-25 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 --- Comment #3 from H.J. Lu 2013-03-25 22:07:18 UTC --- (In reply to comment #2) > I'm a bit skeptical of that. Glibc malloc alignment is 2 * sizeof(void*), and > void* in X32 is 32 bits. Unless X32 code uses the x86_64 libc, I am confus

[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)

2013-03-29 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56781 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

2013-04-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 H.J. Lu changed: What|Removed |Added Known to fail|| --- Comment #6 from H.J. Lu 2013-04

[Bug bootstrap/57077] New: [4.9 Regression] LTO bootstrap failure with profiledbootstrap

2013-04-25 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57077 Bug #: 57077 Summary: [4.9 Regression] LTO bootstrap failure with profiledbootstrap Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFI

[Bug target/46250] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -fPIC -mcmodel=large and __thread variable

2013-04-29 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46250 --- Comment #5 from H.J. Lu 2013-04-29 17:09:22 UTC --- TLS ABI only covers the small model. There is no demand to extend TLS ABI to support medium/large models.

[Bug bootstrap/57077] [4.9 Regression] LTO bootstrap failure with profiledbootstrap

2013-04-29 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57077 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug rtl-optimization/57193] [4.5/4.6/4.7/4.8/4.9 Regression] suboptimal register allocation for SSE registers

2013-05-07 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57193 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com

[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures

2012-08-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libstdc++/54204] New: Wrong baseline_symbols.txt picked for x32

2012-08-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54204 Bug #: 54204 Summary: Wrong baseline_symbols.txt picked for x32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority

[Bug libstdc++/54204] Wrong baseline_symbols.txt picked for x32

2012-08-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54204 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libstdc++/52449] check-abi picks up wrong baseline_symbols.txt with --with-cpu=default32 configs

2012-08-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52449 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from

[Bug libstdc++/52449] check-abi picks up wrong baseline_symbols.txt with --with-cpu=default32 configs

2012-08-08 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52449 H.J. Lu changed: What|Removed |Added Target|powerpc64-*-linux |powerpc64-*-linux,x86_64-*l |

[Bug bootstrap/54209] New: [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 Bug #: 54209 Summary: [4.8 Regression] Failed to build gcc for Android/x86 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p |

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu changed: What|Removed |Added CC||pavel.v.chupin at gmail dot |

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 --- Comment #5 from H.J. Lu 2012-08-09 19:08:49 UTC --- (In reply to comment #4) > > > > Why isn't link.h in AOSP Bionic C library? > > ARM doesn't use eh_frame, so there is no need to create link.h at the > beginning for the Android project,

[Bug middle-end/54215] New: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build

2012-08-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54215 Bug #: 54215 Summary: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED

[Bug middle-end/54228] New: [4.6 Regression] 22_locale/num_put/put/char/9780-2.cc

2012-08-11 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54228 Bug #: 54228 Summary: [4.6 Regression] 22_locale/num_put/put/char/9780-2.cc Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal

[Bug lto/54229] New: [4.8 Regression] LTO is broken

2012-08-11 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54229 Bug #: 54229 Summary: [4.8 Regression] LTO is broken Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-11 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #15 from H.J. Lu 2012-08-11 14:37:30 UTC --- Do we have a run-time testcase?

[Bug libstdc++/54228] [4.6 Regression] 22_locale/num_put/put/char/9780-2.cc

2012-08-11 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54228 H.J. Lu changed: What|Removed |Added Component|middle-end |libstdc++ --- Comment #1 from H.J. Lu 2012-08-

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-12 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #20 from H.J. Lu 2012-08-12 19:50:08 UTC --- (In reply to comment #19) > (In reply to comment #15) > > Do we have a run-time testcase? > > I attached three compile-time test cases that check if the generated RTL > refers > to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-12 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #27 from H

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-12 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #29 from H.J. Lu 2012-08-13 02:17:28 UTC --- (In reply to comment #28) > (In reply to comment #27) > > Please try this patch: > > > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > > index c4d85b7..6c4c2ce 100644 > >

[Bug middle-end/54242] New: [4.8 Regression] Testsuite failures

2012-08-13 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54242 Bug #: 54242 Summary: [4.8 Regression] Testsuite failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/53836] [4.7/4.8 Regression] ICE: unexpected expression of kind template_parm_index

2012-08-13 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836 H.J. Lu changed: What|Removed |Added CC||jason at redhat dot com --- Comment #4 from H.J

[Bug target/54246] Bytemark FOURIER 54% slower in X32 chroot

2012-08-13 Thread hjl.tools at gmail dot com
||2012-08-14 CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com Ever Confirmed|0 |1 --- Comment #1

[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin

2012-08-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 --- Comment #1 from H.J. Lu 2012-08-14 15:57:34 UTC --- The problem is -m64 overrides -mx32.

[Bug c/54037] Warn pointer to signed integer cast for ilp32

2012-08-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54037 H.J. Lu changed: What|Removed |Added Attachment #27836|0 |1 is obsolete|

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #33 from H.J. Lu 2012-08-14 23:43:24 UTC --- We must make sure that --- union S160 { long double a; }; extern union S160 check160 (void); extern void checkx160 (union S160); void test160 (void) { checkx160 (check160 ()); } --- c

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-14 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #36 from H.J. Lu 2012-08-15 01:23:54 UTC --- (In reply to comment #35) > Note that for the test case in comment #34 (and comment #9) to fail that the > MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal checking > ha

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #42 from H.J. Lu 2012-08-15 13:58:16 UTC --- (In reply to comment #37) > (In reply to comment #36) > > (In reply to comment #35) > > > Note that for the test case in comment #34 (and comment #9) to fail that > > > the > > > MAX_FIXED

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #43 from H.J. Lu 2012-08-15 14:21:05 UTC --- The problem is we return a TI union in XF register because the x86-64 psABI.

[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))

2012-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #5 from H.J. Lu 2012-08-15 14:34:53 UTC --- (In reply to comment #4) > I actually wonder how could target attribute work the way it is implemented > right now so far. It works by miracle. See PR 37565.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #46 from H.J. Lu 2012-08-15 16:01:15 UTC --- (In reply to comment #45) > Changing this is generally very risky for ABI incompatibilities, many targets > base some of the decisions how to pass parameters or return values on the type >

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #47 from H.J. Lu 2012-08-16 00:00:25 UTC --- Created attachment 28028 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28028 A patch Here is a patch which should be applied on top of http://gcc.gnu.org/ml/gcc-patches/2012-08/msg0

[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391

2012-08-16 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839 --- Comment #2 from H.J. Lu 2012-08-16 13:46:24 UTC --- It was triggered by revision 176549: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00816.html But ICE is always there.

[Bug target/52495] rs6000.c fails to (cross-) build: "implicit declaration of function ‘ASM_WEAKEN_DECL’"

2012-08-16 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52495 --- Comment #2 from H.J. Lu 2012-08-17 01:13:29 UTC --- I also run into this. The bug is in rs6000.h: #ifdef HAVE_GAS_WEAK #define RS6000_WEAK 1 #else #define RS6000_WEAK 0 #endif #if RS6000_WEAK /* Used in lieu of ASM_WEAKEN_LABEL. */ #defin

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

2012-08-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

2012-08-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug middle-end/28831] [4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

2012-08-18 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com

[Bug middle-end/28831] [4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

2012-08-18 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831 --- Comment #20 from H.J. Lu 2012-08-18 16:10:43 UTC --- With -maccumulate-outgoing-args, GCC 3.4 will also make a copy.

[Bug middle-end/54315] New: Unnecessary copy of return value

2012-08-18 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315 Bug #: 54315 Summary: Unnecessary copy of return value Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug middle-end/54315] Unnecessary copy of return value

2012-08-18 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315 --- Comment #1 from H.J. Lu 2012-08-18 17:42:58 UTC --- -m32 also causes extra copy: [hjl@gnu-6 pr54315]$ gcc -S -O2 -m32 y.i [hjl@gnu-6 pr54315]$ cat y.s .file"y.i" .text .p2align 4,,15 .globltest160 .typetest160

[Bug middle-end/54315] Unnecessary copy of return value

2012-08-18 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315 --- Comment #2 from H.J. Lu 2012-08-18 17:45:43 UTC --- The difference between -m32 and -m64 is - struct S160 D.1692; + struct S160 D.1719; ;; basic block 2, loop depth 0 ;;pred: ENTRY - D.1692 = check160 (); [return slot optim

[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/54327] [4.8 Regression] Segmentation fault in init_ggc

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc

2012-08-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|c

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 --- Comment #4 from H.J. Lu 2012-08-20 16:27:26 UTC --- (In reply to comment #3) > Looks good to me... HJ? Looks good to me too.

[Bug fortran/54332] New: [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 Bug #: 54332 Summary: [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONF

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added CC||areg.melikadamyan at gmail |

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #2 from H.J. Lu 2012-08-20 21:18:00 UTC --- Revision 190401 takes 512MB virtual memory to compile module_domain.fppized.f90 while revision 190402 takes 10GB. This is a 20x increase.

[Bug driver/54335] New: -dm doesn't work

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54335 Bug #: 54335 Summary: -dm doesn't work Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever Confirmed|1

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-20 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #4 from H.J. Lu 2012-08-21 02:59:15 UTC --- It was introduced between revision 189101 and revision 189664 on cxx-conversion branch. Unfortunately, since branch was broken between those 2 revisions, I can't bisect further.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #7 from H.J. Lu 2012-08-21 13:58:05 UTC --- (In reply to comment #6) > > If it's related to the hash table, then comparing rev 188059 vs rev > 188129 may show the regression. > Neither rev 188059 nor rev 188129 will build: ../../

[Bug target/54347] New: REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used in i386

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54347 Bug #: 54347 Summary: REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used in i386 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #9 from H.J. Lu 2012-08-21 16:20:37 UTC --- Revision 188059 is bad: f951: out of memory allocating 36872 bytes after a total of 583266304 bytes

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2012-08-20 00:00:00

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #13 from H.J. Lu 2012-08-21 17:10:09 UTC --- It can be reproduced with -frecord-marker=4 -O -funswitch-loops.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #14 from H.J. Lu 2012-08-21 17:41:10 UTC --- It failed even with diff --git a/gcc/tree-ssa-loop.c b/gcc/tree-ssa-loop.c index 3d650bf..30ac4b5 100644 --- a/gcc/tree-ssa-loop.c +++ b/gcc/tree-ssa-loop.c @@ -149,7 +149,7 @@ tree_ssa_lo

[Bug c++/54341] [4.7/4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54341 H.J. Lu changed: What|Removed |Added CC||jason at redhat dot com Target Milestone|---

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #15 from H.J. Lu 2012-08-21 17:57:59 UTC --- It failed with diff --git a/gcc/passes.c b/gcc/passes.c index b6fe18e..10174c4 100644 --- a/gcc/passes.c +++ b/gcc/passes.c @@ -1449,7 +1449,6 @@ init_optimization_passes (void) NEXT_

[Bug driver/54335] -dm doesn't work

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54335 --- Comment #2 from H.J. Lu 2012-08-21 18:03:17 UTC --- There are: opts.c:typedef char *char_p; /* For DEF_VEC_P. */ opts.c:DEF_VEC_P(char_p); opts.c:DEF_VEC_ALLOC_P(char_p,heap); opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #16 from H.J. Lu 2012-08-21 18:08:49 UTC --- There are: opts.c:typedef char *char_p; /* For DEF_VEC_P. */ opts.c:DEF_VEC_P(char_p); opts.c:DEF_VEC_ALLOC_P(char_p,heap); opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #19 from H.J. Lu 2012-08-21 18:54:45 UTC --- (In reply to comment #15) > It failed with > > diff --git a/gcc/passes.c b/gcc/passes.c > index b6fe18e..10174c4 100644 > --- a/gcc/passes.c > +++ b/gcc/passes.c > @@ -1449,7 +1449,6 @@ in

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #22 from H.J. Lu 2012-08-21 19:27:50 UTC --- This seems to work: diff --git a/gcc/df-scan.c b/gcc/df-scan.c index 35100d1..39f444f 100644 --- a/gcc/df-scan.c +++ b/gcc/df-scan.c @@ -4392,6 +4392,7 @@ df_bb_verify (basic_block bb)

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #24 from H.J. Lu 2012-08-21 19:53:14 UTC --- (In reply to comment #23) > > The problem with this is that you are switching a stack vec into a heap > vec. This may not always be what the caller wanted. My patch just restores the ol

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

2012-08-21 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug target/54347] REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used with XFmode

2012-08-22 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54347 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu 2012-08-22 1

[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument

2012-08-22 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument

2012-08-22 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 --- Comment #6 from H.J. Lu 2012-08-22 22:10:51 UTC --- This may be related to PR 54315.

<    1   2   3   4   5   6   7   8   9   10   >