[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Richard Smith from comment #0)
> The C++ language rules do not permit optimization (eg, deletion) of direct
> calls to 'operator new' and 'operator delete'.

I thought that was considered a bug?
Gcc does optimize those, like it does malloc/free...

> This bug requests that libstdc++ uses these builtins when available.

So just in std::allocator, or are there other places?

> (Separately, it'd be great if GCC considered supporting them too.)

IIRC (would need to dig up the conversation), when the optimization for
new/delete pairs was added in gcc, the builtin option was rejected.

[Bug rtl-optimization/94292] [10 Regression] ICE: SIGSEGV in forward_propagate_and_simplify (fwprop.c:1417) with -O -g -fno-tree-dce since r10-3985-g8b8ab8f473b42933b9c1e292c4b1ab02adf1863a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-24
 Ever confirmed|0   |1
Summary|[10 Regression] ICE:|[10 Regression] ICE:
   |SIGSEGV in  |SIGSEGV in
   |forward_propagate_and_simpl |forward_propagate_and_simpl
   |ify (fwprop.c:1417) with -O |ify (fwprop.c:1417) with -O
   |-g -fno-tree-dce|-g -fno-tree-dce since
   ||r10-3985-g8b8ab8f473b42933b
   ||9c1e292c4b1ab02adf1863a
   Target Milestone|--- |10.0
 CC||marxin at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r10-3985-g8b8ab8f473b42933b9c1e292c4b1ab02adf1863a.

[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-24
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #5 from Richard Biener  ---
For the DSE part there's no operator delete handling in stmt_kills_ref_p.  The
clobber would need to be handled by DCE which is the one eliding new/delete
pairs.

Probably both are not too difficult to handle.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-24
   Keywords||missed-optimization
 Depends on||94293
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
See PR94293 for more analysis.  We can use PR94294 for the new/delete issue and
the other for the DSE one.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
[Bug 94293] [missed optimization] Useless statements populating local string
not removed

[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed

[eyalroz at technion dot ac.il]

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

--- Comment #6 from Eyal Rozenberg  ---
(In reply to Richard Biener from comment #5)
> DSE part  ... DCE

DSE = Dead Statement Elimination? DCE = Dead Code Elimination?

[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 24 Mar 2020, eyalroz at technion dot ac.il wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
> 
> --- Comment #6 from Eyal Rozenberg  ---
> (In reply to Richard Biener from comment #5)
> > DSE part  ... DCE
> 
> DSE = Dead Statement Elimination? DCE = Dead Code Elimination?

Exactly.

[Bug fortran/93600] [10 Regression] ICE in gfc_match_assignment, at fortran/match.c:1366/1340

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
commit https://gcc.gnu.org/g:b0d84ecc55f3ea86764b119040c5ffde36cd0524

[Bug c++/94276] [9/10 Regression] g++: error: gcc/testsuite/g++.dg/ext/stmtexpr3.C: -fcompare-debug failure since r9-3352-g87bd153645f393a1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug debug/94277] [9/10 Regression] error: undef.c: ‘-fcompare-debug’ failure (length) since r9-6413-g1db01ff96aa5ce5c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:047811579f09048ed538674fd5251b35e5a92025

commit r10-7349-g047811579f09048ed538674fd5251b35e5a92025
Author: Jakub Jelinek 
Date:   Tue Mar 24 09:33:17 2020 +0100

cgraphunit: Avoid code generation differences based on -w/TREE_NO_WARNING
[PR94277]

The following testcase FAILs with -fcompare-debug, but not because -g vs.
-g0 would make a difference, but because the second compilation is done
with
-w in order not to emit warnings twice and -w seems to affect the *.gkd
dump
content.
This is because TREE_NO_WARNING flag, or warn_unused_function does affect
not just whether a warning/pedwarn is printed, but also whether we set
TREE_PUBLIC on such decls.
The following patch makes sure we set it regardless of anything warning
related (TREE_NO_WARNING or warn_unused_function).

2020-03-24  Jakub Jelinek  

PR debug/94277
* cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and
non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC
regardless of whether TREE_NO_WARNING is set on it or whether
warn_unused_function is true or not.

* gcc.dg/pr94277.c: New test.

[Bug debug/94283] [8/9/10 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a5a9400a846244d040caa6d1531434eee8fc8ec7

commit r10-7350-ga5a9400a846244d040caa6d1531434eee8fc8ec7
Author: Jakub Jelinek 
Date:   Tue Mar 24 09:34:58 2020 +0100

if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]

The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
where the decisions what statements are needed is based also on debug stmt
operands, which is wrong.
So, this patch makes sure to never add debug stmt to the worklist, or never
add an assign to worklist just because it is used in a debug stmt in
another
bb.

2020-03-24  Jakub Jelinek  

PR debug/94283
* tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just
set
GF_PLF_2, but don't add them to worklist.  Don't add an assigment
to
worklist or set GF_PLF_2 just because it is used in a debug stmt in
another bb.  Formatting improvements.

* gcc.target/i386/pr94283.c: New test.

[Bug debug/94285] [9/10 Regression] gfortran: error: gcc/testsuite/gfortran.dg/array_constructor_40.f90: ‘-fcompare-debug’ failure (length) since r10-1654

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:565ab7efbdc68cca5a2a81d872015f33359048b4

commit r10-7351-g565ab7efbdc68cca5a2a81d872015f33359048b4
Author: Jakub Jelinek 
Date:   Tue Mar 24 09:36:32 2020 +0100

loop-manip: Avoid -fcompare-debug issues in create_iv [PR94285]

The following testcase FAILs with -fcompare-debug.  The problem is that
create_iv behaves differently when inserting after into an empty bb (in
that
case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
at the end of bb; in that case it will not set location, otherwise it will
set it to the location of next stmt).
This isn't -fcompare-debug friendly, because if inserting after and the
bb contains only debug stmts, then the location will not be set with -g
and will be with -g0, or when inserting before, the location might either
be set from the following debug stmt rather than some non-debug stmt after
that, or might not be set with -g0 if it is to be inserted at the end of
bb,
while with -g would be set to location of debug stmt.

2020-03-24  Jakub Jelinek  

PR debug/94285
* tree-ssa-loop-manip.c (create_iv): If after, set stmt location to
e->goto_locus even if gsi_bb (*incr_pos) contains only debug stmts.
If not after and at *incr_pos is a debug stmt, set stmt location to
location of next non-debug stmt after it if any.

* gfortran.dg/pr94285.f90: New test.

[Bug debug/94283] [8/9 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] gcc:|[8/9 Regression] gcc:
   |error:  |error:
   |gcc/testsuite/gcc.dg/fold-b |gcc/testsuite/gcc.dg/fold-b
   |opcond-1.c: |opcond-1.c:
   |‘-fcompare-debug’ failure   |‘-fcompare-debug’ failure
   |since   |since
   |r7-4804-gb54819879e0518b3   |r7-4804-gb54819879e0518b3

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/94285] [9 Regression] gfortran: error: gcc/testsuite/gfortran.dg/array_constructor_40.f90: ‘-fcompare-debug’ failure (length) since r10-1654

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] gfortran: |[9 Regression] gfortran:
   |error:  |error:
   |gcc/testsuite/gfortran.dg/a |gcc/testsuite/gfortran.dg/a
   |rray_constructor_40.f90:|rray_constructor_40.f90:
   |‘-fcompare-debug’ failure   |‘-fcompare-debug’ failure
   |(length) since r10-1654 |(length) since r10-1654

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/94277] [9 Regression] error: undef.c: ‘-fcompare-debug’ failure (length) since r9-6413-g1db01ff96aa5ce5c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] error:|[9 Regression] error:
   |undef.c: ‘-fcompare-debug’  |undef.c: ‘-fcompare-debug’
   |failure (length) since  |failure (length) since
   |r9-6413-g1db01ff96aa5ce5c   |r9-6413-g1db01ff96aa5ce5c

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Eyal Rozenberg from comment #6)
> (In reply to Richard Biener from comment #5)
> > DSE part  ... DCE
> 
> DSE = Dead Statement Elimination? DCE = Dead Code Elimination?

I thought Dse was dead store elimination.

[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #1 from Martin Liška  ---
I'm taking this as I want to learn how to fix -fcompare-debug issues ;)

[Bug debug/94296] New: [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375

[marxin at gcc dot gnu.org]

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

Bug ID: 94296
   Summary: [10 Regression] gcc: error:
gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’
failure (length) since r10-4482-gaea86742ce396375
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I see the following error:

$ gcc gcc/testsuite/gcc.dg/cleanup-13.c -fno-asynchronous-unwind-tables
-fcompare-debug
gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure
(length)

[Bug debug/94296] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-24
 Ever confirmed|0   |1
  Known to work||9.3.0
   Target Milestone|--- |10.0
   Priority|P3  |P2
  Known to fail||10.0

[Bug target/94286] [10 Regression] ICE: in decompose, at rtl.h:2279 with __builtin_sub_overflow() at -O -g

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:596c90d35591589e0efddda65c81609fb422a986

commit r10-7352-g596c90d35591589e0efddda65c81609fb422a986
Author: Jakub Jelinek 
Date:   Tue Mar 24 10:28:58 2020 +0100

arm: Fix arm {,u}subvdi4 and usubvsi4 expanders [PR94286]

The following testcase ICEs, because these expanders will happily create
a SImode 0x8000 CONST_INT, which is not valid RTL, as CONST_INTs need
to
be sign extended from the mode precision to full HWI.

2020-03-24  Jakub Jelinek  

PR target/94286
* config/arm/arm.md (subvdi4, usubvsi4, usubvdi4): Use gen_int_mode
instead of GEN_INT.

* gcc.dg/pr94286.c: New test.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
I don't believe there is a "new/delete" issue.

[Bug target/94286] [10 Regression] ICE: in decompose, at rtl.h:2279 with __builtin_sub_overflow() at -O -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/94125] [9 Regression] wrong code at -O3 on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Bin Cheng :

https://gcc.gnu.org/g:95c969e58f7905b14d3f2889cf41595eb2c13cbb

commit r9-8411-g95c969e58f7905b14d3f2889cf41595eb2c13cbb
Author: Bin Cheng 
Date:   Tue Mar 24 17:40:21 2020 +0800

backport PR94125: Update post order number for merged SCC.

Function loop_distribution::break_alias_scc_partitions needs to compute
SCC with runtime alias edges skipped.  As a result, partitions could be
re-assigned larger post order number than SCC's precedent partition and
distributed before the precedent one.  This fixes the issue by updating
the merged partition to the minimal post order in SCC.

Backport from mainline.
PR tree-optimization/94125
* tree-loop-distribution.c
(loop_distribution::break_alias_scc_partitions): Update post order
number for merged scc.

* gcc.dg/tree-ssa/pr94125.c: New test.

[Bug tree-optimization/94125] [9 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||9.3.1
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Richard Biener  ---
Fixed.

[Bug c++/94297] New: std::replace internal compiler error

[jens.seifert at de dot ibm.com]

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

Bug ID: 94297
   Summary: std::replace internal compiler error
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

#include 
#include 

void patch(std::string& s)
{
   std::replace(s.begin(),s.end(),'.','-');
}

gcc replace.C

In file included from
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/uniform_int_dist.h:35,
 from
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algo.h:66,
 from /opt/rh/devtoolset-8/root/usr/include/c++/8/algorithm:62,
 from replace.C:1:
/opt/rh/devtoolset-8/root/usr/include/c++/8/limits:1677:7: internal compiler
error: Segmentation fault
   max() _GLIBCXX_USE_NOEXCEPT { return __DBL_MAX__; }
   ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccFTVYLT.out file, please attach this to
your bugreport.

[Bug target/94297] PPCLE std::replace internal compiler error

[jens.seifert at de dot ibm.com]

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

Jens Seifert  changed:

   What|Removed |Added

Summary|std::replace internal   |PPCLE std::replace internal
   |compiler error  |compiler error
  Component|c++ |target
 CC||wschmidt at gcc dot gnu.org

--- Comment #1 from Jens Seifert  ---
Same code compile on x86 on same version of compiler.

[Bug target/94298] New: x86 duplicates loads

[rguenth at gcc dot gnu.org]

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

Bug ID: 94298
   Summary: x86 duplicates loads
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For the following testcase at -O3 -fgimple (gimple testcase because the
vectorizer generated code depends on not committed patches) we somehow
duplicate the load from y:

typedef double v2df __attribute__((vector_size(16)));
typedef long v2di __attribute__((vector_size(16)));
double x[1024], y[1024];
void __GIMPLE (ssa,guessed_local(10737416))
foo ()
{
  v2df * vectp_x7;
  v2df vect__56;
  v2df vect__45;
  v2df * vectp_y3;
  v2df _12;
  v2df _13;
  unsigned int _19;
  unsigned int _24;

  __BB(2,guessed_local(10737416)):
  goto __BB3(precise(134217728));

  __BB(3,loop_header(1),guessed_local(1063004409)):
  vectp_y3_21 = __PHI (__BB2: &y, __BB3: vectp_y3_17);
  vectp_x7_6 = __PHI (__BB2: &x, __BB3: vectp_x7_20);
  _19 = __PHI (__BB2: 0u, __BB3: _24);
  vect__45_14 = __MEM  ((double *)vectp_y3_21);
  _13 = __VEC_PERM (vect__45_14, vect__45_14, _Literal (v2di) { 1l, 1l });
  _12 = __VEC_PERM (vect__45_14, vect__45_14, _Literal (v2di) { 0l, 0l });
  vect__56_7 = _12 + _13;
  __MEM  ((double *)vectp_x7_6) = vect__56_7;
  vectp_y3_17 = vectp_y3_21 + 16ul;
  vectp_x7_20 = vectp_x7_6 + 16ul;
  _24 = _19 + 1u;
  if (_24 != 512u)
goto __BB3(adjusted(132875551));
  else
goto __BB4(adjusted(1342177));

  __BB(4,guessed_local(10737416)):
  return;

}


results in

foo:
.LFB0:
.cfi_startproc
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
movapd  y(%rax), %xmm1
movapd  y(%rax), %xmm0
addq$16, %rax
unpcklpd%xmm1, %xmm1
unpckhpd%xmm0, %xmm0
addpd   %xmm1, %xmm0
movaps  %xmm0, x-16(%rax)
cmpq$8192, %rax
jne .L2
ret

The duplication happens in IRA/LRA but I suspect either x86 costing or
operand constraints makes them think this is cheaper.  LRA is fed with

(insn 8 6 11 3 (set (reg/v:V2DF 85 [ vect__45 ])
(mem:V2DF (plus:DI (reg:DI 86 [ ivtmp.6 ])
(symbol_ref:DI ("y") [flags 0x2]  ))
[1 MEM[symbol: y, index: ivtmp.6_7, offset: 0B]+0 S16 A128])) 1338
{movv2df_internal}
 (expr_list:REG_EQUIV (mem:V2DF (plus:DI (reg:DI 86 [ ivtmp.6 ])
(symbol_ref:DI ("y") [flags 0x2]  ))
[1 MEM[symbol: y, index: ivtmp.6_7, offset: 0B]+0 S16 A128])
(nil)))
(insn 11 8 12 3 (set (reg:V2DF 89)
(vec_select:V2DF (vec_concat:V4DF (reg/v:V2DF 85 [ vect__45 ])
(reg/v:V2DF 85 [ vect__45 ]))
(parallel [
(const_int 0 [0])
(const_int 2 [0x2])
]))) "t2.c":27:3 2995 {*vec_interleave_lowv2df}
 (nil))
(insn 12 11 13 3 (set (reg:V2DF 90)
(vec_select:V2DF (vec_concat:V4DF (reg/v:V2DF 85 [ vect__45 ])
(reg/v:V2DF 85 [ vect__45 ]))
(parallel [
(const_int 1 [0x1])
(const_int 3 [0x3])
]))) "t2.c":27:3 2989 {*vec_interleave_highv2df}
 (expr_list:REG_DEAD (reg/v:V2DF 85 [ vect__45 ])
(nil)))
(insn 13 12 14 3 (set (reg:V2DF 91 [ vect__56 ])
(plus:V2DF (reg:V2DF 89)
(reg:V2DF 90))) "t2.c":27:3 1519 {*addv2df3}
 (expr_list:REG_DEAD (reg:V2DF 90)
(expr_list:REG_DEAD (reg:V2DF 89)
(expr_list:REG_EQUIV (mem:V2DF (plus:DI (reg:DI 86 [ ivtmp.6 ])
(symbol_ref:DI ("x") [flags 0x2]  )) [1 MEM[symbol: x, index: ivtmp.6_7, offset: 0B]+0 S16
A128])
(nil)
(insn 14 13 15 3 (set (mem:V2DF (plus:DI (reg:DI 86 [ ivtmp.6 ])
(symbol_ref:DI ("x") [flags 0x2]  ))
[1 MEM[symbol: x, index: ivtmp.6_7, offset: 0B]+0 S16 A128])
(reg:V2DF 91 [ vect__56 ])) "t2.c":27:3 1338 {movv2df_internal}
 (expr_list:REG_DEAD (reg:V2DF 91 [ vect__56 ])
(nil)))

and the LRA:

 Choosing alt 3 in insn 11:  (0) x  (1) 0  (2) m
{*vec_interleave_lowv2df}
  Creating newreg=92 from oldreg=89, assigning class SSE_REGS to r92
   11: r92:V2DF=vec_select(vec_concat(r92:V2DF,[r86:DI+`y']),parallel)
Inserting insn reload before:
   26: r92:V2DF=[r86:DI+`y']
Inserting insn reload after:
   27: r89:V2DF=r92:V2DF

and postreload CSE cannot do anything because the shuffle clobbers the
reg we loaded into (only sched2 moves things in a way that CSE would
be possible again but after sched2 there's no CSE anymore).

[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jakub at gcc dot gnu.org
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
It has something to do with end location of function:

$ cat hash.c
void fn1()
{
}
void fn2()
{
  ;
}

$ ./xg++ -B. -g hash.c -c -O1 -fno-tree-dce -fipa-icf -fno-tree-forwprop
-fdump-rtl-cmpelim=/dev/stdout
...
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 5 2 8 2 (debug_marker) "hash.c":6:3 -1
 (nil))

$ ./xg++ -B. -g hash.c -c -O1 -fno-tree-dce -fipa-icf -fno-tree-forwprop
-fdump-rtl-pro_and_epilogue=/dev/stdout
...
(note 2 9 5 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 5 2 10 2 (debug_marker) "hash.c":6:3 -1
 (nil))
(note 10 5 11 2 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 11 10 12 2 (simple_return) "hash.c":7:1 -1
 (nil)
 -> simple_return)

$ ./xg++ -B. -g hash.c -c -O1 -fno-tree-dce -fipa-icf -fno-tree-forwprop
-fdump-rtl-pro_and_epilogue=/dev/stdout -g0
...
(note 9 2 10 2 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 10 9 11 2 (simple_return) "hash.c":4:6 -1
 (nil)
 -> simple_return)

So hash.c:4:6 is DECL_SOURCE_LOCATION while hash.c:7:1 is function_end_locus.
So maybe a bad source_location or maybe screwed by IPA ICF.

Anyway, leaving for now..

[Bug target/94254] [10 regression] r10-7312 causes compiler hangs

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
(In reply to rsand...@gcc.gnu.org from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > That patch looks fine, thank you!
> > 
> > Is there some way you can test if this works?  Ideally in the testsuite
> > of course, but that can be hard :-/
> 
> I've now tried doing a bootstrap & regtest with --with-cpu-power6 as well,
> comparing without the lra patch with after both patches.  (With master the
> build hangs in the same way as it did for Zdenek.)  There didn't seem
> to be any differences in test results.
> 
> Hopefully that will have given some execution test coverage when
> running things like gcc.dg/dfp and c-c++-common/dfp.

Excellent :-)


Segher

[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536

commit r10-7353-g906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536
Author: Martin Liska 
Date:   Tue Mar 24 11:40:10 2020 +0100

Improve endianess detection.

PR lto/94249
* plugin-api.h: Add more robust endianess detection.

[Bug target/94254] [10 regression] r10-7312 causes compiler hangs

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
(In reply to Zdenek Sojka from comment #14)
> (In reply to rsand...@gcc.gnu.org from comment #11)
> > Created attachment 48088 [details]
> > Candidate patch
> 
> It fixes the build for me.
> I am unable to find a way how to run the testsuite on a non-native system
> (using qemu userspace emulation).

Yeah, with qemu it is harder than with proper emulators (qemu does not
mimic any existing cpu model closely).  It should be possible if you do
some magic in a boards file.

Maybe ask on gcc@?  And/or start a topic for it on the wiki?

[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug debug/94296] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/cleanup-13.c: ‘-fcompare-debug’ failure (length) since r10-4482-gaea86742ce396375

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
This is yet another test that should be dg-skip-if -fcompare-debug and
-fno-asynchronous-unwind-tables.
The code is different depending on the __GCC_HAVE_DWARF2_CFI_ASM macro, which
is dependent on whether -g -fno-asynchronous-unwind-tables is present or not.
$ ./cc1 -quiet -g -fno-asynchronous-unwind-tables -dD -E /dev/null | grep CFI
#define __GCC_HAVE_DWARF2_CFI_ASM 1
$ ./cc1 -quiet -g0 -fno-asynchronous-unwind-tables -dD -E /dev/null | grep CFI
$ ./cc1 -quiet -g -gtoggle -fno-asynchronous-unwind-tables -dD -E /dev/null |
grep CFI
$ ./cc1 -quiet -g -fasynchronous-unwind-tables -dD -E /dev/null | grep CFI
#define __GCC_HAVE_DWARF2_CFI_ASM 1
$ ./cc1 -quiet -g0 -fasynchronous-unwind-tables -dD -E /dev/null | grep CFI
#define __GCC_HAVE_DWARF2_CFI_ASM 1
$ ./cc1 -quiet -g -gtoggle -fasynchronous-unwind-tables -dD -E /dev/null | grep
CFI
#define __GCC_HAVE_DWARF2_CFI_ASM 1
This macro is predefined when code should use .cfi_* directives in inline asm,
which is not when the assembler doesn't support them obviously, but otherwise
either when -fasynchronous-unwind-tables is on, or when -g is on.  If neither
is on, neither .eh_frame nor .debug_frame will be emitted and thus the .cfi*
directives are undesirable.

[Bug sanitizer/94299] New: false positive: AddressSanitizer: stack-use-after-scope on address

[jan.kratochvil at redhat dot com]

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

Bug ID: 94299
   Summary: false positive: AddressSanitizer:
stack-use-after-scope on address
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 48103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48103&action=edit
reproducer patch

I believe it is a false positive.

gcc-9.2.1-1.fc31.x86_64

git clone https://github.com/llvm/llvm-project.git
(cd llvm-project;git checkout b6ae8937e031cde2e70e6a83d46c21e940fdf4ac;patch
-p1 <../asan.patch)
mkdir llvm-project-gccassertdebugasanO1
cd llvm-project-gccassertdebugasanO1
cmake ../llvm-project-gccassertdebugasanO1/llvm/ -DCMAKE_BUILD_TYPE=Debug 
-DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" 
-DLLVM_USE_SPLIT_DWARF=ON -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold 
-Wl,--gdb-index" -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold  -Wl,--gdb-index"
-DLLVM_ENABLE_ASSERTIONS=ON  -DLLVM_OPTIMIZED_TABLEGEN=ON
-DLLVM_USE_SANITIZER=Address
make
gdb -batch -ex 'catch syscall exit_group' -ex r -ex bt -ex 'frame 19' -ex 'info
source' --args ./bin/lldb -o 'command regex -h h -s s foo s/1/2/' 
Catchpoint 1 (syscall 'exit_group' [231])
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 1526560]
[Detaching after vfork from child process 1526576]
[New Thread 0x7fffd1ad2700 (LWP 1526592)]
(lldb) command regex -h h -s s foo s/1/2/
=
==1526553==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffa410 at pc 0x7fffd9c497ec bp 0x7fff9c10 sp 0x7fff9c00
READ of size 1 at 0x7fffa410 thread T0
#0 0x7fffd9c497eb in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*, std::forward_iterator_tag)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x28d77eb)
#1 0x7fffdb147b04 in
lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd5b04)
#2 0x7fffdb14d6b2 in
lldb_private::CommandObjectRegexCommand::CommandObjectRegexCommand(lldb_private::CommandInterpreter&,
llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int, unsigned int,
bool)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3ddb6b2)
#3 0x7fffe2c80c35 in
CommandObjectCommandsAddRegex::DoExecute(lldb_private::Args&,
lldb_private::CommandReturnObject&)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0xb90ec35)
#4 0x7fffdb1432c3 in lldb_private::CommandObjectParsed::Execute(char
const*, lldb_private::CommandReturnObject&)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd12c3)
#5 0x7fffdb12c344 in lldb_private::CommandInterpreter::HandleCommand(char
const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&,
lldb_private::ExecutionContext*, bool, bool)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dba344)
#6 0x7fffdb1319be in
lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&,
std::__cxx11::basic_string, std::allocator
>&)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dbf9be)
#7 0x7fffdad4286f in lldb_private::IOHandlerEditline::Run()
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x39d086f)
#8 0x7fffdacb1d2d in lldb_private::Debugger::RunIOHandlers()
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x393fd2d)
#9 0x7fffdb0e5ade in
lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool,
lldb_private::CommandInterpreterRunOptions&)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3d73ade)
#10 0x7fffd9e51ed9 in lldb::SBDebugger::RunCommandInterpreter(bool, bool,
lldb::SBCommandInterpreterRunOptions&, int&, bool&, bool&)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x2adfed9)
#11 0x412c7e in Driver::MainLoop()
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/lldb+0x412c7e)
#12 0x42339d in main
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdeb

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-03-24

