Re: Reload problems with only one base reg for "base + offset" addressing mode
2010/7/31 redriver jiang :
> Hi,
>
> Seems there are still some exceptions.
>
> During my testing, the compiler complains:
>
> ./os_core.c: In function 'OS_EventTaskWait':
> ./os_core.c:747: error: unable to find a register to spill in class
> 'POINTER_REGS'
> ./os_core.c:747: error: this is the insn:
> (insn 7 6 8 2 ./os_core.c:739 (set (mem/s/f:HI (plus:HI (reg/f:HI 16
> R16 [orig:39 OSTCBCur.39 ] [39])
> (const_int 13 [0xd])) [11 .OSTCBEventPtr+0 S2 A8])
> (reg/v/f:HI 2 R2 [orig:40 pevent ] [40])) 48 {*movhi} (nil))
> ./os_core.c:747: confused by earlier errors, bailing out
>
>
> I guess that it is caused by that there is only one register "R18" in
> "POINTER_REGS" class.
>
> I have changed "LEGITIMIZE_RELOAD_ADDRESS" several times, but still can't
> work.
>
> Do I miss some "macro" definition?
>
> Could someone give some direction?
I have a lot of experiments with reloading memory addresses while I
debug AVR port.
Finally I have emulated memory addressing with infinite displacement.
Look carefully at avr.c: out_movhi_r_mr
Denis.
Re: Reload problems with only one base reg for "base + offset" addressing mode
Hi Denis,
I read the "out_movqi_r_mr" code of the AVR port. I see that following
exception are
handled:
1. "REG_X+offset", which is not supported by AVR.
2. "REGY+offset", with offset larger than 63, which is not supported by AVR.
Seems reload can not handle the targets that has some base regs are
offsetable, and some can't.
I will follow your method to handle my port.
Thanks!
2010/8/1 Denis Chertykov :
> 2010/7/31 redriver jiang :
>> Hi,
>>
>> Seems there are still some exceptions.
>>
>> During my testing, the compiler complains:
>>
>> ./os_core.c: In function 'OS_EventTaskWait':
>> ./os_core.c:747: error: unable to find a register to spill in class
>> 'POINTER_REGS'
>> ./os_core.c:747: error: this is the insn:
>> (insn 7 6 8 2 ./os_core.c:739 (set (mem/s/f:HI (plus:HI (reg/f:HI 16
>> R16 [orig:39 OSTCBCur.39 ] [39])
>> (const_int 13 [0xd])) [11 .OSTCBEventPtr+0 S2 A8])
>> (reg/v/f:HI 2 R2 [orig:40 pevent ] [40])) 48 {*movhi} (nil))
>> ./os_core.c:747: confused by earlier errors, bailing out
>>
>>
>> I guess that it is caused by that there is only one register "R18" in
>> "POINTER_REGS" class.
>>
>> I have changed "LEGITIMIZE_RELOAD_ADDRESS" several times, but still can't
>> work.
>>
>> Do I miss some "macro" definition?
>>
>> Could someone give some direction?
>
> I have a lot of experiments with reloading memory addresses while I
> debug AVR port.
> Finally I have emulated memory addressing with infinite displacement.
>
> Look carefully at avr.c: out_movhi_r_mr
>
> Denis.
>
porting gcc to new arch: unrecognizable insn
Hi All, I'm porting GCC 4.4.4 to a new arch and while cross-compiling libgcc I get the following error: ../../../libgcc/../gcc/libgcc2.c: In function ‘__clzsi2’: ../../../libgcc/../gcc/libgcc2.c:716: error: unrecognizable insn: (insn 49 48 50 16 ../../../libgcc/../gcc/libgcc2.c:713 (set (reg:QI 25) (mem/s/u/j:QI (plus:SI (reg/f:SI 22) (reg:SI 23)) [0 __clz_tab S1 A8])) -1 (nil)) ../../../libgcc/../gcc/libgcc2.c:716: internal compiler error: in extract_insn, at recog.c:2048 Please submit a full bug report, If I understand correctly it complains about a move instruction where src memory location should be (reg22+reg23). My arch defines: #define MAX_REGS_PER_ADDRESS 1 the first pseudo reg is 13 So I don't really understand why it tries to use such a pattern. My arch supports: REG->REG, REG->MEM, MEM->REG, MEM->MEM, IMM->REG, IMM->MEM (MEM can be symbol, REF+index, and IMM+index which doesn't really work now). If I write an asm code for count_leading_zero in longlong.h then it goes on but that piece of C code should compile anyway. Thanks Gabor Kerenyi
Re: Reload problems with only one base reg for "base + offset" addressing mode
2010/8/1 redriver jiang : > Hi Denis, > > I read the "out_movqi_r_mr" code of the AVR port. I see that following > exception are > > handled: > > 1. "REG_X+offset", which is not supported by AVR. > 2. "REGY+offset", with offset larger than 63, which is not supported by AVR. > > Seems reload can not handle the targets that has some base regs are > offsetable, and some can't. IMHO reload can't handle small number of pointer regs with small offsets only in very rare cases. Also, look at avr.h: BASE_REG_CLASS definition. My main idea was to disable infinite offsets in addressing (and REG_X+offset) as long as possible. But, if wrong addressing occurs then I have to emulate it. Look at avr.h: LEGITIMIZE_RELOAD_ADDRESS it's not easy to understand Denis.
Re: onlinedocs/libstdc++ appears stale
On Tue, 27 Jul 2010, Benjamin Kosnik wrote: >> gcc.gnu.org will be preferrable, I think. That allows a number of us >> to help out if neede, re-running scripts, etc. > Right. The Makefiles are set up for this now. Cool. >> For the time being I suggest to apply the patch below, though. What >> we have in place as of today simply is broken (and has been for >> quarters, at a minimum). > OK Done, also updated on gcc.gnu.org, and removed all .gz files from onlinedocs/libstdc++ (verifying that old had naked .html versions as well). Gerald
gcc-4.3-20100801 is now available
Snapshot gcc-4.3-20100801 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100801/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 162805 You'll find: gcc-4.3-20100801.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100801.tar.bz2 C front end and core compiler gcc-ada-4.3-20100801.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100801.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100801.tar.bz2 C++ front end and runtime gcc-java-4.3-20100801.tar.bz2 Java front end and runtime gcc-objc-4.3-20100801.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100801.tar.bz2The GCC testsuite Diffs from 4.3-20100725 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
