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
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 in the previous version of this patch series
(originally poste
26 matches
Mail list logo
