[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r12-4721-g8c59f4118357789cfa8df2cf0d3ecb61be7e9041
Author: Vladimir N. Makarov 
Date:   Tue Oct 26 14:03:42 2021 -0400

[PR102842] Consider all outputs in generation of matching reloads

Without considering all output insn operands (not only processed
before), in rare cases LRA can use the same hard register for
different outputs of the insn on different assignment subpasses.  The
patch fixes the problem.

gcc/ChangeLog:

PR rtl-optimization/102842
* lra-constraints.c (match_reload): Ignore out in checking values
of outs.
(curr_insn_transform): Collect outputs before doing reloads of
operands.

gcc/testsuite/ChangeLog:

PR rtl-optimization/102842
* g++.target/arm/pr102842.C: New test.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-21 Thread vmakarov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #12 from Vladimir Makarov  ---
The patch just hid the bug.  I believe the bug is still present on the trunk
too.

The insn in question is

(insn 26 64 109 3 (parallel [
(set (reg:SI 134 [ _12 ])
(plus:SI (mult:SI (reg:SI 117 [ _8 ])
(reg:SI 128))
(reg:SI 138)))
(set (reg:SI 135 [ _12+4 ])
(plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI
(zero_extend:DI (reg:SI 117 [ _8 ]))
(zero_extend:DI (reg:SI 128)))
(zero_extend:DI (reg:SI 138)))
(const_int 32 [0x20])))
(reg:SI 138)))
]) "a.cpp":15:32 70 {umlal}
 (expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:SI 128)
(nil

And its definition is 

(define_insn "mlal"
  [(set (match_operand:SI 0 "s_register_operand" "=r,")
(plus:SI
 (mult:SI
  (match_operand:SI 4 "s_register_operand" "%r,r")
  (match_operand:SI 5 "s_register_operand" "r,r"))
 (match_operand:SI 1 "s_register_operand" "0,0")))
   (set (match_operand:SI 2 "s_register_operand" "=r,")
(plus:SI
 (truncate:SI
  (lshiftrt:DI
   (plus:DI
(mult:DI (SE:DI (match_dup 4)) (SE:DI (match_dup 5)))
(zero_extend:DI (match_dup 1)))
   (const_int 32)))
 (match_operand:SI 3 "s_register_operand" "2,2")))]
  "TARGET_32BIT"
  "mlal%?\\t%0, %2, %4, %5"
  [(set_attr "type" "umlal")
   (set_attr "predicable" "yes")
   (set_attr "arch" "v6,nov6")]

After couple of LRA constraints and assignment sub-passes, the two output
operands get the same hard reg.  And this results in cse abort in post-reload
pass.

The issue is that reload pseudos for pseudos 134 and 135 get the same value as
they both are matched with different occurrences of pseudo 138 in the insn.

The bug is in a very sensitive LRA code area and fixing it will take some time.
 But I hope I'll have a fix at the end of next week.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-21 Thread herrtimson at yahoo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

tt_1  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #11 from tt_1  ---
(In reply to Martin Liška from comment #10)
> > Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile
> > bootstrap is fundamentally broken by missing fenv header in the gcc-11
> > branch. Mixing up host and target compiler versions is nothing to desire,
> > its a place where there will be dragons.
> 
> Oh, is it something we can help with? Is it a problem of the compiler?

the fenv bug is not new and was reported via #100017, there is already a
discussion with two possible solutions. The title is a bit misleading, I hit it
when I bootstrap a rootfs with all libs and headers for the armv7 target. 

it seems that the fix for my gcc-10 bug was a stray commit without any bug
report, so I don't know who and where to ask for a proper backport. Gentoo's
gcc maintainer trofi (Sergey Trofimov) has resigned, to my great misfortune, so
I'm kind of lost with the process. Can we at least reopen? The bug is def not
fixed in the gcc-10 branch.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-21 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #10 from Martin Liška  ---
> Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile
> bootstrap is fundamentally broken by missing fenv header in the gcc-11
> branch. Mixing up host and target compiler versions is nothing to desire,
> its a place where there will be dragons.

Oh, is it something we can help with? Is it a problem of the compiler?

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread herrtimson at yahoo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #9 from tt_1  ---
So, I did a little bit of research. pr92807 has indeed been backported to the
gcc-10 branch and is included in the gcc-10.3.0 release - it touches
gcc/config/i386/i386.c and adds a testcase. 

There is another fixup on top of that, which is the real fix the here reported
ICE:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126
or r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126 , to which you pointed me
as the most likely fix. But that fixup (commited by Vladimir Makarov) doesn't
have any bug number in the description. I wrote him an email, maybe he will
comment here later.

Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile
bootstrap is fundamentally broken by missing fenv header in the gcc-11 branch.
Mixing up host and target compiler versions is nothing to desire, its a place
where there will be dragons.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #8 from Martin Liška  ---
(In reply to tt_1 from comment #7)
> hey, thanks for the messages. I just finished to compile firefox with
> patched cross-gcc-10.3.0, the ice is fixed with the patch from
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=74dc179a6da33cd00f6d4a93fbb97dc84f610126 applied to it. 

Great!

> 
> So can you please tell me if this has already been backported to the gcc-10
> branch?

No, it wasn't.

> I just browsed through the git dirs, and I'm not certain. Also no
> hint in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been
> fixed for the gcc-10 branch. 
> 
> Is it queued to be backported?

Apparently, the commit does not fix a regression so the author decided not to
backport it.

So I would recommend updating to GCC 11.2.0, which is the latest support
release.

> Sorry if I'm asking dumb questions, I'm just
> a regular user, not a gentoo dev.

No, your questions are very reasonable and we thank you reporting the issue you
deal with.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread herrtimson at yahoo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #7 from tt_1  ---
hey, thanks for the messages. I just finished to compile firefox with patched
cross-gcc-10.3.0, the ice is fixed with the patch from
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126
applied to it. 

So can you please tell me if this has already been backported to the gcc-10
branch? I just browsed through the git dirs, and I'm not certain. Also no hint
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been fixed for
the gcc-10 branch. 

Is it queued to be backported? Sorry if I'm asking dumb questions, I'm just a
regular user, not a gentoo dev.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Closing as fixed.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #5 from Martin Liška  ---
And reduced test-case looks like this:

struct Plane {
  using T = float;
  T *Row();
};
using ImageF = Plane;
long long Mirror_x;
struct EnsurePaddingInPlaceRowByRow {
  void Process() {
switch (strategy_) {
case kSlow:
  float *row = img_.Row();
  long long xsize = x1_;
  while (Mirror_x >= xsize)
if (Mirror_x)
  Mirror_x = 2 * xsize - 1;
  *row = Mirror_x;
}
  }
  ImageF img_;
  unsigned x1_;
  enum { kSlow } strategy_;
};
void FinalizeImageRect() {
  EnsurePaddingInPlaceRowByRow ensure_padding;
  ensure_padding.Process();
}

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

2021-10-20 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed|2021-10-19 00:00:00 |2021-10-20
 Status|UNCONFIRMED |NEW
Summary|[10/11/12 Regression] ICE   |[10 Regression] ICE in
   |in cselib_record_set at -O2 |cselib_record_set at -O2 or
   |or greater  |greater
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
All right, now I can reproduce it with the cross compiler. Apparently, it's
fixed with r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126.