[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

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

[Bug testsuite/93935] [9/10 regression] gcc.dg/vect/bb-slp-over-widen-2.c fails starting with r262371 (r10-6856)

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #5 from Kewen Lin  ---
Should be fixed on both trunk and gcc-9.

[Bug testsuite/93935] [9/10 regression] gcc.dg/vect/bb-slp-over-widen-2.c fails starting with r262371 (r10-6856)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:768779dd1165edf49e148bca425321093c7dc15b

commit r9-8415-g768779dd1165edf49e148bca425321093c7dc15b
Author: Kewen Lin 
Date:   Fri Mar 13 05:51:21 2020 -0500

[testsuite] Fix PR93935 to guard case under vect_hw_misalign

This patch is to apply the same fix as r267528 to another similar case
bb-slp-over-widen-2.c which requires misaligned vector access.

gcc/testsuite/ChangeLog

2020-03-25  Kewen Lin  

Backport from master
2020-03-13  Kewen Lin  

PR testsuite/93935
* gcc.dg/vect/bb-slp-over-widen-2.c: Expect basic block vectorized
messages only on vect_hw_misalign targets.

[Bug d/94315] New: [10 regression] new tests gdc.dg/pr93038.d and gdc.dg/pr93038b.d in r10-7320 fail

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94315
   Summary: [10 regression]  new tests gdc.dg/pr93038.d and
gdc.dg/pr93038b.d in r10-7320 fail
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g: 4a01f7b1e73e98a86520d8a825ddd3777faa7c33
r10-7320

These fail on all powerpc64 targets.

I don't know what these tests are really supposed to be doing so I am not sure
what is wrong.

FAIL: gdc.dg/pr93038.d   -O0   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O0 -frelease   scan-file pr93038.o: [^\n]*/pr93038.d
[ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O0 -frelease -g   scan-file pr93038.o:
[^\n]*/pr93038.d [ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O0 -g   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O1   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O1 -frelease   scan-file pr93038.o: [^\n]*/pr93038.d
[ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O1 -frelease -g   scan-file pr93038.o:
[^\n]*/pr93038.d [ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O1 -g   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O2   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O2 -frelease   scan-file pr93038.o: [^\n]*/pr93038.d
[ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O2 -frelease -g   scan-file pr93038.o:
[^\n]*/pr93038.d [ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O2 -g   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O3   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O3 -frelease   scan-file pr93038.o: [^\n]*/pr93038.d
[ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O3 -frelease -g   scan-file pr93038.o:
[^\n]*/pr93038.d [ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -O3 -g   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -Os   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -Os -frelease   scan-file pr93038.o: [^\n]*/pr93038.d
[ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -Os -frelease -g   scan-file pr93038.o:
[^\n]*/pr93038.d [ \n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038.d   -Os -g   scan-file pr93038.o: [^\n]*/pr93038.d [
\n]*[^\n]*/fileimports/pr93038.txt
FAIL: gdc.dg/pr93038b.d   -O0   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O0 -frelease   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O0 -frelease -g   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O0 -g   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O1   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O1 -frelease   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O1 -frelease -g   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O1 -g   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O2   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O2 -frelease   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O2 -frelease -g   scan-file pr93038b.o:
[^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O2 -g   scan-file pr93038b.o: [^\n]*/pr93038b.d [
\n]*[^\n]*/fileimports/pr93038.txt\n\n[^\n]*/fileimports/pr93038.txt:
FAIL: gdc.dg/pr93038b.d   -O3   scan-file pr93038b.o: [^\n]*/pr93038b.d [

[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger  ---
Okay, forget my previous comment,
I overlooked that you say the .c.gcov is missing...

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:75b7b7fdc4597170f24c069ea13aa3e14f37fde7

commit r10-7362-g75b7b7fdc4597170f24c069ea13aa3e14f37fde7
Author: Marek Polacek 
Date:   Mon Mar 16 10:17:11 2020 -0400

c++: Fix wrong no post-decrement operator error in template [PR94190]

Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it.  In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it.  So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR.  Before
the convert_like change it got *S::operator long int &() whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type.  But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.

Fixed by calling convert_from_reference on the result of convert_like.

PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (convert_like_real): Use convert_from_reference on the
result.

* g++.dg/conversion/op7.C: New test.

[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[sandra at gcc dot gnu.org]

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

--- Comment #18 from sandra at gcc dot gnu.org ---
I'm seeing the missing gcov file on nios2-linux-gnu as well.  Git revision
6e00d8dcf32ace6588a1a4843dfcc0e8b9f9d00f.

I took another look at the testcase.  I haven't used gcov for about a gazillion
years, but...

It says "{ dg-do compile }".  Don't you have to run the testcase to collect the
data to run with gcov?  And copy the .gcda file from the target to the host?

Then, it is trying to run "gcov gcov-pr94029.c" instead of e.g. "nios2-elf-gcov
gcov-pr94029.c", and it's picking up some random gcov program installed on the
host system instead of the one for the target.

Maybe this testcase should just be restricted to native targets?

[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Martin?

[Bug c++/94186] [10 Regression] compiler incorrectly accepts a requires clause with predicate of non-bool type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r10-7361-gfddfd3ce555965864b6116cf541f6355d2057d3d
Author: Jason Merrill 
Date:   Tue Mar 24 18:25:17 2020 -0400

c++: Improve handling of ill-formed constraints [PR94186].

It would have been trivial to make the error for non-bool constraint in
satisfy_atom unconditional, but that didn't give context for the error or
printing with the dependent form and template arguments.  So I changed a
couple of places so that, when a hard error is encountered during quiet
substitution/satisfaction, we go through again noisily; this builds up the
necessary context.

The similar change to tsubst_nested_requirement does not build up the
necessary context; rather than try to fix that now I changed
get_constraint_error_location to give up and use input_location if there's
no CONSTR_CONTEXT.  In the case of concepts-pr67697.C, we still have a good
source location because the NESTED_REQ has a correct EXPR_LOCATION, but
this
patch doesn't improve context printing for this case as it does for the
above.

gcc/cp/ChangeLog
2020-03-24  Jason Merrill  

PR c++/94186
* constraint.cc (constraint_satisfaction_value): Repeat noisily on
error.
(tsubst_nested_requirement): Likewise.
(get_constraint_error_location): Allow missing context.
(diagnose_atomic_constraint): Diagnose non-bool constraint here.
(satisfy_atom): Not here.  Only diagnose non-constant when noisy.

[Bug c++/94186] [10 Regression] compiler incorrectly accepts a requires clause with predicate of non-bool type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #3)
> Isn't this fixable by simply tweaking satisfy_atom to unconditionally issue
> the error?

Yes, but I thought we could do better. :)

[Bug c++/94314] New: [10 Regression] Optimizing mismatched new/delete pairs

[glisse at gcc dot gnu.org]

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

Bug ID: 94314
   Summary: [10 Regression] Optimizing mismatched new/delete pairs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

(originally posted at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00276.html , I don't know
if we will do something about it, but it seems worth documenting it in
bugzilla)

Now that we optimize class-specific operator new/delete pairs (but you could do
the same with the global replacable ones as well):

#include 
int count = 0;
struct A {
  __attribute__((malloc,noinline))
  static void* operator new(unsigned long sz){++count;return ::operator
new(sz);}
  static void operator delete(void* ptr){--count;::operator delete(ptr);}
};
int main(){
  delete new A;
  printf("%d\n",count); // Should print 0.
}

If we do not inline anything, we can remove the pair and nothing touches count.
If we inline both new and delete, we can then remove the inner pair instead,
count increases and decreases, fine. If we inline only one of them, and DCE the
mismatched pair new/delete, we get something inconsistent (count is -1).

This seems to indicate we should check that the new and delete match somehow...

[Bug middle-end/90404] No warning on attempts to modify a const object

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94313

--- Comment #6 from Martin Sebor  ---
See also pr94313 which shows how reliably diagnosing some of these invalid
stores is made challenging by optimizations that remove them.

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

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #6 from Richard Smith  ---
(In reply to Marc Glisse from comment #5)
> Ah, since you are here, and you appeared as an author of N3664 but not N3537
> (precisely when this subtlety happened), could you explain why? It isn't
> discussed in the paper, complicates the design, and I cannot think of any
> use for this distinction

It isn't discussed in the paper because it wasn't part of the original plan /
design, but was added due to committee push-back. People want some guarantees:

 * If they write a test for their global 'operator new' (particularly, testing
failure cases, mallinfo, the effect of configuration parameters on its
behavior, ...), that test should still work in the presence of the language
change.

 * A direct function call to a user-defined function should behave as a direct
function call to that user-defined function. Even if it has a non-identifier
name.

In the end, the language and user model we found to be most satisfying, given
the above, is: new-expressions, like std::allocator, may obtain storage by
calling 'operator new', but it's unspecified how often it's called and with
what arguments. And the language rules are an approximation of that idea.


(In reply to Marc Glisse from comment #5)
> This of course doesn't at all prevent from adding a __builtin_operator_new
> option in std::allocator, it only affects how motivated we should be to fix
> the non-conformance.

Well, in case it helps your analysis, LLVM once did what GCC does now (before
there were standard rules in place), and in practice we saw it break some stuff
(largely, tests for allocators, but also weird things like using 'operator
new((size_t)-1)' as a way to throw bad_alloc from code that can't '#include
').

[Bug middle-end/94313] New: stores into string literals sometimes silently eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 94313
   Summary: stores into string literals sometimes silently
eliminated
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Modifying a const-qualified object or a string literal is undefined in both C
and C++ and can result in subtle bugs.  Detecting attempts to do so as
requested in pr90404 will help prevent such hard-to-find bugs.  However,
reliable detection is made difficult by optimizations that silently eliminate
stores to such objects.  The test case below shows that the second of the four
invalid stores below (in g1) is silently eliminated (by DSE) while the others
are retained.  (None of them is diagnosed.)  The first two will likely crash if
the strings are stored in ROM.  The second two could lead in unexpected results
as a result of other optimizations (such as the strlen pass) that assume that
const objects cannot change.

The last revision I have access to that did not eliminate the store is r145753.
 The first revision that does is r145825, so the change was introduced sometime
in between these two.

$ cat z.c && gcc -O2 -S -Wall -Wwrite-strings -fdump-tree-optimized=/dev/stdout
z.c
void f (void*);

static char* str (void) { return (char*)"abc"; }

void g0 (int x)
{
  char *s = __builtin_strchr (str (), 'a');
  *s = 'x';   // not eliminated (okay)
  f (s);
}

void g1 (int x)
{
  char *s = __builtin_strchr (str (), x);
  *s = 'x';   // eliminated
  f (s);
}

const char a[] = "bcd";

void g2 (void)
{
  char *s = __builtin_strchr (a, 'b');
  *s = 'x';   // not eliminated (okay)
  f (s);
}

void g3 (int x)
{
  const char a[] = "cde";
  char *s = __builtin_strchr (a, 'c');
  *s = 'x';   // not eliminated (okay)
  f (s);
}


;; Function g0 (g0, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=1)

g0 (int x)
{
   [local count: 1073741824]:
  MEM[(char *)"abc"] = 120;
  f ("abc"); [tail call]
  return;

}



;; Function g1 (g1, funcdef_no=2, decl_uid=1939, cgraph_uid=3, symbol_order=2)

g1 (int x)
{
  char * s;

   [local count: 1073741824]:
  s_3 = __builtin_strchr ("abc", x_2(D));
  f (s_3); [tail call]
  return;

}



;; Function g2 (g2, funcdef_no=3, decl_uid=1944, cgraph_uid=4, symbol_order=4)

g2 ()
{
   [local count: 1073741824]:
  MEM[(char *)] = 120;
  f (); [tail call]
  return;

}



;; Function g3 (g3, funcdef_no=4, decl_uid=1948, cgraph_uid=5, symbol_order=5)

g3 (int x)
{
  char * s;
  const char a[4];

   [local count: 1073741824]:
  a = "cde";
  s_3 = __builtin_strchr (, 99);
  *s_3 = 120;
  f (s_3);
  a ={v} {CLOBBER};
  return;

}

[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 #5 from Marc Glisse  ---
(In reply to Richard Smith from comment #2)
> (In reply to Marc Glisse from comment #1)
> > (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?
> 
> No, it's intentional: if the user directly calls '::operator new(42)' and
> they've replaced that function, the replacement function is guaranteed to be
> called. In this regard, 'operator new' is just a regular function with a
> funny name.
> 
> To be clear, the implicit call to 'operator new' produced by, say, 'new int'
> *is* optimizable, but a direct explicit call to 'operator new(sizeof(int))'
> is not.

Ah, since you are here, and you appeared as an author of N3664 but not N3537
(precisely when this subtlety happened), could you explain why? It isn't
discussed in the paper, complicates the design, and I cannot think of any use
for this distinction (there are workarounds if people don't want their explicit
call elided).

This of course doesn't at all prevent from adding a __builtin_operator_new
option in std::allocator, it only affects how motivated we should be to fix the
non-conformance.

[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

--- Comment #5 from Iain Sandoe  ---
(In reply to Martin Liška from comment #4)
> (In reply to Iain Sandoe from comment #3)
> > 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.
> 
> If you point me to the pending patches, I can make reduction based on that?

(the reduction is not urgent, I've an idea about the problem, hopefully have a
few cycles on it tomorrow)

unreviewed:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542407.html
review-in-progress:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542411.html

(but thanks for the offer!)

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

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Iain Sandoe from comment #3)
> 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.

If you point me to the pending patches, I can make reduction based on that?

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

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #4 from Richard Smith  ---
(In reply to Andrew Pinski from comment #3)
> PR 23383 is where part of the discussion was done.
> 
> In fact GCC implements the optimization without the builtin:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-07/msg00136.html

Yep, looks like GCC miscompiles direct calls to operator new / operator delete
since that patch landed: https://godbolt.org/z/dK99Rz

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Smith from comment #2)
> (In reply to Marc Glisse from comment #1)
> > (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?
> 
> No, it's intentional: if the user directly calls '::operator new(42)' and
> they've replaced that function, the replacement function is guaranteed to be
> called. In this regard, 'operator new' is just a regular function with a
> funny name.
> 
> To be clear, the implicit call to 'operator new' produced by, say, 'new int'
> *is* optimizable, but a direct explicit call to 'operator new(sizeof(int))'
> is not.
> 
> > Gcc does optimize those, like it does malloc/free...
> 
> That sounds like non-conforming behavior.


PR 23383 is where part of the discussion was done.

In fact GCC implements the optimization without the builtin:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-07/msg00136.html

[Bug middle-end/94312] missing -Wreturn-local-addr on returning local address via memchr or memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|missing -Wreturn-local-addr |missing -Wreturn-local-addr
   |on returning local address  |on returning local address
   |via memchr  |via memchr or memset

--- Comment #1 from Martin Sebor  ---
Ditto for memset and strpbrk.  The warning should be reviewed for coverage. 
Rather than handling just built-ins a more general and more broadly usable
solution is to add a new function attribute to specify that a function returns
either the same value as one of its arguments (unchanged, such as memset), or a
pointer into the same array as one of its arguments (such as memchr).

[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

--- Comment #5 from Jens Seifert  ---
No options. Same failure with -O2. System is a RHEL 7.5.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/ppc64le-redhat-linux/8/lto-wrapper
Target: ppc64le-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr
--mandir=/opt/rh/devtoolset-8/root/usr/share/man
--infodir=/opt/rh/devtoolset-8/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-ppc64le-redhat-linux/isl-install
--disable-libmpx --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-cpu-32=power8 --with-tune-32=power8
--with-cpu-64=power8 --with-tune-64=power8 --build=ppc64le-redhat-linux
Thread model: posix
gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)


No error with:
gcc -std=gnu++98 replace.C
gcc -std=gnu++03 replace.C

Error with:
gcc -std=gnu++11 replace.C
gcc -std=gnu++17 replace.C

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

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #2 from Richard Smith  ---
(In reply to Marc Glisse from comment #1)
> (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?

No, it's intentional: if the user directly calls '::operator new(42)' and
they've replaced that function, the replacement function is guaranteed to be
called. In this regard, 'operator new' is just a regular function with a funny
name.

To be clear, the implicit call to 'operator new' produced by, say, 'new int'
*is* optimizable, but a direct explicit call to 'operator new(sizeof(int))' is
not.

> Gcc does optimize those, like it does malloc/free...

That sounds like non-conforming behavior.

> > This bug requests that libstdc++ uses these builtins when available.
> 
> So just in std::allocator, or are there other places?

std::allocator's specification has an explicit provision to permit these
optimizations, see [allocator.members]/4:

"The storage for the array is obtained by calling ::operator new (17.6.2), but
it is unspecified when or how often this function is called."

In Clang + libc++ at least, we interpret that as meaning we can call
'::operator new' zero times if we don't need the storage, just like for a
new-expression, and the LWG members I've talked to about this have agreed that
that's in line with the intent.

[Bug middle-end/94312] New: missing -Wreturn-local-addr on returning local address via memchr

[msebor at gcc dot gnu.org]

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

Bug ID: 94312
   Summary: missing -Wreturn-local-addr on returning local address
via memchr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Wreturn-local-addr diagnoses only the first function below.  It misses the
same problem in the second function.  The root cause is a missing label for
BUILT_IN_MEMCHR in is_addr_local in gimple-ssa-isolate-paths.c (it was
accidentally omitted in r273261).

$ cat x.c && gcc -O2 -S -Wall x.c
void* f (char x)
{ 
  char a[] = { x, x + 1 };
  return __builtin_strchr (a, 0);   // -Wreturn-local-addr (okay)
}

void* g (char x)
{
  char a[] = { x, x + 1 };
  return __builtin_memchr (a, 0, sizeof a);   // missing -Wreturn-local-addr
}
x.c: In function ‘f’:
x.c:4:10: warning: function returns address of local variable
[-Wreturn-local-addr]
4 |   return __builtin_strchr (a, 0);   // -Wreturn-local-addr (okay)
  |  ^~~
x.c:3:8: note: declared here
3 |   char a[] = { x, x + 1 };
  |^

[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

--- Comment #4 from Marek Polacek  ---
Still can't reproduce with mainline trunk/9/8.

Since I happen to work on DTS, I've also tried
devtoolset-8-gcc-8.2.1-3.el7.ppc64le and devtoolset-8-gcc-8.3.1-3.2.el7.ppc64le
but couldn't reproduce it either.  Did you use any special options not
mentioned in this bug report?

[Bug lto/94311] New: LTO produces line info entries with invalid line numbers

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94311
   Summary: LTO produces line info entries with invalid line
numbers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Unfortunately this doesn't have a simple reproducer, but can be seen when
compiling valgrind:

$ wget https://sourceware.org/pub/valgrind/valgrind-3.15.0.tar.bz2
$ tar -xf valgrind-3.15.0.tar.bz2
$ cd valgrind-3.15
$ ./autogen.sh
$ ./configure --prefix=`pwd`/install --enable-only64bit --enable-lto
$ make install

then

$ ./install/bin/valgrind -q date

produces warnings like

   ==14497== warning: Can't handle line info entry with line number 177277754
greater than 1048575
   ==14497== (Nb: this message is only shown once)
   ==14497== warning: Can't handle inlined call info entry with line number
177277750 greater than 1048575 
   ==14497== (Nb: this message is only shown once)
Tue 24 Mar 2020 03:54:34 PM EDT

while with GCC 8 these warnings weren't issued.

[Bug c++/94310] New: using constructor inheritance breaks the code

[tilin97 at yandex dot ru]

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

Bug ID: 94310
   Summary: using constructor inheritance breaks the code
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tilin97 at yandex dot ru
  Target Milestone: ---

The following code is compiled without errors

template
struct B {
};

template
struct A : public B... {
using B::operator=...;
using B::B...;
};

int main() {}

But when you change the order of using declarations compilation fails (the same
error occurs in all versions of gcc on godbolt.org)

template
struct B {
};

template
struct A : public B... {
using B::B...;<---
using B::operator=...;<---
};

int main() {}

gcc -v -std=c++17 -Wall -Wextra main.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.2.1-17ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191102 (Ubuntu 9.2.1-17ubuntu1~18.04.1) 
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-Wall' '-Wextra' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/9/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=generic -march=x86-64
-auxbase main -Wall -Wextra -std=c++17 -version -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat-security -o /tmp/ccVHNdqy.s
GNU C++17 (Ubuntu 9.2.1-17ubuntu1~18.04.1) version 9.2.1 20191102
(x86_64-linux-gnu)
compiled by GNU C version 9.2.1 20191102, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/9"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/9
 /usr/include/x86_64-linux-gnu/c++/9
 /usr/include/c++/9/backward
 /usr/lib/gcc/x86_64-linux-gnu/9/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++17 (Ubuntu 9.2.1-17ubuntu1~18.04.1) version 9.2.1 20191102
(x86_64-linux-gnu)
compiled by GNU C version 9.2.1 20191102, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 33caeb1da5df6f896d4e495951c13eae
main.cpp:8:11: error: expected nested-name-specifier before ‘B’
8 | using B::operator=...;
  |   ^


-

The following code is also compiled with an error if there is no comment

template
struct B {
void foo() {}
};

template
struct A : public B... {
// using B::B...;  <---

void bar() {
(B::foo() , ...);
}
};

int main() {}

gcc -std=c++17 -Wall -Wextra b.cpp
b.cpp: In member function ‘void A::bar()’:
b.cpp:11:11: error: expected primary-expression before ‘>’ token
   11 |   (B::foo() , ...);
  |   ^
b.cpp:11:14: error: ‘::foo’ has not been declared
   11 |   (B::foo() , ...);
  |  ^~~
b.cpp:11:11: error: binary expression in operand of fold-expression
   11 |   (B::foo() , ...);
  |~~~^~~~
b.cpp:11:11: error: operand of fold expression has no unexpanded parameter
packs

[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

--- Comment #3 from Jens Seifert  ---
Created attachment 48110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48110=edit
Pre-processed file created using -save-temps

[Bug c++/94309] Fail to find post-increment operator in templated function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Dup.  I've posted a patch.

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

[Bug c++/94190] [10 Regression] error: no post-decrement operator for type since r10-7096-gd417b4f5414d9076

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #2 from Marek Polacek  ---
*** Bug 94309 has been marked as a duplicate of this bug. ***

[Bug c++/94309] New: Fail to find post-increment operator in templated function

[romain.geissler at amadeus dot com]

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

Bug ID: 94309
   Summary: Fail to find post-increment operator in templated
function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

This snippet started to fail recently with gcc trunk. Note, it was working fine
with "g++ (GCC) 10.0.1 20200305", and it works fine with gcc <= 9, and all
clang versions


struct A
{
int _i;

operator int&()
{
return _i;
}
};

void f()
{ 
A a;
a++; // works
}

template  void f()
{
A a;
a++; // fails
}


The error is:

#2 with x86-64 gcc (trunk)
: In function 'void f()':
:20:6: error: no post-increment operator for type
   20 | a++; // fails
  |  ^~
Compiler returned: 1


Cheers,
Romain

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

[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 )
   : Data(Str.data()), Length(Str.length()) {}


So GCC is correct.

[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 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/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=edit
gcc10-pr94308.patch

Untested fix.

[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] 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 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 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 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 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 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=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 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 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 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 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 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=edit
gcc10-pr94303.patch

Full untested patch.

[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 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 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++/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 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 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 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 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 #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 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 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 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 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 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 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
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 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 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 =  
  }; 
  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 #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++/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 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 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/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

[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 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=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 #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 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=edit
gcc10-pr94300.patch

Untested fix.

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

[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 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 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 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/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 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 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 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, , 64);
  __builtin_memcpy(mem + 8, , 64);
  V c = {}; 
  __builtin_memcpy(, 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 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=edit
gcc10-pr94292.patch

Untested fix.

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

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

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