[Bug c++/90587] New: asan: stack-use-after-scope with -O3 and -Wall

[dcb314 at hotmail dot com]

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

Bug ID: 90587
   Summary: asan: stack-use-after-scope with -O3 and -Wall
   Product: gcc
   Version: 9.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 46399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46399&action=edit
C++ source code

The attached C++ code does this:

==7322==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffebf37620 at pc 0x0390b2ba bp 0x7fffebf373e0 sp 0x7fffebf373d8

when compiled like this:

$ /home/dcb/gcc/results.271500.asan/bin/gcc -O3 -Wall -std=c++11 bug522.cc

The bug seems to start sometime between revision 271200 and 271500.
I will post reduced C++ code when I get it.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Thomas Koenig from comment #21)
> OK, if the callee is a C function... what is its declaration
> on the Fortran side?  Is there any interface, bind(c) or otherwise?
> 
> I suppose there must be something, otherwise nf_put_vara_double would
> have a trailing underscore.
> 
> On the caller side, I see that an array is passed, but the fsym
> has rank=0.  I think this would be flagged otherwise.

So ncfortran.h contains:
#define nf_put_vara_double  nf_put_vara_double_

And Fortran interface is defined in netcdf/include/netcdf.inc:

  integer nf_put_vara_double
! (integer ncid,
!  integer varid,
!  integer start(1),
!  integer count(1),
!  doubleprecision dvals(1))
  externalnf_put_vara_double

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
One another note is that the problematic code lives in src/netcdf/* and the
same code contain:
benchspec/CPU/521.wrf_r/src/netcdf/
and
benchspec/CPU/628.pop2_s/src/netcdf/

So that would explain also the segfault of the wrf benchmark.

[Bug target/90588] New: [AArch64] SVE2 flag patch omits aarch64-protos.h

[p...@gcc-bugzilla.mail.kapsi.fi]

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

Bug ID: 90588
   Summary: [AArch64] SVE2 flag patch omits aarch64-protos.h
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

AArch64 SVE2 flag patch (commit 33af5a3270d6c9abaf5c05040a89e41130cbd5ca) does
not update `gcc/config/aarch64/aarch64-protos.h' (still uses unsigned long, not
uint64_t), leading to compile errors.  Maybe these changes are already done,
but weren't included in the commit by a mistake?

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
(In reply to Thomas Koenig from comment #22)
> I've been trying out some things, and I cannot construct a failing
> test case.
> 
> A sane way to build such an interface would be
> 
>  cat tst.f90
> module x
>   use, intrinsic :: iso_c_binding, only : c_double
>   implicit none
>   interface
>  subroutine foo(a) bind(c)
>import
>real(kind=c_double) :: a(*)
>  end subroutine foo
>   end interface
>   private
>   public :: bar
> 
> contains
>   subroutine bar(a)
> real(kind=c_double), dimension(:) :: a
> a = 42._c_double
> call foo(a)
>   end subroutine bar
> end module x
> 
> program main
>   use, intrinsic :: iso_c_binding, only : c_double
>   use x
>   implicit none
>   real(kind=c_double), dimension(1) :: a
>   call bar(a)
> end program main
> $ cat foo.c
> #include 
> 
> void foo (double *a)
> {
>   printf("%f\n", *a);
> }
> $ gfortran -flto -O tst.f90 foo.c
> $ ./a.out
> 42.00
> 
> This works as expected.
> 
> What I do not understand is (comment #17)
> 
> (gdb) p debug(fsym)
> || symbol: '_formal_107'  
>   type spec : (REAL 8)
>   attributes: (VARIABLE  DIMENSION DUMMY)
>   Array spec:(0 [0])
> 
> 
> This means that the dummy parameter has rank zero. How, then,
> is it possible to pass a rank-1 argument to it?
> 
> (gdb) p debug(expr)
> nf90_put_var_1d_eightbytereal:values(FULL) (REAL 8)
> 
> (gdb) p *expr->ref
> $8 = {
>   type = REF_ARRAY, 
>   u = {
> ar = {
>   type = AR_FULL, 
>   dimen = 1, 
>   codimen = 0, 
> 
> Something very fishy going on here.
> 
> Please look up the Fortran interface to the C function that is called,
> nc_put_vara_double.
> 
> Also, please break on gfc_conv_procedure_call for the call
> in question and do
> 
> $ call debug(sym)
> $ p args
> $ call debug(args->expr)
> $ p args->next
> $ call debug(args->next->expr)

(gdb) call debug(sym)
|| symbol: 'nf_put_vara_double' 
  type spec : (INTEGER 4)
  attributes: (PROCEDURE EXTERNAL-PROC IMPLICIT-SAVE EXTERNAL FUNCTION)
  result: nf_put_vara_double
  Formal arglist: _formal_103 _formal_104 _formal_105 _formal_106 _formal_107
(gdb) p args
$4 = (gfc_actual_arglist *) 0x2a766f0
(gdb) call debug(args->expr)
nf90_put_var_1d_eightbytereal:ncid (INTEGER 4)
(gdb) p args->next
$5 = (gfc_actual_arglist *) 0x2a72150
(gdb) call debug(args->next->expr)
nf90_put_var_1d_eightbytereal:varid (INTEGER 4)
(gdb) call debug(args->next->next->expr)
nf90_put_var_1d_eightbytereal:localstart(FULL) (INTEGER 4)
(gdb) call debug(args->next->next->next->expr)
nf90_put_var_1d_eightbytereal:localcount(FULL) (INTEGER 4)
(gdb) call debug(args->next->next->next->next->expr)
nf90_put_var_1d_eightbytereal:values(FULL) (REAL 8)

> 
> ... and so on, until args->...->next becomes a null pointer.
> 
> I am starting do suspect that this is, in fact, another piece of SPEC
> bugware where they made some sort of broken interface between C
> and Fortran, which is exposed by my patch.

That's likely :) Hope my remove gdb session helped.

> 
> Hmpf...

[Bug sanitizer/90570] [9/10 Regression] AddressSanitizer: stack-use-after-scope

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01559.html

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-23
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please test it with:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01559.html
?

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-23
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can confirm it. I'll reduce it down..

[Bug c++/90415] [10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0, 9.1.1
   Keywords||rejects-valid
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 CC|jason at redhat dot com|jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|std::is_copy_constructible< |[10 Regression]
   |std::tuple> is|std::is_copy_constructible<
   |incomplete  |std::tuple> is
   ||incomplete
  Known to fail||10.0

--- Comment #4 from Jonathan Wakely  ---
Thanks for the bisection.

Changing component to c++ for now, although it's possible a fix is needed in
the library.

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Jonathan Wakely  ---
GDB is a separate project with its own bugzilla, see
https://sourceware.org/bugzilla

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The glibc change was https://sourceware.org/bugzilla/show_bug.cgi?id=21120 and
is present from version 2.26

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Jonathan Wakely from comment #1)
> GDB is a separate project with its own bugzilla, see
> https://sourceware.org/bugzilla

Thanks. 
I am not quite sure whether this is a bug of gdb or gcc. 
I am wondering that the problem is caused by wrong code generated by gcc.

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Here is the reduced C++ code:

typedef unsigned a;
typedef char b;
typedef struct {
  a *c;
} d;
int e(d *f) {
  if (f)
return *f->c;
}
a g(d *f) { return e(f); }
typedef struct {
  b channel;
} h;
b *j(d *f, int channel, b *dest) {
  int k = 80, i;
  for (i = 0; i < 4; ++i, k = 1)
if (channel & k)
  dest[i] = g(f);
  return dest;
}
void l(int, b *dest, b *m) {
  int i;
  for (i = 0; i < 4; ++i)
dest[i] = m[i];
}
b n(d *f) {
  for (;;) {
h *o;
b *dest;
b p[4];
if (j(f, o->channel, p))
  l(o->channel, dest, p);
  }
}

[Bug libgomp/90585] libgomp hsa plugin ftbfs in the x32 multilib variant

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 46400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46400&action=edit
gcc10-pr90585.patch

Untested fix.  Note, the rest of libgomp uses PRIu64 only conditionally on
HAVE_INTTYPES_H, so this patch does that too, but as it is in many spots, using
a typedef.

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

[tschwinge at gcc dot gnu.org]

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

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu May 23 08:22:56 2019
New Revision: 271540

URL: https://gcc.gnu.org/viewcvs?rev=271540&root=gcc&view=rev
Log:
[PR90510] Adjust 'brig.dg/test/gimple/packed.hsail'

... for r271463 "Fix PR90510, VEC_PERM -> BIT_INSERT folding".

gcc/testsuite/
PR middle-end/90510
* brig.dg/test/gimple/packed.hsail: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/brig.dg/test/gimple/packed.hsail

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|MOVED   |INVALID

--- Comment #3 from Jonathan Wakely  ---
Putting "[gdb]" in the bug summary suggests you're trying to report a GDB bug,
which doesn't belong here.

You're trying to put a breakpoint on a line with no code, which won't work. Try
breaking on line 12.

[Bug sanitizer/90589] New: In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

Bug ID: 90589
   Summary: In Fedora 30 ps hangs using address sanitizer
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mccannd at uk dot ibm.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I'm using Fedora 30 in a docker container running on a Ubuntu 16.04 or 18.04
host. The following command hangs:
LD_PRELOAD=/lib64/libasan.so.5.0.0 ps

The same commands works using Fedora 29.

If I take off the LD_PRELOAD, then the command completes successfully.

An strace always shows it in the following:
futex(0x7f19408a0be8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 2, NULL,
FUTEX_BITSET_MATCH_ANY

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
So the problem can be reproduced when only factor.cc is compiled with -flto
-Os.
Problematic comparison is:


 for (pivot = temp.pivots.next; pivot != &temp.pivots;
  pivot = pivot->next)
 {
eliminatePivot(pivot->idx, pivot->pos, eps );
 }
  }

I reduced that to problematic call to:
#0  aliasing_component_refs_p (ref1=0x773cd480, ref1_alias_set=15,
base1_alias_set=6, offset1=..., max_size1=..., ref2=0x77441030,
ref2_alias_set=15, base2_alias_set=13, offset2=..., max_size2=...,
ref2_is_decl=false)

true is returned for:

(gdb) p print_generic_expr (stderr, ref1, 0)
this_16(D)->temp.pivots.next$8 = void
(gdb) p print_generic_expr (stderr, ref2, 0)
_1090->next$9 = void

(gdb) p debug_tree(ref1)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type
0x7758e888 fields  context 
pointer_to_this >
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 15 structural-equality
pointer_to_this  reference_to_this
>

arg:0 

arg:0 

arg:0 

arg:0 
visited var 
def_stmt GIMPLE_NOP
version:16
ptr-info 0x776c0eb8>
arg:1 > arg:1

factor.cc:1369:23 start: factor.cc:1369:23 finish:
factor.cc:1369:23>
arg:1 
nonlocal BLK clufactor.h:75:15 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset 
bit-offset  context
 chain >
factor.cc:1369:28 start: factor.cc:1369:28 finish: factor.cc:1369:28>
arg:1 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality reference_to_this >
unsigned nonlocal DI clufactor.h:53:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset  bit-offset  context 
chain 
unsigned nonlocal DI clufactor.h:54:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
factor.cc:1369:35 start: factor.cc:1369:35 finish: factor.cc:1369:35>

(gdb) p debug_tree(ref2)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type
0x7758e888 fields  context 
pointer_to_this >
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 15 structural-equality
pointer_to_this  reference_to_this
>

arg:0 

arg:0 
visited
def_stmt _1090 = _1088->prev;
version:1090
ptr-info 0x775e6228>
arg:1 >
arg:1 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality reference_to_this >
unsigned nonlocal DI clufactor.h:53:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
unsigned nonlocal DI clufactor.h:54:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
factor.cc:1079:7 start: factor.cc:1079:7 finish: factor.cc:1079:7>

(gdb) p offset1
$12 = {
  > = {
coeffs = {3392}
  }, }
(gdb) p offset2
$13 = {
  > = {
coeffs = {0}
  }, }

(gdb) p max_size1
$14 = {
  > = {
coeffs = {64}
  }, }
(gdb) p max_size2
$15 = {
  > = {
coeffs = {64}
  }, }

I hope it will be enough information.
Honza?

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to David Binderman from comment #2)
> Here is the reduced C++ code:
> 
> typedef unsigned a;
> typedef char b;
> typedef struct {
>   a *c;
> } d;
> int e(d *f) {
>   if (f)
> return *f->c;
> }
> a g(d *f) { return e(f); }
> typedef struct {
>   b channel;
> } h;
> b *j(d *f, int channel, b *dest) {
>   int k = 80, i;
>   for (i = 0; i < 4; ++i, k = 1)
> if (channel & k)
>   dest[i] = g(f);
>   return dest;
> }
> void l(int, b *dest, b *m) {
>   int i;
>   for (i = 0; i < 4; ++i)
> dest[i] = m[i];
> }
> b n(d *f) {
>   for (;;) {
> h *o;
> b *dest;
> b p[4];
> if (j(f, o->channel, p))
>   l(o->channel, dest, p);
>   }
> }

There's missing main function that will call the reduced test-case.

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 Blocks||86656

--- Comment #4 from Martin Liška  ---
> 
> There's missing main function that will call the reduced test-case.

Ah, sorry, compiler should be executed. Let me take a look then..


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] Issues found with -fsanitize=address

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce on openSUSE Tumbleweed:

marxin@marxinbox:/tmp> LD_PRELOAD=/usr/lib64/libasan.so.5.0.0 ps
  PID TTY  TIME CMD
20622 pts/17   00:00:00 bash
26138 pts/17   00:00:00 ps
marxin@marxinbox:/tmp> LD_PRELOAD=/usr/lib64/libasan.so.4.0.0 ps
  PID TTY  TIME CMD
20622 pts/17   00:00:00 bash
26903 pts/17   00:00:00 ps

Do you have the 'ps' instrumented with ASAN?

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #2 from mccannd at uk dot ibm.com ---
No, I've just installed the procps and libasan packages within my Fedora 30
container.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Do you have the same problem not in a container?
How useful is to use the LD_PRELOAD for the ps?

[Bug libstdc++/90590] New: enumeration value not handled in switch warning for std::ios_base::seek_dir

[alan at birtles dot org.uk]

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

Bug ID: 90590
   Summary: enumeration value not handled in switch warning for
std::ios_base::seek_dir
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alan at birtles dot org.uk
  Target Milestone: ---

GCC (and clang bug 67996) raises a warning when declaring a switch statement
which uses std::ios_base::seek_dir.

The following:

#include 

int main()
{
std::ios_base::seekdir dir = std::ios_base::end;
switch ( dir )
{
case std::ios_base::end:
case std::ios_base::beg:
case std::ios_base::cur:
break;
}
}

produces:
test.cpp: In function 'int main()':
test.cpp:6:12: warning: enumeration value '_S_ios_seekdir_end' not handled in
switch [-Wswitch]

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||vlad at ispras dot ru
  Known to work||9.1.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
Summary|asan: stack-use-after-scope |[10 Regression] asan:
   |with -O3 and -Wall  |stack-use-after-scope with
   ||-O3 and -Wall
  Known to fail||10.0

--- Comment #5 from Martin Liška  ---
Started with r271460.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #4 from mccannd at uk dot ibm.com ---
I've not yet tried outside of a container.

I have a script that sets LD_PRELOAD so that I can detect problems in code I do
care about. It just so happens that this code calls ps, which then hung. I'm
concerned that it indicates a problem that will affect more than ps.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is not a libstdc++ bug, we're allowed to define whatever enumerators we
want as long as they use reserved names.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a libstdc++ bug, we're allowed to define whatever enumerators we
> want as long as they use reserved names.

Which is almost exactly what I said in the Clang bug you linked to. Nice to
know I'm consistent.

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
In theory we could do this to avoid the warning:

--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -189,13 +189,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   operator^=(_Ios_Iostate& __a, _Ios_Iostate __b)
   { return __a = __a ^ __b; }

+  enum _Ios_Seekdir_range
+{
+  _S_ios_seekdir_beg_ = 0,
+  _S_ios_seekdir_end = 1L << 16
+};

-  enum _Ios_Seekdir 
+  enum _Ios_Seekdir : __underlying_type(_Ios_Seekdir_range)
 { 
   _S_beg = 0,
   _S_cur = _GLIBCXX_STDIO_SEEK_CUR,
-  _S_end = _GLIBCXX_STDIO_SEEK_END,
-  _S_ios_seekdir_end = 1L << 16 
+  _S_end = _GLIBCXX_STDIO_SEEK_END
 };


But giving the enum a fixed underlying type changes its semantics, as now any
value of the underlying type is a valid value of the enumeration type.

As I said in the Clang bug, I think a better approach would be to suppress the
warning for enumerators that are defined in system headers and that use
reserved names.

So I'm changing this to a compiler enhancement request, to suppress this
warning for cases like this.

[Bug middle-end/88784] Middle end is missing some optimizations about unsigned

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Qi Feng from comment #9)
> And there's another problem. Take `x >  y  &&  x != 0   -->   x > y' for
> example, I would also like to do
> 
>x <  y  &&  y != 0  -->  x < y
>x != 0  &&  x >  y  -->  x > y
>y != 0  &&  x <  y  -->  x < y
> 
> If the constant always comes in as the second operand is incorrect, these
> would have to be doubled.
> 
> I tried to add :c to truth_andif, but got the `operation is not commutative'
> error.  I also tried to make truth_andif commutative by modifying
> genmatch.c, but again, I don't know it well, afraid that I would break
> something.
> 
> The patterns I wrote looks like:
> 
> /* x >  y  &&  x != 0 --> x > y
>Only for unsigned x and y.  */
> (simplify
>  (truth_andif:c (gt@2 @0 @1) (ne @0 integer_zerop))
>  (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@0))
>   && INTEGRAL_TYPE_P (TREE_TYPE(@1)) && TYPE_UNSIGNED
> (TREE_TYPE(@1)))
>@2))
> 
> I have to wrote 4 of this with minor modification for a single
> transformation. If there's better way to do it, please do leave a comment.

