On Mon, Nov 18, 2013 at 1:11 PM, Bernd Edlinger
wrote:
> Hi,
>
>
> This modified test case exposes a bug in the already approved part of the
> strict-volatile-bitfields patch:
>
> #include
>
> typedef struct {
> char pad;
> int arr[0];
> } __attribute__((packed)) str;
>
> str *
> foo (int* s
Hi,
This modified test case exposes a bug in the already approved part of the
strict-volatile-bitfields patch:
#include
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
str *
foo (int* src)
{
str *s = malloc (sizeof (str) + sizeof (int));
s->arr[0] = 0x12345678;
On Fri, Nov 15, 2013 at 2:24 PM, Bernd Edlinger
wrote:
>>
>> But then why is the mode QImode in the first place? The access is
>> definitely of SImode.
>>
>
> that's in the test case:
>
> s->arr[0] = 0x12345678;
>
>
> it is QImode from that in expand_assignment:
>
> to_rtx = expand_expr (t
>
> But then why is the mode QImode in the first place? The access is
> definitely of SImode.
>
that's in the test case:
s->arr[0] = 0x12345678;
it is QImode from that in expand_assignment:
to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
tem is "s", a MEM_REF, of QImode,
On Fri, Nov 15, 2013 at 1:08 PM, Bernd Edlinger
wrote:
>>>
>>> hmm...
>>> the above change is just not aggressive enough.
>>>
>>>
>>> with a slightly changed test case I have now got a
>>> recursion on the extract_fixed_bit_fields on ARM but
>>> interestingly not on powerpc:
>>>
>>> #include
>>>
>>
>> hmm...
>> the above change is just not aggressive enough.
>>
>>
>> with a slightly changed test case I have now got a
>> recursion on the extract_fixed_bit_fields on ARM but
>> interestingly not on powerpc:
>>
>> #include
>>
>> typedef struct {
>> char pad;
>> int arr[0];
>> } __attribute__(
On Fri, Nov 15, 2013 at 10:28 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote:
>>
>> On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> sorry, for the delay.
>>> Sandra seems to be even more busy than me...
>>>
>>> Attached is a combi
Hi,
On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote:
>
> On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> sorry, for the delay.
>> Sandra seems to be even more busy than me...
>>
>> Attached is a combined patch of the original part 1, and the update,
>> in diff -up format
On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
wrote:
> Hi,
>
> sorry, for the delay.
> Sandra seems to be even more busy than me...
>
> Attached is a combined patch of the original part 1, and the update,
> in diff -up format.
>
> On Mon, 11 Nov 2013 13:10:45, Richard Biener wrote:
>>
>> On Thu
Hi,
sorry, for the delay.
Sandra seems to be even more busy than me...
Attached is a combined patch of the original part 1, and the update,
in diff -up format.
On Mon, 11 Nov 2013 13:10:45, Richard Biener wrote:
>
> On Thu, Oct 31, 2013 at 1:46 AM, Sandra Loosemore
> wrote:
>> On 10/29/2013 02:
On Thu, Oct 31, 2013 at 1:46 AM, Sandra Loosemore
wrote:
> On 10/29/2013 02:51 AM, Bernd Edlinger wrote:
>>
>>
>> On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
>>>
>>> On 10/28/2013 03:20 AM, Bernd Edlinger wrote:
I have attached an update to your patch, that should
a) fix t
On 10/29/2013 02:51 AM, Bernd Edlinger wrote:
On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
On 10/28/2013 03:20 AM, Bernd Edlinger wrote:
I have attached an update to your patch, that should
a) fix the recursion problem.
b) restrict the -fstrict-volatile-bitfields to not violate the C+
On 10/29/2013 02:51 AM, Bernd Edlinger wrote:
On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
I again tried backporting the patch series along with your fix to GCC
4.8 and tested on arm-none-eabi. I found that it was still getting
stuck in infinite recursion unless the test from this patc
Hi,
On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
>
> On 10/28/2013 03:20 AM, Bernd Edlinger wrote:
>>
>> On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
>>>
>>> I tried a backport to GCC 4.8 and tested on arm-none-eabi. On the new
>>> pr56997-1.c testcase, it got stuck in infinite r
On 10/28/2013 03:20 AM, Bernd Edlinger wrote:
On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
I tried a backport to GCC 4.8 and tested on arm-none-eabi. On the new
pr56997-1.c testcase, it got stuck in infinite recursion between
store_split_bit_field/store_fixed_bit_field and/or
extract_
Hi Sandra,
On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
>
> On 10/18/2013 10:38 AM, Richard Biener wrote:
>> Sandra Loosemore wrote:
>>> On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
wrote:
> This patch fixes various -fstr
Hi,
On Wed, 23 Oct 2013 14:37:43, Richard Biener wrote:
> The C++ memory model says that you may not introduce a data-race
> and thus you have to access Type without touching Prefix.
Thanks.
Right now I see the following priorities:
1. make -fno-strict-volatile-bitfields respect the C++ memory
On Wed, Oct 23, 2013 at 9:11 AM, Bernd Edlinger
wrote:
> Hi Richard/Joseph,
>
> I noticed, this test case crashes on arm-eabi already witout the patch.
>
> extern void abort (void);
>
> #define test_type unsigned short
> #define MAGIC (unsigned short)0x102u
>
> typedef struct s{
> unsigned char P
Hi Richard/Joseph,
I noticed, this test case crashes on arm-eabi already witout the patch.
extern void abort (void);
#define test_type unsigned short
#define MAGIC (unsigned short)0x102u
typedef struct s{
unsigned char Prefix[1];
test_type Type;
}__attribute((__packed__,__aligned__(4))) ss;
Well,
one more point where the current patch is probably wrong:
the AAPCS states that for volatile bit-field access:
"For a write operation the read must always occur even if the entire contents
of the container will be replaced"
that means
struct s
{
volatile int a:32;
} ss;
ss.a=1; //nee
>
>> 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
Hi,
On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
> Hr. After some further testing, I'm afraid this patch is still
> buggy. :-(
>
> I tried a backport to GCC 4.8 and tested on arm-none-eabi. On the new
> pr56997-1.c testcase, it got stuck in infinite recursion between
> store_split_bit
> 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
On 10/18/2013 10:38 AM, Richard Biener wrote:
Sandra Loosemore wrote:
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
wrote:
This patch fixes various -fstrict-volatile-bitfields wrong-code
bugs,
including instances where bitfield values were
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
Sandra Loosemore wrote:
>On 10/18/2013 04:50 AM, Richard Biener wrote:
>> On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
>> wrote:
>>> This patch fixes various -fstrict-volatile-bitfields wrong-code
>bugs,
>>> including instances where bitfield values were being quietly
>truncated as
>>> well
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
wrote:
This patch fixes various -fstrict-volatile-bitfields wrong-code bugs,
including instances where bitfield values were being quietly truncated as
well as bugs relating to using the wrong width.
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
wrote:
> This patch fixes various -fstrict-volatile-bitfields wrong-code bugs,
> including instances where bitfield values were being quietly truncated as
> well as bugs relating to using the wrong width. The code changes are
> identical to those
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
On Fri, Jun 14, 2013 at 6:31 PM, Sandra Loosemore
wrote:
> On 06/14/2013 06:31 AM, Richard Biener wrote:
>
>> I think we can split the patch up, so let me do piecewise approval of
>> changes.
>>
>> The changes that remove the packedp flag passing around and remove
>> the warning code are ok. The
On 06/14/2013 06:31 AM, Richard Biener wrote:
I think we can split the patch up, so let me do piecewise approval of changes.
The changes that remove the packedp flag passing around and remove
the warning code are ok. The store_bit_field_1 change is ok, as is
the similar extract_bit_field_1 cha
On Wed, Jun 12, 2013 at 11:59 PM, Sandra Loosemore
wrote:
> Background: on ARM and some other targets, the ABI requires that volatile
> bit-fields be accessed atomically in a mode that corresponds to the declared
> type of the field, which conflicts with GCC's normal behavior of doing
> accesses
47 matches
Mail list logo