--- Comment #1 from Andrew Pinski  ---
>I believe it is a false positive.
If it is a false positive, then without address santiizer, GCC might produce
wrong code 
But I really have my doubts.
What line is causing the failure?
That is what does:
#1 0x7fffdb147b04 in
lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int)
(/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd5b04)

Correspond to?

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I forgot to say one more thing, GCC is more strict than LLVM when it comes to
temps going out of scope too.

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[jan.kratochvil at redhat dot com]

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

--- Comment #3 from Jan Kratochvil  ---
(In reply to Andrew Pinski from comment #1)
> #1 0x7fffdb147b04 in
> lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
> llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int)
> (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/
> liblldb.so.11git+0x3dd5b04)
> 
> Correspond to?

(gdb) frame
#14 lldb_private::CommandObject::CommandObject (this=0x612133c0,
interpreter=..., name=..., help=..., syntax=..., flags=) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Interpreter/CommandObject.cpp:47
47m_cmd_help_short = std::string(help);

llvm::StringRef help is from

#15 0x7fffdb14d6b3 in lldb_private::CommandObjectRaw::CommandObjectRaw
(flags=0, syntax=..., help=..., name=..., interpreter=..., this=0x612133c0)
at
/home/jkratoch/redhat/llvm-monorepo3/lldb/include/lldb/Interpreter/CommandObject.h:396

