Re: [PATCH] Pad SEC_MERGE sections to entsize boundary in gas

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Nov 25, 2002 at 12:40:38AM -0800, Ulrich Drepper wrote:
> >>This is presumably just due to lack of alignment padding after the
> >>last entry, right?  Otherwise the merge code would be rather
> >>confused...
> > 
> > 
> > Yeah. gcc emits something like:
> >         .section        .rodata.cst16,"aM",@progbits,16
> >         .align 16
> > .LC0:
> >         .long   0
> >         .long   -939524096
> >         .long   16389
> > for long double constants and doesn't put there another .align 16
> > after it (or another .long 0).
> 
> I actually believe it is gcc's fault.
> 
> Why should every entry in a .rodata.cst16 section have .align 16?

The IA-32 backend has sizeof(long double) == 12 and
__alignof__(long double) == 16 if it is a real constant or variable (ie.
outside of structures/unions/arrays), that's why it emits just 3 .long's and
.align 16. .rodata.cst16 is chosen because the alignment affects the
real constant sizes (.rodata.cst12 would be wrong).

> Alignment and size are two different issues.
> 
> gcc should emit the padding word, too.

Yeah, I already told Alan in private I'm going to look at gcc today.
But IMHO gas can do this too, if not for something else than for
compatibility with gcc 3.[12].

	Jakub