[Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99824
   Summary: ICE in wide_int_to_tree_1, at tree.c:1572
   Product: gcc
   Version: 11.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: ---

Created attachment 50484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50484&action=edit
ltrans object file

The following happens for the current gcc-10 branch when building Linux kernel
with LTO.

$ ./lto1 vmlinux.o.ltrans720.o -fltrans -quiet
during GIMPLE pass: fre
../../../../home/marxin/Programming/linux-misc/drivers/media/pci/cx18/cx18-i2c.c:
In function ‘init_cx18_i2c’:
../../../../home/marxin/Programming/linux-misc/drivers/media/pci/cx18/cx18-i2c.c:217:
internal compiler error: in wide_int_to_tree_1, at tree.c:1572
  217 | int init_cx18_i2c(struct cx18 *cx)
  | 
0x5e2780 wide_int_to_tree_1
/home/marxin/Programming/gcc2/gcc/tree.c:1572
0xa59ac3 set_min_and_max_values_for_integral_type(tree_node*, int, signop)
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2822
0xa5e766 set_min_and_max_values_for_integral_type(tree_node*, int, signop)
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2816
0xa5e766 fixup_signed_type(tree_node*)
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2834
0xcb07ae build_nonstandard_integer_type(unsigned long, int)
/home/marxin/Programming/gcc2/gcc/tree.c:8020
0xbd6245 vn_reference_lookup_3
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890
0xb32522 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-alias.c:3691
0xbd124f vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:3545
0xbd6e8e visit_reference_op_load
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:4934
0xbd6e8e visit_stmt
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:5374
0xbd7b96 process_bb
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7047
0xbd9a3e do_rpo_vn
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7566
0xbda300 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7834
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/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|ICE in wide_int_to_tree_1,  |[10 Regression] ICE in
   |at tree.c:1572  |wide_int_to_tree_1, at
   ||tree.c:1572
   Last reconfirmed||2021-03-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
The issue is likely fixed on master.
Is it something familiar Richi?

[Bug tree-optimization/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Richard Biener  ---
(In reply to Martin Sebor from comment #14)
> Reconfirmed with GCC 11 and the C test case below:
> 
> void f (int);
> 
> int main () {
> int i;
> int array[10];
> for (; i<10; ++i) { // no warning
> f (i);  // no warning
> array [i] = i;  // no warning, really hurts
> }
> }

So what's going "wrong" here is that we figure the BB with the i<10 check
post-dominates the entry block and thus is always executed.  But when
doing warn_uninit on the SSA var we do not consider the value on the
always-executed path from entry (which is uninitialized i_3(D)).

That's for the early pass, the late pass doesn't run at -O0.

Note since we walk BBs in index order which 'i' we warn for is probably
random, I think we'll only warn once since we set TREE_NO_WARNING on the
underlying decl of the SSA name (that's probably misguided - different
SSA defs can have different uninit state).

It might be possible to populate possibly_undefined_names in the BB walk
by visiting PHIs and considering fallthru entries being taken to have this
work out without major restructuring of the pass (a lattice of "undefinedness"
would probably be more to the point).

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Liška  ---
valgrind tells:

==2489== Conditional jump or move depends on uninitialised value(s)
==2489==at 0xCFBD22: wi::force_to_size(long*, long const*, unsigned int,
unsigned int, unsigned int, signop) (wide-int.cc:370)
==2489==by 0xCB2CD3: from (wide-int.h:1172)
==2489==by 0xCB2CD3: wide_int_to_tree_1(tree_node*,
generic_wide_int > const&) (tree.c:1515)
==2489==by 0xA59AC3: set_min_and_max_values_for_integral_type(tree_node*,
int, signop) [clone .part.0] (stor-layout.c:2822)
==2489==by 0xA5E766: set_min_and_max_values_for_integral_type
(stor-layout.c:2816)
==2489==by 0xA5E766: fixup_signed_type(tree_node*) (stor-layout.c:2834)
==2489==by 0xCB079E: build_nonstandard_integer_type(unsigned long, int)
(tree.c:8020)
==2489==by 0xBD6245: vn_reference_lookup_3(ao_ref*, tree_node*, void*,
translate_flags*) (tree-ssa-sccvn.c:2890)
==2489==by 0xB32522: walk_non_aliased_vuses(ao_ref*, tree_node*, bool,
void* (*)(ao_ref*, tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*,
translate_flags*), tree_node* (*)(tree_node*), unsigned int&, void*)
(tree-ssa-alias.c:3691)
==2489==by 0xBD124F: vn_reference_lookup(tree_node*, tree_node*,
vn_lookup_kind, vn_reference_s**, bool, tree_node**, tree_node*)
(tree-ssa-sccvn.c:3545)
==2489==by 0xBD6E8E: visit_reference_op_load (tree-ssa-sccvn.c:4934)
==2489==by 0xBD6E8E: visit_stmt(gimple*, bool) [clone .isra.0]
(tree-ssa-sccvn.c:5374)
==2489==by 0xBD7B96: process_bb(rpo_elim&, basic_block_def*, bool, bool,
bool, bool, bool, bitmap_head*, bool) [clone .constprop.0]
(tree-ssa-sccvn.c:7047)
==2489==by 0xBD9A3E: do_rpo_vn(function*, edge_def*, bitmap_head*, bool,
bool) (tree-ssa-sccvn.c:7566)
==2489==by 0xBDA300: (anonymous namespace)::pass_fre::execute(function*)
(tree-ssa-sccvn.c:7834)

#0  fancy_abort (file=file@entry=0x148dfb8
"/home/marxin/Programming/gcc2/gcc/tree.c", line=line@entry=1572,
function=function@entry=0x148cba0 "wide_int_to_tree_1") at
/home/marxin/Programming/gcc2/gcc/diagnostic.c:1778
#1  0x005e2781 in wide_int_to_tree_1 (type=,
pcst=...) at /home/marxin/Programming/gcc2/gcc/tree.c:1572
#2  0x00a59ac4 in set_min_and_max_values_for_integral_type
(type=, type@entry=,
precision=6, sgn=sgn@entry=SIGNED) at
/home/marxin/Programming/gcc2/gcc/poly-int.h:671
#3  0x00a5e767 in set_min_and_max_values_for_integral_type (sgn=SIGNED,
precision=, type=) at
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2816
#4  fixup_signed_type (type=) at
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2834
#5  0x00cb079f in build_nonstandard_integer_type
(precision=precision@entry=384, unsignedp=0) at
/home/marxin/Programming/gcc2/gcc/tree.c:8020
#6  0x00bd6246 in vn_reference_lookup_3 (ref=ref@entry=0x7fffd760,
vuse=vuse@entry=,
data_=data_@entry=0x7fffd7f0,
disambiguate_only=disambiguate_only@entry=0x7fffd694)
at /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890

It's called for a string constant:

(gdb) p debug_tree((tree)0x7fffd410)
 