I think first of all you do _not_ want to use truth_andif since that
will only prevail iff x or y have side-effects.  To match on GIMPLE
you want bit_and instead/as well since all truth_ stuff doesn't prevail there.

And obviously truth_andif is _not_ commutative.  You can use :C if you
want to force it though.  Both truth_and and bit_and are commutative.
So sth like

(for and (truth_and bit_and)
 (for ltgtop (lt le)
  (simplify
   (and:c (ltgtop:c@2 @0 @1) (ne @0 integer_zerop))
   (if (...)
@2)))

should cover all of

   x <  y  &&  y != 0  -->  x < y
   x != 0  &&  x >  y  -->  x > y
   y != 0  &&  x <  y  -->  x < y
   x <  y  &&  y != 0  -->  x < y

note that from

(and (lt:c@2 @0 @1) (ne @0 integer_zerop))

we generate

(and (lt@2 @0 @1) (ne @0 integer_zerop))
(and (gt@2 @1 @0) (ne @0 integer_zerop))

so :c will ensure the semantically same operation will be present with
swapped operands.  As opposed to :C which would do lt@2 @1 @0.

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe  ---
Author: iains
Date: Thu May 23 09:23:47 2019
New Revision: 271544

URL: https://gcc.gnu.org/viewcvs?rev=271544&root=gcc&view=rev
Log:
x86, testsuite - update fuse-caller-save tests.

These tests had started to XPASS on pic targets where
the codegen is now as expected.

gcc/testsuite/

2019-05-23  Iain Sandoe  

PR rtl-optimisation/64895
* gcc.target/i386/fuse-caller-save-rec.c: Remove XFAILs.
* gcc.target/i386/fuse-caller-save.c: Likewise.
* gcc.target/i386/fuse-caller-save-xmm.c: Adjust tests for
PIC cases, remove XFAILs.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c

[Bug target/85539] x86_64: loads are not always narrowed

[navyadeepika.garakapati at gmail dot com]

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

Navya  changed:

   What|Removed |Added

 CC||navyadeepika.garakapati@gma
   ||il.com

--- Comment #2 from Navya  ---
Testcase:
$cat test.c
int foo(long *p)
{
return *p;
}

$cat test.s
foo:
movq(%rdi), %rax
retq

While analysing it found that, in gcc trunck with -O0 optimization,

In ira pass, there is a conversion information from 64bit to 32bit 
subreg:SI (reg:DI 82 [ _1 ]) 0)): 

