Daniel Berlin <[EMAIL PROTECTED]> wrote on 17/07/2005 17:33:17:
> On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
[...]
> > I can't agree with that as is. I would refine it to:
> > Anything that *does* optimizes away visible reads or writes of
> > something marked volatile is buggy.
>
> Fine.
> But the tree optimizers currently make no distinction between reads and
> writes of volatile operands, or even which operands of a statement are
> volatile and which are not. So from the perspective of what we do
> *now*, what i said is completely correct, because the optimizers do not
> (not "can not") distinguish to the level you want.
>
> I'd also guess it's probably not worth doing so, but i may be wrong.
>
Could be so, as volatile is not very commonly used (in regular
code). As for embedded code, I am not so sure, it could well be
that volatile is prevalent in embedded or in low level
code, making it a high impact issue in a big niche - I don't know.
Yet, marking the PRs as INVALID is probably not the correct
thing to do. Maybe WONTFIX, or something like that would be
more appropriate. As I understand GCC's bugzilla, INVALID means
that the report is incorrect. I think that the report finds a
true deficiency in gcc, and hence it is correct (a missed
optimization).
As for the importance of the missed optimization, nobody
can tell unless numbers are provided. So it would be fine to
postpone this PR indefinitely - until patches/numbers are
provided to persuade otherwise.
Michael
