This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Warning regression with COMPARE fixes
>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
Joseph> On Mon, 19 Mar 2001, Mark Mitchell wrote:
>> In any case, I'd like other people's opinion on the question of
>> whether or not this warning regression needs fixing. I have no
>> idea
Joseph> I think it should be fixed, though not necessarily for
Joseph> 3.0.
Do you have any idea how to do this? I don't. :-(
=== Possibly Boring Extended Discussion Follows ===
The basic problem is that there is no clear criteria for when the
warning should be issued. It basically boils down to "whenever the
compiler can't prove that there is no path on which the variable is
used uninitialized." That's a standard which changes with the smarts
of the compiler. That means that changes to the "guts" of the
compiler bleed into the user interface. Not user-friendly -- despite
the cleverness of using the optimization machinery to eliminate false
positives.
Most compilers do only the simplest form of analysis when emitting
this warning, and are either more conservative than GCC, or emit more
false positives. In that sense, GCC is better. However, in the sense
of predictability and consistency GCC is worse.
Even if we fix this regression, there will always be programs that
oscillate back and forth between warning and not warning from release
to release, optimization level to optimization level, and machine
architecture to machine architecture. (For example, the program in
question doesn't yield a warning on x86, even though it does on
PowerPC. I'd rather not try explaining that to a curious user.)
My inclination would be to redo this warning at the tree level, in a
simpler, more predictable way -- but not before 3.0. I would specify
the conditions under which the warning should appear in terms of the
user's source code -- not GCC's internal representation -- and then
implement that. Probably, that means moving the warning to the tree
level.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com