[Bug lto/81351] New: [8 regression] Many LTO testcases FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81351 Bug ID: 81351 Summary: [8 regression] Many LTO testcases FAIL Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.12, sparc-sun-solaris2.12 Between 20170705 (r250005) and 20170706 (r250037), many LTO testcases started to FAIL on Solaris/SPARC and x86: +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -flto +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -flto -flto-partition=1to1 +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -flto -flto-partition=none +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -flto +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -flto -flto-partition=1to1 +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -flto -flto-partition=none +FAIL: g++.dg/torture/pr49115.C -O2 -flto execution test +FAIL: g++.dg/torture/pr49115.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/pr60750.C -O2 -flto execution test +FAIL: g++.dg/torture/pr60750.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/pr68184.C -O2 -flto execution test +FAIL: g++.dg/torture/pr68184.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-global-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-global-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-global-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-global-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-inline-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-inline-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-inline-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-inline-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-inline-2.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-inline-2.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-inline-2.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-inline-2.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/throw-1.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/throw-1.C -O2 -flto -flto-partition=none execution test +FAIL: g++.dg/torture/stackalign/throw-1.C -O2 -flto -flto-partition=none -fpic execution test +FAIL: g++.dg/torture/stackalign/throw-1.C -O2 -flto -fpic execution test +FAIL: g++.dg/torture/stackalign/throw-2.C -O2 -flto execution test +FAIL: g++.dg/torture/stackalign/throw-2.C -O2 -flto -flto-partition=none exe
[Bug sanitizer/58841] std::bad_alloc not thrown with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://github.com/google/s ||anitizers/issues/295 Resolution|--- |MOVED --- Comment #2 from Jonathan Wakely --- Yes, this is a problem in the upstream sanitizer behaviour, not something GCC can change. When using ASan I compile with -fcheck-new to avoid crashes in constructors. I also have a patch to make libstdc++'s std::allocator check for operator new returning new, and throw a std::bad_alloc instead. That at least makes all code using std::allocator do the right thing.
[Bug sanitizer/78654] ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #4 from Yuri Gribov --- Overhead seems to be intentional so perhaps close?
[Bug lto/81351] [8 regression] Many LTO testcases FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81351 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE --- > I'll start a reghunt to identify the culprit, but the most likely candidates > are [...] > changeset: 39311:a2df04e7a94b > user:hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 > date:Thu Jul 06 16:47:20 2017 + > files: gcc/ChangeLog gcc/lto-wrapper.c > description: > * lto-wrapper.c (merge_and_complain): Do not merge > fexceptions, fnon_call_exceptions, ftrapv, ffp_contract_, fmath_errno, > fsigned_zeros, ftrapping_math, fwrapv. > (append_compiler_options): Do not track these options. > (append_linker_options): Likewie Got it: just reverting svn r250035 was enough to make one of the testcases PASS again. Rainer
[Bug sanitizer/78654] ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 --- Comment #5 from Jakub Jelinek --- Not intentional, but unavoidable I think.
[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #5 from Yuri Gribov --- Has been fixed in r215527. Close?
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- When trying to compile the test I get integer(kind=INT32), parameter :: r=RADIUS! radius of stencil 1 Error: Symbol 'radius' at (1) has no IMPLICIT type What am I missing?
[Bug sanitizer/63245] renderMemorySnippet shouldn't show more bytes than the underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63245 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #3 from Yuri Gribov --- This has been fixed in r215527. Close?
[Bug sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #10 from Yuri Gribov --- This should be fixed since r229111 (and 229115). Close?
[Bug lto/81351] [8 regression] Many LTO testcases FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81351 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > Got it: just reverting svn r250035 was enough to make one of the > testcases PASS again. comparing pr49115.exe.ltrans0.s without and with the patch shows what's wrong: the broken version has lost the complete .eh_frame section. No wonder EH won't work ;-) Rainer
[Bug sanitizer/60892] GCC (libsanitizer) fails to build with Linux 2.6.21 headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60892 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- This is probly a dup of bug 59068. Can it be closed as such?
[Bug sanitizer/61995] gcc 4.9.1 fails to compile with error in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- This is probly a dup of bug 59068. Can it be closed as such?
[Bug tree-optimization/81346] Missed constant propagation into comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-07 CC||glisse at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Indeed, it is fold_div_compare in fold-const.c. Perhaps we should move the first part of that routine (the computation of lo and hi) into a helper subroutine and use that in match.pd pattern that would then based on those lo/hi trees decide how to optimize stuff?
[Bug sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Maxim Ostapenko --- Yes, fixed.
[Bug sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #12 from Ramana Radhakrishnan --- (In reply to Maxim Ostapenko from comment #11) > Yes, fixed. Fixed for GCC 6.0 I suspect.
[Bug sanitizer/78028] ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #5 from Yuri Gribov --- I was able to repro this in Ubuntu 14.04 with GCC 5.4.0 but not with GCC 6.2.0 (the latter successfully reports both leaks). Generated asm code is almost identical so probly fixed with one of libasan merges since GCC5. Ok to close?
[Bug target/81352] New: [nvptx] trap placement for non-returning function call in vector-single mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81352
Bug ID: 81352
Summary: [nvptx] trap placement for non-returning function call
in vector-single mode
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following fortran test-case:
...
program foo
integer :: a(2,2,4), k, kk, kkk
a = 2
!$acc parallel num_gangs(1) num_workers(1) vector_length(32)
!$acc loop gang(static:1)
do k=1,2
if (any(a(k,1:2,1:4).ne.2)) call abort
enddo
!$acc end parallel
end program
...
We generate the following ptx for -O2:
{
.reg .u32 %x;
mov.u32 %x,%tid.x;
setp.ne.u32 %r47,%x,0;
}
...
@ %r47 bra $L12;
{
call _gfortran_abort;
trap;
}
$L12:
$L3:
...
which results in this SASS generated with -O4:
...
/*01f8*/ ISETP.NE.U32.AND P0, PT, R21, RZ, PT;
/*0208*/ SSY `(.L_25);
/*0210*/ @P0 BRA `(.L_26);
/*0218*/ JCAL `(_gfortran_abort);
/*0220*/ BPT.TRAP 0x1;
.L_26:
/*0228*/ NOP.S;
.L_25:
...
We have to think of the diverging branch '@P0 BRA `(.L_26)' as executing both
paths, one after the other, with different threads in the warp enabled, without
any guarantee which path will be executed first.
The paths end at an instruction with the .s prefix, and after the execution of
the second path, converged execution is resumed at the target of the SSY insn:
.L_25.
So either we execute this sequence:
1. branch taken path first:
/*0208*/ SSY `(.L_25);
/*0210*/ @P0 BRA `(.L_26);
/*0228*/ NOP.S;
/*0218*/ JCAL `(_gfortran_abort);
or this one:
2. branch not taken path first:
/*0208*/ SSY `(.L_25);
/*0210*/ @P0 BRA `(.L_26);
/*0218*/ JCAL `(_gfortran_abort);
In both cases, we reliably end up at _gfortran_abort at runtime. So, the
generated code is not wrong.
But, it looks fragile to me. What guarantees us that a sync point is in fact
generated? That's not so clear, given that there's no clear post-domination
point, because one of the paths ends in a trap. And if no sync point is
generated, execution can fall through and execute random code after $L12.
Furthermore, while the trap placement right after the _gfortran_abort call is
accurate in the sense that that's the function call not returning, so that's
where the control flow barrier is, it's clear that the code does not intend to
execute past $L3 in any of the other threads in the warp.
So, the more clear (and possibly more reliable trap) placement is this:
...
@ %r47 bra $L12;
{
call _gfortran_abort;
}
$L12:
trap;
$L3:
...
Resulting in this SASS code:
...
/*01f8*/ ISETP.NE.U32.AND P0, PT, R21, RZ, PT;
/*0208*/ SSY `(.L_26);
/*0210*/ @P0 BRA `(.L_27);
/*0218*/ JCAL `(_gfortran_abort);
.L_27:
/*0220*/ NOP.S;
.L_26:
/*0228*/ BPT.TRAP 0x1;
...
Note that the trap is placed after the sync pont .L_26.
[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818 --- Comment #7 from Andreas Krebbel --- Created attachment 41699 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41699&action=edit Additional changes required ontop of the proposed patch Changes which might be required on-top of your patch. Your patch alone does not appear to fix the testcase for me. Neither the reduced nor the full version. The hard reg clobber is added in collect_non_operand_hard_regs not in add_regs_to_insn_regno_info. Copying what your patch does in add_regs_to_insn_regno_info to collect_non_operand_hard_regs does fix the problem for me.
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- You've probably missed the -DRADIUS=2 -DSTAR
[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > Once I enable a floating point exception trap with "-ffpe-trap=whatever", > it doesn't seem to be possible to disable it in the same command line > (as it is possible with warnings, for instance. An empty list as in > "-ffpe-trap=" is accepted, but it doesn't disable traps. AFAIU gfc_handle_fpe_option in gcc/fortran/options.c, '-ffpe-trap=set1 -ffpe-trap=set2' is equivalent to '-ffpe-trap=set1,set2'. If it helps, I can add a line in the manual. Note that this is not true for '-ffpe-summary=set1 -ffpe-summary=set2' which reports the exceptions for set2 only. > This would be useful when using a tool like CMake, where it is convenient > to set a default set of flags, and then override them if desired in specific > files, rather. (1) You cal always use '-ffpe-trap=set1,set2' for some files and '-ffpe-trap=set1' for some other files. (2) You can look at the code implementing -fcheck=no-diag and implement a -ffpe-trap=no-execpt. IMO it does not worth the trouble. The above have been tested with ! test the -ffpe-trap= and -ffpe-summary= options. program main real a,b,c a=1e-20 b=a**2 print *,b a=0 b=0 c=a/b print *,c c=1./b print *,c STOP end
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 --- Comment #3 from Jakub Jelinek --- That said, I believe it is just a buggy testcase. In the 4 taskloop directives in apply_stencil I believe the rule for implicit data-sharing of W, A and B variables is: "In an orphaned task generating construct, if no default clause is present, dummy arguments are firstprivate." but of course, you actually rely on at least B to be shared and for efficiency it is desirable that W and A are also shared. Also, why so many taskwait directives everywhere? taskloop without nogroup clause will wait at the !$omp taskloop end until all those tasks finish.
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 --- Comment #4 from Jakub Jelinek --- Note if I add shared(W,A,B) clause to the 4 taskloop directives in apply_stencil, no errors are reported.
[Bug middle-end/70801] IRA caller-saves does not support rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70801 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-07 CC||wilco at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Wilco --- This is fixed by improving aarch64_legitimate_constant_p: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00359.html
[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331 Rainer Orth changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu, ||i386-pc-solaris2.12 Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-07 CC||ro at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Rainer Orth --- I already see it at r249926 on i386-pc-solaris2.12 (32-bit only), so it appeared between r249882 and r249926. Rainer
[Bug libstdc++/81353] New: Please provide a libstdc++ version macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81353 Bug ID: 81353 Summary: Please provide a libstdc++ version macro Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: coypu at sdf dot org Target Milestone: --- occasionally workarounds are needed for old libstdc++ versions, it would be easier to do so with the help of a macro. if the compiler used is not GCC, we can't check for GCC's version.
[Bug libstdc++/78905] Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 Jonathan Wakely changed: What|Removed |Added CC||coypu at sdf dot org --- Comment #11 from Jonathan Wakely --- *** Bug 81353 has been marked as a duplicate of this bug. ***
[Bug libstdc++/81353] Please provide a libstdc++ version macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81353 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Already done. *** This bug has been marked as a duplicate of bug 78905 ***
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Jeff Hammond changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeff Hammond --- You are right. This is a bogus bug report. I am still figuring out how to use TASKLOOP correctly. Sorry for the trouble.
[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Jeff Hammond changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069
--- Comment #3 from Tom de Vries ---
The immediate reason for the failure is a bug in the ptx JIT compiler.
This piece of ptx code (containing two functionally equivalent but differently
layed out variants, DETOUR=0 and DETOUR=1) is a minimal example, and is
translated correctly for DETOUR=0 and incorrectly for DETOUR=1:
...
.version 3.1
.target sm_30
.address_size 64
.entry test_function (.param .u64 %in_ar0);
.entry test_function (.param .u64 %in_ar0)
{
// Init %ra to 0 in all lanes.
.reg .u32 %ra;
mov.u32 %ra,0;
// Branch around if not lane 0.
{
.reg .u32 %l;
mov.u32 %l,%laneid;
.reg .pred %lane0;
setp.eq.u32 %lane0,%l,0;
@ ! %lane0 bra $L20;
}
bra $L3;
#if DETOUR == 0
$L3:
// Set %ra to 1 in lane zero
mov.u32 %ra,1;
$L20:
bra $L8;
#endif
$L8:
// Broadcast %ra from lane 0 to all lanes
shfl.idx.b32 %ra,%ra,0,31;
// Branch to trap if %ra not 1 in all lanes
{
.reg .pred %ra_is_one;
setp.eq.u32 %ra_is_one,%ra,1;
@ ! %ra_is_one bra $L6;
}
ret;
$L6:
trap;
#if DETOUR == 1
$L3:
// Set %ra to 1 in lane zero
mov.u32 %ra,1;
$L20:
bra $L8;
#endif
}
...
The problem for the DETOUR=1 case is that while the divergent branch '@ !
%lane0 bra $L20' is post-dominated by $L20, the synchronization point is
inserted much later, after the shfl. This means the shfl is executed in
divergent state, which invokes undefined behaviour, causing an undefined result
%ra in one of the threads in the warp, which causes the example to call the
trap.
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 Wilco changed: What|Removed |Added Status|NEW |RESOLVED CC||wilco at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Wilco --- Confirmed fixed on trunk.
[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119 Wilco changed: What|Removed |Added Target Milestone|--- |8.0
[Bug sanitizer/78028] ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 David Barto changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from David Barto --- OK to close by me. Thanks for the research.
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 --- Comment #4 from Tom de Vries --- > The immediate reason for the failure is a bug in the ptx JIT compiler. The minimal openacc program triggering this is: ... program foo integer :: a(2,2,4), k, kk, kkk a = 2 !$acc parallel num_gangs(1) num_workers(1) vector_length(32) !$acc loop gang(static:1) do k=1,2 if (any(a(k,1:2,1:4).ne.2)) call abort enddo !$acc loop gang(static:1) do k=1,2 if (any(a(k,1:2,1:4).ne.2)) call abort enddo !$acc end parallel end program ... With -mno-optimize we have: ... @!%r52 bra.uni $L4; bra $L3; ... $L3: @%r65 bra $L18; mov.u32 %r23, %r64; setp.ne.u32 %r59, %r30, 1; $L18: ... and with -moptimize we have: ... @!%r52 bra.uni $L4; @%r65 bra $L20; bra $L3; ... $L3: mov.u32 %r23, %r64; setp.ne.u32 %r59, %r30, 1; $L20: ... So, -moptimize has extended the sese region being neutered, by including the branch to $L3. In general the point of -moptimize is to combine individual blocks that need to be neutered: ... if !V0 goto L1; A L1: if !V0 goto L2; B L2: ... into neutering of a sese region containing the blocks: ... if !V0 goto L2; A B L2: ... But in this case, we're extending the sese region being neutered to include a branch that doesn't have to be neutered. I don't think there's a purpose in doing that.
[Bug target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81348 --- Comment #4 from Michael Meissner --- Author: meissner Date: Fri Jul 7 17:02:58 2017 New Revision: 250054 URL: https://gcc.gnu.org/viewcvs?rev=250054&root=gcc&view=rev Log: [gcc] 2017-07-07 Michael Meissner PR target/81348 * config/rs6000/rs6000.md (HI sign_extend splitter): Use the correct operand in doing the split. [gcc/testsuite] 2017-07-07 Michael Meissner PR target/81348 * gcc.target/powerpc/pr81348.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr81348.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug target/81317] builtin_vec_ld fails for powerpc with altivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317 --- Comment #7 from Randy MacLeod --- Is anyone working on this bug? I'm not pushing, but rather trying to understand what to expect.
[Bug c++/81354] New: Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354
Bug ID: 81354
Summary: Segmentation fault in SSA Strength Reduction using -O3
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jgrossma at qti dot qualcomm.com
Target Milestone: ---
The following is a complete testcase:
struct T { double a; double b; };
void foo(T Ad[], int As[2])
{
int j;
int i;
int Bs[2] = {0,0};
T Bd[16];
for (j = 0; j < 4; j++) {
for (i = 0; i + 1 <= j + 1; i++) {
Ad[i + As[0] * j] = Bd[i + Bs[0] * j];
}
i = j + 1; // <- comment out this line and it does not crash
for (; i + 1 < 5; i++) {
Ad[i + As[0] * j].a = 0.0;
Ad[i + As[0] * j].b = 0.0;
}
}
}
This crashes when compiled as follows:
$ g++ -c test.cpp -O3
test.cpp: In function ‘void foo(T*, int*)’:
test.cpp:3:6: internal compiler error: Segmentation fault
void foo(T Ad[], int As[2])
^
0xaf6acf crash_signal
../../gcc/toplev.c:383
0xfef7b0 record_phi_increments
../../gcc/gimple-ssa-strength-reduction.c:2590
0xfef795 record_phi_increments
../../gcc/gimple-ssa-strength-reduction.c:2601
0xfef8f9 record_increments
../../gcc/gimple-ssa-strength-reduction.c:2638
0xff1e02 analyze_candidates_and_replace
../../gcc/gimple-ssa-strength-reduction.c:3594
0xff1e02 execute
../../gcc/gimple-ssa-strength-reduction.c:3681
This is in GCC 5.4.0 on Linux x86_64 (SuSE 11).
Removing the line:
i = j + 1; // <- comment out this line and it does not crash
[which leaves the code functionally equivalent] removes the crash. Dropping
down to -O2 or turning on -fno-strict-aliasing also removes the crash.
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 --- Comment #8 from David Malcolm --- Author: dmalcolm Date: Fri Jul 7 18:49:09 2017 New Revision: 250058 URL: https://gcc.gnu.org/viewcvs?rev=250058&root=gcc&view=rev Log: libcpp: preserve ranges within macro expansions (PR c++/79300) gcc/testsuite/ChangeLog: PR c++/79300 * g++.dg/diagnostic/pr79300.C: New test case. libcpp/ChangeLog: PR c++/79300 * line-map.c (linemap_macro_loc_to_def_point): Preserve range information for macro expansions by delaying resolving ad-hoc locations until within the loop. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr79300.C Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from David Malcolm --- Both issues should now be fixed on trunk.
[Bug c++/81349] Classes with deleted constructor templates incorrectly labeled as non-aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81349
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
The suggested code contains several typos, here a corrected version:
#include
struct S {
template
S(T) = delete;
};
int main() {
static_assert(std::is_aggregate_v);
}
[Bug target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81348 --- Comment #5 from Michael Meissner --- Author: meissner Date: Fri Jul 7 20:47:15 2017 New Revision: 250060 URL: https://gcc.gnu.org/viewcvs?rev=250060&root=gcc&view=rev Log: [gcc] 2017-07-07 Michael Meissner Backport from mainline PR target/81348 * config/rs6000/rs6000.md (HI sign_extend splitter): Use the correct operand in doing the split. [gcc/testsuite] 2017-07-07 Michael Meissner Backport from mainline 2017-07-07 Michael Meissner PR target/81348 * gcc.target/powerpc/pr81348.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr81348.c - copied unchanged from r250054, trunk/gcc/testsuite/gcc.target/powerpc/pr81348.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #5 from Yuri Gribov --- (In reply to Michael Thayer from comment #3) > Seems my mistake. I think the ASAN library was still getting loaded > dynamically. Now I have the following problem, which I think means that > code (constructors?) getting called before ASAN is initialised is getting > hold of memory map areas which ASAN is hard-coded to use. So probably no > static ASAN for me. Michael, to work on this we'd need a complete repro. Or if you are no longer interested in this, please close as CANTREPRO or something like this.
[Bug c++/81355] New: SegFault when using attribute target dispatch with empty parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81355
Bug ID: 81355
Summary: SegFault when using attribute target dispatch with
empty parameter
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: erich.keane at intel dot com
Target Milestone: ---
This very simple repro causes a segfault:
__attribute__((target("default")))
int foo() {return 99;}
__attribute__((target("sse4.2","")))
int foo() {return 1;}
int main() {
return foo();
}
As you can see, this does dispatch, and should otherwise be valid. However,
the blank string causes a segfault: https://godbolt.org/g/dmuCaZ
Additionally of interest, ONLY the 1st parameter to target participates in
dispatch.
[Bug target/81356] New: __builtin_strcpy is not good for copying an empty string on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356
Bug ID: 81356
Summary: __builtin_strcpy is not good for copying an empty
string on aarch64
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
Take:
void f(char *a)
{
__builtin_strcpy (a, "");
}
CUT ---
This produces:
f:
adrpx1, .LC0
ldrbw1, [x1, #:lo12:.LC0]
strbw1, [x0]
ret
But why can't it be just:
f:
strbwzr, [x0]
ret
[Bug target/81357] New: Extra mov for zero extend of add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Bug ID: 81357
Summary: Extra mov for zero extend of add
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
Take:
unsigned long long d;
unsigned int test1(unsigned int fParm)
{
d = fParm + 1;
return fParm + 1;
}
--- CUT ---
Currently this produces:
test1:
add w2, w0, 1
adrpx1, d
str x2, [x1, #:lo12:d]
mov x0, x2
ret
But w0 is dead after the add, so why not use w0 instead of x2. This should
allow the removal of the mov at the end of the function.
This looks like it only shows up with function returns.
[Bug other/81287] [8 Regression] bootstrap fails with --enable-languages=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81287 Andrew Pinski changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |RESOLVED Component|bootstrap |other Resolution|--- |FIXED Target Milestone|--- |8.0 Summary|bootstrap fails with|[8 Regression] bootstrap |--enable-languages=all |fails with ||--enable-languages=all --- Comment #1 from Andrew Pinski --- Fixed by r249962 .
[Bug middle-end/55546] Static functions that are fully inlined can end up in the object file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55546 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- This was fixed in r198821. Could someone close?
