Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23089 > unrolled thread

Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually

Back to article view | Back to comp.lang.c

Contents

  Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-05 10:44 -0700
    Re: Clarification on the applicability of compile-time optimization to a  struct variable which encompasses a mixture of fields declared as volatile  and non-volatile individually pete <pfiland@mindspring.com> - 2012-07-05 14:59 -0400
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-07 12:53 -0700
    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-05 23:22 +0100
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 13:08 -0400
        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 09:20 +1200
          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 14:01 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 18:11 -0400
              Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 14:33 -0400
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 11:29 +1200
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 16:27 -0400
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 12:37 +1200
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 17:29 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ian Collins <ian-news@hotmail.com> - 2012-07-07 15:50 +1200
                          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:55 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-07 17:04 +0300
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 00:10 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Gareth Owen <gwowen@gmail.com> - 2012-07-07 10:00 +0100
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 10:55 -0700
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-07 15:13 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 04:40 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-07 17:20 +0300
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 10:33 -0700
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 08:16 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 05:12 -0400
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 09:24 -0400
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 06:07 -0400
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Keith Thompson <kst-u@mib.org> - 2012-07-07 13:26 -0700
                          Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 16:04 -0400
                            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually James Kuyper <jameskuyper@verizon.net> - 2012-07-09 11:14 -0400
            Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 16:58 -0700
              Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 17:20 -0400
                Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 19:39 -0700
                  Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 18:54 -0400
                    Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 20:12 -0700
                      Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:25 -0400
                        Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-06 20:33 -0700
                          Re: Clarification on the applicability of compile-time optimizationo to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-06 19:47 -0400
              Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Jens Gustedt <jens.gustedt@loria.fr> - 2012-07-07 15:47 +0200
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Uncle Steve <stevet810@gmail.com> - 2012-07-07 06:58 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-14 21:46 -0700
                Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-07 16:19 -0700
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Jens Gustedt <jens.gustedt@loria.fr> - 2012-07-08 09:40 +0200
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually James Kuyper <jameskuyper@verizon.net> - 2012-07-08 10:51 -0400
                  Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-13 23:25 -0700
                    Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-14 14:37 -0700
                      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Joshua Maurice <joshuamaurice@gmail.com> - 2012-07-14 14:46 -0700
                        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Philip Lantz <prl@canterey.us> - 2012-07-14 21:39 -0700
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 17:24 -0700
        Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-07 02:33 +0100
      Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Myth__Buster <raghavanil4m@gmail.com> - 2012-07-07 12:53 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#23286

Uncle Steve wrote:
> Currently I'm developing on x86_64 and x86, and I chose to
> use "lock incl %0" and then inspect the result to detect collisions.
> It is obviously very fast, and I can control how long a thread will
> spin on the lock before sleeping.  I have yet to investigate whether I
> need to use a different instruction for the 64-bit arch.

You may not want to use inc, because then you can't discover the result 
without reading it again, so you lose atomicity. I recommend using xadd 
to add 1, it atomically returns the previous value in a register.

[toc] | [prev] | [next] | [standalone]

#23192

On Jul 7, 6:47 am, Jens Gustedt <jens.gust...@loria.fr> wrote:
> Am 07.07.2012 01:58, schrieb Joshua Maurice:
>
> > To be topical, here's the answer for C11: volatile is useless as a
> > portable threading construct. Do not use it. It's (maybe) useful in a
> > portable way only for 3 obscure situations: MMIO, setjmp and longjmp
> > stuff, and signal handling.
>
> No, this is misleading. volatile alone is not sufficient to warrant data
> consistency between threads, but is necessary. volatile and _Atomic are
> complementary specifications that *both* are needed if you want to make
> sure that a thread always uses the latest stored value of a variable. If
> you have
>
> static int _Atomic a = ATOMIC_VAR_INIT(23);
> if (tester)
>   for (;;) printf("current value is %d\n", a);
>
> The compiler is allowed to change the loop into something equivalent to
>
>  {
>   int tmp = a; // do an atomic_load operation here
>   for (;;) printf("current value is %d\n", tmp);
>  }
>
> and thus always print the same value.
>
> static int _Atomic volatile a = ATOMIC_VAR_INIT(23);
>
> would assure that each execution of printf would see an updated value.