ira pass:

(insn 8 7 11 2 (set (reg:SI 83 [ _4 ])
(subreg:SI (reg:DI 82 [ _1 ]) 0)) "t.c":3:8 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg:DI 82 [ _1 ])
(nil)))

while reload pass is deleting this information and assigning 32bit to 32bit
i.e; SI to SI which results this as a dead code for the next pass and as a
result this insn 8 is getting deleted in next pass which is split2 pass.

reload pass:

(insn 8 7 15 2 (set (reg:SI 0 ax [orig:83 _4 ] [83])
(reg:SI 0 ax [orig:82 _1 ] [82])) "t.c":3:8 67 {*movsi_internal}
 (nil))

please let us know if there is any target hook being used, because of which the
conversion information from DI to SI is converted to SI to SI in reload pass.

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn]

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

--- Comment #4 from Yibiao Yang  ---
(In reply to Jonathan Wakely from comment #3)
> Putting "[gdb]" in the bug summary suggests you're trying to report a GDB
> bug, which doesn't belong here.
> 
> You're trying to put a breakpoint on a line with no code, which won't work.
> Try breaking on line 12.

Thanks. 
Indeed, as you said, I would probably agree that this is a bug in gdb. In fact,
we can set breakpoint at the label statement (Line 13) as follows. The behavior
of gdb is correct in this case. Thus, this problem should not be caused by "a
line with no code".

$ cat small.c
#include 
int main()
{
  int i = 0;
  int j = 0;
  for (; i<=1; i++) {
for (; j<=1; j++) {
  goto lbl;
}
  }

  printf("hello\n");
lbl:  // line 13
  return 0;
}

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||9.1.0

--- Comment #22 from Richard Biener  ---
So this was fixed for GCC 9.  Both the GCC 8 and GCC 7 branches are still open
for wrong-code fixes, I'd appreciate at least providing "official" backports of
the fix even if we end up not committing them because for the fear of breakage.
You probably know best - was there any fallout of the two revs committed here
that needed to be fixed?

Thanks.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #40 from Jakub Jelinek  ---
I must say I don't like -fbroken-callers option name too much, can we use
instead something like -ftail-call-workaround={0,1,2} /
-f{,no-}tail-call-workaround
where -ftail-call-workaround == -ftail-call-workaround=1 would be the default
(for now) and enabled only if resolve_symbol finds FL_PROCEDURE if_source ==
IFSRC_UNKNOWN symbols (remembered in some gfc_ns member and set on containing
procedure, not say containing BLOCK), -fno-tail-call-workaround ==
-ftail-call-workaround=0 would disable this and -ftail-call-workaround=2 would
be enabled no matter whether there are any FL_PROCEDURE IFSRC_UNKNOWN symbols
or not?

[Bug tree-optimization/90591] New: Avoid unnecessary data transfer out of OMP construct

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90591
   Summary: Avoid unnecessary data transfer out of OMP construct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The reverse side of PR90573.  For (all too common!) code like:

int i;
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = 0; i < N; ++i)
  [...]
  }
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = N - 1; i >= 0; --i)
  [...]
  }
['i' never read here]

