PR92606: Which target hook to disallow symbol aliasing?

PR92606: Which target hook to disallow symbol aliasing?

[Georg-Johann Lay]

Hi, gcc generates wrong code when it aliases symbols like in (For a 
complete test cases cf. PR92606):

static const __attribute((progmem)) int xyz_prog[] = { 123, 123, 123 };
int xyz[] = { 123, 123, 123 };

for target avr.  xyz and xyz_prog are binary the same, but the program 
accesses them with different instructions (LPM for the 1st to read from 
flash, LD in the 2nd case to read from RAM).

The bug is that the compiler issues

	.section	.progmem.data,"a",@progbits
	.type	xyz_prog, @object
	.size	xyz_prog, 12
xyz_prog:
	.byte	123
...
	.set	xyz,xyz_prog

which is obviously wrong because the symbols MUST NOT alias each other.

As I failed to find the target hook that disables such aliasing; please 
would someone point me to it?

Johann


FYI, the generated code is also wrong with names address spaces:

static const __flash int xyz_prog[] = { 123, 123, 123 };
int xyz[] = { 123, 123, 123 };

again, PR92606 has a test case:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606#c3

Re: PR92606: Which target hook to disallow symbol aliasing?

[Richard Sandiford]

Georg-Johann Lay <avr@gjlay.de> writes:
> Hi, gcc generates wrong code when it aliases symbols like in (For a 
> complete test cases cf. PR92606):
>
> static const __attribute((progmem)) int xyz_prog[] = { 123, 123, 123 };
> int xyz[] = { 123, 123, 123 };
>
> for target avr.  xyz and xyz_prog are binary the same, but the program 
> accesses them with different instructions (LPM for the 1st to read from 
> flash, LD in the 2nd case to read from RAM).
>
> The bug is that the compiler issues
>
> 	.section	.progmem.data,"a",@progbits
> 	.type	xyz_prog, @object
> 	.size	xyz_prog, 12
> xyz_prog:
> 	.byte	123
> ...
> 	.set	xyz,xyz_prog
>
> which is obviously wrong because the symbols MUST NOT alias each other.
>
> As I failed to find the target hook that disables such aliasing; please 
> would someone point me to it?

I agree it doesn't look like there is one.  Sounds like a useful
hook to add though.

Thanks,
Richard

>
> Johann
>
>
> FYI, the generated code is also wrong with names address spaces:
>
> static const __flash int xyz_prog[] = { 123, 123, 123 };
> int xyz[] = { 123, 123, 123 };
>
> again, PR92606 has a test case:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606#c3

Re: PR92606: Which target hook to disallow symbol aliasing?

[Georg-Johann Lay]

Am 13.12.19 um 12:25 schrieb Richard Sandiford:
> Georg-Johann Lay <avr@gjlay.de> writes:
>> Hi, gcc generates wrong code when it aliases symbols like in (For a
>> complete test cases cf. PR92606):
>>
>> static const __attribute((progmem)) int xyz_prog[] = { 123, 123, 123 };
>> int xyz[] = { 123, 123, 123 };
>>
>> for target avr.  xyz and xyz_prog are binary the same, but the program
>> accesses them with different instructions (LPM for the 1st to read from
>> flash, LD in the 2nd case to read from RAM).
>>
>> The bug is that the compiler issues
>>
>> 	.section	.progmem.data,"a",@progbits
>> 	.type	xyz_prog, @object
>> 	.size	xyz_prog, 12
>> xyz_prog:
>> 	.byte	123
>> ...
>> 	.set	xyz,xyz_prog
>>
>> which is obviously wrong because the symbols MUST NOT alias each other.
>>
>> As I failed to find the target hook that disables such aliasing; please
>> would someone point me to it?
> 
> I agree it doesn't look like there is one.  Sounds like a useful
> hook to add though.

Ok, I added a respective tree-optimization bug:

https://gcc.gnu.org/PR92932

Johann

> Thanks,
> Richard
> 
>>
>> Johann
>>
>>
>> FYI, the generated code is also wrong with names address spaces:
>>
>> static const __flash int xyz_prog[] = { 123, 123, 123 };
>> int xyz[] = { 123, 123, 123 };
>>
>> again, PR92606 has a test case:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606#c3
>