Revisiting max_align_t and stdalign.h

Revisiting max_align_t and stdalign.h

[Rich Felker]

I was looking back at the max_align_t issue and there seems to be a
lot more to resolve: gcc is badly broken in regards to everything
related to stdalign.h. This test program on i386:

#include <stdalign.h>
#include <stdio.h>

int main()
{
	long long x;
	printf("%d %d\n", (int)_Alignof(x), (int)_Alignof(long long));
}

prints 8 8 on most gcc versions, and what's worse, its behavior
depends on -std; adding -std=c11 and using gcc 4.9.0 changes it to
printing 8 4. The correct result of course would be 4 4.

I had in mind the following patch for stdalign.h:

diff --git a/include/stdalign.h b/include/stdalign.h
index b6e50ae..3f00466 100644
--- a/include/stdalign.h
+++ b/include/stdalign.h
@@ -4,7 +4,7 @@
 /* this whole header only works in C11 or with compiler extensions */
 #if __STDC_VERSION__ < 201112L && defined( __GNUC__)
 #define _Alignas(t) __attribute__((__aligned__(t)))
-#define _Alignof(t) __alignof__(t)
+#define _Alignof(t) (sizeof(struct {char __x; __typeof__(t) __y;}) - sizeof(t))
 #endif
 
 #define alignas _Alignas

but it doesn't really help since _Alignof is broken even with
-std=c11.

I suspect _Alignas is similarly broken.

The only "solution" I see is adopting stdc-predef.h and putting
#defines for _Alignof and _Alignas in there for all __GNUC__ compilers
earlier than the first version of gcc that gets fixed. I've wanted to
add stdc-predef.h for a while anyway to define things like
__STDC_ISO_10646__ but since it's only auto-included for gcc 4.8 and
later, we should either patch earlier gcc's to add it or just throw
"-include stdc-predef.h" into the specfile (of course this is outside
the scope of musl itself).

Rich

Re: Revisiting max_align_t and stdalign.h

[Rich Felker]

On Sun, Jun 08, 2014 at 10:59:24AM -0400, Rich Felker wrote:
> I was looking back at the max_align_t issue and there seems to be a
> lot more to resolve: gcc is badly broken in regards to everything
> related to stdalign.h. This test program on i386:
> 
> #include <stdalign.h>
> #include <stdio.h>
> 
> int main()
> {
> 	long long x;
> 	printf("%d %d\n", (int)_Alignof(x), (int)_Alignof(long long));
> }
> 
> prints 8 8 on most gcc versions, and what's worse, its behavior
> depends on -std; adding -std=c11 and using gcc 4.9.0 changes it to
> printing 8 4. The correct result of course would be 4 4.

My tests must have been messed up here; apparently gcc 4.9.0 works
even without -std=c11. So a workaround that applies only to versions
earlier than 4.9 should be possible.

Moreover it appears that _Alignof is not required to accept
expressions as its argument, only types. If this is correct then 4.9.0
is working, albeit doing something ugly in the case of invalid code.

> I had in mind the following patch for stdalign.h:
> 
> diff --git a/include/stdalign.h b/include/stdalign.h
> index b6e50ae..3f00466 100644
> --- a/include/stdalign.h
> +++ b/include/stdalign.h
> @@ -4,7 +4,7 @@
>  /* this whole header only works in C11 or with compiler extensions */
>  #if __STDC_VERSION__ < 201112L && defined( __GNUC__)
>  #define _Alignas(t) __attribute__((__aligned__(t)))
> -#define _Alignof(t) __alignof__(t)
> +#define _Alignof(t) (sizeof(struct {char __x; __typeof__(t) __y;}) - sizeof(t))
>  #endif
>  
>  #define alignas _Alignas
> 
> but it doesn't really help since _Alignof is broken even with
> -std=c11.
> 
> I suspect _Alignas is similarly broken.

And _Alignas might be broken even on current gcc -- it accepts not
just types but also expressions. However it's not clear to me whether
it can even be used in contexts where it would be observably wrong, so
I don;t know how to write a test for it. IIRC there's an open issue
about whether it can be used in structs, or only on objects.

Rich

Re: Revisiting max_align_t and stdalign.h

[Rich Felker]

On Sun, Jun 08, 2014 at 11:54:41AM -0400, Rich Felker wrote:
> > I suspect _Alignas is similarly broken.
> 
> And _Alignas might be broken even on current gcc -- it accepts not
> just types but also expressions. However it's not clear to me whether

Never mind; I was being stupid. The expression argument to _Alignas is
a value for the alignment, not an expression whose type is used.

Rich