In addition that we can avoid unnecessary data transfer into each OMP construct
(PR90573), we also don't need to copy 'i' out in such scenarios, so can
optimize 'copy' to 'copyin', or 'copyout' to 'create'.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu.org]

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

--- Comment #40 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #39)
> (In reply to Richard Biener from comment #36)
> > Created attachment 46396 [details]
> > poor mans solution^Whack



> How does this work if op is a SSA_NAME?

it doens't, the patch has to be fixed to create a new def and adjust
all uses which isn't possible here (no immediate uses).

It's a proof-of-concept hack - the SSA name issue means we have to
find a better place for such hack.  Note I don't think we should
go with this kind of hack, iff, then we should at least not use
an ASM but some special __IFN and a more appropriate construct on
the RTL side (not sure what that would be).

[Bug c++/90592] New: Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90592
   Summary: Documentation: Missing word (or wrong
parenthesization) in "Function Names as Strings"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

In "Function Names as Strings" (par. 6.50 in
) there's the following
text:

  As an extension, at file (or, in C++, namespace scope), __func__
  evaluates to the empty string.

Here, "at file" should be followed by the word "scope", so I suggest changing
the text to either

  - As an extension, at file (or, in C++, namespace) scope, __func__
evaluates to the empty string.

or

  - As an extension, at file scope (or, in C++, namespace scope), __func__
evaluates to the empty string.

[Bug target/90552] attribute((optimize(3))) not overriding -Os

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #3 from Uroš Bizjak  ---
This happens due to the following TODO from i386-options.c:

  /* TODO: ix86_cost should be chosen at instruction or function granuality
 so for cold code we use size_cost even in !optimize_size compilation.  */
  if (opts->x_optimize_size)
ix86_cost = &ix86_size_cost;
  else
ix86_cost = ix86_tune_cost;

ix86_rtx_costs in i386.c is correctly called with speed=1, even when -Os is
used. However, -Os switches ix86_cost to ix86_size_cost so the following line
still returns ix86_size_cost:

  const struct processor_costs *cost = speed ? ix86_cost : &ix86_size_cost;

So, someone should comb through i386*.c files and fix up ix86_cost usage to
finally implement switching at insn/function "granuality" [sic]. Luckily, there
are not that many instances in the code.

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[gennaro.prota+gccbugzilla at gmail dot com]

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

--- Comment #1 from Gennaro Prota  
---
In "Function Names as Strings" (par. 6.50 in
) there's the following
text:

  As an extension, at file (or, in C++, namespace scope), __func__
  evaluates to the empty string.

Here, "at file" should be followed by the word "scope", so I suggest changing
the text to either

  - As an extension, at file (or, in C++, namespace) scope, __func__
evaluates to the empty string.

or

  - As an extension, at file scope (or, in C++, namespace scope), __func__
evaluates to the empty string.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to mccannd from comment #4)
> I've not yet tried outside of a container.
> 
> I have a script that sets LD_PRELOAD so that I can detect problems in code I
> do care about. It just so happens that this code calls ps, which then hung.
> I'm concerned that it indicates a problem that will affect more than ps.

I see. Would be probably interesting to attach gdb to the process and print
back-trace.

[Bug target/90552] attribute((optimize(3))) not overriding -Os

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Patch to fix this particular PR:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 463e78112f0..79fcb5c4e57 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -19124,7 +19124,8 @@ ix86_rtx_costs (rtx x, machine_mode mode, int
outer_code_i, int opno,
   rtx mask;
   enum rtx_code code = GET_CODE (x);
   enum rtx_code outer_code = (enum rtx_code) outer_code_i;
-  const struct processor_costs *cost = speed ? ix86_cost : &ix86_size_cost;
+  const struct processor_costs *cost
+= speed ? ix86_tune_cost : &ix86_size_cost;
   int src_cost;

   switch (code)
--cut here--

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[umesh.kalappa0 at gmail dot com]

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

--- Comment #13 from Umesh Kalappa  ---
>>There is no point in emitting an asm thunk if you use a long call though.
thunk required to adjust the this pointer (in c++ cases)

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
I've got a patch for it.

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Full report:

==26783==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fff19d9ac10 at pc 0x02d5bd6e bp 0x7fff19d9a9f0 sp 0x7fff19d9a9e8
READ of size 8 at 0x7fff19d9ac10 thread T0
#0 0x2d5bd6d in bool wi::eq_p >, generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/marxin/Programming/gcc/gcc/wide-int.h:1856
#1 0x2d5ac1e in
wi::binary_traits >,
generic_wide_int >,
wi::int_traits >
>::precision_type, wi::int_traits > >::precision_type>::predicate_result
operator== >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/marxin/Programming/gcc/gcc/wide-int.h:3268
#2 0x2d4bf89 in value_sat_pred_p
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1063
#3 0x2d4e35c in is_pred_expr_subset_of
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1501
#4 0x2d4e7e9 in is_pred_chain_subset_of
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1525
#5 0x2d4ea48 in is_included_in
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1554
#6 0x2d4ec85 in is_superset_of
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1585
#7 0x2d54e75 in is_use_properly_guarded
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:2488
#8 0x2d55215 in find_uninit_use
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:2532
#9 0x2d5586f in warn_uninitialized_phi
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:2601
#10 0x2d5643d in execute
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:2710
#11 0x21778df in execute_one_pass(opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2473
#12 0x2178152 in execute_pass_list_1
/home/marxin/Programming/gcc/gcc/passes.c:2559
#13 0x21781cd in execute_pass_list_1
/home/marxin/Programming/gcc/gcc/passes.c:2560
#14 0x2178271 in execute_pass_list(function*, opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2570
#15 0x143943f in cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2194
#16 0x143a429 in expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
#17 0x143c4be in symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2683
#18 0x143cdc3 in symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2861
#19 0x257b442 in compile_file /home/marxin/Programming/gcc/gcc/toplev.c:481
#20 0x2583430 in do_compile /home/marxin/Programming/gcc/gcc/toplev.c:2205
#21 0x2583cb8 in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.c:2340
#22 0x4b87f4a in main /home/marxin/Programming/gcc/gcc/main.c:39
#23 0x7f2456b01b7a in __libc_start_main ../csu/libc-start.c:308
#24 0x8a0799 in _start (/dev/shm/objdir2/gcc/cc1plus+0x8a0799)

Address 0x7fff19d9ac10 is located in stack of thread T0 at offset 224 in frame
#0 0x2d4bc1e in value_sat_pred_p
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:1057

  This frame has 5 object(s):
[32, 64) 'andw'
[96, 128) ''
[160, 192) ''
[224, 256) '' <== Memory access at offset 224 is inside this
variable
[288, 320) ''
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
/home/marxin/Programming/gcc/gcc/wide-int.h:1856 in bool
wi::eq_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
Shadow bytes around the buggy address:
  0x1000633ab530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000633ab540: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f2 f2 f2 f2
  0x1000633ab550: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x1000633ab560: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f2 f2
  0x1000633ab570: f2 f2 f8 f8 f8 f8 f2 f2 f2 f2 f8 f8 f8 f8 f2 f2
=>0x1000633ab580: f2 f2[f8]f8 f8 f8 f2 f2 f2 f2 00 00 00 00 f3 f3
  0x1000633ab590: f3 f3 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
  0x1000633ab5a0: 00 f2 f2 f2 f2 f2 00 00 00 f2 f3 f3 f3 f3 00 00
  0x1000633ab5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000633ab5c0: 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2
  0x1000633ab5d0: f2 f2 f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==26783==ABORTING

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code, wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We somehow build a broken(?) CFG from the start:

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  if (argc == 0)
;;succ:   3

;;   basic block 3, loop depth 0
;;pred:   2
label:
  if (argc == 1)
goto ; [INV]
  else
goto ; [INV]

see how BB2 only has a single outgoing edge.  CFG cleanup fixes this for us.

.gimple has

  [t.c:2:1] {
void label = <<< error >>>;

[t.c:3:6] if (argc == 0) goto ; else goto ;
:
[t.c:4:5] {
  int * ptr;

  [t.c:6:1] label:
}
:
[t.c:10:6] if (argc == 1) goto ; else goto ;

so that looks good, likewise .lower:

  [t.c:3:6] if (argc == 0) goto ; else goto ;
  :
  [t.c:6:1] label:
  :
  [t.c:10:6] if (argc == 1) goto ; else goto ;

iff we'd elide an empty block as having no side-effects we would have
deleted the label.

Thus confirmed as CFG build bug.

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
But that's how -gsplit-dwarf is designed.

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias
   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
  Component|lto |middle-end
   Target Milestone|--- |9.2

[Bug sanitizer/90570] [9/10 Regression] AddressSanitizer: stack-use-after-scope

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Thu May 23 10:12:01 2019
New Revision: 271548

URL: https://gcc.gnu.org/viewcvs?rev=271548&root=gcc&view=rev
Log:
Do not instrument static target_expr for use-after-scope (PR sanitizer/90570).

2019-05-23  Martin Liska  

PR sanitizer/90570
* gimplify.c (gimplify_target_expr): Skip TREE_STATIC target
expression similarly to gimplify_decl_expr.
2019-05-23  Martin Liska  

PR sanitizer/90570
* g++.dg/asan/pr90570.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr90570.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/90570] [9 Regression] AddressSanitizer: stack-use-after-scope

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression]   |[9 Regression]
   |AddressSanitizer:   |AddressSanitizer:
   |stack-use-after-scope   |stack-use-after-scope
  Known to fail|10.0|

--- Comment #8 from Martin Liška  ---
Fixed on trunk so far.

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #1)
> But that's how -gsplit-dwarf is designed.

Shouldn't it then be documented where any .dwo files are stored?  At least in
combination with -o in comment 0, cwd looks like a strange choice.

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
  Known to work||8.3.0
  Known to fail||10.0, 9.1.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r268992.

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> thunk required to adjust the this pointer (in c++ cases)

Yes, but just use a regular thunk.

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||rguenth at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
left-shift by negative value is undefined.  arithmetic left-shift _of_ a
negative value is undefined as well.

I see lshift translates to a logical shift so the 2nd issue is moot.  But we
have in .gimple:

_1 = (unsigned int) D.3899;
_2 = _1 << -30;

note that constant folding treats _1 << -30 as _1 >> 30 but at -O0 we
ask the CPU to perform this shift via

sall%cl, %edx

which simply truncates -30 by & 255.

[Bug libgomp/90593] New: OpenACC 'acc_async_sync' need not imply synchronizing after every intermediate step but rather just once, at the end

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90593
   Summary: OpenACC 'acc_async_sync' need not imply synchronizing
after every intermediate step but rather just once, at
the end
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Before r271128 "OpenACC 'async' re-work", we had the following TODO comment in
'libgomp/plugin/plugin-nvptx.c', 'select_stream_for_async':

/* NOTE: AFAICT there's no particular need for acc_async_sync to map to the
   null stream, and in fact better performance may be obtainable if it
doesn't
   (because the null stream enforces overly-strict synchronisation with
   respect to other streams for legacy reasons, and that's probably not
   needed with OpenACC).  Maybe investigate later.  */
if (async == acc_async_sync)
  stream = ptx_dev->null_stream;

That code and comment is now gone, but the issue not resolved.  Nowadays,
instead of mapping 'acc_async_sync' to the 'NULL' 'aq', 'acc_async_sync' would
get its own, separate 'aq', and, as far as possible/feasible, we'd use that one
to launch all intermediate steps, and then synchronize just once, at the end.

Basically, that means to turn:

#pragma acc parallel [data clauses] // default 'async(acc_async_sync)'
{ [...] }

... into something like:

#pragma acc parallel [data clauses] async([internal])
{ [...] }
#pragma acc wait([internal])

..., so inside 'GOACC_parallel_*', asynchronously launch (on one specific 'aq')
all the data transfers needed per the data clauses, and then the GPU kernel
launch itself, and only then synchronize.

This should allow for hiding latencies that occur when initiating multiple GPU
memory transfers.

[Bug libgomp/90593] OpenACC 'acc_async_sync' need not imply synchronizing after every intermediate step but rather just once, at the end

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
I wonder how this would relate to r237070 "[OpenACC] Make reduction arguments
addressable", where we currently in the front ends explicitly look for 'async'
clauses being present.

[Bug tree-optimization/90591] Avoid unnecessary data transfer out of OMP construct

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
We want to add some attribute(s) on the structure types used to pass
information in and out (or in the fields), and have some specialized IPA
optimization that tries to optimize such cases.

[Bug tree-optimization/90579] Huge store forward stall due to vectorizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
.cfi_startproc
movslq  %edi, %rax
addl$4, %edi
vbroadcastsd%xmm0, %ymm1
movslq  %edi, %rdi
vmovddup%xmm0, %xmm0
vmulpd  a(,%rax,8), %ymm1, %ymm1
vmulpd  a(,%rdi,8), %xmm0, %xmm0
vmovupd %ymm1, r(%rip)
vmovups %xmm0, r+32(%rip)
vmovupd r+16(%rip), %ymm1
^^^ this one

vextractf128$0x1, %ymm1, %xmm2
vunpckhpd   %xmm2, %xmm2, %xmm0
vaddsd  .LC0(%rip), %xmm0, %xmm0
vaddsd  %xmm2, %xmm0, %xmm0
vunpckhpd   %xmm1, %xmm1, %xmm2
vaddsd  %xmm2, %xmm0, %xmm0
vaddsd  %xmm1, %xmm0, %xmm0
vaddsd  r+8(%rip), %xmm0, %xmm0
vaddsd  r(%rip), %xmm0, %xmm0
vzeroupper
ret

unaligned accesses are prone to STLF issues but there's no easy
way out here, at least I don't see a good way of say, restricting
the 2nd loop vectorization to SSE.

Note when misaligning by a single element we'd have to disable
vectorization completely.

In some way this is a target issue since it allows unaligned
loads.  If it would split them (we have a tunable for this)
we'd be fine here (by luck, until misalinging not by SSE vector size).

Similar cases can be made with placing unvectorized by element initializations
before a vectorized loop (possibly in another function).

Those STLF issues are just a bad "feature" of modern CPUs and the fix
is ultimatively in them...

[Bug c/90580] error: ‘offsetof’ undeclared when it is declared, but used with the wrong number of arguments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #6 from mccannd at uk dot ibm.com ---
Yes, I've got it failing in a Fedora 30 virtual image outside of any container.

root@localhost ~]# LD_PRELOAD=/lib64/libasan.so.5.0.0
ASAN_OPTIONS=alloc_dealloc_mismatch=0 gdb $(which ps)
warning: Found custom handler for signal 7 (Bus error) preinstalled.
warning: Found custom handler for signal 8 (Floating point exception)
preinstalled.
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
GNU gdb (GDB) Fedora 8.2.91.20190401-23.fc30
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ps...
(No debugging symbols found in /usr/bin/ps)
Missing separate debuginfos, use: dnf debuginfo-install
procps-ng-3.3.15-5.fc30.x86_64
(gdb) run
Starting program: /usr/bin/ps 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x773705f8 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
(gdb) where
#0  0x773705f8 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
#1  0x773c2833 in textdomain () from /lib64/libc.so.6
#2  0x775ee531 in ?? () from /lib64/libasan.so.5.0.0
#3  0xec6f in ?? ()
#4  0x773b1f33 in __libc_start_main () from /lib64/libc.so.6
#5  0xf65e in ?? ()

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Just curious - were you able to simply up this limit successfully?

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[robotux at celest dot fr]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||robotux at celest dot fr

