[PATCH] Trust TREE_ADDRESSABLE

Eric Botcazou ebotcazou@adacore.com
Sat Jun 7 11:03:00 GMT 2014


> Hmm, I don't see this.

Usual scheduler-sensitive stuff I guess, here's the assembly I have:

	movq	aliasing3_pkg__pointer(%rip), %rax
	testq	%rax, %rax
	je	.L6
	cmpl	$5, aliasing3_pkg__block(%rip)
	movl	$5, (%rax)

insns #4 and #5 have been wrongly swapped.

> >In Ada we don't mark (external) variables as addressable if we don't
> >see their address taken.
> 
> You have to (now).  The testing was of course to detect this...

Well, you need to define what TREE_ADDRESSABLE means now, because according to

/* In VAR_DECL, PARM_DECL and RESULT_DECL nodes, nonzero means address
   of this is needed.  So it cannot be in a register.
[...]
#define TREE_ADDRESSABLE(NODE) ((NODE)->base.addressable_flag)

your change is clearly wrong and the Ada compiler clearly right.  And auditing 
the various front-ends might also be in order here if they really need to mark 
every single external variable as addressable to be safe wrt aliasing.

Obvious testcase for the C compiler attached, compile at -O2.

This looks like a big hack to work around an LTO issue...

-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.c
Type: text/x-csrc
Size: 79 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140607/ed6dd2fe/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u.c
Type: text/x-csrc
Size: 96 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140607/ed6dd2fe/attachment-0001.bin>


More information about the Gcc-patches mailing list