This is the mail archive of the
`gcc-patches@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] |

Other format: | [Raw text] |

*From*: Paul Schlie <schlie at mediaone dot net>*To*: Jason Merrill <jason at redhat dot com>*Cc*: Linus Torvalds <torvalds at transmeta dot com>, Alexandre Oliva <aoliva at redhat dot com>, Richard Henderson <rth at redhat dot com>, <gdr at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>*Date*: Sun, 16 Dec 2001 16:51:36 -0500*Subject*: Re: Volatile MEMs in statement expressions and functions inlinedastrees

(sorry, final logical sequence annotations now included below) > (please see annotations below) > >>>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes: >> >>>>>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes: >>>> >>>>> (tt)(lv = rv) :: (lv = ((lt)tmp = rv, (lt)tmp), (tt)((lt)tmp)) >>>> >>>> Nope. If this was the case, then (x += y) += z would add z to some random >>>> temporary. >>>> >> >>> Would have expected it to unambiguously be equivalent to: >> >>> x = x + y, x = x + z; >> >> As would I. Actually, I should have said '(x = y) += z'; based on your >> transformation above, I would expect this to become >> >> tmp = y, x = tmp, tmp = tmp + z >> >> whereas it should be >> >> x = y, x = x + z >> >> or am I misinterpreting you? > > In which case I would re-write it as: > > x = y, x = x + z > > :: x = (x = ((xt)tmp = y, (xt)tmp)), ((xt)tmp2 = x, (xt)tmp2) > + ((xt)tmp3 = y, (xt)tmp3)) Logically: tmp = y, x = tmp, tmp2 = x, tmp3 = y, x = tmp2 + tem3 > > -or- > > x = y + z > > :: x = ((xt)tmp = y, (xt)tmp) + ((xt)temp2 = z, (xt)tmp2) > Logically: tmp = y, tmp2 = z, x = tmp + tmp2 > Depending on adherence to an abstract rule requiring correlation between > the number and sequence of explicit original coded references to a volatile > within an expression, to it's correspondingly more restrictive semantic > interpretation. > >> >>> But in no case should the interpretation be ambiguous, some uniform rule >>> should be established. >> >> Agreed. >> >>>>> And it is agreed that: >>>> >>>>> volatile q >>>>> (q = 10) == 10 >>>> >>>> No, that's where I disagree. >> >>> It it being asserted that: >> >>> volatile q >>> (q = 10) == 10 >> >>> is ambiguous, and therefore defined? >> >> I am asserting that in C++ the above is unambiguously equivalent to >> >> q = 10, q == 10 >> >> and therefore the result of the comparison cannot be predicted. >> >> Jason > > Hence you are asserting that "(q = 10) == 10" may not be true, if q is > volatile. Correct? > > -paul-

**References**:**Re: Volatile MEMs in statement expressions and functions inlinedastrees***From:*Paul Schlie

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |