Date: Sat, 8 Feb 2003 17:50:53 -0800 From: David Schultz <dschultz@uclink.berkeley.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: Ray Kohler <ataraxia@cox.net>, freebsd-current@FreeBSD.ORG Subject: Re: Compiling with high optimization? Message-ID: <20030209015053.GB21191@HAL9000.homeunix.com> In-Reply-To: <3E45AD75.47C80368@mindspring.com> References: <20030208173756.GA56030@arkadia.nv.cox.net> <20030208232724.GA20435@HAL9000.homeunix.com> <3E459BF3.BB3FC381@mindspring.com> <20030209002542.GA20812@HAL9000.homeunix.com> <3E45AD75.47C80368@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>:
> David Schultz wrote:
> > Thus spake Terry Lambert <tlambert2@mindspring.com>:
> > > Actually, failure to use optimization suppresses some compilation
> > > warnings, particularly those which normally print from using some
> > > variables without initializing them.
> >
> > I think you're thinking of dataflow analysis, which I believe gcc
> > does with -O and higher optimization levels. So unless you're
> > using -O0, I would expect that you'd get all the warnings you
> > want.
>
> See the thread "Re: tmpfile breakage on setuid executables".
>
> Kris accidently introduced a bug that had to do with whether or
> not a variable was used before it was initialized. The compiler
> didn't complain when he checked it before committing it because
> optimization was off by default; it should have complained, e.g.:
>
> "x.c:9:warning: `foo' might be used uninitialized in this function"
Thanks, I saw that. I'm just pointing out that all you need is -O
to get that warning:
das@bloody-mary:~> cat foo.c
int main() {
int foo;
return foo;
}
das@bloody-mary:~> gcc -o foo foo.c -Wall -O
foo.c: In function `main':
foo.c:2: warning: `foo' might be used uninitialized in this function
<rant>
This is one of those things that gcc3 does pretty well, but Sun's
javac does very badly. First of all, in Java, the above warning
is considered an error (except *maybe* in JDK 1.4, which is broken
and slow on IA64 so I can't use it). Second, the dataflow
analysis in javac is braindead, so the compiler is almost always
wrong. When I get the same warning from gcc, it's usually right
unless interprocedural analysis would be required.
</rant>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030209015053.GB21191>