llvm::StringRef help = ""

which is from

#16 lldb_private::CommandObjectRegexCommand::CommandObjectRegexCommand
(this=0x612133c0, interpreter=..., name=..., help=..., syntax=...,
max_matches=10, completion_type_mask=0, is_removable=true) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Interpreter/CommandObjectRegexCommand.cpp:24

llvm::StringRef help

which is from

#18 CommandObjectCommandsAddRegex::DoExecute (this=,
command=..., result=...) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Commands/CommandObjectCommands.cpp:991
991 m_regex_cmd_up = std::make_unique(
992 m_interpreter, name, m_options.GetHelp(),
m_options.GetSyntax(), 10, 0,
993 true);

m_options.GetHelp()

which is

llvm::StringRef GetHelp() { return (m_help.empty() ? "" : m_help); }
llvm::StringRef GetSyntax() { return (m_syntax.empty() ? "" : m_syntax); }
std::string m_help;
std::string m_syntax;

Surprisingly replacing it by:

llvm::StringRef GetHelp() { return m_help; }
llvm::StringRef GetSyntax() { return m_syntax; }
std::string m_help;
std::string m_syntax;

"fixes" the problem.

Compiling with -O0 (instead of -O1) by using
-DLLVM_OPTIMIZE_SANITIZED_BUILDS=OFF also "fixes" the problem.

