[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)

[Michel Dänzer]

On Die, 2013-08-20 at 13:16 -0400, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays.  Atombios tends to do things
> like:
> 
> struct object {
>     u8 version;
>     u8 num_elements;
>     u32 elements[1]; /* num_elements entries */
> };
> 
> We then do things like the following in the driver code:
> 
> for (i = 0; i < atom_object->num_elements; i++) {
>     driver_object[i] = atom_object->elements[i];
> }
> 
> With previous versions of gcc this used to work fine, but with
> 4.7 and 4.8, it seems to generate code that wanders off into the
> weeds.
> 
> According to:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> The traditional way of handling variably sized arrays (ISO C90)
> is to use an array length of 1.  Gcc allows you to use an array
> length of 0 and newer versions of gcc only seem to do the
> right thing when 0 is used.

[...]

> diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h
> index 16b120c..3f1f011 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
[...]
> @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE                         //Above 4 object table
[...]
>  typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT         //usSrcDstTableOffset pointing to this structure
>  {
>    UCHAR               ucNumberOfSrc;
> -  USHORT              usSrcObjectID[1];
> +  USHORT              usSrcObjectID[0];
>    UCHAR               ucNumberOfDst;
> -  USHORT              usDstObjectID[1];
> +  USHORT              usDstObjectID[0];
>  }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

[...]

> @@ -6194,8 +6194,8 @@ typedef struct _ATOM_INIT_REG_INDEX_FORMAT{
>  typedef struct _ATOM_INIT_REG_BLOCK{
>  	USHORT													usRegIndexTblSize;													//size of asRegIndexBuf
>  	USHORT													usRegDataBlkSize;														//size of ATOM_MEMORY_SETTING_DATA_BLOCK
> -	ATOM_INIT_REG_INDEX_FORMAT			asRegIndexBuf[1];
> -	ATOM_MEMORY_SETTING_DATA_BLOCK	asRegDataBuf[1];
> +	ATOM_INIT_REG_INDEX_FORMAT			asRegIndexBuf[0];
> +	ATOM_MEMORY_SETTING_DATA_BLOCK	asRegDataBuf[0];
>  }ATOM_INIT_REG_BLOCK;
>  
>  #define END_OF_REG_INDEX_BLOCK  0x0ffff
> @@ -6938,8 +6938,8 @@ typedef struct _ATOM_DISP_OUT_INFO
>    ATOM_COMMON_TABLE_HEADER sHeader;  
>  	USHORT ptrTransmitterInfo;
>  	USHORT ptrEncoderInfo;
> -	ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
> -	ASIC_ENCODER_INFO      asEncoderInfo[1];
> +	ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
> +	ASIC_ENCODER_INFO      asEncoderInfo[0];
>  }ATOM_DISP_OUT_INFO;
>  
>  typedef struct _ATOM_DISP_OUT_INFO_V2
> @@ -6948,8 +6948,8 @@ typedef struct _ATOM_DISP_OUT_INFO_V2
>  	USHORT ptrTransmitterInfo;
>  	USHORT ptrEncoderInfo;
>    USHORT ptrMainCallParserFar;                  // direct address of main parser call in VBIOS binary. 
> -	ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
> -	ASIC_ENCODER_INFO      asEncoderInfo[1];
> +	ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
> +	ASIC_ENCODER_INFO      asEncoderInfo[0];
>  }ATOM_DISP_OUT_INFO_V2;

I'm not sure how these structs are supposed to work, before or after
this change... The compiler can't know how to access the fields after
the first variably-sized array?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer