Hi,
On Mon, 30 Mar 2015 12:33:47, Richard Biener wrote:
>
> On Mon, Mar 16, 2015 at 11:53 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>>
>> when looking at the m68k I realized the following, which is
>> a general problem...
>>
>> If the alignment of the structure is less than sizeof(field), the
>> s
On Mon, Mar 16, 2015 at 11:53 AM, Bernd Edlinger
wrote:
>
> Hi,
>
>
> when looking at the m68k I realized the following, which is
> a general problem...
>
> If the alignment of the structure is less than sizeof(field), the
> strict volatile bitfields code may read beyond the end of the
> structure
Hi,
On Mon, 16 Mar 2015 20:31:53, Hans-Peter Nilsson wrote:
>
> On Mon, 16 Mar 2015, Eric Botcazou wrote:
>>> If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
>>> architecture. I doubt that the strict alignment code makes any sense for
>>> modesize> BIGGEST_ALIGNMENT.
>>
>> Note
On Tue, 17 Mar 2015, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
> > Q: So why not adjust the BIGGEST_ALIGNMENT definition in such
> > targets to be at least the natural alignment of supported
> > atomic types?
>
> A: Because it's an ABI change.
I intended that to be included in "bad eff
Hans-Peter Nilsson writes:
> Q: So why not adjust the BIGGEST_ALIGNMENT definition in such
> targets to be at least the natural alignment of supported
> atomic types?
A: Because it's an ABI change.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 175
On Mon, 16 Mar 2015, Eric Botcazou wrote:
> > If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
> > architecture. I doubt that the strict alignment code makes any sense for
> > modesize> BIGGEST_ALIGNMENT.
>
> Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition
Hi,
when looking at the m68k I realized the following, which is
a general problem...
If the alignment of the structure is less than sizeof(field), the
strict volatile bitfields code may read beyond the end of the
structure!
Consider this example:
struct s
{
char x : 8;
volatile unsigned i
> If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit
> architecture. I doubt that the strict alignment code makes any sense for
> modesize> BIGGEST_ALIGNMENT.
Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition of
BIGGEST_ALIGNMENT, not honoring an alignment l
Hi,
On Sat, 14 Mar 2015 13:24:33, Mikael Pettersson wrote:
>
> Bernd Edlinger writes:
>> Hi,
>>
>> are there any more comments on this?
>>
>> I would like to apply the patch as is, unless we find a
>> a way to get to a test case, maybe with a cross-compiler,
>> where the MODE_ALIGNMENT is differe
Bernd Edlinger writes:
> Hi,
>
> are there any more comments on this?
>
> I would like to apply the patch as is, unless we find a
> a way to get to a test case, maybe with a cross-compiler,
> where the MODE_ALIGNMENT is different from MODE_BITSIZE.
>
> Currently, I think that does not h
Hi,
are there any more comments on this?
I would like to apply the patch as is, unless we find a
a way to get to a test case, maybe with a cross-compiler,
where the MODE_ALIGNMENT is different from MODE_BITSIZE.
Currently, I think that does not happen.
Thanks
Bernd.
> Date: Tue, 10 Mar 2015 14
Hi Richard and Eric,
On Mon, 9 Mar 2015 15:30:31, Richard Biener wrote:
>> Reg-tested on x86_64 successfully and ARM is still running.
ARM completed without regressions meanwhile.
>>
>> Is it OK for trunk?
>
> Looks ok to me apart from
>
> /* Check for cases of unaligned fields that must be spli
On Fri, Mar 6, 2015 at 12:48 PM, Bernd Edlinger
wrote:
> Hi Richard,
>
> here is my new proposal, it addresses your objections and generates
> "better" code for this test case:
>
> main:
> .LFB0:
> .cfi_startproc
> pushq%rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> m
Hi Richard,
here is my new proposal, it addresses your objections and generates
"better" code for this test case:
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl global+1(%rip), %eax
Hi,
On Thu, 5 Mar 2015 16:36:48, Richard Biener wrote:
>
> On Thu, Mar 5, 2015 at 4:05 PM, Bernd Edlinger
> wrote:
>>
>> every access is split in 4 QImode accesses. but that is as
>> expected, because the structure is byte aligned.
>
> No, it is not expected because the CPU can handle unaligned S
On Thu, Mar 5, 2015 at 4:05 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Mar 2015 12:24:56, Richard Biener wrote:
>>
>> On Thu, Mar 5, 2015 at 12:00 PM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote:
On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edl
Hi,
On Thu, 5 Mar 2015 12:24:56, Richard Biener wrote:
>
> On Thu, Mar 5, 2015 at 12:00 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote:
>>>
>>> On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger
>> Maybe one thing is missing from strict_volatile_bitfield_p,
On Thu, Mar 5, 2015 at 12:00 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote:
>>
>> On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger
>> wrote:
>>> bounced... again, without html.
>>>
>>>
>>> Hi Richard,
>>>
>>> while working on another bug in the area of -fstri
Hi,
On Thu, 5 Mar 2015 10:00:26, Richard Biener wrote:
>
> On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger
> wrote:
>> bounced... again, without html.
>>
>>
>> Hi Richard,
>>
>> while working on another bug in the area of -fstrict-volatile-bitfields
>> I became aware of another example where -fstr
On Wed, Mar 4, 2015 at 3:13 PM, Bernd Edlinger
wrote:
> bounced... again, without html.
>
>
> Hi Richard,
>
> while working on another bug in the area of -fstrict-volatile-bitfields
> I became aware of another example where -fstrict-volatile-bitfields may
> generate
> wrong code. This is re
bounced... again, without html.
Hi Richard,
while working on another bug in the area of -fstrict-volatile-bitfields
I became aware of another example where -fstrict-volatile-bitfields may
generate
wrong code. This is reproducible on a !STRICT_ALIGNMENT target like x86_64.
The problem is
21 matches
Mail list logo
