[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at gcc dot gnu.org]

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

--- Comment #18 from palmer at gcc dot gnu.org ---
Author: palmer
Date: Mon Mar 20 16:43:21 2017
New Revision: 246283

URL: https://gcc.gnu.org/viewcvs?rev=246283=gcc=rev
Log:
RISC-V: Don't prefer FP_REGS for integers

On RISC-V we can't store integers in floating-point registers as this is
forbidden by the ISA.  We've always disallowed this, but we were
setting the preferred mode to FP_REGS for some integer modes.  This
caused the LRA to blow up with some hard to read error messages.

This patch removes the prefered mode hook, as the right thing to do here
is nothing.

Thanks to Kito for finding the bug, and mpf for the fix.  See also
.

PR target/79912

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/riscv.c

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

--- Comment #17 from Palmer Dabbelt  ---
I'm sending out the immediate fix, I'll try and get some time to clean up the
mov patterns this weekend.

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00960.html

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #16 from mpf at gcc dot gnu.org ---
(In reply to Palmer Dabbelt from comment #15)
> Created attachment 40968 [details]
> glibc file that loops
> 
> The suggested patch causes an infinate loop while building glibc for RISC-V.
> The preprocessed source is attached, but I think the right way to fix this
> might be to actually fix the int-in-FP problem in our backend.  If I
> understand correctly we don't actually need riscv_preferred_reload_class()
> but I can instead remove all the integer->FP modes from the mov{q,h,s,d}
> patterns.

OK, I expect the conditions would need even more fine tuning but...

> 
> With just
> 
> static reg_class_t
> riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
> {
>   return rclass;
> }

Yes, or remove the hook entirely of course.  I don't think the
preferred_reload_class is really achieving anything in its current form anyway
as I think it boils down to representing the exact same thing as can be
inferred from the register classes that modes are allowed in anyway. I.e. the
register class will naturally reduce to the right one because some registers
are simply not allowed to hold some modes. I believe, but am not an expert,
that this hook is only really necessary for more complex rules but yours are
relatively simple.

> (which I assume is the same as removing preferred_reload_class()) everything
> builds, but I haven't even bothered running the test suite yet.  Looking at
> the mov patterns I can't actually find any that are illegal.  I'm looking
> for something like
> 
>   [(set (match_operand:QI 0 "nonimmediate_operand" "=f")
> (match_operand:QI 1 "move_operand" " r"))]
> 
> which would allow an integer to end up in a FP register, as opposed to

It would if an FPR was allowed to hold a register of mode QI but it is not so
this alternative will always fail. It was just confusing LRA and diagnosing the
true issue was harder because of this being present. Better to remove so it
doesn't mislead future debugging efforts.

>   [(set (match_operand:QI 0 "nonimmediate_operand" "=r")
> (match_operand:QI 1 "move_operand" " f"))]
> 

This is equally wrong. It will never succeed just like above but it is
describing a situation where a QImode register is in an FPR just like above
except it is already in an FPR here rather than moving to one. There is no
float-mode involved in this pattern. Did you perhaps just mix up the reference
to an FPR regclass with the use of floats?

> which from my understanding is legal, since we can store floats in GPRs.  I
> can understand how the f-operand versions of movqi and movhi don't make any
> sense, so I'll get rid of those, but I think the all our others are OK?
> 
> What am I missing?

Not much from what I can see, just the mix-up that FPR does not imply float.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

--- Comment #15 from Palmer Dabbelt  ---
Created attachment 40968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40968=edit
glibc file that loops

The suggested patch causes an infinate loop while building glibc for RISC-V. 
The preprocessed source is attached, but I think the right way to fix this
might be to actually fix the int-in-FP problem in our backend.  If I understand
correctly we don't actually need riscv_preferred_reload_class() but I can
instead remove all the integer->FP modes from the mov{q,h,s,d} patterns.

With just

static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
  return rclass;
}

(which I assume is the same as removing preferred_reload_class()) everything
builds, but I haven't even bothered running the test suite yet.  Looking at the
mov patterns I can't actually find any that are illegal.  I'm looking for
something like

  [(set (match_operand:QI 0 "nonimmediate_operand" "=f")
(match_operand:QI 1 "move_operand" " r"))]

