ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Geert bosch]

Compiler bootstraps fine, but fails with the following test case:
> struct s {
>   char c;
>   double d;
> };
>
> struct s t [] = { { 0, 0.0 } };

It hits an ICE in assemble_real, at varasm.c:2169:
>   if (align < GET_MODE_ALIGNMENT (mode))
>     abort ();

According to comments in darwin.h, Darwin word-aligns FP doubles
but doubleword-aligns 64-bit ints and increases natural record
alignment to doubleword if the first field is an FP double while
the FP fields remain word aligned.

GET_MODE_ALIGNMENT is defined as below in rtl.c, and will cause
the mode alignment for doubles to be 64 bits, which is wrong.
I wonder how this is supposed to work and how this should be fixed.
Should I write a new get_darwin_mode_alignment that returns
32 for double and calls get_mode_alignment otherwise,
or am I completely wrong here?

   -Geert

> /* Return the alignment of MODE. This will be bounded by 1 and
>    BIGGEST_ALIGNMENT.  */
>
> unsigned int
> get_mode_alignment (mode)
>      enum machine_mode mode;
> {
>   unsigned int alignment = GET_MODE_UNIT_SIZE (mode);
>   /* Extract the LSB of the size.  */
                   ^^^ shouldn't this be MSB (most significant bit)?
>   alignment = alignment & -alignment;
>   alignment *= BITS_PER_UNIT;
>
>   alignment = MIN (BIGGEST_ALIGNMENT, MAX (1, alignment));
>   return alignment;
> }

Re: ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Stan Shebs]

Geert bosch wrote:
> 
> Compiler bootstraps fine, but fails with the following test case:
> > struct s {
> >   char c;
> >   double d;
> > };
> >
> > struct s t [] = { { 0, 0.0 } };
> 
> It hits an ICE in assemble_real, at varasm.c:2169:
> >   if (align < GET_MODE_ALIGNMENT (mode))
> >     abort ();

OK OK, I admit to being a dirty software hoarder!  We have some
local patches to fix several alignment problems, and apparently
this is one of them, because your example works fine in our latest
code.  The patches are intermingled with a - get ready to retch -
-malign-mac68k option that is needed by some very old code, and
we wanted to separate things before submitting.  But clearly we
need to do the separating sooner rather than later - sorry!

Stan

Re: ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Phil Edwards]

On Thu, Nov 29, 2001 at 04:47:05PM -0800, Stan Shebs wrote:
> -malign-mac68k option that is needed by some very old code, and

Heck, one of my coworkers maligns the 68K all the time; this is default
behavior in the simulations lab, where they're all x86 bigots.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Phil Edwards]

On Thu, Nov 29, 2001 at 04:47:05PM -0800, Stan Shebs wrote:
> -malign-mac68k option that is needed by some very old code, and

Heck, one of my coworkers maligns the 68K all the time; this is default
behavior in the simulations lab, where they're all x86 bigots.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Stan Shebs]

Geert bosch wrote:
> 
> Compiler bootstraps fine, but fails with the following test case:
> > struct s {
> >   char c;
> >   double d;
> > };
> >
> > struct s t [] = { { 0, 0.0 } };
> 
> It hits an ICE in assemble_real, at varasm.c:2169:
> >   if (align < GET_MODE_ALIGNMENT (mode))
> >     abort ();

OK OK, I admit to being a dirty software hoarder!  We have some
local patches to fix several alignment problems, and apparently
this is one of them, because your example works fine in our latest
code.  The patches are intermingled with a - get ready to retch -
-malign-mac68k option that is needed by some very old code, and
we wanted to separate things before submitting.  But clearly we
need to do the separating sooner rather than later - sorry!

Stan

ICE outputting unaligned fp constant on powerpc-apple-darwin5.1

[Geert bosch]

Compiler bootstraps fine, but fails with the following test case:
> struct s {
>   char c;
>   double d;
> };
>
> struct s t [] = { { 0, 0.0 } };

It hits an ICE in assemble_real, at varasm.c:2169:
>   if (align < GET_MODE_ALIGNMENT (mode))
>     abort ();

According to comments in darwin.h, Darwin word-aligns FP doubles
but doubleword-aligns 64-bit ints and increases natural record
alignment to doubleword if the first field is an FP double while
the FP fields remain word aligned.

GET_MODE_ALIGNMENT is defined as below in rtl.c, and will cause
the mode alignment for doubles to be 64 bits, which is wrong.
I wonder how this is supposed to work and how this should be fixed.
Should I write a new get_darwin_mode_alignment that returns
32 for double and calls get_mode_alignment otherwise,
or am I completely wrong here?

   -Geert

> /* Return the alignment of MODE. This will be bounded by 1 and
>    BIGGEST_ALIGNMENT.  */
>
> unsigned int
> get_mode_alignment (mode)
>      enum machine_mode mode;
> {
>   unsigned int alignment = GET_MODE_UNIT_SIZE (mode);
>   /* Extract the LSB of the size.  */
                   ^^^ shouldn't this be MSB (most significant bit)?
>   alignment = alignment & -alignment;
>   alignment *= BITS_PER_UNIT;
>
>   alignment = MIN (BIGGEST_ALIGNMENT, MAX (1, alignment));
>   return alignment;
> }