[Bug target/31110] New: Problem while compiling gcc for mn10300-elf

[Bug target/31110] New: Problem while compiling gcc for mn10300-elf

[mstein at phenix dot rootshell dot be]

Hello,
there seems to be a gcc problem with the target 'mn10300-elf':


/home/mstein/sim/mn10300-elf/build/./gcc/xgcc
-B/home/mstein/sim/mn10300-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/ -isystem
/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/targ-include -isystem
/n/07/mstein/combined-trunk/newlib/libc/include
-B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/bin/
-B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/lib/ -isystem
/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/include -isystem
/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/sys-include
-L/home/mstein/sim/mn10300-elf/build/./ld -DPACKAGE_NAME=\"newlib\"
-DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\"
-DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\"  -I.
-I/n/07/mstein/combined-trunk/newlib/libc/stdlib -O2 -fno-builtin      -O2 -g
-O2   -mam33 -c -o lib_a-ldtoa.o `test -f 'ldtoa.c' || echo
'/n/07/mstein/combined-trunk/newlib/libc/stdlib/'`ldtoa.c
/n/07/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c: In function '_ldtoa_r':
/n/07/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c:2858: internal compiler
error: in default_secondary_reload, at targhooks.c:588
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[8]: *** [lib_a-ldtoa.o] Error 1
make[8]: Leaving directory
`/home/mstein/sim/mn10300-elf/build/mn10300-elf/am33/newlib/libc/stdlib'


The SVN revision was 122728.


-- 
           Summary: Problem while compiling gcc for mn10300-elf
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mstein at phenix dot rootshell dot be
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mn10300-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[mstein at phenix dot rootshell dot be]

------- Comment #1 from mstein at phenix dot rootshell dot be  2007-03-09 18:16 -------
Created an attachment (id=13182)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13182&action=view)
from SVN revision: 122728

Commandline used to create ldtoa.i:


/home/mstein/sim/mn10300-elf/build/./gcc/xgcc
-B/home/mstein/sim/mn10300-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/ -isystem
/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/targ-include -isystem
/n/07/mstein/combined-trunk/newlib/libc/include
-B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/bin/
-B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/lib/ -isystem
/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/include -isystem
/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/sys-include
-L/home/mstein/sim/mn10300-elf/build/./ld -DPACKAGE_NAME=\"newlib\"
-DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\"
-DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\"  -I.
-I/n/07/mstein/combined-trunk/newlib/libc/stdlib -O2 -fno-builtin      -O2 -g
-O2   -mam33 -c -o lib_a-ldtoa.o `test -f 'ldtoa.c' || echo
'/n/07/mstein/combined-trunk/newlib/libc/stdlib/'`ldtoa.c -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[rask at sygehus dot dk]

------- Comment #2 from rask at sygehus dot dk  2007-06-09 11:02 -------
It is still broken as of revision 125570.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[mstein dot lists at googlemail dot com]

------- Comment #3 from mstein dot lists at googlemail dot com  2008-03-20 13:55 -------
patch:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01458.html


-- 

mstein dot lists at googlemail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com, nickc
                   |                            |at redhat dot com
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[law at redhat dot com]

------- Comment #4 from law at redhat dot com  2008-03-25 21:54 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

mstein dot lists at googlemail dot com wrote:
> ------- Comment #3 from mstein dot lists at googlemail dot com  2008-03-20 13:55 -------
> patch:
> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01458.html
> 
> 
I haven't worked with the mn103 in a long time, a little refreshment 
would go a long way.

What does CLASS, MODE and IN look like?  And more interesting, what are 
all the forms IN, CLASS & MODE might be at this point?  Given the way 
the code is written, we must have thought one particular case required a 
secondary register that was a DATA_REG, presumably because an 
ADDRESS_REG wouldn't work.  Your change would likely break that case.


It's also unclear to me that this really solves the problem as opposed 
to just papering over the problem.

Aren't DATA_OR_EXTENDED_REGS and DATA_REGS subclasses of GENERAL_REGS 
and thus ought to work just fine given the constraints of reload_insi's 
clobber operand? "=&r"

I think this needs further discusssion

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at redhat dot com]

------- Comment #5 from nickc at redhat dot com  2008-03-26 14:16 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

Hi Jeff,

> What does CLASS, MODE and IN look like?

Err, presumably you are talking about these values when 
default_secondary_reload() triggers the abort ?

The CLASS is DATA_OR_EXTENDED_REGS.

The MODE is SImode.

IN looks like this:

   (plus:SI (reg/f:SI 9 sp)
       (const_int 1100 [0x44c]))


> And more interesting, what are 
> all the forms IN, CLASS & MODE might be at this point?

Hmm, well I only ever saw this problem for the case in 
mn10300_secondary_reload_class() that handles additions to the stack 
pointer, so I think that we can say that IN will always be:

       (plus (reg sp) (...))
   or  (plus (...) (reg sp))

CLASS is going to be DATA_REGS or DATA_OR_EXTENDED_REGS depending upon 
whether we are compiling for an AM33 or an MN10300.  (I have seen the 
problem for both targets).  MODE I assume will always be SImode.  Do we 
ever make stack adjustments in other modes ?


> Given the way 
> the code is written, we must have thought one particular case required a 
> secondary register that was a DATA_REG, presumably because an 
> ADDRESS_REG wouldn't work.  Your change would likely break that case.

I think it was because the stack adjustment was too large for it to be 
handled as part of the addressing mode, and so a data reg was needed in 
order to be able to perform the arithmetic on the stack pointer.


> It's also unclear to me that this really solves the problem as opposed 
> to just papering over the problem.

Well the other approach it seems to me would be to change the class of 
the scratch register in the reload_insi pattern to be "=dx&" in order to 
match the possible register classes returned by 
mn10300_secondary_reload_class().  I did not try this as I was worried 
about changing a pattern that is going to influence a lot of other code 
generation, not just stack adjustments.



> Aren't DATA_OR_EXTENDED_REGS and DATA_REGS subclasses of GENERAL_REGS 

Yes

> and thus ought to work just fine given the constraints of reload_insi's 
> clobber operand? "=&r"

No because the assert at line 649 of targhooks.c says that the class of 
the scratch register must be the same as the class from which we are 
choosing a secondary reload register.  But the class of the 
reload_insi's clobbered operand is GENERAL_REGS whereas the class from 
which we are selecting a register is DATA_OR_EXTENDED_REGS.  I agree 
that this class is a subset of GENERAL_REGS, but the assert does not 
allow for this.  Maybe it should, but I was very loath to change a piece 
of generic reload code for what seemed to be a MN10300 specific problem. 
  I interpreted the assert as saying "if this assert is triggered, the 
target has a discrepancy between the register class returned by 
SECONDARY_RELOAD_CLASS and the reload_{in|out}<mode> pattern for that 
target".


Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[law at redhat dot com]

------- Comment #6 from law at redhat dot com  2008-03-27 00:35 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

nickc at redhat dot com wrote:
> ------- Comment #5 from nickc at redhat dot com  2008-03-26 14:16 -------
> Subject: Re:  Problem while compiling gcc for mn10300-elf
> 
> Hi Jeff,
> 
>> What does CLASS, MODE and IN look like?
> 
> Err, presumably you are talking about these values when 
> default_secondary_reload() triggers the abort ?
Yea.

> 
> The CLASS is DATA_OR_EXTENDED_REGS.
> 
> The MODE is SImode.
> 
> IN looks like this:
> 
>    (plus:SI (reg/f:SI 9 sp)
>        (const_int 1100 [0x44c]))
Hmm, so why isn't this caught by this code in secondary_reload_class:

   /* We can't directly load sp + const_int into a data register;
      we must use an address register as an intermediate.  */
   if (class != SP_REGS
       && class != ADDRESS_REGS
       && class != SP_OR_ADDRESS_REGS
       && class != SP_OR_EXTENDED_REGS
       && class != ADDRESS_OR_EXTENDED_REGS
       && class != SP_OR_ADDRESS_OR_EXTENDED_REGS
       && (in == stack_pointer_rtx
           || (GET_CODE (in) == PLUS
               && (XEXP (in, 0) == stack_pointer_rtx
                   || XEXP (in, 1) == stack_pointer_rtx))))
     return ADDRESS_REGS;


In fact, I'm having trouble seeing why the clause which returns 
DATA_REGS/DATA_OR_EXTENDED_REGS exists at all.

Am I being overly dense today?

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at redhat dot com]

------- Comment #7 from nickc at redhat dot com  2008-03-27 08:26 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

Hi Jeff,


>> The CLASS is DATA_OR_EXTENDED_REGS.

>>    (plus:SI (reg/f:SI 9 sp)
>>        (const_int 1100 [0x44c]))

> Hmm, so why isn't this caught by this code in secondary_reload_class:
> 
>    /* We can't directly load sp + const_int into a data register;
>       we must use an address register as an intermediate.  */
>    if (class != SP_REGS
>        && class != ADDRESS_REGS
>        && class != SP_OR_ADDRESS_REGS
>        && class != SP_OR_EXTENDED_REGS
>        && class != ADDRESS_OR_EXTENDED_REGS
>        && class != SP_OR_ADDRESS_OR_EXTENDED_REGS
>        && (in == stack_pointer_rtx
>            || (GET_CODE (in) == PLUS
>                && (XEXP (in, 0) == stack_pointer_rtx
>                    || XEXP (in, 1) == stack_pointer_rtx))))
>      return ADDRESS_REGS;
> 
> 
> In fact, I'm having trouble seeing why the clause which returns 
> DATA_REGS/DATA_OR_EXTENDED_REGS exists at all.
> 
> Am I being overly dense today?

Nope, when you pointed it out to me I puzzled over it too.  The answer 
is quite simple though, at the point where 
mn10300_secondary_reload_class is called the value of CLASS is 
ADDRESS_REGS, which explains why the above fragment of code is not 
triggered.

I guess it makes sense - if you need to perform a reload of a stack 
pointer manipulation then the obvious first choice of class is the 
address registers.  If that does not work, say because the stack 
adjustment is too big, then using a data or extended register and 
performing direct arithmetic on the stack pointer is the way to go.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[law at redhat dot com]

------- Comment #8 from law at redhat dot com  2008-03-27 18:57 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

nickc at redhat dot com wrote:
> 
> Nope, when you pointed it out to me I puzzled over it too.  The answer 
> is quite simple though, at the point where 
> mn10300_secondary_reload_class is called the value of CLASS is 
> ADDRESS_REGS, which explains why the above fragment of code is not 
> triggered.
> 
> I guess it makes sense - if you need to perform a reload of a stack 
> pointer manipulation then the obvious first choice of class is the 
> address registers.  If that does not work, say because the stack 
> adjustment is too big, then using a data or extended register and 
> performing direct arithmetic on the stack pointer is the way to go.
So, if CLASS is ADDRESS_REGS, the worst possible scenario I can envision 
  would be for IN to have the form

(plus (stack_pointer_rtx) (pseudo))

Where the pseudo did not get a hard register and lives at a large offset 
   within the local stack.  For that case I think this sequence works 
regardless of what kind of scratch register we are given:


(set (reloadreg) (stack_pointer_rtx))          /* sp into addrreg */
(set (scratch) (reloadreg))                    /* sp into scratch */
(set (reloadreg) (plus (reloadreg) (offset)))  /* ADDR of pseudo */
(set (reloadreg) (mem (reloadreg))             /* get pseudo */
(set (reloadreg) (plus (reloadreg) (scratch))  /* sp + pseudo */



So if reload or the backend can generate that sequence, then I think we 
can indeed return GENERAL_REG like your patch suggests.

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at redhat dot com]

------- Comment #9 from nickc at redhat dot com  2008-03-28 08:43 -------
Hi Jeff,

  Thanks - I have checked the patch in.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at gcc dot gnu dot org]

------- Comment #10 from nickc at gcc dot gnu dot org  2008-03-28 08:43 -------
Subject: Bug 31110

Author: nickc
Date: Fri Mar 28 08:42:36 2008
New Revision: 133675

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133675
Log:
PR target/31110
   * config/mn10300/mn10300.c (mn10300_secondary_reload_class):
        Return GENERAL_REGS for stack adjustment reloads.

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[mstein dot lists at googlemail dot com]

------- Comment #11 from mstein dot lists at googlemail dot com  2008-03-28 08:54 -------
Can the patch be applied to the 4.3 branch too?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at gcc dot gnu dot org]

------- Comment #12 from nickc at gcc dot gnu dot org  2008-03-28 09:30 -------
Subject: Bug 31110

Author: nickc
Date: Fri Mar 28 09:30:05 2008
New Revision: 133676

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133676
Log:
        PR target/31110
        * config/mn10300/mn10300.c (mn10300_secondary_reload_class):
        Return GENERAL_REGS for stack adjustment reloads.

Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/config/mn10300/mn10300.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at redhat dot com]

------- Comment #13 from nickc at redhat dot com  2008-03-28 09:31 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

Hi Mike,

> Can the patch be applied to the 4.3 branch too?

Done.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[mstein dot lists at googlemail dot com]

------- Comment #14 from mstein dot lists at googlemail dot com  2008-03-28 10:31 -------
Fixed :)


-- 

mstein dot lists at googlemail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110