This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 2/2


On Wed, 16 Oct 2013 22:50:20, DJ Delorie wrote:
> Not all of them can work, because they describe something that can't
> be done in hardware. For example, the first test has an incomplete
> bitfield - the fields do not completely describe an "int" so the
> structure is smaller (one byte, according to sizeof()) than the access
> type (2-8 bytes).
>

where in the C standard did you read the requirement that every bit
field must be complete? (This is a serious question).
extern struct
{
  volatile unsigned int b : 1;
} bf3;

on my compiler this structure occupies 4 bytes.
and it is aligned at 4 bytes.
That is OK for me and AAPCS.

But the access "bf3.b=1" is SI mode with Sandra's patch (part 1, which just
obeys the AAPCS and does nothing else) 
and QI mode without this patch, which is just a BUG.
I am quite surprised how your target manages to avoid it?

It is as Sandra said, at least on ARM -fstrict-volatile-bitfields
does not function at all. And the C++11 memory model wins all the time.

> Looking through the tests, most of them combine "packed" with
> mismatched types. IMHO, those tests are invalid.

I dont think so. They are simply packed. And volatile just says that
the value may be changed by a different thread. It has a great
impact on loop optimizations.

>>> Either way, if -fstrict-volatile-bitfields does not do what it's
>>> supposed to do, the correct action is to fix it - not to disable it on
>>> targets that rely on it for correct operation.

Agreed. That is the number one priority here.

>...
> I've not objected to fixing -fstrict-volatile-bitfields, or making the
> -fno-strict-volatile-bitfields case match the standard. I've only
> objected to breaking my targets by making that flag not the default.

Fine. Why cant we just get this fixed?

Bernd. 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]