Am Montag, dem 17.03.2025 um 23:25 +0000 schrieb Joseph Myers:
> On Sun, 16 Mar 2025, Martin Uecker wrote:
>
> > This is a workaround for another issue related to PR118765.
> > I do not yet understand what goes wrong in merge_decls in
> > this case (somehow we end up with TYPE_DECLS where
> > DECL_ORIGINAL_TYPE is not set correctly, so we can not
> > determine the correct tag later), so I do not merge
> > these TYPE_DECLS in this specific case as a workaround
> > and add a "sorry" for the alignment case (or should this
> > simply become an error?).
>
> I'm not convinced a workaround for something not understood is a good idea
> here.
Me neither, but it would be a safe short-term fix
by avoiding the dangerous scenario.
> I think different alignment should be considered different types, so an
> error.
We currently allow different alignment to be added in typedefs
as in the new typedef-redecl3.c test:
#define N 64
struct f { int x; };
typedef struct f T;
typedef struct f T __attribute__((aligned (N)));
typedef struct f T __attribute__((aligned (N * 2)));
typedef struct f T __attribute__((aligned (N)));
typedef struct f T;
_Static_assert (_Alignof (T) == N * 2, "N * 2");
The case that would not work with the patch when skipping
merge_decl is the following where we redefine the struct
(so no existing code affected)
#define N 64
typedef struct f { int x; } T;
typedef struct f { int x; } T __attribute__((aligned (N)));
typedef struct f { int x; } T __attribute__((aligned (N * 2)));
typedef struct f { int x; } T __attribute__((aligned (N)));
typedef struct f { int x; } T;
_Static_assert (_Alignof (T) == N * 2, "N * 2");
So there are three choices:
- make both an error
- make only the second scenario an error
- make it work by using merge_decl with a suitable fix.
(there might be other issues related to not calling merge_decl,
e.g. merging of attributes)
Martin
