This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization bug in g77
- To: law at cygnus dot com
- Subject: Re: optimization bug in g77
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Sun, 21 Feb 1999 15:41:05 -0800
- CC: toon at moene dot indiv dot nluug dot nl, egcs-bugs at cygnus dot com
- References: <7542.919635144@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
Jeffrey> In message <36D02A11.55617BEE@moene.indiv.nluug.nl>you
Jeffrey> write:
>> > Mark, could you produce a patch, so that I might be able to
>> look at > which Fortran problems that would solve ?
>>
>> I went ahead and tried the following (patch against a CVS'd
>> copy of the egcs_1_1_branch obtained a few hours ago):
Toone, I'm sorry I didn't get back to you sooner. I was out of town
for a couple of days.
Jeffrey> 99.9% of code will not trigger this kind of problem, we
Jeffrey> don't want all that code to suffer because a few programs
Jeffrey> do trigger this kind of problem.
I see your point.
Jeffrey> For those codes which do trip the problem folks can
Jeffrey> disable this optimization.
But, for most users, it's very difficult, if not impossible, to figure
out *what* optimization is causing the problem. Most likely, they'll
compile a large program and find it behave unexpectedly, and just not
know why. This reflects poorly on EGCS.
I think it's a good deal more responsible to invert your suggestion:
disable the (known to be broken) optimization by default, and then
provide an option to *enable* it. Thus, the "power users", who want
maximum speed, can know what they're getting into: the documentation
will say explicitly that the option is, in general, known to be
unsafe.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com