This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Error in INSN_ADDRESSES (INSN_UID (get_last_insn ()))


> Hi,
> 
> trying to build --target=avr from CVS today, I got the following error:
> 
> ../../../cvs/egcs/gcc/libgcc2.c: In function `__cmpdi2':
> ../../../cvs/egcs/gcc/libgcc2.c:812: virtual array insn_addresses[184]: element
> 186 out of bounds in avr_output_function_epilogue, at config/avr/avr.c:752
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> 
> The offending code in avr.c:752 is this:
> 
>   function_size = (INSN_ADDRESSES (INSN_UID (get_last_insn ()))
>                    - INSN_ADDRESSES (INSN_UID (get_insns ())));
> 
> The size is only used for statistics (numbers reported as part of comments
> in the asm output) so it's no big deal if it has to be disabled, but it
> used to work...  Is this a bug in the AVR port (shouldn't calculate the
> function size that way, it worked by accident), or a bug elsewhere in GCC?

This appears to be side effect of my INSN_STMT change.  I now rebuild
NOTE_BLOCK_BEG/NOTE_BLOCK_END after branch shortening resulting in
unintialized INSN_ADDRESSES.

I've fixed generic code to deal with this, but didn't expected such
tricks in machine dependent bits.
Simplu looking for first/last nonnote insn will solve your problem.
Is this scheme common enought?  If yes, I may think about rebuilding the
scope forest earlier, but this is unfortunate from different point of
view - I don't want to do so when -g is not passed and not doing so
always may cause differences in generated file.

Honza
> 
> Thanks,
> Marek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]