[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 2 07:50:19 2015 New Revision: 224013 URL: https://gcc.gnu.org/viewcvs?rev=224013root=gccview=rev Log: 2015-06-02 Richard Biener rguent...@suse.de PR tree-optimization/65961 * tree-vect-slp.c (vect_get_and_check_slp_defs): Remove bogus check and clarify dump message. (vect_build_slp_tree): If all children are built up from scalars build up the parent from scalars instead. * tree-vect-stmts.c (vect_is_simple_use): Cleanup. * gcc.dg/torture/pr65961.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr65961.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c
[Bug c++/66374] [5/6 Regression] template function accessing a temporary through a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66374 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-02 Known to work||4.9.2 Summary|template function accessing |[5/6 Regression] template |a temporary through a |function accessing a |lambda |temporary through a lambda Ever confirmed|0 |1 Known to fail||5.1.0, 6.0 Severity|major |normal
[Bug target/66369] gcc 4.8.3/5.1.0 miss optimisation with vpmovmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66369 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- v = (long ) _mm256_movemask_epi8( _mm256_cmpeq_epi8(regchx256,regset256) ); isn't this because there maybe isn't an intrinsic producing a 64bit value? If so the backend probably misses a pattern for it and thus combine doesn't generate it.
[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- PRE doesn't seem to do sth wrong here. The testcase can be fixed by for example disabling VRP2. VRP2 needs either store-motion or complete unrolling to make it trigger the miscompile. Nicest IL before VRP2 is with -fno-ivopts -fno-tree-loop-im. The transform VRP2 does is Folding statement: if (a.4_17 = 13) Simplified relational if (a.4_17 = 13) into if (a.4_17 != 14) and Registering jump thread: (6, 7) incoming edge; (7, 8) normal; Threaded jump 6 -- 7 to 12 bb 6: # prephitmp_3 = PHI prephitmp_22(5) # prephitmp_39 = PHI prephitmp_22(5) bb 7: # prephitmp_26 = PHI prephitmp_39(6), pretmp_23(3) if (prephitmp_26 != 113) goto bb 8; else goto bb 9; bb 8: __builtin_abort (); so it looks jump-threading related to me. Somehow the equivalences I see being recorded miss the backedge for prephitmp_22 but only record zero.
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- Checked in.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 Dominik Vogt vogt at linux dot vnet.ibm.com changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com --- I think the problem is that in the backtrace below _Unwind_Find_registered_FDE() is called with a pc that points one byte before the start of main.main (0x80001de8). That is cause by this line from uw_frame_state_for(): fde = _Unwind_Find_FDE (context-ra + _Unwind_IsSignalFrame (context) - 1, context-bases); -- snip -- #0 _Unwind_Find_registered_FDE (bases=0xc2084176e0, pc=0x80001de7 main.main+23) at ../../../libgcc/unwind-dw2-fde.c:1010 #1 _Unwind_Find_FDE (pc=0x80001de7 main.main+23, bases=0xc2084176e0) at ../../../libgcc/unwind-dw2-fde-dip.c:454 #2 0x03fff6ee665c in uw_frame_state_for ( context=context@entry=0xc2084175b0, fs=fs@entry=0xc208417738) at ../../../libgcc/unwind-dw2.c:1241 #3 0x03fff6ee8442 in _Unwind_Backtrace (trace=0x3fff7aca438 unwind, trace_argument=0xc208417aa8) at ../../../libgcc/unwind.inc:290 #4 0x03fff7aca51a in backtrace_full (state=optimized out, skip=optimized out, callback=optimized out, error_callback=optimized out, data=0xc208417b78) at ../../../libbacktrace/backtrace.c:106 #5 0x03fff7773a16 in runtime_callers (skip=optimized out, locbuf=optimized out, m=optimized out, keep_thunks=optimized out) at ../../../libgo/runtime/go-callers.c:168 #6 0x03fff777356c in runtime.Caller (skip=skip@entry=20) at ../../../libgo/runtime/go-caller.c:168 #7 0x80001de8 in main.main () at pr66303.go:9 -- snip --
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to Andrew from comment #7) Nevertheless, that is no reason to generate an INFINITY LOOP, which will be cleaned all the memory, including the NULL address. If the program has undefined behaviour, then the compiler makes no guarantees at all, it's allowed to do pretty much anything at any part of the program
[Bug middle-end/66345] [5/6 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Jun 2 09:17:49 2015 New Revision: 224017 URL: https://gcc.gnu.org/viewcvs?rev=224017root=gccview=rev Log: PR middle-end/66345 * gimple-fold.c (gimple_fold_builtin_snprintf): Return false if get_maxval_strlen does not produce an INTEGER_CST. * gcc.dg/torture/pr66345.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr66345.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimple-fold.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #6 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Ah, forget it, the addresses are okay; I'll dig deeper into the code.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 İsmail cartman Dönmez ismail at donmez dot ws changed: What|Removed |Added CC||ismail at donmez dot ws --- Comment #18 from İsmail cartman Dönmez ismail at donmez dot ws --- It would make sense to set this fixed size to 1GB.
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew from comment #7) IMHO So no GCC bug, just wrongly assuming pointers can't become null pointers if they were not null pointers. Nevertheless, that is no reason to generate an INFINITY LOOP, which will be cleaned all the memory, including the NULL address. But undefined behavior can do anything. And this is just undefined behavior.
[Bug middle-end/66345] [5/6 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Jun 2 09:13:29 2015 New Revision: 224016 URL: https://gcc.gnu.org/viewcvs?rev=224016root=gccview=rev Log: PR middle-end/66345 * gimple-fold.c (gimple_fold_builtin_snprintf): Return false if get_maxval_strlen does not produce an INTEGER_CST. * gcc.dg/torture/pr66345.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66345.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/66345] [5/6 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug target/65225] [AArch64] Various aarch64_rtx_costs improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- The aarch64 costs issue that I could find have been fixed on trunk for GCC 6
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #6 from Sebastiano Vigna sebastiano.vigna at unimi dot it --- I forgot an important aspect: with -fsanitize=undefined the optimization bug does not show up. The instrumentation perturbs the code enough to make it go away.
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I will have a looksee.
[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 --- Comment #15 from vries at gcc dot gnu.org --- (In reply to vries from comment #3) [ There's a problem with the matching. The rs in ..rrr were supposed to match the PTR_PTR_PTR arguments. But that's not the case, since we need to add a dot even for a void result. So the intended spec string was ...rrr. AFAIU, this problem does not affect this PR. But I will review omp-builtins.def for similar problems. ] Fixed in https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00089.html
[Bug c++/66374] [5/6 Regression] template function accessing a temporary through a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66374 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Started with r216056
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090
--- Comment #10 from Andrew wad at infinet dot ru ---
(In reply to Christian Prochaska from comment #0)
test.c:
void func()
{
unsigned int i;
unsigned int *ptr = (unsigned int*)0xf000;
for (i = 0; i 1024; i++)
*(ptr++) = 0;
}
There is no attempts to check pointer for NULL.
But, this is hidden attempt to substitute one test (i 1024) to another (ptr
!= NULL), which will be the result of unexpected always true.
And by the way:
void *ptr = malloc(1024);
if (ptr == NULL) /* always false ? Never panic()? */
panic();
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #5 from Sebastiano Vigna sebastiano.vigna at unimi dot it --- Fantastic tool! I didn't know about it. But it doesn't fire. There is no undefined behaviour in that code--it's just that the optimizer at -O1 does something wrong. I tried a binary search over the single options induced by -O1, but it turns out it's a combination of things--when I split the options in two half, the problem did not show up with either half. The code is 30-40 lines of assembly--I guess someone proficient with the output of the compiler could easily spot what's going wrong.
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 --- Comment #2 from jkratoch at gcc dot gnu.org --- Author: jkratoch Date: Tue Jun 2 07:37:22 2015 New Revision: 224012 URL: https://gcc.gnu.org/viewcvs?rev=224012root=gccview=rev Log: PR other/65366 * gdbhooks.py: Use int(...) instead of long(...). Use print(...) instead of print ... . Modified: trunk/gcc/ChangeLog trunk/gcc/gdbhooks.py
[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66372 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-02 Known to work||5.1.0 Target Milestone|--- |6.0 Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. (gdb) p path-last ()-e-src-loop_father Cannot access memory at address 0xa5a5a5a5a5a5a5bd looks like e-src was freed.
[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from vries at gcc dot gnu.org --- patch committed, marking resolved-fixed
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090 Andrew wad at infinet dot ru changed: What|Removed |Added CC||wad at infinet dot ru --- Comment #7 from Andrew wad at infinet dot ru --- IMHO So no GCC bug, just wrongly assuming pointers can't become null pointers if they were not null pointers. Nevertheless, that is no reason to generate an INFINITY LOOP, which will be cleaned all the memory, including the NULL address.
[Bug rtl-optimization/66370] compiler crashes when compiling a function with a huge number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66370 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Component|c |rtl-optimization --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Is the size of the stack limited on mingw-w64? If so, try unlimiting it. We do have gcc.c-torture/compile/limits-fnargs.c in the testsuite which uses 10 parameters (albeit it just declares such a function and calls it with constant arguments). It works fine here (x86_64-linux) with 28040 arguments and optimization, but it takes quite some time to compile (the scaling doesn't seem linear but quadratic at least... :/). time-report from GCC 5, 28040 arguments and -O1: Execution times (seconds) phase opt and generate : 97.58 (100%) usr 0.15 (68%) sys 97.73 (100%) wall 100442 kB (90%) ggc forward prop: 29.33 (30%) usr 0.03 (14%) sys 29.36 (30%) wall 3942 kB ( 4%) ggc combiner: 32.60 (33%) usr 0.03 (14%) sys 32.63 (33%) wall 14237 kB (13%) ggc integrated RA : 33.77 (35%) usr 0.05 (23%) sys 33.79 (35%) wall 26565 kB (24%) ggc TOTAL : 97.66 0.2297.88 111079 kB I have a stack limit of 8MB configured.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Funny, the backtrace claims that 0x80001de7 ist main.main+23 (#0 of the backtrace), but it actually is main.main-1 (#7).
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 --- Comment #5 from David Malcolm dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Tue Jun 2 18:45:50 2015 New Revision: 224041 URL: https://gcc.gnu.org/viewcvs?rev=224041root=gccview=rev Log: PR c/66220: Fix false positive from -Wmisleading-indentation gcc/c-family/ChangeLog: PR c/66220: * c-indentation.c (should_warn_for_misleading_indentation): Use expand_location rather than expand_location_to_spelling_point. Don't warn if the guarding statement is more indented than the next/body stmts. gcc/testsuite/ChangeLog: PR c/66220: * c-c++-common/Wmisleading-indentation.c (fn_35): New. (fn_36): New. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-indentation.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
[Bug c++/66067] [5/6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 35682 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35682action=edit Somewhat reduced testcase
[Bug c/66220] -Wmisleading-indentation false/inconsistent warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm dmalcolm at gcc dot gnu.org --- (In reply to Franz Sirl from comment #4) Patch from #c3 works fine for our codebase, I couldn't spot any false positives anymore. Thanks. Should be fixed as of r224041.
[Bug ada/66384] New: Compiler fails with message compilation abandoned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66384 Bug ID: 66384 Summary: Compiler fails with message compilation abandoned Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: andrewborrill at hotmail dot co.uk Target Milestone: --- Created attachment 35684 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35684action=edit All ada specs bodies which have been gnat chopped and concatinated into the bigfile This is the error in more detail: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.4.3/gnat1 -quiet -dumpbase controller.adb -mtune=generic -march=i486 controller.adb -o controller.s +===GNAT BUG DETECTED==+ | 4.4.3 (i486-pc-linux-gnu) Assert_Failure sinfo.adb:880 | | Error detected at controller.adb:337:37 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. controller.adb util.ads util-streams.ads util-streams-pipes.ads util-processes.ads util-streams-buffered.ads util-streams-texts.ads util-texts.ads util-texts-transforms.ads debug_exceptions.ads list may be incomplete controller.adb:337:64: missing ) compilation abandoned
[Bug libfortran/66385] ICE: FORALL writing multiple elements of one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66385 --- Comment #1 from Mianzhi Wang wangmianzhi1 at linuxmail dot org --- The bug is bypassed by -fno-frontend-optimize, same as in the case of 66050 and 66386.
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-02 Summary|[5/6 Regression] tree check |[6 Regression] tree check |ICE: accessed elt 1 of |ICE: accessed elt 1 of |tree_vec with 0 elts in |tree_vec with 0 elts in |write_template_args, at |write_template_args, at |cp/mangle.c:2574|cp/mangle.c:2574 Ever confirmed|0 |1 Known to fail|5.1.1 | --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Cannot reproduce the issue with 5.1.1.
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Here's a slightly different testcase, which works as expected. module constant integer x1, x2, y1, y2 equivalence (y1,x1), (x2,y2) end module program test use constant y1 = 1 x2 = 2 call another() contains subroutine another() use constant, only : x1, y2 if (x1 /= 1 .or. x2 /= 2) call abort end subroutine end program Thus, there is something about the arrayness of x in the original testcase that matters. Off-by-one maybe?
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377
--- Comment #2 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Jun 02, 2015 at 06:41:53PM +, kargl at gcc dot gnu.org wrote:
Thus, there is something about the arrayness of x in
the original testcase that matters. Off-by-one maybe?
There certainly is an appearance of off-by-one.
For the original testcase, if I use -fdump-tree-original
and remove the unessential portions of the dump, I get
another ()
{
static integer(kind=4) x1 [value-expr: constant.eq.1.x1];
static integer(kind=4) x[2] [value-expr: constant.eq.1.x];
}
test ()
{
static integer(kind=4) x1 [value-expr: constant.eq.0.x1];
static integer(kind=4) x2 [value-expr: constant.eq.0.x2];
static integer(kind=4) x[2] [value-expr: constant.eq.0.x];
}
If I change
subroutine another()
use constant, only : x1
if (x1 /= 1) call abort
end subroutine
to
subroutine another()
use constant, only : x1,x
if (x1 /= 1) call abort
end subroutine
everything works. The -fdump-tree-original then gives
another ()
{
static integer(kind=4) x1 [value-expr: constant.eq.0.x1];
static integer(kind=4) x2 [value-expr: constant.eq.0.x2];
static integer(kind=4) x[2] [value-expr: constant.eq.0.x];
}
with the same reduced test(). I haven't checked on what
constant.eq.0.x versus constant.eq.1.x means. Who's our
equivalence guru?
[Bug fortran/66386] New: ICE: FORALL reading multiple elements from one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66386 Bug ID: 66386 Summary: ICE: FORALL reading multiple elements from one array Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: wangmianzhi1 at linuxmail dot org Target Milestone: --- The ICE is triggered when compiling the following code with -O1 or higher -O levels. program test double precision::a(30),b(3,10) a(:)=1d0 forall(i=1:10) b(:,i)=a(10*[0,1,2]+i) end forall end program
[Bug fortran/66386] ICE: FORALL reading multiple elements from one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66386 --- Comment #1 from Mianzhi Wang wangmianzhi1 at linuxmail dot org --- The bug is bypassed by -fno-frontend-optimize
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #5 from James Almer jamrial at gmail dot com --- Created attachment 35683 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35683action=edit Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 svn 223417 How about this one? Crashes with segmentation fault on gcc 5.1.1 svn 223417 (ArchLinux x86_64). With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE as the first test case. I can post that -freport-bug output if needed.
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 2 17:50:23 2015 New Revision: 224039 URL: https://gcc.gnu.org/viewcvs?rev=224039root=gccview=rev Log: PR bootstrap/66319 * configure.ac: Use -std=gnu++98. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug c++/65966] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966
--- Comment #3 from Lewis Hyatt lhyatt at gmail dot com ---
Hello-
I thought it would make sense to ping this one again a month later, I am afraid
I may have confused matters by mixing two separate issues in one report...
Definitely the second issue is already covered in other bug reports, but I
believe the main one is a new regression in 5.1 vs 4.9, so it ought to be
marked as such rather than unconfirmed, no?
Just to recap, here is the testcase:
struct A {
A();
~A();
};
struct B {
A a{};
};
struct C {
B array[100][100];
} c;
=
and it breaks starting at rev 220544:
https://gcc.gnu.org/viewcvs?rev=220544root=gccview=rev
I just confirmed it is still broken on the current mainline.
Thanks!
-Lewis
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to James Almer from comment #5) Created attachment 35683 [details] Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 svn 223417 How about this one? Crashes with segmentation fault on gcc 5.1.1 (ArchLinux x86_64). With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE as the first test case. I can post that -freport-bug output if needed. I'm using gcc version 5.1.1 20150519. Will recheck with an updated version tomorrow.
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #7 from James Almer jamrial at gmail dot com --- (In reply to Markus Trippelsdorf from comment #6) (In reply to James Almer from comment #5) Created attachment 35683 [details] Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 svn 223417 How about this one? Crashes with segmentation fault on gcc 5.1.1 (ArchLinux x86_64). With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE as the first test case. I can post that -freport-bug output if needed. I'm using gcc version 5.1.1 20150519. Will recheck with an updated version tomorrow. That's the one that crashed for me with this new test case. svn 223417 (used for the 20150519 weekly snapshot).
[Bug libfortran/66385] New: ICE: FORALL writing multiple elements of one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66385 Bug ID: 66385 Summary: ICE: FORALL writing multiple elements of one array Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: wangmianzhi1 at linuxmail dot org Target Milestone: --- The ICE is triggered when compiling the following code with -O1 or higher -O levels. program test double precision::a(30) forall(i=1:10) a(10*[0,1,2]+i)=1d0 end forall end program
[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 Adam Conrad adconrad at 0c3 dot net changed: What|Removed |Added CC||adconrad at 0c3 dot net --- Comment #4 from Adam Conrad adconrad at 0c3 dot net --- No, this is specifically about powerpc-linux-gnu. powerpc64le works fine. As for the library path questions, this first came up in runtime bug reports, and has been confirmed by many on clean chroots, so no, there aren't random libraries kicking around from other builds. doko's stack-protector discovery makes perfect sense as to why this works fine on Debian but not Ubuntu, as that's really the only difference between our two toolchains. Now, the question is *why*, and why only on ppc32? (Or maybe only on big-endian PPC, neither of us has tested a powerpc64-linux-gnu build yet).
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #3) (In reply to Oleg Endo from comment #2) Defaulting -mlra might be reasonable for gcc 6. For gcc 5, I thought the patch for prepare_move_operands like diff --git a/config/sh/sh.c b/config/sh/sh.c index 1cf6ed0..b855d70 100644 --- a/config/sh/sh.c +++ b/config/sh/sh.c @@ -1789,9 +1789,8 @@ prepare_move_operands (rtx operands[], machine_mode mode) target/55212. We split possible load/store to two move insns via r0 so as to shorten R0 live range. It will make some codes worse but will -win on avarage for LRA. */ - else if (sh_lra_p () - TARGET_SH1 ! TARGET_SH2A +win on avarage. */ + else if (TARGET_SH1 ! TARGET_SH2A (mode == QImode || mode == HImode) ((REG_P (operands[0]) MEM_P (operands[1])) || (REG_P (operands[1]) MEM_P (operands[0] which would be a simplest form of the preallocating r0 for this limited case, though I'm afraid that it's still too invasive for the release branch. There could be some negative side effects with the patch above, because it forces the R0 usage quite early (at RTL expansion). I'd like to give the RTL pass a try, although it's probably even more invasive than the patch above.
[Bug ipa/66342] [6 regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++11 scan-ipa-dump icf Equal symbols: [67]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- I have patch in testing for this.
[Bug target/66363] ICE in modified test inline-39.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66363 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Hmm, ipa-inline's transform pass does fixup_cfg and other things that are not really optional, so perhaps we should not support disabling it?
[Bug rtl-optimization/66351] [6 regression] r223883 miscompiles stage2 compiler on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66351 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Hello, the following patch should fix the miscompilation: Index: ipa-polymorphic-call.c === --- ipa-polymorphic-call.c (revision 224053) +++ ipa-polymorphic-call.c (working copy) @@ -1602,6 +1603,8 @@ } } } + if (!instance_ref) + return false; } } this issue here is that for OBJ_TYPE_REF we start the alias oracle walk looking for vtbl change from wrong instruction - it should not start by call, it should start by load of vptr. This path is originally copied from ipa-prop code so it was in for a while. Reason why i did not commit the patch to mianline yet is that I do not 100% understand why it breaks in case of ipa-icf.c because the load should alias with the vptr store, too. What happens is that the call is devirtualized by GVN first, so perhaps we turn the call to pure and lose the link, but I wanted to analyze this first. I will bootstrap and regtest the patch on x86_64 and I guess it should go in if it fixes the ia64 bootstrap issue (which i can't test apparently).
[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02876.html
[Bug middle-end/66325] [6 Regression] ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz --- The ICE backtrace is: 930408-1.c:6:1: error: type variant differs by TYPE_PACKED. } s; ^ enumeral_type 0x7f7dbda115e8 foo asm_written unsigned packed type_0 QI Hmm, actually I wonder why we put TYPE_PACKED to enums? I see this at least as far back as r223695 and it appears on trunk at r223800. Honza, is this related to your type work recently? Probably, I added the verification bits, but the issue is in the tree probably for ags. Honza
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #2 from Jim Wilson wilson at gcc dot gnu.org --- Author: wilson Date: Wed Jun 3 00:46:19 2015 New Revision: 224054 URL: https://gcc.gnu.org/viewcvs?rev=224054root=gccview=rev Log: gcc/ PR target/66258 * config/aarch64/aarch64.c (aarch64_function_value_regno_p): Change !TARGET_GENERAL_REGS_ONLY to TARGET_FLOAT. (aarch64_secondary_reload): Likewise (aarch64_expand_builtin_va_start): Change TARGET_GENERAL_REGS_ONLY to !TARGET_FLOAT. (aarch64_gimplify_va_arg_expr, aarch64_setup_incoming_varargs): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 Jim Wilson wilson at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jim Wilson wilson at gcc dot gnu.org --- Patch approved and checked in on mainline.
[Bug fortran/66380] ICE for intrinsic reshape with insufficient number of array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66380 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Jun 02, 2015 at 11:37:27PM +, sgk at troutmask dot apl.washington.edu wrote: OK. Digging a little deeper. The problem is in module.c (load_equiv). There is a section of code (lines 4526-4534) that tries to avoid loading unused equivalenced symbols. If those lines are commented out, the original code works. Run gmake check-gfortran with the commented out code does not cause any regressions. The question I guess is this some attempt at an optimization.
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #3 from Jim Wilson wilson at gcc dot gnu.org --- The patch doesn't completely fix grub, because grub is trying to compile FP code with +nofp, which can't work without a soft-float ABI, which we don't have. So grub gets an error instead of an ICE with the patch. However, apparently the Aarch64 UEFI spec requires FP, so grub can be changed to stop using +nofp.
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377
--- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Jun 02, 2015 at 07:04:21PM +, sgk at troutmask dot
apl.washington.edu wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377
--- Comment #2 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Jun 02, 2015 at 06:41:53PM +, kargl at gcc dot gnu.org wrote:
Thus, there is something about the arrayness of x in
the original testcase that matters. Off-by-one maybe?
There certainly is an appearance of off-by-one.
For the original testcase, if I use -fdump-tree-original
and remove the unessential portions of the dump, I get
another ()
{
static integer(kind=4) x1 [value-expr: constant.eq.1.x1];
static integer(kind=4) x[2] [value-expr: constant.eq.1.x];
}
test ()
{
static integer(kind=4) x1 [value-expr: constant.eq.0.x1];
static integer(kind=4) x2 [value-expr: constant.eq.0.x2];
static integer(kind=4) x[2] [value-expr: constant.eq.0.x];
}
OK. Digging a little deeper. The problem is in
module.c (load_equiv). There is a section of code
(lines 4526-4534) that tries to avoid loading unused
equivalenced symbols. If those lines are commented
out, the original code works.
In looking at these lines and neighboring code, it looks
like an singly-linked list is constructed from the
equivalence in the module file, but it is compressed due
to the missing (ie unused symbols). So, it still suspect
a counting problem.
[Bug target/65768] sub-optimimal code for constant Uses in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768 kugan at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from kugan at gcc dot gnu.org --- Fixed now.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 --- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #6) There could be some negative side effects with the patch above, because it forces the R0 usage quite early (at RTL expansion). Yes, the comment part says it and it was discussed in #c83 and #c82 of PR55212. This patch will be a 'micro-degradation', though it wins CSiBE for the code size at least, even without LRA. I'd like to give the RTL pass a try, although it's probably even more invasive than the patch above. It sounds better and OK for trunk. Also yes, it looks too invasive for the release branch.
[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #7 from Steven Noonan steven at uplinklabs dot net --- Tried applying the patch mentioned in comment 6 and doing a build using --with-build-config=bootstrap-lto. Ended with: [...] /build/gcc-multilib/src/gcc-build/./prev-gcc/xgcc -B/build/gcc-multilib/src/gcc-build/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin / -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem / usr/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -flto=jobserver -frandom-seed=1 -gnatpg -W -Wall -nostdinc -I- -I. -Iada/gene rated -Iada -I/build/gcc-multilib/src/gcc-5-20150602/gcc/ada -I/build/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface /build/gc c-multilib/src/gcc-5-20150602/gcc/ada/comperr.adb -o ada/comperr.o [...] raised STORAGE_ERROR : stack overflow or erroneous memory access /build/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface/Make-lang.in:119: recipe for target 'ada/comperr.o' failed Ideas?
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 --- Comment #8 from James Almer jamrial at gmail dot com --- (In reply to James Almer from comment #7) (In reply to Markus Trippelsdorf from comment #6) (In reply to James Almer from comment #5) Created attachment 35683 [details] Preprocessed source as generated by -freport-bug, third test case, gcc 5.1.1 svn 223417 How about this one? Crashes with segmentation fault on gcc 5.1.1 (ArchLinux x86_64). With gcc 6.0.0 svn 223906 it crashes with apparently the same tree_check ICE as the first test case. I can post that -freport-bug output if needed. I'm using gcc version 5.1.1 20150519. Will recheck with an updated version tomorrow. That's the one that crashed for me with this new test case. svn 223417 (used for the 20150519 weekly snapshot). Looks like a heisenbug. Can't reproduce it when i use the preprocessed output created by -freport-bug, only when i try to normally compile the file. If the same happens in your end, you could try (with gcc 5.1.1): git clone https://github.com/ericniebler/range-v3.git cd range-v3 mkdir build cd build cmake .. make alg.partial_sort_copy
[Bug c++/66387] New: [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387
Bug ID: 66387
Summary: [5/6 Regression] ICE in make_decl_rtl with lambda
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
template typename T
void
bar (T x)
{
x ();
}
void
foo ()
{
constexpr int a[1] = { 1 };
bar ([]{ return a[0]; });
}
ICEs with -std=c++11 and -std=c++14 starting with r217814.
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 --- Comment #5 from Matthias Klose doko at gcc dot gnu.org --- building trunk libgo with -fstack-protector-strong yields: $ go version fatal error: unexpected signal during runtime execution [signal 0xb code=0x1 addr=0x3] goroutine 16 [running]: :0 :0 :0 :0 [...] building libgo and libbacktrace with -fstack-protector-strong yields: fatal error: unexpected signal during runtime execution [signal 0xb code=0x1 addr=0x3] goroutine 16 [running]: runtime_dopanic ../../../src/libgo/runtime/panic.c:131 runtime_throw ../../../src/libgo/runtime/panic.c:193 sig_panic_leadin ../../../src/libgo/runtime/go-signal.c:247 sig_panic_info_handler ../../../src/libgo/runtime/go-signal.c:281 :0 __go_go ../../../src/libgo/runtime/proc.c:2328 runtime_main ../../../src/libgo/runtime/proc.c:598 goroutine 0 [idle]: panic during panic goroutine 0 [idle]: runtime_dopanic ../../../src/libgo/runtime/panic.c:131 runtime_startpanic ../../../src/libgo/runtime/panic.c:100 runtime_throw ../../../src/libgo/runtime/panic.c:191 runtime_gogo ../../../src/libgo/runtime/proc.c:251 runtime_tracebackothers ../../../src/libgo/runtime/proc.c:767 runtime_dopanic ../../../src/libgo/runtime/panic.c:139 runtime_throw ../../../src/libgo/runtime/panic.c:193 sig_panic_leadin ../../../src/libgo/runtime/go-signal.c:247 sig_panic_info_handler ../../../src/libgo/runtime/go-signal.c:281 :0 __go_go ../../../src/libgo/runtime/proc.c:2328 runtime_main ../../../src/libgo/runtime/proc.c:598
[Bug target/65768] sub-optimimal code for constant Uses in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768 --- Comment #3 from kugan at gcc dot gnu.org --- Author: kugan Date: Tue Jun 2 22:53:15 2015 New Revision: 224048 URL: https://gcc.gnu.org/viewcvs?rev=224048root=gccview=rev Log: gcc/ChangeLog: 2015-06-03 Kugan Vivekanandarajah kug...@linaro.org Zhenqiang Chen zhenqiang.c...@linaro.org PR target/65768 * cprop.c (try_replace_reg): Check cost of constants before propagating. gcc/testsuite/ChangeLog: 2015-06-03 Kugan Vivekanandarajah kug...@linaro.org PR target/65768 * gcc.target/arm/maskdata.c: Remove -fno-gcse. Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/maskdata.c
[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 Ondrej Bilka neleai at seznam dot cz changed: What|Removed |Added CC||neleai at seznam dot cz --- Comment #13 from Ondrej Bilka neleai at seznam dot cz --- Yes, this is duplicate of following. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 Until thats fixed you should compile everything with -fno-builtin-strcmp -fno-builtin-memcmp
[Bug fortran/66380] ICE for intrinsic reshape with insufficient number of array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66380 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Jun 2 23:02:05 2015 New Revision: 224049 URL: https://gcc.gnu.org/viewcvs?rev=224049root=gccview=rev Log: 2015-06-02 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66380 * simplify.c (gfc_simplify_reshape): Convert assert into returning NULL, which triggers an error condition. 2015-06-02 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66380 * gfortran.dg/reshape_7.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/reshape_7.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/simplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #40 from amker at gcc dot gnu.org --- The issue array reference not recognized as IV is resolved now. From gimple optimizer's view, there is still another issue in which loop header is bloated because of lose of signness information. The root cause is we use sizetype for addresses, and unsigned type (unsigned int in this case) for loop niter. We need to prove (sizetype)(unsigned int)(i - 1) equals to (sizetype)(i-1) in this case by using VRP/loop initial conditions. I am fixing this now.
[Bug tree-optimization/66388] New: Test gcc.target/i386/pr49781-1.c failed because of recent scev overflow patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66388 Bug ID: 66388 Summary: Test gcc.target/i386/pr49781-1.c failed because of recent scev overflow patches. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Target Milestone: --- gcc.target/i386/pr49781-1.c failed because of recent scev overflow patches at revisions 224009/224020. Seems IVO made worse choice with more IVs recognized. I will investigate this issue. FAIL: gcc.target/i386/pr49781-1.c scan-assembler-not lea[lq]?[ \t]\\((%|)r[a-z0-9]*
[Bug c++/65843] [5/6 Regression] multiple use of const variable in lamba in template function causes compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843 Sebastien Alaiwan sebastien.alaiwan at gmail dot com changed: What|Removed |Added CC||sebastien.alaiwan at gmail dot com --- Comment #2 from Sebastien Alaiwan sebastien.alaiwan at gmail dot com --- *** Bug 66374 has been marked as a duplicate of this bug. ***
[Bug c++/66374] [5/6 Regression] template function accessing a temporary through a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66374 Sebastien Alaiwan sebastien.alaiwan at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Sebastien Alaiwan sebastien.alaiwan at gmail dot com --- duplicate *** This bug has been marked as a duplicate of bug 65843 ***
[Bug target/66389] New: sh2eb-linux-* is not recognized by configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66389 Bug ID: 66389 Summary: sh2eb-linux-* is not recognized by configure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- The processor type sh2eb is not recognized by configure, at least not for Linux targets, and the only way I could find to get a working big endian sh2 compiler was to use sheb-linux-*, yielding default code generation for sh1 rather than sh2. Binutils is affected by the same issue. Reportedly this is a regression since 4.2.1 and binutils 2.17.
[Bug c++/61683] decltype-specifier not accepted as mem-initializer-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61683 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Jun 2 10:28:14 2015 New Revision: 224022 URL: https://gcc.gnu.org/viewcvs?rev=224022root=gccview=rev Log: /cp 2015-06-02 Paolo Carlini paolo.carl...@oracle.com PR c++/61683 * parser.c (cp_parser_mem_initializer): Allow for decltype-specifier. /testsuite 2015-06-02 Paolo Carlini paolo.carl...@oracle.com PR c++/61683 * g++.dg/cpp0x/decltype-mem-initializer1.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype-mem-initializer1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-02 Blocks||32834 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 [Bug 32834] [Meta-bug] 'Fortran 95'-only failures
[Bug target/66369] gcc 4.8.3/5.1.0 miss optimisation with vpmovmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66369 --- Comment #3 from Marcus Kool marcus.kool at urlfilterdb dot com --- The intrinsic returns int, and from the above tree dump, the compiler won't even consider to combine the sign-extension with vpmovmskb. That is the core of the issue: the part of gcc that deals with intrinsics does not consider to use the 64bit version of the vpmovmskb instruction. BTW: how is gcc behaving on a system with AVX512 ?
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Hum.
bb 5:
# prephitmp_22 = PHI 0(4), c.2_15(10)
...
e_12 = (char) prephitmp_22;
_13 = (int) e_12;
...
c.2_15 = _13 + -11;
Simulating statement (from ssa_edges): prephitmp_22 = PHI 0(4), c.2_15(10)
Visiting PHI node: prephitmp_22 = PHI 0(4), c.2_15(10)
Argument #0 (4 - 5 executable)
0: [0, 0]
Argument #1 (10 - 5 executable)
c.2_15: [-22, -11]
Meeting
[0, 0]
and
[-22, -11]
to
[-22, 0]
...
Found new range for prephitmp_22: [-2147483647, 0]
...
Visiting statement:
_13 = (int) e_12;
Intersecting
[-128, 127]
and
[-128, 127]
to
[-128, 127]
Found new range for _13: [-128, 127]
marking stmt to be not simulated again
Simulating statement (from ssa_edges): c.2_15 = _13 + -11;
Visiting statement:
c.2_15 = _13 + -11;
Found new range for c.2_15: [-139, 116]
marking stmt to be not simulated again
Simulating statement (from ssa_edges): prephitmp_22 = PHI 0(4), c.2_15(10)
Visiting PHI node: prephitmp_22 = PHI 0(4), c.2_15(10)
Argument #0 (4 - 5 executable)
0: [0, 0]
Argument #1 (10 - 5 executable)
c.2_15: [-139, 116]
Meeting
[0, 0]
and
[-139, 116]
to
[-139, 116]
marking stmt to be not simulated again
(note no Found new range for prephitmp_22 here!)
Value ranges after VRP:
prephitmp_22: [-2147483647, 0]
oops.
This seems to be because we drop to [-2147483647, 2147483646] but then
adjust_range_with_scev computes {0, +, -11}_1 for _22 which is obviously
wrong.
It looks like the CHREC gets built from
static t_bool
follow_ssa_edge_binary (struct loop *loop, gimple at_stmt,
tree type, tree rhs0, enum tree_code code, tree rhs1,
gphi *halting_phi, tree *evolution_of_loop,
int limit)
{
...
switch (code)
{
case POINTER_PLUS_EXPR:
case PLUS_EXPR:
if (TREE_CODE (rhs0) == SSA_NAME)
{
if (TREE_CODE (rhs1) == SSA_NAME)
{
...
else
{
/* Match an assignment under the form:
a = b + */
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
evolution_of_loop, limit);
if (res == t_true)
*evolution_of_loop = add_to_evolution
(loop-num, chrec_convert (type, *evolution_of_loop,
at_stmt),
code, rhs1, at_stmt);
and what goes wrong is follow_ssa_edge skipping the (unsigned char) truncation.
Still digging...
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Indeed as we just feed the initial condition to chrec_convert it happily just
fold_convert()s the zero to signed char and then back to int ...
So
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
evolution_of_loop, limit);
if (res == t_true)
*evolution_of_loop = add_to_evolution
(loop-num, chrec_convert (type, *evolution_of_loop,
at_stmt),
code, rhs1, at_stmt);
doesn't work at all (the follow_ssa_edge call just picking up the initial
value converted to the type of the add).
static tree
analyze_evolution_in_loop (gphi *loop_phi_node,
tree init_cond)
{
...
/* Pass in the initial condition to the follow edge function. */
ev_fn = init_cond;
res = follow_ssa_edge (loop, ssa_chain, loop_phi_node, ev_fn, 0);
I suppose a trick would be to always pass a symbolic initial condition
but then this would likely pessimize code. With that we get
(add_to_evolution
(loop_nb = 1)
(chrec_before = (int) (signed char) D.1876)
(to_add = -11)
(res = {(int) (signed char) D.1876, +, -11}_1))
(evolution_function = {(int) (signed char) 0, +, -11}_1))
Hmm, but that isn't correct either. We want (int)(signed char){(int)0, +,
-11)_1
Sorter testcase pin-pointing the issue in VRP/SCEV:
int a;
extern void abort (void);
int main ()
{
int c = 0;
for (; a 13; ++a)
c = (signed char)c - 11;
if (c != 113)
abort ();
return c;
}
[Bug go/66378] New: libgo syscall.Sendfile() does not honor/use offset argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66378 Bug ID: 66378 Summary: libgo syscall.Sendfile() does not honor/use offset argument Product: gcc Version: 5.1.1 URL: https://bugs.launchpad.net/snappy/+bug/1460530 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: mvo at debian dot org CC: cmang at google dot com Target Milestone: --- Created attachment 35676 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35676action=edit Patch that make syscall.Sendfile() use offset. The implementation in libgo/go/syscall/libcall_linux.go does not use the offset argument. Instead it uses soff and poff which is never initialized with the offset provided by the user (so always zero). This means that sendfile will not be correct for any offset != 0. Attached is a patch that fixes this issue, I verified the fix against our failing snappy testsuite that has a test for sendfile with alternative offsets.
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #14 from amker at gcc dot gnu.org --- Author: amker Date: Tue Jun 2 10:19:18 2015 New Revision: 224020 URL: https://gcc.gnu.org/viewcvs?rev=224020root=gccview=rev Log: PR tree-optimization/48052 * cfgloop.h (struct control_iv): New. (struct loop): New field control_ivs. * tree-ssa-loop-niter.c : Include stor-layout.h. (number_of_iterations_lt): Set no_overflow information. (number_of_iterations_exit): Init control iv in niter struct. (record_control_iv): New. (estimate_numbers_of_iterations_loop): Call record_control_iv. (loop_exits_before_overflow): New. Interface factored out of scev_probably_wraps_p. (scev_probably_wraps_p): Factor loop niter related code into loop_exits_before_overflow. (free_numbers_of_iterations_estimates_loop): Free control ivs. * tree-ssa-loop-niter.h (free_loop_control_ivs): New. gcc/testsuite/ChangeLog PR tree-optimization/48052 * gcc.dg/tree-ssa/scev-8.c: New. * gcc.dg/tree-ssa/scev-9.c: New. * gcc.dg/tree-ssa/scev-10.c: New. * gcc.dg/vect/pr48052.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-9.c trunk/gcc/testsuite/gcc.dg/vect/pr48052.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-loop-niter.h
[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Tue Jun 2 11:48:56 2015 New Revision: 224028 URL: https://gcc.gnu.org/viewcvs?rev=224028root=gccview=rev Log: [PR libgomp/65742, PR middle-end/66332] XFAIL acc_on_device compile-time evaluation The OpenACC 2.0a specification mandates differently, but we currently do get a library call in the host code. PR libgomp/65742 PR middle-end/66332 gcc/testsuite/ * c-c++-common/goacc/acc_on_device-2.c: XFAIL for C, too. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c
[Bug libgomp/65742] [5/6 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 --- Comment #7 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Tue Jun 2 11:48:56 2015 New Revision: 224028 URL: https://gcc.gnu.org/viewcvs?rev=224028root=gccview=rev Log: [PR libgomp/65742, PR middle-end/66332] XFAIL acc_on_device compile-time evaluation The OpenACC 2.0a specification mandates differently, but we currently do get a library call in the host code. PR libgomp/65742 PR middle-end/66332 gcc/testsuite/ * c-c++-common/goacc/acc_on_device-2.c: XFAIL for C, too. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c
[Bug ada/66162] segfault on code using controlled types in -gnatc mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66162 --- Comment #6 from simon at pushface dot org --- (In reply to Eric Botcazou from comment #3) That's not the problem., just avoid using -gnatc on the runtime. Eric, In PR64866 comment 2, Arno said Visibility in the Ada runtime do not follow standard Ada rules. In other words, the Ada runtime isn't implemented in Ada, but in a different dialect very close to Ada, with additional restrictions.” He notes two of the additional restrictions: is there a writeup anywhere of the language restrictions and usage restrictions like this one? Thanks, --S
[Bug c++/66381] New: ice in dfs_enumerate_from with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66381 Bug ID: 66381 Summary: ice in dfs_enumerate_from with -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 35677 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35677action=edit C++ source code For trunk gcc dated 20150530 Cue2Toc.cc: In function ‘cuesheet* read_cue(const char*, const char*)’: Cue2Toc.cc:298:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1195 0x8dc305 dfs_enumerate_from(basic_block_def*, int, bool (*)(basic_block_def const*, void const*), basic_block_def**, int, void const*) ../../src/trunk/gcc/cfganal.c:1195 0xfabaa0 determine_bb_domination_status ../../src/trunk/gcc/tree-ssa-threadupdate.c:1768 0xfabaa0 thread_through_loop_header ../../src/trunk/gcc/tree-ssa-threadupdate.c:1953 0xfae22a thread_through_all_blocks(bool) ../../src/trunk/gcc/tree-ssa-threadupdate.c:2667 0xee203b execute ../../src/trunk/gcc/tree-ssa-dom.c:1244 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Flag -O3 required.
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Bootstrapped / tested on x86_64-unknown-linux-gnu with no regressions... testing a more complete fix (applying this to all cases in follow_ssa_edge_binary) now.
[Bug fortran/66380] New: ICE for intrinsic reshape with insufficient number of array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66380 Bug ID: 66380 Summary: ICE for intrinsic reshape with insufficient number of array elements Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code with less array elements than requested via shape sh : program p integer, parameter :: sh(2) = [2, 3] integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], sh) print *, a end yields : f951: internal compiler error: in gfc_simplify_reshape, at fortran/simplify.c:5177 --- Whereas this version : program p integer, parameter :: sh(2) = [2, 1] integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], sh) print *, a end flags an error : integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], sh) 1 Error: Different shape for array assignment at (1) on dimension 2 (2 and 1)
[Bug tree-optimization/66349] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu in dfs_enumerate_from, at cfganal.c:1195
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66349 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 66381 has been marked as a duplicate of this bug. ***
[Bug target/66369] gcc 4.8.3/5.1.0 miss optimisation with vpmovmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66369 --- Comment #4 from Marcus Kool marcus.kool at urlfilterdb dot com --- The intrinsic returns int, and from the above tree dump, the compiler won't even consider to combine the sign-extension with vpmovmskb. So, why not: unsigned int v; v = (unsigned int) _mm256_movemask_epi8( ... ); if (v != 0) return (long) __builtin_ctz( v ); Because that will produce the extra and unnecessary sign extension instructions if the result is used to index an array of structs. Can this issue be resolved by simply always letting the intrinsic producing a 64bit result and hence always producing the 64bit instruction vpmovmskb YMM,R64 ? It well be that a 64bit results is not desired and a conversion to 32bit is then required but an (implicit) conversion from a long to an int does _not_ need an instruction while conversion from int to long does need an unnecessary instruction.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #8 from Ian Lance Taylor ian at airs dot com --- The initial stack frame of a goroutine is set up by the makecontext function, which is part of the C library. Ideally makecontext should arrange matters such that a backtrace stops at that point, as pthread_create does.
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 35678 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35678action=edit patch What I am testing.
[Bug c++/66381] ice in dfs_enumerate_from with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66381 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This has been fixed. *** This bug has been marked as a duplicate of bug 66349 ***
[Bug ipa/66342] [6 regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++11 scan-ipa-dump icf Equal symbols: [67]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #7 from John David Anglin danglin at gcc dot gnu.org --- Also fails on hppa2.0w-hp-hpux11.11.
[Bug fortran/66377] New: [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 Bug ID: 66377 Summary: [F95] Wrong-code with equivalenced array in module Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- This code: module constant integer :: x(2), x1, x2 equivalence (x(1),x1), (x(2),x2) end module program test use constant x = (/1, 2/) call another() contains subroutine another() use constant, only : x1 print *, x1 end subroutine end program should output 1, but outputs 0 with all versions of gfortran tested.
[Bug target/66369] gcc 4.8.3/5.1.0 miss optimisation with vpmovmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66369 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- I have looked briefly at this. The compiler actually generates the following: vpmovmskb %ymm0, %edx # 16avx2_pmovmskb [length = 4] testl %edx, %edx # 18*cmpsi_ccno_1/1 [length = 2] je .L5 # 19*jcc_1 [length = 2] movslq %edx, %rdx # 21*extendsidi2_rex64/2[length = 3] tzcntq %rdx, %rdx # 52*ctzdi2_falsedep[length = 5] from: int _14; long unsigned int v.1_15; int _16; ... _14 = __builtin_ia32_pmovmskb256 (_13); if (_14 != 0) goto bb 5; else goto bb 6; bb 5: v.1_15 = (long unsigned int) _14; _16 = __builtin_ctzl (v.1_15); _17 = (long int) _16; The intrinsic returns int, and from the above tree dump, the compiler won't even consider to combine the sign-extension with vpmovmskb. So, why not: unsigned int v; v = (unsigned int) _mm256_movemask_epi8( ... ); if (v != 0) return (long) __builtin_ctz( v );
[Bug c++/61683] decltype-specifier not accepted as mem-initializer-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61683 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 --- Comment #7 from Dominik Vogt vogt at linux dot vnet.ibm.com --- When dumping the complete backtrace, gdb produces a warning. Maybe the libgo/runtime code does not properly set up the initial stack frame of the thread? (gdb) set backtrace past-main (gdb) bt #0 main.main () at pr66303.go:8 #1 0x03fff778a538 in runtime_main (dummy=optimized out) at ../../../libgo/runtime/proc.c:626 #2 0x03fff77879c4 in kickoff () at ../../../libgo/runtime/proc.c:235 #3 0x03fff6d89ca2 in __makecontext_ret () from /lib64/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC|law at gcc dot gnu.org |spop at gcc dot gnu.org
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Sebastian - it seems that we have to somehow tell the analysis phase that we
are analyzing an evolution, not just an initial value. Like instead of
/* Match an assignment under the form:
a = b + */
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
evolution_of_loop, limit);
if (res == t_true)
*evolution_of_loop = add_to_evolution
(loop-num, chrec_convert (type, *evolution_of_loop,
at_stmt),
code, rhs1, at_stmt);
doing the add_to_evolution first and only then following the SSA edge.
That seems to kind-of work, though the debug output is strange:
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = c_1)
(get_scalar_evolution
(scalar = c_1)
(scalar_evolution = ))
(analyze_initial_condition
(loop_phi_node =
c_1 = PHI 0(2), c_7(3)
)
(init_cond = 0))
(analyze_evolution_in_loop
(loop_phi_node = c_1 = PHI 0(2), c_7(3)
)
(add_to_evolution
(loop_nb = 1)
(chrec_before = 0)
(to_add = -11)
(res = {0, +, -11}_1))
... computing niter, from chrec_convert stuff I guess
(evolution_function = (int) (signed char) {0, +, 245}_1))
(that 245 looks wrong)
but at least the scalar evolution ends up (correctly) as being not know...
That is with
Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 224013)
+++ tree-scalar-evolution.c (working copy)
@@ -991,15 +991,15 @@ follow_ssa_edge_binary (struct loop *loo
{
/* Match an assignment under the form:
a = b + */
+ *evolution_of_loop = add_to_evolution
+ (loop-num, chrec_convert (type, *evolution_of_loop,
+at_stmt),
+ code, rhs1, at_stmt);
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
evolution_of_loop, limit);
if (res == t_true)
- *evolution_of_loop = add_to_evolution
- (loop-num, chrec_convert (type, *evolution_of_loop,
-at_stmt),
- code, rhs1, at_stmt);
-
+ ;
else if (res == t_dont_know)
*evolution_of_loop = chrec_dont_know;
}
but as said, I don't think this is correct ...? (just thrown it to testing)
[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|5.1.0 |6.0 Resolution|--- |FIXED --- Comment #3 from Thomas Schwinge tschwinge at gcc dot gnu.org --- XFAILed in r 224028. Documented: http://gcc.gnu.org/wiki/OpenACC?action=diffrev1=10rev2=11.
[Bug debug/65549] [4.9/5 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Summary|[4.9/5/6 Regression] crash |[4.9/5 Regression] crash in |in htab_hash_string with|htab_hash_string with -flto |-flto -g|-g --- Comment #33 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Let's re-open this for the original testcase.
[Bug c++/66371] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66371
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-02
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
This is what creduce came up with:
trippels@gcc75 ~ % cat cc.ii
namespace std {
template typename _Tp, _Tp struct A;
template typename, typename struct B;
template bool struct enable_if;
template typename class allocator;
template typename = allocatorint class vector {};
}
namespace meta {
template typename T, T... struct C;
template bool B using bool_ = std::Abool, B;
template typename struct D;
template template typename class struct quote;
template bool... Bools using and_c = std::BCbool, Bools..., Cbool;
template typename using fast_and = and_c;
}
template typename I, typename using common_iterator = I;
template typename T struct static_const { static constexpr T value{}; };
template typename int _nullptr_v;
template typename Concept
struct F : meta::bool_decltype(_nullptr_vConcept)::value {};
template typename... using Constructible = struct View;
template typename using range_iterator_t = View;
template typename using range_sentinel_t = View;
template typename Rng
using range_common_iterator_t =
common_iteratorrange_iterator_tRng, range_sentinel_tRng;
template typename, typename I using ReserveAndAssignable = FI;
template typename Rng, typename = range_common_iterator_tRng
using ConvertibleToContainer = meta::fast_andConstructible;
template typename struct to_container_fn {
template typename C, typename R
using ReserveConcept = meta::fast_andReserveAndAssignableC, R;
template typename Rng, typename Cont,
typename std::enable_ifConvertibleToContainerCont()
ReserveConceptCont, Rng()::type
void m_fn1();
};
auto to_vector =
static_constto_container_fnmeta::quotestd::vector::value;
template typename Cont to_container_fnmeta::DCont to_();
struct G {
operator std::vectorstd::allocatorint() { to_std::vector(); }
};
trippels@gcc75 ~ % g++ -std=c++14 -c cc.ii
cc.ii: In instantiation of ?struct
to_container_fnmeta::Dstd::vectorstd::allocatorint ?:
cc.ii:41:68: required from here
cc.ii:36:8: internal compiler error: canonical types differ for identical types
std::enable_if(ConvertibleToContainerCont() to_container_fn
template-parameter-1-1 ::ReserveConceptCont, Rng()) and
std::enable_if(ConvertibleToContainerCont, range_common_iterator_tCont ()
to_container_fnmeta::quotestd::vector ::ReserveConceptCont, Rng())
void m_fn1();
^
[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142 --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Ok, so even with PR63916 rudimentary fixed we hit the issue that in _9 = D.3665[_11].org; MEM[(struct vec_ *)_9] = 1.0e+0; MEM[(struct vec_ *)_9 + 4B] = _8; ... _24 = MEM[(const struct Ray *)D.3665][_11].org.x; the store to MEM[(struct vec_ *)_9 + 4B] aliases MEM[(const struct Ray *)D.3665][_11].org.x. And the rudimentary fix for PR63916 doesn't allow for the forwarding to succeed into MEM[(struct vec_ *)_9 + 4B] either. Without SRA we get D.3665[_11].org = p; D.3665[_11].dir.x = x_12; D.3665[_11].dir.y = y_13; D.3664[_11].t = 1.0e+10; D.3664[_11].h = 0; _25 = MEM[(const struct Ray *)D.3665][_11].org.x; and the look-through-aggregate-copy code bails out at /* See if the assignment kills REF. */ base2 = ao_ref_base (lhs_ref); offset2 = lhs_ref.offset; size2 = lhs_ref.size; maxsize2 = lhs_ref.max_size; if (maxsize2 == -1 || (base != base2 (TREE_CODE (base) != MEM_REF || TREE_CODE (base2) != MEM_REF || TREE_OPERAND (base, 0) != TREE_OPERAND (base2, 0) || !tree_int_cst_equal (TREE_OPERAND (base, 1), TREE_OPERAND (base2, 1 || offset2 offset || offset2 + size2 offset + maxsize) return (void *)-1; stmt_kills_ref_p fails to compare MEM[(const struct Ray *)D.3665][_15].org and D.3665[_15].org equal via operand_equal_p.