[Bug target/94291] [10 Regression] ICE: in reg_or_subregno, at jump.c:1928 at -Og since r10-3993-ga79048f6250febc1acce09d790035276d534e754

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I guess this is related to PR84169
r8-6756-gba95aa209678e681dcc86df9ebd0a39501c70187
The code assumes that for split_i2i3 SET_DEST must be a REG or SUBREG of REG,
but nothing actually checks this.  In the testcase it is a MEM instead.

[Bug target/94291] [10 Regression] ICE: in reg_or_subregno, at jump.c:1928 at -Og since r10-3993-ga79048f6250febc1acce09d790035276d534e754

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This is on try_combine on:
(gdb) p debug_rtx (i3)
(insn 20 12 22 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [1 x+0 S4 A32])
(reg:SI 125)) "pr94291.c":7:8 241 {*arm_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 125)
(nil)))
(gdb) p debug_rtx (i2)
(insn 12 7 20 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 121 [  ])
(const_int 0 [0])))
(set (reg:SI 125)
(reg:SI 121 [  ]))
]) "pr94291.c":7:8 248 {*movsi_compare0}
 (expr_list:REG_UNUSED (reg:CC 100 cc)
(nil)))
where it is merged into cc = r121 cmp 0; [sfp-4] = r121 and as that isn't
recognized, it is being split_i2i3 into: [sfp-4] = r121 followed by cc = r121
cmp 0 where SET_DEST of newi2pat is a MEM rather than REG.
So, either we should somewhere punt instead of set split_i2i3 because the dest
is a MEM, not REG, or we should handle it somehow.

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #4 from Martin Liška  ---
I'm going to reproduce that..

[Bug target/94292] [10 Regression] ICE: SIGSEGV in forward_propagate_and_simplify (fwprop.c:1417) with -O -g -fno-tree-dce since r10-3985-g8b8ab8f473b42933b9c1e292c4b1ab02adf1863a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested fix.

[Bug tree-optimization/94300] New: [10 Regression] memcpy vector load miscompiled during const-prop

[kretz at kde dot org]

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

Bug ID: 94300
   Summary: [10 Regression] memcpy vector load miscompiled during
const-prop
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Test case `-O1 -march=skylake-avx512`:

int main()  
{   
  double mem[16];   
  using V [[gnu::vector_size(64)]] = double;
  const V a{0, 1, 2, 3, 4, 5, 6, 7};
  const V b{8, 9, 10, 11, 12, 13, 14, 15};  
  __builtin_memcpy(mem, &a, 64);
  __builtin_memcpy(mem + 8, &b, 64);
  V c = {}; 
  __builtin_memcpy(&c, mem + 4, 64);
  if (c[5] != double(9))
__builtin_abort();  
}

>From my extended test case, where c would be {4, 5, 6, 7, 8, 15, 9, 10}. If GCC
is made to forget the contents of mem (e.g. inline-asm), the test does not
fail. GCC9 does not do constant evaluation of the code above and therefore
doesn't fail.

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So I was able to reproduce the problem but I don't see what exactly happens
there. Note that -O2 is needed in order to process inlining and further
optimizations. I bet it's an issue in the code itself.
Feel free to send a reduced-testcase:
https://gcc.gnu.org/wiki/HowToPrepareATestcase

[Bug target/94298] x86 duplicates loads

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
The situation is a bit more complicated. IRA DTRT:

