[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #3 from Markus Trippelsdorf --- (In reply to Kostya Serebryany from comment #2) > Please symbolize the output. How? asan_symbolize.py doesn't parse this output. If I run addr2line on the first few symbols by hand I get: Stack: sigaction.c:? gsignal+0x0034 :? abort+0x0147 :? /home/markus/gcc/libgcc/unwind-pe.h:257 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:415 dl_iterate_phdr+0x0134 :? _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 /home/markus/gcc/libgcc/unwind-dw2.c:1182 _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 crtstuff.c:? crtstuff.c:? __asan_report_error+0x083A ??:? __interceptor_setlocale+0x0155 ??:? > Also, does this happen with the clang version of AddressSanitizer? Clang trunk cannot build Firefox with -fsanitize=address, because I get asan related linker errors.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #4 from Andrew Pinski --- (In reply to Markus Trippelsdorf from comment #3) > (In reply to Kostya Serebryany from comment #2) > > Please symbolize the output. > > How? > asan_symbolize.py doesn't parse this output. > If I run addr2line on the first few symbols by hand I get: Update the version of addr2line you are using first. Basically a newer addr2line will understand dwarf4 that GCC outputs.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #5 from Kostya Serebryany --- > Clang trunk cannot build Firefox with -fsanitize=address, because I get > asan related linker errors. To the best of my knowledge, firefox is routinely built by several different teams using clang+asan. Please report a separate bug at code.google.com/p/address-sanitizer/
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #6 from Kostya Serebryany --- > _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 > /home/markus/gcc/libgcc/unwind-dw2.c:1182 > _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 Interesting. asan detects a bug and starts reporting it, then if crashes inside the slow unwinder. Try the fast unwinder? ASAN_OPTIONS=fast_unwind_on_fatal=1
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #7 from Markus Trippelsdorf --- (In reply to Kostya Serebryany from comment #5) > > Clang trunk cannot build Firefox with -fsanitize=address, because I get > > asan related linker errors. > To the best of my knowledge, firefox is routinely built by several different > teams using clang+asan. > Please report a separate bug at code.google.com/p/address-sanitizer/ (In reply to Andrew Pinski from comment #4) > (In reply to Markus Trippelsdorf from comment #3) > > (In reply to Kostya Serebryany from comment #2) > > > Please symbolize the output. > > > > How? > > asan_symbolize.py doesn't parse this output. > > If I run addr2line on the first few symbols by hand I get: > > Update the version of addr2line you are using first. Basically a newer > addr2line will understand dwarf4 that GCC outputs. I use the latest version, but gcc and glibc was build without debugging information.
[Bug middle-end/60546] [4.8 and 4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #1 from Andrew Pinski --- -fno-strict-aliasing fixes the issue So there might be an aliasing issue in the code.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #8 from Markus Trippelsdorf --- (In reply to Kostya Serebryany from comment #5) > > Clang trunk cannot build Firefox with -fsanitize=address, because I get > > asan related linker errors. > To the best of my knowledge, firefox is routinely built by several different > teams using clang+asan. > Please report a separate bug at code.google.com/p/address-sanitizer/ Sorry, but I don't have a google account and refuse to create one.
[Bug bootstrap/60050] Build failure on MinGW64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Kai Tietz --- This bug was fixed on mingw-w64's side. It isn't a gcc-bug. Btw gcc 4.6 isn't under maintenance anymore.
[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing ".../xgcc -dumpspecs"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz --- Hmm, can't reproduce it. I will do today some additional tests for it.
[Bug other/60547] New: libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60547 Bug ID: 60547 Summary: libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ? Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Static analyser cppcheck says 1. [libcilkrts/runtime/record-replay.cpp:561]: (warning) scanf without field width limits can crash with huge input data. Source code is fret = fscanf(f, "%s %s %d %d\n", ped_type, ped_str, &i1, &i2); but char ped_type[PED_TYPE_SIZE]; It might be worthwhile to limit the %s to PED_TYPE_SIZE 2. [libcilkrts/runtime/record-replay.cpp:569]: (warning) scanf without field width limits can crash with huge input data. Duplicate.
[Bug other/60548] New: [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60548 Bug ID: 60548 Summary: [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Source code is while (fscanf (fp_in, "%s %d %d %d %d %d\n", fname_in, &total, &verified, ®set, ®pair, &unused) != EOF) but char fname_in[1024]; Maybe better code might be while (fscanf (fp_in, "%1024s %d %d %d %d %d\n", fname_in, &total, &verified, ®set, ®pair, &unused) != EOF)
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #9 from Markus Trippelsdorf --- (In reply to Kostya Serebryany from comment #6) > > _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 > > /home/markus/gcc/libgcc/unwind-dw2.c:1182 > > _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 > > Interesting. asan detects a bug and starts reporting it, then if crashes > inside the slow unwinder. > Try the fast unwinder? > ASAN_OPTIONS=fast_unwind_on_fatal=1 Thanks, this works fine: markus@x4 tmp % ASAN_OPTIONS=fast_unwind_on_fatal=1 /var/tmp/moz-build-dir/dist/bin/firefox = ==10632==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 READ of size 2 at 0x6021ec50 thread T0 #0 0x7f3e30645dbc in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3cdbc) #1 0x7f3e1d643400 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x20400) #2 0x7f3e1d637472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) 0x6021ec50 is located 0 bytes inside of 12-byte region [0x6021ec50,0x6021ec5c) freed by thread T0 here: #0 0x7f3e30667d37 in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x5ed37) #1 0x7f3e2fc0b6c2 in setlocale (/lib/libc.so.6+0x2a6c2) #2 0x7f3e30645cdb in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3ccdb) #3 0x7f3e1d641dc2 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x1edc2) #4 0x7f3e1d637472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) previously allocated by thread T0 here: #0 0x7f3e30667f6f in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x5ef6f) #1 0x7f3e2fc64639 in __GI___strdup (/lib/libc.so.6+0x83639) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 setlocale Shadow bytes around the buggy address: 0x0c047fffbd30: fa fa 00 00 fa fa 00 00 fa fa fd fd fa fa 00 00 0x0c047fffbd40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fd 0x0c047fffbd50: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 fa 0x0c047fffbd60: fa fa 00 00 fa fa 06 fa fa fa 00 04 fa fa fd fd 0x0c047fffbd70: fa fa 00 04 fa fa 00 04 fa fa fd fd fa fa 00 04 =>0x0c047fffbd80: fa fa 00 04 fa fa fd fd fa fa[fd]fd fa fa 00 04 0x0c047fffbd90: fa fa fd fd fa fa 00 04 fa fa 00 04 fa fa fd fd 0x0c047fffbda0: fa fa 00 04 fa fa 00 04 fa fa fd fd fa fa 00 04 0x0c047fffbdb0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fffbdc0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fffbdd0: fa fa 00 fa fa fa 00 07 fa fa 00 fa fa fa fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==10632==ABORTING The strange thing is that I cannot reproduce the issue above anymore. Without ASAN_OPTIONS=fast_unwind_on_fatal=1 I now get: = ==10801==ERROR: AddressSanitizer: heap-use-after-free on address 0x6021ec50 at pc 0x7fc97d727dbd bp 0x7fff3cd0d460 sp 0x7fff3cd0d438 READ of size 2 at 0x6021ec50 thread T0 #0 0x7fc97d727dbc in setlocale (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1+0x3cdbc) #1 0x7fc96a725400 in qtSettingsInit (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x20400) #2 0x7fc96a719472 in qtcurve_rc_style_init (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x14472) #3 0x7fc97040da17 in g_type_create_instance (/usr/lib/libgobject-2.0.so.0+0x31a17) #4 0x7fc9703f1562 in g_object_new_internal (/usr/lib/libgobject-2.0.so.0+0x15562) #5 0x7fc9703f327c in g_object_newv (/usr/lib/libgobject-2.0.so.0+0x1727c) #6 0x7fc9703f3a0b in g_object_new (/usr/lib/libgobject-2.0.so.0+0x17a0b) #7 0x7fc96a720afb in theme_create_rc_style (/usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so+0x1bafb) #8 0x7fc96ffe6b1d in gtk_rc_parse_any (/usr/lib/libgtk-x11-2.0.so.0+0x17cb1d) #9 0x7fc96ffe731c in gtk_rc_context_parse_one_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d31c) #10 0x7fc96ffe7584 in gtk_rc_context_parse_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d584) #11 0x7fc96ffe6246 in gtk_rc_parse_any (/usr/lib/libgtk-x11-2.0.so.0+0x17c246) #12 0x7fc96ffe731c in gtk_rc_context_parse_one_file (/usr/lib/libgtk-x11-2.0.so.0+0x17d31c) #13 0x7fc96ffe7584 in gtk_rc_context_parse_file (/usr/li
[Bug other/60548] [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60548 David Binderman changed: What|Removed |Added Severity|normal |minor
[Bug other/60547] libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60547 David Binderman changed: What|Removed |Added Severity|normal |minor
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed. expand_omp_simd has for this case:
6837 /* If not -fno-tree-loop-vectorize, hint that we want to vectorize
6838 the loop. */
6839 if ((flag_tree_loop_vectorize
6840|| (!global_options_set.x_flag_tree_loop_vectorize
6841&& !global_options_set.x_flag_tree_vectorize))
6842 && loop->safelen > 1)
6843 {
6844 loop->force_vect = true;
6845 cfun->has_force_vect_loops = true;
6846 }
but gate_tree_loop_vectorize isn't called at all, because gate_tree_loop
returns false. So maybe:
--- gcc/tree-ssa-loop.c
+++ gcc/tree-ssa-loop.c
@@ -47,7 +47,7 @@ along with GCC; see the file COPYING3. If not see
static bool
gate_tree_loop (void)
{
- return flag_tree_loop_optimize != 0;
+ return flag_tree_loop_optimize != 0 || cfun->has_force_vect_loops;
}
namespace {
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516
--- Comment #7 from Kai Tietz ---
Thanks for the patch. I am about to do a full-regression test for it. This
will take some time.
Quick test has shown that issue isn't 'thiscall' specific at all. stdcall, and
fastcall calling-convention do have the same issues. So I would suggest to add
these two testcases to the patch, too.
/* PR target/60516 */
/* { dg-do compile } */
/* { dg-options "-O2" } */
struct S { char c[65536]; };
__attribute__((ms_abi, thiscall)) void
foo (void *x, struct S y)
{
}
/* PR target/60516 */
/* { dg-do compile } */
/* { dg-options "-O2" } */
struct S { char c[65536]; };
__attribute__((ms_abi, fastcall)) void
foo (void *x, void *xx, struct S y)
{
}
[Bug other/60548] [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60548 --- Comment #1 from Andrew Pinski --- This file is never compiled so it is very minor.
[Bug other/60547] libcilkrts/runtime/record-replay.cpp: 2 * possible problems in calls to scanf ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60547 --- Comment #1 from Andrew Pinski --- This code is never used unless you turn on the code manually.
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #26 from rguenther at suse dot de --- On Sat, 15 Mar 2014, linux at carewolf dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 > > --- Comment #25 from Allan Jensen --- > Will it be backported to 4.8? Yes.
[Bug middle-end/60546] [4.8 and 4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #2 from Andrew Pinski --- But it might be related to bug 60429.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #10 from Kostya Serebryany --- > ==10632==ERROR: AddressSanitizer: heap-use-after-free on address > 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 > READ of size 2 at 0x6021ec50 thread T0 > #0 0x7f3e30645dbc in setlocale So, sounds like a real use-after-free in firefox
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #11 from Kostya Serebryany --- > Sorry, but I don't have a google account and refuse to create one. You can login to our bug tracker with any existing e-mail, or you can contact us via address-saniti...@googlegroups.com or you can file a bug using the llvm bug tracker
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #7 from Mikael Pettersson --- (In reply to Bernd Edlinger from comment #6) > that would be r208419 and r208150 Reverting r208150 + r208419 and rebuilding from scratch eliminated all acats regressions.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #12 from Markus Trippelsdorf --- (In reply to Kostya Serebryany from comment #11) > > Sorry, but I don't have a google account and refuse to create one. > You can login to our bug tracker with any existing e-mail, > or you can contact us via address-saniti...@googlegroups.com > or you can file a bug using the llvm bug tracker OK, sorry. I didn't know that. (In reply to Kostya Serebryany from comment #10) > > ==10632==ERROR: AddressSanitizer: heap-use-after-free on address > > 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 > > READ of size 2 at 0x6021ec50 thread T0 > > #0 0x7f3e30645dbc in setlocale > > So, sounds like a real use-after-free in firefox No. It's a bug in libqtcurve (a QT/GTK theme). When I switch to a different theme I hit the real Firefox bug that I was after: https://bugzilla.mozilla.org/show_bug.cgi?id=983995 What about the "allocating memory until the OOM killer hits" issue? Do you think this is an asan bug?
[Bug fortran/60549] New: [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Bug ID: 60549 Summary: [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Follow up to PR 55207 and to r208590; see http://gcc.gnu.org/ml/fortran/2014-03/msg00108.html Since r208590, the execution time of Polyhedron's fatigue.f90 doubled from ~1.4s to ~2.9s. I have not closely looked at fatigue.f90, however, I believe that this is due to the following: Fatigue's main program has internal procedures, which access variables defined in the main program. As static variables usually global variables, GCC does not a good job at optimizing static variables - even if it could in case they are defined within one function only. Possible solution: Small variables [of the MAIN program only!] should be (again) created on the stack - possibly even (new!) when they do have an explicitly set SAVE attribute. I think that's especially relevant for integer and real variables. I think it is impossible to see the difference from within the program; the only exception are __attribute__((destructor)) - thus, if one wants to play safe is to exclude those with TARGET attribute.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Tobias Burnus changed: What|Removed |Added CC||dominiq at lps dot ens.fr, ||janus at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #13 from Kostya Serebryany --- > What about the "allocating memory until the OOM killer hits" issue? > Do you think this is an asan bug? Dunno. File a bug with more details if you think it's a bug. I guess you can close this one.
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- No, instead we should treat !flag_tree_loop_optimize the same as we treat explicit -fno-tree-vectorize in omp-low.c (there are two spots).
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #7 from Oleg Endo --- (In reply to Rich Felker from comment #6) > On Sun, Mar 16, 2014 at 11:32:21PM +, olegendo at gcc dot gnu.org wrote: > > If it's OK for a temporary mode switch to clobber other FPSCR bits (such as > > in > > the PR = single mode above), it should also be OK to load the FPSCR value > > from > > a thread local variable inside the thread-control-block: > > > > mov.l @(, gbr),r0 // r0 = address to fpscr value for a > >// particular mode setting > > lds.l @r0+,fpscr // mode switch > > IMO this is an ugly hack that shouldn't be taken. It has lots of > complex interactions with other things: signal handlers, the > ucontext.h functions, fenv, pthread, etc. Could you please elaborate on the problems you see there? > that could probably be > achieved correctly if somebody wanted to spend the effort on it, but > it would be ugly and SH-specific and honestly we already have a > shortage of people willing to spend time fixing SH problems without > introducing even more work. I failed to mention, that the idea with TLS variables was meant to be a separate option. If implemented in the compiler it would need to be turned on explicitly, similar to the option '-matomic-model=soft-tcb,gbr-offset='. Thus, if a libc/kernel/whatever doesn't want to make use of it, it won't have to. > > > This would require that any FPSCR setting change is also propagated to > > the TLS variables. E.g. setting the rounding mode would have to update > > FPSCR mode values in all such TLS variables. > > I guess that it would be useful to be able to select an FPSCR value for at > > least all combinations of FR and SZ bit settings, in other words having > > a TLS __fpscr_values array with 4 entries. However, it would make things > > such as toggling FPSCR.FR via frchg inefficient due to the required updates > > of the TLS variables. Other setting changes such as denorm or rounding > > mode are probably not so critical. > > If I'm not mistaken, the toggle approach will be efficient without > this TLS hack once it's implemented, right? No. The toggle approach is only efficient on SH4A. Other SH FPUs don't implement the fpchg instruction and require sts-lds fpscr sequences, regardless of toggling or explicitly setting the PR mode. > I don't think it makes > sense to introduce a hack for just a short-term mitigation of the > performance regression. If you think the short-term fix for this issue > is too costly, the proper solution is probably to add a -m option to > turn it back off (using the old __fpscr_values approach). This was not meant to be a short-term mitigation. In fact figuring out whether FPSCR bits can be clobbered during a PR mode switch or not is already not so simple. If at all, it would be an additional optimization opportunity after everything else is in place. Keeping the 'global __fpscr_values' approach as an option could be useful for thread model = single, or for bare-metal applications where the rounding mode etc is never changed from the default and FP status bits are never read back by application code.
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Jakub Jelinek changed: What|Removed |Added Attachment #32367|0 |1 is obsolete|| --- Comment #8 from Jakub Jelinek --- Created attachment 32368 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32368&action=edit gcc49-pr60516.patch Ok, testcase adjusted.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-17 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > Since r208590, the execution time of Polyhedron's fatigue.f90 doubled > from ~1.4s to ~2.9s. To make the things clear, these timings were obtained after applying the patch at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html I have a few very short (invalid) tests which are optimized differently before and after r208590. I can post some of them if there is an interest.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #2 from Richard Biener --- Indeed once such variables have their address taken (trivially happens in fortran) we have a hard time disambiguating them. You might want to try (the imperfect) -fipa-pta, even though that pessimizes code in some cases.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #14 from Markus Trippelsdorf --- Closing.
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 --- Comment #14 from Andreas Schwab --- Author: schwab Date: Mon Mar 17 09:23:15 2014 New Revision: 208612 URL: http://gcc.gnu.org/viewcvs?rev=208612&root=gcc&view=rev Log: PR testsuite/58851 * gfortran.dg/unlimited_polymorphic_13.f90: Properly compute storage size. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_13.f90
[Bug fortran/58793] Wrong value for _vtab for intrinsic types with CLASS(*): storage_size of class(*) gives wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58793 Bug 58793 depends on bug 58851, which changed state. Bug 58851 Summary: FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 Andreas Schwab changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Andreas Schwab --- .
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #3 from Dominique d'Humieres --- > You might want to try (the imperfect) -fipa-pta, even though that pessimizes > code in some cases. It does not change the run time for fatigue.f90.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #4 from Jakub Jelinek --- (In reply to Dominique d'Humieres from comment #3) > > You might want to try (the imperfect) -fipa-pta, even though that > > pessimizes > > code in some cases. > > It does not change the run time for fatigue.f90. And what exact change do you get with a mere http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch, against same version without it (e.g. both without the SAVE for MAIN__ change, or both with that change)?
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #15 from Jakub Jelinek --- Well, even when it is Firefox/whatever bug, the question is why do you get a crash in libgcc_s.so.1. Is that because your libgcc is too old to handle the gcc 4.9 emitted unwind info? Note, I'm not aware of any such changes in the last few years, so it would need to be very old, or -flto generating invalid unwind info or something. Can you make sure you are using libgcc_s.so.1 built by gcc trunk with debug info and see where exactly it crashes?
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|[4.8 and 4.9] O2 & asan |[4.8/4.9] O2 & asan enable |enable generates wrong |generates wrong insns |insns | --- Comment #3 from Richard Biener --- It's not fixed by the fix for PR60429. But 1.cpp: In member function ‘unsigned int WTF::StringImpl::hashSlowCase() const’: 1.cpp:26260:1: warning: no return statement in function returning non-void [-Wreturn-type] } ^ so at least there's sth fishy going on (fixing it with an obvious change doesn't fix the abort). Note that valgrind reports the error without -fsanitize=address, for -O2 but not for -Os. -fno-tree-loop-im fixes this so it might be a duplicate of PR??? as loop invariant motion can cause the read of uninitialized memory when applying store-motion.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #16 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #15) > Well, even when it is Firefox/whatever bug, the question is why do you get a > crash in libgcc_s.so.1. > Is that because your libgcc is too old to handle the gcc 4.9 emitted unwind > info? > Note, I'm not aware of any such changes in the last few years, so it would > need to be very old, or -flto generating invalid unwind info or something. > > Can you make sure you are using libgcc_s.so.1 built by gcc trunk with debug > info and see where exactly it crashes? You're right: x4 ~ # ll /lib/libgcc_s.so.1 -rw-r--r-- 1 root root 546544 Dec 3 2012 /lib/libgcc_s.so.1 So it's pretty old. I will install a new version and see what happens.
[Bug tree-optimization/60537] Loop header copying code bloat for simple loops that don't benefit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60537
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
Summary|Loop optimization code |Loop header copying code
|bloat for simple loops |bloat for simple loops that
||don't benefit
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
For -O2 we do this to enable loop optimizations which almost all require
do { } while style loops. This canonicalization can sometimes peel an
entire iteration as you can see here, and this canonicalization is
not done at -Os unless the loop is determined as hot (so with -Os
and profile-feedback some loops may get this treatment).
It's hard to undo this transform but that's what would be needed here ...
(or make more passes deal with number-of-iterations == n or zero)
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/57425] [4.8 Regression] RTL alias analysis unprepared to handle stack slot sharing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57425 --- Comment #18 from Mikael Pettersson --- Bill, the backport patch has now been approved: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00792.html
[Bug fortran/60550] New: ICE on factory design pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550 Bug ID: 60550 Summary: ICE on factory design pattern Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pogos77 at hotmail dot com Created attachment 32369 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32369&action=edit The test case for the design pattern: factory pattern. I want to select different benchmark problems in an optimization field. The attached program cannot compile due to an ICE. The error is ice2014.f90: In function ‘create_problem’: ice2014.f90:350:0: internal compiler error: in fold_convert_loc, at fold-const.c:1994 ALLOCATE(self%problemPtr, SOURCE=FRosenbrock(self%problemID, ndim, self%problemName)) ^ The gfortran version is gcc version 4.9.0 20140313 (experimental) [trunk revision 208526] (GCC) Thanking you for your prompt response.
[Bug c++/60551] New: __attribute__((used)) is ignored for 'static' function declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551
Bug ID: 60551
Summary: __attribute__((used)) is ignored for 'static' function
declarations
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
// a.cc:
// I plan to implement it in only one .cc module
// and not this one, thus I don't need external visibility.
static void friendly_accessor (void) __attribute__((used));
struct Something
{
friend void friendly_accessor (void);
void f (void);
};
// somewhere in b.cc 'friendly_accessor (void);' is implemented
// and used in 'Something::f()'
When compiling 'a.cc' I haven't managed to silence gcc on -Wall:
> a.cc:7:17: warning: 'void friendly_accessor()' declared 'static' but never
> defined [-Wunused-function]
> friend void friendly_accessor (void);
^
If i'll add a definition right after declaration the warning will go away:
> static void friendly_accessor (void) {}
Looks like a declaration tracking bug. It's a gcc-4.8.2 on amd64.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #4 from Richard Biener --- Created attachment 32370 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32370&action=edit patch to fix store motion issue Fixing that doesn't fix it (or my fix doesn't work ;)).
[Bug target/60539] [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Comment #1 from chrbr at gcc dot gnu.org ---
yes or not, it's not really ignored, it's the prob_likely value tuning. Setting
it to REG_BR_PROB_BASE restores the loop align but also impacts code ordering
for the byte-at-a-time code chunk that becomes less likely.
so we get worse:
movr4,r0
tst#3,r0
movr4,r1
bt.L10
.L6:
mov.b@r1+,r2
tstr2,r2
bf.L6
movr1,r0
rts
subcr4,r0
.align 1
.L10:
mov#0,r3
.L4:
mov.l@r1+,r2
cmp/strr3,r2
bf.L4
bra.L6
add#-4,r1
The problem is that .L14 is reached both from the word-at-atime paths and
byte-at-atime paths... and I was not able to find the proper tuning value to
favor boths given than the word loop iteration number is probably small
("strings are generally" not so big) and that the byte loop number of
iterations is less than 4, so introducing a .align here can be a cost.
I did try to introduce a UNSPECV_ALIGN here but without measuring any speed
improvement (or any small negative impact) on my board. Anyway any interesting
benchmarking tuning here is interesting, or even find a pathological case here
welcome,
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #6 from Sergei Trofimovich --- I was about to fill the bug about -Weverything to enable all the warnings you have. All those things I've got from 'gcc --help=warnings': -Wdelete-non-virtual-dtor -Wsuggest-attribute=noreturn -Wsuggest-attribute=format -Wredundant-decls ... (+around of 20 of this kind) But I'd like to see them (and new cool ones!) just with gcc upgrade and a run on -Weverything on a project (as I do with clang). Thanks!
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #5 from linzj --- Well,valgind do detect invalid memory usage.That's not an asan problem then. Since it effects from 4.8,does that mean 4.8 is not secure any more?
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #21 from Richard Biener --- Created attachment 32371 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32371&action=edit Fix
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #22 from Richard Biener --- The fix uses the store-data-race avoiding path which keeps a flag per moved mem-ref whether it was stored to. With that I can avoid loading from the ref before the loop if there are no loads in the loop itself. But it reveals that we possibly use too many flags (we don't try combining them - some simple analysis should be able to improve that).
[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #23 from Richard Biener --- Mine, but not for 4.9.
[Bug target/60539] [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539 --- Comment #2 from chrbr at gcc dot gnu.org --- note also that instead of merging the 3 max remaining bytes after the world-at-time loop with the byte-at-a-time loop I had a version that unrolled the 3 of them of we have 2 different path (word,bytes) instead of 3 (words, words+byte remaining, bytes). But the additional CF complexity was not beneficial in average for my set of benchmarks compared to a simple version with the remaining bytes falling thru the byte-at-atime loop
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-17
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase (-flto -fsanitize=undefined -O2):
struct A { int c; };
A *a;
int b = a->c;
int
main ()
{
}
[Bug sanitizer/60535] [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
Yeah, that is the reason why we run ubsan tests with dg-skip-if "" { *-*-* } {
"-flto" } { "" }. I don't think it's a regression, it never worked.
[Bug other/60552] New: integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Bug ID: 60552 Summary: integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min^ Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: addepalli.prasad at tcs dot com When I am trying to build a cpp file with the gcc compiler. I am getting the below errors: /include/c++/4.4.3/bits/locale_facets.tcc",line 453: warning #61-D: integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^ detected during: instantiation of "std::num_get< _CharT, _InIter> ::iter_type std::num_get< _CharT, _InIter> ::_M_extract_int(std::num_get< _CharT, _InIter> ::iter_type, std::num_get< _CharT, _InIter> ::iter_type, std::ios_base &, std::ios_base::iostate &, _ValueT &) const [with _CharT=char, _InIter=std::istreambuf_iterator< std::basic_streambuf< char, std::char_traits< char> > ::char_type, std::basic_streambuf< char, std::char_traits< char> > ::traits_type> , _ValueT=long]" at line 2168 of "/proj/DTE_releases/9.63.0.1/cade/cade_B_tools_gcc-ppc/Linux /i686/bin/../lib/gcc/powerpc-eabi/4.4.3/../../../../powerpc- eabi/include/c++/4.4.3/bits/locale_facets.h" instantiation of "std::num_get< _CharT, _InIter> ::iter_type std::num_get< _CharT, _InIter> ::do_get(std::num_get< _CharT, _InIter> ::iter_type, std::num_get< _CharT, _InIter> ::iter_type, std::ios_base &, std::ios_base::iostate &, long &) const [with _CharT=char, _InIter=std::istreambuf_iterator< std::basic_streambuf< char, std::char_traits< char> > ::char_type, std::basic_streambuf< char, std::char_traits< char> > ::traits_type> ]" /include/c++/4.4.3/ext/numeric_traits.h: In copy constructor '__gnu_cxx::__numeric_traits<_Value>::__numeric_traits(const __gnu_cxx::__numeric_traits<_Value>&)': powerpc-eabi/include/c++/4.4.3/ext/numeric_traits.h:126: error: '_Tp' was not declared in this scope include/c++/4.4.3/ext/numeric_traits.h:126: error: '_Tp' was not declared in this scope accum1.cpp: In function 'int accum1_test(int, char**)': accum1.cpp:17: warning: comparison between signed and unsigned integer expressions accum1.cpp: At global scope: accum1.cpp:25: error: specialization of 'char* std::allocator<_Alloc>::_att_tmpl_text() const [with _Tp = char]' after instantiation accum1.cpp:27: error: specialization of 'char* std::allocator<_Alloc>::_att_tmpl_text() const [with _Tp = wchar_t]' after instantiation accum1.cpp:32: error: specialization of 'char* std::basic_string<_CharT, _Traits, _Alloc>::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]' after instantiation accum1.cpp:33: error: specialization of 'char* std::collate<_CharT>::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:37: error: specialization of 'char* std::collate_byname<_CharT>::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:38: error: specialization of 'char* std::basic_streambuf<_CharT, _Traits>::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traits]' after instantiation accum1.cpp:39: error: specialization of 'char* std::numpunct<_CharT>::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:44: error: specialization of 'char* std::numpunct_byname<_CharT>::_att_tmpl_text() const [with _CharT = char]' after instantiation accum1.cpp:45: error: specialization of 'char* std::num_get<_CharT, _InIter>::_att_tmpl_text() const [with _CharT = char, _InIter = std::istreambuf_iterator >]' after instantiation accum1.cpp:46: error: specialization of 'char* std::num_put<_CharT, _OutIter>::_att_tmpl_text() const [with _CharT = char, _OutIter = std::ostreambuf_iterator >]' after instantiation accum1.cpp:47: error: specialization of 'char* std::basic_ios<_CharT, _Traits>::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traits]' after instantiation accum1.cpp:48: error: specialization of 'char* std::basic_ostream<_CharT, _Traits>::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traits]' after instantiation accum1.cpp:49: error: no member function '_att_tmpl_text' declared in 'std::basic_ostream >::sentry' accum1.cpp:50: error: specialization of 'char* std::basic_istream<_CharT, _Traits>::_att_tmpl_text() const [with _CharT = char, _Traits = std::char_traits]' after instantiation accum1.cpp:54: error: n
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #5 from Dominique d'Humieres --- > And what exact change do you get with a mere > http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html > patch, against same version without it (e.g. both without the SAVE > for MAIN__ change, or both with that change)? With the patch, the timing when compiling with '-Ofast -fwhole-program' is between 1.40 to 1.45s before r208590 and above 3s after it. The later timing is unaffected by the addition of -fipa-pta. I did not test the effect of -fipa-pta before r208590 and I have no access to the machine before this evening.
[Bug target/60516] [4.7/4.8/4.9 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #9 from Kai Tietz --- Did regression-test for 32-bit mingw for C, C++, and Fortran. No new regressions occurred. So patch is from my POV ok for trunk and branches
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 --- Comment #6 from Jakub Jelinek --- (In reply to Dominique d'Humieres from comment #5) > > And what exact change do you get with a mere > > http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html > > patch, against same version without it (e.g. both without the SAVE > > for MAIN__ change, or both with that change)? > > With the patch, the timing when compiling with '-Ofast -fwhole-program' is > between 1.40 to 1.45s before r208590 and above 3s after it. The later timing > is unaffected by the addition of -fipa-pta. I did not test the effect of > -fipa-pta before r208590 and I have no access to the machine before this > evening. I meant whether my (and Honza's and Tobias') patch actually fixed PR58721 on the benchmark or not (i.e. what were the timings without the http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html patch?).
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Jonathan Wakely changed: What|Removed |Added Severity|major |normal --- Comment #1 from Jonathan Wakely --- You haven't provided the requested information requested at http://gcc.gnu.org/bugs/ - please read that before reporting bugs. /include/c++/4.4.3/bits/locale_facets.tcc",line 453: warning #61-D: integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^ This is not an error from GCC 4.4.3, are you sure that's what you're using? GCC 4.4.3 has been unsupported for several years, please either update to a newer release or report this to the vendor you got your compiler from.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #6 from Richard Biener --- Meanwhile -fno-tree-dse also "fixes" this but it only prevents mayhem downstream (Jakub bisected this to a revision that exposed the issue, r158047). You have to disable both tree DSE passes btw, thus it points to a pass running after DSE2. It's not -fhoist-adjacent-loads, not RTL PRE nor RTL loop invariant motion or the scheduler.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Comment #8 from chrbr at gcc dot gnu.org ---
Hi Oleg,
I posted a patch in 2006
(http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01562.html) to support mode
flipping fpchg instruction for the sh4a. it is in used in our current (4.8)
production compiler without issue since then.
I didn't insist a lot pushing it since too sh4a specific, but I'd be happy to
port it to the 4.10 branch and repost if there is enough interest.
Cheers
a code like
float
foo(float a)
{
return a+2;
}
compiles into:
mova.L2,r0
fmov.s @r0+,fr0
fpchg
faddfr5,fr0
rts
fpchg
instead of:
mov.l .L2,r1
mova.L3,r0
fmov.s @r0+,fr0
lds.l @r1+,fpscr
add #-4,r1
add #4,r1
faddfr5,fr0
rts
lds.l @r1+,fpscr
.L4:
.align 2
.L2:
.long ___fpscr_values
.L3:
.long 1073741824
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Richard Biener ---
Looks like TBAA violations to me:
struct QualifiedNameComponents c;
short unsigned int _316;
short unsigned int _317;
:
# data_157 = PHI
_316 = MEM[base: data_157, offset: 2B];
_317 = MEM[base: data_157, offset: 0B];
... hashing ...
data_329 = data_157 + 4;
if (data_329 != &MEM[(void *)&c + 12B])
goto ;
else
goto ;
so you hash the QualifiedNameComponents pointers, not its strings. And
you do it by reading the pointers as 'unsigned short'. Probably via
template static inline unsigned hashMemory(const void* data)
{
typedef int dummylength_must_be_a_multible_of_four [(!(length % 4)) ? 1
: -1];
return computeHash(static_cast(data), length /
sizeof(UChar));
}
which introduces the violation. It should not use 'short' hashing but
hashing of 'char'.
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Sivaprasad changed: What|Removed |Added Severity|normal |major
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 --- Comment #2 from Sivaprasad --- with GCC 4.6.3 also, we are facing same problems.
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #5 from Jorn Wolfgang Rennecke --- Created attachment 32372 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32372&action=edit tentative patch for tentative reloads In this case, reload already knows that it has to re-do the reloads, but it goes ahead anyway and computes reloads registers for this iteration. Unfortunately, when find_reload_regs fails, it then calls spill_failure, giving a hard error for a reload that we don't need in the first place. The patch in this attachment passes down something_changed from reload as tentative to select_reload_regs and then on to find_reload_regs to not worry about the failure. Also, in reload, I made it not 'goto failure' in that case.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #8 from linzj --- I don't think it can be mark as resolved-invalid that fast.This code is used by WebKit for a long time and no one would say this is an illegal algorithm.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #9 from linzj --- If this is an illegal expression, it should be reported at compile time,not generating a wrong code.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Markus Trippelsdorf changed: What|Removed |Added Summary|[4.9 Regression] Link |Link failure with -flto and |failure with -flto and |-fsanitize=undefined |-fsanitize=undefined| Severity|normal |enhancement
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #27 from Richard Biener --- Author: rguenth Date: Mon Mar 17 13:08:41 2014 New Revision: 208615 URL: http://gcc.gnu.org/viewcvs?rev=208615&root=gcc&view=rev Log: 2014-03-17 Richard Biener Backport from mainline 2014-03-11 Richard Biener PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/60485] field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Mar 17 13:08:41 2014 New Revision: 208615 URL: http://gcc.gnu.org/viewcvs?rev=208615&root=gcc&view=rev Log: 2014-03-17 Richard Biener Backport from mainline 2014-03-11 Richard Biener PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60485-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-structalias.c
[Bug middle-end/60429] [4.7 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Richard Biener changed: What|Removed |Added Known to work||4.8.3, 4.9.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] |Miscompilation (aliasing) |Miscompilation (aliasing) |with -finline-functions |with -finline-functions Known to fail||4.7.3, 4.8.2 --- Comment #28 from Richard Biener --- Also fixed on the 4.8 branch.
[Bug other/60552] integer operation result is out of range ? -__gnu_cxx::__numeric_traits<_ValueT>::__min ^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60552 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-17 Ever confirmed|0 |1 Severity|major |normal --- Comment #3 from Jonathan Wakely --- 4.6.3 is also unsupported, and you still haven't read http://gcc.gnu.org/bugs/
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 linzj changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #10 from linzj --- add __attribute__((noinline)) to computeHash "resolves" this bug.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Biener --- That doesn't make this bug valid.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #9 from Kazumoto Kojima --- Although it seems that (1)-(5) in #3 are interesting points, they are almost optimizations. I guess that programs with frequent FP mode switchings are simply rare in real world and would be a bit special or even pathological in the first place. I like the idea of mode switching without __fpscr_values even if it requires more instructions on SH4. Now SH4 is a fairy old core and is not for heavy FP computations anyway. I think that it won't impact the real working set. It looks to me that Christian's patch is the way to go.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 32373 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32373&action=edit gcc49-pr60535.patch Untested fix. There are 3 remaining tests I haven't removed the dg-skip-if for yet: c-c++-common/ubsan/null-4.c c-c++-common/ubsan/overflow-int128.c These 2 fail because with -flto we get type names instead of say complex double or int128_t (if I remember it well). Dunno if there is anything that can be done about it though. g++.dg/ubsan/pr59437.C This one shows a bug either in the -fvtable-* verification stuff, or in cgraph, but doesn't look related to ubsan: ==27993== Invalid write of size 8 ==27993==at 0x89AEEC: bitmap_initialize_stat(bitmap_head*, bitmap_obstack*) (bitmap.h:277) ==27993==by 0x89BA7C: bitmap_obstack_alloc_stat(bitmap_obstack*) (bitmap.c:376) ==27993==by 0xDCB7B2: mark_def_dom_walker::mark_def_dom_walker(cdi_direction) (tree-into-ssa.c:2234) ==27993==by 0xDCBA80: rewrite_into_ssa() (tree-into-ssa.c:2331) ==27993==by 0xDCBD70: (anonymous namespace)::pass_build_ssa::execute() (tree-into-ssa.c:2403) ==27993==by 0xC56F9D: execute_one_pass(opt_pass*) (passes.c:2229) ==27993==by 0xC571B6: execute_pass_list(opt_pass*) (passes.c:2282) ==27993==by 0xC4B58E: gcc::pass_manager::execute_early_local_passes() (passes.c:135) ==27993==by 0x92BCA4: cgraph_process_new_functions() (cgraphunit.c:338) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993== Address 0xbc0cdf0 is 96 bytes inside a block of size 4,064 free'd ==27993==at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27993==by 0x3C5FA84857: obstack_free (in /usr/lib64/libc-2.18.so) ==27993==by 0x89B901: bitmap_obstack_release(bitmap_obstack*) (bitmap.c:358) ==27993==by 0x92C95C: analyze_function(cgraph_node*) (cgraphunit.c:665) ==27993==by 0x92BC0B: cgraph_process_new_functions() (cgraphunit.c:334) ==27993==by 0x80DDE3: vtv_generate_init_routine() (vtable-class-hierarchy.c:1191) ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) ==27993==by 0xD42091: compile_file() (toplev.c:562) ==27993==by 0xD441E9: do_compile() (toplev.c:1914) ==27993==by 0xD44354: toplev_main(int, char**) (toplev.c:1990) ==27993==by 0x14BD71B: main (main.c:36) Apparently this is related to the default obstack freeing and use after free, either vtable*.c calls cgraph at a pointer where it is not supposed to (or needs to conditionalize it on cgraph_state), or cgraph doesn't handle nesting properly.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > Created attachment 32373 [details] > gcc49-pr60535.patch > > Untested fix. > > There are 3 remaining tests I haven't removed the dg-skip-if for yet: > c-c++-common/ubsan/null-4.c > c-c++-common/ubsan/overflow-int128.c > > These 2 fail because with -flto we get type names instead of say > complex double or int128_t (if I remember it well). Dunno if there is > anything that can be done about it though. You need to amend lto/lto-lang.c:lto_init with more NAME_TYPEs (basically cover all global trees with a name we'd use for LTO - which would be matching the C frontend).
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Mon Mar 17 14:15:51 2014 New Revision: 208616 URL: http://gcc.gnu.org/viewcvs?rev=208616&root=gcc&view=rev Log: PR middle-end/60534 * omp-low.c (omp_max_vf): Treat -fno-tree-loop-optimize the same as -fno-tree-loop-vectorize. (expand_omp_simd): Likewise. testsuite/ * gcc.dg/gomp/pr60534.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr60534.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60534] ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Marek Polacek --- Fixed.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #10 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #9) > Although it seems that (1)-(5) in #3 are interesting points, they > are almost optimizations. Yep. Those are not necessary to get the functionality (of not using __fpscr_values). > I guess that programs with frequent FP > mode switchings are simply rare in real world and would be a bit > special or even pathological in the first place. > I like the idea of mode switching without __fpscr_values even if it > requires more instructions on SH4. Now SH4 is a fairy old core and > is not for heavy FP computations anyway. I think that it won't impact > the real working set. > It looks to me that Christian's patch is the way to go. Yep. However, when the patch was proposed there were some objections regarding the modifications in lcm.c (if I'm not mistaken). We could try again. The reason why I brought up (1)-(5) in #3 was that if one of them is eventually implemented (e.g. reorder calculation insns) the changes to lcm.c might not be required and could be avoided. Depending on the implementation of such optimization, the mode switch information might have to be obtained/maintained in a different way. However, I at the moment I have no concrete ideas/plans. If Christian's patch is accepted, that's cool, too.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #12 from linzj --- Alright,should I change the algorithm to avoid this bug?
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #13 from rguenther at suse dot de --- On Mon, 17 Mar 2014, manjian2006 at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 > > --- Comment #12 from linzj --- > Alright,should I change the algorithm to avoid this bug? Of course, what else ...
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #14 from linzj --- Well,but I have not figured out what goes wrong in the hashing algorithm. Would you point it out.
[Bug sanitizer/60535] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 --- Comment #5 from Marek Polacek --- (In reply to Jakub Jelinek from comment #3) > g++.dg/ubsan/pr59437.C > > This one shows a bug either in the -fvtable-* verification stuff, or in > cgraph, but doesn't look related to ubsan: > > ==27993== Invalid write of size 8 > ==27993==at 0x89AEEC: bitmap_initialize_stat(bitmap_head*, > bitmap_obstack*) (bitmap.h:277) > ==27993==by 0x89BA7C: bitmap_obstack_alloc_stat(bitmap_obstack*) > (bitmap.c:376) > ==27993==by 0xDCB7B2: > mark_def_dom_walker::mark_def_dom_walker(cdi_direction) > (tree-into-ssa.c:2234) > ==27993==by 0xDCBA80: rewrite_into_ssa() (tree-into-ssa.c:2331) > ==27993==by 0xDCBD70: (anonymous namespace)::pass_build_ssa::execute() > (tree-into-ssa.c:2403) > ==27993==by 0xC56F9D: execute_one_pass(opt_pass*) (passes.c:2229) > ==27993==by 0xC571B6: execute_pass_list(opt_pass*) (passes.c:2282) > ==27993==by 0xC4B58E: gcc::pass_manager::execute_early_local_passes() > (passes.c:135) > ==27993==by 0x92BCA4: cgraph_process_new_functions() (cgraphunit.c:338) > ==27993==by 0x80DDE3: vtv_generate_init_routine() > (vtable-class-hierarchy.c:1191) > ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) > ==27993==by 0xD42091: compile_file() (toplev.c:562) > ==27993== Address 0xbc0cdf0 is 96 bytes inside a block of size 4,064 free'd > ==27993==at 0x4A07577: free (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==27993==by 0x3C5FA84857: obstack_free (in /usr/lib64/libc-2.18.so) > ==27993==by 0x89B901: bitmap_obstack_release(bitmap_obstack*) > (bitmap.c:358) > ==27993==by 0x92C95C: analyze_function(cgraph_node*) (cgraphunit.c:665) > ==27993==by 0x92BC0B: cgraph_process_new_functions() (cgraphunit.c:334) > ==27993==by 0x80DDE3: vtv_generate_init_routine() > (vtable-class-hierarchy.c:1191) > ==27993==by 0x6B534E: cp_write_global_declarations() (decl2.c:4619) > ==27993==by 0xD42091: compile_file() (toplev.c:562) > ==27993==by 0xD441E9: do_compile() (toplev.c:1914) > ==27993==by 0xD44354: toplev_main(int, char**) (toplev.c:1990) > ==27993==by 0x14BD71B: main (main.c:36) > > Apparently this is related to the default obstack freeing and use after > free, either vtable*.c calls cgraph at a pointer where it is not supposed to > (or needs to conditionalize it on cgraph_state), or cgraph doesn't handle > nesting properly. I think this is PR59441.
[Bug lto/59441] ICE in bitmap_element_allocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-17 Ever confirmed|0 |1
[Bug tree-optimization/57303] [4.7 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 --- Comment #11 from Richard Biener --- Author: rguenth Date: Mon Mar 17 14:38:55 2014 New Revision: 208618 URL: http://gcc.gnu.org/viewcvs?rev=208618&root=gcc&view=rev Log: 2014-03-17 Richard Biener Backport from mainline 2013-05-21 Richard Biener PR tree-optimization/57303 * tree-ssa-sink.c (statement_sink_location): Properly handle self-assignments. * gcc.dg/torture/pr57303.c: New testcase. 2013-12-02 Richard Biener PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. 2014-02-14 Richard Biener PR tree-optimization/60183 * tree-ssa-phiprop.c (propagate_with_phi): Avoid speculating loads. (tree_ssa_phiprop): Calculate and free post-dominators. * gcc.dg/torture/pr60183.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57303.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr59139.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr60183.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_7-branch/gcc/tree-ssa-phiprop.c branches/gcc-4_7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/59139] [4.7 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Mar 17 14:38:55 2014 New Revision: 208618 URL: http://gcc.gnu.org/viewcvs?rev=208618&root=gcc&view=rev Log: 2014-03-17 Richard Biener Backport from mainline 2013-05-21 Richard Biener PR tree-optimization/57303 * tree-ssa-sink.c (statement_sink_location): Properly handle self-assignments. * gcc.dg/torture/pr57303.c: New testcase. 2013-12-02 Richard Biener PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. 2014-02-14 Richard Biener PR tree-optimization/60183 * tree-ssa-phiprop.c (propagate_with_phi): Avoid speculating loads. (tree_ssa_phiprop): Calculate and free post-dominators. * gcc.dg/torture/pr60183.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57303.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr59139.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr60183.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_7-branch/gcc/tree-ssa-phiprop.c branches/gcc-4_7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/60183] [4.7 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon Mar 17 14:38:55 2014 New Revision: 208618 URL: http://gcc.gnu.org/viewcvs?rev=208618&root=gcc&view=rev Log: 2014-03-17 Richard Biener Backport from mainline 2013-05-21 Richard Biener PR tree-optimization/57303 * tree-ssa-sink.c (statement_sink_location): Properly handle self-assignments. * gcc.dg/torture/pr57303.c: New testcase. 2013-12-02 Richard Biener PR tree-optimization/59139 * tree-ssa-loop-niter.c (chain_of_csts_start): Properly match code in get_val_for. (get_val_for): Use gcc_checking_asserts. * gcc.dg/torture/pr59139.c: New testcase. 2014-02-14 Richard Biener PR tree-optimization/60183 * tree-ssa-phiprop.c (propagate_with_phi): Avoid speculating loads. (tree_ssa_phiprop): Calculate and free post-dominators. * gcc.dg/torture/pr60183.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57303.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr59139.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr60183.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_7-branch/gcc/tree-ssa-phiprop.c branches/gcc-4_7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/60183] [4.7 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #15 from Marek Polacek --- "It should not use 'short' hashing but hashing of 'char'." doesn't help?
[Bug tree-optimization/57303] [4.7 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/59139] [4.7 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 --- Comment #16 from linzj --- Yes,that may work.But what exactly go wrong in the original algorithm? I can't change a correct algorithm just because it volatiles TBBA and make the compiler generate wrong code.Because it's CORRECT logically.
[Bug c++/59571] [C++11] ICE when casting inside static member constexpr brace initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Mar 17 14:53:05 2014 New Revision: 208619 URL: http://gcc.gnu.org/viewcvs?rev=208619&root=gcc&view=rev Log: /cp 2014-03-17 Paolo Carlini PR c++/59571 * typeck2.c (check_narrowing): Use fold_non_dependent_expr_sfinae. /testsuite 2014-03-17 Paolo Carlini PR c++/59571 * g++.dg/cpp0x/constexpr-ice13.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 Bug ID: 60553 Summary: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin.liska at gmail dot com I do compile Chromium with LTO and there's ICE with enormous call stack: gcc --version: gcc (GCC) 4.9.0 20140313 (experimental) ld --version: GNU gold (GNU Binutils 2.24.51.20140304) 1.11 (gdb) bt -20 #529301 0x005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763af738) at ./gtype-lto.h:359 #529302 0x005aaf8b in gt_ggc_mx_lang_tree_node (x_p=0x7f5c644eedc8) at ./gtype-lto.h:378 #529303 0x005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a40a8) at ./gtype-lto.h:359 #529304 0x005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a70c0) at ./gtype-lto.h:55 #529305 0x005aae54 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4150) at ./gtype-lto.h:357 #529306 0x005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a73a0) at ./gtype-lto.h:55 #529307 0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4690) at ./gtype-lto.h:356 #529308 0x005aadfd in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763c2c78) at ./gtype-lto.h:354 #529309 0x005aa694 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c7650fc00) at ./gtype-lto.h:263 #529310 0x00821c23 in gt_ggc_m_P9tree_node4htab (x_p=0x7f5c7775a850) at gtype-desc.c:3185 #529311 0x007bfde6 in ggc_mark_root_tab (rt=0x10cd140 ) at ../../gcc/ggc-common.c:133 #529312 0x007c0281 in ggc_mark_roots () at ../../gcc/ggc-common.c:152 #529313 0x005d0c2a in ggc_collect () at ../../gcc/ggc-page.c:2077 #529314 0x005c32e7 in read_cgraph_and_symbols (nfiles=11258, fnames=0x36701f0) at ../../gcc/lto/lto.c:3004 #529315 0x005c406a in lto_main () at ../../gcc/lto/lto.c:3406 #529316 0x009e4273 in compile_file () at ../../gcc/toplev.c:548 #529317 0x009e640a in do_compile () at ../../gcc/toplev.c:1914 #529318 0x009e6575 in toplev_main (argc=11283, argv=0x35fe750) at ../../gcc/toplev.c:1990 #529319 0x7f5c765b6be5 in __libc_start_main () from /lib64/libc.so.6 #529320 0x00587831 in _start () at ../sysdeps/x86_64/start.S:122 (gdb) bt 10 #0 0x005cec2c in lookup_page_table_entry (p=) at ../../gcc/ggc-page.c:584 #1 0x005cfc5e in ggc_set_mark (p=0x7f5c399c1170) at ../../gcc/ggc-page.c:1467 #2 0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c1170) at ./gtype-lto.h:36 #3 0x005aae1a in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6f18) at ./gtype-lto.h:355 #4 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6e70) at ./gtype-lto.h:375 #5 0x005aa4b8 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c10b8) at ./gtype-lto.h:246 #6 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c60a8) at ./gtype-lto.h:374 #7 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf5e8) at ./gtype-lto.h:375 #8 0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bae60) at ./gtype-lto.h:243 #9 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf348) at ./gtype-lto.h:374 I don't know what to dump, if you are interested I can add all kind info you need.
[Bug c++/59571] [C++11] ICE when casting inside static member constexpr brace initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini --- Fixed for 4.9.0.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #11 from chrbr at gcc dot gnu.org --- (In reply to Oleg Endo from comment #10) > (In reply to Kazumoto Kojima from comment #9) > > Although it seems that (1)-(5) in #3 are interesting points, they > > are almost optimizations. > > Yep. Those are not necessary to get the functionality (of not using > __fpscr_values). > > > I guess that programs with frequent FP > > mode switchings are simply rare in real world and would be a bit > > special or even pathological in the first place. > > I like the idea of mode switching without __fpscr_values even if it > > requires more instructions on SH4. Now SH4 is a fairy old core and > > is not for heavy FP computations anyway. I think that it won't impact > > the real working set. > > It looks to me that Christian's patch is the way to go. > > Yep. However, when the patch was proposed there were some objections > regarding the modifications in lcm.c (if I'm not mistaken). We could try > again. there were neither followup nor objections to the last version. I'll post again, the time to cross-check with epiphany or x96. > > The reason why I brought up (1)-(5) in #3 was that if one of them is > eventually implemented (e.g. reorder calculation insns) the changes to lcm.c > might not be required and could be avoided. Depending on the implementation > of such optimization, the mode switch information might have to be > obtained/maintained in a different way. However, I at the moment I have no > concrete ideas/plans. If Christian's patch is accepted, that's cool, too. Implementing in LCM can also be a base to expose the architectural mode flipping extension with other ports (MMX was suggested I think)
