>
>> have an option for true AAPCS compliance, which will
>> be allowed to break the C++11 memory model and
>
>> And an option that addresses your requirements,
>> which will _not_ break the C++11 memory model
>
> So the problem isn't that what *I* need conflicts with C++11, it's
> that what AAPCS
> have an option for true AAPCS compliance, which will
> be allowed to break the C++11 memory model and
> And an option that addresses your requirements,
> which will _not_ break the C++11 memory model
So the problem isn't that what *I* need conflicts with C++11, it's
that what AAPCS needs confl
Bernd Edlinger wrote:
>Hi,
>
>>> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
>>
>> Why a new option? The -fstrict-volatile-bitfields option is already
>> GCC-specific, and I think it can do what you want anyway.
>
>As I understand Richard's comment, he proposes to
>have an o
Hi,
>> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
>
> Why a new option? The -fstrict-volatile-bitfields option is already
> GCC-specific, and I think it can do what you want anyway.
As I understand Richard's comment, he proposes to
have an option for true AAPCS compliance,
> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
Why a new option? The -fstrict-volatile-bitfields option is already
GCC-specific, and I think it can do what you want anyway.
> We use the container mode where possible.
> It is always possible for well-formed bit-fields.
This is the only part I really need.
> If necessary the user has to add anonymous bit field members, or
> convert normal members to bit-fields.
IIRC I added code to support normal members as well, th
Hi,
On Thu, 17 Oct 2013 16:41:13, DJ Delorie wrote:
> I'm starting from an MCU that doesn't work right if GCC doesn't do
> what the user tells GCC to do. I added -fstrict-volatile-bitfields to
> tell gcc that it needs to be more strict than the standard allows for
> bitfield access, because withou
On Wed, Oct 9, 2013 at 3:09 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Mon, 30 Sep 2013 16:18:30, DJ Delorie wrote:
>>
>> As per my previous comments on this patch, I will not approve the
>> changes to the m32c backend, as they will cause real bugs in real
>> hardware, and violate the hardware's ABI.
I'm starting from an MCU that doesn't work right if GCC doesn't do
what the user tells GCC to do. I added -fstrict-volatile-bitfields to
tell gcc that it needs to be more strict than the standard allows for
bitfield access, because without that flag, there's no way to force
gcc to use a specific
On Thu, 17 Oct 2013, DJ Delorie wrote:
> > At least on ARM, you can e.g. have a non-bit-field "char" that occupies
> > part of the same 4-byte unit as an "int" bit-field.
>
> Ok, "when the user doesn't give the compiler conflicting requirements."
> (which is why I contemplated making those confl
> At least on ARM, you can e.g. have a non-bit-field "char" that occupies
> part of the same 4-byte unit as an "int" bit-field.
Ok, "when the user doesn't give the compiler conflicting requirements."
(which is why I contemplated making those conflicts errors at first)
I'm a big fan of blaming t
On Thu, 17 Oct 2013, DJ Delorie wrote:
> > 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.
>
> Are we talking about N2429? I read through the changes and it didn't
> preclude honoring the user's types.
> where in the C standard did you read the requirement that every bit
> field must be complete? (This is a serious question).
The spec doesn't say each field must be complete, but neither does it
say that the structure must be as big as the type used. If you
specify "int foo:1" then the compile
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
> I'm curious; do all the test cases included in
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
> work for you on those targets as well (without applying the rest of the
> patch)?
Not all of them can work, because they describe something that can't
be done in hardware. For example, t
On 10/16/2013 05:46 PM, DJ Delorie wrote:
As it looks like, the -fstrict-volatile-bitfields are already totally broken,
I tested your example on rl78-elf, with and without
-fstrict-volatile-bitfields, and it generates correct code with it and
incorrect code without it. Same for m32c-elf. Sa
> As it looks like, the -fstrict-volatile-bitfields are already totally broken,
I tested your example on rl78-elf, with and without
-fstrict-volatile-bitfields, and it generates correct code with it and
incorrect code without it. Same for m32c-elf. Same for h8300-elf.
Seems to be working OK for
Hi,
On Mon, 30 Sep 2013 16:18:30, DJ Delorie wrote:
>
> As per my previous comments on this patch, I will not approve the
> changes to the m32c backend, as they will cause real bugs in real
> hardware, and violate the hardware's ABI. The user may use
> -fno-strict-volatile-bitfields if they do not
As per my previous comments on this patch, I will not approve the
changes to the m32c backend, as they will cause real bugs in real
hardware, and violate the hardware's ABI. The user may use
-fno-strict-volatile-bitfields if they do not desire this behavior and
understand the consequences.
I am
19 matches
Mail list logo
