avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for X


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Align attribute in gcc requiring alignment of 2 for Xmegas with USB.
Date: Mon, 19 Nov 2012 14:59:40 +0100
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

Thomas, George wrote:
> Section 20.13.7 of the Xmega manual speaks about the requirement of 16 bit 
> alignment.
> 
> http://www.atmel.com/images/doc8331.pdf
> 
> As the MAXIMUM_ALIGNMENT in avr.h is set to 1,  it throws an error when 
> trying to compile.
> 
> I have attached a patch which sets it to 2 by default in the compiler.
> I have also attached a case which fails.
> 
> struct testStruct {
> 
> char a;
> int  b;
> float c;
> };
> 
> 
> /*volatile struct testStruct testObj; */
> char a __attribute__ ((aligned (2)));
> 
> int main () {
> a = 2;
> /*
> testObj.a = 'c';
> testObj.b = 6;
> return testObj.a;
> */
> 
> }

I cannot reproduce this a fail. With the oldest release series that supports
xmega, which is 4.7, your code compiles correctly and without warnings, both
with -fcommon and -fno-common:


-fcommon (default):
        .comm   a,1,2


-fno-common :

.global a
        .section .bss
        .p2align        1
        .type   a, @object
        .size   a, 1
a:
        .zero   1


In 4.7.0 we have PR53448 [1] which is fixed in 4.7.1, but notice that 4.7.0
won't work with XMEGA, anyway, so that you don't want to use 4.7.0, anyway.


> diff -Naurp gcc/config/avr/avr.h gcc/config/avr/avr.h
> --- gcc/config/avr/avr.h      2012-11-16 13:43:25.000000000 +0530
> +++ gcc/config/avr/avr.h      2012-11-16 14:12:32.000000000 +0530
> @@ -245,8 +245,8 @@ enum
>  
>  #define EMPTY_FIELD_BOUNDARY 8
>  
> -/* No data type wants to be aligned rounder than this.  */
> -#define BIGGEST_ALIGNMENT 8
> +/* For Xmega USB buffers */
> +#define BIGGEST_ALIGNMENT 16
>  
>  #define TARGET_VTABLE_ENTRY_ALIGN 8
>  
> Would this be an acceptable change ?

I don't think this is appropriate because it leads to memory waste in noswitch
sections.


Johann



[1] http://gcc.gnu.org/PR53448




reply via email to

[Prev in Thread] Current Thread [Next in Thread]