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
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
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
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
25 matches
Mail list logo