--- Comment #23 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #22)
> So this was fixed for GCC 9.  Both the GCC 8 and GCC 7 branches are still
> open for wrong-code fixes, I'd appreciate at least providing "official"
> backports of the fix even if we end up not committing them because for the
> fear of breakage.
> You probably know best - was there any fallout of the two revs committed here
> that needed to be fixed?
> 
> Thanks.

I don't remember any fallout from the final patch no. My reticence for a
backport was due to

* adding a new target hook
* patching functions to generate PIC sequences.

I'm not sure how much these functions have changed over the year, I suspect not
much and the rest of the patch should be fairly self contained. I would not
expect too much work to backport the change itself by someone else (I am not in
a position to do the work myself), but whether such a change would be
acceptable on a stable branch is up to the relevant maintainer.

[Bug target/90568] stack protector should use cmp or sub, not xor, to allow macro-fusion on x86

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 46401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46401&action=edit
gcc10-pr90568-2.patch

Incremental untested patch for the macro-fusion, on top of
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01541.html

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
@Jakub: Can you please reproduce it?

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

[Bug debug/90586] [gdb] gdb wrongly set the breakpoint as expected

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The reason is that somehow the only stmt with line 9 prevailing is one
not originally having it:

   :
  [t.c:11:14] D.1918 = 0;
  [t.c:11:14] // predicted unlikely by early return (on trees) predictor.
  [t.c:9:11] g = {CLOBBER};
  goto ; [INV]

   :
  [t.c:14:10] D.1918 = 0;

   :
