This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: why are we not using const?
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Chris Lattner <clattner at apple dot com>
- Cc: 'Richard Guenther' <richard dot guenther at gmail dot com>, "'Kaveh R. Ghazi'" <ghazi at caipclassic dot rutgers dot edu>, gdr at integrable-solutions dot net, gcc at gnu dot org, lopezibanez at gmail dot com, pinskia at physics dot uc dot edu, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Jun 2006 18:20:06 +0200
- Subject: Re: why are we not using const?
- References: <014d01c69b83$27ba9c40$a501a8c0@CAM.ARTIMI.COM> <3E0FBACE-1C92-490B-9D1D-861D71BC28B1@apple.com>
int G;
void foo(const int *P1) {
G = *P1 + 1;
}
int bar() {
int tmp = G;
foo(&G);
return G-tmp;
}
bar returns 1, not 0, and there is no pointer casting happening.
Well, G is known to escape anyway here. Even worse is this:
-- f1.c --
extern int G;
void foo(const int *P1) {
int a = *P1;
G = *P1 + 1; /* optimizable even for non-const int *P1 */
return *P1 - a; /* non-optimizable anyway */
}
-- f2.c --
int G;
int bar() {
return foo(&G);
}
where there is not even the possibility to optimize *P1 in foo. While
compiling f1.c, the compiler does not even know that G escapes and must
assume the worse.
It's a different story for static variables or for -fwhole-program, but
then the compiler (as for the second load from *P1) can optimize the
third load anyway, independent of whether P1 is const or not.
Paolo