Related articles |
---|
-O4 in SunOS compiler jb3o+@andrew.cmu.edu (Jon Allen Boone) (1992-08-26) |
Re: -O4 in SunOS compiler wismuell@Informatik.TU-Muenchen.DE (1992-08-31) |
Re: -O4 in SunOS compiler chased@rbbb.Eng.Sun.COM (1992-09-01) |
Re: -O4 in SunOS compiler khb@chiba.Eng.Sun.COM (1992-09-01) |
Re: -O4 in SunOS compiler fjh@mundil.cs.mu.OZ.AU (1992-09-02) |
-O4 in SunOS compiler dolf@toet.echo.tds.philips.nl (1992-09-03) |
Re: -O4 in SunOS compiler Alfred.Kayser@dnpap.et.tudelft.nl (1992-09-04) |
Newsgroups: | comp.compilers |
From: | dolf@toet.echo.tds.philips.nl (Dolf Grunbauer) |
Organization: | Compilers Central |
Date: | Thu, 3 Sep 1992 12:28:32 GMT |
References: | 92-09-017 92-09-003 |
Keywords: | sparc, optimize, C |
David Chase wrote:
>> * The compiler may produce 'wrong' code ...
>>The last item is common to all optimizing compilers (at least for C),
>>since aliasing analysis relies on some assumptions that must hold for a
>>program, e.g. the sequence 'p = &i; *(p+offset) = 123;' will access (a
>>component of) i, but no other variable. Of course, you cannot enforce this
>>in C.
>
>What you have there is a case of "undefined behavior" (as specified by the
>ANSI and ISO C language standards). When this is the case, it is not
>"wrong" to produce code that has different results depending upon the
>optimization level. Detecting such code is difficult, but not impossible.
>(Example implementation -- generate a map for all of memory, and check
>each instance of pointer arithmetic and dereferencing to ensure that it
>conforms to the C standard. You may find this too costly, but it is not
>at all impossible.)
An interesting simple program might be the following C code.
Depending on the level of optimalisation the answer varies.
I tested this on Sun 4.1.1..
Options -g, -O and -O2 give a 1 while -O3 and -O4 give 2.
(This program has previously been dealt with in comp.lang.c):
--------------------------------------------------------------------------
/* What should the following program print ? */
/* (Don't mind about layout, I've done it to save space on your screen) */
#include <stdio.h>
typedef struct T { int (*func)(); int val; } T;
foo(x) T *x; { return (0); }
bar(x) T *x; { x->val++; x->func = foo; return (0); }
dum(x,y) int x,y; { return (0); }
main()
{ T x; x.func = bar; x.val = 0;
dum (x.func(&x), x.func(&x));
printf("The value is: %d\n", x.val);
}
/*
Possible answers:
1 because on the first call to 'bar' (i.e. x.func in main) x.func will be
set to 'foo', so x.val only increased once
2 because when calling 'dum' in main it is allowed (?) to determine the
value of x.func only once, so two calls to 'bar'. This of course depends
heavily on the evaluation of the arguments of dum.
*/
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.