:
  return D.1918;

so the return stmt will end up inheriting it if we are "lucky".  try-finally
lowering assigns the location, possibly simply taking the location of the
last stmt from the "throw".

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #2 from Dominique d'Humieres  ---
LSHIFT is a GNU extension defined as

LSHIFT returns a value corresponding to I with all of the bits shifted left by
SHIFT places. If the absolute value of SHIFT is greater than BIT_SIZE(I), the
value is undefined. Bits shifted out from the left end are lost; zeros are
shifted in from the opposite end.

I don't see any mention of "left-shift by negative value is undefined".

If it is the case for the gfortran implementation, this should be documented.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #8 from mccannd at uk dot ibm.com ---
Or more fully:

#0  0x773705f8 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
#1  0x773c2833 in textdomain () from /lib64/libc.so.6
#2  0x775ee531 in __interceptor_textdomain (domainname=0x5556a1a8
"procps-ng")
at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:401
#3  0xec6f in main (argc=1, argv=0x7fffda78) at
ps/display.c:628

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[umesh.kalappa0 at gmail dot com]

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

--- Comment #15 from Umesh Kalappa  ---
>>Yes, but just use a regular thunk.
you mean ,the target-independent code in the C++ front end will generate a less
efficient heavyweight thunk that calls function instead of jumping to it ?

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Thu, 23 May 2019, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578
> 
> Dominique d'Humieres  changed:
> 
>What|Removed |Added
> 
>  Status|RESOLVED|NEW
>  Resolution|INVALID |---
> 
> --- Comment #2 from Dominique d'Humieres  ---
> LSHIFT is a GNU extension defined as
> 
> LSHIFT returns a value corresponding to I with all of the bits shifted left by
> SHIFT places. If the absolute value of SHIFT is greater than BIT_SIZE(I), the
> value is undefined. Bits shifted out from the left end are lost; zeros are
> shifted in from the opposite end.
> 
> I don't see any mention of "left-shift by negative value is undefined".

But it doesn't define what happens either ;)  Thus it is "undefined" :P

So, if the GNU extension would document it as "A LSHIFT by a 
negative value is treated as a RSHIFT" then the frontend has
to emit y < 0 ? x >> y : x << y since what I am saying is that
the middle-end follows the C standard here and treats negative
shift amounts as undefined.

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01579.html

[Bug target/90568] stack protector should use cmp or sub, not xor, to allow macro-fusion on x86

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 23 11:18:41 2019
New Revision: 271552

URL: https://gcc.gnu.org/viewcvs?rev=271552&root=gcc&view=rev
Log:
PR target/90568
* config/i386/i386.md (stack_protect_test_): Use sub instead
of xor.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug target/90588] [AArch64] SVE2 flag patch omits aarch64-protos.h

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-23
 CC||matmal01 at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |matmal01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Matthew Malcomson  ---
Thanks -- I guess I missed that because I bootstrapped on aarch64 instead of
building a cross compiler on an arch where unsigned long and uint64_t are
different.

I'll go and fix it & test it better this time ;-)

[Bug tree-optimization/90594] New: [9/10 regression] Spurious popcount emitted

[wilco at gcc dot gnu.org]

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

Bug ID: 90594
   Summary: [9/10 regression] Spurious popcount emitted
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

The following testcase emits a popcount which computes the final pointer value.
This is redundant given the loop already computes the pointer value. The
popcount causes the code to be significantly larger and slower than previous
GCC versions.

int *bad_popcount (unsigned x, int *p)
{
  for (; x != 0; )
{
  int tmp = __builtin_ctz (x);
  x = x & (x - 1);
  *p++ = tmp;
}
  return p;
}

GCC8:
cbz w0, .L2
.L3:
rbitw2, w0
clz w2, w2
str w2, [x1], 4
sub w2, w0, #1
andsw0, w0, w2
bne .L3
.L2:
mov x0, x1
ret

GCC9:
cbz w0, .L12
mov x4, x1
mov w2, w0
.L11:
rbitw3, w2
clz w3, w3
str w3, [x4], 4
sub w3, w2, #1
andsw2, w2, w3
bne .L11
fmovs0, w0
cnt v0.8b, v0.8b
addvb0, v0.8b
umovw0, v0.b[0]
sub w0, w0, #1
add x0, x0, 1
add x0, x1, x0, lsl 2
ret
.L12:
mov x0, x1
ret

[Bug tree-optimization/88440] size optimization of memcpy-like code

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
Author: rguenth
Date: Thu May 23 11:35:16 2019
New Revision: 271553

URL: https://gcc.gnu.org/viewcvs?rev=271553&root=gcc&view=rev
Log:
2019-05-23  Richard Biener  

PR tree-optimization/88440
* opts.c (default_options_table): Enable
-ftree-loop-distribute-patterns
at -O[2s]+.
* tree-loop-distribution.c (generate_memset_builtin): Fold the
generated call.
(generate_memcpy_builtin): Likewise.
(distribute_loop): Pass in whether to only distribute patterns.
(prepare_perfect_loop_nest): Also allow size optimization.
(pass_loop_distribution::execute): When optimizing a loop
nest for size allow pattern replacement.

* gcc.dg/tree-ssa/ldist-37.c: New testcase.
* gcc.dg/tree-ssa/ldist-38.c: Likewise.
* gcc.dg/vect/vect.exp: Add -fno-tree-loop-distribute-patterns.
* gcc.dg/tree-ssa/ldist-37.c: Adjust.
* gcc.dg/tree-ssa/ldist-38.c: Likewise.
* g++.dg/tree-ssa/pr78847.C: Likewise.
* gcc.dg/autopar/pr39500-1.c: Likewise.
* gcc.dg/autopar/reduc-1char.c: Likewise.
* gcc.dg/autopar/reduc-7.c: Likewise.
* gcc.dg/tree-ssa/ivopts-lt-2.c: Likewise.
* gcc.dg/tree-ssa/ivopts-lt.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-1.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-2.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-3.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-4.c: Likewise.
* gcc.dg/tree-ssa/prefetch-7.c: Likewise.
* gcc.dg/tree-ssa/prefetch-8.c: Likewise.
* gcc.dg/tree-ssa/prefetch-9.c: Likewise.
* gcc.dg/tree-ssa/scev-11.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-33.c: Likewise.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c: Likewise.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-33.c: Likewise.
* gcc.target/i386/pr30970.c: Likewise.
* gcc.target/i386/vect-double-1.c: Likewise.
* gcc.target/i386/vect-double-2.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-2.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-26.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-32.c: Likewise.
* gfortran.dg/vect/vect-5.f90: Likewise.
* gfortran.dg/vect/vect-8.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr78847.C
trunk/gcc/testsuite/gcc.dg/autopar/pr39500-1.c
trunk/gcc/testsuite/gcc.dg/autopar/reduc-1char.c
trunk/gcc/testsuite/gcc.dg/autopar/reduc-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopts-lt-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopts-lt.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-dse-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-dse-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-dse-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-dse-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-9.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-11.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-33.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-33.c
trunk/gcc/testsuite/gcc.dg/vect/vect.exp
trunk/gcc/testsuite/gcc.target/i386/pr30970.c
trunk/gcc/testsuite/gcc.target/i386/vect-double-1.c
trunk/gcc/testsuite/gcc.target/i386/vect-double-2.c
trunk/gcc/testsuite/gfortran.dg/vect/vect-5.f90
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90
trunk/gcc/tree-loop-distribution.c