$1 = void

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Richard Biener  ---
(In reply to Jan Hubicka from comment #15)
> I also tried to reproduce this locally w/o luck.
> 
> Looking at the backtrace in detail, there is no DEF_STMT involved.  It walks
> from dwarf dies, to RTL constant pool address that points to tree which has
> abstract origin that points to symtab node which points to callgraph edge
> which points to dead basic block.
> 
> The pointer from cgraph node to edge that should be removed.
> I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt
> in the backtrace, so it would not help here.

We're already doing this it seems:

void
fini_ssanames (struct function *fn)
{
  unsigned i;
  tree name;
  /* Some SSA names leak into global tree data structures so we can't simply
 ggc_free them.  But make sure to clear references to stmts since we now
 ggc_free the CFG itself.  */
  FOR_EACH_VEC_SAFE_ELT (SSANAMES (fn), i, name)
if (name)
  SSA_NAME_DEF_STMT (name) = NULL;

> W/o reproducer it seem hard to tell what is/was real cause of this issue...

So the backtrace points at

  gt_ggc_m_11symtab_node
((*x).generic.function_decl.common.common.symtab_node);

from LTO 'tree' walk.  To me it's still obvious - we walk a cgraph edge
call_stmt and from there to gimple_bb which was freed.

Looking around the only place (we don't know whether this was WPA or LTRANS)
we'd have a cgraph with edges is during clone materialization which pointed
me at cgraph_node::release_body which frees the body but fails to eventually
zap ->call_stmt references.

Matthias reported this for "trunk 20210306" which I assume is a snapshot
tarball configured the Debian way.

> Honza

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Martin Liška  ---
(In reply to Haoxin Tu from comment #7)
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r9-7156-g33579b59aaf02eb7.
> 
> Hi Martin. I am sorry to bother you, and I just have a question about how to
> find a bad commit quickly in GCC.

Hello.

You don't have to find a bad revision, we can easily do that.

>  
> As far as I know, we can use git bitset to set a bad and good commit to then
> apply binary search to find the exact place that caused the error(I usually
> do like this). My question is, is this means I should always find a commit
> (to be tested), then build the source code and run the given test case to
> tell a bad/good result? My concern is that build a GCC from a source code
> may take a relatively long time (maybe more than half an hour), so if the
> number of commits is much, it will take a long time to find the error
> commit. Is my understanding correct or not? 

I have a script which I use:
https://github.com/marxin/script-misc/blob/master/gcc-bisect.py

I can do quick bisection as I have built binaries for all GCC revisions for a
couple last years.

> 
> Also, I am wondering if you are using an automatic tool or other approaches
> that can quickly find the bad commit to cause the problem. If I learned how
> to do this quickly, I'd like to do the bitset myself and tell the bad commit
> when I submit a report next time.
> 
> Please correct me if I am wrong and any suggestions are welcome! Thank you
> very much!

We thank you for a nice bug report. Keep doing :)

Martin

> 
> 
> Best,
> Haoxin

[Bug sanitizer/99801] Address sanitizer false positive with pointer to member function.

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-30
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I can take a look.

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
I have started some script that continuously do following:
  git pull
  configure
  make 
  make install
  do 5000 attempts to compile system headers in random order
  upload the results of the attempts to http://lelyakin.de/modules

They are sorted by error message and by count of successfully compiled headers. 
Results are updated approximately every 7-8 hours.

Currently reproducible are the following errors:

99737 - Aborted
99479 - Aborted signal terminated program cc1plus
99722 - Segmentation fault
99426 - failed to read compiled module cluster
99283 - in assert_definition
99241 - in install_entity
99284 - in key_mergeable
99242 - in lookup_mark
99243 - in set_filename
99244 - in tsubst_copy
99246 - in write_location
99427 - non-constant condition for static assertion
99760 - qsort checking failed
99274 - wrong number of template arguments (1, should be 2

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-30

--- Comment #1 from Martin Liška  ---
Thanks for the report. Hm, it's strange as we should request exactly this
version of the symbol through the following code path:

  COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN(regexec, "GLIBC_2.3.4");
\

#ifdef __GLIBC__
// If we could not find the versioned symbol, fall back to an unversioned
// lookup. This is needed to work around a GLibc bug that causes dlsym
// with RTLD_NEXT to return the oldest versioned symbol.
// See https://sourceware.org/bugzilla/show_bug.cgi?id=14932.
// For certain symbols (e.g. regexec) we have to perform a versioned lookup,
// but that versioned symbol will only exist for architectures where the
// oldest Glibc version pre-dates support for that architecture.
// For example, regexec@GLIBC_2.3.4 exists on x86_64, but not RISC-V.
// See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920.
#define COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN(fn, ver) \
  COMMON_INTERCEPT_FUNCTION_VER_UNVERSIONED_FALLBACK(fn, ver)
#else
#define COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN(fn, ver) \
  COMMON_INTERCEPT_FUNCTION(fn)
#endif

#define ASAN_INTERCEPT_FUNC_VER_UNVERSIONED_FALLBACK(name, ver)  \
  do {   \
if (!INTERCEPT_FUNCTION_VER(name, ver) && !INTERCEPT_FUNCTION(name)) \
  VReport(1, "AddressSanitizer: failed to intercept '%s@@%s' or '%s'\n", \
  #name, #ver, #name);   \
  } while (0)


Can you please debug if INTERCEPT_FUNCTION_VER really fails?
I'm sorry but I don't have a handy s390 machine.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Richard Biener  ---
It doesn't reproduce for me with a debug build.  The backtrace you cite is
impossible (with that STRING_CST).  The GCC10 package from leap unfortunately
doesn't have zstd support enabled...  I'm trying a local
profile-LTO-bootstrapped build.

What exact rev. were you testing and how did you configure/build GCC?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Version|11.0|10.2.1
  Known to fail|10.2.0  |10.2.1

[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||10.2.1
  Known to fail||11.0
Summary|Assembler messages: Error:  |[11 Regression] Assembler
   |integer register expected   |messages: Error: integer
   |in the extended/shifted |register expected in the
   |operand register at operand |extended/shifted operand
   |3 -- `adds x1,xzr,#2'   |register at operand 3 --
   ||`adds x1,xzr,#2'
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2021-03-30
   Target Milestone|--- |11.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
OK, so I guess that things go wrong in wi::min_value where we nowhere check
that the precision we're asking for (384) fits in a wide_int,
WIDE_INT_MAX_PRECISION should be 160 (MAX_BITSIZE_MODE_ANY_INT) rounded up
to 64bits thus 192.  That then clobbers the stack somewhere and things go
wrong.

This is likely uncovered by the PR98834 "fix"
g592388d4f6e8a6adb470428fef6195694f4a3dce (but this fix shouldn't expose
such large precisions by itself)

I still like to reproduce it to see what events lead to such large requested
precision.  On trunk sth like

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 784f131ebb8..94b8b21c7a8 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
   if (precision < 1)
 return;

+  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
+
   TYPE_MIN_VALUE (type)
 = wide_int_to_tree (type, wi::min_value (precision, sgn));
   TYPE_MAX_VALUE (type)

should uncover any similar issue and eventually allow producing smaller
testcases.

[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I'll take it.

[Bug target/99825] New: ICE in vect_build_combine_node

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 99825
   Summary: ICE in vect_build_combine_node
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gfortran-11.0.1-alpha20210328 snapshot
(g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) ICEs when compiling the following
testcase, reduced from gcc/testsuite/gfortran.dg/inline_matmul_11.f90, w/
-march=armv8.3-a -O3:

program main
  complex, dimension(3, 2) :: a
  complex, dimension(2, 4) :: b
  complex, dimension(3, 4) :: c, res1

  data a /0, (-5., -7.), (11., -13.), 0, 0, 0/
  data b /0, 0, 0, 0, 0, 0, 0, 0/
  data res1 /0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0/

  c = matmul(a, conjg(b))
  if (any(res1 /= c)) stop 2
end program main

% aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O3 -c xfxklbt7.f90
during GIMPLE pass: vect
xfxklbt7.f90:12:16:

   12 | end program main
  |^
internal compiler error: in quick_push, at vec.h:1021
0x7c477e vec, va_heap,
vl_embed>::quick_push(std::pair const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/vec.h:1021
0x7c489a vec, va_heap,
vl_embed>::quick_push(std::pair const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp-patterns.c:907
0x7c489a vec, va_heap,
vl_ptr>::quick_push(std::pair const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/vec.h:1875
0x7c489a vect_build_combine_node
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp-patterns.c:891
0x123f945 complex_mul_pattern::build(vec_info*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp-patterns.c:1068
0x1232418 vect_match_slp_patterns_2
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:2430
0x12323c4 vect_match_slp_patterns_2
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:2422
0x12323c4 vect_match_slp_patterns_2
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:2422
0x12366b7 vect_match_slp_patterns
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:2458
0x12366b7 vect_analyze_slp(vec_info*, unsigned int)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:2901
0x1213157 vect_analyze_loop_2
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-loop.c:2316
0x1214eb3 vect_analyze_loop(loop*, vec_info_shared*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-loop.c:2985
0x1245aa7 try_vectorize_loop_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vectorizer.c:1009
0x1246540 vectorize_loops()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vectorizer.c:1243

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> It doesn't reproduce for me with a debug build.  The backtrace you cite is
> impossible (with that STRING_CST).  The GCC10 package from leap unfortunately
> doesn't have zstd support enabled...  I'm trying a local
> profile-LTO-bootstrapped build.


> 
> What exact rev. were you testing and how did you configure/build GCC?

Please build it locally for

commit 982df4d606e8f3e8f41369672bf0c6ff22ee58c1 (HEAD -> releases/gcc-10,
origin/releases/gcc-10)
Author: GCC Administrator 
Date:   Tue Mar 30 00:17:29 2021 +

Daily bump.

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: /home/marxin/Programming/gcc2/configure
--prefix=/home/marxin/bin/gcc2 --enable-languages=c,c++,fortran
--disable-bootstrap --disable-multilib --disable-libsanitizer
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210330 (GCC)

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 784f131ebb8..94b8b21c7a8 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
>if (precision < 1)
>  return;
>  
> +  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
> +
>TYPE_MIN_VALUE (type)
>  = wide_int_to_tree (type, wi::min_value (precision, sgn));
>TYPE_MAX_VALUE (type)
> 
> should uncover any similar issue and eventually allow producing smaller
> testcases.

Where would you expect the assert to be triggered? In LTO/non-LTO mode?

[Bug fortran/93660] Decl mismatch between fndecl TYPE and used arglist / ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Christophe Lyon
:

https://gcc.gnu.org/g:960eaefb99a805dd6afdc1f223055bd2458d6c49

commit r10-9617-g960eaefb99a805dd6afdc1f223055bd2458d6c49
Author: Jakub Jelinek 
Date:   Mon Mar 29 17:05:47 2021 +0200

testsuite: Expect a warning on aarch64 for declare-simd-coarray-lib.f90
[PR93660]

aarch64 currently doesn't support declare simd where the return value and
arguments
have different sizes and warns about that case.  This change adds a
dg-warning
for that case like various other tests have already.

2021-03-29  Jakub Jelinek  

PR fortran/93660
* gfortran.dg/gomp/declare-simd-coarray-lib.f90: Expect a mixed
size
declare simd warning on aarch64.

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Breakpoint 4, __interception::InterceptFunction (name=0x3fffd61e8f2 "regexec",
ver=0x3fffd61eb7e "GLIBC_2.3.4", ptr_to_real=0x3fffd677d08
<__interception::real_regexec>, func=16779728, 
wrapper=4398001883504) at
/devel/gcc-4/src/libsanitizer/interception/interception_linux.cpp:74
74void *addr = GetFuncAddr(name, ver);

At the end of InterceptFunction we have:

(gdb) print addr
$1 = (void *) 0x3fffd2e9110 <__GI___regexec>

The address itself also LGTM, i.e., `readelf -s /lib64/libc.so.6 | grep
regexec` results in:
   279: 000e9110   344 FUNCGLOBAL DEFAULT   13 regexec@@GLIBC_2.3.4
...
 25156: 000e9110   344 FUNCLOCAL  DEFAULT   13 __GI___regexec

However, variables func and wrapper differ 

(gdb) print func
$2 = 16779728
(gdb) print wrapper
$3 = 4398001883504

so we return false.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Jan Hubicka  ---
> Looking around the only place (we don't know whether this was WPA or LTRANS)
> we'd have a cgraph with edges is during clone materialization which pointed
> me at cgraph_node::release_body which frees the body but fails to eventually
> zap ->call_stmt references

This I agree with, but during our last discussion I went through all
release_body calls and found none which would match this scenario - they are
all on paths where we zap cgraph edges to (it is only makes sense to exist in
this case, since we are supposed to keep cgrpah edges in sync with actual body
and after feeing the body this would leave cgaph in inconsistent stage).

I will try to move tree to 20210306 and see if that helps.

I can simply add cgraph edge removal to release_body to make code bit more
robust - while most uses erases edges earlier, it is almost free to check the
pointer for being NULL twice.  Still it is weird that the bug does not
reproduce with allways collect.

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Liška  ---
Strange, please report it to upstream:
https://github.com/google/sanitizers/issues

and CC people from https://reviews.llvm.org/D96348

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Jan Hubicka  ---
Created attachment 50485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50485&action=edit
small refactoring

this patch moves the removal to release_body and removes the calls on those
paths where removal is done just after call to it (as opposed to being done
earlier or via reset cal).

But still there is no code path where it should make difference. Pehraps the
assert will catch something interesting. Tests are running.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Richard Biener  ---
So we're value-numbering a char load

Value numbering stmt = _177 = *sc_175;

with sc_175 == _7 and

  _7 = &cx_41(D)->i2c_adap[i_24].name;

which get's us a valueized ref (of type 'char') that looks like
cx_41(D)->i2c_adap[i_24].name and ao_ref_init_from_vn_reference turning
that into

$1 = {ref = , base = , 
  offset = {> = {coeffs = {388000}}, }, 
  size = {> = {coeffs = {384}}, }, 
  max_size = {> = {coeffs = {384}}, }, 
  ref_alias_set = 0, base_alias_set = 0, volatile_p = false}

because it looks at COMPONENT_REF/BIT_FIELD_REF sizes but those really only
represent offsets (well, not really really, but ...).

We then arrive at

# .MEM_170 = VDEF <.MEM_169>
cx_41(D)->i2c_adap[i_24].name = "cx18 i2c driver";

So this looks like a latent thing waiting to happen.  The GIMPLE FE is
currently not happy to produce a testcase.  Trunk is somewhat more
resilent to produce the situation since vn_reference_maybe_forwprop_address
uses the SSA lattice for the address offset calculation (in this case
i_24 has value zero).

With the proposed assert at least the LTRANS unit reproduces an ICE
with a debug build for me.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Richard Biener  ---
(In reply to Martin Liška from comment #6)
> > diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> > index 784f131ebb8..94b8b21c7a8 100644
> > --- a/gcc/stor-layout.c
> > +++ b/gcc/stor-layout.c
> > @@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
> >if (precision < 1)
> >  return;
> >  
> > +  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
> > +
> >TYPE_MIN_VALUE (type)
> >  = wide_int_to_tree (type, wi::min_value (precision, sgn));
> >TYPE_MAX_VALUE (type)
> > 
> > should uncover any similar issue and eventually allow producing smaller
> > testcases.
> 
> Where would you expect the assert to be triggered? In LTO/non-LTO mode?

Eventually in both.  The assert also triggers with the cited change reverted
so I do think the issue is latent.

[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
I think the bug is in swapped constraints on add3_poly_1.
We have:
(define_constraint "Uai"
  "@internal
   A constraint that matches a VG-based constant that can be added by
   a single INC or DEC."
  (match_operand 0 "aarch64_sve_scalar_inc_dec_immediate"))

(define_constraint "Uav"
  "@internal
   A constraint that matches a VG-based constant that can be added by
   a single ADDVL or ADDPL."
 (match_operand 0 "aarch64_sve_addvl_addpl_immediate"))

and *add3_aarch64 has:
Uai,Uav
and matching output for those 2 constraints is:
  * return aarch64_output_sve_scalar_inc_dec (operands[2]);
  * return aarch64_output_sve_addvl_addpl (operands[2]);"
Now, *add3_poly_1 has:
Uav,Uai
and matching output for those 2 constraints is:
  * return aarch64_output_sve_scalar_inc_dec (operands[2]);
  * return aarch64_output_sve_addvl_addpl (operands[2]);
so IMHO, either we need to swap those 2 return lines, or do:
--- gcc/config/aarch64/aarch64.md.jj2021-02-25 23:07:07.851319165 +0100
+++ gcc/config/aarch64/aarch64.md   2021-03-30 11:13:35.994077470 +0200
@@ -2051,7 +2051,7 @@
 (match_operand:GPI 0 "register_operand" "=r,r,r,r,r,r,&r")
 (plus:GPI
  (match_operand:GPI 1 "register_operand" "%rk,rk,rk,rk,rk,0,rk")
- (match_operand:GPI 2 "aarch64_pluslong_or_poly_operand"
"I,r,J,Uaa,Uav,Uai,Uat")))]
+ (match_operand:GPI 2 "aarch64_pluslong_or_poly_operand"
"I,r,J,Uaa,Uai,Uav,Uat")))]
   "TARGET_SVE && operands[0] != stack_pointer_rtx"
   "@
   add\\t%0, %1, %2

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Richard Biener  ---
Changing ao_ref_init_from_vn_reference to avoid excess sizes (in excess of the
access type specified) like with

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 4b280f21006..926b4a976ae 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -996,22 +996,26 @@ ao_ref_init_from_vn_reference (ao_ref *ref,
   poly_offset_int size = -1;
   tree size_tree = NULL_TREE;

-  /* First get the final access size from just the outermost expression.  */
+  machine_mode mode = TYPE_MODE (type);
+  if (mode == BLKmode)
+size_tree = TYPE_SIZE (type);
+  else
+size = GET_MODE_BITSIZE (mode);
+  if (size_tree != NULL_TREE
+  && poly_int_tree_p (size_tree))
+size = wi::to_poly_offset (size_tree);
+
+  /* Lower the final access size from the outermost expression.  */
   op = &ops[0];
+  size_tree = NULL_TREE;
   if (op->opcode == COMPONENT_REF)
 size_tree = DECL_SIZE (op->op0);
   else if (op->opcode == BIT_FIELD_REF)
 size_tree = op->op0;
-  else
-{
-  machine_mode mode = TYPE_MODE (type);
-  if (mode == BLKmode)
-   size_tree = TYPE_SIZE (type);
-  else
-   size = GET_MODE_BITSIZE (mode);
-}
   if (size_tree != NULL_TREE
-  && poly_int_tree_p (size_tree))
+  && poly_int_tree_p (size_tree)
+  && (!known_size_p (size)
+ || known_lt (wi::to_poly_offset (size_tree), size)))
 size = wi::to_poly_offset (size_tree);

   /* Initially, maxsize is the same as the accessed element size.

avoids hitting the assert.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Created attachment 50486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50486&action=edit
patch I am testing

I'm testing this patch, on trunk first, but it also applies to the branch where
it fixes the issue on the LTRANS unit in question.  Maybe you can check a
kernel LTO build with this?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Martin Liška  ---
(In reply to Richard Biener from comment #10)
> Created attachment 50486 [details]
> patch I am testing
> 
> I'm testing this patch, on trunk first, but it also applies to the branch
> where it fixes the issue on the LTRANS unit in question.  Maybe you can
> check a kernel LTO build with this?

All right, I'll try first reducing a test-case..

[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Full untested fix.

[Bug c/99826] New: GIMPLE FE fails to grok pointer declarators

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99826
   Summary: GIMPLE FE fails to grok pointer declarators
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

char * __GIMPLE(ssa) foo(char *p)
{
  char *_2;

__BB(2):
  _2 = p_1(D);
  return _2;
}

shows two issues, first the return type declaration causes __GIMPLE to be
not associated with the function, failing it to parse at all.  Fixing that
using a typedef shows that we fail to parse the SSA declaration 'char *_2'
as SSA name declaration because we have

  /* Handle SSA name decls specially, they do not go into the identifier
 table but we simply build the SSA name for later lookup.  */
  unsigned version, ver_offset;
  if (declarator->kind == cdk_id
  && is_gimple_reg_type (specs->type)

but declarator is

$5 = {kind = cdk_pointer, id_loc = 0, declarator = 0x3775200, u = {id = {
  id = , attrs = }, arg_info = 0x0, array = {
  dimen = , quals = 0, attrs = , static_p = 0, 
  vla_unspec_p = 0}, pointer_quals = 0, attrs = }}

in this case.  It looks like we need to unwrap cdk_pointer at least
(and build the actual pointer type in the SSA case).  The "early-out"
case for SSA names tries to avoid start_decl and building a decl
(and registering it in the binding for future lookup).

[Bug target/99825] [11 Regression] ICE in vect_build_combine_node

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|ICE in  |[11 Regression] ICE in
   |vect_build_combine_node |vect_build_combine_node
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-30
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
Started with r11-6734-gad2603433853129e847cade5e269c6a5f889a020

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Tue, 30 Mar 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99824
> 
> --- Comment #11 from Martin Liška  ---
> (In reply to Richard Biener from comment #10)
> > Created attachment 50486 [details]
> > patch I am testing
> > 
> > I'm testing this patch, on trunk first, but it also applies to the branch
> > where it fixes the issue on the LTRANS unit in question.  Maybe you can
> > check a kernel LTO build with this?
> 
> All right, I'll try first reducing a test-case..

That would be nice - I don't even have a GIMPLE FE one even if I know
exactly how it goes "wrong" in VN...

[Bug target/99825] [11 Regression] ICE in vect_build_combine_node

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
887   perm.create (SLP_TREE_LANES (rep));
888 
889   for (unsigned x = 0; x < SLP_TREE_LANES (rep); x+=2)
890 {
891   perm.quick_push (std::make_pair (0, x));
892   perm.quick_push (std::make_pair (1, x+1));
893 }

that was added in r11-6693-ge09173d84dabd186ad2463f47350c1bcabfeab8f
can't really work, it allocates just SLP_TREE_LANES (resp) elements,
but can quick_push one more elements - when SLP_TREE_LANES is odd (in this
testcase 3).  So, either some caller needs to ensure SLP_TREE_LANES is even or
this function isn't called, or it needs to be changed to handle even odd
numbers.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Martin Liška  ---
Reduced test-case:

$ cat ice.i
unsigned int
strlen(char *s) {
  for (; *s;)
;
}

struct i2c_adapter {
  char name[48];
};

struct {
  int instance;
  struct i2c_adapter i2c_adap[];
} * init_cx18_i2c_cx;

const struct i2c_adapter cx18_i2c_adap_template = {""};
int init_cx18_i2c___trans_tmp_1;

void
init_cx18_i2c() {
  int i = 0;
  for (;; i++) {
init_cx18_i2c_cx->i2c_adap[i] = cx18_i2c_adap_template;
init_cx18_i2c___trans_tmp_1 = strlen(init_cx18_i2c_cx->i2c_adap[i].name);
  }
}

$ gcc -O2 ice.i -c
ice.i:2:1: warning: conflicting types for built-in function ‘strlen’; expected
‘long unsigned int(const char *)’ [-Wbuiltin-declaration-mismatch]
2 | strlen(char *s) {
  | ^~
ice.i:1:1: note: ‘strlen’ is declared in header ‘’
  +++ |+#include 
1 | unsigned int
during GIMPLE pass: fre
ice.i: In function ‘init_cx18_i2c’:
ice.i:26:1: internal compiler error: in
set_min_and_max_values_for_integral_type, at stor-layout.c:2819
   26 | }
  | ^
0x5eaa0e set_min_and_max_values_for_integral_type(tree_node*, int, signop)
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2819
0xb1ad14 fixup_signed_type(tree_node*)
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2836
0xd6d15e build_nonstandard_integer_type(unsigned long, int)
/home/marxin/Programming/gcc2/gcc/tree.c:8020
0xc92c55 vn_reference_lookup_3
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890
0xbeef32 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-alias.c:3691
0xc8dc5f vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:3545
0xc9389e visit_reference_op_load
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:4934
0xc9389e visit_stmt
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:5374
0xc945a6 process_bb
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7047
0xc9644e do_rpo_vn
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7566
0xc96d10 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7834
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Fixed on master with r11-198-g1595a1cb7bfac8d5 and started with
r10-1823-g8389386c6d55d57a (one needs -fno-finite-loops).

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Martin Liška  ---
> Fixed on master with r11-198-g1595a1cb7bfac8d5

Reverting the match.pd hunk does not help with reproduction on the current
master.

[Bug target/99825] [11 Regression] ICE in vect_build_combine_node

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #3 from Tamar Christina  ---
(In reply to Jakub Jelinek from comment #2)
> 887 perm.create (SLP_TREE_LANES (rep));
> 888   
> 889 for (unsigned x = 0; x < SLP_TREE_LANES (rep); x+=2)
> 890   {
> 891 perm.quick_push (std::make_pair (0, x));
> 892 perm.quick_push (std::make_pair (1, x+1));
> 893   }
> 
> that was added in r11-6693-ge09173d84dabd186ad2463f47350c1bcabfeab8f
> can't really work, it allocates just SLP_TREE_LANES (resp) elements,
> but can quick_push one more elements - when SLP_TREE_LANES is odd (in this
> testcase 3).  So, either some caller needs to ensure SLP_TREE_LANES is even
> or this function isn't called, or it needs to be changed to handle even odd
> numbers.

It can't work on odd lanes since the operation needs to update both a real and
imaginary component. So this should have been rejected much earlier.

Testing a patch.

[Bug c++/79070] Unhelpful error message for ambiguous type in template parameter

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-02-08 00:00:00 |2021-3-30

--- Comment #4 from Jonathan Wakely  ---
For Barry's example, Clang gives the exact same error in all three cases, which
is much more useful:


79070.C:11:17: error: reference to 'Something' is ambiguous
static_assert(C>);
^
79070.C:8:30: note: candidate found by name lookup is 'Something'
template  struct Something { };
 ^
79070.C:2:58: note: candidate found by name lookup is 'N::Something'
template  struct Something { };
 ^
79070.C:14:3: error: reference to 'Something' is ambiguous
X> x;
  ^
79070.C:8:30: note: candidate found by name lookup is 'Something'
template  struct Something { };
 ^
79070.C:2:58: note: candidate found by name lookup is 'N::Something'
template  struct Something { };
 ^
79070.C:17:11: error: reference to 'Something' is ambiguous
using T = Something;
  ^
79070.C:8:30: note: candidate found by name lookup is 'Something'
template  struct Something { };
 ^
79070.C:2:58: note: candidate found by name lookup is 'N::Something'
template  struct Something { };
 ^
3 errors generated.

[Bug target/98136] [8/9/10/11 Regression] [aarch64] Internal compiler error with large classes and virtual methods since r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:48c79f054bf435051c95ee093c45a0f8c9de5b4e

commit r11-7905-g48c79f054bf435051c95ee093c45a0f8c9de5b4e
Author: Richard Sandiford 
Date:   Tue Mar 30 11:42:50 2021 +0100

aarch64: Tweak post-RA handling of CONST_INT moves [PR98136]

This PR is a regression caused by r8-5967, where we replaced
a call to aarch64_internal_mov_immediate in aarch64_add_offset
with a call to aarch64_force_temporary, which in turn uses the
normal emit_move_insn{,_1} routines.

The problem is that aarch64_add_offset can be called while
outputting a thunk, where we require all instructions to be
valid without splitting.  However, the move expanders were
not splitting CONST_INT moves themselves.

I think the right fix is to make the move expanders work
even in this scenario, rather than require callers to handle
it as a special case.

gcc/
PR target/98136
* config/aarch64/aarch64.md (mov): Pass multi-instruction
CONST_INTs to aarch64_expand_mov_immediate when called after RA.

gcc/testsuite/
PR target/98136
* g++.dg/pr98136.C: New test.

[Bug tree-optimization/99825] [11 Regression] ICE in vect_build_combine_node

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

  Component|target  |tree-optimization
 Status|NEW |ASSIGNED

[Bug target/98136] [8/9/10 Regression] [aarch64] Internal compiler error with large classes and virtual methods since r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |[aarch64] Internal compiler |[aarch64] Internal compiler
   |error with large classes|error with large classes
   |and virtual methods since   |and virtual methods since
   |r8-5967-gf5470a77425a54efeb |r8-5967-gf5470a77425a54efeb
   |fe1732488c40f05ef176d0  |fe1732488c40f05ef176d0

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems in *.ira dump the v1 (33) register is only used in OImode, so
reg->biggest_mode being E_OImode makes sense.
But for some reason LRA has added
 (expr_list:REG_DEAD (reg:VNx8BF 33 v1)
and the code is unhappy to see partial_subreg_p called for unordered modes.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

   Assignee|avieira at gcc dot gnu.org |rsandifo at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
The RTL side is the same problem as PR97141.

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Testing a patch.  See also PR98726.

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #9)
> [test@ibm-p8-cluster-02 ~]$ cat 97653.c
> int printf(const char*, ...);
> 
> const unsigned long k = 256;
> 
> int main()
> {
>   long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
>   for (int i = 0; i < 4; ++i)
>   {
> unsigned long j = k * r[i];
> printf("%lu * %Lf = %lu\n", k, r[i], j);
>   }
> }
> [test@ibm-p8-cluster-02 ~]$ ~/gcc/ieee/bin/gcc 97653.c  -mno-gnu-attribute
> -mabi=ibmlongdouble  -Wall -static-libgcc -v  && ./a.out
> Using built-in specs.
> COLLECT_GCC=/home/test/gcc/ieee/bin/gcc
> COLLECT_LTO_WRAPPER=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-
> linux-gnu/11.0.1/lto-wrapper
> Target: powerpc64le-unknown-linux-gnu
> Configured with: /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee
> --disable-multilib --disable-bootstrap --enable-languages=c++ --disable-pch
> --disable-nls --without-isl --with-long-double-format=ieee : (reconfigured)
> /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee --disable-multilib
> --disable-bootstrap --enable-languages=c++ --disable-pch --disable-nls
> --without-isl --with-long-double-format=ieee

Is your compiler intentionally configured without --with-long-double-128, i.e.
are you intentionally testing the double == long double case?
I can reproduce the weirdo output only when I build with such configured
cross-compiler (without -mlong-double-128) and link on gcc112 on CompilerFarm
with the system compiler (which defaults to -mlong-double-128).

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Thanks for the pointers!  I reported it upstream in issue
[1390](https://github.com/google/sanitizers/issues/1390)

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #10)
> Is your compiler intentionally configured without --with-long-double-128,

No.

> i.e. are you intentionally testing the double == long double case?

Not intentionally, isn't that implied by --with-long-double-format=ieee ?!

That's what the docs seem to say:

  Specify whether long double uses the IBM extended double format or the IEEE
  128-bit floating point format on PowerPC Linux systems.
  [...]
  If you use the --with-long-double-64 configuration option, the
  --with-long-double-format=ibm and --with-long-double-format=ieee options
  are ignored.

That tells me that using --with-long-double-format={ibm,ieee} chooses *which*
of the 128-bit long double formats you want, and so --with-long-double-128 is
implied. Maybe I'm reading it wrong.

Let me test again. Maybe I was using the system libgcc_s.so not the one
configured as --with-long-double-format=ieee (but I would still expect that to
work as the system one is from F34's gcc-11).

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Jonathan Wakely  ---
Also, the docs for --with-long-double-128 say

  When neither of these configure options are used, the default will be 128-bit
  long double when built against GNU C Library 2.4 and later, 64-bit long
double
  otherwise.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-7906-gbd3d919b58466a9837e423c1255b88215f89bc9d
Author: Richard Biener 
Date:   Tue Mar 30 11:22:52 2021 +0200

tree-optimization/99824 - avoid excessive integer type precision in VN

VN sometimes builds new integer types to handle accesss where precision
of the access type does not match the access size.  The way
ao_ref_init_from_vn_reference is computing the access size ignores
the access type in case the ref operands have an outermost
COMPONENT_REF which, in case it is an array for example, can be
way larger than the access size.  This can cause us to try
building an integer type with precision larger than WIDE_INT_MAX_PRECISION
eventually leading to memory corruption.

The following adjusts ao_ref_init_from_vn_reference to only lower
access sizes via the outermost COMPONENT_REF but otherwise honor
the access size as specified by the access type.

It also places an assert in integer type building that we remain
in the limits of WIDE_INT_MAX_PRECISION.  I chose the shared code
where we set TYPE_MIN/MAX_VALUE because that will immediately
cross the wide_ints capacity otherwise.

2021-03-30  Richard Biener  

PR tree-optimization/99824
* stor-layout.c (set_min_and_max_values_for_integral_type):
Assert the precision is within the bounds of
WIDE_INT_MAX_PRECISION.
* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
the outermost component ref only to lower the access size
and initialize that from the access type.

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

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #11)
> That tells me that using --with-long-double-format={ibm,ieee} chooses
> *which* of the 128-bit long double formats you want, and so
> --with-long-double-128 is implied. Maybe I'm reading it wrong.

At least from seeing what my cross-compiler does it is not implied.
If I compile with those 
-mno-gnu-attribute -mabi=ibmlongdouble
options, scp assembly to gcc112, compile there (system compiler defaults to
-mlong-double-128), it fails, if I compile locally with
-mno-gnu-attribute -mabi=ibmlongdouble -mlong-double-128
and scp and do the same, it works.
And I can't reproduce on gcc112 with 11.0.0 20210126 gcc natively built there
which defaults to -mlong-double-128:
~/gcc/obj31/gcc/xgcc -B ~/gcc/obj31/gcc/ -B
~/gcc/obj31/powerpc64le-unknown-linux-gnu/libgcc/ -o pr97653{,.c}
-static-libgcc -mno-gnu-attribute -mabi=ibmlongdouble
./pr97653
256 * 0.10 = 25
256 * 0.20 = 51
256 * 0.50 = 128
256 * 0.90 = 230

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-9618-gee15832c53d52656e562c29110f2be1cfb66c450
Author: Richard Biener 
Date:   Tue Mar 30 11:22:52 2021 +0200

tree-optimization/99824 - avoid excessive integer type precision in VN

VN sometimes builds new integer types to handle accesss where precision
of the access type does not match the access size.  The way
ao_ref_init_from_vn_reference is computing the access size ignores
the access type in case the ref operands have an outermost
COMPONENT_REF which, in case it is an array for example, can be
way larger than the access size.  This can cause us to try
building an integer type with precision larger than WIDE_INT_MAX_PRECISION
eventually leading to memory corruption.

The following adjusts ao_ref_init_from_vn_reference to only lower
access sizes via the outermost COMPONENT_REF but otherwise honor
the access size as specified by the access type.

It also places an assert in integer type building that we remain
in the limits of WIDE_INT_MAX_PRECISION.  I chose the shared code
where we set TYPE_MIN/MAX_VALUE because that will immediately
cross the wide_ints capacity otherwise.

2021-03-30  Richard Biener  

PR tree-optimization/99824
* stor-layout.c (set_min_and_max_values_for_integral_type):
Assert the precision is within the bounds of
WIDE_INT_MAX_PRECISION.
* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
the outermost component ref only to lower the access size
and initialize that from the access type.

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

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[Alexander.Richardson at cl dot cam.ac.uk via Gcc-bugs]

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

Alex Richardson  changed:

   What|Removed |Added

 CC||Alexander.Richardson at cl dot 
cam
   ||.ac.uk

--- Comment #5 from Alex Richardson  
---
Does the sanitizer runtime library include the https://reviews.llvm.org/D96348
patch?

IMO the real issue is that dlsym() with RTLD_NEXT selects the oldest versioned
symbol. Not sure why that behaviour was chosen.
I'm sure there are lots of other sanitizer interceptors that are also affected
by https://sourceware.org/bugzilla/show_bug.cgi?id=1319.

[Bug tree-optimization/99726] [10/11 Regression] ICE in create_intersect_range_checks_index, at tree-data-ref.c:1855 since r10-4762-gf9d6338bd15ce1fae36bf25d3a0545e9678ddc58

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
(In reply to Alex Richardson from comment #5)
> Does the sanitizer runtime library include the
> https://reviews.llvm.org/D96348 patch?

Yes, the change was merged into GCC master some time ago.

> 
> IMO the real issue is that dlsym() with RTLD_NEXT selects the oldest
> versioned symbol. Not sure why that behaviour was chosen.
> I'm sure there are lots of other sanitizer interceptors that are also
> affected by https://sourceware.org/bugzilla/show_bug.cgi?id=1319.

Shouldn't dlvsym return the only one symbol in this case? Can't we rely on
that?

[Bug middle-end/98689] [11 Regression] FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
   Last reconfirmed||2021-03-30
 Ever confirmed|0   |1

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #20 from Jan Hubicka  ---
I re-tried with g:0ad6a2e2f0c667f9916cfcdb81f41f6055f1d0b3
and it builds all fine even with --param ggc-min-expand=0 --param
ggc-min-heapsize=0. It seems that --enable-checking=gcac is now noop.

@doko: perhaps using --param ggc-min-expand=0 --param ggc-min-heapsize=0 on
your setup may trigger the problem again.  There is some chance that i.e. the
qt headers are the cause, but I am tempted to close the bug as WORKSFORME after
committing the refactoring patch.

[Bug c++/99827] New: [coroutines] co_await on function receiving initializer list of shared pointers causes ICE

[inf17092 at lehre dot dhbw-stuttgart.de via Gcc-bugs]

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

Bug ID: 99827
   Summary: [coroutines] co_await on function receiving
initializer list of shared pointers causes ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: inf17092 at lehre dot dhbw-stuttgart.de
  Target Milestone: ---

When using coroutines and awaiting the return value of a function receiving an
initializer list of shared pointers, the tree check fails with the following
error:

  internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have array_type in build_special_member_call, at
cp/call.c:10143

When using the promise type `promise::promise_type`, the following function
produces the error. In this case, `func1` receives the initializer list of
shared pointers and returns an awaitable.

  promise task() {
co_await func1({ std::make_shared(1) });
  }

You can find a short sample file demonstrating the bug and the full error
output here: https://godbolt.org/z/489EcWdb3. The bug also occurs with version
10.2.0-5 on my local Ubuntu system but not with version 10.2.0 on godbolt.org.

[Bug sanitizer/99814] regexec fails with -fsanitize=address

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Alex Richardson from comment #5)
> Does the sanitizer runtime library include the
> https://reviews.llvm.org/D96348 patch?
> 
> IMO the real issue is that dlsym() with RTLD_NEXT selects the oldest
> versioned symbol. Not sure why that behaviour was chosen.
> I'm sure there are lots of other sanitizer interceptors that are also
> affected by https://sourceware.org/bugzilla/show_bug.cgi?id=1319.

dlsym behavior matches the behavior of normal symbol lookup resolution.
When glibc (or some other libraries) started, it was unversioned and later
symbol versions were added to it.  When linking against the very old glibc,
libraries or binaries would use unversioned symbols and so that for ABI
compatibility naturally needs to be resolved against the oldest symbol version.
 Libraries/binaries linked against newer glibc versions then have versioned
symbols and use both the symbol name and symbol version in symbol lookup (i.e.
as dlvsym).
For dlsym, one doesn't really know in which era the library or binary has been
linked against and what it expects, it could be very old binary or newer or
most recent, and if the same symbol has multiple symbol versions, which one to
choose is unknown.  So, for symbols with more than one symbol version one
should use dlvsym instead of dlsym.
Ideally, libsanitizer shared libraries would be symbol versioned, for its own
APIs with some sanitizer specific symbol version(s), for the symbols it
intercepts from glibc with the symbol versions from glibc it was configured
against, and for symbols with multiple symbol versions one should have multiple
interceptors, which if they call the intercepted function should use dlvsym.
That would mean at library configure time scaning glibc symbol versions and
deciding on the *san version scripts and predefined macros based on that.

[Bug c++/99827] [10/11 Regression] [coroutines] co_await on function receiving initializer list of shared pointers causes ICE

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
  Known to work||10.2.0
  Known to fail||10.2.1, 11.0
 CC||iains at gcc dot gnu.org
   Last reconfirmed||2021-03-30
Summary|[coroutines] co_await on|[10/11 Regression]
   |function receiving  |[coroutines] co_await on
   |initializer list of shared  |function receiving
   |pointers causes ICE |initializer list of shared
   ||pointers causes ICE

--- Comment #1 from Jonathan Wakely  ---
Please provide the code here, not just a URL (as requested by
https://gcc.gnu.org/bugs which bugzilla asks you to read before creating a
bug).


#include 
#include 

// promise
struct promise {
  struct promise_type {
promise get_return_object() { return {}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {};
  };
};

// generate awaitable (1)
std::suspend_never func1(std::initializer_list>) { return
{}; }

// generate awaitable (2)
std::suspend_never func2(std::initializer_list) { return {}; }

promise task() {
  {
// produces a compiler error
co_await func1({ std::make_shared(1) });
  }

  {
// does not produce a compiler error
func1({ std::make_shared(1) });
  }

  {
// does not produce a compiler error
auto is = { std::make_shared(1) };
co_await func1(is);
  }

  {
// does not produce a compiler error
co_await func2({ 1 });
  }
}

int main() { task(); }


co.C: In function 'promise task()':
co.C:41:1: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:10106
   41 | }
  | ^
0x80cc4f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/jwakely/src/gcc/gcc/gcc/tree.c:9816
0x6178b5 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3393
0x6178b5 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:10106
0x9300a4 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2973
0x92fcb6 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2991
0x92fcb6 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2991
0x9314fb maybe_promote_temps
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3176
0x9314fb await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3681
0x137e72a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12101
0x931000 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3441
0x137e72a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12101
0x9316de await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3429
0x137e72a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12101
0x931000 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3441
0x137e72a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12101
0x137e8ce walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12449
0x931000 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3441
0x137e72a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.c:12101
0x9316de await_statement_

[Bug c/99826] GIMPLE FE fails to grok pointer declarators

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
__GIMPLE(ssa) char * foo(char *p) {..}

works for the first issue.  I failed to make the "late" __GIMPLE spec work in
a straight-forward manner.  I guess we might want to change the default dumping
to prefer the above order.

The 2nd issue remains and can be seen as

char * foo (char * p)
{
  char * _2;

   :
  _2_2 = p_1(D);
  return _2_2;

}

fixing it in a generic way will likely require exposing more of grokdeclarator
and eventually generating the SSA name there directly.  Limited support
is possible of course and the workaround is to declare a decl:

  char * q;

__BB(2):
  q_2 = p_1(D);
  return q_2;

which will work at the expense of creating a decl.

[Bug c++/99827] [10/11 Regression] [coroutines] co_await on function receiving initializer list of shared pointers causes ICE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Jakub Jelinek  ---
As a quick hack, we could do e.g.
--- gcc/configure.ac2021-03-23 19:42:05.417907561 +0100
+++ gcc/configure.ac2021-03-30 14:54:31.655766205 +0200
@@ -3404,12 +3404,15 @@ AC_DEFINE_UNQUOTED(HAVE_GAS_SHF_GNU_RETA
 # Test if the assembler supports the section flag 'o' for specifying
 # section with link-order.
 case "${target}" in
-  # Solaris may use GNU assembler with Solairs ld.  Even if GNU
+  # Solaris may use GNU assembler with Solaris ld.  Even if GNU
   # assembler supports the section flag 'o', it doesn't mean that
   # Solairs ld supports it.
   *-*-solaris2*)
 gcc_cv_as_section_link_order=no
 ;;
+  powerpc*-*-*)
+gcc_cv_as_section_link_order=no
+;;
   *)
 gcc_GAS_CHECK_FEATURE([section 'o' flag], gcc_cv_as_section_link_order,
   [2,35,0], [--fatal-warnings],
i.e. effectively revert H.J's patch for powerpc* targets.
That is a hack rather than proper solution.
For GCC11 we need some solution at least for the P1 regression, i.e. the
ELFv1 support that worked in the past and was broken by
r11-5656-g694d4a6d0c466d0fbc97920a9c6641a7b349ca35

[Bug c++/99823] -funroll-all-loops bugs when using contexpr variable

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
-funroll-all-loops applies to the RTL loop unroller, the GIMPLE level
concludes:

Estimating sizes for loop 1
 BB: 3, after_exit: 0
  size:   1 _1 = MEM[(int (*) (int) &)__for_begin_21];
  size:   5 _13 = _1 (s_20);
  size:   1 __for_begin_14 = __for_begin_21 + 8;
  size:   1 ivtmp_4 = ivtmp_11 - 1;
   Induction variable computation will be folded away.
  size:   2 if (ivtmp_4 != 0)
   Exit condition will be eliminated in peeled copies.
   Exit condition will be eliminated in last copy.
   Constant conditional.
 BB: 5, after_exit: 1
size: 10-3, last_iteration: 10-3
  Loop size: 10
  Estimated size after unrolling: 14
Not unrolling loop 1: contains call and code would grow.

so it concludes unrolling isn't profitable (but it would turn indirect into
direct calls).

[Bug fortran/99819] [9/10/11 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.4

[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
   Priority|P3  |P4

[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug target/99808] [8/9/10/11 Regression] ICE in as_a, at machmode.h:365

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:41d57b2a97c44ae7b0a5b01ae703a8f0d0495238

commit r11-7907-g41d57b2a97c44ae7b0a5b01ae703a8f0d0495238
Author: Kyrylo Tkachov 
Date:   Tue Mar 30 14:07:50 2021 +0100

aarch64: Fix gcc.target/aarch64/pr99808.c for ILP32

Fix test for -mabi=ilp32

gcc/testsuite/ChangeLog:

PR target/99808
* gcc.target/aarch64/pr99808.c: Use ULL constant suffix.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:6f93a7c7fc62b2d6ab47e5d5eb60d41366e1ee9e

commit r11-7908-g6f93a7c7fc62b2d6ab47e5d5eb60d41366e1ee9e
Author: Christophe Lyon 
Date:   Tue Mar 30 12:26:33 2021 +

arm: Fix emission of Tag_ABI_VFP_args with MVE and -mfloat-abi=hard (PR
target/99773)

When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
want to emit Tag_ABI_VFP_args even though we are not emitting
floating-point instructions (we need "+mve.fp" for that), because we
use MVE registers to pass FP arguments.

This patch removes the condition on (! TARGET_SOFT_FLOAT) because this
is a case where TARGET_SOFT_FLOAT is true, and TARGET_HARD_FLOAT_ABI
is true too.

2021-03-30  Richard Earnshaw  

gcc/
PR target/99773
* config/arm/arm.c (arm_file_start): Fix emission of
Tag_ABI_VFP_args attribute.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[clyon at gcc dot gnu.org via Gcc-bugs]

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #7 from Christophe Lyon  ---
Fixed

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #41 from Martin Jambor  ---
I reworked the series in order to avoid the biggest objection and posted them
as https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567471.html and
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567472.html

Because the first one is a bit disruptive, I do not think they are suitable for
stage4.  Therefore I suggest that in GCC 10 and 11 we paper over the issue with
the patch from comment #11 and in GCC 12 we fix this independently from DCE
pass with the referenced patches.

Sorry I could not come up with this earlier, it took me a lot of unsuccessful
attempts to get here.

[Bug c++/99827] [10/11 Regression] [coroutines] co_await on function receiving initializer list of shared pointers causes ICE

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
see 98056

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

[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||inf17092 at lehre dot 
dhbw-stuttga
   ||rt.de

--- Comment #6 from Iain Sandoe  ---
*** Bug 99827 has been marked as a duplicate of this bug. ***

[Bug lto/99828] New: inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99828
   Summary: inlining failed in call to ‘always_inline’ ‘memcpy’:
--param max-inline-insns-auto limit reached
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Noticed by Andi Kleen in kernel, reduced to:

$ cat 1.i
__attribute__((__always_inline__)) void *memcpy();
void *foo = memcpy;

$ touch 2.s
$ cat 3.i
int kasan_check_range();
int __memcpy();

enum { false, true }
memcpy(void *dest, void *src, long len) {
  if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0))
return __memcpy(dest, src, len);
}

int *LZ4_decompress_generic_outputSize_op;
int mlen;

LZ4_decompress_generic_outputSize_match() {
  {
__builtin_memcpy(LZ4_decompress_generic_outputSize_op,
 LZ4_decompress_generic_outputSize_match, mlen);
  }
}

$ gcc 1.i 2.s 3.i -c -flto -Os -shared && gcc [123].o -shared
1.i:1:42: warning: ‘always_inline’ function might not be inlinable
[-Wattributes]
1 | __attribute__((__always_inline__)) void *memcpy();
  |  ^~
3.i:5:1: warning: conflicting types for built-in function ‘memcpy’; expected
‘void *(void *, const void *, long unsigned int)’
[-Wbuiltin-declaration-mismatch]
5 | memcpy(void *dest, void *src, long len) {
  | ^~
3.i:1:1: note: ‘memcpy’ is declared in header ‘’
  +++ |+#include 
1 | int kasan_check_range();
3.i:13:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
   13 | LZ4_decompress_generic_outputSize_match() {
  | ^~~
1.i:1:42: warning: type of ‘memcpy’ does not match original declaration
[-Wlto-type-mismatch]
1 | __attribute__((__always_inline__)) void *memcpy();
  |  ^
3.i:5:1: note: return value type mismatch
5 | memcpy(void *dest, void *src, long len) {
  | ^
: warning: type of ‘__builtin_memcpy’ does not match original
declaration [-Wlto-type-mismatch]
3.i:5:1: note: return value type mismatch
3.i:5:1: note: ‘memcpy’ was previously declared here
3.i:5:1: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
3.i: In function ‘LZ4_decompress_generic_outputSize_match’:
1.i:1:42: error: inlining failed in call to ‘always_inline’ ‘memcpy’: --param
max-inline-insns-auto limit reached
1 | __attribute__((__always_inline__)) void *memcpy();
  |  ^
3.i:15:5: note: called from here
   15 | __builtin_memcpy(LZ4_decompress_generic_outputSize_op,
  | ^
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 tree-optimization/99825] [11 Regression] ICE in vect_build_combine_node

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:9c68e2abe294a48385224cd7617eca0720144b5c

commit r11-7909-g9c68e2abe294a48385224cd7617eca0720144b5c
Author: Tamar Christina 
Date:   Tue Mar 30 14:16:03 2021 +0100

slp: reject non-multiple of 2 laned SLP trees (PR99825)

TWO_OPERANDS allows any order or number of combinations of + and -
operations
but the pattern matcher only supports pairs of operations.

This patch has the pattern matcher for complex numbers reject SLP trees
where
the lanes are not a multiple of 2.

gcc/ChangeLog:

PR tree-optimization/99825
* tree-vect-slp-patterns.c (vect_check_evenodd_blend):
Reject non-mult 2 lanes.

gcc/testsuite/ChangeLog:

PR tree-optimization/99825
* gfortran.dg/vect/pr99825.f90: New test.

[Bug tree-optimization/99825] [11 Regression] ICE in vect_build_combine_node

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Fixed.

[Bug target/99829] New: MVE: ICE in lra_assign at -O3

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99829
   Summary: MVE: ICE in lra_assign at -O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ arm-eabi-gcc -c -xc++ gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c
-march=armv8.1-m.main+mve -mfloat-abi=hard -mtune=cortex-m7 -O3
during RTL pass: reload
In file included from gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c:5:
gcc/testsuite/c-c++-common/torture/vshuf-main.inc: In function 'int main()':
gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1: internal compiler
error: in lra_assign, at lra-assigns.c:1649
   26 | }
  | ^
0xe2d8fe lra_assign(bool&)
/home/alecop01/toolchain/src/gcc/gcc/lra-assigns.c:1649
0xe298f2 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2387
0xddb586 do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5835
0xddb586 execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:6021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

On the GCC 10 branch, we ICE even without the -mtune option (the default
scheduling for MVE changed for GCC 11).

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:5463cee277038df4688b61144db498ae7d24e631

commit r11-7910-g5463cee277038df4688b61144db498ae7d24e631
Author: H.J. Lu 
Date:   Tue Mar 23 20:04:58 2021 -0700

x86: Define __rdtsc and __rdtscp as macros

Define __rdtsc and __rdtscp as macros for callers with general-regs-only
target attribute to avoid inline failure with always_inline attribute.

gcc/

PR target/99744
* config/i386/ia32intrin.h (__rdtsc): Defined as macro.
(__rdtscp): Likewise.

gcc/testsuite/

PR target/99744
* gcc.target/i386/pr99744-1.c: New test.

[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization

--- Comment #1 from Richard Biener  ---
The issue is that we do not "merge" the attributes and the memcpy
definition lacks the always_inline attribute, somehow
expand_call_inline then picks up the decl with the attribute set.

I'd argue the 1.i TU is clearly invalid in taking the address of memcpy,
but we don't diagnose this.

How we manage to pick up the attribute in 3.i during WPA / LTRANS remains to be
analyzed.  But the "fix" is in the kernel.

[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

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

commit r11-7911-gf64b91568f3ac8f152c6c617b4fcc6b51da10ac4
Author: luo...@cn.ibm.com 
Date:   Fri Mar 26 22:26:57 2021 -0500

rs6000: Enable 32bit variable vec_insert [PR99718]

32bit and P7 VSX could also benefit a lot from the variable vec_insert
implementation with shift/insert/shift back method.

2011-03-29  Xionghu Luo  

PR target/99718
* config/rs6000/altivec.md (altivec_lvsl_reg): Change to ...
(altivec_lvsl_reg_): ... this.
(altivec_lvsr_reg): Change to ...
(altivec_lvsr_reg_): ... this.
* config/rs6000/predicates.md (vec_set_index_operand): New.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Enable 32bit variable vec_insert for all TARGET_VSX.
* config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9):
Enable 32bit variable vec_insert for p9 and above.
(rs6000_expand_vector_set_var_p8): Rename to ...
(rs6000_expand_vector_set_var_p7): ... this.
(rs6000_expand_vector_set): Use TARGET_VSX and adjust assert
position.
* config/rs6000/vector.md (vec_set): Use
vec_set_index_operand.
* config/rs6000/vsx.md (xl_len_r): Use gen_altivec_lvsl_reg_di and
gen_altivec_lvsr_reg_di.

gcc/testsuite/
PR target/99718
* gcc.target/powerpc/fold-vec-insert-char-p8.c: Update
instruction counts.
* gcc.target/powerpc/fold-vec-insert-char-p9.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-double.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-float-p8.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-float-p9.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-int-p8.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-int-p9.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-longlong.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-short-p8.c: Likewise.
* gcc.target/powerpc/fold-vec-insert-short-p9.c: Likewise.
* gcc.target/powerpc/pr79251.p8.c: Likewise.
* gcc.target/powerpc/pr79251.p9.c: Likewise.
* gcc.target/powerpc/vsx-builtin-7.c: Likewise.
* gcc.target/powerpc/pr79251-run.p7.c: New test.
* gcc.target/powerpc/pr79251.p7.c: New test.

[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-30
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Btw, one solution would be to drop __always_inline__ after always-inline
inlining
and thus make it reliably not present for IPA inlining.

__always_inline__ is a decl attribute and thus per call-stmt processing via
gimple_call_fntype doesn't work but instead this is subject to WPA cgraph
merging (I guess IPA inline still sees the unmerged cgraph).

[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Confirmed then.

[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Jakub Jelinek  ---
Another more targeted partial reversion:
2021-03-30  Jakub Jelinek  

* targhooks.h (default_print_patchable_function_entry_1): Declare.
* targhooks.c (default_print_patchable_function_entry_1): New function,
copied from default_print_patchable_function_entry with an added flags
argument.
(default_print_patchable_function_entry): Rewritten into a small
wrapper around default_print_patchable_function_entry_1.
* config/rs6000/rs6000.c (TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY):
Redefine.
(rs6000_print_patchable_function_entry): New function.

--- gcc/targhooks.h.jj  2021-01-04 10:25:39.665224403 +0100
+++ gcc/targhooks.h 2021-03-30 15:48:42.826706369 +0200
@@ -230,6 +230,9 @@ extern bool default_use_by_pieces_infras
bool);
 extern int default_compare_by_pieces_branch_ratio (machine_mode);

+extern void default_print_patchable_function_entry_1 (FILE *,
+ unsigned HOST_WIDE_INT,
+ bool, unsigned int);
 extern void default_print_patchable_function_entry (FILE *,
unsigned HOST_WIDE_INT,
bool);
--- gcc/targhooks.c.jj  2021-01-04 10:25:38.974232228 +0100
+++ gcc/targhooks.c 2021-03-30 15:51:22.924932795 +0200
@@ -1832,17 +1832,15 @@ default_compare_by_pieces_branch_ratio (
   return 1;
 }

-/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
-   entry.  If RECORD_P is true and the target supports named sections,
-   the location of the NOPs will be recorded in a special object section
-   called "__patchable_function_entries".  This routine may be called
-   twice per function to put NOPs before and after the function
-   entry.  */
+/* Helper for default_print_patchable_function_entry and other
+   print_patchable_function_entry hook implementations.  */

 void
-default_print_patchable_function_entry (FILE *file,
-   unsigned HOST_WIDE_INT patch_area_size,
-   bool record_p)
+default_print_patchable_function_entry_1 (FILE *file,
+ unsigned HOST_WIDE_INT
+ patch_area_size,
+ bool record_p,
+ unsigned int flags)
 {
   const char *nop_templ = 0;
   int code_num;
@@ -1864,9 +1862,6 @@ default_print_patchable_function_entry (
   patch_area_number++;
   ASM_GENERATE_INTERNAL_LABEL (buf, "LPFE", patch_area_number);

-  unsigned int flags = SECTION_WRITE | SECTION_RELRO;
-  if (HAVE_GAS_SECTION_LINK_ORDER)
-   flags |= SECTION_LINK_ORDER;
   switch_to_section (get_section ("__patchable_function_entries",
  flags, current_function_decl));
   assemble_align (POINTER_SIZE);
@@ -1883,6 +1878,25 @@ default_print_patchable_function_entry (
 output_asm_insn (nop_templ, NULL);
 }

+/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
+   entry.  If RECORD_P is true and the target supports named sections,
+   the location of the NOPs will be recorded in a special object section
+   called "__patchable_function_entries".  This routine may be called
+   twice per function to put NOPs before and after the function
+   entry.  */
+
+void
+default_print_patchable_function_entry (FILE *file,
+   unsigned HOST_WIDE_INT patch_area_size,
+   bool record_p)
+{
+  unsigned int flags = SECTION_WRITE | SECTION_RELRO;
+  if (HAVE_GAS_SECTION_LINK_ORDER)
+flags |= SECTION_LINK_ORDER;
+  default_print_patchable_function_entry_1 (file, patch_area_size, record_p,
+   flags);
+}
+
 bool
 default_profile_before_prologue (void)
 {
--- gcc/config/rs6000/rs6000.c.jj   2021-03-29 11:15:49.942202792 +0200
+++ gcc/config/rs6000/rs6000.c  2021-03-30 15:59:10.299755166 +0200
@@ -1341,6 +1341,9 @@ static const struct attribute_spec rs600
 #define TARGET_ASM_ASSEMBLE_VISIBILITY rs6000_assemble_visibility
 #endif

+#undef TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY
+#define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY
rs6000_print_patchable_function_entry
+
 #undef TARGET_SET_UP_BY_PROLOGUE
 #define TARGET_SET_UP_BY_PROLOGUE rs6000_set_up_by_prologue

@@ -14642,6 +14645,30 @@ rs6000_assemble_visibility (tree decl, i
 }
 #endif


+/* Write PATCH_AREA_SIZE NOPs into the asm outfile FILE around a function
+   entry.  If RECORD_P is true and the target supports named sections,
+   the location of the NOPs will be recorded in a special object section
+   called "__patchable_function_entries"

[Bug rtl-optimization/99830] New: [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 99830
   Summary: [11 Regression] ICE: in lra_eliminate_regs_1, at
lra-eliminations.c:659 with -O2
-fno-expensive-optimizations -fno-split-wide-types -g
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 50488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50488&action=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O2 -fno-expensive-optimizations
-fno-split-wide-types -g testcase.c
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in lra_eliminate_regs_1, at
lra-eliminations.c:659
6 | }
  | ^
0x73e41c lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:659
0xf16d42 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:602
0xf16b3c lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:503
0xf16ba9 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:507
0xf171ad lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:610
0xf16d42 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:602
0xf16ba9 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:507
0xf171ad lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:610
0xf183ff eliminate_regs_in_insn(rtx_insn*, bool, bool, poly_int<2u, long>)
/repo/gcc-trunk/gcc/lra-eliminations.c:1023
0xf18f9d process_insn_for_elimination
/repo/gcc-trunk/gcc/lra-eliminations.c:1333
0xf18f9d lra_eliminate(bool, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:1401
0xefa038 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2470
0xeab919 do_reload
/repo/gcc-trunk/gcc/ira.c:5835
0xeab919 execute
/repo/gcc-trunk/gcc/ira.c:6021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-7911-20210330134321-gf64b91568f3-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/11.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-7911-20210330134321-gf64b91568f3-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210330 (experimental) (GCC)

[Bug testsuite/91799] [10/11 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[seurer at gcc dot gnu.org via Gcc-bugs]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #12 from seurer at gcc dot gnu.org ---
fixed

[Bug c++/99831] New: ICE: in reshape_init, at cp/decl.c:6720

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99831
   Summary: ICE: in reshape_init, at cp/decl.c:6720
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This is a complicated one since I don't know how to reduce it.

https://godbolt.org/z/rqTGxMWef

#include 

template 
struct StringLiteral {
  constexpr StringLiteral(const char (&str)[N]) {
std::ranges::copy_n(str, N, value);
  }
  char value[N];
};

template 
struct string{
  constexpr bool operator==(const string&) const noexcept = default;
};

template 
constexpr auto operator+(string, string) {
  constexpr auto L3 = []{
constexpr auto size1 = sizeof(L1.value);
constexpr auto size2 = sizeof(L2.value);
char value[size1 + size2 - 1] = {};
std::ranges::sort(value);
std::ranges::copy_n(L1.value, size1, value);
std::ranges::copy_n(L2.value, size2, value + size1 - 1);
return StringLiteral{value};
  }();
  return string{};
}

static_assert(
  string<"hello, world">{} ==
  string<"hello">{} + string<", world">{}
);

static_assert(
  string<"a rose is a rose is a rose">{} ==
  string<"a rose">{} + string<" is ">{} + 
  string<"a rose">{} + string<" is ">{} + 
  string<"a rose">{}
);

:36:40: internal compiler error: in reshape_init, at cp/decl.c:6720
   36 |   string<"a rose is a rose is a rose">{} ==
  |^
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x6ba871 fancy_abort(char const*, int, char const*)
???:0
0x7810b6 reshape_init(tree_node*, tree_node*, int)
???:0
0x97e050 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-03-30
 Status|UNCONFIRMED |NEW

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Confirmed.  The REG_NOTE itself is easy to fix (I have a patch),
but then we run into similar problems because of the (correct-looking)
code added for PR77761.  Not sure what the best way out of this is.

[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
Note that if we comment one of the asserts, there will be no problem, or we
just comment the redundant std::ranges::sort.

[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed.

Breakpoint 1, fancy_abort (file=0x283d618
"/home/mpolacek/src/gcc/gcc/cp/decl.c", line=6720, 
function=0x28403ca "reshape_init") at
/home/mpolacek/src/gcc/gcc/diagnostic.c:1884
1884  if (global_dc->printer == NULL)
(gdb) up
#1  0x00b284fd in reshape_init (type=, 
init=, complain=3) at
/home/mpolacek/src/gcc/gcc/cp/decl.c:6720
6720  gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (init));
(gdb) p init
$1 = 

[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:19199a6f2b0f4ce4b100856c78706d56a16b1956

commit r11-7912-g19199a6f2b0f4ce4b100856c78706d56a16b1956
Author: Kyrylo Tkachov 
Date:   Tue Mar 30 15:43:36 2021 +0100

aarch64: PR target/99822 Don't allow zero register in first operand of
SUBS/ADDS-immediate

In this PR we end up generating an invalid instruction:
adds x1,xzr,#2

because the pattern accepts zero as an operand in the comparison, but the
instruction doesn't.
Fix it by adjusting the predicate and constraints.

gcc/ChangeLog:

PR target/99822
* config/aarch64/aarch64.md (sub3_compare1_imm): Do not allow
zero
in operand 1.

gcc/testsuite/ChangeLog:

PR target/99822
* gcc.c-torture/compile/pr99822.c: New test.

[Bug target/99822] [11 Regression] Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed.

[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||needs-reduction

--- Comment #3 from Marek Polacek  ---
Trying to reduce (--param ggc-min-heapsize=100 --param ggc-min-expand=10 seems
to help), but it'll take time.

[Bug target/98119] [10/11 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Boris Kolpackov  ---
I still get the same error if I move the inline function into an interface
partition (main.cxx is unchanged):

cat 

[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Thanks for looking at this.  I agree swapping the constraints for
operand 2 looks like the right fix, and brings it into line with
*add3_aarch64".  I think we need to swap operand 1 too
though, since Uai needs tied registers but Uav doesn't.

I'll test with that change overnight.

[Bug rtl-optimization/99560] aarch64: ICE (segfault) in LRA with SVE intrinsics

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Same -ftrapv problem as PR99540.

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

[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
*** Bug 99560 has been marked as a duplicate of this bug. ***

[Bug target/99252] SVE: ICE in maybe_legitimize_operand with LTO

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Confirmed to be the same problem as PR99216.

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

[Bug target/99216] ICE in aarch64_sve::function_expander::expand() with LTO

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
*** Bug 99252 has been marked as a duplicate of this bug. ***

[Bug target/99820] aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

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

commit r11-7913-gc277abd9cd3d10db59f9965d7d6356868da42a9f
Author: Kyrylo Tkachov 
Date:   Tue Mar 30 16:42:17 2021 +0100

aarch64: PR target/99820: Guard on available SVE issue info before using

This fixes a simple segfault ICE when using the use_new_vector_costs
tunable with a CPU tuning that it wasn't intended for.
I'm not adding a testcase here as we intend to remove the tunable for GCC
12 anyway (the new costing logic will remain and will benefit
from this extra check, but the -moverride option will no longer exist).

gcc/ChangeLog:

PR target/99820
* config/aarch64/aarch64.c (aarch64_analyze_loop_vinfo): Check for
available issue_info before using it.

[Bug target/99820] aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Fixed.