[Bug target/81357] New: Extra mov for zero extend of add

[pinskia at gcc dot gnu.org]

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 target/81356] New: __builtin_strcpy is not good for copying an empty string on aarch64

[pinskia at gcc dot gnu.org]

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 c++/81355] New: SegFault when using attribute target dispatch with empty parameter

[erich.keane at intel dot com]

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 sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

[tetra2005 at gmail dot com]

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 target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[meissner at gcc dot gnu.org]

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=gcc=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 c++/81349] Classes with deleted constructor templates incorrectly labeled as non-aggregates

[daniel.kruegler at googlemail dot com]

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 c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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=gcc=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++/81354] New: Segmentation fault in SSA Strength Reduction using -O3

[jgrossma at qti dot qualcomm.com]

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 target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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 target/81348] PowerPC64: Code built with -mcpu=power9 hits SEGV in RTL split2

[meissner at gcc dot gnu.org]

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=gcc=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/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL

[vries at gcc dot gnu.org]

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 sanitizer/78028] ASAN doesn't find memory leak

[barto at cambridgesemantics dot com]

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/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70119

Wilco  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/70119] AArch64 should take advantage of implicit truncation of variable shift amount without defining SHIFT_COUNT_TRUNCATED

[wilco at gcc dot gnu.org]

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/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL

[vries at gcc dot gnu.org]

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 fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350

Jeff Hammond  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

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 libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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 libstdc++/81353] New: Please provide a libstdc++ version macro

[coypu at sdf dot org]

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 regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

[ro at gcc dot gnu.org]

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 middle-end/70801] IRA caller-saves does not support rematerialization

[wilco at gcc dot gnu.org]

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 fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jakub at gcc dot gnu.org]

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 fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jakub at gcc dot gnu.org]

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/81344] Can't disable -ffpe-trap (or not documented)

[dominiq at lps dot ens.fr]

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

[jakub at gcc dot gnu.org]

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 rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[krebbel at gcc dot gnu.org]

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=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 target/81352] New: [nvptx] trap placement for non-returning function call in vector-single mode

[vries at gcc dot gnu.org]

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 sanitizer/78028] ASAN doesn't find memory leak

[tetra2005 at gmail dot com]

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 sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.

[ramana at gcc dot gnu.org]

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/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.

[m.ostapenko at samsung dot com]

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 tree-optimization/81346] Missed constant propagation into comparison

[jakub at gcc dot gnu.org]

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/61995] gcc 4.9.1 fails to compile with error in libsanitizer

[tetra2005 at gmail dot com]

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 sanitizer/60892] GCC (libsanitizer) fails to build with Linux 2.6.21 headers.

[tetra2005 at gmail dot com]

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 lto/81351] [8 regression] Many LTO testcases FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.

[tetra2005 at gmail dot com]

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 sanitizer/63245] renderMemorySnippet shouldn't show more bytes than the underlying type

[tetra2005 at gmail dot com]

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 fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[dominiq at lps dot ens.fr]

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/61693] [asan] is not intercepting aligned_alloc

[tetra2005 at gmail dot com]

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 sanitizer/78654] ubsan can lead to excessive stack usage

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654

--- Comment #5 from Jakub Jelinek  ---
Not intentional, but unavoidable I think.

[Bug lto/81351] [8 regression] Many LTO testcases FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

[tetra2005 at gmail dot com]

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 sanitizer/58841] std::bad_alloc not thrown with -fsanitize=address

[redi at gcc dot gnu.org]

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 lto/81351] New: [8 regression] Many LTO testcases FAIL

[ro at gcc dot gnu.org]

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 

[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Given that nonnull attribute is ignored on purpose, perhaps this should be
closed (as wontfix)?

[Bug sanitizer/55316] gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error "Unsupported arch"

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55316

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
Can this be closed as not-a-bug?

[Bug sanitizer/58841] std::bad_alloc not thrown with -fsanitize=address

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #1 from Yuri Gribov  ---
Upstream dup: https://github.com/google/sanitizers/issues/295 . I suggest to
close this bug and track it upstream instead.