Thread: Re: [PATCHES] fix for strict-alias warnings

[moved to hackers]

----- Original Message ----- 
From: "Tom Lane" <tgl@sss.pgh.pa.us>
>
> I don't think we understand the dangers quite yet, and I think the
> patches applied to date constitute useless thrashing rather than fixes.
> I'd like to see less quick-hack patching and more discussion.
>
> In particular, given that there is as yet no demonstrated effect other
> than mere warnings issued by a possibly-buggy gcc release, I think it's
> premature to be hacking our sources at all.
>

The warning certainly appears to be bogus in one case (the one from
psql/commands.c).

I was inder the impression, perhaps incorrectly, the casting the pointers to
(void *) would inhibit the compiler from making any assumptions about what
it pointed to, and hence inhibit bad effects from those assumptions. The
only way to know would be to examine the assembler output, I suppose. The
alternative is that it would merely inhibit the compiler from issuing a
warning and mask a bad effect. That would be nasty (and a much nastier bug
in gcc, IMNSHO).

Given your last paragraph and the above, I again suggest that the simplest
and safest course right now is to add -fno-strict-aliasing to the gcc flags.
I understand Bruce's concern that compiler issues only tend to get attention
late in the cycle, but ISTM there has been enough discussion on this for it
not to be dropped.

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:
> I was inder the impression, perhaps incorrectly, the casting the pointers to
> (void *) would inhibit the compiler from making any assumptions about what
> it pointed to, and hence inhibit bad effects from those assumptions. The
> only way to know would be to examine the assembler output, I suppose. The
> alternative is that it would merely inhibit the compiler from issuing a
> warning and mask a bad effect. That would be nasty

IIUC the issue is whether the compiler might incorrectly rearrange the
order of operations based on the assumption that two pointers point
to different storage (when in fact they point to the same storage).
I don't see what about introducing "(void *)" would be likely to keep
the compiler from making such assumptions --- you'll still have the same
two pointers and the exact same sequence of operations.  Accordingly,
I think it's very likely that the so-far-proposed patches are indeed
masking the symptom and not solving the real problem.
        regards, tom lane

Tom Lane wrote:

>"Andrew Dunstan" <andrew@dunslane.net> writes:
>  
>
>>I was inder the impression, perhaps incorrectly, the casting the pointers to
>>(void *) would inhibit the compiler from making any assumptions about what
>>it pointed to, and hence inhibit bad effects from those assumptions. The
>>only way to know would be to examine the assembler output, I suppose. The
>>alternative is that it would merely inhibit the compiler from issuing a
>>warning and mask a bad effect. That would be nasty
>>    
>>
>
>IIUC the issue is whether the compiler might incorrectly rearrange the
>order of operations based on the assumption that two pointers point
>to different storage (when in fact they point to the same storage).
>

*nod*

>I don't see what about introducing "(void *)" would be likely to keep
>the compiler from making such assumptions --- you'll still have the same
>two pointers and the exact same sequence of operations.  Accordingly,
>I think it's very likely that the so-far-proposed patches are indeed
>masking the symptom and not solving the real problem.
>
>  
>
My thinking was that it makes those assumptions based on the type of the 
pointer, and it doesn't know the type in the case of (void *).  
Otherwise it really ought to omit a warning even when you cast to (void 
*), IMNSHO.

You could well be right (as I implied above :-) ), and there are at 
least some clues that gcc isn't very smart about this.

So I still think adding -fno-strict-aliasing is the way to go for now.

(back to my day job)

cheers

andrew