This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: optimization bug in g77


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]