This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3 regression] 20020227-1.c:30: interna compiler error: in
- From: Jan Hubicka <jh at suse dot cz>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: Jan Hubicka <jh at suse dot cz>, dave dot anglin at nrc dot ca,gcc-gnats at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Apr 2003 22:47:28 +0200
- Subject: Re: [3.3 regression] 20020227-1.c:30: interna compiler error: in
- References: <20030428083223.GZ4792@kam.mff.cuni.cz> <200304282032.h3SKWlbl018415@hiauly1.hia.nrc.ca>
> Hi Honza,
>
> Having trouble both with your email jh at suse dot cz and gcc-gnats at gcc dot gnu dot org dot
>
> The testcase can be simplified to:
>
> typedef __complex__ float cf;
> struct x { cf f; } __attribute__ ((__packed__));
> void
> f2 (struct x *y)
> {
> if (y->f)
> abort ();
> }
>
> Before reload, we have
>
> (insn 40 39 41 0 0000000000000000 (set (reg:SF 68)
> (subreg:SF (reg:DI 99) 0)) 121 {*pa.md:3418} (insn_list 39 (nil))
> (nil))
This is what worries me. The subreg is already not representable on
reg:DI because the whole value is single register, right?
I believe that before my change reload just misscompiled this piece of
code by simplifuing it into (reg:SF 99). Now it appears to notice the
problem (that was motivation of my patch) and produce reload around.
It does not know how to deal with such a problem so it ends up in
another wrong subreg getting into infinite loop.
>
> I'm not sure that subregs for insns 40 and 41 before reload are invalid.
> I quick hack to try use a pair of general registers for TCmode didn't
> seem to change the situation. So, I don't know how to fix the problem.
> The code generated before for this testcase (PR6221) was wrong on
> all 64-bit targets except apparently powerpc64.
Good to hear that there really was misscompilation before, at least we
don't have regression :=).
It works for x86-64 apparently. Didn't investigated on why.
>
> Isn't the obvious fix to store reg:DI 99 to memory and adjust the memory
> address used in the SFmode loads in insns 67 and 69 so that they access
> the correct portion of what was in reg 99?
Yes, this is what probably should happen. Other way around is to avoid
such a subregs from being produced at first place (reload currently can
deal with cases where the generic registers can represent the subreg,
only fails in the cases where subreg is never representable). Using
subreg for something that really isn't subreg is just sick.
I am not sure how to implement any of these two possibilities. In the
reload case I don't think there is direct way to instruct reload to
offload something into memory, but I may be wrong. I will unlikely be
able to dig into this before end of the week, so in the case you (or
someone else) beat me, I would be happy :)
Honza
>
> Dave
> --
> J. David Anglin dave dot anglin at nrc-cnrc dot gc dot ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6602)