On Mon, Nov 18, 2013 at 1:11 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
This modified test case exposes a bug in the already approved part of the
strict-volatile-bitfields patch:
#include stdlib.h
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
Hi,
This modified test case exposes a bug in the already approved part of the
strict-volatile-bitfields patch:
#include stdlib.h
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
str *
foo (int* src)
{
str *s = malloc (sizeof (str) + sizeof (int));
s-arr[0] =
Hi,
On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote:
On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
bernd.edlin...@hotmail.de 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
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 stdlib.h
typedef struct {
char pad;
int arr[0];
} __attribute__((packed)) str;
str
On Fri, Nov 15, 2013 at 1:08 PM, Bernd Edlinger
bernd.edlin...@hotmail.de 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 stdlib.h
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 2:24 PM, Bernd Edlinger
bernd.edlin...@hotmail.de 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 =
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
san...@codesourcery.com wrote:
On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
bernd.edlin...@hotmail.de 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
On Thu, Oct 31, 2013 at 1:46 AM, Sandra Loosemore
san...@codesourcery.com 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
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
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 recursion
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
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 san...@codesourcery.com wrote:
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
san...@codesourcery.com 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 recursion between
store_split_bit_field/store_fixed_bit_field and/or
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;
On Wed, Oct 23, 2013 at 9:11 AM, Bernd Edlinger
bernd.edlin...@hotmail.de 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{
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
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;
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
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
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
Bernd Edlinger bernd.edlin...@hotmail.de 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
On 10/18/2013 10:38 AM, Richard Biener wrote:
Sandra Loosemore san...@codesourcery.com wrote:
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
san...@codesourcery.com wrote:
This patch fixes various -fstrict-volatile-bitfields wrong-code
bugs,
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,
On Wed, Oct 9, 2013 at 3:09 AM, Bernd Edlinger
bernd.edlin...@hotmail.de 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
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 without
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
san...@codesourcery.com 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
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
san...@codesourcery.com 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
Sandra Loosemore san...@codesourcery.com wrote:
On 10/18/2013 04:50 AM, Richard Biener wrote:
On Sat, Sep 28, 2013 at 4:19 AM, Sandra Loosemore
san...@codesourcery.com wrote:
This patch fixes various -fstrict-volatile-bitfields wrong-code
bugs,
including instances where bitfield values were
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, the
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.
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
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 is
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.
At
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 the user
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 conflicts errors
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
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
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.
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, the
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
Here is the latest version of my -fstrict-volatile-bitfields patches.
I have gone ahead and committed part 1 of the previous version of this
patch series, which was approved back in mid-June. That part just
removes the warning about conflicts with packed structs (which everybody
seemed to
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
This patch makes -fstrict-volatile-bitfields not be the default on any
target. It is unchanged from part 4 of the previous version (v3) of
this patch set that I originally posted back in June and have been
re-pinging many times since then.
Some reviewers of my original patch series argued
On Fri, Jun 14, 2013 at 6:31 PM, Sandra Loosemore
san...@codesourcery.com 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
On Wed, Jun 12, 2013 at 11:59 PM, Sandra Loosemore
san...@codesourcery.com 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
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
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 in a mode that might correspond to the size
of a
50 matches
Mail list logo
