On 04/17/2014 02:00 AM, Tristan Gingold wrote: > > On 16 Apr 2014, at 17:36, Richard Henderson <r...@redhat.com> wrote: > >> On 04/16/2014 12:39 AM, Eric Botcazou wrote: >>>> The primary bit of rfc here is the hunk that applies to ada/types.h >>>> with respect to Fat_Pointer. Given that the Ada type, as defined in >>>> s-stratt.ads, does not include alignment, I can't imagine why the C >>>> type should have it. >>> >>> See gcc-interface/utils.c:finish_fat_pointer_type. >> >> Ah hah. >> >> /* Make sure we can put it into a register. */ >> if (STRICT_ALIGNMENT) >> TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE); >> >> AArch64 is not a STRICT_ALIGNMENT target, thus the mismatch. > > As the align attribute in types.h is for the host, couldn't a configure test > solve > this issue ?
I doubt it. I'm not sure what kind of configure test you could write that would determine the setting of STRICT_ALIGNMENT, since even non-strict-align targets prefer to align data for performance reasons. Be careful that the test couldn't be an execution test, lest you break host != build. > One of the most common Fat_Pointer is for strings, which aren't declared in > any > source and is very commonly used. > > OTOH, I think this optimization mostly targets sparc. Indeed, 32-bit sparc wants 64-bit alignment for its ldd/std instructions. Perhaps the better optimization (supposing it's really worth keeping) is to DECL_ALIGN the static strings, rather than align the type? Presumably Ada strings are as with C string literals -- symbols private to the compilation unit which are normally passed by value. Thus functions within the compilation unit would see the extra alignment of the data and be able to use ldd to load the pair. On the receiving end being able to use std would remain a matter of luck. r~
