Re: [avr-gcc-list] Building AVRGCC on an AMD64-Box fails

[Joerg Wunsch]

Matthias Weißer <address@hidden> wrote:

> Here http://matwei.callisto.twam.info/fixunsdfsi.tar.gz is the complete 
> file. The interesting lines are
> 
>       ldi r18,lo8(0xffffffffcf000000)
>       ldi r19,hi8(0xffffffffcf000000)
>       ldi r20,hlo8(0xffffffffcf000000)
>       ldi r21,hhi8(0xffffffffcf000000)

Hmm.

> And there seems to be 64Bit-Int's instead of 32Bit-Int's which
> should be there. Right?

That's also how I read that.  However, that means you've found a
compiler bug that only happens on 64-bit architectures.  I've once
compiled the entire toolchain on sun4u/Solaris (UltraSPARC) and it
worked, but that's quite some time ago.  Maybe something has been
broken since.

According to the debugging information in the compiled file, this
refers to line number 1159 in libgcc2.c, which would be function
__fixunsdfSI().  At least, this matches the name of the generated
assembler file, so we can't be all that wrong. ;-)

When looking into the implementation of this function, it seems there
is a lot of preprocessor magic around.  Next try: run the command
again, but this time using a -E option instead of -S (and set the
output file name to end in .i, which is the conventional suffix for
preprocessed C source files).  Just try to see how the various
constants used there (Wtype_MIN etc.) resolve.  Perhaps they resolve
to 64-bit constants (suffix LL or ULL) when they ought to resolve to
32-bit constants while compiling for the AVR target.

In either case, submit a bug report for GCC.  I see that GCC 3.3.4 is
close to a release, and only bug fixes are acceptable for commits, so
it's IMHO important to notify the developers of the bug.

>> Hmm, and just in case, have you tried that with the `C' locale, too
>> (instead of the German one)?

> What?

Your error messages etc. came out as German, so I guess you're running
in a de_DE locale.  Sometimes it might be possible that non-English
locales are less tested and introduce a bug that otherwise remains
unnoticed in the default locale (which is named `C').  However, as we
see now, this is probably not the reason.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/