8: r85:V2DF=[r86:DI+`y']
  REG_EQUIV [r86:DI+`y']
   11: r89:V2DF=vec_select(vec_concat(r85:V2DF,r85:V2DF),parallel)
   12: r90:V2DF=vec_select(vec_concat(r85:V2DF,r85:V2DF),parallel)
  REG_DEAD r85:V2DF

Later, LRA propagates memory operand into the insn. Since the insn clobbers its
input, multiple loads are emitted:

   26: xmm1:V2DF=[ax:DI+`y']
   11: xmm1:V2DF=vec_select(vec_concat(xmm1:V2DF,[ax:DI+`y']),parallel)
   28: xmm0:V2DF=[ax:DI+`y']
   12: xmm0:V2DF=vec_select(vec_concat([ax:DI+`y'],xmm0:V2DF),parallel)

which is further "optimized" in postreload pass:

   26: xmm1:V2DF=[ax:DI+`y']
   11: xmm1:V2DF=vec_select(vec_concat(xmm1:V2DF,xmm1:V2DF),parallel)
   28: xmm0:V2DF=[ax:DI+`y']
   12: xmm0:V2DF=vec_select(vec_concat(xmm0:V2DF,xmm0:V2DF),parallel)

It looks to me that a heuristics is missing in LRA, where memory operand
shouldn't propagate into insn, if there are multiple uses of a register.

[Bug tree-optimization/94300] [10 Regression] memcpy vector load miscompiled during const-prop since r10-6809-g7f5617b00445dcc8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||9.3.0
   Priority|P3  |P1
   Last reconfirmed||2020-03-24
Summary|[10 Regression] memcpy  |[10 Regression] memcpy
   |vector load miscompiled |vector load miscompiled
   |during const-prop   |during const-prop since
   ||r10-6809-g7f5617b00445dcc8
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-6809-g7f5617b00445dcc8.
I can reproduce that on Intel SDE simulator:

$ g++ pr94300.c -O1 -march=skylake-avx512 &&
/home/marxin/Programming/intel-sde-new/sde-external-8.16.0-2018-01-30-lin/sde
-skx -- ./a.out 
Aborted (core dumped)

[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/94274] fold phi whose incoming args are defined from binary operations

[z.zhanghaijian at huawei dot com]

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

--- Comment #3 from z.zhanghaijian at huawei dot com  ---
(In reply to Marc Glisse from comment #1)
> Detecting common beginnings / endings in branches is something gcc does very
> seldom. Even at -Os, for if(cond)f(b);else f(c); we need to wait until
> rtl-optimizations to get a single call to f. (of course the reverse
> transformation of duplicating a statement that was after the branches into
> them, if it simplifies, is nice as well, and they can conflict)
> I don't know if handling one such very specific case (binary operations with
> a common argument) separately is a good idea when we don't even handle unary
> operations.

I tried to test this fold on specint2017 and found some performance gains on
500.perlbench_r. Then compared the assemble and found some improvements.

For example:

S_invlist_max, which is inlined by many functions, such as
S__append_range_to_invlist, S_ssc_anything, Perl__invlist_invert ...

invlist_inline.h:
#define FROM_INTERNAL_SIZE(x) ((x)/ sizeof(UV))

S_invlist_max(inlined by S__append_range_to_invlist, S_ssc_anything,
Perl__invlist_invert, )：
return SvLEN(invlist) == 0  /* This happens under _new_invlist_C_array */
   ? FROM_INTERNAL_SIZE(SvCUR(invlist)) - 1
   : FROM_INTERNAL_SIZE(SvLEN(invlist)) - 1;

Dump tree phiopt：

 [local count: 536870911]:
  _46 = pretmp_112 >> 3;
  iftmp.1123_47 = _46 + 18446744073709551615;
  goto ; [100.00%]

   [local count: 536870911]:
  _48 = _44 >> 3;
  iftmp.1123_49 = _48 + 18446744073709551615;

   [local count: 1073741823]:
  # iftmp.1123_50 = PHI 

Which can replaces with：

   [local count: 536870912]:

   [local count: 1073741823]:
  # _48 = PHI <_44(2), pretmp_112(3)>
  _49 = _48 >> 3;
  iftmp.1123_50 = _49 + 18446744073709551615;

Assemble：

lsr x5, x6, #3
lsr x3, x3, #3
sub x20, x5, #0x1
sub x3, x3, #0x1
cselx20, x3, x20, ne

Replaces with：

cselx3, x3, x4, ne
lsr x3, x3, #3
sub x20, x3, #0x1

This can eliminate two instruction.

[Bug target/94298] x86 duplicates loads

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Tue, 24 Mar 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94298
> 
> --- Comment #1 from Uroš Bizjak  ---
> The situation is a bit more complicated. IRA DTRT:
> 
> 8: r85:V2DF=[r86:DI+`y']
>   REG_EQUIV [r86:DI+`y']
>11: r89:V2DF=vec_select(vec_concat(r85:V2DF,r85:V2DF),parallel)
>12: r90:V2DF=vec_select(vec_concat(r85:V2DF,r85:V2DF),parallel)
>   REG_DEAD r85:V2DF
> 
> Later, LRA propagates memory operand into the insn. Since the insn clobbers 
> its
> input, multiple loads are emitted:
> 
>26: xmm1:V2DF=[ax:DI+`y']
>11: xmm1:V2DF=vec_select(vec_concat(xmm1:V2DF,[ax:DI+`y']),parallel)
>28: xmm0:V2DF=[ax:DI+`y']
>12: xmm0:V2DF=vec_select(vec_concat([ax:DI+`y'],xmm0:V2DF),parallel)
> 
> which is further "optimized" in postreload pass:
> 
>26: xmm1:V2DF=[ax:DI+`y']
>11: xmm1:V2DF=vec_select(vec_concat(xmm1:V2DF,xmm1:V2DF),parallel)
>28: xmm0:V2DF=[ax:DI+`y']
>12: xmm0:V2DF=vec_select(vec_concat(xmm0:V2DF,xmm0:V2DF),parallel)
> 
> It looks to me that a heuristics is missing in LRA, where memory operand
> shouldn't propagate into insn, if there are multiple uses of a register.

Yeah, but the odd thing is the memory doesn't actually end up in the
insn but is reloaded!  (I've filed a related PR recently where it actually
ends up in the insns but duplicated and thus code size grows but register
pressure decreases)

So I wonder whether the bug is that there is a memory alternative
in the first place?

[Bug target/94298] x86 duplicates loads

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #2)

> So I wonder whether the bug is that there is a memory alternative
> in the first place?

Memory alternative should be OK, we do have insns that access memory. Perhaps
vec_interleave_high/vec_interleave_low shouldn't be used by middel end in this
particular case?

[Bug tree-optimization/94300] [10 Regression] memcpy vector load miscompiled during const-prop since r10-6809-g7f5617b00445dcc8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

[Bug target/94298] x86 duplicates loads

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 24 Mar 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94298
> 
> --- Comment #3 from Uroš Bizjak  ---
> (In reply to rguent...@suse.de from comment #2)
> 
> > So I wonder whether the bug is that there is a memory alternative
> > in the first place?
> 
> Memory alternative should be OK, we do have insns that access memory. Perhaps
> vec_interleave_high/vec_interleave_low shouldn't be used by middel end in this
> particular case?

It's going through the generic vec_perm_const expander.

[Bug libgomp/81689] libgomp.c/target-link-1.c fails for nvptx: #pragma omp target link not implemented

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:c2211a60ff05b7a0289d3e287e72c181bb4d5d8b

commit r10-7354-gc2211a60ff05b7a0289d3e287e72c181bb4d5d8b
Author: Tobias Burnus 
Date:   Tue Mar 24 15:13:56 2020 +0100

Fix OpenMP offload handling for target-link variables for nvptx (PR81689)

PR libgomp/81689
* lto.c (offload_handle_link_vars): Propagate TREE_PUBLIC state.

PR libgomp/81689
* omp-offload.c (omp_finish_file): Fix target-link handling if
targetm_common.have_named_sections is false.

PR libgomp/81689
* testsuite/libgomp.c/target-link-1.c: Remove xfail.

[Bug debug/94283] [8/9 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
*** Bug 94284 has been marked as a duplicate of this bug. ***

[Bug debug/94284] [9/10 Regression] gcc: error: fort.f90: ‘-fcompare-debug’ failure (length) since r9-7156-g33579b59aaf02eb7

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jeffrey A. Law  ---
Jakub's patch for 94283 takes are of this one as well.  Hits the exact same
spot I looked at last night -- the code which put debug statements on the
worklist within ifcvt_local_dce.

*** This bug has been marked as a duplicate of bug 94283 ***

[Bug tree-optimization/94301] New: Missed vector-vector CTOR / permute simplification

[rguenth at gcc dot gnu.org]

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

Bug ID: 94301
   Summary: Missed vector-vector CTOR / permute simplification
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When the vectorizer creates sth stupid like

  _11 = __MEM  ((double *)vectp_y.3_4);
  vect__2.5_15 = _Literal (vector(2) double) {_11, _Literal (vector(1) double)
{ 0.0 }};
  vectp_y.3_16 = vectp_y.3_4 + 16ul;
  _17 = __MEM  ((double *)vectp_y.3_16);
  vect__2.6_18 = _Literal (vector(2) double) {_17, _Literal (vector(1) double)
{ 0.0 }};
  vect__2.7_19 = __VEC_PERM (vect__2.5_15, vect__2.6_18, _Literal (vector(2)
ssizetype) { 0l, 2l });
  _20 = __VEC_PERM (vect__2.7_19, vect__2.7_19, _Literal (vector(2) ssizetype)
{ 0l, 0l });
  _21 = __VEC_PERM (vect__2.7_19, vect__2.7_19, _Literal (vector(2) ssizetype)
{ 1l, 1l });

we fail to combine those instructions to

  _20 = { _11, _11 };
  _21 = { _17, _17 };

and instead end up with

  _11 = MEM[symbol: y, index: ivtmp.13_10, offset: _Literal (double *) 0];
  vect__2.5_15 = _Literal (vector(2) double) {_11, _Literal (vector(1) double)
{ 0.0 }};
  _17 = MEM[symbol: y, index: ivtmp.13_10, offset: _Literal (double *) 16];
  vect__2.7_19 = __BIT_INSERT (vect__2.5_15, _17, 64u);
  _20 = __VEC_PERM (vect__2.7_19, vect__2.7_19, _Literal (vector(2) ssizetype)
{ 0l, 0l });
  _21 = __VEC_PERM (vect__2.7_19, vect__2.7_19, _Literal (vector(2) ssizetype)
{ 1l, 1l });

where RTL expansion even ICEs on when trying to expand the __BIT_INSERT,
probably because of the V1DFmode insert which eventually ends up as
BLKmode to store_bit_field:

#4  0x00d27c83 in store_bit_field (str_rtx=0x76dab000, bitsize=...,
bitnum=..., 
bitregion_start=..., bitregion_end=..., fieldmode=E_BLKmode,
value=0x76da3888, 
reverse=false) at ../../src/trunk/gcc/expmed.c:1174


That said, the vector-vector CTORs are probably unhandled in forwprop
simplifications.

[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings

[ppalka at gcc dot gnu.org]

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

--- Comment #11 from Patrick Palka  ---
(In reply to Eric Gallager from comment #10)
> (In reply to Patrick Palka from comment #8)
> > Fixed on trunk by r10-7159.
> 
> so... keeping open for backports, I take it?

Probably yes.

[Bug tree-optimization/94300] [10 Regression] memcpy vector load miscompiled during const-prop since r10-6809-g7f5617b00445dcc8

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Tamar Christina
:

https://gcc.gnu.org/g:8fa2081ca6288853f3b8ceecd7d57ddf5dba5e7a

commit r9-8412-g8fa2081ca6288853f3b8ceecd7d57ddf5dba5e7a
Author: Tamar Christina 
Date:   Tue Mar 24 12:36:19 2020 +

AArch64: Break apart paradoxical subregs for VSTRUCT writes (PR
target/94052)

This works around an ICE in reload where from expand we get the following
RTL
generated for VSTRUCT mode writes:

(insn 446 354 445 2 (set (reg:CI 383)
 (subreg:CI (reg:V4SI 291) 0)) "small.i":146:22 3408 {*aarch64_movci}
 (nil))

This sequence is trying to say two things:

1) liveliness: It's trying to say that eventually the whole CI reg will be
   written to. It does this by generating the paradoxical
subreg.
2) write data: It's trying to in the same instruction also write the V4SI
mode
   component at offset 0 in the CI reg.

This patch fixes it by in the backend when we see such a paradoxical
construction breaking it apart and issuing a clobber to correct the
liveliness
information and then emitting a normal subreg write for the component that
the
paradoxical subreg was trying to write to.

Concretely we generate this:

(insn 42 41 43 (clobber (reg/v:CI 122 [ diD.5226 ])) "small.i":121:23 -1
 (nil))

(insn 43 42 44 (set (subreg:V4SI (reg/v:CI 122 [ diD.5226 ]) 0)
(reg:V4SI 136)) "small.i":121:23 -1
 (nil))

gcc/ChangeLog:

PR target/94052
* config/aarch64/aarch64-simd.md (mov): Remove paradoxical
subregs of VSTRUCT modes.

gcc/testsuite/ChangeLog:

PR target/94052
* g++.target/aarch64/pr94052.C: New test.

[Bug c++/94223] [10 Regression] -fcompare-debug -O0 failure on cpp1z/init-statement6.C

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Tamar Christina
:

https://gcc.gnu.org/g:0349bc70454e4de18d1cdf5eea0917646fdf79ae

commit r8-10139-g0349bc70454e4de18d1cdf5eea0917646fdf79ae
Author: Tamar Christina 
Date:   Tue Mar 24 15:00:44 2020 +

AArch64: Break apart paradoxical subregs for VSTRUCT writes (PR
target/94052)

This works around an ICE in reload where from expand we get the following
RTL
generated for VSTRUCT mode writes:

(insn 446 354 445 2 (set (reg:CI 383)
 (subreg:CI (reg:V4SI 291) 0)) "small.i":146:22 3408 {*aarch64_movci}
 (nil))

This sequence is trying to say two things:

1) liveliness: It's trying to say that eventually the whole CI reg will be
   written to. It does this by generating the paradoxical
subreg.
2) write data: It's trying to in the same instruction also write the V4SI
mode
   component at offset 0 in the CI reg.

This patch fixes it by in the backend when we see such a paradoxical
construction breaking it apart and issuing a clobber to correct the
liveliness
information and then emitting a normal subreg write for the component that
the
paradoxical subreg was trying to write to.

Concretely we generate this:

(insn 42 41 43 (clobber (reg/v:CI 122 [ diD.5226 ])) "small.i":121:23 -1
 (nil))

(insn 43 42 44 (set (subreg:V4SI (reg/v:CI 122 [ diD.5226 ]) 0)
(reg:V4SI 136)) "small.i":121:23 -1
 (nil))

gcc/ChangeLog:

PR target/94052
* config/aarch64/aarch64-simd.md (mov): Remove paradoxical
subregs of VSTRUCT modes.

gcc/testsuite/ChangeLog:

* g++.target/aarch64/aarch64.exp: New file.
* g++.target/aarch64/pr94052.C: New test.

[Bug target/89967] Inefficient code generation for vld2q_lane_u8 under aarch64

[tnfchris at gcc dot gnu.org]

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

Bug 94052 Summary: Paradoxical subregs out of expand causes ICE with multi 
register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052

   What|Removed |Added

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

[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #9 from Tamar Christina  ---
Issue fixed in GCC 10 and backported to GCC 8 and 9.

[Bug tree-optimization/94301] Missed vector-vector CTOR / permute simplification

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||missed-optimization

[Bug target/89057] [8/9/10 Regression] AArch64 ld3 st4 less optimized

[tnfchris at gcc dot gnu.org]

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

Bug 94052 Summary: Paradoxical subregs out of expand causes ICE with multi 
register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052

   What|Removed |Added

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

[Bug c++/94066] [8/9 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE
   |(starting/ending union  |(starting/ending union
   |member lifetime) in |member lifetime) in
   |cxx_eval_bare_aggregate, at |cxx_eval_bare_aggregate, at
   |cp/constexpr.c:3790 since   |cp/constexpr.c:3790 since
   |r6-7592 |r6-7592

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 10.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[ibuclaw at gdcproject dot org]

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

--- Comment #17 from Iain Buclaw  ---
I have no strong preferences, if people are wanting to go with the .S file,
then that's fine by me, feel free to commit (or I will if you'd prefer).

I'm just noting that I've seen a patch to implement musl support on s390x. 
Looks like there'll be nothing conflicting though.

https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01806.html

[Bug c++/94302] New: Implement DR 2310: Type completeness and derived-to-base pointer conversions

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94302
   Summary: Implement DR 2310: Type completeness and
derived-to-base pointer conversions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This issue was approved as a DR at Kona 2019:

  template struct check_derived_from { 
static A a; 
static constexpr B *p = &a; 
  }; 
  struct W {}; 
  struct X {}; 
  struct Y {}; 
  struct Z : W, 
X, check_derived_from,  // #1 
check_derived_from, Y { // #2 
check_derived_from cdf; // #3 
  }; 


All three attempted conversions in the example are ill-formed.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[ibuclaw at gdcproject dot org]

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

--- Comment #18 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #17)
> I have no strong preferences, if people are wanting to go with the .S file,
> then that's fine by me, feel free to commit (or I will if you'd prefer).
> 

It would be better to prefix the name with double underscores, as it is an
internal symbol to D runtime.

CSYM(__ibmz_get_tls_offset):

[Bug libgomp/81689] libgomp.c/target-link-1.c fails for nvptx: #pragma omp target link not implemented

[burnus at gcc dot gnu.org]

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

Bug 94251 Summary: [OpenMP] 'target link' fails at run time / 
libgomp.c/target-link-1.c fails on GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251

   What|Removed |Added

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

[Bug libgomp/94251] [OpenMP] 'target link' fails at run time / libgomp.c/target-link-1.c fails on GCN

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
Really close as FIXED

[Bug libgomp/81689] libgomp.c/target-link-1.c fails for nvptx: #pragma omp target link not implemented

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
FIXED.

[Bug c++/94303] New: Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)

[moonchasing1999 at gmail dot com]

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

Bug ID: 94303
   Summary: Program result error When using global object array
(partially initialized with a special constructor, and
the rest with the default constructor)
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moonchasing1999 at gmail dot com
  Target Milestone: ---

g++ version: 8.3.0 (and later)
system: Ubuntu 18.04
complete command line that triggers the bug: g++ -std=c++11 -o out main.cpp
compiler output: none
---

When I use g++8.3 and later version to compile and run the following code, the
results are not as expected. But if I use 8.2 and earlier version or other
compiler, like clang, wont't occure a fault result.

/* class define */
class A
{
private:
int d = 9;
public:
A()=default;
A(int a) : d(a) {}
void f() {cout << d << endl;}
};
/* class define end */

/* test code 1 */
A a[3] = {1}; //global
int main()
{
a[0].f();  //Output: 1
a[1].f();  //Output: 9
a[2].f();  //Output: 0  //error
return 0;
}
/* test code 1 end */

But if put A a[3] = {1} in main() function, it doesn't error.
/* test code 2 */

int main()
{
A a[3] = {1};
a[0].f();  //Output: 1
a[1].f();  //Output: 9
a[2].f();  //Output: 9  //right!
return 0;
}
/* test code 2 end */

And I find add number in initialization list, how many elements are initialized
then the last number of elements in the array is an incorrect result. For
example:

/* test code 3 */
A a[100]={1,1, 1};  // global

int main()
{
a[0].f();   //Output: 1
a[1].f();   //Output: 1
a[2].f();   //Output: 1
a[3].f();   //Output: 9
a[4].f();   //Output: 9
.   //Output: 9
a[96].f();  //Output: 9
a[97].f();  //Output: 0  //error
a[98].f();  //Output: 0  //error
a[99].f();  //Output: 0  //error
return 0;
}
/* test code 3 end */

/* full code of test code 1 */
class A
{
private:
int d = 9;
public:
A()=default;
A(int a) : d(a) {}
void f() {cout << d << endl;}
};

A a[3]={1};

int main()
{
a[0].f();
a[1].f();
a[2].f();
return 0;
}
/* full code end*/

[Bug c++/94288] co_await in while loop crashes g++

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #3 from Iain Sandoe  ---
thanks for the report.  The reduced testcase at c#2 doesn't fire for me once
pending updates are applied. However, the attached case preprocessed code does;
I think we will be able to make suitable test-cases, once the analysis is done.

[Bug d/94304] New: libphobos: Add --with-libdruntime-only configure option

[ibuclaw at gdcproject dot org]

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

Bug ID: 94304
   Summary: libphobos: Add --with-libdruntime-only configure
option
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Most targets are more likely to support only druntime, than both druntime and
phobos.

When bootstrapping the self-hosted D compiler front-end, we don't need to build
all of phobos either.

So machinery to expose both checking if druntime is supported and forcing only
druntime to be built would be beneficial.

[Bug d/94305] New: libphobos: Add configure flag to build phobos in non-release mode

[ibuclaw at gdcproject dot org]

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

Bug ID: 94305
   Summary: libphobos: Add configure flag to build phobos in
non-release mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Currently, libphobos is always built in non-release mode, which means all
asserts, contracts and invariants are compiled in.

For speed, `-frelease' should be the default, but allow this to be overridden
for testing purposes.  Maybe re-using --enable-checking?

[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:04099157691ec6ff25d8d32e30b04eec89dcf94b

commit r10-7355-g04099157691ec6ff25d8d32e30b04eec89dcf94b
Author: John David Anglin 
Date:   Tue Mar 24 17:04:26 2020 +

Define __BIG_ENDIAN__

2020-03-24  John David Anglin  

PR lto/94249
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Define __BIG_ENDIAN__.

[Bug c++/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2020-03-24
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|Program result error When   |[8/9/10 Regression] Program
   |using global object array   |result error When using
   |(partially initialized with |global object array
   |a special constructor, and  |(partially initialized with
   |the rest with the default   |a special constructor, and
   |constructor)|the rest with the default
   ||constructor)
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Untested fix:
--- gcc/varasm.c.jj 2020-01-22 10:19:24.0 +0100
+++ gcc/varasm.c2020-03-24 18:03:08.532690584 +0100
@@ -5152,6 +5152,26 @@ struct oc_local_state {
 static void
 output_constructor_array_range (oc_local_state *local)
 {
+  /* Perform the index calculation in modulo arithmetic but
+ sign-extend the result because Ada has negative DECL_FIELD_OFFSETs
+ but we are using an unsigned sizetype.  */
+  unsigned prec = TYPE_PRECISION (sizetype);
+  offset_int idx = wi::sext (wi::to_offset (TREE_OPERAND (local->index, 0))
+- wi::to_offset (local->min_index), prec);
+  tree valtype = TREE_TYPE (local->val);
+  HOST_WIDE_INT fieldpos
+= (idx * wi::to_offset (TYPE_SIZE_UNIT (valtype))).to_short_addr ();
+
+  /* Advance to offset of this element.  */
+  if (fieldpos > local->total_bytes)
+{
+  assemble_zeros (fieldpos - local->total_bytes);
+  local->total_bytes = fieldpos;
+}
+  else
+/* Must not go backwards.  */
+gcc_assert (fieldpos == local->total_bytes);
+
   unsigned HOST_WIDE_INT fieldsize
 = int_size_in_bytes (TREE_TYPE (local->type));

[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-9 branch has been updated by John David Anglin
:

https://gcc.gnu.org/g:366f69fdf42854f76b90ce81394e3685f2990988

commit r9-8413-g366f69fdf42854f76b90ce81394e3685f2990988
Author: John David Anglin 
Date:   Tue Mar 24 17:07:23 2020 +

Define __BIG_ENDIAN__

2020-03-24  John David Anglin  

PR lto/94249
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Define __BIG_ENDIAN__.

[Bug target/94297] PPCLE std::replace internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I can't reproduce this with latest trunk on ppc64le.  Can you please provide a
preprocessed source file for this ICE?

[Bug c++/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.0, 8.3.0, 9.2.0
  Known to work||8.2.0
   Keywords||wrong-code

--- Comment #2 from Jonathan Wakely  ---
Regressed with r267142

[Bug c++/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Jonathan has bisected this to my
r9-4877-gfaa9232da39587b27b46341667d6d415d2af9280 change (though, as the patch
shows, the bug is actually that varasm.c didn't handle RANGE_EXPRs properly
during output_constructor.

[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-8 branch has been updated by John David Anglin
:

https://gcc.gnu.org/g:dc65052d2351aeb1f1968b6ac9f1244de6ed64e1

commit r8-10140-gdc65052d2351aeb1f1968b6ac9f1244de6ed64e1
Author: John David Anglin 
Date:   Tue Mar 24 17:09:58 2020 +

Define __BIG_ENDIAN__

2020-03-24  John David Anglin  

PR lto/94249
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Define __BIG_ENDIAN__.

[Bug c++/94265] wrong warning "duplicated 'if' condition"

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Patrick Palka  ---
Taking a look.

[Bug libstdc++/66416] string::find_last_of 3.5 times slower than memrchr

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #2 from AK  ---
Could it be because string::find is more optimized than string::rfind?
see: https://gcc.gnu.org/legacy-ml/libstdc++/2017-01/msg00034.html

[Bug middle-end/94303] [8/9/10 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)

[jakub at gcc dot gnu.org]

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

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

Full untested patch.

[Bug c++/87910] Missing typename/template not diagnosed

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
This PR might get resolved by
.

[Bug c++/65969] typename allowed in using declaration of non-types names

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Another test:

struct A {
  void g();
};

namespace N {
  void f();
};

namespace M {
  using typename N::f;
}

struct X : A {
  using typename A::g;
};

[Bug libstdc++/66414] string::find ten times slower than strstr

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #8 from AK  ---
Should we consider this fixed?

[Bug libstdc++/93584] std::string::find_first_not_of is about 9X slower than strspn

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #3 from AK  ---
Could it be because string::find_first_not_of is not as optimized as
string::find?

https://github.com/gcc-mirror/gcc/commit/cb627cdf5c0761f9e1be587a1416db9446a4801b

[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #10 from Paul Thomas  ---
Created attachment 48108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48108&action=edit
Fix for problem with one regression

The attached fixes the problem but causes pr35849.f90 to regress in a rather
peculiar fashion:

pr35849.f90:5:55:

5 | INTEGER, PARAMETER, DIMENSION(10)  :: B = ISHFTC(j, A, -20) ! {
dg-error "must be positive" }
  |   1
Error: SIZE at (1) must be positive
pr35849.f90:6:57:

6 | INTEGER, PARAMETER, DIMENSION(10)  :: C = ISHFTC(1_1, A, j) ! {
dg-error "less than or equal to BIT_SIZE" }
  | 1
Error: ‘SIZE’ at (1) must be less than or equal to BIT_SIZE(‘I’)
pr35849.f90:7:51:

7 | INTEGER, PARAMETER, DIMENSION(10)  :: D = ISHFTC(3, A, 5) ! { dg-error
"Absolute value of SHIFT shall be less than or equal" }
  |   1
Error: Invalid character in name at (1)
pr35849.f90:8:51:

8 | INTEGER, PARAMETER, DIMENSION(10)  :: E = ISHFTC(3_1, A) ! { dg-error
"second argument of ISHFTC exceeds BIT_SIZE of first argument" }
  |   1
Error: Invalid character in name at (1)

The last two error come from match.c and must be left overs that have not been
cleared.

Cheers

Paul

[Bug tree-optimization/93946] Bogus redundant store removal

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #9 from sandra at gcc dot gnu.org ---
Both the new test cases are failing on nios2 at -Os, -O2, and -O3.  I've done
some analysis, but I'm not sure exactly where the problem lies, and whether
this is a problem in the nios2 back end or somewhere else.

long __attribute__((noipa))
foo (struct bb *bv, void *ptr)
{
  struct aa *a = ptr;
  struct bb *b = ptr;
  bv->b.u.f = 1;
  a->a.u.i = 0;
  b->b.u.f = 0;
  return bv->b.u.f;
}

is compiling to

foo:
movir2, 1
stw r2, 0(r4)
ldw r2, 0(r4)
stw zero, 0(r5)
stw zero, 4(r5)
ret

What's going on here is that load instructions have 3-cycle latency on nios2,
so the sched2 pass is moving the "ldw r2, 0(r4)" to load the return value 2
instructions earlier  ahead of the store instruction to the same location
via the aliased pointer.  :-(

I'm not an expert on the instruction scheduler, and it seems like the target
hooks and machine description syntax are all focused on modelling pipeline
costs in order to minimize stalls, not telling the scheduler that certain
instructions cannot be correctly reordered at all.  Should some other pass be
inserting optimization barriers, or something like that?  I feel like I'm
missing some big-picture expertise of where this needs to be fixed, so any
suggestions to point me in the right direction would be appreciated.

[Bug c++/94306] New: Improve diagnostic when "requires" used instead of "requires requires" and add fix-it

[redi at gcc dot gnu.org]

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

Bug ID: 94306
   Summary: Improve diagnostic when "requires" used instead of
"requires requires" and add fix-it
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct S { };
template requires { typename T::type; } struct S { };

This gives:

c.cc:2:31: error: expected primary-expression before '{' token
2 | template requires { typename T::type; } struct S { };
  |   ^
c.cc:2:31: error: expected unqualified-id before '{' token
c.cc:2:62: error: 'T' was not declared in this scope
2 | template requires { typename T::type; } struct S { };
  |  ^
c.cc:2:63: error: template argument 1 is invalid
2 | template requires { typename T::type; } struct S { };
  |   ^
c.cc:2:53: error: an explicit specialization must be preceded by 'template <>'
2 | template requires { typename T::type; } struct S { };
  | ^~~
  | template <> 


The first error is right. The second seems redundant with the first.

The rest of the errors seem bogus. T has been declared, the template argument
is valid, and the specialization is preceded by a template-head.

It would be good to suggest that it should say "requires requires {" and show a
fix-it hint.

[Bug c++/94252] Can't use a lambda in a requires expression

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
  Known to fail||10.0
   Last reconfirmed||2020-03-24
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Patrick Palka  ---
Confirmed.

[Bug sanitizer/94307] New: Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error

[kees at outflux dot net]

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

Bug ID: 94307
   Summary: Provide a way to declare the *SAN exception handler
-fsanitize-undefined-trap-on-error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Instead of unconditionally calling __builtin_trap() for
-fsanitize-undefined-trap-on-error it would help the Linux kernel's use of
UBSAN to have a way to specify the trap function. With that, Linux can use its
own internal exception handling routines and avoid various confused states:

https://lore.kernel.org/linux-next/20200324164433.qusyu5h7ykx3f2bu@treble/

For example something like -fsanitize-undefined-trap-function=__ubsan_trap and
"__ubsan_trap" can then be defined by the kernel itself. Using the standard
handler routines (__ubsan_handle_*) are too heavy duty for some builds, so a
regular trap is needed for the kernel, but this allows us to provide a
"continue anyway" option as well.

[Bug target/94308] New: [10 Regression] ICE in final_scan_insn_1 with vzeroupper

[jakub at gcc dot gnu.org]

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

Bug ID: 94308
   Summary: [10 Regression] ICE in final_scan_insn_1 with
vzeroupper
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

/* { dg-do compile } */
/* { dg-options "-O2 -mfpmath=sse -mavx2 -mfma" } */

#include 

void
foo (float *x, const float *y, const float *z, unsigned int w)
{
  unsigned int a;
  const unsigned int b = w / 8;
  const float *c = y;
  const float *d = z;
  __m256 e = _mm256_setzero_ps ();
  __m256 f, g;
  for (a = 0; a < b; a++)
{
  f = _mm256_loadu_ps (c);
  g = _mm256_loadu_ps (d);
  c += 8;
  d += 8;
  e = _mm256_fmadd_ps (f, g, e);
}
  __attribute__ ((aligned (32))) float h[8];
  _mm256_storeu_ps (h, e);
  _mm256_zeroupper ();
  float i = h[0] + h[1] + h[2] + h[3] + h[4] + h[5] + h[6] + h[7];
  for (a = b * 8; a < w; a++)
i += (*c++) * (*d++);
  *x = i;
}

ICEs on i686-linux or x86_64-linux with -m32.
The problem is that the vzeroupper pass in this case fills in sets for all
xmm0..xmm7 regs, but doesn't force rerecognition of the insn, so it is still
considered avx_vzeroupper_1, but the splitter doesn't trigger for it.

[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10 Regression] ICE in  |[10 Regression] ICE in
   |final_scan_insn_1 with  |final_scan_insn_1 with
   |vzeroupper  |vzeroupper since r10-6451
   Target Milestone|--- |10.0
   Last reconfirmed||2020-03-24
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Started with my r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 change.

[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c/94253] FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
r278376 was okay.  r278658 was bad.

[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #8 from Peter Bergner  ---
(In reply to Richard Biener from comment #7)
> Just default rules applied - the bug is new in GCC 10.  Since it's also a
> testsuite regression it woudl be nice to at least make that clean.  If
> we understand why the regression happens and can live with it we can demote
> it to P2.

So Segher's commit that caused this, added -fsplit-wide-types-early.  If you
use -fno-split-wide-types-early then we get the expected code.  It's strange
that both Segher's patch and my fix from PR87507 tries to break these TImode
uses up early and somehow, we're tripping over each other.  I will continue to
debug this and generate a fix.

That said, I think given there is a work around and that __int128 usage isn't
all that common, that we can probably reduce the priority of this to P2.

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
GCC is correct:

llvm::StringRef GetHelp() { return (m_help.empty() ? "" : m_help); }

has a std::string temp for "" because the conversion to std::string in the ?:.
And then StringRef::StringRef does:
 /// Construct a string ref from an std::string.
 /*implicit*/ StringRef(const std::string &Str)
   : Data(Str.data()), Length(Str.length()) {}


So GCC is correct.

[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address

[jan.kratochvil at redhat dot com]

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

--- Comment #7 from Jan Kratochvil  ---
OK, true, thanks, sorry.