non-optimal code with volatile vars

Mike Stump mrs@windriver.com
Fri Dec 31 20:54:00 GMT 1999


> From: "=?ISO-8859-1?Q?Ralf_G=FCtlein?=" <ralf.guetlein@rodgau.netsurf.de>
> Date: Tue, 28 Dec 1999 15:49:22 +0100

> I traced the global variable volatile_ok to be the culprit.

I just looked at the uses of volatile_ok, and I must say, it is a bad
idea (or maybe just a bad implementation).  Not sure why it is even in
there, maybe someone else can elaborate?  In any event, it seems like
a hack.

Now, why is it a bad idea?  Because there are only two uses of it, and
in those two uses, there are three bugs.  The bugs are obvious (watch
the control flow and the restoration of volatile_ok).  If we supported
frame based cleanup actions in C, and used them, there wouldn't be any
bugs.

I think a .md that doesn't want volatile mem refs in an instruction,
can go out of its way to reject or reload the value, instead of
penalizing all insns in all .mds as it does now.

?



More information about the Gcc-bugs mailing list