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

[ffengqi at gcc dot gnu.org]

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

--- Comment #11 from Qi Feng  ---
I tried 2 patterns for the following test

  /* 1. x >  y  &&  x != 0 --> x > y  */
  /* 2. y <  x  &&  x != 0 --> y < x  */
  /* 3. x != 0  &&  x >  y --> x > y  */
  /* 4. x != 0  &&  y <  x --> y < x  */

  _Bool f1 (unsigned x, unsigned y)
  {
return x >  y  &&  x != 0;
  }

  _Bool f2 (unsigned x, unsigned y)
  {
return y <  x  &&  x != 0;
  }

  _Bool f3 (unsigned x, unsigned y)
  {
return x != 0  &&  x >  y;
  }

  _Bool f4 (unsigned x, unsigned y)
  {
return x != 0  &&  y <  x;
  }

The first one is

  (for and (truth_and bit_and)
(simplify
 (and:c (gt:c@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)))

The transformations did not happen as I checked the dump files of
-fdump-tree-{original,optimized}.

And the second one is

  (simplify
   (truth_andif:C (gt:c@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))

The transformations did happen for all the 4 functions. And the dump of
-fdump-tree-original showes they already happened, so I guess the pattern is
matched before the process get to GIMPLE.

[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> 
> One example of an incompatibility is the following declaration:
> 
>   int __attribute__ ((pure)) abs (int);
> 
> where abs() the built-in is actually declared const.  GCC doesn't currently
> diagnose this except with my patch for bug 81544 (yet to be reviewed).
> 

That's fixed now.

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords|ssemmx  |

--- Comment #5 from Marc Glisse  ---
(In reply to g.peterhoff from comment #4)
> What else should "unsigned __int64" be than a uint64_t (0..2^64-1)?

If they meant uint64_t, they would spell it uint64_t.

> And I miss addcarry/subborrow for uint8/16/128. You could make that
> available as a general __builtin :-)

clang has some __builtin_addc*, we probably already have an enhancement request
in bugzilla asking to implement those...

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

[joseph at codesourcery dot com]

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

--- Comment #41 from joseph at codesourcery dot com  ---
It's likely that caring about exceptions would actually be worse for 
optimization than caring about rounding modes (because exceptions mean 
that floating-point operations can write global state, not just read it).  
I.e., a proper implementation would also indicate splitting 
-ftrapping-math into the existing parts relating only to local 
transformations, and something new for the global effects of operations 
being considered to write the exception state, and so not be movable past 
any code that might read it (which includes most function calls, and asms 
depending on whether they might read the floating-point state register).

(There are plenty of local bugs in this area - both in machine-independent 
optimizations, and in machine-specific code, or libgcc code, that doesn't 
do the right thing regarding exceptions; lots of thorough tests would be 
needed to find such places.  But in general the local bugs should be 
individually straightforward to fix in a way that the global issues 
aren't.)

(See discussions on the gcc mailing list in Dec 2012 / Jan 2013 / Feb 2013 
for more details in this area.)

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
Given how often such issues are in target-specific code, for targets that 
only get built as cross compilers, in practice we'll need someone building 
for all architectures *using a native compiler from the same trunk 
version, and configuring with --enable-werror-always* (whether with 
config-list.mk or otherwise) to detect such problems.  That is, that will 
need doing both as a one-off to find problems now present that 
-Wformat-diag can detect, and subsequently at least every release cycle 
(preferably as a bot whose results are routinely monitored to detect 
problems soon after they are introduced).

I know there are bots building GCC for lots of targets, but I don't know 
if any of the current bots build using current trunk GCC and using 
--enable-werror-always to detect such issues that otherwise only show up 
in a native bootstrap.

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

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 23 19:46:56 2019
New Revision: 271576

URL: https://gcc.gnu.org/viewcvs?rev=271576=gcc=rev
Log:
PR target/90552
* config/i386/i386.c (gen_rtx_cost):
Use ix86_tune_cost instead of ix86_cost.

testsuite/ChangeLog:

PR target/90552
* gcc.target/i386/pr90552.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr90552.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

[g.peterh...@t-online.de]

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

--- Comment #4 from g.peterh...@t-online.de ---
Am 23.05.19 um 20:11 schrieb glisse at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600
> 
> --- Comment #3 from Marc Glisse  ---
> Intel documents that it uses "unsigned __int64" but I don't see where they
> document what __int64 is. We could take a "void *out" argument and cast it
> inside the function, but that would lose useful diagnostics for people trying
> to pass a 32-bit type. We could overload in C++. Not sure any of that is worth
> the trouble, those interfaces are target-specific anyway.
> 
What else should "unsigned __int64" be than a uint64_t (0..2^64-1)? Then this
would look exactly like this:

external __inline uint8_t
__attribute __ ((__ gnu_inline__, __always_inline__, __artificial__))
_addcarry_u64 (uint8_t __CF, uint64_t __X, uint64_t __Y, uint64_t * __P)
{
return __builtin_ia32_addcarryx_u64 (__CF, __X, __Y, __P);
}

And I miss addcarry/subborrow for uint8/16/128. You could make that available
as a general __builtin :-)
Of course it would be better if such functions are included in the C/C++
standard ...

[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/90607] New: [10 regression] gcc.dg/pr53265.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 90607
   Summary: [10 regression] gcc.dg/pr53265.c FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu,
i686-pc-linux-gnu

Between 20190522 (r271513) and 20190523 (r271572), gcc.dg/pr53265.c began to
FAIL on a couple of targets:

+FAIL: gcc.dg/pr53265.c (test for excess errors)

Excess errors:
cc1: warning: '__builtin_memcpy' forming offset [17, 24] is out of the bounds
[0, 16] of object 'c' with type 'unsigned char[16]' [-Warray-bounds]
cc1: warning: '__builtin_memcpy' forming offset [17, 24] is out of the bounds
[0, 16] of object 'a' with type 'unsigned char[16]' [-Warray-bounds]

[Bug c++/90606] New: Replace mfence with faster xchg for std::memory_order_seq_cst.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 90606
   Summary: Replace mfence with faster xchg for
std::memory_order_seq_cst.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

The following example:

#include 
std::atomic a;
void foo_seq_cst(int b) { a = b; }

Compiles with `gcc-9.1 -O3 -std=c++17 -pthread` into 

foo_seq_cst(int):
mov DWORD PTR a[rip], edi
mfence
ret

Whereas `clang++-9 -O3 -std=c++17 -pthread` compiles it into:

foo_seq_cst(int):   # @foo_seq_cst(int)
xchgdword ptr [rip + a], edi
ret



xchg was benchmarked to be 2-3x faster than mfence and Linux kernel switched to
xchg were possible. 

gcc should also switch to using xchg for std::memory_order_seq_cst.

See:

https://lore.kernel.org/lkml/20160112150032-mutt-send-email-...@redhat.com/

https://stackoverflow.com/questions/56205324/why-do-gcc-inserts-mfence-where-clang-dont-use-it/

[Bug middle-end/90605] [10 regression] ICE: in gimplify_cond_expr, at gimplify.c:3998

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/90605] New: [10 regression] ICE: in gimplify_cond_expr, at gimplify.c:3998

[ro at gcc dot gnu.org]

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

Bug ID: 90605
   Summary: [10 regression] ICE: in gimplify_cond_expr, at
gimplify.c:3998
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ibuclaw at gcc dot gnu.org, jason at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

Between 20190522 (r271513) and 20190523 (r271572), three D tests began to FAIL
on Solaris 11/SPARC and x86, both 32 and 64-bit:

+FAIL: gdc.test/runnable/link15017.d   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -O2   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -O2 -frelease   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -O2 -frelease -g   (internal compiler
error)
+FAIL: gdc.test/runnable/link15017.d -O2 -g   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -frelease   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -frelease -g   (internal compiler error)
+FAIL: gdc.test/runnable/link15017.d -g   (internal compiler error)

+FAIL: gdc.test/runnable/sdtor.d   (internal compiler error)
+FAIL: gdc.test/runnable/sdtor.d -O2   (internal compiler error)
[...]
+FAIL: gdc.test/runnable/testaa.d   (internal compiler error)
+FAIL: gdc.test/runnable/testaa.d -fPIC   (internal compiler error)

runnable/sdtor.d: In function 'test51':
runnable/sdtor.d:1297:43: warning: statement will never be executed
[-Wswitch-unreachable]
runnable/sdtor.d: In function 'foo':
runnable/sdtor.d:2195:33: internal compiler error: in gimplify_cond_expr, at
gimplify.c:3998
0x8ebe2ca gimplify_cond_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:3998
0x8e9c343 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12428
0x8ea37e4 gimplify_addr_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:6073
0x8e9ba3f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12518
0x8ea6646 gimplify_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:13479
0x8ea8195 gimplify_call_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:3401
0x8e9c4dc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12443
0x8e99823 gimplify_modify_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5668
0x8e9b5c9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12471
0x8e9ed05 gimplify_stmt(tree_node**, gimple**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:6716
0x8ea7963 gimplify_and_add(tree_node*, gimple**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:465
0x8ea7963 gimplify_return_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1591
0x8e9c116 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12732
0x8e9ed05 gimplify_stmt(tree_node**, gimple**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:6716
0x8e9d03c gimplify_statement_list
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1788
0x8e9d03c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12900
0x8e9ed05 gimplify_stmt(tree_node**, gimple**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:6716
0x8e9f94a gimplify_bind_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1356
0x8e9c4f9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:12672
0x8e9ed05 gimplify_stmt(tree_node**, gimple**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:6716

Most likely due to Jason's recent patch:

2019-05-22  Jason Merrill  

* gimplify.c (gimplify_cond_expr): Don't check TREE_ADDRESSABLE.

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Intel documents that it uses "unsigned __int64" but I don't see where they
document what __int64 is. We could take a "void *out" argument and cast it
inside the function, but that would lose useful diagnostics for people trying
to pass a 32-bit type. We could overload in C++. Not sure any of that is worth
the trouble, those interfaces are target-specific anyway.

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

[g.peterh...@t-online.de]

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

--- Comment #2 from g.peterh...@t-online.de ---
Am 23.05.19 um 19:04 schrieb jakub at gcc dot gnu.org:
> Note, clang agrees with gcc here, and I don't think it is a good idea to 
> change
> this incompatibly.
I think it would be better if there is (on the respective platform) only
exactly an absolute type for the significant size and this is consistently used
everywhere. Then such problems can not occur at all.
PS: I miss the IO-Routines for __int128 (u/int128_t), clang has this. Will they
be retrofitted? On 32-bit platforms (and smaller) these types do not exist
either. (Can that clang?)

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
You can use name_reserved_for_implementation_p for that.

[Bug d/90604] New: ICE in sizemask, at d/dmd/mtype.c:2542

[gs...@t-online.de]

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

Bug ID: 90604
   Summary: ICE in sizemask, at d/dmd/mtype.c:2542
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

$ cat z1.d
void f (__vector(int[8]) n)
{ foreach (i; 0..n) n; }


$ gdc-10-20190519 -c z1.d
d21: internal compiler error: in sizemask, at d/dmd/mtype.c:2542
0x6f68a5 Type::sizemask()
../../gcc/d/dmd/mtype.c:2542
0x6dba5f IntRange::fromType(Type*, bool)
../../gcc/d/dmd/intrange.c:284
0x6dbae5 IntRange::fromType(Type*)
../../gcc/d/dmd/intrange.c:276
0x639a83 visit
../../gcc/d/dmd/dcast.c:3402
0x6428be getIntRange(Expression*)
../../gcc/d/dmd/dcast.c:3559
0x72a10a StatementSemanticVisitor::visit(ForeachRangeStatement*)
../../gcc/d/dmd/statementsem.c:1580
0x7288ea semantic(Statement*, Scope*)
../../gcc/d/dmd/statementsem.c:3498
0x7288ea StatementSemanticVisitor::visit(CompoundStatement*)
../../gcc/d/dmd/statementsem.c:139
0x7244e5 semantic(Statement*, Scope*)
../../gcc/d/dmd/statementsem.c:3498
0x6c958f FuncDeclaration::semantic3(Scope*)
../../gcc/d/dmd/func.c:1696
0x66c2ef Module::semantic3(Scope*)
../../gcc/d/dmd/dmodule.c:814
0x766675 d_parse_file()
../../gcc/d/d-lang.cc:1201

[Bug d/90603] New: ICE in functionParameters, at d/dmd/expression.c:1553

[gs...@t-online.de]

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

Bug ID: 90603
   Summary: ICE in functionParameters, at d/dmd/expression.c:1553
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

$ cat z1.d
auto a(int b) {}
auto a(int b = a) {}


$ gdc-10-20190519 -c z1.d
d21: internal compiler error: Segmentation fault
0xb6ed9f crash_signal
../../gcc/toplev.c:326
0x6a3fc0 functionParameters(Loc, Scope*, TypeFunction*, Type*,
Array*, FuncDeclaration*, Type**, Expression**)
../../gcc/d/dmd/expression.c:1553
0x6b98c1 ExpressionSemanticVisitor::visit(CallExp*)
../../gcc/d/dmd/expressionsem.c:3501
0x6a8495 semantic(Expression*, Scope*)
../../gcc/d/dmd/expressionsem.c:8158
0x69f4b6 resolvePropertiesX(Scope*, Expression*, Expression*)
../../gcc/d/dmd/expression.c:417
0x69f9df resolveProperties(Scope*, Expression*)
../../gcc/d/dmd/expression.c:496
0x6d894d InitializerSemanticVisitor::visit(ExpInitializer*)
../../gcc/d/dmd/initsem.c:349
0x6d85db semantic(Initializer*, Scope*, Type*, NeedInterpret)
../../gcc/d/dmd/initsem.c:520
0x6fe1f6 TypeFunction::semantic(Loc, Scope*)
../../gcc/d/dmd/mtype.c:5643
0x6c5e28 FuncDeclaration::semantic(Scope*)
../../gcc/d/dmd/func.c:683
0x66b478 Module::semantic(Scope*)
../../gcc/d/dmd/dmodule.c:747
0x766365 d_parse_file()
../../gcc/d/d-lang.cc:1153

[Bug d/90602] New: ICE: null field

[gs...@t-online.de]

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

Bug ID: 90602
   Summary: ICE: null field
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

$ cat z1.d
struct S { char[0] x; }
const a = S('a');
const char c = a.x;

$ gdc-10-20190519 -c z1.d
z1.d:3:16: error: Internal Compiler Error: null field x
3 | const char c = a.x;
  |^

[Bug d/90601] New: ICE: gimplification failed (gimplify.c at 13436)

[gs...@t-online.de]

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

Bug ID: 90601
   Summary: ICE: gimplification failed (gimplify.c at 13436)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Outcome of some test runs :

$ cat z1.d
int f (int a)
{
  return ++(a += 1.0);
}


$ gdc-10-20190519 -c z1.d
gimplification failed:
(int) _7 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fdd36758498 precision:32 min  max

pointer_to_this >

arg:0 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fdd36753348 precision:64
pointer_to_this >

def_stmt _7 = (double) a;
version:7>>
z1.d: In function 'f':
z1.d:3:10: internal compiler error: gimplification failed
3 |   return ++(a += 1.0);
  |  ^
0xa0ed94 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13436
0xa21773 gimplify_modify_expr
../../gcc/gimplify.c:5678
0xa0dcba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12464
0xa2172f gimplify_modify_expr
../../gcc/gimplify.c:5662
0xa0dcba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12464
0xa11688 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0xa0e250 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:465
0xa0e250 gimplify_return_expr
../../gcc/gimplify.c:1591
0xa0e250 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12725
0xa11688 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0xa0e75b gimplify_statement_list
../../gcc/gimplify.c:1788
0xa0e75b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12893
0xa11688 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0xa12773 gimplify_bind_expr
../../gcc/gimplify.c:1356
0xa0d4f2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12665
0xa11688 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0xa13729 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:13673
0xa13cb4 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:13817
0x85bc67 cgraph_node::analyze()
../../gcc/cgraphunit.c:667
0x85ee3d analyze_functions
../../gcc/cgraphunit.c:1126

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Note, clang agrees with gcc here, and I don't think it is a good idea to change
this incompatibly.

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Another possibility is to return clk_none from lvalue_kind when seeing a
MODIFY_EXPR with VOID_TYPE_P (TREE_TYPE (ref)).

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The problem is that by the time finish_decltype_type is called, the destructor
call is already folded into a TARGET_EXPR  = {CLOBBER};

The following untested patch fixes it for me:
2019-05-23  Jakub Jelinek  

PR c++/90598
* call.c (build_trivial_dtor_call): Wrap MODIFY_EXPR for
-flifetime-dse into void_type_node NOP_EXPR.

* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/call.c.jj2019-05-23 12:57:16.658493722 +0200
+++ gcc/cp/call.c   2019-05-23 18:37:09.570874611 +0200
@@ -7995,8 +7995,8 @@ build_trivial_dtor_call (tree instance)

   /* A trivial destructor should still clobber the object.  */
   tree clobber = build_clobber (TREE_TYPE (instance));
-  return build2 (MODIFY_EXPR, void_type_node,
-instance, clobber);
+  return build1 (NOP_EXPR, void_type_node,
+build2 (MODIFY_EXPR, void_type_node, instance, clobber));
 }

 /* Subroutine of the various build_*_call functions.  Overload resolution
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj 2019-05-23 18:39:37.034464509
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C2019-05-23 18:39:05.471980348
+0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template  struct C;
+template <> struct C {};
+C t;

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Simplified testcase:

struct A {};
using B = decltype(A ().~A ());
template  struct C;
template <> struct C {};
C t;

This succeeds with GCC 8.x or with -fno-lifetime-dse.

[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 #16 from Eric Botcazou  ---
> 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 ?

The cgraphunit code (cgraph_node::expand_thunk).  I agree that it's suboptimal
but this can often be recouped by means of inlining.

[Bug target/90600] New: incompatible 64-bit-types in x86-intrinsics

[g.peterh...@t-online.de]

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

Bug ID: 90600
   Summary: incompatible 64-bit-types in x86-intrinsics
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Keywords: ssemmx
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.peterh...@t-online.de
  Target Milestone: ---
  Host: x86-64
Target: x86-64
 Build: 9.1.1

COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 9.1.1 20190520 [gcc-9-branch revision 271396] (SUSE Linux) 

snip 1:
using intrinsic_int64_t = decltype(_mm_cvtsi128_si64(__m128i{}));
std::cout<)<
false
true


snip 2:
uint64_ta, b, r;
uint8_t carry;
carry = _addcarry_u64(carry, a, b, );
->
error: invalid conversion from ‘uint64_t*’ {aka ‘long unsigned int*’} to ‘long
long unsigned int*’ [-fpermissive]


Hello,
you're using incompatible 64-bit-types in the x86-intrinsics. Why are not
always and everywhere the default-types taken from "types.h"?
PS: Is there any hope that the completely outdated (from the 70')
short/int/long-types will be completely replaced by u/intX_t (keywords!)? With
(signed/unsigned) char != u/int8_t, so that you can write:
uint8_t ui = 65;
int8_t  si = 65;
unsigned char   uc = 65;
signed char sc = 65;
charc = 65;
std::cout << ui ...
->
65
65
A
A
A

reguards
Gero

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

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Thu May 23 16:07:07 2019
New Revision: 271572

URL: https://gcc.gnu.org/viewcvs?rev=271572=gcc=rev
Log:
PR tree-optimization/90576
* tree-ssa-alias.c (compare_sizes): Remove dead calls to
poly_int_tree_p.
(aliasing_component_refs_p): Fix three way size compare conditional;
give up earlier in case we can not decide on equivalence.

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

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Marek Polacek from comment #4)
> > Suppressing the warning when the enumerator comes from a system header
> > should be fairly easy using in_system_header_at.
> 
> Yes, I got that working myself already.

Do you want this PR then?

> > But for the "use reserved
> > names" requirement -- should we just check whether the name of an enumerator
> > starts with an '_'?
> 
> No, because "_" and "_foo" are not reserved names.
> 
> I suggest "_[_A-Z]" i.e. underscore followed by either another underscore or
> uppercase letter. In practice, for libstdc++'s purposes, it might be enough
> to check for just "_[_S]" but I'd have to double-check that.

Good point.

[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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Marek Polacek from comment #4)
> Suppressing the warning when the enumerator comes from a system header
> should be fairly easy using in_system_header_at.

Yes, I got that working myself already.


> But for the "use reserved
> names" requirement -- should we just check whether the name of an enumerator
> starts with an '_'?

No, because "_" and "_foo" are not reserved names.

I suggest "_[_A-Z]" i.e. underscore followed by either another underscore or
uppercase letter. In practice, for libstdc++'s purposes, it might be enough to
check for just "_[_S]" but I'd have to double-check that.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Reduced:

$ cat x.h
#pragma GCC system_header
enum E { _A, _B, _C };

$ cat x.C
#include "x.h"

void
g ()
{
  E e = _A;
  switch (e)
{
case _A:
case _B:
  break;
}
}

$ ./cc1plus -quiet x.C -Wswitch
x.C: In function ‘void g()’:
x.C:7:10: warning: enumeration value ‘_C’ not handled in switch [-Wswitch]
7 |   switch (e)
  |  ^

Suppressing the warning when the enumerator comes from a system header should
be fairly easy using in_system_header_at.  But for the "use reserved names"
requirement -- should we just check whether the name of an enumerator starts
with an '_'?

[Bug libstdc++/85998] feature request: support C++17 parallel STL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.2 |9.0

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #7)
> GCC 9.1 has been released.

With Intel's PSTL included.

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.4 and 7.5 too.

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:37 2019
New Revision: 271569

URL: https://gcc.gnu.org/viewcvs?rev=271569=gcc=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr

Backport from mainline
2019-01-22  Jonathan Wakely  

PR libstdc++/88740
* testsuite/util/testsuite_hooks.h [stderr] (VERIFY): Use fprintf to
write to stderr instead of using printf.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/testsuite/util/testsuite_hooks.h

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Jonathan Wakely  ---
Fixed for 8.4 and 7.5 too.

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:42 2019
New Revision: 271570

URL: https://gcc.gnu.org/viewcvs?rev=271570=gcc=rev
Log:
PR libstdc++/89466 avoid slow xsltproc command in configure

Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.

This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.

This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.

Backport from mainline
2019-02-27  Jonathan Wakely  

PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.

Added:
branches/gcc-7-branch/libstdc++-v3/src/c++17/
branches/gcc-7-branch/libstdc++-v3/src/c++17/Makefile.in
  - copied, changed from r271569,
branches/gcc-7-branch/libstdc++-v3/src/filesystem/Makefile.in
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/Makefile.in
branches/gcc-7-branch/libstdc++-v3/acinclude.m4
branches/gcc-7-branch/libstdc++-v3/configure
branches/gcc-7-branch/libstdc++-v3/configure.ac
branches/gcc-7-branch/libstdc++-v3/doc/Makefile.in
branches/gcc-7-branch/libstdc++-v3/include/Makefile.in
branches/gcc-7-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-7-branch/libstdc++-v3/po/Makefile.in
branches/gcc-7-branch/libstdc++-v3/python/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/filesystem/Makefile.in
branches/gcc-7-branch/libstdc++-v3/testsuite/Makefile.in

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Author: redi
Date: Thu May 23 15:34:25 2019
New Revision: 271568

URL: https://gcc.gnu.org/viewcvs?rev=271568=gcc=rev
Log:
PR libstdc++/89466 avoid slow xsltproc command in configure

Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.

This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for the local
directory is done using xmlcatalog if available, only checking the
hardcoded list of directories if xmlcatalog fails. The right directory
for Suse is added to the hardcoded list.

This should avoid doing an xsltproc check that would need to download
the stylesheet, so no network connection is made even if a broken
xsltproc is present.

Backport from mainline
2019-02-27  Jonathan Wakely  

PR libstdc++/89466
* acinclude.m4 (GLIBCXX_CONFIGURE_DOCBOOK): Reorder check for local
stylesheet directories before check for xsltproc. Try to use
xmlcatalog to find local stylesheet directory before trying hardcoded
paths. Add path used by suse to hardcoded paths. Adjust xsltproc
check to look for the same stylesheet as doc/Makefile.am uses. Don't
use xsltproc if xmlcatalog fails to find a local stylesheet.
* configure.ac: Check for xmlcatalog.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++17/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/src/c++17/
branches/gcc-8-branch/libstdc++-v3/src/c++17/Makefile.in
  - copied, changed from r271563,
branches/gcc-8-branch/libstdc++-v3/src/filesystem/Makefile.in
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/Makefile.in
branches/gcc-8-branch/libstdc++-v3/acinclude.m4
branches/gcc-8-branch/libstdc++-v3/configure
branches/gcc-8-branch/libstdc++-v3/configure.ac
branches/gcc-8-branch/libstdc++-v3/doc/Makefile.in
branches/gcc-8-branch/libstdc++-v3/include/Makefile.in
branches/gcc-8-branch/libstdc++-v3/libsupc++/Makefile.in
branches/gcc-8-branch/libstdc++-v3/po/Makefile.in
branches/gcc-8-branch/libstdc++-v3/python/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/c++98/Makefile.in
branches/gcc-8-branch/libstdc++-v3/src/filesystem/Makefile.in
branches/gcc-8-branch/libstdc++-v3/testsuite/Makefile.in

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|--- |9.2
Summary|Return type of explicit |[9/10 Regression] Return
   |destructor call wrong   |type of explicit destructor
   ||call wrong

--- Comment #1 from Jonathan Wakely  ---
The regression was caused by r259772

PR c++/61982 - dead stores to destroyed objects.

gcc/cp/
* call.c (build_trivial_dtor_call): New, assigns a clobber.
(build_over_call, build_special_member_call): Use it.
* cp-tree.h: Declare it.
* init.c (build_delete): Remove trivial path.
gcc/
* gimplify.c (gimplify_modify_expr): Simplify complex lvalue on LHS
of clobber.

[Bug middle-end/90599] New: Inefficient code for __builtin_memset

[hjl.tools at gmail dot com]

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

Bug ID: 90599
   Summary: Inefficient code for __builtin_memset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 pieces-6]$ cat x.i
extern char *dst;

void
foo (int x)
{
  __builtin_memset (dst, x, 12);
}
[hjl@gnu-cfl-1 pieces-6]$ make x.s
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O3
-march=skylake  -S x.i
[hjl@gnu-cfl-1 pieces-6]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl  %dil, %eax
movabsq $72340172838076673, %rcx
movzbl  %dil, %edi
imulq   %rcx, %rax  <<< x has been broadcasted to RAX.
imull   $16843009, %edi, %edi
movqdst(%rip), %rdx
movq%rax, (%rdx)
movl%edi, 8(%rdx)  <<< We should just reuse RAX/EAX.
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 10.0.0 20190522 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pieces-6]$

[Bug c++/90598] New: Return type of explicit destructor call wrong

[gcc at mbox dot tinloaf.de]

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

Bug ID: 90598
   Summary: Return type of explicit destructor call wrong
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mbox dot tinloaf.de
  Target Milestone: ---

With GCC 9.1, the return type for an explicit destructor call of an defaulted
destructor has changed from "void" to "void&":


#include 

class Foo {
public:
// With this, the DestructorReturnType below becomes "void"
//~Foo () {} 
};

// … unless I specify the user-defined destructor above, in which case it is
"void"
using DestructorReturnType = decltype(std::declval().~Foo());

template
class TD;

// Says: aggregate 'TD t' has incomplete type and cannot be defined
TD t;


This contradicts [expr.call], point 5.

[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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 7.5 and 8.4 as well.

[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=gcc=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

[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=gcc=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 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 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 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 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=gcc=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 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 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 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=gcc=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 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 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 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 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 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

--- 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=gcc=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 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 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 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 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

--- 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=gcc=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 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 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 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 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 (_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

--- 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=gcc=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 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 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 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=gcc=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 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 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 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 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 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 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 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 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=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 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 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 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 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 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 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 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 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 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 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 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 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 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 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=gcc=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 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 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 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 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 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 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 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 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 : _size_cost;
+  const struct processor_costs *cost
+= speed ? ix86_tune_cost : _size_cost;
   int src_cost;

   switch (code)
--cut here--

[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 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.