This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Hans-Peter Nilsson <hp at bitrange dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Mikael Pettersson <mikpelinux at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, DJ Delorie <dj at redhat dot com>
- Date: Wed, 18 Mar 2015 08:33:14 +0100
- Subject: RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W288F9097DAAF6E3E544713E41E0 at phx dot gbl> <21764 dot 10369 dot 17958 dot 785770 at gargle dot gargle dot HOWL> <DUB118-W10A20C4AFFB15467401C58E4040 at phx dot gbl> <4127610 dot 3C9fpy1YJk at polaris>,<alpine dot BSF dot 2 dot 02 dot 1503162005410 dot 52840 at arjuna dot pair dot com>
Hi,
On Mon, 16 Mar 2015 20:31:53, Hans-Peter Nilsson wrote:
>
> On Mon, 16 Mar 2015, Eric Botcazou wrote:
>>> If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
>>> architecture. I doubt that the strict alignment code makes any sense for
>>> modesize> BIGGEST_ALIGNMENT.
>>
>> Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition of
>> BIGGEST_ALIGNMENT, not honoring an alignment larger than it is perfectly OK.
>
> The context of the above statement is somewhat ambiguous: if the
> statement is taken to include "no matter what is specified in
> the program, including use of __attribute__ ((__aligned__ ...))"
> then I have to object. (I guess Eric, you didn't actually mean
> that, though.)
>
> The definition of BIGGEST_ALIGNMENT is (tm.texi.in):
> "Biggest alignment that any data type can require on this
> machine, in bits. Note that this is not the biggest alignment
> that is supported, just the biggest alignment that, when
> violated, may cause a fault."
>
> So, IMNSHO we'd better *support* a *larger* alignment, as in "if
> the code specified it by explicit means" at least up to
> MAX_OFILE_ALIGNMENT. But, "perfectly OK" when the code didn't
> explicitly say anything else.
>
Absolutely.
The idea if this patch, is to *require* the use of __attribute__((__aligned__(x)))
for all structures that need the strict volatile bitfields semantics.
At least if the ABI has BIGGEST_ALIGNMENT<BITS_PER_WORD.
I don't see any alternative.
Thanks
Bernd.