which would allow an integer to end up in a FP register, as opposed to


  [(set (match_operand:QI 0 "nonimmediate_operand" "=r")
(match_operand:QI 1 "move_operand" " f"))]

which from my understanding is legal, since we can store floats in GPRs.  I can
understand how the f-operand versions of movqi and movhi don't make any sense,
so I'll get rid of those, but I think the all our others are OK?

What am I missing?

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[andrew at sifive dot com]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #14 from Andrew Waterman  ---
(In reply to mpf from comment #13)
> (In reply to Palmer Dabbelt from comment #12)
> > I believe this is a problem in the RISC-V port, so you're welcome to assign
> > the bug to me.  I might not have time to fix this today, this way I won't
> > lose it.
> 
> Thanks Palmer, glad I could find something specific to try and resolve this
> as it could have easily been much harder! Sorry to have exposed a bug so
> late in the release but I suspect there were other ways to hit this already
> so it may just have caught it early.

I suspect you are correct; and if so, it is we who should thank you :)

> 
> Matthew

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|mpf at gcc dot gnu.org |palmer at dabbelt dot 
com

--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Palmer Dabbelt from comment #12)
> I believe this is a problem in the RISC-V port, so you're welcome to assign
> the bug to me.  I might not have time to fix this today, this way I won't
> lose it.

Thanks Palmer, glad I could find something specific to try and resolve this as
it could have easily been much harder! Sorry to have exposed a bug so late in
the release but I suspect there were other ways to hit this already so it may
just have caught it early.

Matthew

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

Palmer Dabbelt  changed:

   What|Removed |Added

 CC||palmer at dabbelt dot com

--- Comment #12 from Palmer Dabbelt  ---
We actually _can't_ allow integer modes in FPRs on RISC-V because it's
undefined behavior in the ISA spec (this allows flexibility in the internal
representation of FP registers, which can help the hardware).  Our simulators
don't model this right now, so I'm going to go fix them, and then fix the bugs
that fall out.

If I understand this all correctly then mpf's riscv_preferred_reload_class fix
is the right way to go about it, I'm going to start running some test suites to
make sure nothing blows up.

Nobody knows why we have the f modes in movqi and friends.  Andrew and I
suspect it's vestigial (probably a workaround for a bug in our port), so I'm
going to try and remove them and fix the fallout.

I believe this is a problem in the RISC-V port, so you're welcome to assign the
bug to me.  I might not have time to fix this today, this way I won't lose it.

Thanks for all the info!

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> I recommend that on balance for all targets the current behavior is a
> reasonable compromise. I have said elsewhere that I am happy to continue
> working in this area and would welcome any further help to evaluate the
> effects of further work. EricB has offered his assistance and any additional
> help would also be good as this issue affects targets in different ways.

Yes, I don't think that we want to revert r245655 now, since it is necessary
for MIPS and doesn't really hurt ARM.  Its only effect is to widen some subword
loads to word loads, which shouldn't really matter in most cases.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #10 from mpf at gcc dot gnu.org ---
(In reply to Kito Cheng from comment #8)
> [1]
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index 89567f7..148967b 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -3581,10 +3581,6 @@ riscv_hard_regno_mode_ok_p (unsigned int regno, enum
> machine_mode mode)
>if (!FP_REG_P (regno + nregs - 1))
> return false;
>  
> -  if (GET_MODE_CLASS (mode) != MODE_FLOAT
> - && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT)
> -   return false;
> -
>/* Only use callee-saved registers if a potential callee is guaranteed
>  to spill the requisite width.  */
>if (GET_MODE_UNIT_SIZE (mode) > UNITS_PER_FP_REG
> @@ -3634,7 +3630,7 @@ riscv_class_max_nregs (reg_class_t rclass, enum
> machine_mode mode)
>  static reg_class_t
>  riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
>  {
> -  return reg_class_subset_p (FP_REGS, rclass) ? FP_REGS :
> +  return reg_class_subset_p (FP_REGS, rclass) && TARGET_HARD_FLOAT ?
> FP_REGS :
>  reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
>  rclass;
>  }

I don't think you want to do this really.  Allowing integer modes in FPRs can
make a real mess and lead to extra cost moving to and from FPRs which can be
slow as well as using additional register banks that would not normally be
required. I.e. consider code that only uses integer types hitting the FPU
registers.  Assuming the FPRs can be managed in a lazy context fashion then
this means you can introduce additional context switch overhead for
non-floating-point processes which is additional waste.

Doesn't my original fix work for you? It should just lead to the loads being a
different width but not using FPRs; I guess it could break something else
though.

The problem here is that WORD_REGISTER_OPERATIONS allows a subreg and a reg of
the same hard-register to be used without need for sign/zero extension but
instead relying on the LOAD_EXTEND_OP rules. The 'true' value is that of the
inner mode and there can be loads/stores in that inner-mode elsewhere that
expect the full width of the inner-mode to be valid in memory. If you do an
output reload in the outer-mode and only store outer-mode-width in memory then
any inner mode consumer will get junk in the upper bits.  There are of course
occasions where this does not matter. In particular that means input reloads
could be done in the outer-mode (when that is narrower) as long as and output
reloads for the same instruction are done in the inner-mode i.e. keeping memory
content consistent but reducing the size of loads. Doing that kind of
optimisation and getting it correct is far too invasive for stage 4 and the
aspects of the current behavior are necessary for correctness.

I recommend that on balance for all targets the current behavior is a
reasonable compromise. I have said elsewhere that I am happy to continue
working in this area and would welcome any further help to evaluate the effects
of further work. EricB has offered his assistance and any additional help would
also be good as this issue affects targets in different ways.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #9 from Kito Cheng  ---
Code gen in previous comment is output for riscv32-unknown-linux-gnu-gcc
pr52750.c -S


ARM got worse code gen too:

configure: --target=arm-eabi
$ arm-eabi-gcc pr52750.c -S

For pr52750.c:

$ diff before.arm.s after.arm.s
170c170
<   ldrbr3, [fp, #-176]
---
>   ldr r3, [fp, #-176]
172c172
<   ldrbr3, [fp, #-180]
---
>   ldr r3, [fp, #-180]
174c174
<   ldrbr3, [fp, #-184]
---
>   ldr r3, [fp, #-184]
176c176
<   ldrbr3, [fp, #-188]
---
>   ldr r3, [fp, #-188]
178c178
<   ldrbr3, [fp, #-192]
---
>   ldr r3, [fp, #-192]
180c180
<   ldrbr3, [fp, #-196]
---
>   ldr r3, [fp, #-196]
182c182
<   ldrbr3, [fp, #-200]
---
>   ldr r3, [fp, #-200]
184c184
<   ldrbr3, [fp, #-204]
---
>   ldr r3, [fp, #-204]
186c186
<   ldrbr3, [fp, #-208]
---
>   ldr r3, [fp, #-208]
188c188
<   ldrbr3, [fp, #-212]
---
>   ldr r3, [fp, #-212]
190c190
<   ldrbr3, [fp, #-216]
---
>   ldr r3, [fp, #-216]
192c192
<   ldrbr3, [fp, #-220]
---
>   ldr r3, [fp, #-220]
194c194
<   ldrbr3, [fp, #-224]
---
>   ldr r3, [fp, #-224]
196c196
<   ldrbr3, [fp, #-228]
---
>   ldr r3, [fp, #-228]
198c198
<   ldrbr3, [fp, #-232]
---
>   ldr r3, [fp, #-232]
200c200
<   ldrbr3, [fp, #-236]
---
>   ldr r3, [fp, #-236]
202c202
<   ldrbr3, [fp, #-240]
---
>   ldr r3, [fp, #-240]
204c204
<   ldrbr3, [fp, #-244]
---
>   ldr r3, [fp, #-244]
206c206
<   ldrbr3, [fp, #-248]
---
>   ldr r3, [fp, #-248]

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #8 from Kito Cheng  ---
Hi Matthew:
Oh, my fault, I just go another way[1] to fix this issue, but I got worse code
gen for both hard-float and soft-float after r245655, before.*.s is generate by
gcc with revert r245655, *rv32imafd.s for hard-float and *rv32ima.s for
soft-float, RISC-V define WORD_REGISTER_OPERATIONS as 1, but also provide qi/hi
load/store, I guess this may effect other RISC arch too.

$ diff before.rv32imafd.s after.rv32imafd.s
139c139,142
<   lbu a5,-244(s0)
---
>   flw fa5,-244(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5
141c144,147
<   lbu a5,-248(s0)
---
>   flw fa5,-248(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5
143c149,152
<   lbu a5,-252(s0)
---
>   flw fa5,-252(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5
145c154,157
<   lbu a5,-256(s0)
---
>   flw fa5,-256(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5
147c159,162
<   lbu a5,-260(s0)
---
>   flw fa5,-260(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5
173c188,191
<   lbu a5,-264(s0)
---
>   flw fa5,-264(s0)
>   fmv.x.s a5,fa5
>   fmv.s.x fa5,a5
>   fmv.x.s a5,fa5


$ diff before.rv32ima.s after.rv32ima.s
143c143
<   lbu a4,-244(s0)
---
>   lw  a4,-244(s0)
145c145
<   lbu a4,-248(s0)
---
>   lw  a4,-248(s0)
147c147
<   lbu a4,-252(s0)
---
>   lw  a4,-252(s0)
149c149
<   lbu a4,-256(s0)
---
>   lw  a4,-256(s0)
151c151
<   lbu a4,-260(s0)
---
>   lw  a4,-260(s0)
153c153
<   lbu a4,-264(s0)
---
>   lw  a4,-264(s0)


[1]
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 89567f7..148967b 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3581,10 +3581,6 @@ riscv_hard_regno_mode_ok_p (unsigned int regno, enum
machine_mode mode)
   if (!FP_REG_P (regno + nregs - 1))
return false;

-  if (GET_MODE_CLASS (mode) != MODE_FLOAT
- && GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT)
-   return false;
-
   /* Only use callee-saved registers if a potential callee is guaranteed
 to spill the requisite width.  */
   if (GET_MODE_UNIT_SIZE (mode) > UNITS_PER_FP_REG
@@ -3634,7 +3630,7 @@ riscv_class_max_nregs (reg_class_t rclass, enum
machine_mode mode)
 static reg_class_t
 riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
 {
-  return reg_class_subset_p (FP_REGS, rclass) ? FP_REGS :
+  return reg_class_subset_p (FP_REGS, rclass) && TARGET_HARD_FLOAT ? FP_REGS :
 reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
 rclass;
 }

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #7 from mpf at gcc dot gnu.org ---
The same fix will resolve soft-float as well I think. In the soft-float case I
believe it is reasonably logical that preferred_reload_class is wrong as there
are no registers in FPR_REGS available at all.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #6 from Kito Cheng  ---
Hi Matthew:
Thanks for you feedback, I will disuses with other RISC-V maintainer for the
GPR <-> FPR issue, however it's still hang on LRA for pr52750.c when use soft
float[1] and work if revert r245655 too, do you have any idea for that?


[1]
$ riscv32-unknown-linux-gnu-gcc pr52750.c  -march=rv32ima -mabi=ilp32

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #5 from mpf at gcc dot gnu.org ---
I think there are some relatively serious issues in the riscv backend here.  
What I understand so far:

1) Only floating point modes are allowed in FPRs
2) There is an alternative in the movqi_internal pattern that allows FPR to GPR
moves but from (1) this is impossible. The presence of this alternative skews
the error from LRA. Removing these alternatives changes the LRA error to max
reloads reached.
3) The preferred reload class for riscv is always FP_REGS if the requested
class is ALL_REGS but there is no check to ensure the mode of the expression
being reloaded can go in FP_REGS.
4) LRA always generates reloads as ALL_REGS to start with and refines
5) Therefore a QImode reload can end up trying to reload through an FP_REG
which is completely impossible. I expect similar FPR-GPR alternatives in other
integer move patterns may also be bugs.

   Spilling non-eliminable hard regs: 8
  Creating newreg=182, assigning class FP_REGS to slow mem r182
  Creating newreg=183, assigning class FP_REGS to slow mem r183
  194: r180:QI=r183:QI
  REG_DEAD r102:SI
Inserting slow mem reload before:
  196: r182:SI=[frame:SI-0x108]
  197: r183:QI=r182:SI#0

Simply removing the preferred_reload_class hook allows LRA to succeed but
presumably it is desirable to try and reload through FPRs for float modes where
possible.

I suspect the preferred_reload_class should be:

static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
  machine_mode mode = GET_MODE (x);
  if ((GET_MODE_CLASS (mode) == MODE_FLOAT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
  && reg_class_subset_p (FP_REGS, rclass))
return FP_REGS;

  return reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
 rclass;
}

But it needs a riscv maintainer to comment on what they were trying to achieve
and the constraints on movqi_internal, movhi_internal, movsi_internal need
checking. From my read through of the backend I believe all the alternatives
involving 'f' on these are invalid but I can't be sure.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #4 from Kito Cheng  ---
Hi Eric:
>> vfscanf.c: In function ‘_IO_vfscanf_internal’:
>> vfscanf.c:3050:1: error: unable to generate reloads for:
>> (insn 11026 11523 5651 1080 (set (reg:QI 3515)
>> (mem/c:QI (plus:SI (reg/f:SI 65 frame)
>> (const_int -1568 [0xf9e0])) [65 %sfp+-1504 S1
>> A32])) "vfscanf.c":266 138 {*movqi_internal}
>>  (expr_list:REG_DEAD (reg:QI 3956)
>> (nil)))

> I presume that it's not a valid address?  If so, why isn't it valid?

RISC-V have 12-bit signed immediate for offset (2047~-2048), so it's should be
valid address.




Here is another simple case in gcc testsuite:

riscv32-unknown-linux-gnu-gcc gcc/testsuite/gcc.c-torture/compile/pr52750.c -O0
-march=rv32imafd -mabi=ilp32d

/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:
In function ‘foo’:
/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:11:1:
error: unable to generate reloads for:
 }
 ^
(insn 194 197 145 2 (set (reg:QI 180)
(mem/c:QI (plus:SI (reg/f:SI 65 frame)
(const_int -268 [0xfef4])) [2 %sfp+-204 S1 A32]))
"/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c":10
138 {*movqi_internal}
 (expr_list:REG_DEAD (reg:QI 183)
(nil)))
/home/kito/riscv-workspace/riscv-gnu-toolchain/riscv-gcc/gcc/testsuite/gcc.c-torture/compile/pr52750.c:11:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:3785
0xa9f298 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../src/gcc/trunk/gcc/rtl-error.c:108
0x9a2001 curr_insn_transform
../../../src/gcc/trunk/gcc/lra-constraints.c:3785
0x9a3286 lra_constraints(bool)
../../../src/gcc/trunk/gcc/lra-constraints.c:4754
0x98cf7c lra(_IO_FILE*)
../../../src/gcc/trunk/gcc/lra.c:2392
0x942ddb do_reload
../../../src/gcc/trunk/gcc/ira.c:5451
0x942ddb execute
../../../src/gcc/trunk/gcc/ira.c:5635
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
Version|6.1.0   |7.0

--- Comment #3 from Eric Botcazou  ---
> vfscanf.c: In function ‘_IO_vfscanf_internal’:
> vfscanf.c:3050:1: error: unable to generate reloads for:
> (insn 11026 11523 5651 1080 (set (reg:QI 3515)
> (mem/c:QI (plus:SI (reg/f:SI 65 frame)
> (const_int -1568 [0xf9e0])) [65 %sfp+-1504 S1
> A32])) "vfscanf.c":266 138 {*movqi_internal}
>  (expr_list:REG_DEAD (reg:QI 3956)
> (nil)))

I presume that it's not a valid address?  If so, why isn't it valid?

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-06
 CC||mpf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpf at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from mpf at gcc dot gnu.org ---
I'll take a look shortly. It may be a day to get initial feedback so I can
build tools and check dumps and RISCV description in GCC.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[npickito at gmail dot com]

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

--- Comment #1 from Kito Cheng  ---
Update for command to reproduce:

riscv32-unknown-linux-gnu-gcc  vfscanf.E.i  -O2