[Bug fortran/94030] ICE equivalence of an integer and an element of an array of size n

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-04
 CC||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started to ICE with r6-635-g9b7df66f80888ba9, before that the code was rejected
with:

   integer :: arr(n)
 1
Error: Variable ‘n’ at (1) in this context must be constant
pr94030.f90:5:17:

   equivalence (i, arr(1))
 1
Error: Array ‘arr’ at (1) with non-constant bounds cannot be an EQUIVALENCE
object

[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Sure, let me take a look.

[Bug bootstrap/94042] New: [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Bug ID: 94042
   Summary: [10 Regression] Bootstrap fails on ppc-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47973&action=edit
Build log

Doing bootstrap on ppc-linux-gnu I see many ICEs when building libsupc+:

[ 3338s] libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/./gcc/xgcc
-shared-libgcc
-B/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/./gcc
-nostdinc++
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/src
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/src/.libs
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux/include -isystem
/usr/powerpc64-suse-linux/sys-include -fno-checking
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/libstdc++-v3/../libgcc
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/powerpc64-suse-linux
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=bad_alloc.lo -O2 -D_FORTIFY_SOURCE=2
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -g -U_FORTIFY_SOURCE -D_GNU_SOURCE -c
../../../../libstdc++-v3/libsupc++/bad_alloc.cc  -fPIC -DPIC -D_GLIBCXX_SHARED
-o bad_alloc.o
...
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::integral_constant':
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:106:14:
  required from here
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:62:17:
internal compiler error: in iterative_hash_template_arg, at cp/pt.c:1915
[ 3338s]62 |   constexpr operator value_type() const noexcept { return
value; }
[ 3338s]   | ^~~~
[ 3338s] make[5]: *** [Makefile:762: bad_alloc.lo] Error 1

I can't reproduce that with a cross compiler and I noticed that one needs to
bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy
machine where I could reproduce that right now..

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Target||ppc-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-05
 CC||rguenth at gcc dot gnu.org
  Known to work||9.2.0
   Host||ppc-linux-gnu
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0
  Build||ppc-linux-gnu

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

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

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #47973|0   |1
is obsolete||

--- Comment #4 from Martin Liška  ---
Created attachment 47975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47975&action=edit
Build log

Sorry, this is the proper build log.

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Martin Liška from comment #1)
> > Created attachment 47974 [details]
> > Reduced test-case
> I doubt this is a reduced testcase.  It is a reduced testcase for the ICE
> but not the wrong code causing the ICE, see your comment below ...

Yes.

> 
> 
> (In reply to Martin Liška from comment #0)
> > I can't reproduce that with a cross compiler and I noticed that one needs
> > to bootstrap compiler.  --disable-bootstrap seems fine. I don't have a handy
> > machine where I could reproduce that right now..
> 
> So if you use --disable-bootstrap, did you run the testsuite?  That
> sometimes will find which testcase is producing wrong code now.
> The other way to find what is being miscompiled is bisect the commit which
> introduced the problem and then compare the .o files for the stage which is
> being compiled.  
> 

I would normally do that, but right now I only have a open build service worker
output. That's why I'm asking for help somebody how can run the bootstrap
locally. I hope IBM guys will help us.

[Bug c/94040] [9/10 Regression] ICE in get_constant, at c-family/c-format.c:325 (error: 'format' attribute argument 2 value '3' refers to parameter type 'int *')

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-05
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||8.4.0
   Target Milestone|--- |9.3
Summary|[10 Regression] ICE in  |[9/10 Regression] ICE in
   |get_constant, at|get_constant, at
   |c-family/c-format.c:325 |c-family/c-format.c:325
   |(error: 'format' attribute  |(error: 'format' attribute
   |argument 2 value '3' refers |argument 2 value '3' refers
   |to parameter type 'int *')  |to parameter type 'int *')
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r9-4163-g1d24950977c730f5.

[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug rtl-optimization/93996] [10 Regression] ICE in lookup_page_table_entry

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Andrew Pinski from comment #7)
> This seems to fix the issue (but I am not a scheduler expert and I am not
> 100% sure about it):
> diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
> index 1d3de7b6a76..9ca986eabdd 100644
> --- a/gcc/haifa-sched.c
> +++ b/gcc/haifa-sched.c
> @@ -4239,6 +4239,8 @@ remove_notes (rtx_insn *head, rtx_insn *tail)
>   if (insn != tail)
> {
>   remove_insn (insn);
> + if (NOTE_P (next) && NOTE_KIND (next) == NOTE_INSN_BASIC_BLOCK)
> +   next = NEXT_INSN (next);
>   add_reg_note (next, REG_SAVE_NOTE,
> GEN_INT (NOTE_INSN_EPILOGUE_BEG));
>   break;

There's one another test-case (also fixed with the suggested hunk):

$ ./gcc/xgcc -Bgcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr71727-2.c
-ftree-parallelize-loops=10 -O3 -fsched2-use-superblocks
--param=max-predicted-iterations=0 --param=parloops-min-per-thread=2 -c -S
during RTL pass: sched2
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr71727-2.c: In
function ‘foo._loopfn.0’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr71727-2.c:11:3:
internal compiler error: in safe_as_a, at is-a.h:210
   11 |   for (sum = 0, count = 0; count < length; count++) {
  |   ^
0xb32326 rtx_insn* safe_as_a(rtx_def*)
/home/marxin/Programming/gcc2/gcc/is-a.h:210
0xb31bb3 NEXT_INSN(rtx_insn const*)
/home/marxin/Programming/gcc2/gcc/rtl.h:1469
0x209466b schedule_ebb(rtx_insn*, rtx_insn*, bool)
/home/marxin/Programming/gcc2/gcc/sched-ebb.c:486
0x2094cb1 schedule_ebbs()
/home/marxin/Programming/gcc2/gcc/sched-ebb.c:655
0x11b703a rest_of_handle_sched2
/home/marxin/Programming/gcc2/gcc/sched-rgn.c:3744
0x11b7208 execute
/home/marxin/Programming/gcc2/gcc/sched-rgn.c:3882

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #10 from Martin Liška  ---
Ah, ok, I'm trying to reproduce that on power7 machine (gcc110 compile farm
box) with CC="gcc -m32" ...

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
I've got a patch candidate, testing right now.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-05
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7024-ge516294a1acb28aa.

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
I can reproduce it on GCC110 machine, let me bisect that and isolate a
test-case.

[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed for all releases.

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Jeffrey A. Law from comment #12)
> The way I've done ppc32 bootstraps is to have a 32bit root filesystem,
> installed on a 64bit system.  I then chroot into that 32bit root filesystem
> and I can do 32bit "native" builds at native speed.
> 
> I was doing this on Red Hat systems where I can sudo chroot :-)  I haven't
> tried it in the compile farm.

Thanks for hint.
Right now, I can reproduce it on powerpc64 system with -m32.

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

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

$ cat ./tmp0/024.ii
  template
struct __enable_if
{ };
  template
struct __enable_if
{ typedef _Tp __type; };

$ valgrind /tmp/cc1plus ./tmp0/024.ii
==25053== Memcheck, a memory error detector
==25053== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25053== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25053== Command: /tmp/cc1plus ./tmp0/024.ii
==25053== 
==25053== Invalid read of size 1
==25053==at 0x1048C3D0: convert_template_argument(tree_node*, tree_node*,
tree_node*, int, int, tree_node*) (in /tmp/cc1plus)
==25053==by 0x1048FBCF: coerce_template_parms(tree_node*, tree_node*,
tree_node*, int, bool, bool) (in /tmp/cc1plus)
==25053==by 0x10498E77: get_partial_spec_bindings(tree_node*, tree_node*,
tree_node*) (in /tmp/cc1plus)
==25053==by 0x104E9267: process_partial_specialization(tree_node*) (in
/tmp/cc1plus)
==25053==by 0x104EEA83: maybe_process_partial_specialization(tree_node*)
(in /tmp/cc1plus)
==25053==by 0x104168C7: cp_parser_class_specifier_1(cp_parser*) (in
/tmp/cc1plus)
==25053==by 0x104182EB: cp_parser_type_specifier(cp_parser*, int,
cp_decl_specifier_seq*, bool, int*, bool*) (in /tmp/cc1plus)
==25053==by 0x104196FB: cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) (in /tmp/cc1plus)
==25053==by 0x10451097: cp_parser_single_declaration(cp_parser*,
vec*, bool, bool, bool*) (in
/tmp/cc1plus)
==25053==by 0x1045156B:
cp_parser_template_declaration_after_parameters(cp_parser*, tree_node*, bool)
(in /tmp/cc1plus)
==25053==by 0x1045221B: cp_parser_explicit_template_declaration(cp_parser*,
bool) (in /tmp/cc1plus)
==25053==by 0x1045655B: cp_parser_declaration(cp_parser*) (in /tmp/cc1plus)
==25053==  Address 0x129f47c5 is not stack'd, malloc'd or (recently) free'd
==25053== 
./tmp0/024.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
./tmp0/024.ii:5:12:   required from here
./tmp0/024.ii:5:12: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~

[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||vmakarov at gcc dot gnu.org

--- Comment #15 from Martin Liška  ---
Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Martin Liška from comment #15)
> > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
> 
> This should just change the costs of the register usage.  Which means it
> might be a latent bug before this patch.

Yep. The miscompiled file is really cp/pt.c. The issue with the revision is
that the assembly of pt.o is completely different as a lower register is
preferred.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
I'll try to make part of the condition:

+ || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+ && best_hard_regno > hard_regno))

to be controllable by debug counter.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
Ok, using the following patch:

diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index 232b192..7e45e46 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -173,6 +173,7 @@ DEBUG_COUNTER (if_conversion_tree)
 DEBUG_COUNTER (ipa_sra_params)
 DEBUG_COUNTER (ipa_sra_retvalues)
 DEBUG_COUNTER (ira_move)
+DEBUG_COUNTER (irahonor)
 DEBUG_COUNTER (ivopts_loop)
 DEBUG_COUNTER (local_alloc_for_sched)
 DEBUG_COUNTER (match)
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index a2bf108..908c717 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ira-int.h"
 #include "reload.h"
 #include "cfgloop.h"
+#include "dbgcnt.h"

 typedef struct allocno_hard_regs *allocno_hard_regs_t;

@@ -1925,8 +1926,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
}
   if (min_cost > cost)
min_cost = cost;
+  bool honor = dbg_cnt(irahonor);
   if (min_full_cost > full_cost
- || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+ || (honor && !HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
  && best_hard_regno > hard_regno))
{
  min_full_cost = full_cost;

First bad: -fdbg-cnt=irahonor:788382
Last good: -fdbg-cnt=irahonor:788381

The change is only in function tsubst_template_arg:
diff -u /tmp/good.s /tmp/bad.s -U9
--- /tmp/good.s 2020-03-06 09:33:27.548791681 +0100
+++ /tmp/bad.s  2020-03-06 09:48:46.504419609 +0100
@@ -1,38 +1,37 @@
 mr. r7,r3
 beq 0x104c91x0 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 lhz r8,0(r7)
 addis   r9,r2,-128
 addir9,r9,29456
 rldicr  r8,r8,2,61
 lwzxr9,r9,r8
 cmpwi   r9,2
 beq 0x104c91x0 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 andi.   r9,r5,2
 addis   r9,r2,13
 addir9,r9,3152
-ld  r8,0(r9)
+stdur1,-128(r1)
+ld  r0,0(r9)
 bne 0x104c9160 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+160>
-std r31,-8(r1)
+std r31,120(r1)
 nop
 addir31,r2,22820
-cmpld   r7,r8
-stdur1,-128(r1)
+cmpld   r7,r0
 lwa r9,0(r31)
 addir10,r9,1
 stw r10,0(r31)
 beq 0x104c914x <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 mflrr0
 li  r7,1
 std r0,144(r1)
 bl  0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0>
 ld  r0,144(r1)
 lwz r9,0(r31)
-mr  r8,r3
 mtlrr0
 addir9,r9,-1
 extsw   r9,r9
-addir1,r1,128
 stw r9,0(r31)
-mr  r3,r8
-ld  r31,-8(r1)
+ld  r31,120(r1)
+mr  r3,r0
+addir1,r1,128
 blr

Optimized dump of the problematic function:

tsubst_template_arg (union tree_node * t, union tree_node * args,
tsubst_flags_t complain, union tree_node * in_decl)
{
  union tree_node * r;
  short unsigned int _1;
  int _2;
  tree_code_class _3;
  union tree_node * pretmp_14;
  int _15;
  int c_inhibit_evaluation_warnings.2997_16;
  int _17;
  int pretmp_18;
  union tree_node * _19;
  union tree_node * _21;
  int prephitmp_27;
  int _30;
  union tree_node * _34;

   [local count: 1073741823]:
  if (t_6(D) == 0B)
goto ; [30.00%]
  else
goto ; [70.00%]

   [local count: 751619280]:
  _1 = t_6(D)->base.code;
  _2 = (int) _1;
  _3 = tree_code_type[_2];
  if (_3 == 2)
goto ; [20.24%]
  else
goto ; [79.76%]

   [local count: 152127741]:
  r_12 = tsubst (t_6(D), args_9(D), complain_8(D), in_decl_10(D)); [tail call]
  goto ; [100.00%]

   [local count: 599491539]:
  _15 = complain_8(D) & 2;
  pretmp_14 = global_trees[0];
  if (_15 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 299745769]:
  c_inhibit_evaluation_warnings.2997_16 = c_inhibit_evaluation_warnings;
  _17 = c_inhibit_evaluation_warnings.2997_16 + 1;
  c_inhibit_evaluation_warnings = _17;
  if (t_6(D) == pretmp_14)
goto ; [30.95%]
  else
goto ; [69.05%]

   [local count: 299745769]:
  # _21 = PHI <_34(10), pretmp_14(6)>
  # prephitmp_27 = PHI <_30(10), c_inhibit_evaluation_warnings.2997_16(6)>
  c_inhibit_evaluation_warnings = prephitmp_27;

   [local count: 1073741824]:
  # r_5 = PHI 
  return r_5;

   [local count: 299745770]:
  if (t_6(D) == pretmp_14)
goto ; [30.95%]
  else
goto ; [69.05%]

   [local count: 206974454]:
  _34 = _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 (t_6(D), args_9(D),
complain_8(D), in_decl_10(D), 1);
  pretmp_18 = c_inhibit_evaluation_warnings;
  _30 = pretmp_18 + -1;
  goto ; [100.00%]

   [local count: 206974454]:
  _19 = _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 (t_6(D), args_9(D),
complain_8(D), in_decl_10(D), 1); [tail call]
  goto ; [100.00%]

}

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is used and that r0 is used for mtlr (moving back the return address).

Yes, I can confirm the $r0 is screwed. The value is equal in good/bad binary at
the beginning of the function:

(gdb) p /x $r0
$37 = 0x1049a3dc

good code stores:
0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std
r0,144(r1)
(gdb) p /x $r0
$38 = 0x104c9294

but the wrong one into a different memory address:
(gdb) p /x $r0
$28 = 0x104c92a4

So yes, $r0 is used first here in bad version here:
   │0x104c90f4 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+52>  ld 
r0,0(r9)

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
> 
> good code stores:
> 0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std
> r0,144(r1)
> (gdb) p   /x $r0
> $38 = 0x104c9294
> 
> but the wrong one into a different memory address:
> (gdb) p   /x $r0
> $28 = 0x104c92a4
> 

No this is correct, it's return value and it corresponds to backtraces:

#0  0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ ()
#1  0x104c9294 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ ()
#2  0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ ()

vs.

#0  0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ ()
#1  0x104c92a4 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ ()
#2  0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ ()

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is used and that r0 is used for mtlr (moving back the return address).

This is the correct explanation, thanks Adrew.

In good version
   │0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl 
0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0>

sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8):
(gdb) p /x $r3
$60 = 0x3fffaf3814d0

while in bad version we return value of:
   │0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlrr0
(gdb) p /x $r3
$31 = 0x104c92a4

which is the return address (can be seen in back-trace).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
Created attachment 47985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47985&action=edit
RTL dump files for the function - good

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
Created attachment 47984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47984&action=edit
RTL dump files for the function - bad

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #27 from Martin Liška  ---
@Segher: Any of -fno-shrink-wrap-separate, -fno-shrink-wrap removes the
problem.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
Created attachment 47990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47990&action=edit
Attempt to self-contained test-case

There's a PRE that needs to be triggered for error_mark_node and I was unable
to force it to do..

[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you see the same on llvm? Note that libsanitizer library is taken from
LLVM, so I would recommend to report that to upstream.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Last reconfirmed||2020-03-09

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-4929-g54aa6b58fe2fe73b.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
  Known to work||9.2.0
   Target Milestone|--- |10.0

[Bug analyzer/94099] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874 since r10-7023-g3d66e153b40ed000

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE in  |ICE in
   |make_region_for_unexpected_ |make_region_for_unexpected_
   |tree_code, at   |tree_code, at
   |analyzer/region-model.cc:48 |analyzer/region-model.cc:48
   |74  |74 since
   ||r10-7023-g3d66e153b40ed000
   Last reconfirmed||2020-03-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7023-g3d66e153b40ed000.

[Bug target/93800] [9 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[9/10 Regression] GCC adds  |[9 Regression] GCC adds
   |unwanted nops to align  |unwanted nops to align
   |loops on powerpc 8xx since  |loops on powerpc 8xx since
   |r9-1623 |r9-1623
  Known to work||9.2.1
  Known to fail|9.2.0   |

--- Comment #5 from Martin Liška  ---
Fixed on trunk so far.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #31 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #30)
> I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> toolchain).
> Martin, you have a working recipe?

Go to gcc110 machine and do:
$ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
--disable-lto
$ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #35 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to Martin Liška from comment #31)
> > (In reply to Segher Boessenkool from comment #30)
> > > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > > toolchain).
> > > Martin, you have a working recipe?
> > 
> > Go to gcc110 machine and do:
> > $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
> > --disable-lto
> > $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"
> 
> I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> but that builds stage2 as 64-bit?

Hm, that's possible. But the stage2 should not crash right?

> 
> Is that stage1 flags the secret sauce?

No that's not the secret sauce.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #40 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> > 
> > Hm, that's possible. But the stage2 should not crash right?
> 
> It doesn't work, of course (mixed 32-bit and 64-bit thing).
> 
> And I need a 32-bit stage2 in any case, to have a compiler that miscompiles
> pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use
> GPR0 somewhere it obviously is live.

Ok, I've just run the build on gcc110 machine and you take a look at
/tmp/build.log. You are right that, using CC="gcc -m32" will cause that stage1
compiler is a cross from powerpc to powerpc64.
The miscompiled compiler is stage2:

$ file ./xgcc
./xgcc: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped

and it ICEs on a simple test-case:

$ ./xgcc -B. /tmp/reduced.ii
/tmp/reduced.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
/tmp/reduced.ii:5:24:   required from here
/tmp/reduced.ii:5:24: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat /tmp/reduced.ii
  template
  struct __enable_if
  { };
template
struct __enable_if
{ typedef _Tp __type; };

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #41 from Martin Liška  ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32

that should also lead to the ICE. I'm checking that.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #43 from Martin Liška  ---
(In reply to Martin Liška from comment #41)
> Ok, the way how we build our compiler is to use:
> ./configure --with-cpu=default32
> 
> that should also lead to the ICE. I'm checking that.

So this one crashes for stage3 compiler as well:

$ ./gcc/xgcc -Bgcc /tmp/reduced.ii 
/tmp/reduced.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
/tmp/reduced.ii:5:24:   required from here
/tmp/reduced.ii:5:24: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~
0x10cbb63f crash_signal
../../gcc/toplev.c:328
0x1041f45c contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3391
...
$ cat stage_current
stage3
$ file ./gcc/xgcc
./gcc/xgcc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with unknown
capability 0x4100 = 0x11676e75, with unknown capability 0x1 = 0x90401,
not stripped

[Bug analyzer/94105] ICE in get_region, at analyzer/region-model.h:1744

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with r10-5950-g757bf1dff5e8cee3.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #45 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #44)
> So, with the reversion, can this be closed as FIXED?

I bet no. There's probably an underlying shrink-wrapping issue and Segher is
investigating that.

[Bug middle-end/94120] [OpenACC] ICE in gimplify_adjust_omp_clauses_1 for 'declare' for variable outside scope

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Just for the record, started to ICE with r6-4824-g6e232ba4246ca324.

[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
> So I think we instead should use abs_hwi (or absu_hwi, depending on if the
> most negative value can appear or not) instead of std::abs or abs in
> value-prof.c.

No, the counter can never be INT64_MIN.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #47 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #46)
> Thank you very much for that new testcase!  I wish I had it before :-)

Do you mean /tmp/reduced.ii ? Note that it's already mentioned in c#14.

> 
> Yesterday I found the problem.  It is in separate shrink-wrapping.  The
> fix is probably simple; hang on :-)

Great to hear that! Nice cooperation.

[Bug c++/94124] New: [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[marxin at gcc dot gnu.org]

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

Bug ID: 94124
   Summary: [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since
r10-6388-ge98ebda074bf8fc5
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

I found it in libqt5-qtlocation package:

$ cat circle.ii
template  struct A { typedef int _Type[_Nm]; };
template  struct B { typename A<_Nm>::_Type _M_elems; };
class C;
class D {
  D(C);
};
class F {
public:
  F(B<2>);
  F(D);
};
F fn1() { return {{{0}}}; }

$ g++ -c circle.ii
circle.ii: In function ‘F fn1()’:
circle.ii:12:24: error: conversion from ‘’ to
‘F’ is ambiguous
   12 | F fn1() { return {{{0}}}; }
  |^
circle.ii:10:3: note: candidate: ‘F::F(D)’
   10 |   F(D);
  |   ^
circle.ii:9:3: note: candidate: ‘F::F(B<2>)’
9 |   F(B<2>);
  |   ^

Note that clang is also happy about the code.

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.0
  Known to work||9.2.0
   Target Milestone|--- |10.0

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-03-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> You should report this to Ubuntu, I suspect a build problem there,
> eventually enabling zstd compression for gfortran-10 but zlib compression
> for gcc-10-offload-nvptx (I'm not sure we inter-operate here - Martin?)

Yes, I bet one of the compilers does not have enabled ZSTD compression.
You can see it with gcc -v:

$ gcc -v
...
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200310 (experimental) (GCC) 

Right now we should catch different compression algorithm:

void
lto_end_uncompression (struct lto_compression_stream *stream,
   lto_compression compression)
{
#ifdef HAVE_ZSTD_H
  if (compression == ZSTD)
{
  lto_uncompression_zstd (stream);
  return;
}
#endif
  if (compression == ZSTD)
internal_error ("compiler does not support ZSTD LTO compression");

  lto_uncompression_zlib (stream);
}

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
The provided files are not much useful. How difficult is building the Folly
from source. Can you please provide steps?

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
  Known to work||9.2.0
 Status|UNCONFIRMED |NEW
Summary|[10 Regression] ICE: tree   |[10 Regression] ICE: tree
   |check: expected |check: expected
   |integer_cst, have plus_expr |integer_cst, have plus_expr
   |in get_len, at tree.h:5927  |in get_len, at tree.h:5927
   ||since
   ||r10-2814-g22fca489eaf98f26
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r10-2814-g22fca489eaf98f26.

[Bug c++/94128] ICE on C++20 "requires requires" with lambda

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Version|unknown |10.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-11
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Is it really a valid code?
Started to ICE with r10-3735-gcb57504a55015891, before that we rejected the
code:

pr94128.cc:1:11: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts’
1 | void test(auto param)
  |   ^~~~
pr94128.cc:2:3: error: ‘requires’ only available with ‘-fconcepts’
2 |   requires requires{ { [](auto p){return p;}(param) }; };
  |   ^~~~
pr94128.cc:2:12: error: ‘requires’ was not declared in this scope
2 |   requires requires{ { [](auto p){return p;}(param) }; };
  |^~~~
pr94128.cc: In function ‘void test(auto:1)’:
pr94128.cc:2:52: error: expected ‘;’ before ‘}’ token
2 |   requires requires{ { [](auto p){return p;}(param) }; };
  |^~

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Laurent Stacul from comment #5)
> I forgot to remove some arguments in the command:
> 
> /opt/1A/toolchain/x86_64-v20/bin/g++ \
> -O3 -Wl,-flto -ffat-lto-objects -fuse-linker-plugin \
> CacheLocalityTest.cpp.o  -o cache_locality_test -L. libfolly.so -pthread

Ok, so please provide pre-processed source file for CacheLocalityTest.cpp.o.
Just add -E option to command line.

[Bug testsuite/94036] [9 regression] gcc.target/powerpc/pr72804.c fails

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
commit r9-8357-g85c08558c66dd8e2000a4ad282ca03368028fce3
Author: Xionghu Luo 
Date:   Mon Mar 9 20:25:20 2020 -0500

Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c

Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
Tested pass on P9/P8/P7.
(gcc-8 is not needed as the test doesn't exists.)

P9LE generated instruction is not worse than P8LE.
mtvsrdd;xxlnot;stxv vs. not;not;std;std.
It can have longer latency, but latency via memory is not so critical,
and this does save decode and other resources.  It's hard to choose
which is best.  Update the test case to fix failures.

gcc/testsuite/ChangeLog:

2020-03-10  Luo Xiong Hu  

backport from master.
PR testsuite/94036

2019-12-02  Luo Xiong Hu  

PR testsuite/92398
* gcc.target/powerpc/pr72804.c: Split the store function to...
* gcc.target/powerpc/pr92398.h: ... this one.  New.
* gcc.target/powerpc/pr92398.p9+.c: New.
* gcc.target/powerpc/pr92398.p9-.c: New.
* lib/target-supports.exp (check_effective_target_p8): New.
(check_effective_target_p9+): New.

[Bug middle-end/93961] gnat.dg/lto24.adb FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
commit r10-7125-ge835226bab5b3575c8a55c048dcfed3d4cde5e0e
Author: Eric Botcazou 
Date:   Wed Mar 11 11:29:39 2020 +0100

Fix GIMPLE verification failure in LTO mode on Ada code

The issue is that tree_is_indexable doesn't return the same result for
a FIELD_DECL with QUAL_UNION_TYPE and the QUAL_UNION_TYPE, resulting
in two instances of the QUAL_UNION_TYPE in the bytecode.  The result
for the type is the correct one (false, since it is variably modified)
while the result for the field is falsely true because:

  else if (TREE_CODE (t) == FIELD_DECL
   && lto_variably_modified_type_p (DECL_CONTEXT (t)))
return false;

is not satisfied.  The reason for this is that the DECL_QUALIFIER of
fields of a QUAL_UNION_TYPE depends on a discriminant in Ada, which
means that the size of the type does too (CONTAINS_PLACEHOLDER_P),
which in turn means that it is reset to a mere PLACEHOLDER_EXPR by
free_lang_data, which finally means that the size of DECL_CONTEXT is
too, so RETURN_TRUE_IF_VAR is false.

In other words, the CONTAINS_PLACEHOLDER_P property of the DECL_QUALIFIER
of fields of a QUAL_UNION_TYPE hides the variably_modified_type_p property
of  these fields, if you look from the outside.

PR middle-end/93961
* tree.c (variably_modified_type_p) : Recurse into
fields whose type is a qualified union.

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #13 from Martin Liška  ---
commit r9-8357-g85c08558c66dd8e2000a4ad282ca03368028fce3
Author: Xionghu Luo 
Date:   Mon Mar 9 20:25:20 2020 -0500

Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c

Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
Tested pass on P9/P8/P7.
(gcc-8 is not needed as the test doesn't exists.)

P9LE generated instruction is not worse than P8LE.
mtvsrdd;xxlnot;stxv vs. not;not;std;std.
It can have longer latency, but latency via memory is not so critical,
and this does save decode and other resources.  It's hard to choose
which is best.  Update the test case to fix failures.

gcc/testsuite/ChangeLog:

2020-03-10  Luo Xiong Hu  

backport from master.
PR testsuite/94036

2019-12-02  Luo Xiong Hu  

PR testsuite/92398
* gcc.target/powerpc/pr72804.c: Split the store function to...
* gcc.target/powerpc/pr92398.h: ... this one.  New.
* gcc.target/powerpc/pr92398.p9+.c: New.
* gcc.target/powerpc/pr92398.p9-.c: New.
* lib/target-supports.exp (check_effective_target_p8): New.
(check_effective_target_p9+): New.

[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
commit r10-7123-g42bc589e87a326282be2156ddeb18588677c645d
Author: Jakub Jelinek 
Date:   Wed Mar 11 10:54:22 2020 +0100

aarch64: Fix ICE in aarch64_add_offset_1 [PR94121]

abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the
(invalid) testcase shows, the function can be called with such an offset.
The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows
even
that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN
in that case.  The function then uses moffset in two spots which wouldn't
care if the value is (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN or
HOST_WIDE_INT_MIN and wouldn't accept it (!moffset and
aarch64_uimm12_shift (moffset)), then in one spot where the signedness of
moffset does matter and using unsigned is the right thing -
moffset < 0x100 - and finally has code which will handle even this
value right; the assembler doesn't really care for DImode immediates if
mov x1, -9223372036854775808
or
mov x1, 9223372036854775808
is used and similarly it doesn't matter if we add or sub it in DImode.

2020-03-11  Jakub Jelinek  

PR target/94121
* config/aarch64/aarch64.c (aarch64_add_offset_1): Use absu_hwi
instead of abs_hwi, change moffset type to unsigned HOST_WIDE_INT.

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

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
commit r10-7115-gdf15a82804e1f7f4a7432670b33387779de46549
Author: Jason Merrill 
Date:   Tue Mar 10 17:51:46 2020 -0400

c++: Fix ICE with omitted template args [PR93956].

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A.  maybe_aggr_guide should also use that test.

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

PR c++/93956
* pt.c (maybe_aggr_guide): Check BRACE_ENCLOSED_INITIALIZER_P.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
commit r10-7114-g37e0df8a9be5a8232f4ccb73cdadb02121ba523f
Author: Jiufu Guo 
Date:   Tue Mar 10 13:51:57 2020 +0800

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

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

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

gcc/
2020-03-10  Jiufu Guo  

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

gcc/testsuite
2020-03-10  Jiufu Guo  

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

[Bug c++/94117] deferred noexcept specifications and friend fns

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
commit r10-7103-gc222eabcf8be0e3f644e4bd4c3316b40dba4b514
Author: Jonathan Wakely 
Date:   Tue Mar 10 10:50:40 2020 +

libstdc++: Fix invalid noexcept-specifier (PR 94117)

G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.

PR c++/94117
* include/std/ranges
(ranges::transform_view::_Iterator::iter_move):
Change expression in noexcept-specifier to match function body.

[Bug target/90763] PowerPC vec_xl_len should take const

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
commit r10-7109-ge00cb200f39d8144de226e76c5d0257b613dbbf6
Author: Will Schmidt 
Date:   Tue Mar 10 14:38:13 2020 -0500

PR90763: PowerPC vec_xl_len should take const argument.

PR target/90763
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Add
clause to handle P9V_BUILTIN_VEC_LXVL with const arguments.

* gcc.target/powerpc/pr90763.c: New.

[Bug testsuite/94023] [9 regression] gcc.dg/vect/slp-perm-12.c fails starting with r9-5008

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7083-gd5114529228f97c2a433fa72ddea3fadeb6465b3
Author: Kewen Lin 
Date:   Sun Mar 8 21:34:13 2020 -0500

[testsuite] Fix PR94023 to guard case under vect_hw_misalign

As PR94023 shows, the expected SLP requires misaligned vector access
support.  This patch is to guard the check under the target condition
vect_hw_misalign to ensure that.

gcc/testsuite/ChangeLog

2020-03-09  Kewen Lin  

PR testsuite/94023
* gcc.dg/vect/slp-perm-12.c: Expect loop vectorized messages only on
vect_hw_misalign targets.

[Bug target/94095] Modifier 'a' do not work as described

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
commit r10-7092-ga931bb50fe77446058166b50eea4e53223ad7ef7
Author: Andrew Pinski 
Date:   Mon Mar 9 09:45:23 2020 -0700

Fix 'A' operand modifier: PR inline-asm/94095

The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.

Committed as obvious.

2020-03-09  Andrew Pinski  

PR inline-asm/94095
* doc/extend.texi (x86 Operand Modifiers): Fix column
for 'A' modifier.

[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
commit r10-7095-gea182fe63634bb5b7913b3f1b6846e1900c5e0c4
Author: Jonathan Wakely 
Date:   Mon Mar 9 23:22:57 2020 +

libstdc++: Handle type-changing path concatenations (PR 94063)

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.

PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge
to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

[Bug rtl-optimization/93564] [10 Regression] 470.lbm regresses by 25% on znver2 with -Ofast -march=native LTO and PGO since r10-6384-g2a07345c4f8dabc2

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
commit r10-7093-g5dc1390b41db5c1765e25fd21dad1a930a015aac
Author: Vladimir N. Makarov 
Date:   Mon Mar 9 14:05:09 2020 -0400

Revert: One more patch for PR93564: Prefer smaller hard regno when we do
not honor reg alloc order.

2020-03-09  Vladimir Makarov  

Revert:

2020-02-28  Vladimir Makarov  

PR rtl-optimization/93564
* ira-color.c (assign_hard_reg): Prefer smaller hard regno when we
do not honor reg alloc order.

[Bug testsuite/94019] [9 regression] gcc.dg/vect/vect-over-widen-17.c fails starting with g:370c2ebe8fa20e0812cd2d533d4ed38ee2d37c85, r9-1590

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7084-gcb2c60206f4f2218f84ccde21663b00de068d8c7
Author: Kewen Lin 
Date:   Sun Mar 8 21:55:11 2020 -0500

[testsuite] Fix PR94019 to check vector char when vect_hw_misalign

As PR94019 shows, without misaligned vector access support but with
realign load, the vectorized loop will end up with realign scheme.
It generates mask (control vector) with return type vector signed
char which breaks the not check.

gcc/testsuite/ChangeLog

2020-03-09  Kewen Lin  

PR testsuite/94019
* gcc.dg/vect/vect-over-widen-17.c: Don't expect vector char if
it's without misaligned vector access support.

[Bug c++/93729] [concepts] binding bit-field to lvalue reference in requires expression should be SFINAE

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
commit r10-7080-g5e1b4e60c1823115ba7ff0e8c4b35f6058ad9969
Author: Patrick Palka 
Date:   Tue Mar 3 12:27:33 2020 -0500

c++: Fix missing SFINAE when binding a bit-field to a reference (PR 93729)

We are unconditionally emitting an error here, without first checking
complain.

gcc/cp/ChangeLog:

PR c++/93729
* call.c (convert_like_real): Check complain before emitting an
error
about binding a bit-field to a reference.

gcc/testsuite/ChangeLog:

PR c++/93729
* g++.dg/concepts/pr93729.C: New test.

[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
commit r10-7074-g191bcd0f30dd37dec773efb0125afdcae9bd90ef
Author: Nathan Sidwell 
Date:   Fri Mar 6 10:51:26 2020 -0800

Fix mangling ICE [PR94027]

PR c++/94027
* mangle.c (find_substitution): Don't call same_type_p on template
args that cannot match.

Now same_type_p rejects argument packs, we need to be more careful
calling it with template argument vector contents.

The mangler needs to do some comparisons to find the special
substitutions.  While that code looks a little ugly, this seems the
smallest fix.

[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #29 from Martin Liška  ---
commit r10-7078-g6733ecaf3fe77871d86bfb36bcda5497ae2aaba7
Author: H.J. Lu 
Date:   Sun Mar 8 05:01:03 2020 -0700

gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c"

PR target/89229
PR target/89346
* gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c", instead
of "pr89229-5a.c".

[Bug target/91598] [8/9 regression] 60% speed drop on neon intrinsic loop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
commit r10-7073-g0b8393221177617f19e7c5c5c692b8c59f85fffb
Author: Wilco Dijkstra 
Date:   Fri Mar 6 18:29:02 2020 +

[AArch64] Use intrinsics for widening multiplies (PR91598)

Inline assembler instructions don't have latency info and the scheduler
does
not attempt to schedule them at all - it does not even honor latencies of
asm source operands.  As a result, SIMD intrinsics which are implemented
using
inline assembler perform very poorly, particularly on in-order cores.
Add new patterns and intrinsics for widening multiplies, which results in a
63% speedup for the example in the PR, thus fixing the reported regression.

gcc/
PR target/91598
* config/aarch64/aarch64-builtins.c (TYPES_TERNOPU_LANE): Add
define.
* config/aarch64/aarch64-simd.md
(aarch64_vec_mult_lane): Add new insn for widening lane
mul.
(aarch64_vec_mlal_lane): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Add intrinsics.
* config/aarch64/arm_neon.h:
(vmlal_lane_s16): Expand using intrinsics rather than inline asm.
(vmlal_lane_u16): Likewise.
(vmlal_lane_s32): Likewise.
(vmlal_lane_u32): Likewise.
(vmlal_laneq_s16): Likewise.
(vmlal_laneq_u16): Likewise.
(vmlal_laneq_s32): Likewise.
(vmlal_laneq_u32): Likewise.
(vmull_lane_s16): Likewise.
(vmull_lane_u16): Likewise.
(vmull_lane_s32): Likewise.
(vmull_lane_u32): Likewise.
(vmull_laneq_s16): Likewise.
(vmull_laneq_u16): Likewise.
(vmull_laneq_s32): Likewise.
(vmull_laneq_u32): Likewise.
* config/aarch64/iterators.md (Vcondtype): New iterator for lane
mul.
(Qlane): Likewise.

[Bug target/89346] Unnecessary EVEX encoding

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
commit r10-7078-g6733ecaf3fe77871d86bfb36bcda5497ae2aaba7
Author: H.J. Lu 
Date:   Sun Mar 8 05:01:03 2020 -0700

gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c"

PR target/89229
PR target/89346
* gcc.target/i386/pr89229-3c.c: Include "pr89229-3a.c", instead
of "pr89229-5a.c".

[Bug driver/93645] Support -fuse-ld=/absolute/path/to/ld

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
   Last reconfirmed||2020-03-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Version|unknown |10.0
 CC||marxin at gcc dot gnu.org
   Keywords||patch

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Matthias Klose from comment #3)
> $ gfortran-10 -v -fopenacc program.f90 2>&1 |grep zstd
> Supported LTO compression algorithms: zlib zstd
> Supported LTO compression algorithms: zlib zstd
> 
> afaics both builds are correctly configured.

Then you can dump lto header in a .o file:

$ gcc -flto -c bss.c
$ readelf -SW bss.o  | grep lto_.lto
  [ 6] .gnu.lto_.lto.2cfeb5fb4c8095f PROGBITS 62
08 00   E  0   0  1

$ objdump -s -j .gnu.lto_.lto.2cfeb5fb4c8095f bss.o

bss.o: file format elf64-x86-64

Contents of section .gnu.lto_.lto.2cfeb5fb4c8095f:
  0900 01000100

that ending 0100 is zstd == 1.

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Laurent Stacul from comment #7)
> Created attachment 48019 [details]
> preprocessed sources

Thanks and last missing piece is command line how lityTest.cpp.o is compiled?

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Ok, I see in the .s file:

$ grep _ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE
cache_locality_test.ltrans0.s
leaq_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE@tpoff, %rbp
leaq_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE@tpoff, %rbx

So the symbols is a TLS static variable:
$ grep cpuCache *.ii
  static __thread CpuCache cpuCache;

Can you please reduce the .ii file with creduce:
https://gcc.gnu.org/bugs/minimize.html
?

That should be doable by grepping for the:
 unresolvable R_X86_64_TPOFF32 relocation against symbol
`_ZN5folly14AccessSpreaderISt6atomicE8cpuCacheE'

error message.

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Good, now I can see a similar issue:

$ gcc  -o cache_locality_test -L. libfolly.so -pthread CacheLocalityTest.o
-shared
/usr/bin/ld: /tmp/cache_locality_test.Kz3DE7.ltrans0.ltrans.o: relocation
R_X86_64_TPOFF32 against `_ZL10testingCpu' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

and I can confirm adding -fPIC helps.

[Bug c++/93907] [10 Regression] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
commit r10-7135-g690de2b706baaec628b7534a82f7feb1c42df3b5
Author: Jakub Jelinek 
Date:   Thu Mar 12 01:28:55 2020 +0100

testsuite: Fix concepts-using2.C failure on 32-bit targets [PR93907]

The test FAILs on 32-bit targets that don't have __int128 type.

2020-03-12  Jakub Jelinek  

PR c++/93907
* g++.dg/cpp2a/concepts-using2.C (cc): Use long long instead of
__int128 if __SIZEOF_INT128__ isn't defined.

[Bug c++/94124] [10 Regression] conversion from ‘’ to ‘F’ is ambiguous since r10-6388-ge98ebda074bf8fc5

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
commit r10-7139-g4069adf4bbc90d16b603e0308b48499c36b2b637
Author: Jakub Jelinek 
Date:   Thu Mar 12 08:28:05 2020 +0100

c++: Tweak reshape_init_array_1 [PR94124]

Isn't it wasteful to first copy perhaps a large constructor (recursively)
and then truncate it to very few elts (zero in this case)?

> We should certainly avoid copying if they're the same.  The code above
for
> only copying the bits that aren't going to be thrown away seems pretty
> straightforward, might as well use it even if the savings aren't likely
to
> be large.

Calling vec_safe_truncate with the same number of elts the vector already
has is a nop, so IMHO we just should make sure we only unshare if it
changed.

2020-03-12  Jakub Jelinek  

PR c++/94124
* decl.c (reshape_init_array_1): Don't unshare constructor if there
aren't any trailing zero elts, otherwise only unshare the first
nelts.

[Bug c++/93907] [10 Regression] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
commit r10-7133-gbde31a76ba48be49dbe26317ce5e19d10ae9f310
Author: Jason Merrill 
Date:   Wed Mar 11 00:53:01 2020 -0400

c++: Fix ICE with concepts and aliases [PR93907].

The problem here was that we were checking satisfaction once with 'e', a
typedef of 'void', and another time with 'void' directly, and treated them
as different for hashing based on the assumption that
canonicalize_type_argument would have already removed a typedef that wasn't
a complex dependent alias.  But that wasn't happening here, so let's add a
call.

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

PR c++/93907
* constraint.cc (tsubst_parameter_mapping): Canonicalize type
argument.

[Bug c/94151] New: test

[marxin at gcc dot gnu.org]

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

Bug ID: 94151
   Summary: test
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

[Bug middle-end/94146] [10 Regression] Merging functions with same bodies stopped working

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Yes, ICF wrappers can be inlined back and that's what happened here since
r10-3583-g562d1e9556777988.
I don't see what's problematic here?

[Bug lto/94150] Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
You can probably use -fdump-ipa-cgraph where you will see object files:
...
  Read from file: pr91307-1.o
...

[Bug target/93800] [9 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
commit r9-8363-g716cc43745fb11ea883684d55e62fe2c1694902b
Author: Martin Liska 
Date:   Thu Mar 12 13:36:17 2020 +0100

Backport 314b91220a07bd63f13c58e37f1b5b9430a3702b

Backport from mainline
2020-03-09  Martin Liska  

PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.
Backport from mainline
2020-03-09  Martin Liska  

PR target/93800
* gcc.target/powerpc/pr93800.c: New test.

[Bug target/93800] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail|9.2.0   |
  Known to work||9.3.1
 Status|ASSIGNED|RESOLVED
Summary|[9 Regression] GCC adds |GCC adds unwanted nops to
   |unwanted nops to align  |align loops on powerpc 8xx
   |loops on powerpc 8xx since  |since r9-1623
   |r9-1623 |

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
commit r10-7143-g54f46d82f54ba7a4110cef102b7c18eaf8b4b6bd
Author: H.J. Lu 
Date:   Thu Mar 12 03:47:45 2020 -0700

i386: Use ix86_output_ssemov for MMX TYPE_SSEMOV

There is no need to set mode attribute to XImode since ix86_output_ssemov
can properly encode xmm16-xmm31 registers with and without AVX512VL.

PR target/89229
* config/i386/i386.c (ix86_output_ssemov): Handle MODE_DI,
MODE_V1DF and MODE_V2SF.
* config/i386/mmx.md (MMXMODE:*mov_internal): Call
ix86_output_ssemov for TYPE_SSEMOV.  Remove ext_sse_reg_operand
check.

[Bug tree-optimization/94130] [8/9 Regression] Unintended result with optimization option when assigning two structures, memset and 0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
commit r10-7140-g349ab34dc64a10fe0b1eda66d13b62862878b73e
Author: Jakub Jelinek 
Date:   Thu Mar 12 09:34:00 2020 +0100

tree-dse: Fix mem* head trimming if call has lhs [PR94130]

As the testcase shows, if DSE decides to head trim
{mem{set,cpy,move},strncpy}
and the call has lhs, it is incorrect to leave the lhs as is, because it
will then point to the adjusted address (base + head_trim) instead of the
original base.
The following patch fixes that by dropping the lhs of the call and
assigning
lhs the original base in a following statement.

2020-03-12  Jakub Jelinek  

PR tree-optimization/94130
* tree-ssa-dse.c: Include gimplify.h.
(increment_start_addr): If stmt has lhs, drop the lhs from call and
set it after the call to the original value of the first argument.
Formatting fixes.
(decrement_count): Formatting fix.

* gcc.c-torture/execute/pr94130.c: New test.

[Bug c++/94153] internal compiler error: in cp_lexer_new_from_tokens, at cp/parser.c:700

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Well, it's ICE on invalid code which is very common case.
Was the original file a valid code?

[Bug target/94103] Wrong optimization: reading value of a variable changes its representation for optimizer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
commit r10-7145-g1dc00a8ec9aeba86b74b16bff6f171824bb7b4a1
Author: Richard Biener 
Date:   Thu Mar 12 14:18:35 2020 +0100

tree-optimization/94103 avoid CSE of loads with padding

VN currently replaces a load of a 16 byte entity 128 bits of precision
(TImode) with the result of a load of a 16 byte entity with 80 bits of
mode precision (XFmode).  That will go downhill since if the padding
bits are not actually filled with memory contents those bits are
missing.

2020-03-12  Richard Biener  

PR tree-optimization/94103
* tree-ssa-sccvn.c (visit_reference_op_load): Avoid type
punning when the mode precision is not sufficient.

* gcc.target/i386/pr94103.c: New testcase.

[Bug c++/94153] [8/9/10 Regression] internal compiler error: in cp_lexer_new_from_tokens, at cp/parser.c:700

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Slava Barinov from comment #3)
> (In reply to Martin Liška from comment #1)
> > Well, it's ICE on invalid code which is very common case.
> Hm. So no need to report them? 

Well, we have a bazillion of such error recovery issues for C++.

[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
@Richi: Can you please enable zstd for our nvptx cross compiler:

$ x86_64-suse-linux-accel-nvptx-none-gcc-10 -v
...
Supported LTO compression algorithms: zlib

We'll need to add
BuildRequires: libzstd-devel

into cross spec file.

[Bug lto/94157] New: [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack

[marxin at gcc dot gnu.org]

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

Bug ID: 94157
   Summary: [10 Regression] error: lto-wrapper failed with
-Wa,--noexecstack  -Wa,--noexecstack
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Using gcc10 package I see a strange error:

$ echo "int main() {}" > x.c
$ gcc -flto -c x.c
$ gcc -Wa,--noexecstack  -Wa,--noexecstack   x.o
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ gcc -Wa,--noexecstack x.o
[fine]

I can't reproduce that with locally built GCC and gcc9 package seems fine.

[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Ok, I can reproduce that now..

[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10 Regression] error:  |[10 Regression] error:
   |lto-wrapper failed with |lto-wrapper failed with
   |-Wa,--noexecstack   |-Wa,--noexecstack
   |-Wa,--noexecstack   |-Wa,--noexecstack since
   ||r10-6807-gf1a681a174cdfb82

--- Comment #2 from Martin Liška  ---
Started with r10-6807-gf1a681a174cdfb82. One can reproduce with:

$ gcc foo.c -c -flto && gcc -fPIE -Wa,--noexecstack -Wa,--noexecstack foo.o -o
a.out -Wa,--execstack  -Wa,--execstack -Wa,--execstack -Wa,--execstack
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

==14211== Invalid write of size 1
==14211==at 0x483B98C: strcat (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14211==by 0x408A08: run_gcc(unsigned int, char**) (lto-wrapper.c:1320)
==14211==by 0x4057C5: main (lto-wrapper.c:1981)
==14211==  Address 0x1fff001000 is not stack'd, malloc'd or (recently) free'd

[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Version|9.0 |10.0
 CC||prathamesh3492 at gcc dot 
gnu.org
   Priority|P3  |P1

[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
commit r9-8364-g08f00a213f8a1b99bbf3ad3c337dea249a288cf1
Author: Richard Earnshaw 
Date:   Fri Mar 6 10:04:51 2020 +

arm: correct constraints on movsi_compare0 [PR91913]

The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states.  That instruction lacks support for SP which is
permitted in Arm state, but has restrictions in Thumb2 code.

This patch fixes the problem by allowing SP when in ARM state for all
registers; in Thumb state it allows SP only as a source when the
register really is copied to another target.

gcc/ChangeLog:
PR target/91913
Backport from master
* config/arm/arm.md (movsi_compare0): Allow SP as a source register
in Thumb state and also as a destination in Arm state.  Add T16
variants.

gcc/testsuite/ChangeLog:
2020-02-10  Jakub Jelinek  

PR target/91913
Backport from master
* gfortran.dg/pr91913.f90: New test.

[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
commit r8-10119-g3d46f4875c6c50e8095294b6b700d6678a7e2f1e
Author: Richard Earnshaw 
Date:   Fri Mar 6 10:04:51 2020 +

arm: correct constraints on movsi_compare0 [PR91913]

The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states.  That instruction lacks support for SP which is
permitted in Arm state, but has restrictions in Thumb2 code.

This patch fixes the problem by allowing SP when in ARM state for all
registers; in Thumb state it allows SP only as a source when the
register really is copied to another target.

gcc/ChangeLog:
PR target/91913
Backport from master
* config/arm/arm.md (movsi_compare0): Allow SP as a source register
in Thumb state and also as a destination in Arm state.  Add T16
variants.

gcc/testsuite/ChangeLog:
2020-02-10  Jakub Jelinek  

PR target/91913
Backport from master
* gfortran.dg/pr91913.f90: New test.

[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
commit r9-8369-g7ef07b622d8c2fca35813bf50669dcd663fe5cf2
Author: Jonathan Wakely 
Date:   Thu Mar 12 17:39:05 2020 +

libstdc++: Handle type-changing path concatenations (PR 94063)

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated.

Backport from mainline
2020-03-09  Jonathan Wakely  

PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge
to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #12 from Martin Liška  ---
commit r9-8365-g362c8772e7779d9e4730e2e51628ccaadce98bd0
Author: Jonathan Wakely 
Date:   Thu Mar 12 17:39:04 2020 +

libstdc++: Ensure root-dir converted to forward slash (PR93244)

Backport from mainline
2020-01-13  Jonathan Wakely  

PR libstdc++/93244
* include/bits/fs_path.h (path::generic_string)
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to
forward-slash.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Check
root-dir is converted to forward slash in generic pathname.
* testsuite/27_io/filesystem/path/generic/utf.cc: New test.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.

[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
I've got a patch candidate, will send it to GCC patches mailing list.

[Bug lto/94138] [gcc10] unresolvable R_X86_64_TPOFF32 relocation against symbol when LTO activated

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Thank you, let's close it then.

[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
commit r9-8370-gde8e3b71c8bec6dde60e6ee70c73d6895c67d782
Author: Bill Schmidt 
Date:   Thu Mar 12 15:28:50 2020 -0500

rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560)

PR87560 reports an ICE when a test case is compiled with -mpower9-vector
and -mno-altivec.  This patch terminates compilation with an error when
this combination (and other unreasonable ones) are requested.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Reported error is now:

f951: Error: '-mno-altivec' turns off '-mpower9-vector'

2020-03-12  Bill Schmidt  

Backport from master
2020-03-02  Bill Schmidt  

PR target/87560
* rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define.
* rs6000.c (rs6000_disable_incompatible_switches): Add table entry
for OPTION_MASK_ALTIVEC.

[Bug rtl-optimization/94119] [8/9/10 regression] invalid filling of branch delay slots leads to corrupt jump

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
commit r9-8372-g593e47a6134085e9b856c62f98f72acd4446ba7c
Author: Eric Botcazou 
Date:   Fri Mar 13 09:58:44 2020 +0100

Fix incorrect filling of delay slots in branchy code at -O2

The issue is that relax_delay_slots can streamline the CFG in some cases,
in particular remove BARRIERs, but removing BARRIERs changes the way the
instructions are associated with (basic) blocks by the liveness analysis
code in resource.c (find_basic_block) and thus can cause entries in the
cache maintained by resource.c to become outdated, thus producing wrong
answers downstream.

The fix is to invalidate the cache entries affected by the removal of
BARRIERs in relax_delay_slots, i.e. for the instructions down to the
next BARRIER.

PR rtl-optimization/94119
* resource.h (clear_hashed_info_until_next_barrier): Declare.
* resource.c (clear_hashed_info_until_next_barrier): New function.
* reorg.c (add_to_delay_list): Fix formatting.
(relax_delay_slots): Call clear_hashed_info_until_next_barrier on
the next instruction after removing a BARRIER.