Re: asking for __attribute__((aligned()) clarification
On Wed, 21 Aug 2019 at 17:50, Paul Koning wrote: > > > > > On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote: > > > > On Wed, 21 Aug 2019, Paul Koning wrote: > > > >> I agree, but if the new approach generates a warning for code that was > >> written > >> to the old rules, that would be unfortunate. > > > > FWIW I don't know which GCC versions accepted 'packed' on a scalar type. > > That wasn't what I meant; I was talking about the packed and aligned > attributes on struct members. I thought you were saying that > ((packed,aligned(2))) is now a warning. That doesn't appear to be the case, > though; it's accepted without complaint as it always was. Right, nobody's suggesting that should be a warning. The warning is for trying to pack a scalar variable, which is (and always was) meaningless.
Re: asking for __attribute__((aligned()) clarification
> On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote: > > On Wed, 21 Aug 2019, Paul Koning wrote: > >> I agree, but if the new approach generates a warning for code that was >> written >> to the old rules, that would be unfortunate. > > FWIW I don't know which GCC versions accepted 'packed' on a scalar type. That wasn't what I meant; I was talking about the packed and aligned attributes on struct members. I thought you were saying that ((packed,aligned(2))) is now a warning. That doesn't appear to be the case, though; it's accepted without complaint as it always was. paul
Re: asking for __attribute__((aligned()) clarification
On Wed, 21 Aug 2019, Paul Koning wrote: > I agree, but if the new approach generates a warning for code that was written > to the old rules, that would be unfortunate. FWIW I don't know which GCC versions accepted 'packed' on a scalar type. Already in 2006 GCC 3.4 would issue a warning: $ echo 'typedef int ui __attribute__((packed));' | gcc34 -xc - -S -o- .file "" :1: warning: `packed' attribute ignored .section.note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.4.6 20060404 (Red Hat 3.4.6-4)" > Yes. But last I tried, optimizing that for > 1 alignment is problematic > because that information often doesn't make it down to the target code even > though it is documented to do so. Thanks, indeed this memcpy solution is not so well suited for that. Alexander
Re: asking for __attribute__((aligned()) clarification
> On Aug 21, 2019, at 10:28 AM, Alexander Monakov wrote: > > On Tue, 20 Aug 2019, "Markus Fröschle" wrote: > >> Thank you (and others) for your answers. Now I'm just as smart as before, >> however. >> >> Is it a supported, documented, 'long term' feature we can rely on or not? >> >> If yes, I would expect it to be properly documented. If not, never mind. > > I think it's properly documented in gcc-9: > > https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html > > (the "old" behavior where the compiler would neither honor reduced alignment > nor issue a warning seems questionable, the new documentation promises a more > sensible approach) I agree, but if the new approach generates a warning for code that was written to the old rules, that would be unfortunate. > In portable code one can also use memcpy to move unaligned data, the compiler > should translate it like an unaligned load/store when size is a suitable > constant: > > int val; > memcpy(, ptr, sizeof val); > > (or __builtin_memcpy when -ffreestanding is in effect) Yes. But last I tried, optimizing that for > 1 alignment is problematic because that information often doesn't make it down to the target code even though it is documented to do so. paul
Re: Aw: Re: asking for __attribute__((aligned()) clarification
On Tue, 20 Aug 2019, "Markus Fröschle" wrote: > Thank you (and others) for your answers. Now I'm just as smart as before, > however. > > Is it a supported, documented, 'long term' feature we can rely on or not? > > If yes, I would expect it to be properly documented. If not, never mind. I think it's properly documented in gcc-9: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html (the "old" behavior where the compiler would neither honor reduced alignment nor issue a warning seems questionable, the new documentation promises a more sensible approach) In portable code one can also use memcpy to move unaligned data, the compiler should translate it like an unaligned load/store when size is a suitable constant: int val; memcpy(, ptr, sizeof val); (or __builtin_memcpy when -ffreestanding is in effect) Alexander
Aw: Re: asking for __attribute__((aligned()) clarification
Thank you (and others) for your answers. Now I'm just as smart as before, however. Is it a supported, documented, 'long term' feature we can rely on or not? If yes, I would expect it to be properly documented. If not, never mind. > Gesendet: Montag, 19. August 2019 um 16:08 Uhr > Von: "Alexander Monakov" > An: "Richard Earnshaw (lists)" > Cc: "Paul Koning" , "Markus Fröschle" > , gcc@gcc.gnu.org > Betreff: Re: asking for __attribute__((aligned()) clarification > > On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote: > > > Correct, but note that you can only pack structs and unions, not basic > > types. > > there is no way of under-aligning a basic type except by wrapping it in a > > struct. > > I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been > significantly revised, and now ends with > > When used as part of a typedef, the aligned attribute can both increase and > decrease alignment, and specifying the packed attribute generates a > warning. > > (but I'm sure defacto behavior of accepting and honoring reduced alignment on > a typedef'ed scalar type goes way earlier than gcc-9) > > Alexander >
Re: asking for __attribute__((aligned()) clarification
> On Aug 19, 2019, at 10:08 AM, Alexander Monakov wrote: > > On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote: > >> Correct, but note that you can only pack structs and unions, not basic types. >> there is no way of under-aligning a basic type except by wrapping it in a >> struct. > > I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been > significantly revised, and now ends with > > When used as part of a typedef, the aligned attribute can both increase and > decrease alignment, and specifying the packed attribute generates a warning. > > (but I'm sure defacto behavior of accepting and honoring reduced alignment on > a typedef'ed scalar type goes way earlier than gcc-9) Interesting. It certainly wasn't that way a decade ago. And for the old code pattern to generate a warning seems like a bad incompatible change. Honoring reducing alignments is one thing, complaining about packed is not good. paul
Re: asking for __attribute__((aligned()) clarification
On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote: > Correct, but note that you can only pack structs and unions, not basic types. > there is no way of under-aligning a basic type except by wrapping it in a > struct. I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been significantly revised, and now ends with When used as part of a typedef, the aligned attribute can both increase and decrease alignment, and specifying the packed attribute generates a warning. (but I'm sure defacto behavior of accepting and honoring reduced alignment on a typedef'ed scalar type goes way earlier than gcc-9) Alexander
Re: asking for __attribute__((aligned()) clarification
On 19/08/2019 14:57, Paul Koning wrote:
On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t __attribute__((aligned(1)));
uint32_t getuuint32(uint8_t p[]) {
return *(uuint32_t*)p;
}
This is meant to prevent gcc to produce hard faults/address errors on
architectures that do not support unaligned access to shorts/ints (e.g some
ARMs, some m68k). On these architectures, gcc is supposed to replace the 32 bit
access with a series of 8 or 16 bit accesses.
I originally came from gcc 4.6.4 (yes, pretty old) where this did not work and
gcc does not respect the aligned(1) attribute for its code generation (i.e. it
generates a 'normal' pointer dereference, consequently crashing when the code
executes). To be fair, it is my understanding that the gcc manuals never
promised this *would* work.
That has never been my understanding. I've always read the manual to say that "aligned"
only INCREASES the alignment. The normal alignment is that specified by the ABI for the given data
type (often, but not always, the size of the primitive type) -- or it is 1 for "packed".
So I use __attribute__ ((packed)) to request byte alignment, and, say,
__attribute__ ((packed, aligned(2))) to specify alignment to 2 byte multiples.
paul
Correct, but note that you can only pack structs and unions, not basic
types. there is no way of under-aligning a basic type except by
wrapping it in a struct.
R.
Re: asking for __attribute__((aligned()) clarification
> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
>
> All,
>
> this is my first post on these lists, so please bear with me.
>
> My question is about gcc's __attribute__((aligned()). Please consider the
> following code:
>
> #include
>
> typedef uint32_t uuint32_t __attribute__((aligned(1)));
>
> uint32_t getuuint32(uint8_t p[]) {
>return *(uuint32_t*)p;
> }
>
> This is meant to prevent gcc to produce hard faults/address errors on
> architectures that do not support unaligned access to shorts/ints (e.g some
> ARMs, some m68k). On these architectures, gcc is supposed to replace the 32
> bit access with a series of 8 or 16 bit accesses.
>
> I originally came from gcc 4.6.4 (yes, pretty old) where this did not work
> and gcc does not respect the aligned(1) attribute for its code generation
> (i.e. it generates a 'normal' pointer dereference, consequently crashing when
> the code executes). To be fair, it is my understanding that the gcc manuals
> never promised this *would* work.
That has never been my understanding. I've always read the manual to say that
"aligned" only INCREASES the alignment. The normal alignment is that specified
by the ABI for the given data type (often, but not always, the size of the
primitive type) -- or it is 1 for "packed".
So I use __attribute__ ((packed)) to request byte alignment, and, say,
__attribute__ ((packed, aligned(2))) to specify alignment to 2 byte multiples.
paul
