On Wed, Aug 26, 2009 at 12:50 PM, Ned Gill wrote:
>
> FWIW, I'm still looking at this on and off. I beleive the pure function was
> a red herring, as this example also does the wrong thing:
>
> extern int z;
>
> int foo(int *y)
> {
> z = 1;
> *y = 0;
> return z; // returns 1, even though
FWIW, I'm still looking at this on and off. I beleive the pure function
was a red herring, as this example also does the wrong thing:
extern int z;
int foo(int *y)
{
z = 1;
*y = 0;
return z; // returns 1, even though y could point to z :(
}
Not much joy tracking it down as yet
On Tue, Aug 18, 2009 at 11:32 AM, Ned Gill wrote:
> On Tue, 18 Aug 2009 10:14:37 +0100, Richard Guenther
> wrote:
>
>> It sounds like a bug in points-to analysis where it doesn't correctly
>> handle return values of pure/const functions. I would just
>> add a constraint from anything to the lhs o
On Tue, 18 Aug 2009 10:14:37 +0100, Richard Guenther
wrote:
It sounds like a bug in points-to analysis where it doesn't correctly
handle return values of pure/const functions. I would just
add a constraint from anything to the lhs of the call to fix it.
Thanks for the quick reply. Could y
On Tue, Aug 18, 2009 at 10:39 AM, Ned Gill wrote:
>
> I'm having a problem with code like the following on all 4.2.x versions of
> gcc (at least on intel and with my port):
>
> unsigned z = 1;
> unsigned *foo()
> {
> return &z;
> }
>
> int main(void)
> {
> z = 1;
> *foo() = 0;
> return
I'm having a problem with code like the following on all 4.2.x versions of
gcc (at least on intel and with my port):
unsigned z = 1;
unsigned *foo()
{
return &z;
}
int main(void)
{
z = 1;
*foo() = 0;
return z;
}
When optimisation is enabled, but inlining disabled (-O1 for ex