[Bug rtl-optimization/90595] New: LRA liveness analysis is slow

[rguenth at gcc dot gnu.org]

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

Bug ID: 90595
   Summary: LRA liveness analysis is slow
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Split out from PR88440.  As of today you'll see a big compile-time increase
for compiling module_configure.fppized.f90 of 521.wrf_r at -O2.

Time profile before/after:

╔══╤╤╤═╗
║ PASS │ Before │ After  │ Change  ║
╠══╪╪╪═╣
║ backwards jump threading │ 6.29   │ 6.16   │ 97.93%  ║
║ integrated RA│ 6.76   │ 6.41   │ 94.82%  ║
║ tree SSA incremental │ 9.01   │ 11.16  │ 123.86% ║
║ LRA create live ranges   │ 15.68  │ 40.02  │ 255.23% ║
║ PRE  │ 23.24  │ 32.32  │ 139.07% ║
║ alias stmt walking   │ 27.69  │ 28.75  │ 103.83% ║
║ phase opt and generate   │ 124.13 │ 163.95 │ 132.08% ║
║ TOTAL│ 125.39 │ 165.17 │ 131.73% ║

so LRA live ranges is already slow before.  perf profiling after the change
shows

Samples: 579  of event 'cycles:ppp', Event count (approx.): 257134187434191 
Overhead  Command  Shared Object Symbol 
  22.26%  f951 f951  [.] process_bb_lives
  15.06%  f951 f951  [.] ix86_hard_regno_call_part_clobbered
   8.55%  f951 f951  [.] concat
   6.88%  f951 f951  [.] find_base_term
   3.60%  f951 f951  [.] get_ref_base_and_extent
   3.27%  f951 f951  [.] find_base_term
   2.95%  f951 f951  [.] make_hard_regno_dead

which IMHO points at

static inline void
check_pseudos_live_through_calls (int regno,
  HARD_REG_SET last_call_used_reg_set,
  rtx_insn *call_insn)
{
...
  for (hr = 0; HARD_REGISTER_NUM_P (hr); hr++)
if (targetm.hard_regno_call_part_clobbered (call_insn, hr,
PSEUDO_REGNO_MODE (regno)))
  add_to_hard_reg_set (&lra_reg_info[regno].conflict_hard_regs,
   PSEUDO_REGNO_MODE (regno), hr);

where we do a lot of redundant work because we call this function in a loop
possibly very many times with the same arguments besides regno (but with
same PSEUDO_REGNO_MODE).

[Bug tree-optimization/88440] size optimization of memcpy-like code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #24 from Richard Biener  ---
Fixed on trunk.

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
Or, to put it differently:  It looks odd that while `gcc -gsplit-dwarf -c
test.c -o /path/test.o` puts test.dwo next to test.o into /path/, `gcc
-gsplit-dwarf test.c -o /path/test` puts it into cwd.

[Bug rtl-optimization/90595] LRA liveness analysis is slow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog, ra
 CC||vmakarov at gcc dot gnu.org
  Known to fail||10.0

--- Comment #1 from Richard Biener  ---
Note I have a reduced module_configure.fppized.f90 (reduced to require no
fortran module and only containing a single function).  While WRF sources
seem to be publically available the copy in SPEC itself may be different
enough and the public download is behind a registration wall at least.

SPEC docs say

  Benchmark Description

   521.wrf_r is based on Version 3.6.1 of the Weather Research and
   Forecasting Model (WRF) available from http://www.wrf-model.org/index.php.
...

  Sources and Licensing

   The benchmark was contributed directly to SPEC by UCAR. Note: Therefore,
   source code references to other terms under which the program may be
   available are not relevant for the SPEC CPU version. It uses netcdf; for
   details, see [5]SPEC CPU2017 Licenses.

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 11:47:30 2019
New Revision: 271554

URL: https://gcc.gnu.org/viewcvs?rev=271554&root=gcc&view=rev
Log:
PR c++/90592 add missing word "scope" to __func__ docs

PR c++/90592
* doc/extend.texi (Function Names): Add missing word.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Stephan Bergmann from comment #3)
> Or, to put it differently:  It looks odd that while `gcc -gsplit-dwarf -c
> test.c -o /path/test.o` puts test.dwo next to test.o into /path/, `gcc
> -gsplit-dwarf test.c -o /path/test` puts it into cwd.

probably a better "default" than putting it behind the temporary object
file in $TMPDIR ;)

But yeah...  another fallback would be the linker output location.

That said, -gsplit-dwarf is mostly unmaintained these days...

[Bug c++/90592] Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|unknown |10.0
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Jonathan Wakely  ---
Fixed, thanks.

[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  x86_64:

bad_popcount:
.LFB0:
.cfi_startproc
testl   %edi, %edi
je  .L4
movq%rsi, %rcx
movl%edi, %edx
.p2align 4,,10
.p2align 3
.L3:
xorl%r8d, %r8d
addq$4, %rcx
tzcntl  %edx, %r8d
blsr%edx, %edx
movl%r8d, -4(%rcx)
jne .L3
popcntl %edi, %edi
leal-1(%rdi), %eax
leaq4(%rsi,%rax,4), %rax
ret


this is SCCP doing final value replacement for 'p' and a more general
issue of SCCP eliding out-of-loop IV uses just because it can rather
than because it will save anything (for example it may elide an
induction variable).

I've long had the opinion that this separate pass should go away and
that we instead should perform this transform only when it enables
sth else.

So not really a regression, we just got the ability to compute the
final value of p in generic infrastructure...

[Bug debug/90574] [gdb] gdb wrongly stopped at a breakpoint in an unexecuted line of code

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Richard Biener from comment #1)
> We somehow build a broken(?) CFG from the start:
> 
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   if (argc == 0)
> ;;succ:   3
> 
> ;;   basic block 3, loop depth 0
> ;;pred:   2
> label:
>   if (argc == 1)
> goto ; [INV]
>   else
> goto ; [INV]
> 
> see how BB2 only has a single outgoing edge.  CFG cleanup fixes this for us.
> 
> .gimple has
> 
>   [t.c:2:1] {
> void label = <<< error >>>;
> 
> [t.c:3:6] if (argc == 0) goto ; else goto ;
> :
> [t.c:4:5] {
>   int * ptr;
> 
>   [t.c:6:1] label:
> }
> :
> [t.c:10:6] if (argc == 1) goto ; else goto ;
> 
> so that looks good, likewise .lower:
> 
>   [t.c:3:6] if (argc == 0) goto ; else goto ;
>   :
>   [t.c:6:1] label:
>   :
>   [t.c:10:6] if (argc == 1) goto ; else goto ;
> 
> iff we'd elide an empty block as having no side-effects we would have
> deleted the label.
> 
> Thus confirmed as CFG build bug.

Thanks for the comfirmation. 
Another bug I reported seems also a valid bug with a different code structure.
I am not quite sure whether it is a valid or not. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Thu May 23 12:07:09 2019
New Revision: 271555

URL: https://gcc.gnu.org/viewcvs?rev=271555&root=gcc&view=rev
Log:
Do not use tree_to_wide_ref that point to a temporary (PR c++/90587).

2019-05-23  Martin Liska  

PR c++/90587
* tree-ssa-uninit.c (value_sat_pred_p): The result of &
operation points to a temporary (pointed via tree_to_wide_ref)
that is out of scope after the &.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
For example DCE could, when it comes to marking a loop-closed PHI node
necessary see if it can replace it by computing the final value and if
so do _not_ mark its definition necessary (and record this somewhere).
If at the end the definition did not become necessary we will remove it
and replace the LC PHI with the final value computation.  If not then
we keep the loop-closed PHI.  We already perform similar tricks for
eliding malloc/free pairs for example.  IVOPTs would be another candidate
which could disregard some IV uses if it can replace them via a
final value.

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Martin Liška  ---
Fixed.

[Bug other/86656] Issues found with -fsanitize=address

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 90587, which changed state.

Bug 90587 Summary: [10 Regression] asan: stack-use-after-scope with -O3 and 
-Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90587

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn]

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

Yibiao Yang  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #5 from Yibiao Yang  ---
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90574

This should be also a valid bug report. I change the status of this bug report
as unconfirmed.

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

[vittorio.romeo at outlook dot com]

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

--- Comment #4 from Vittorio Romeo  ---
> I wonder how the "original" testcase looked
like - the one in this bug is probably simplified from real-world code?

This is what the original author of the code (Filipp Gelman) said:

> I was reviewing some code that checked configuration. The configuration 
> struct has several functions taking no arguments and returning bool. The 
> value of an enum determined which of these was called.
> I thought that the choice of which member function to call depends only on 
> the enum and not on anything else in the configuration, so I tried splitting 
> selecting the member function from calling it.
> This code looks much closer to what I reviewed: https://godbolt.org/z/L_W_oi
> The author wrote `test1`. I considered suggesting `test2`, but was surprised 
> by it not optimizing to the same code.

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 13:39:06 2019
New Revision: 271556

URL: https://gcc.gnu.org/viewcvs?rev=271556&root=gcc&view=rev
Log:
PR libstdc++/90220 fix experimental::any_cast for non-object types

This corresponds to the fixes done for std::any_cast, but has to be done
without if-constexpr. The dummy specialization of _Manager_internal<_Op>
is used to avoid instantiating the real _Manager_internal::_S_manage
function just to compare its address.

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/any
trunk/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug libgomp/90596] New: 'GOACC_parallel_keyed' should use 'GOMP_MAP_VARS_TARGET'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90596
   Summary: 'GOACC_parallel_keyed' should use
