On 28/02/2019 14:51, Bernd Edlinger wrote:
> On 2/28/19 1:10 PM, Richard Earnshaw (lists) wrote:
>> On 27/01/2019 11:20, Bernd Edlinger wrote:
>>>
>>> $ arm-linux-gnueabihf-gcc -march=armv5te -O3 -S test.c
>>> $ cat test.s
>>> f:
>>> @ args = 12, pretend = 0, frame = 0
>>> @ frame_needed =
On 2/28/19 1:10 PM, Richard Earnshaw (lists) wrote:
> On 27/01/2019 11:20, Bernd Edlinger wrote:
>>
>> $ arm-linux-gnueabihf-gcc -march=armv5te -O3 -S test.c
>> $ cat test.s
>> f:
>> @ args = 12, pretend = 0, frame = 0
>> @ frame_needed = 0, uses_anonymous_args = 0
>> @ link register
On 27/01/2019 11:20, Bernd Edlinger wrote:
> Hi,
>
> I know I am a bit late on the party.
Sorry for the delay replying, I've been off sick...
>
> But I have a question...
>
> Consider this test case:
>
> $ cat test.c
> struct s {
> int a, b;
> } __attribute__((aligned(8)));
>
> struct s f0
Hi,
I know I am a bit late on the party.
But I have a question...
Consider this test case:
$ cat test.c
struct s {
int a, b;
} __attribute__((aligned(8)));
struct s f0;
int f(int a, int b, int c, int d, int e, struct s f)
{
f0 = f;
return __alignof(f);
}
$ arm-linux-gnueabihf-gcc -march
On 22/01/2019 14:50, Jakub Jelinek wrote:
> On Tue, Jan 22, 2019 at 02:10:59PM +, Richard Earnshaw (lists) wrote:
>> @@ -6630,6 +6633,13 @@ arm_needs_doubleword_align (machine_mode mode,
>> const_tree type)
>> Make sure we can warn about that with -Wpsabi. */
>>ret = -1;
>>
On Tue, Jan 22, 2019 at 02:10:59PM +, Richard Earnshaw (lists) wrote:
> @@ -6630,6 +6633,13 @@ arm_needs_doubleword_align (machine_mode mode,
> const_tree type)
>Make sure we can warn about that with -Wpsabi. */
> ret = -1;
>}
> +else if (TREE_CODE (field) == F
After discussions with Jakub on IRC, I've committed this patch along
with a couple of other tweaks to the testsuite. New ChangeLog below.
This issue has existed since GCC-6 but has only come to light following
the release of gcc-8 where code was added to the compiler sources that
exposed the bug.
Hi,
> Unfortunately another PCS bug has come to light with the layout of
> structs whose alignment is dominated by a 64-bit bitfield element. Such
> fields in the type list appear to have alignment 1, but in reality, for
> the purposes of alignment of the underlying structure, the alignment is
>
Unfortunately another PCS bug has come to light with the layout of
structs whose alignment is dominated by a 64-bit bitfield element. Such
fields in the type list appear to have alignment 1, but in reality, for
the purposes of alignment of the underlying structure, the alignment is
derived from th
