[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
The #c9 patch passed bootstrap, but regresses:
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

The thing is that those tests do those use after scope accesses but don't
really have anything afterwards that would allow optimizing those accesses
away.  With the previous behavior of ASAN_MARK ifns such barriers were in those
ifns.
So, the big question is, what do we want.
For -O0 -fsanitize=address both the unpatched and patched versions work
similarly, and for -O1 -fsanitize=address and higher,
do we want the sanitizer to detect just those after scope uses that would
remain after optimization even in non-instrumented code?  Then we want the
patch.  Or do we want to detect more after scope uses, even at the expense of
some false positive warnings?
If I try clang++ -O{0,1} -fsanitize=address on the use-after-scope-types-1.C
testcase, then it detects the violation (patched g++ with already -O1
-fsanitize=address doesn't), but clang++ -O{2,3} -fsanitize=address doesn't
detect it (while unpatched g++ -O{2,3} -fsanitize=address does).

[Bug c++/91759] [8/9/10 Regression] g++ accepts ill-formed deduction guides in wrong scope since r7-6608-ga56c0ac08242269b

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7236-gaf8656be8df68ac26840f7844430fd595255ebd2
Author: Jakub Jelinek 
Date:   Wed Mar 18 08:53:23 2020 +0100

c++: Diagnose a deduction guide in a wrong scope [PR91759]

The following testcase is accepts-invalid since r7-6608-ga56c0ac08242269b.
Before that change we had this
"deduction guide %qD must be declared in the same scope as %qT"
diagnostics for it, after the change it is expected to be diagnosed
in set_decl_namespace at the not_found: label in there.  On this testcase
nothing is diagnosed though, because set_decl_namespace isn't called at
all,
as in_namespace is NULL.

The following patch restores the old warning but does it only in case we
don't call set_decl_namespace.

2020-03-18  Jakub Jelinek  

PR c++/91759
* decl.c (grokfndecl): Restore old diagnostics about deduction
guide declared in different scope if in_namespace is NULL_TREE.

* g++.dg/cpp1z/class-deduction72.C: New test.

[Bug c++/91759] [8/9 Regression] g++ accepts ill-formed deduction guides in wrong scope since r7-6608

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] g++ |[8/9 Regression] g++
   |accepts ill-formed  |accepts ill-formed
   |deduction guides in wrong   |deduction guides in wrong
   |scope since |scope since r7-6608
   |r7-6608-ga56c0ac08242269b   |

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

[Bug c/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403

[jakub at gcc dot gnu.org]

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

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

[Bug middle-end/94206] Wrong optimization: memset of n-bit integer types (from bit-fields) is truncated to n bits (instead of sizeof)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-18
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||4.8.5

--- Comment #2 from Richard Biener  ---
Broken since long via memset folding:

  __MEM  ((void *)&x) = _Literal (uint33) 8589934591;

[Bug c/94188] [10 Regression] error: request for member ‘node’ in something not a structure or union since r10-7127-gcb99630f254aaec6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:4e3d3e40726e1b68bf52fa205c68495124ea60b8

commit r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8
Author: Richard Biener 
Date:   Wed Mar 18 09:13:17 2020 +0100

middle-end/94188 fix fold of addr expression generation

This adds a missing type conversion to build_fold_addr_expr and adjusts
fallout - build_fold_addr_expr was used as a convenience to build an
ADDR_EXPR but some callers do not expect the result to be simplified
to something else.

2020-03-18  Richard Biener  

PR middle-end/94188
* fold-const.c (build_fold_addr_expr): Convert address to
correct type.
* asan.c (maybe_create_ssa_name): Strip useless type conversions.
* gimple-fold.c (gimple_fold_stmt_to_constant_1): Use build1
to build the ADDR_EXPR which we don't really want to simplify.
* tree-ssa-dom.c (record_equivalences_from_stmt): Likewise.
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Likewise.
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise.
(simplify_builtin_call): Strip useless type conversions.
* tree-ssa-strlen.c (new_strinfo): Likewise.

* gcc.dg/pr94188.c: New testcase.

[Bug c/94188] [10 Regression] error: request for member ‘node’ in something not a structure or union since r10-7127-gcb99630f254aaec6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

Re: March Order

[May Lee via Gcc-bugs]

Good Morning

We have attach our March order to this mail, confirm this order 
by return mail and issue send Invoice Asap.


Thanks & Best Regards


May Lee 
Know How International GmbH & Co. KG  
Import 

[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Regarding the original testcase, small tweak results in the same warning even
without sanitization:
#include "pr91146.h"

class A
{
public:
  virtual void f () = 0;
};

template 
void foo (T &);

class B : public A
{
public:
  void f () override
  {
small_vector v;
auto i = v.begin ();
foo (i);
v.insert (i, 1); 
foo (v);
  }
};

int main ()
{
  B b;
  b.f ();
  return 0;
}

Here we just make sure the method isn't optimized away completely and that the
optimizer doesn't know v.insert is called with v.begin () iterator.
And the problem is that the llvm small vector implementation does:
iterator insert(iterator I, T &&Elt) {
...
T *EltPtr = &Elt;
if (I <= EltPtr && EltPtr < this->EndX)
  ++EltPtr;

*I = ::std::move(*EltPtr);
return I;
  }

*++EltPtr on an int (not array) is obviously UB, but the condition should guard
that this doesn't happen.  Except that there is UB already in the condition
that guards this, because non-equality pointer comparisons are valid only if
both pointers point into the same object or one past the end of it, or both are
NULL.
That isn't the case here, as I points into the payload of the v variable and so
does this->endX, while EltPtr points to a temporary holding 1.
So, I'd say this is LLVM bug.

[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Though, admittedly fixing that:
 T *EltPtr = &Elt;
-if (I <= EltPtr && EltPtr < this->EndX)
+if ((std::uintptr_t) I <= (std::uintptr_t) EltPtr && (std::uintptr_t)
EltPtr < (std::uintptr_t) this->EndX)
   ++EltPtr;

 *I = ::std::move(*EltPtr);
doesn't make the warning go away.
We have:
  int D.48534;
...
   [local count: 885408257]:
  # EltPtr_49 = PHI <&D.48534(27), &D.48534(28), &MEM  [(void *)&D.48534 +
4B](29)>
  _50 = MEM[(type &)EltPtr_49];
  *I_42 = _50;
before phiprop and phiprop changes that into:
   [local count: 442704129]:
  _33 = MEM[(type &)&D.48534];
  goto ; [100.00%]
...
   [local count: 221352064]:
  _34 = MEM[(type &)&D.48534];
  goto ; [100.00%]

   [local count: 221352064]:
  _48 = MEM[(type &)&D.48534 + 4];

   [local count: 885408257]:
  # EltPtr_49 = PHI <&MEM  [(void *)&D.48534 + 4B](29), &D.48534(38),
&D.48534(39)>
  # _50 = PHI <_48(29), _33(38), _34(39)>
  *I_42 = _50;
where the _48 load is clearly UB, but with -fsanitize=address the compiler
can't prove that it is unreachable, or with the adjusted testcase either.
So we are back to the dozens of other PRs of this kind, late warnings warning
on UB in dead code and the question what the users actually want, whether a
(false positive) warning, or no warning, or whether the compiler should replace
the UB code with __builtin_unreachable and let the code be further simplified,
or replace it with __builtin_trap.

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

[amker at gcc dot gnu.org]

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

--- Comment #11 from bin cheng  ---
(In reply to Richard Biener from comment #10)
> Thanks Bin, fixed on trunk sofar.

Hmm, if it's fine, I will backport this to GCC9.

Thanks

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

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 18 Mar 2020, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
> 
> --- Comment #11 from bin cheng  ---
> (In reply to Richard Biener from comment #10)
> > Thanks Bin, fixed on trunk sofar.
> 
> Hmm, if it's fine, I will backport this to GCC9.

I think so.

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
(In reply to Martin Liška from comment #14)
> There's another issue for ppc64le:
> 
> $ ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c
> Error: global_options are modified in local context:
>   unroll_only_small_loops (0/1)
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/attributes-3.c:9:1:
> internal compiler error: in handle_optimize_attribute, at
> c-family/c-attribs.c:4464
> 9 | extern void __attribute__((optimize ("O2"))) fn0 (void); /* {
> dg-warning "optimization attribute" } */
>   | ^~
> 0xa98687 handle_optimize_attribute
>   /home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4464
> 0x8e6dba decl_attributes(tree_node**, tree_node*, int, tree_node*)
>   /home/marxin/Programming/gcc/gcc/attribs.c:713
> 0x8fc617 c_decl_attributes
>   /home/marxin/Programming/gcc/gcc/c/c-decl.c:4977
> 0x8fcb61 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
>   /home/marxin/Programming/gcc/gcc/c/c-decl.c:5116
> 0x96c7d4 c_parser_declaration_or_fndef
>   /home/marxin/Programming/gcc/gcc/c/c-parser.c:2272
> 0x96b434 c_parser_external_declaration
>   /home/marxin/Programming/gcc/gcc/c/c-parser.c:1746
> 0x96af96 c_parser_translation_unit
>   /home/marxin/Programming/gcc/gcc/c/c-parser.c:1619
> 0x9a8e51 c_parse_file()
>   /home/marxin/Programming/gcc/gcc/c/c-parser.c:21710
> 0xa262f8 c_common_parse_file()
>   /home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1186
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

I've got a patch candidate for this particular issue. It can be fixed in a
reasonable way.

[Bug c++/94210] New: ICE in tsubst, at cp/pt.c:15105

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 94210
   Summary: ICE in tsubst, at cp/pt.c:15105
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, gcc crashes given the following example, while clang compiles normally.
$ cat 1.cpp
template struct X {};

namespace Nested {
  template int f1(X... a);

  int a1 = f1(X(), X());
}

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-20200315/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-20200315/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10-20200315/configure --prefix=/usr/local/gcc-20200315
--enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200315 (experimental) (GCC) 

$　g++ -c -std=c++11 1.cpp

1.cpp: In substitution of ‘template int Nested::f1(X...)
[with T = ]’:
1.cpp:6:62:   required from here
1.cpp:6:62: internal compiler error: in tsubst, at cp/pt.c:15105
6 |   int a1 = f1(X(), X());
  |  ^
0x5f0f06 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-10-20200315/gcc/cp/pt.c:15105
0x75dd9a unify_pack_expansion
../../gcc-10-20200315/gcc/cp/pt.c:22534
0x74aff5 unify
../../gcc-10-20200315/gcc/cp/pt.c:23307
0x74a20a unify
../../gcc-10-20200315/gcc/cp/pt.c:23204
0x74ae8b unify
../../gcc-10-20200315/gcc/cp/pt.c:23301
0x75e5da try_class_unification
../../gcc-10-20200315/gcc/cp/pt.c:22298
0x74a744 unify
../../gcc-10-20200315/gcc/cp/pt.c:23338
0x75d248 unify_one_argument
../../gcc-10-20200315/gcc/cp/pt.c:21531
0x75db29 unify_pack_expansion
../../gcc-10-20200315/gcc/cp/pt.c:22546
0x749b80 type_unification_real
../../gcc-10-20200315/gcc/cp/pt.c:21670
0x769684 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc-10-20200315/gcc/cp/pt.c:21030
0x640da5 add_template_candidate_real
../../gcc-10-20200315/gcc/cp/call.c:3396
0x6414f4 add_template_candidate
../../gcc-10-20200315/gcc/cp/call.c:3481
0x6414f4 add_candidates
../../gcc-10-20200315/gcc/cp/call.c:5834
0x6418f7 add_candidates
../../gcc-10-20200315/gcc/cp/call.c:4482
0x6418f7 perform_overload_resolution
../../gcc-10-20200315/gcc/cp/call.c:4490
0x644525 build_new_function_call(tree_node*, vec**, int)
../../gcc-10-20200315/gcc/cp/call.c:4564
0x77bd5c finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-10-20200315/gcc/cp/semantics.c:2671
0x71f998 cp_parser_postfix_expression
../../gcc-10-20200315/gcc/cp/parser.c:7427
0x7041ba cp_parser_binary_expression
../../gcc-10-20200315/gcc/cp/parser.c:9519
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/94211] New: [9/10 Regression] -fcompare-debug failure on phi-opt-13.c

[zhroma at gcc dot gnu.org]

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

Bug ID: 94211
   Summary: [9/10 Regression] -fcompare-debug failure on
phi-opt-13.c
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at gcc dot gnu.org
  Target Milestone: ---

This command:
gcc -c -O2 -fcompare-debug gcc/testsuite/gcc.dg/tree-ssa/phi-opt-13.c

fails on todays master (r10-7237) on ppc64le, fails on 9.3 on x86_64, but not
in 7.4.  Haven't checked version 8.x.

long f(long a, long b) {
  if (__builtin_expect(b == 1, 1)) return a;
  return a / b;
}

Tree .phiopt2 is the first dump which seems buggy.

[Bug c/94201] aarch64：ICE in tiny code model for ilp32

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r10-7240-gd91480dee934478063fe5945b73ff3c108e40a91
Author: Duan bo 
Date:   Wed Mar 18 10:18:39 2020 +

aarch64: Fix SYMBOL_TINY_GOT handling for ILP32 [PR94201]

The SYMBOL_TINY_GOT case in aarch64_load_symref_appropriately was
missing support for ILP32.  This caused an ICE on the testcase.

2020-03-18  Duan bo  

gcc/
PR target/94201
* config/aarch64/aarch64.md (ldr_got_tiny): Delete.
(@ldr_got_tiny_): New pattern.
(ldr_got_tiny_sidi): Likewise.
* config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Use
them to handle SYMBOL_TINY_GOT for ILP32.

gcc/testsuite/
PR target/94201
* gcc.target/aarch64/pr94201.cï¼New test.

[Bug tree-optimization/91246] vectorization failure for a small loop to search array element

[avieira at gcc dot gnu.org]

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

--- Comment #5 from avieira at gcc dot gnu.org ---
I have posted a prototype on the mailing list
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541908.html

This is really just a prototype to investigate code-gen impact, I don't expect
to commit this as is and whether it makes sense to do something like this.

[Bug tree-optimization/94211] [9/10 Regression] -fcompare-debug failure on phi-opt-13.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||9.3.0
   Target Milestone|--- |9.4
  Known to work||7.4.0

[Bug middle-end/94206] Wrong optimization: memset of n-bit integer types (from bit-fields) is truncated to n bits (instead of sizeof)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||10.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/94206] Wrong optimization: memset of n-bit integer types (from bit-fields) is truncated to n bits (instead of sizeof)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:1ba9acb11e3589b96ed945ed2a3af6acd6377018

commit r10-7242-g1ba9acb11e3589b96ed945ed2a3af6acd6377018
Author: Richard Biener 
Date:   Wed Mar 18 13:11:30 2020 +0100

middle-end/94206 fix memset folding to avoid types with padding

This makes sure that the store a memset is folded to uses a type
covering all bits.

2020-03-18   Richard Biener  

PR middle-end/94206
* gimple-fold.c (gimple_fold_builtin_memset): Avoid using
partial int modes or not mode-precision integer types for
the store.

* gcc.dg/torture/pr94206.c: New testcase.

[Bug c++/94147] mangling of lambdas in initializers is wrong

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:11cf25c40e3f586d19474108c78a2dfad7925902

commit r10-7243-g11cf25c40e3f586d19474108c78a2dfad7925902
Author: Nathan Sidwell 
Date:   Wed Mar 18 05:16:28 2020 -0700

PR c++/94147 - mangling of lambdas assigned to globals

This patch implements Jason's suggestion of pushing a lambda scope
when parsing a global variable initializer.  That bit worked fine, but
happened to cause g++.dg/opt/dump1.C to not give any
used-but-not-defined warnings.

The reason was no_linkage_check, which considers any lambda that has
an extra-scope to have linkage.  Which is technically correct.  Except
that we think that all types that have linkage have external linkage.

Our representation of linkage and visibility is somewhat inaccurate,
particularly when it comes to types.  We have TREE_PUBLIC,
DECL_EXTERNAL, DECL_VISIBILITY, DECL_COMDAT, DECL_NOT_REALLY_EXTERN.
It could really do with a through cleanup, but that won't be a simple
task.

The best I could come up with was seeing if the extra scope was a
VAR_DECL, and if that was TREE_PUBLIC and the var was inline (its
COMDATness is sadly not set at that point) or a template
instantiation, then the lambda had linkage.  Otherwise it's as-if it
has no-linkage from the POV of compiler internals.

This is an ABI change (so we should document it), but it's changing
mangling from an unpredictable (in practice) counter, to something the
ABI defines.  So I'm not concerned about mangling-changed warnings, or
preserving the broken mangling under some ABI selection flag.  Code
that did this worked by accident within a single TU.  It'll continue
to work by design there, and across TUs.

* parser.c (cp_parser_init_declarator): Namespace-scope variables
provide a lambda scope.
* tree.c (no_linkage_check): Lambdas with a variable for extra
scope have a linkage from the variable.

[Bug c++/94147] mangling of lambdas in initializers is wrong

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 11cf25c40e3f586d19474108c78a2dfad7925902

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

The problem is that C FE finish_function uses input_location as
cfun->function_end_locus, but input_location isn't really updated very often in
the C FE anymore, mostly in the line change hooks but that doesn't trigger here
because the macro arguments span across newline.
So, either like in the completely untested patch we can update input_location
somewhat more often, or we'd need to propagate the location_t of the closing }
from c_parser_compound_statement_nostart to the callers.

[Bug c/94212] New: [AARCH64] [Regression] Incorrect vectorization of loop with FP calculations

[dpochepk at gmail dot com]

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

Bug ID: 94212
   Summary: [AARCH64] [Regression] Incorrect vectorization of loop
with FP calculations
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dpochepk at gmail dot com
  Target Milestone: ---

Created attachment 48054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48054&action=edit
example application returning different result for O3 and O2

Example application (FP polynomial loop calculations) gives different result
for O2 and O3 optimizations. Different is 1 ulp, so it might be some kind of
rounding error (unsafe math leaked?).
"-O3 -fno-tree-vectorize" gives correct result.

This issue seems to affect aarch64-only (at least x86_64 is fine).
Tried several gcc versions:

trunk: affected
gcc8.3: affected
gcc7.4: not affected

(I haven't investigated assembly)

Example application is in attachment. Method "foo" has vectorized loop, which
is probably the trigger for this bug.

[Bug c++/94210] ICE in tsubst, at cp/pt.c:15105

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-03-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

--- Comment #1 from Marek Polacek  ---
Confirmed, but not a recent regression; even g++ 5 ICEs.

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

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 48053 [details]
> gcc10-pr94029.patch
> 
> The problem is that C FE finish_function uses input_location as
> cfun->function_end_locus, but input_location isn't really updated very often
> in the C FE anymore, mostly in the line change hooks but that doesn't
> trigger here because the macro arguments span across newline.
> So, either like in the completely untested patch we can update
> input_location somewhat more often, or we'd need to propagate the location_t
> of the closing }
> from c_parser_compound_statement_nostart to the callers.

Thank you very much Jakub. If it survives regression tests, I would install the
suggested patch.

[Bug libstdc++/94213] New: doesn

[Zahira.Ammarguellat at intel dot com]

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

Bug ID: 94213
   Summary:  doesn
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Zahira.Ammarguellat at intel dot com
  Target Milestone: ---

[Bug middle-end/94212] [AARCH64] [Regression] Incorrect vectorization of loop with FP calculations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
I suspect there is an Fused multiple-add being used for vectorized version
while not for the non-vectorized version.

[Bug libstdc++/94213] doesn

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug middle-end/94212] [AARCH64] [Regression] Incorrect vectorization of loop with FP calculations

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>(at least x86_64 is fine)
No, just FMA is not enabled by default.  
If I use -march=skylake-avx512 , I get the same answers as on aarch64_64.

[Bug middle-end/94212] Incorrect vectorization of loop with FP calculations

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> >(at least x86_64 is fine)
> No, just FMA is not enabled by default.  
> If I use -march=skylake-avx512 , I get the same answers as on aarch64_64.

Note I am running on Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz.

[Bug libstdc++/94213] doesn

[Zahira.Ammarguellat at intel dot com]

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

Zahira Ammarguellat  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

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

[jakub at gcc dot gnu.org]

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

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

Variant patch which doesn't change input_location but propagates the closing }
location to finish_function.

[Bug middle-end/94212] Incorrect vectorization of loop with FP calculations

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Note also using -ffp-contract=off will also change the value.

[Bug libstdc++/94213] doesn

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
I guess we can consider lowering the default value of the param and/or having
separate param for var-tracking vs. for normal RTL optimizations.
But before doing that I think we want to gather some statistics to help us
decide on which value we want, like:
--- gcc/alias.c 2020-03-09 13:38:04.534284063 +0100
+++ gcc/alias.c 2020-03-18 14:20:03.669278109 +0100
@@ -2116,6 +2116,14 @@ find_base_term (rtx x)
   rtx res = find_base_term (x, visited_vals);
   for (unsigned i = 0; i < visited_vals.length (); ++i)
 visited_vals[i].first->locs = visited_vals[i].second;
+  if (visited_vals.length () > 100)
+{
+  FILE *f = fopen ("/tmp/fbt", "a");
+  fprintf (f, "%d %s %s %d %d\n", (int) BITS_PER_WORD,
+  main_input_filename ? main_input_filename : "-",
+  current_function_name (), visited_vals.length (), res !=
NULL_RTX);
+  fclose (f);
+}
   return res;
 }

and use it on both x86_64-linux and i686-linux bootstrap/regtest (perhaps other
targets too) and perhaps on some other packages too (firefox, libreoffice,
...).

[Bug c++/94214] New: function lookup with overloaded operators accepts invalid

[niklas at nolte dot dev]

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

Bug ID: 94214
   Summary: function lookup with overloaded operators accepts
invalid
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niklas at nolte dot dev
  Target Milestone: ---

Sample code:
```
#include 

template 
void blub(std::vector const& i) {
  -i;
  //getsize(i); //this also fails in gcc
}

int operator-(std::vector const& i) {
return i.size();
}

int getsize(std::vector const& i) {
return i.size();
}

int main() { blub(std::vector{1}); }
```

this shouldn't compile, it doesn't in clang..

See
- https://godbolt.org/z/hgGeH3

-
https://stackoverflow.com/questions/60740257/clang-vs-gcc-function-lookup-with-operator-overloads?noredirect=1#comment107466162_60740257
-
https://stackoverflow.com/questions/58793092/two-phase-function-template-compilation-not-only-adl-is-employed-in-the-2nd-p

[Bug c++/94210] ICE in tsubst, at cp/pt.c:15105

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Confirmed, started to ICE in between
r0-79589-g0de2ae02735c71f5318af4486444d33c26fc211a
and r0-79620-g89132ebc4c9e2bd960520dbbd8469d956794a7dd ,
almost certainly with 
r0-79609-g5d80a306744bf10263a1f69ceda3ac8366ba6606 .

[Bug tree-optimization/94211] [9/10 Regression] -fcompare-debug failure on phi-opt-13.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r8-5241-g8697bf9f46f36168ddba5752db582e673e3cbe8c .  I'll have a
quick look.

[Bug tree-optimization/94212] [8/9/10 Regression] Incorrect vectorization of loop with FP calculations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.4.0
Summary|Incorrect vectorization of  |[8/9/10 Regression]
   |loop with FP calculations   |Incorrect vectorization of
   ||loop with FP calculations
  Component|middle-end  |tree-optimization
Version|tree-ssa|10.0
   Target Milestone|--- |8.5
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Target||aarch64

--- Comment #5 from Richard Biener  ---
The vectorizer vectorizes the reduction in-order but appearantly sth goes wrong
there.

[Bug analyzer/94047] ICE: SIGSEGV in ana::region_model::get_lvalue_1() with -fanalyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r10-7250-gf665beeba625490bd96a593d23e00726d969cf98
Author: David Malcolm 
Date:   Tue Mar 10 18:50:03 2020 -0400

analyzer: add test coverage for fixed ICE [PR94047]

PR analyzer/94047 reports an ICE, which turned out to be caused
by the erroneous use of TREE_TYPE on the view region's type
in region_model::get_representative_path_var that I introduced
in r10-7024-ge516294a1acb28d44cfd583cc6a80354044e and
fixed in g:787477a226033e36be3f6d16b71be13dd917e982.

This patch adds a regression test for the ICE.

gcc/testsuite/ChangeLog:
PR analyzer/94047
* gcc.dg/analyzer/pr94047.c: New test.

[Bug analyzer/94047] ICE: SIGSEGV in ana::region_model::get_lvalue_1() with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Regression test added; marking as resolved.

[Bug tree-optimization/94212] [8/9/10 Regression] Incorrect vectorization of loop with FP calculations

[dpochepk at gmail dot com]

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

--- Comment #6 from Dmitrij Pochepko  ---
Just checked: non-vectorized assembly for aarch64 (O2) is using fmadd and fmsub
intensively.

[Bug tree-optimization/94212] [8/9/10 Regression] Incorrect vectorization of loop with FP calculations

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Dmitrij Pochepko from comment #6)
> Just checked: non-vectorized assembly for aarch64 (O2) is using fmadd and
> fmsub intensively.

Try with -ffp-contract=off then.  Note due to effective unrolling of
the loop with vectorization we might end up forming "different" fmadd
groups.  So you might also want to check whether the vectorized loop still
sees fmadd use.

[Bug tree-optimization/94211] [8/9/10 Regression] -fcompare-debug failure on phi-opt-13.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|9.4 |8.5
Summary|[9/10 Regression]   |[8/9/10 Regression]
   |-fcompare-debug failure on  |-fcompare-debug failure on
   |phi-opt-13.c|phi-opt-13.c

--- Comment #2 from Jakub Jelinek  ---
I think I've introduced this with
r8-3866-g14745bcac0e7b90a5c671b1f9402a53e57ea6431
With
  int e = a + 1;
before return a / b; it started already in that revision.

[Bug tree-optimization/94211] [8/9/10 Regression] -fcompare-debug failure on phi-opt-13.c

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug tree-optimization/94215] New: [10

[marxin at gcc dot gnu.org]

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

Bug ID: 94215
   Summary: [10
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

[Bug tree-optimization/94215] [10

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
.

[Bug tree-optimization/94216] New: [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[marxin at gcc dot gnu.org]

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

Bug ID: 94216
   Summary: [10 Regression] ICE in
maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899
since
r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE isolated from ade package:

$ cat /tmp/comm.ii
template  struct A { typedef int _Type[_Nm]; };
template  struct B {
  typename A<_Nm>::_Type _M_elems;
  void operator[](int) { int a = *_M_elems; }
};
class C {
  struct D {
using type = int *;
  };

public:
  using pointer = D::type;
};
class F {
public:
  using pointer = C::pointer;
  F(pointer);
};
struct G {
  int data;
};
template  struct H {
  using dimensions_t = B;
  dimensions_t dimensions;
  G mem;
};
template 
H alloc_view(int, DimT, AlignT, Allocator) {
  H b;
  b.dimensions[0];
  return b;
}
namespace memory {
template  using DynMdView = H<6>;
}
class I {
  I();
  memory::DynMdView m_view;
  F m_memory;
};
int c, d, e;
I::I() : m_view(alloc_view<6>(c, d, e, [] {})), m_memory(&m_view.mem.data) {}

$ ./xgcc -B. /tmp/comm.ii -c -g -O 
during IPA pass: inline
/tmp/comm.ii: In constructor ‘I::I()’:
/tmp/comm.ii:42:1: internal compiler error: in maybe_canonicalize_mem_ref_addr,
at gimple-fold.c:4899
   42 | I::I() : m_view(alloc_view<6>(c, d, e, [] {})),
m_memory(&m_view.mem.data) {}
  | ^
0xeae3c7 maybe_canonicalize_mem_ref_addr
../../gcc/gimple-fold.c:4899
0xeaedda fold_stmt_1
../../gcc/gimple-fold.c:5046
0xeafb25 fold_stmt(gimple_stmt_iterator*)
../../gcc/gimple-fold.c:5307
0x1219414 fold_marked_statements
../../gcc/tree-inline.c:5341
0x12278f3 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5447
0x1b56403 inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.c:722
0x10c09ba execute_one_ipa_transform_pass
../../gcc/passes.c:2233
0x10c09ba execute_all_ipa_transforms(bool)
../../gcc/passes.c:2272
0xd24fcb cgraph_node::expand()
../../gcc/cgraphunit.c:2276
0xd2609f expand_all_functions
../../gcc/cgraphunit.c:2454
0xd2609f symbol_table::compile()
../../gcc/cgraphunit.c:2804
0xd2872c symbol_table::compile()
../../gcc/cgraphunit.c:2717
0xd2872c symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2984
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/94214] function lookup with overloaded operators accepts invalid

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like a dup of PR 51577

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I wonder if we shouldn't do:
--- gcc/fold-const.c.jj 2020-03-18 12:47:36.0 +0100
+++ gcc/fold-const.c2020-03-18 17:34:14.586455801 +0100
@@ -82,6 +82,7 @@ along with GCC; see the file COPYING3.
 #include "attribs.h"
 #include "tree-vector-builder.h"
 #include "vec-perm-indices.h"
+#include "tree-ssa.h"

 /* Nonzero if we are folding constants inside an initializer; zero
otherwise.  */
@@ -10262,6 +10263,10 @@ fold_binary_loc (location_t loc, enum tr
   switch (code)
 {
 case MEM_REF:
+  STRIP_USELESS_TYPE_CONVERSION (arg0);
+  if (arg0 != op0)
+   return fold_build2 (MEM_REF, type, arg0, op1);
+
   /* MEM[&MEM[p, CST1], CST2] -> MEM[p, CST1 + CST2].  */
   if (TREE_CODE (arg0) == ADDR_EXPR
  && TREE_CODE (TREE_OPERAND (arg0, 0)) == MEM_REF)
to catch all similar issues.  Otherwise, we'd need to strip the useless type
conversion at least in the case which triggers this:
  return fold_build2 (MEM_REF, type,
  build_fold_addr_expr (base),
  int_const_binop (PLUS_EXPR, arg1,
   size_int (coffset)));
a few lines below this, where build_fold_addr_expr now returns a NOP_EXPR that
we really want to strip again, even when op0 wasn't a NOP_EXPR.

[Bug target/81594] Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #41854|0   |1
is obsolete||

--- Comment #4 from Michael Meissner  ---
Created attachment 48057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48057&action=edit
Update proposed patch to fix the problem

[Bug tree-optimization/94212] [8/9/10 Regression] Incorrect vectorization of loop with FP calculations

[dpochepk at gmail dot com]

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

--- Comment #8 from Dmitrij Pochepko  ---
(In reply to Richard Biener from comment #7)
> (In reply to Dmitrij Pochepko from comment #6)
> > Just checked: non-vectorized assembly for aarch64 (O2) is using fmadd and
> > fmsub intensively.
> 
> Try with -ffp-contract=off then.  Note due to effective unrolling of
> the loop with vectorization we might end up forming "different" fmadd
> groups.  So you might also want to check whether the vectorized loop still
> sees fmadd use.

-O2 -ffp-contract=off
-O3 -ffp-contract=off
produce same calculation result as -O2


regarging assembly:
vectorized version is using fmla and fmls, which is vectorized version of
multiply-add/sub. It's hard to say the difference in how multiplications and
additions/subtractions are grouped without detailed step-by-step comparison
though.

[Bug c++/94214] function lookup with overloaded operators accepts invalid

[niklas at nolte dot dev]

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

--- Comment #2 from niklas at nolte dot dev ---
(In reply to Jonathan Wakely from comment #1)
> Looks like a dup of PR 51577

agreed

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
So for the problematic wrf file we get:

$ gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy
-fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g
...
$ wc -l /tmp/fbt 
26273112 /tmp/fbt
$ sort /tmp/fbt | uniq -c | sort -n | tac | head -n10
24666359 64 module_configure.fppized.f90 initial_config 2001 0
 482996 64 module_configure.fppized.f90 initial_config 757 0
 336377 64 module_configure.fppized.f90 initial_config 620 0
 321717 64 module_configure.fppized.f90 initial_config 607 0
 288735 64 module_configure.fppized.f90 initial_config 571 0
 101785 64 module_configure.fppized.f90 initial_config 317 0
  23376 64 module_configure.fppized.f90 initial_config 127 0
  22014 64 module_configure.fppized.f90 initial_config 120 0
  18135 64 module_configure.fppized.f90 initial_config 107 0
 41 64 module_configure.fppized.f90 initial_config 115 0

[Bug middle-end/93092] g++ takes tremendous compilation times in var-tracking

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #4 from Nicholas Krause  ---
(In reply to Richard Biener from comment #2)
> On trunk:
> 
> (gdb) p cfun->cfg->x_last_basic_block 
> $1 = 8940
> (gdb) p cfun->cfg->x_n_edges
> $2 = 14897
> 
> so we miss
> 
>   if (n_basic_blocks_for_fn (cfun) > 500
>   && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 20)
> {
>   vt_debug_insns_local (true);
>   return 0;
> }
> 
> this isn't really a good absolute limit, it's just singling out very
> insane cases of very many edges (but allow scaling with the number of BBs).
> 
> There's another limit for the dataflow problem size that is also not hit
> (--param max-vartrack-size).
> 
> There are plenty of similar bugreports (unfortunately).

Richard,
Not sure if this would be considered a regression fix for stage 4 but we should
update these numbers to a more sane limit. I've assuming based on the ration of
25 to 1 that we should just make it something like:
if (n_basic_blocks_for_fn (cfun) > 5
   && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 2500)
 {
  vt_debug_insns_local (true);
   return 0;
 }

Not sure if we can do this for stage 4 of GCC 10 based on the comments. However
we should update these numbers at least at some point in stage 1 of GCC 11.
I'll send a patch either way.

[Bug c++/51577] dependent name lookup finds operator in global namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||niklas at nolte dot dev

--- Comment #12 from Jonathan Wakely  ---
*** Bug 94214 has been marked as a duplicate of this bug. ***

[Bug c++/94214] function lookup with overloaded operators accepts invalid

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
.

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

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
Jakub, 
I just tested your patch like this:
./gcc -B. comm.ii -c -g -O

as mentioned by Martin Liska's report. It does not crash now so this
should be fixed by it and the compiler was configured like:
Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
-disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Nicholas Krause from comment #2)
> Jakub, 
> I just tested your patch like this:
> ./gcc -B. comm.ii -c -g -O
> 
> as mentioned by Martin Liska's report. It does not crash now so this
> should be fixed by it and the compiler was configured like:
> Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
> -disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir

What is this comment good for?  Of course I've tested my patch against that
testcase, what I haven't done (yet) is full bootstrap/regtest.

[Bug ipa/94217] New: [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[marxin at gcc dot gnu.org]

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

Bug ID: 94217
   Summary: [10 Regression] ICE in ipa_find_agg_cst_for_param, at
ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
rguenth at gcc dot gnu.org
  Target Milestone: ---

Related to the same revision as PR94216, but it's not fixed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216#c1:

$ cat star.ii
template  struct A { A(int, _T2); };
template  class B {
  struct C {
C(B &p1) : _M_t(p1) {}
template  void operator()(_Arg) { _M_t._M_create_node(); }
B &_M_t;
  };
  void _M_create_node();
  int _S_key() {  }
  template 
  int _M_insert_(int *, int *, _Arg &&, _NodeGen &);

public:
  template  A _M_insert_unique(_Arg &&);
};
template 
template 
int B<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert_(int *p1, int *p2,
 _Arg &&,
 _NodeGen &p4) {
  p1 || p2 || _S_key();
  p4(0);
}
template 
template 
A
B<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert_unique(_Arg &&) {
  int a;
  int *b;
  C c(*this);
  _M_insert_(&a, b, 0, c);
  return A (1, false);
}
struct IdIsoLanguageEntry;
class D {
public:
  typedef A value_type;
  B _M_t;
  void insert(value_type p1) { _M_t._M_insert_unique(p1); }
};
class F {
public:
  F(const char *);
};
enum { LANGUAGE_ENGLISH };
struct IdIsoLanguageEntry {
  int m_languageId;
  const char m_language[3];
  F m_country;
} d[]{LANGUAGE_ENGLISH, "", ""};
class IdIsoLanguageMap {
public:
  IdIsoLanguageMap() {
for (auto l : d)
  m_idLanguageMap.insert(D::value_type(l.m_languageId, l));
  }
  D m_idLanguageMap;
} e;

$ g++ star.ii -c -flto -O2 -o x.o && gcc -shared x.o
star.ii: In member function ‘int B< ,
, , ,
 >::_S_key()’:
star.ii:9:19: warning: no return statement in function returning non-void
[-Wreturn-type]
9 |   int _S_key() {  }
  |   ^
star.ii: In member function ‘int B< ,
, , ,
 >::_M_insert_(int*, int*, _Arg&&, _NodeGen&)’:
star.ii:24:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   24 | }
  | ^
during IPA pass: cp
lto1: internal compiler error: in ipa_find_agg_cst_for_param, at
ipa-prop.c:3467
0xdc77e7 ipa_find_agg_cst_for_param(ipa_agg_value_set*, tree_node*, long, bool,
bool*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:3467
0xd87e7f evaluate_conditions_for_known_args
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c:371
0xd93a6a estimate_ipcp_clone_size_and_time(cgraph_node*, vec, vec,
vec, int*, sreal*, sreal*, int*)
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c:3658
0x205c840 estimate_local_effects
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3478
0x205d78a propagate_constants_topo
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3816
0x205da33 ipcp_propagate_stage
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3912
0x206262e ipcp_driver
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5908
0x2062814 execute
/home/marxin/Programming/gcc/gcc/ipa-cp.c:6001
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
  Known to fail||10.0
   Last reconfirmed||2020-03-18
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
  Known to work||9.3.0

[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
--- gcc/cp/parser.c.jj  2020-03-18 13:36:34.217840388 +0100
+++ gcc/cp/parser.c 2020-03-18 18:52:53.630586929 +0100
@@ -34059,6 +34059,8 @@ cp_parser_omp_var_list_no_open (cp_parse
   token->location);
}
}
+  if (outer_automatic_var_p (decl))
+   decl = process_outer_var_ref (decl, tf_warning_or_error);
   if (decl == error_mark_node)
;
   else if (kind != 0)
fixes the ICE, but doesn't seem to be enough, for some reason gimplification
still replaces the uses of score inside of the body with __closure->score
access, which is wrong.

[Bug target/94185] [10 Regression] crashes with "error: unable to generate reloads for {*zero_extendsidi2} internal compiler error: in curr_insn_transform, at lra-constraints.c:4006

[slyfox at inbox dot ru]

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

--- Comment #9 from Sergei Trofimovich  ---
Now smartmontools-7.0 builds successfully against gcc version 10.0.1 20200317
(experimental), commit 2e30d3e3e88b6a544074ff89de4974bc5e200e89.

Thank you for a superfast fix!

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi Marin,
I've not sure if this is correct but it does not ICE with this fix:
tree off = fold_convert (ptr_type_node, op1);
-   return build_fold_addr_expr_loc
-   (loc,
+   return build1_loc
+   (loc, ADDR_EXPR, TREE_TYPE (op0),
 fold_build2 (MEM_REF,
  TREE_TYPE (TREE_TYPE (op0)),
  unshare_expr (op0), off));

should actually be:  
(EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
 fold_build2 (MEM_REF,
  TREE_TYPE (TREE_TYPE (op0)),
  unshare_expr (op0), off));

I've tested with your file and I get:
star.ii: In member function ‘int B< ,
, , ,
 >::_S_key()’:
star.ii:9:19: warning: no return statement in function returning non-void
[-Wreturn-type]
9 |   int _S_key() {  }
  |   ^
star.ii: In member function ‘int B< ,
, , ,
 >::_M_insert_(int*, int*, _Arg&&, _NodeGen&)’:
star.ii:24:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   24 | }


However this seems to be on multiple ade package files so can you test it
against that as well.

[Bug middle-end/94218] New: Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[gsdrtge6h at protonmail dot com]

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

Bug ID: 94218
   Summary: Different __builtin_setjmp/__builtin_longjmp buffer
layout is suggested in case of cet.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsdrtge6h at protonmail dot com
  Target Milestone: ---
Target: ia32

Created attachment 48058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48058&action=edit
test for setjmp call

The current implementation layout is to put shadow stack pointer at jb + 16 and
normal stack pointer at jb + 24 when cet is enabled.

rdsspq  %rax
movq%rax, jb_extern+16(%rip)
movq%rsp, jb_extern+24(%rip)

When CET is disabled normal stack pointer goes to jb + 16.

It is suggested to switch the locations of shadow stack pointer and normal
stack pointer within the jump buffer.  This way there can be a chance to link
legacy/no-cet __builtin_longjmp() code with cet __builtin_setjmp() code.

[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[foom at fuhm dot net]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #7 from James Y Knight  ---
FWIW, the discussion in Clang about this is still ongoing, and the functions
remain unimplemented there.

I personally remain of the opinion that it would be ideal to leave these
permanently unimplemented, despite that the standards committee decided to keep
them in the standard even after objections were raised.

My second-favorite implementation after "unimplemented", would be to just
return constant values of 64 and 128 universally, regardless of architecture.
(If you cannot return an actually-correct answer, and decided that you need to
return something, you might as well just do something really easy and, _shrug_,
oh well.).


Others are arguing for implementing them to return actually valid and correct
values that depend on the exact configuration, and marking them as not being
abi-stable. Users would then need to be aware that they must not use the
constants in ABIs (which means effectively "don't use in a header file"), since
the value might change at any time with a compiler upgrade, or with the use of
different command-line flags (e.g. -mcpu/-march).

(To return correct values, compiler upgrades must be allowed to change the
values if it becomes aware of a new CPU model which changes the
largest/smallest-known cacheline sizes that this code could run on. And
-mcpu/-march flags similarly ought to change the values by restricting the
possible set of CPUs this code might run on.)

Any new thoughts from GCC developers?

[Bug middle-end/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[gsdrtge6h at protonmail dot com]

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

--- Comment #1 from gsdrtge6h at protonmail dot com ---
Created attachment 48059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48059&action=edit
longjmp part of the test

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
__builtin_setjmp/__builtin_longjmp really should not be used.  They are
normally used internally for Exception handling if dwarf2 eh is not enabled.

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
"This can make __builtin_setjmp and __builtin_longjmp more efficient than their
library counterparts in some cases, but it can also cause incorrect and
mysterious behavior when mixing with code that uses the full register set."

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Nonlocal-Gotos.html#index-_005f_005fbuiltin_005fsetjmp

"You should use the standard C library functions declared in  in user
code instead of the builtins"

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> "This can make __builtin_setjmp and __builtin_longjmp more efficient than
> their library counterparts in some cases, but it can also cause incorrect
> and mysterious behavior when mixing with code that uses the full register
> set."

CET is considered register set differences.

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Also:
"GCC provides the built-in functions __builtin_setjmp and __builtin_longjmp
which are similar to, but not interchangeable with, the C library functions
setjmp and longjmp."

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
(In reply to Nicholas Krause from comment #1)
> Hi Marin,
> I've not sure if this is correct but it does not ICE with this fix:
> tree off = fold_convert (ptr_type_node, op1);
> -   return build_fold_addr_expr_loc
> -   (loc,
> +   return build1_loc
> +   (loc, ADDR_EXPR, TREE_TYPE (op0),
>  fold_build2 (MEM_REF,
>   TREE_TYPE (TREE_TYPE (op0)),
>   unshare_expr (op0), off));
> 
> should actually be:  
> (EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
>  fold_build2 (MEM_REF,
>   TREE_TYPE (TREE_TYPE (op0)),
>   unshare_expr (op0), off));

Huh?  Why do you think that changing the location should fix the ICE?  That's a
completely random change that you never bothered to test, because it doesn't
fix the crash.

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[xerofoify at gmail dot com]

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

--- Comment #3 from Nicholas Krause  ---
(In reply to Marek Polacek from comment #2)
> (In reply to Nicholas Krause from comment #1)
> > Hi Marin,
> > I've not sure if this is correct but it does not ICE with this fix:
> > tree off = fold_convert (ptr_type_node, op1);
> > -   return build_fold_addr_expr_loc
> > -   (loc,
> > +   return build1_loc
> > +   (loc, ADDR_EXPR, TREE_TYPE (op0),
> >  fold_build2 (MEM_REF,
> >   TREE_TYPE (TREE_TYPE (op0)),
> >   unshare_expr (op0), off));
> > 
> > should actually be:  
> > (EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
> >  fold_build2 (MEM_REF,
> >   TREE_TYPE (TREE_TYPE (op0)),
> >   unshare_expr (op0), off));
> 
> Huh?  Why do you think that changing the location should fix the ICE? 
> That's a completely random change that you never bothered to test, because
> it doesn't fix the crash.

Here is my exact output of testing the change:
[xerofoify@gcc2-power8 bin]$ ./g++ star.ii -c -flto -O2 -o x.o && ./gcc -shared
x.o
star.ii: In member function ‘int B< ,
, , ,
 >::_S_key()’:
star.ii:9:19: warning: no return statement in function returning non-void
[-Wreturn-type]
9 |   int _S_key() {  }
  |   ^
star.ii: In member function ‘int B< ,
, , ,
 >::_M_insert_(int*, int*, _Arg&&, _NodeGen&)’:
star.ii:24:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   24 | }
  | ^

If you look at the revision mentioned for this bug in gimple-fold.c here:
tree off = fold_convert (ptr_type_node, op1);
-   return build_fold_addr_expr_loc
-   (loc,
+   return build1_loc
+   (loc, ADDR_EXPR, TREE_TYPE (op0),
that's incorrect as loc is not the tree we want but off and from that the
EXPR_LOCATION of that tree. Does that make more sense now?

[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think we need also:
--- gcc/cp/cp-gimplify.c.jj 2020-03-11 09:28:53.964213973 +0100
+++ gcc/cp/cp-gimplify.c2020-03-18 19:09:53.281323970 +0100
@@ -2260,12 +2260,17 @@ cxx_omp_finish_clause (tree c, gimple_se
 bool
 cxx_omp_disregard_value_expr (tree decl, bool shared)
 {
-  return !shared
-&& VAR_P (decl)
-&& DECL_HAS_VALUE_EXPR_P (decl)
-&& DECL_ARTIFICIAL (decl)
-&& DECL_LANG_SPECIFIC (decl)
-&& DECL_OMP_PRIVATIZED_MEMBER (decl);
+  if (shared)
+return false;
+  if (VAR_P (decl)
+  && DECL_HAS_VALUE_EXPR_P (decl)
+  && DECL_ARTIFICIAL (decl)
+  && DECL_LANG_SPECIFIC (decl)
+  && DECL_OMP_PRIVATIZED_MEMBER (decl))
+return true;
+  if (is_capture_proxy (decl))
+return true;
+  return false;
 }

 /* Fold expression X which is used as an rvalue if RVAL is true.  */

but will need as well proper testsuite coverage for using OpenMP constructs in
lambdas; in OpenMP 4.5 and earlier that wasn't well defined, but in OpenMP 5.0
which we (partially) support now it is.

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[gsdrtge6h at protonmail dot com]

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

--- Comment #7 from gsdrtge6h at protonmail dot com ---
Okay, but why the current layout is any better than the suggested layout.

[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to gsdrtge6h from comment #7)
> Okay, but why the current layout is any better than the suggested layout.

Because these are not useful for anything really.  The suggested layout might
require big changes in the compiler which does not make a big difference in the
long run anways since these are not used except for testing to make sure sjlj
eh still works.

[Bug c++/93589] Template instantiation creates a conversion warning when it should not

[jrdowning at yahoo dot com]

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

John Downing  changed:

   What|Removed |Added

 CC||jrdowning at yahoo dot com

--- Comment #11 from John Downing  ---
I think I understand, but one more question.  The "*" operator promotes the RHS
to int, then it converted back to short.  But you say the warning is a "false
positive".  So if it's a "false positive", then why isn't that false positive
suppressed?  I know that clang does not show an error for the exact same code,
so clearly it is compliant with the C++ standard to do so.

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Nicholas Krause from comment #1)
> Hi Marin,

s/Marin/Martin

@Nicholas: As Marek said, please do not propose changes that are not completely
tested and that are more just quests. An issue like this is super covered: we
know starting revision and the changes were made by our very senior developers
(Richard and Jakub). That means they will fix the issue quickly and with
consideration of all possible pitfalls.

If you are interested in solving bugzilla issue, please take a look at issues
that haven't had attention for a long time.

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 48060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48060&action=edit
Reduced test-case without a warning

$ gcc -O2 -flto star.ii -shared
during IPA pass: cp
lto1: internal compiler error: in ipa_find_agg_cst_for_param, at
ipa-prop.c:3467
0x66038d ipa_find_agg_cst_for_param(ipa_agg_value_set*, tree_node*, long, bool,
bool*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:3467
0x66038d ipa_find_agg_cst_for_param(ipa_agg_value_set*, tree_node*, long, bool,
bool*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:3440
0xae630f evaluate_conditions_for_known_args
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c:371
0xaefdb9 estimate_ipcp_clone_size_and_time(cgraph_node*, vec, vec,
vec, int*, sreal*, sreal*, int*)
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c:3658
0x167ff18 estimate_local_effects
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3478
0x168a26f propagate_constants_topo
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3816
0x168a26f ipcp_propagate_stage
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3912
0x168a26f ipcp_driver
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5908
0x168a26f execute
/home/marxin/Programming/gcc/gcc/ipa-cp.c:6001
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
For firefox with LTO we get:

$ wc -l /tmp/fbt
1645 /tmp/fbt
$ sort /tmp/fbt | uniq -c | sort -n | tac | head -n20
 10 64 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 103 0
 10 64 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 101 0
  6 64 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 106 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 997 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 996 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 995 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 994 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 993 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 992 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 991 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 988 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 987 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 986 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 985 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 984 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 983 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 982 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 979 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 978 0
  2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 977 0

there are no bigger values than 1000.

[Bug c/3481] function attributes should apply to function pointers too

[cgf at gcc dot gnu.org]

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

Chris Faylor  changed:

   What|Removed |Added

 CC||cgf at gcc dot gnu.org

--- Comment #125 from Chris Faylor  ---
Trying to trigger a response from bugs.debian.org to see how we're suppressing
the X-Loop header.

[Bug ipa/92799] [8/9/10 Regression] ICE on a weakref function definition followed by a declaration

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:3512dc0108afbed3bece2e9fa1719fb3ce1d73d9

commit r10-7267-g3512dc0108afbed3bece2e9fa1719fb3ce1d73d9
Author: Martin Sebor 
Date:   Wed Mar 18 14:47:29 2020 -0600

PR ipa/92799 - ICE on a weakref function definition followed by a
declaration

gcc/testsuite/ChangeLog:

PR ipa/92799
* gcc.dg/attr-weakref-5.c: New test.

gcc/ChangeLog:

PR ipa/92799
* cgraphunit.c (process_function_and_variable_attributes): Also
complain about weakref function definitions and drop all effects
of the attribute.

[Bug ipa/92799] [8/9 Regression] ICE on a weakref function definition followed by a declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] ICE on  |[8/9 Regression] ICE on a
   |a weakref function  |weakref function definition
   |definition followed by a|followed by a declaration
   |declaration |

--- Comment #7 from Martin Sebor  ---
Fixed for GCC 10.  The patch should be safe to backport to release branches
after some time.

[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542190.html

[Bug c++/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542098.html

[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #8 from Jonathan Wakely  ---
(In reply to James Y Knight from comment #7)
> I personally remain of the opinion that it would be ideal to leave these
> permanently unimplemented, despite that the standards committee decided to
> keep them in the standard even after objections were raised.

I'm inclined to agree.

> My second-favorite implementation after "unimplemented", would be to just
> return constant values of 64 and 128 universally, regardless of
> architecture. (If you cannot return an actually-correct answer, and decided
> that you need to return something, you might as well just do something
> really easy and, _shrug_, oh well.).

Which makes them just verbose ways to spell an integer that might or might not
be right for your target.

> Others are arguing for implementing them to return actually valid and
> correct values that depend on the exact configuration, and marking them as
> not being abi-stable. Users would then need to be aware that they must not
> use the constants in ABIs (which means effectively "don't use in a header
> file"), since the value might change at any time with a compiler upgrade, or
> with the use of different command-line flags (e.g. -mcpu/-march).

I suppose a warning if you use them in a header might mitigate the dangers a
bit.

> (To return correct values, compiler upgrades must be allowed to change the
> values if it becomes aware of a new CPU model which changes the
> largest/smallest-known cacheline sizes that this code could run on. And
> -mcpu/-march flags similarly ought to change the values by restricting the
> possible set of CPUs this code might run on.)
> 
> Any new thoughts from GCC developers?

I'm not aware of anybody planning to work on them.

I continue to think they're broken by design.

[Bug rtl-optimization/90275] [8/9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:529ea7d9596b26ba103578eeab448e9862a2d2c5

commit r10-7268-g529ea7d9596b26ba103578eeab448e9862a2d2c5
Author: Jeff Law 
Date:   Wed Mar 18 16:07:28 2020 -0600

Complete change to resolve pr90275.

PR rtl-optimization/90275
* cse.c (cse_insn): Delete no-op register moves too.

[Bug c++/94219] New: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790

[ppalka at gcc dot gnu.org]

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

Bug ID: 94219
   Summary: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat 94066-struct.C
struct A { long x; };

struct U;
constexpr A foo(U *up);

struct U {   // struct instead of union
  A a = foo(this); int y;
};

constexpr A foo(U *up) {
  up->y = 11;
  return {42};
}

extern constexpr U u = {};

static_assert(u.y == 11, "");
static_assert(u.a.x == 42, "");
$ g++ -std=c++14 94066-struct.C
94066-modified.C:15:25: internal compiler error: in cxx_eval_bare_aggregate, at
cp/constexpr.c:3790
   18 | extern constexpr U u = {};
  | ^
0x602956 cxx_eval_bare_aggregate
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:3790
0x941caf cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5895
0x944914 cxx_eval_outermost_constant_expr
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6451
0x9498c4 maybe_constant_init_1
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6908
0xb1919c store_init_value(tree_node*, tree_node*, vec**, int)
/home/patrick/code/gcc-master/gcc/cp/typeck2.c:889
0x9acc22 check_initializer
/home/patrick/code/gcc-master/gcc/cp/decl.c:6838
0x9ae917 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/patrick/code/gcc-master/gcc/cp/decl.c:7764
0xa57a9d cp_parser_init_declarator
/home/patrick/code/gcc-master/gcc/cp/parser.c:20837
0xa378f3 cp_parser_simple_declaration
/home/patrick/code/gcc-master/gcc/cp/parser.c:13689
0xa5fd97 cp_parser_declaration
/home/patrick/code/gcc-master/gcc/cp/parser.c:13388
0xa60517 cp_parser_translation_unit
/home/patrick/code/gcc-master/gcc/cp/parser.c:4731
0xa60517 c_parse_file()
/home/patrick/code/gcc-master/gcc/cp/parser.c:43758
0xb70dcb c_common_parse_file()
/home/patrick/code/gcc-master/gcc/c-family/c-opts.c:1186



This is closely related to PR c++/94066, but unlike that PR, this one is not a
regression AFAICT.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r10-7270-gb3341826531e80e02f194460b4fbe1b0541c0463
Author: Jonathan Wakely 
Date:   Wed Mar 18 23:19:12 2020 +

libstdc++: Fix is_trivially_constructible (PR 94033)

This attempts to make is_nothrow_constructible more robust (and
efficient to compile) by not depending on is_constructible. Instead the
__is_constructible intrinsic is used directly. The helper class
__is_nt_constructible_impl which checks whether the construction is
non-throwing now takes a bool template parameter that is substituted by
the result of the instrinsic. This fixes the reported bug by not using
the already-instantiated (and incorrect) value of std::is_constructible.
I don't think it really fixes the problem in general, because
std::is_nothrow_constructible itself could already have been
instantiated in a context where it gives the wrong result. A proper fix
needs to be done in the compiler.

PR libstdc++/94033
* include/std/type_traits (__is_nt_default_constructible_atom):
Remove.
(__is_nt_default_constructible_impl): Remove.
(__is_nothrow_default_constructible_impl): Remove.
(__is_nt_constructible_impl): Add bool template parameter. Adjust
partial specializations.
(__is_nothrow_constructible_impl): Replace class template with
alias
template.
(is_nothrow_default_constructible): Derive from alias template
__is_nothrow_constructible_impl instead of
__is_nothrow_default_constructible_impl.
* testsuite/20_util/is_nothrow_constructible/94003.cc: New test.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #19 from Jonathan Wakely  ---
Should be fixed now. Thanks for the testcases and testing.

[Bug libstdc++/93923] [10 Regression] std::is_copy_constructible raises compilation error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
I'm going to close this, for the reason stated earlier: the standard says you
can't use is_constructible with an incomplete type.

Performing overload resolution for is_copy_constructible has to check if
A(const B&) is viable, which tries to construct B from const A&, which
has to check the constraints of B::B(Args&&...) which depends on
is_constructible.

I'm not convinced this example is very realistic, but if needed it can be fixed
by excluding the B(Args&&...) constructor from being used with a single
argument of type T:

template
struct  B {
template
  struct check : std::is_constructible { };
template
  struct check : std::is_same> { };

template<
class... Args,
std::enable_if_t::value, int> = 0>
B(Args && ... args) {}

B(const T&) { }
B(T&&) { }
};

Alternatively, just make the B(Args&&...) constructor explicit (and add a
separate default constructor, because explicit default constructors are weird
and unhelpful), which is probably the right thing to do anyway:

template
struct  B {
template<
class... Args,
std::enable_if_t::value, int> = 0 >
explicit
B(Args && ... args) {}

B() = default;
};

If you have a realistic use case that can't be solved in one of these ways, and
shows a reasonable situation where is_constructible needs to work for
incomplete types, please provide it and re-open the bug.

[Bug libgcc/94220] New: libgcc FTB for ARM Thump when optimizing for size

[npl at chello dot at]

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

Bug ID: 94220
   Summary: libgcc FTB for ARM Thump when optimizing for size
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npl at chello dot at
CC: rearnsha at arm dot com
  Target Milestone: ---

This issue was introduced with 6b9ce2b4eb49e3c930730c3721323349e2136b1a,
the sections guarded with __OPTIMIZE_SIZE__ where apparently left out

/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1139: Error:
cannot honor width suffix -- `mul r2,r0'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1140: Error:
cannot honor width suffix -- `sub r1,r1,r2'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1238: Error:
MOV Rd, Rs with two low registers is not permitted on this architecture -- `mov
work,dividend'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1239: Error:
cannot honor width suffix -- `eor work,divisor'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1241: Error:
cannot honor width suffix -- `mov curbit,#1'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1242: Error:
cannot honor width suffix -- `mov result,#0'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1245: Error:
cannot honor width suffix -- `neg divisor,divisor'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1249: Error:
cannot honor width suffix -- `neg dividend,dividend'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1256: Error:
MOV Rd, Rs with two low registers is not permitted on this architecture -- `mov
r0,result'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1260: Error:
cannot honor width suffix -- `neg r0,r0'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1351: Error:
cannot honor width suffix -- `mul r2,r0'
/tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1352: Error:
cannot honor width suffix -- `sub r1,r1,r2'

(Fix is rather straightforward: add an 's' to every op)

[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4161

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jiu Fu Guo
:

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

commit r9-8401-gd01cb80e0fbe23510a861faab9909b76837faf98
Author: Jiufu Guo 
Date:   Tue Mar 10 13:51:57 2020 +0800

rs6000: Check -+0 and NaN for smax/smin generation

PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
relates to max of '-inf' and 'nan'. This regression occur on P9 because
P9 new instruction 'xsmaxcdp' is generated.
And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2
for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b).
In GCC9, the issue also occur as the new test case shows.

This generates prevents 'xsmaxcdp' to be generated for those cases.
'xsmincdp' also is handled in patch.

gcc/
2020-03-19  Jiufu Guo  

PR target/93709
* gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check
NAN and SIGNED_ZEROR for smax/smin.

gcc/testsuite
2020-03-19  Jiufu Guo  

PR target/93709
* gcc.target/powerpc/p9-minmax-3.c: New test.

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Mine.

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine.

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #1)
> I wonder if we shouldn't do:
> --- gcc/fold-const.c.jj   2020-03-18 12:47:36.0 +0100
> +++ gcc/fold-const.c  2020-03-18 17:34:14.586455801 +0100
> @@ -82,6 +82,7 @@ along with GCC; see the file COPYING3.
>  #include "attribs.h"
>  #include "tree-vector-builder.h"
>  #include "vec-perm-indices.h"
> +#include "tree-ssa.h"
>  
>  /* Nonzero if we are folding constants inside an initializer; zero
> otherwise.  */
> @@ -10262,6 +10263,10 @@ fold_binary_loc (location_t loc, enum tr
>switch (code)
>  {
>  case MEM_REF:
> +  STRIP_USELESS_TYPE_CONVERSION (arg0);

We already applied STRIP_NOPS to arg0

> +  if (arg0 != op0)
> + return fold_build2 (MEM_REF, type, arg0, op1);
> +
>/* MEM[&MEM[p, CST1], CST2] -> MEM[p, CST1 + CST2].  */
>if (TREE_CODE (arg0) == ADDR_EXPR
> && TREE_CODE (TREE_OPERAND (arg0, 0)) == MEM_REF)
> to catch all similar issues.  Otherwise, we'd need to strip the useless type
> conversion at least in the case which triggers this:
>   return fold_build2 (MEM_REF, type,
>   build_fold_addr_expr (base),
>   int_const_binop (PLUS_EXPR, arg1,
>size_int (coffset)));
> a few lines below this, where build_fold_addr_expr now returns a NOP_EXPR
> that we really want to strip again, even when op0 wasn't a NOP_EXPR.

True.  But note there could be a not useless type conversion here, for
example for MEM [&a] and void *a for example.  Here I think
the better fix is (again) to use build1 and then in case the base was
a MEM_REF recurse to the preceeding pattern.

I'm testing such a patch.