'GOMP_MAP_VARS_TARGET'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

'GOACC_parallel_keyed' currently calls 'gomp_map_vars' with
'GOMP_MAP_VARS_OPENACC' instead of 'GOMP_MAP_VARS_TARGET', and does its own
'devaddrs' management, split between there and the device plugin.  When
switching to 'GOMP_MAP_VARS_TARGET', it would benefit from 'gomp_coalesce_buf'
handling, and thus avoid each one device memory allocation, copy from host to
device, device memory deallocation call per kernel launch.

[Bug middle-end/90597] New: FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 90597
   Summary: FAIL: gcc.dg/attr-vector_size.c (internal compiler
error)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-vector_size.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -Wall -Wno-unused -S -o attr-vector_size.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-vector_size.c:30:1: internal
compiler error: in layout_type, at stor-layout.c:2401
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-vector_size.c:30:1: internal
compiler error: in layout_type, at stor-layout.c:2401
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.dg/attr-vector_size.c (internal compiler error)
FAIL: gcc.dg/attr-vector_size.c LP64 (test for errors, line 33)
FAIL: gcc.dg/attr-vector_size.c LP64 (test for errors, line 60)
FAIL: gcc.dg/attr-vector_size.c (test for excess errors)

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 14:18:13 2019
New Revision: 271558

URL: https://gcc.gnu.org/viewcvs?rev=271558&root=gcc&view=rev
Log:
PR libstdc++/90220 fix experimental::any_cast for non-object types

This corresponds to the fixes done for std::any_cast, but has to be done
without if-constexpr. The dummy specialization of _Manager_internal<_Op>
is used to avoid instantiating the real _Manager_internal::_S_manage
function just to compare its address.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/experimental/any
   
branches/gcc-9-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

[qinzhao at gcc dot gnu.org]

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Just curious - were you able to simply up this limit
> successfully?

Yes, one of our applications' depth of nested #include is 202

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #8 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #1)
> (I'm starting to think that __float128 support should have been disabled on
> targets where it requires greater alignment than malloc guarantees, instead
> of making GCC's max_align_t lie).

The problem is that popular mallocs do not care about ABI and return unaligned
pointers for allocations smaller than the max_align_t alignment.  As a result,
__float128 support with 16-byte alignment would end up with a potentially
rather short list of supported targets (including targets which have a
16-byte-aligned long double already).

We spent a lot energy fixing this in glibc without breaking backwards
compatibility with existing Emacs binaries:

  

Basically, we had to include a heap rewriter that converts the heap from the
old to the new format.  But other mallocs wouldn't even have to do that, and
they still don't want to fix their default alignment choices unfortunately.

I also found this for the first time:

  

So if the standard moves to the weak guarantee, GCC probably shouldn't make
assumptions in the other direction.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Florian Weimer from comment #8)
> The problem is that popular mallocs do not care about ABI and return
> unaligned pointers for allocations smaller than the max_align_t alignment. 
> As a result, __float128 support with 16-byte alignment would end up with a
> potentially rather short list of supported targets (including targets which
> have a 16-byte-aligned long double already).

Understood.

> I also found this for the first time:
> 
>   
> 
> So if the standard moves to the weak guarantee, GCC probably shouldn't make
> assumptions in the other direction.

Yes, I already fixed libstdc++ to not assume the strong-alignment reading, see
r265068.

But this PR isn't about the alignment of allocations where the size is smaller
than alignof(max_align_t). What makes my life difficult is that some mallocs
(including glibc up to 2.25) do not respect GCC's new alignof(max_align_t) even
for large allocations. I understand why, but it's just annoying that GCC
changed max_align_t to be misleading. If the underlying malloc doesn't agree,
making max_align_t lie isn't very helpful.

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 14:49:15 2019
New Revision: 271561

URL: https://gcc.gnu.org/viewcvs?rev=271561&root=gcc&view=rev
Log:
PR libstdc++/90220 Fix any_cast for non-object types

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220 (partial)
* include/std/any (any_cast(any*), any_cast(const any*)): Do
not attempt ill-formed static_cast to pointers to non-object types.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
function types.

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220
* include/std/any (__any_caster): Use remove_cv_t instead of decay_t.
Avoid a runtime check for types that can never be stored in std::any.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
array types.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/experimental/any
branches/gcc-8-branch/libstdc++-v3/include/std/any
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:08:58 2019
New Revision: 271565

URL: https://gcc.gnu.org/viewcvs?rev=271565&root=gcc&view=rev
Log:
PR libstdc++/90220 Fix any_cast for non-object types

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220 (partial)
* include/std/any (any_cast(any*), any_cast(const any*)): Do
not attempt ill-formed static_cast to pointers to non-object types.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
function types.

Backport from mainline
2019-04-24  Jonathan Wakely  

PR libstdc++/90220
* include/std/any (__any_caster): Use remove_cv_t instead of decay_t.
Avoid a runtime check for types that can never be stored in std::any.
* testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with
array types.

Backport from mainline
2019-05-23  Jonathan Wakely  

PR libstdc++/90220
* include/experimental/any (__any_caster): Constrain to only be
callable for object types. Use remove_cv_t instead of decay_t.
If the type decays or isn't copy constructible, compare the manager
function to a dummy specialization.
(__any_caster): Add overload constrained for non-object types.
(any::_Manager_internal<_Op>): Add dummy specialization.
* testsuite/experimental/any/misc/any_cast.cc: Test function types
and array types.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/experimental/any
branches/gcc-7-branch/libstdc++-v3/include/std/any
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/any/misc/any_cast.cc