(Let's assume you were talking about C11.) You are simply wrong. That
is not what the standard says. This is not what people on the
standards committee are saying. That is not what compile writers are
implementing. This is not what the experts are saying. volatile is
useless for threading code by the C11 standard. Entirely useless for
inter-thread communication.

However, having said that, your example is an interesting one. The
specific rule which disallows the above compiler transformation is an
obscure one, and not one of my favorites. I've tried to discuss this
very issue on comp.std.c++, with no replies IIRC. C11 threading, being
largely just a copy of C++11 threading, has the rule in question. In
the draft I have lying around of C11, n1570, the rule is:

n1570: 7.17.3 Order and consistency / 16
[quote]
Implementations should make atomic stores visible to atomic loads
within a reasonable amount of time.
[/quote]

That rule disallows the above transformation. The only reasonable
reading of that rule is to prevent compiler transformations like the
one above.

There's also one other new obscure rule, again copied from C++11 to
C11, which has some relevance here.

n1570: 6.8.5 Iteration statements / 6
[quote]
An iteration statement whose controlling expression is not a constant
expression, that performs no input/output operations, does not access
volatile objects, and performs no synchronization or atomic operations
in its body, controlling expression, or (in the case of a for
statement) its expression-3, may be assumed by the implementation to
terminate.
[/quote]

This generated a lot of discussion on the C++ newsgroups. In short,
this says:
> for(;;);
is now undefined behavior. I think I dislike the wording of this one
even more than the earlier rule. However, going with the "spirit" of
this rule, I might argue that above compiler transformation is
disallowed; if you're not allowed to make a non-terminating loop with
a constant controlling expression, then the compiler probably
shouldn't be allowed to make one either. Still, I want to emphasize
that reading is merely IMHO, whereas "7.17.3 Order and consistency /
16" much less ambiguously disallows the above compiler
transformation.

For further reading, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
http://msdn.microsoft.com/en-us/library/12a04hfd.aspx
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
http://kerneltrap.org/Linux/Volatile_Superstition
The C++11 and C11 standards.

[toc] | [prev] | [next] | [standalone]

#23199

Am 08.07.2012 01:19, schrieb Joshua Maurice:
> On Jul 7, 6:47 am, Jens Gustedt <jens.gust...@loria.fr> wrote:
>> Am 07.07.2012 01:58, schrieb Joshua Maurice:
>>
>>> To be topical, here's the answer for C11: volatile is useless as a
>>> portable threading construct. Do not use it. It's (maybe) useful in a
>>> portable way only for 3 obscure situations: MMIO, setjmp and longjmp
>>> stuff, and signal handling.
>>
>> No, this is misleading. volatile alone is not sufficient to warrant data
>> consistency between threads, but is necessary. volatile and _Atomic are
>> complementary specifications that *both* are needed if you want to make
>> sure that a thread always uses the latest stored value of a variable. If
>> you have
>>
>> static int _Atomic a = ATOMIC_VAR_INIT(23);
>> if (tester)
>>   for (;;) printf("current value is %d\n", a);
>>
>> The compiler is allowed to change the loop into something equivalent to
>>
>>  {
>>   int tmp = a; // do an atomic_load operation here
>>   for (;;) printf("current value is %d\n", tmp);
>>  }
>>
>> and thus always print the same value.
>>
>> static int _Atomic volatile a = ATOMIC_VAR_INIT(23);
>>
>> would assure that each execution of printf would see an updated value.
> 
> (Let's assume you were talking about C11.)

Sure I was, _Atomic only comes with C11

> You are simply wrong. That
> is not what the standard says. This is not what people on the
> standards committee are saying. That is not what compile writers are
> implementing. This is not what the experts are saying. volatile is
> useless for threading code by the C11 standard. Entirely useless for
> inter-thread communication.

Then read the example I gave again :)

> However, having said that, your example is an interesting one. The
> specific rule which disallows the above compiler transformation is an
> obscure one, and not one of my favorites. I've tried to discuss this
> very issue on comp.std.c++, with no replies IIRC. C11 threading, being
> largely just a copy of C++11 threading, has the rule in question. In
> the draft I have lying around of C11, n1570, the rule is:
> 
> n1570: 7.17.3 Order and consistency / 16
> [quote]
> Implementations should make atomic stores visible to atomic loads
> within a reasonable amount of time.
> [/quote]

The "should" makes it clearly a non-normative part of the standard and
leaves it to the appreciation of the compiler implementor what
"reasonable amount of time" is.

If the implementor decides that "reasonable amount of time" is 1
milli-second, the loop could be implemented to only do an update each
milli-second.

Said otherwise, there can be no guarantee that for the non-volatile
case an implementation decides to skip a load operation somewhere that
would bring a fresh value into some other thread.

> That rule disallows the above transformation.

no, I just suggest that a compiler shouldn't do it.

> The only reasonable
> reading of that rule is to prevent compiler transformations like the
> one above.

to discourage, not to prevent

Jens

[toc] | [prev] | [next] | [standalone]

#23201

On 07/08/2012 03:40 AM, Jens Gustedt wrote:
> Am 08.07.2012 01:19, schrieb Joshua Maurice:
...
>> n1570: 7.17.3 Order and consistency / 16
>> [quote]
>> Implementations should make atomic stores visible to atomic loads
>> within a reasonable amount of time.
>> [/quote]
> 
> The "should" makes it clearly a non-normative part of the standard and
> leaves it to the appreciation of the compiler implementor what
> "reasonable amount of time" is.

While the "should" is a strong hint, it's the fact that it's in a
"recommended practice" section which makes it perfectly clear that this
is optional.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#23282

Joshua Maurice wrote:
> There's also one other new obscure rule, again copied from C++11 to
> C11, which has some relevance here.
> 
> n1570: 6.8.5 Iteration statements / 6
> [quote]
> An iteration statement whose controlling expression is not a constant
> expression, that performs no input/output operations, does not access
> volatile objects, and performs no synchronization or atomic operations
> in its body, controlling expression, or (in the case of a for
> statement) its expression-3, may be assumed by the implementation to
> terminate.
> [/quote]
> 
> This generated a lot of discussion on the C++ newsgroups. In short,
> this says:
> > for(;;);
> is now undefined behavior.

The controlling expression of that loop is a constant expression--
footnote 156 makes this clear--so it doesn't meet the prerequisites for 
paragraph 6.8.5p6 to apply.

Furthermore, even if the paragraph did apply, it doesn't make the 
behavior undefined, it just allows the compiler to remove the loop if it 
doesn't detect any side effects.

[toc] | [prev] | [next] | [standalone]

#23283

On Jul 13, 11:25 pm, Philip Lantz <p...@canterey.us> wrote:
> Joshua Maurice wrote:
> > There's also one other new obscure rule, again copied from C++11 to
> > C11, which has some relevance here.
>
> > n1570: 6.8.5 Iteration statements / 6
> > [quote]
> > An iteration statement whose controlling expression is not a constant
> > expression, that performs no input/output operations, does not access
> > volatile objects, and performs no synchronization or atomic operations
> > in its body, controlling expression, or (in the case of a for
> > statement) its expression-3, may be assumed by the implementation to
> > terminate.
> > [/quote]
>
> > This generated a lot of discussion on the C++ newsgroups. In short,
> > this says:
> > > for(;;);
> > is now undefined behavior.
>
> The controlling expression of that loop is a constant expression--
> footnote 156 makes this clear--so it doesn't meet the prerequisites for
> paragraph 6.8.5p6 to apply.

Oh damn. My apologies. I stand corrected in the entirety.

> Furthermore, even if the paragraph did apply, it doesn't make the
> behavior undefined, it just allows the compiler to remove the loop if it
> doesn't detect any side effects.

I will have to disagree here. This does not allow the compiler to
remove the loop. It allows the compiler to assume the loop will
terminate. Those are very very different. The way it was described to
me, IIRC, it allows the compiler to change this:
  for ( ; /* some non-const expr*/ ; )
  {
    /* some body that fulfills the requirements */
  }
  x = 1;
into this:
  x = 1;
  for ( ; /* some non-const expr*/ ; )
  {
    /* some body that fulfills the requirements */
  }

The compiler still has to prove that the body does not access x, but
if it can, then it can move that above the loop. I forget what all of
the heated discussion was about, as I cannot see offhand why this is
bad at all. Looking back on this, I don't see why the compiler cannot
already do this absent the rule. The only way another thread could
notice is if it had a formal race condition, and that's undefined
behavior anyway. Maybe I'll go take another look at those discussions
if I can find them, as apparently I am very confused.

So, nevermind. And thanks for the correction!

[toc] | [prev] | [next] | [standalone]

#23284

On Jul 14, 2:37 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Jul 13, 11:25 pm, Philip Lantz <p...@canterey.us> wrote:
>
> > Joshua Maurice wrote:
> > > There's also one other new obscure rule, again copied from C++11 to
> > > C11, which has some relevance here.
>
> > > n1570: 6.8.5 Iteration statements / 6
> > > [quote]
> > > An iteration statement whose controlling expression is not a constant
> > > expression, that performs no input/output operations, does not access
> > > volatile objects, and performs no synchronization or atomic operations
> > > in its body, controlling expression, or (in the case of a for
> > > statement) its expression-3, may be assumed by the implementation to
> > > terminate.
> > > [/quote]
>
> > > This generated a lot of discussion on the C++ newsgroups. In short,
> > > this says:
> > > > for(;;);
> > > is now undefined behavior.
>
> > The controlling expression of that loop is a constant expression--
> > footnote 156 makes this clear--so it doesn't meet the prerequisites for
> > paragraph 6.8.5p6 to apply.
>
> Oh damn. My apologies. I stand corrected in the entirety.
>
> > Furthermore, even if the paragraph did apply, it doesn't make the
> > behavior undefined, it just allows the compiler to remove the loop if it
> > doesn't detect any side effects.
>
> I will have to disagree here. This does not allow the compiler to
> remove the loop. It allows the compiler to assume the loop will
> terminate. Those are very very different. The way it was described to
> me, IIRC, it allows the compiler to change this:
>   for ( ; /* some non-const expr*/ ; )
>   {
>     /* some body that fulfills the requirements */
>   }
>   x = 1;
> into this:
>   x = 1;
>   for ( ; /* some non-const expr*/ ; )
>   {
>     /* some body that fulfills the requirements */
>   }
>
> The compiler still has to prove that the body does not access x, but
> if it can, then it can move that above the loop. I forget what all of
> the heated discussion was about, as I cannot see offhand why this is
> bad at all. Looking back on this, I don't see why the compiler cannot
> already do this absent the rule. The only way another thread could
> notice is if it had a formal race condition, and that's undefined
> behavior anyway. Maybe I'll go take another look at those discussions
> if I can find them, as apparently I am very confused.
>
> So, nevermind. And thanks for the correction!

Well, shoot. Just as I hit send, I recall one of the potentially
surprising results.

  #include <stdlib.h>
  int main(void)
  {
    unsigned int x = 1;
    for (; x != 0; x += 2)
      ;
    exit(0);
  }

As I understand it, without that rule I would expect this program to
have the "observable behavior" of not-halting and no (other)
observable behavior. With this rule, it's still an allowed
"execution", but another allowed execution is for the program is to
halt and have exit value 0.

So, again you are right that it's entirely unrelated to my earlier
point, but I don't think it's quite right to say "the compiler can
remove the loop" without going into some more of the details. Also,
you are right that it's not "formally undefined behavior", but it's
definitely quite weird to change the obvious semantics of a well
defined program so drastically. Worse, both executions are allowed,
and which you get depends on a coin flip by the compiler /
implementation on each execution. (Of course, QoI would prevent coin
flipping, but nothing else would.)

[toc] | [prev] | [next] | [standalone]

#23285

Joshua Maurice wrote:
> So, again you are right that it's entirely unrelated to my earlier
> point, but I don't think it's quite right to say "the compiler can
> remove the loop" without going into some more of the details. Also,
> you are right that it's not "formally undefined behavior", but it's
> definitely quite weird to change the obvious semantics of a well
> defined program so drastically. Worse, both executions are allowed,
> and which you get depends on a coin flip by the compiler /
> implementation on each execution. (Of course, QoI would prevent coin
> flipping, but nothing else would.)

I agree, that was an oversimplification on my part. If I recall 
correctly (but I'm not at all sure that I do), when I first encountered 
the proposal, I think it didn't include the bit about a non-constant 
control. Without that requirement for the rule to apply, I think this 
would have been a very bad rule. With that requirement, I think it 
simply means that if you want a loop to run forever, you need to make 
that clear. I'm not sure that's a bad thing. Like you, I remember some 
heated discussions of this, so I've probably forgotten something.

[toc] | [prev] | [next] | [standalone]

#23122

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> [can optimization sometimes be done even though volatile is used?]
>
> To a very large extent, the C standard washes it hands of volatile
> objects.  Sure, it says a fair bit about what *may* happen but it also
> says "[w]hat constitutes an access to an object that has volatile-
> qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
> implementation need not evaluate part of an expression if it can deduce
> that [...] no needed side effects are produced (including any caused by
> [...] accessing a volatile object)" (5.1.2.3 p4).
>
> Together, these give an implementation so much leeway that you often
> need to refer to the implementation, not the standard.  For example, an
> implementation may well be able to deduce that the assignment is not a
> "needed side effect", coming as it does at the start of main.  Equally,
> an implementation may treat all accesses to volatile-qualified objects
> with kid gloves.

My conclusion is similar to yours, but we're 180 degrees
apart on the reading of 5.1.2.3 p4.  Any access to a
volatile object potentially causes a needed side-effect, and
there is -- by definition -- _no way_ for an implementation
to know whether or which accesses to volatile objects will
cause such a side-effect.  However an implementation chooses
to define what actions constitute an access to a volatile
object, these actions _must_ be carried out for each such
access that is evaluated during a program execution, whether
it seems to have any bearing on other "needed" side-effects
or not.  All the latitude comes from 6.7.3 p7;  none comes
from 5.1.2.3 p4, and in fact just the opposite.  Such
actions must in fact be carried out during actual execution,
and must not be "optimized away" no matter whether they seem
to have any bearing on other program behavior or not.

Anyway that's my reading/interpretation;  I don't mean to
start any arguments about which reading is right, but I
thought you would want to know that they are different.

[toc] | [prev] | [next] | [standalone]

#23131

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> [can optimization sometimes be done even though volatile is used?]
>>
>> To a very large extent, the C standard washes it hands of volatile
>> objects.  Sure, it says a fair bit about what *may* happen but it also
>> says "[w]hat constitutes an access to an object that has volatile-
>> qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
>> implementation need not evaluate part of an expression if it can deduce
>> that [...] no needed side effects are produced (including any caused by
>> [...] accessing a volatile object)" (5.1.2.3 p4).
>>
>> Together, these give an implementation so much leeway that you often
>> need to refer to the implementation, not the standard.  For example, an
>> implementation may well be able to deduce that the assignment is not a
>> "needed side effect", coming as it does at the start of main.  Equally,
>> an implementation may treat all accesses to volatile-qualified objects
>> with kid gloves.
>
> My conclusion is similar to yours, but we're 180 degrees
> apart on the reading of 5.1.2.3 p4.  Any access to a
> volatile object potentially causes a needed side-effect, and
> there is -- by definition -- _no way_ for an implementation
> to know whether or which accesses to volatile objects will
> cause such a side-effect.  However an implementation chooses
> to define what actions constitute an access to a volatile
> object, these actions _must_ be carried out for each such
> access that is evaluated during a program execution, whether
> it seems to have any bearing on other "needed" side-effects
> or not.  All the latitude comes from 6.7.3 p7;  none comes
> from 5.1.2.3 p4, and in fact just the opposite.  Such
> actions must in fact be carried out during actual execution,
> and must not be "optimized away" no matter whether they seem
> to have any bearing on other program behavior or not.
>
> Anyway that's my reading/interpretation;  I don't mean to
> start any arguments about which reading is right, but I
> thought you would want to know that they are different.

OK, I can see that.  I.e. is there permission to deduce that the side
effect is needed or simply to deduce that it is produced?  I will pin my
colours firmly to fence I am sitting on and say hmmm...

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23185

On Thursday, July 5, 2012 3:22:49 PM UTC-7, Ben Bacarisse wrote:
> Myth__Buster <raghavanil4m@gmail.com> writes:
> 
> > #include <stdio.h>
> >
> > struct InterruptData
> > {
> >         int numberOfInterrupts;
> >         volatile int timer;
> >         int numberOfTimesInterruptsMasked;
> > } InterruptMonitor;
> >
> >
> > /*
> >  *  Interrupt handler code.
> >  */
> >  
> > int main(void)
> > {
> >     InterruptMonitor = InterruptMonitor;      
> <snip>
> >     return 0;
> > }
> >
> > -------------
> >
> > InterruptMonitor = InterruptMonitor; - Should this be a candidate for
> > compile-time optimization in spite of having a field qualified as
> > volatile?
> 
> I fear that your example may be one "a bit like" the code you really
> care about, but I have to talk about what you post...
> 
> To a very large extent, the C standard washes it hands of volatile
> objects.  Sure, it says a fair bit about what *may* happen but it also
> says "[w]hat constitutes an access to an object that has volatile-
> qualified type is implementation-defined" (6.7.3 p7) and "[a]n actual
> implementation need not evaluate part of an expression if it can deduce
> that [...] no needed side effects are produced (including any caused by
> [...] accessing a volatile object)" (5.1.2.3 p4).
> 
> Together, these give an implementation so much leeway that you often
> need to refer to the implementation, not the standard.  For example, an
> implementation may well be able to deduce that the assignment is not a
> "needed side effect", coming as it does at the start of main.  Equally,
> an implementation may treat all accesses to volatile-qualified objects
> with kid gloves.
> 
> -- 
> Ben.


Okay, thanks for the clarification.

Cheers,
Raghavan Santhanam

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web