------=_Part_1649_1114653053.1521786057428
Content-Type: multipart/alternative;
 boundary="----=_Part_1650_486794692.1521786057428"

------=_Part_1650_486794692.1521786057428
Content-Type: text/plain; charset="UTF-8"

I am confusing about the necessity of the keyword `volatile` in C++, as we
already have the atomics, and this keyword is not able to deal with
processor optimizations. Is there any meaningful use case that depends on
this keyword in C++ (except for the atomic library in C)? If not, I think
it shall be deprecated or removed, like the keyword `register`.

I am looking forward to your comments!

Mingxin Wang

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%40isocpp.org.

------=_Part_1650_486794692.1521786057428
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am confusing about the necessity of the keyword `volatil=
e` in C++, as we already have the atomics, and this keyword is not able to =
deal with processor optimizations. Is there any meaningful use case that de=
pends on this keyword in C++ (except for the atomic library in C)? If not, =
I think it shall be deprecated or removed, like the keyword `register`.<br>=
<div><br></div><div>I am looking forward to your comments!</div><div><br></=
div><div>Mingxin Wang</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678=
%40isocpp.org</a>.<br />

------=_Part_1650_486794692.1521786057428--

------=_Part_1649_1114653053.1521786057428--

.

--00000000000054d62a05680e91a4
Content-Type: text/plain; charset="UTF-8"

`volatile` aren't supposed to be used as thread safe storage, they aren't
designed to do that and any code that relies on that specific feature is
broken.

You should use volatile when loading or storing a variable causes side
effects outside of your program. For example:

- You set a pointer to volatile value to 0, so that the flow of blood from
some device stops.
- You read a value from a pointer to volatile to get the current
temperature from a smart thermometer.

Basically, whenever loading or storing to a value has side effects that the
compiler doesn't know about. The compiler is this prohibited to optimize
such accesses to volatile. This is a feature, not a bug.

On Fri, Mar 23, 2018, 7:20 AM Mingxin Wang <wmx16835vv@163.com> wrote:

> I am confusing about the necessity of the keyword `volatile` in C++, as we
> already have the atomics, and this keyword is not able to deal with
> processor optimizations. Is there any meaningful use case that depends on
> this keyword in C++ (except for the atomic library in C)? If not, I think
> it shall be deprecated or removed, like the keyword `register`.
>
> I am looking forward to your comments!
>
> Mingxin Wang
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2LZNEv6D9Ci0VSMGEqMZhoQ5eEFeKshq4GxCZ8UD_2KA%40mail.gmail.com.

--00000000000054d62a05680e91a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">`volatile` aren&#39;t supposed to be used as thread safe =
storage, they aren&#39;t designed to do that and any code that relies on th=
at specific feature is broken.<div dir=3D"auto"><br></div><div dir=3D"auto"=
>You should use volatile when loading or storing a variable causes side eff=
ects outside of your program. For example:</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">- You set a pointer to volatile value to 0, so that the =
flow of blood from some device stops.</div><div dir=3D"auto">- You read a v=
alue from a pointer to volatile to get the current temperature from a smart=
 thermometer.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Basically,=
 whenever loading or storing to a value has side effects that the compiler =
doesn&#39;t know about. The compiler is this prohibited to optimize such ac=
cesses to volatile. This is a feature, not a bug.</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Mar 23, 2018, 7:20 AM Mingxin Wan=
g &lt;<a href=3D"mailto:wmx16835vv@163.com" rel=3D"noreferrer noreferrer no=
referrer" target=3D"_blank">wmx16835vv@163.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">I am confusing about the necess=
ity of the keyword `volatile` in C++, as we already have the atomics, and t=
his keyword is not able to deal with processor optimizations. Is there any =
meaningful use case that depends on this keyword in C++ (except for the ato=
mic library in C)? If not, I think it shall be deprecated or removed, like =
the keyword `register`.<br><div><br></div><div>I am looking forward to your=
 comments!</div><div><br></div><div>Mingxin Wang</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer noreferrer noreferrer" target=3D"_blank">std-proposals+un=
subscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"=
>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%=
40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2LZNEv6D9Ci0VSMGEqMZhoQ5eEFeKs=
hq4GxCZ8UD_2KA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2LZNEv6D9C=
i0VSMGEqMZhoQ5eEFeKshq4GxCZ8UD_2KA%40mail.gmail.com</a>.<br />

--00000000000054d62a05680e91a4--

.

------=_Part_1817_1062399111.1521789131841
Content-Type: multipart/alternative;
 boundary="----=_Part_1818_484975582.1521789131842"

------=_Part_1818_484975582.1521789131842
Content-Type: text/plain; charset="UTF-8"

On Friday, March 23, 2018 at 2:31:02 PM UTC+8, Nicolas Lesser wrote:
>
> `volatile` aren't supposed to be used as thread safe storage, they aren't
> designed to do that and any code that relies on that specific feature is
> broken.
>
> You should use volatile when loading or storing a variable causes side
> effects outside of your program. For example:
>
> - You set a pointer to volatile value to 0, so that the flow of blood from
> some device stops.
> - You read a value from a pointer to volatile to get the current
> temperature from a smart thermometer.
>
> Basically, whenever loading or storing to a value has side effects that
> the compiler doesn't know about. The compiler is this prohibited to
> optimize such accesses to volatile. This is a feature, not a bug.
>

The problem is that `volatile` only works at compile-time, rather than at
runtime, and the processor optimization may also perform reordering. If my
understanding is right, the only way to prohibite runtime reordering,
guaranteed by the standard, is to use atomics and fences.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%40isocpp.org.

------=_Part_1818_484975582.1521789131842
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 23, 2018 at 2:31:02 PM UTC+8, Nicolas Les=
ser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto">`v=
olatile` aren&#39;t supposed to be used as thread safe storage, they aren&#=
39;t designed to do that and any code that relies on that specific feature =
is broken.<div dir=3D"auto"><br></div><div dir=3D"auto">You should use vola=
tile when loading or storing a variable causes side effects outside of your=
 program. For example:</div><div dir=3D"auto"><br></div><div dir=3D"auto">-=
 You set a pointer to volatile value to 0, so that the flow of blood from s=
ome device stops.</div><div dir=3D"auto">- You read a value from a pointer =
to volatile to get the current temperature from a smart thermometer.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Basically, whenever loading or=
 storing to a value has side effects that the compiler doesn&#39;t know abo=
ut. The compiler is this prohibited to optimize such accesses to volatile. =
This is a feature, not a bug.</div></div></blockquote><div><br></div><div>T=
he problem is that `volatile` only works at compile-time, rather than at ru=
ntime, and the processor optimization may also perform reordering. If my un=
derstanding is right, the only way to prohibite runtime reordering, guarant=
eed by the standard, is to use atomics and fences.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92=
%40isocpp.org</a>.<br />

------=_Part_1818_484975582.1521789131842--

------=_Part_1817_1062399111.1521789131841--

.

--00000000000031f45105680f453f
Content-Type: text/plain; charset="UTF-8"

I would be highly surprised if a processor reorders instructions as a form
of optimization. I know it can execute multiple loop bodies at the same
time and other such optimization, such as speculative execution, but they
don't change the effective order of instructions.The instructions are still
executed as-if they are executed in order.

I'm pretty sure that the processor will not change the effective order of
instructions, as that would make any program behave in odd ways, regardless
of whether volatile is used or not. Do you have an example of such a
optimization?

Also, if the processor can reorder instructions, then it could also reorder
the instructions that were supposed to be protected by a fence/barrier/...

On Fri, Mar 23, 2018, 8:12 AM Mingxin Wang <wmx16835vv@163.com> wrote:

> On Friday, March 23, 2018 at 2:31:02 PM UTC+8, Nicolas Lesser wrote:
>>
>> `volatile` aren't supposed to be used as thread safe storage, they aren't
>> designed to do that and any code that relies on that specific feature is
>> broken.
>>
>> You should use volatile when loading or storing a variable causes side
>> effects outside of your program. For example:
>>
>> - You set a pointer to volatile value to 0, so that the flow of blood
>> from some device stops.
>> - You read a value from a pointer to volatile to get the current
>> temperature from a smart thermometer.
>>
>> Basically, whenever loading or storing to a value has side effects that
>> the compiler doesn't know about. The compiler is this prohibited to
>> optimize such accesses to volatile. This is a feature, not a bug.
>>
>
> The problem is that `volatile` only works at compile-time, rather than at
> runtime, and the processor optimization may also perform reordering. If my
> understanding is right, the only way to prohibite runtime reordering,
> guaranteed by the standard, is to use atomics and fences.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0bfz_VUTmDN%2Be5LvsJq4bszR0-W9UMN5HMd%2Bp3VgSW6g%40mail.gmail.com.

--00000000000031f45105680f453f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I would be highly surprised if a processor reorders instr=
uctions as a form of optimization. I know it can execute multiple loop bodi=
es at the same time and other such optimization, such as speculative execut=
ion, but they don&#39;t change the effective order of instructions.The inst=
ructions are still executed as-if they are executed in order.<div dir=3D"au=
to"><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m=
 pretty sure that the processor will not change the effective order of inst=
ructions, as that would make any program behave in odd ways, regardless of =
whether volatile is used or not. Do you have an example of such a optimizat=
ion?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, if the proces=
sor can reorder instructions, then it could also reorder the instructions t=
hat were supposed to be protected by a fence/barrier/...</div></div></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Mar 23, 2018, =
8:12 AM Mingxin Wang &lt;<a href=3D"mailto:wmx16835vv@163.com" rel=3D"noref=
errer noreferrer noreferrer" target=3D"_blank">wmx16835vv@163.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, M=
arch 23, 2018 at 2:31:02 PM UTC+8, Nicolas Lesser wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"auto">`volatile` aren&#39;t supposed to =
be used as thread safe storage, they aren&#39;t designed to do that and any=
 code that relies on that specific feature is broken.<div dir=3D"auto"><br>=
</div><div dir=3D"auto">You should use volatile when loading or storing a v=
ariable causes side effects outside of your program. For example:</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">- You set a pointer to volatile v=
alue to 0, so that the flow of blood from some device stops.</div><div dir=
=3D"auto">- You read a value from a pointer to volatile to get the current =
temperature from a smart thermometer.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Basically, whenever loading or storing to a value has side ef=
fects that the compiler doesn&#39;t know about. The compiler is this prohib=
ited to optimize such accesses to volatile. This is a feature, not a bug.</=
div></div></blockquote><div><br></div><div>The problem is that `volatile` o=
nly works at compile-time, rather than at runtime, and the processor optimi=
zation may also perform reordering. If my understanding is right, the only =
way to prohibite runtime reordering, guaranteed by the standard, is to use =
atomics and fences.</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer noreferrer noreferrer" target=3D"_blank">std-proposals+un=
subscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"=
>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f03a4ed6-632d-462d-849b-627b1cd7bd92%=
40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq0bfz_VUTmDN%2Be5LvsJq4bszR0-W9=
UMN5HMd%2Bp3VgSW6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0bfz_V=
UTmDN%2Be5LvsJq4bszR0-W9UMN5HMd%2Bp3VgSW6g%40mail.gmail.com</a>.<br />

--00000000000031f45105680f453f--

.

On 23 March 2018 at 09:21, Nicolas Lesser <blitzrakete@gmail.com> wrote:
> I would be highly surprised if a processor reorders instructions as a form
> of optimization. I know it can execute multiple loop bodies at the same time
> and other such optimization, such as speculative execution, but they don't
> change the effective order of instructions.The instructions are still
> executed as-if they are executed in order.
>
> I'm pretty sure that the processor will not change the effective order of
> instructions, as that would make any program behave in odd ways, regardless
> of whether volatile is used or not. Do you have an example of such a
> optimization?
>
> Also, if the processor can reorder instructions, then it could also reorder
> the instructions that were supposed to be protected by a fence/barrier/...


*bats eyelids* huh what? This
https://en.wikipedia.org/wiki/Out-of-order_execution has been a thing
for decades. The processor doesn't reorder around fences and barriers
because the compiler lays
down instructions that prevent the processor from doing so.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUanXSCkz_BCUaZHNr1J7hYFbnOF6-V6nXp4xkvDMNxH8A%40mail.gmail.com.

.

On Fri, Mar 23, 2018 at 12:12:11AM -0700, Mingxin Wang wrote:
> On Friday, March 23, 2018 at 2:31:02 PM UTC+8, Nicolas Lesser wrote:
> >
> > `volatile` aren't supposed to be used as thread safe storage, they aren't
> > designed to do that and any code that relies on that specific feature is
> > broken.
> >
> > You should use volatile when loading or storing a variable causes side
> > effects outside of your program. For example:
> >
> > - You set a pointer to volatile value to 0, so that the flow of blood from
> > some device stops.
> > - You read a value from a pointer to volatile to get the current
> > temperature from a smart thermometer.
> >
> > Basically, whenever loading or storing to a value has side effects that
> > the compiler doesn't know about. The compiler is this prohibited to
> > optimize such accesses to volatile. This is a feature, not a bug.
> >
>
> The problem is that `volatile` only works at compile-time, rather than at
> runtime, and the processor optimization may also perform reordering. If my
> understanding is right, the only way to prohibite runtime reordering,
> guaranteed by the standard, is to use atomics and fences.

volatile tells the compiler that the storage location might be changed by
things outside it's control.

Example:

volatile struct memory_mapped_thingie* thingieP;

for (;;) {
  if (thingieP->flag) {
    thingieP->control = value;
  }
}

Without volatile the compiler is allowed to transform that code into

if (thingieP->flag) {
  for (;;) {
    thingieP->control = value;
  }
} else {
  for (;;)
     ;
}

since it knows that it never writes to thingieP->flag.

/MF

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180323090120.GA8540%40noemi.bahnhof.se.

.

------=_Part_2157_1645533897.1521801751642
Content-Type: multipart/alternative;
 boundary="----=_Part_2158_159923721.1521801751642"

------=_Part_2158_159923721.1521801751642
Content-Type: text/plain; charset="UTF-8"

On Friday, March 23, 2018 at 5:01:25 PM UTC+8, Magnus Fromreide wrote:
>
> volatile tells the compiler that the storage location might be changed by
> things outside it's control.
>
> Example:
>
> volatile struct memory_mapped_thingie* thingieP;
>
> for (;;) {
>   if (thingieP->flag) {
>     thingieP->control = value;
>   }
> }
>
> Without volatile the compiler is allowed to transform that code into
>
> if (thingieP->flag) {
>   for (;;) {
>     thingieP->control = value;
>   }
> } else {
>   for (;;)
>      ;
> }
>
> since it knows that it never writes to thingieP->flag.
>
> /MF
>

The keyword indeed could prevent such optimization. However, in the case
you provided, there seems to be no guarantee for the visibility of
`thingieP->flag` and `thingieP->control`, which introduces bugs that hard
to find. For example, the assignment `thingieP->control = value` may be
ignored after processor optimization since the value is never acquired in
the current thread. Thus, I do not think this case is a meaningful one to
the keyword `volatile`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-bdf3-a2c1877871a2%40isocpp.org.

------=_Part_2158_159923721.1521801751642
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 23, 2018 at 5:01:25 PM UTC+8, Magnus From=
reide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">volatile tells the=
 compiler that the storage location might be changed by
<br>things outside it&#39;s control.
<br>
<br>Example:
<br>
<br>volatile struct memory_mapped_thingie* thingieP;
<br>
<br>for (;;) {
<br>=C2=A0 if (thingieP-&gt;flag) {
<br>=C2=A0 =C2=A0 thingieP-&gt;control =3D value;
<br>=C2=A0 }
<br>}
<br>
<br>Without volatile the compiler is allowed to transform that code into
<br>
<br>if (thingieP-&gt;flag) {
<br>=C2=A0 for (;;) {
<br>=C2=A0 =C2=A0 thingieP-&gt;control =3D value;
<br>=C2=A0 }
<br>} else {
<br>=C2=A0 for (;;)
<br>=C2=A0 =C2=A0 =C2=A0;
<br>}
<br>
<br>since it knows that it never writes to thingieP-&gt;flag.
<br>
<br>/MF
<br></blockquote><div><br></div><div>The keyword indeed could prevent such =
optimization. However, in the case you provided, there seems to be no guara=
ntee for the visibility of `thingieP-&gt;flag` and `thingieP-&gt;control`, =
which introduces bugs that hard to find. For example, the assignment `thing=
ieP-&gt;control =3D value` may be ignored after processor optimization sinc=
e the value is never acquired in the current thread. Thus, I do not think t=
his case is a meaningful one to the keyword `volatile`.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-bdf3-a2c1877871a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-bdf3-a2c1877871a2=
%40isocpp.org</a>.<br />

------=_Part_2158_159923721.1521801751642--

------=_Part_2157_1645533897.1521801751642--

.

--000000000000f2134505681239fd
Content-Type: text/plain; charset="UTF-8"

On 23 March 2018 at 10:42, Mingxin Wang <wmx16835vv@163.com> wrote:

> On Friday, March 23, 2018 at 5:01:25 PM UTC+8, Magnus Fromreide wrote:
>>
>> volatile tells the compiler that the storage location might be changed by
>> things outside it's control.
>>
>> Example:
>>
>> volatile struct memory_mapped_thingie* thingieP;
>>
>> for (;;) {
>>   if (thingieP->flag) {
>>     thingieP->control = value;
>>   }
>> }
>>
>> Without volatile the compiler is allowed to transform that code into
>>
>> if (thingieP->flag) {
>>   for (;;) {
>>     thingieP->control = value;
>>   }
>> } else {
>>   for (;;)
>>      ;
>> }
>>
>> since it knows that it never writes to thingieP->flag.
>>
>> /MF
>>
>
> The keyword indeed could prevent such optimization. However, in the case
> you provided, there seems to be no guarantee for the visibility of
> `thingieP->flag` and `thingieP->control`, which introduces bugs that hard
> to find. For example, the assignment `thingieP->control = value` may be
> ignored after processor optimization since the value is never acquired in
> the current thread. Thus, I do not think this case is a meaningful one to
> the keyword `volatile`.
>

This is precisely the meaning of 'volatile'. It forces the compiler to emit
a write to memory regardless of whether the value will be read back. It is
designed for reading and writing values to memory mapped I/O, where the
very act of placing signals on the bus has real consequences for the
hardware.

Remember that not all memory-mapped I/O behaves like RAM. Sometimes,
reading from a mapped address can cause a signal to be sent to a peripheral
(i.e. read is really a write). volatile is the way c and c++ express this
relationship with hardware.





> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-
> bdf3-a2c1877871a2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-bdf3-a2c1877871a2%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbG2KxhpOFfb3WN8rAuXw-RRtKoh37v6Hwx0kZ--PiZ7w%40mail.gmail.com.

--000000000000f2134505681239fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 23 March 2018 at 10:42, Mingxin Wang <span dir=3D"ltr">&lt;<a href=
=3D"mailto:wmx16835vv@163.com" target=3D"_blank">wmx16835vv@163.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">On Friday, March 23, 2018 at 5:01:25 PM UTC+8, Magnus Fromreide wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">volatile tells the compiler that=
 the storage location might be changed by
<br>things outside it&#39;s control.
<br>
<br>Example:
<br>
<br>volatile struct memory_mapped_thingie* thingieP;
<br>
<br>for (;;) {
<br>=C2=A0 if (thingieP-&gt;flag) {
<br>=C2=A0 =C2=A0 thingieP-&gt;control =3D value;
<br>=C2=A0 }
<br>}
<br>
<br>Without volatile the compiler is allowed to transform that code into
<br>
<br>if (thingieP-&gt;flag) {
<br>=C2=A0 for (;;) {
<br>=C2=A0 =C2=A0 thingieP-&gt;control =3D value;
<br>=C2=A0 }
<br>} else {
<br>=C2=A0 for (;;)
<br>=C2=A0 =C2=A0 =C2=A0;
<br>}
<br>
<br>since it knows that it never writes to thingieP-&gt;flag.
<br>
<br>/MF
<br></blockquote><div><br></div></span><div>The keyword indeed could preven=
t such optimization. However, in the case you provided, there seems to be n=
o guarantee for the visibility of `thingieP-&gt;flag` and `thingieP-&gt;con=
trol`, which introduces bugs that hard to find. For example, the assignment=
 `thingieP-&gt;control =3D value` may be ignored after processor optimizati=
on since the value is never acquired in the current thread. Thus, I do not =
think this case is a meaningful one to the keyword `volatile`.</div></div><=
/blockquote><div><br></div><div>This is precisely the meaning of &#39;volat=
ile&#39;. It forces the compiler to emit a write to memory regardless of wh=
ether the value will be read back. It is designed for reading and writing v=
alues to memory mapped I/O, where the very act of placing signals on the bu=
s has real consequences for the hardware.</div><div><br></div><div>Remember=
 that not all memory-mapped I/O behaves like RAM. Sometimes, reading from a=
 mapped address can cause a signal to be sent to a peripheral (i.e. read is=
 really a write). volatile is the way c and c++ express this relationship w=
ith hardware.</div><div><br></div><div><br></div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/772c456b-2629-49c6-bdf3-a2c1877871a2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/772c=
456b-2629-49c6-<wbr>bdf3-a2c1877871a2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbG2KxhpOFfb3WN8rAuXw-RRtKoh37v=
6Hwx0kZ--PiZ7w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbG2KxhpOFf=
b3WN8rAuXw-RRtKoh37v6Hwx0kZ--PiZ7w%40mail.gmail.com</a>.<br />

--000000000000f2134505681239fd--

.

On 23 March 2018 at 12:52, Richard Hodges <hodges.r@gmail.com> wrote:
>> The keyword indeed could prevent such optimization. However, in the case
>> you provided, there seems to be no guarantee for the visibility of
>> `thingieP->flag` and `thingieP->control`, which introduces bugs that hard to
>> find. For example, the assignment `thingieP->control = value` may be ignored
>> after processor optimization since the value is never acquired in the
>> current thread. Thus, I do not think this case is a meaningful one to the
>> keyword `volatile`.
>
>
> This is precisely the meaning of 'volatile'. It forces the compiler to emit
> a write to memory regardless of whether the value will be read back. It is
> designed for reading and writing values to memory mapped I/O, where the very
> act of placing signals on the bus has real consequences for the hardware.
>
> Remember that not all memory-mapped I/O behaves like RAM. Sometimes, reading
> from a mapped address can cause a signal to be sent to a peripheral (i.e.
> read is really a write). volatile is the way c and c++ express this
> relationship with hardware.


While the semantics of volatile access are implementation-defined,
volatile access is a side-effect,
so there's little to no danger of a compiler optimizing it away.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbJjLGYsggp8_t6T%2B2Yogg_PDAb7O4RvgB_2YBgVWrxew%40mail.gmail.com.

.

On Fri, Mar 23, 2018 at 8:32 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 23 March 2018 at 09:21, Nicolas Lesser <blitzrakete@gmail.com> wrote:
>> I would be highly surprised if a processor reorders instructions as a form
>> of optimization. I know it can execute multiple loop bodies at the same time
>> and other such optimization, such as speculative execution, but they don't
>> change the effective order of instructions.The instructions are still
>> executed as-if they are executed in order.
>>
>> I'm pretty sure that the processor will not change the effective order of
>> instructions, as that would make any program behave in odd ways, regardless
>> of whether volatile is used or not. Do you have an example of such a
>> optimization?
>>
>> Also, if the processor can reorder instructions, then it could also reorder
>> the instructions that were supposed to be protected by a fence/barrier/...
>
>
> *bats eyelids* huh what? This
> https://en.wikipedia.org/wiki/Out-of-order_execution has been a thing
> for decades. The processor doesn't reorder around fences and barriers
> because the compiler lays
> down instructions that prevent the processor from doing so.

Indeed, modern processors effectively rewrite the program, not just
"reorder" the instructions. However, Nicolas is correct in the sense
that however that is performed, the external behavior must be
preserved w.r.t. the guarantees that the architecture gives for each
instruction. The same way optimizing C++ compilers can perform all
kinds of transformations as long as the program behaves within the
promises the specification gives.

Of course, volatile has always been in both C and C++ a hairy subject
because implementations may choose to give it stronger/different
semantics than required by the standard because users de facto gave
them those semantics and now they don't want to break their clients'
code.

Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72%3Dag0dYN5x%3DA3Zi4qwCSXGW_GswakLpAFa-qqCD34H%2BhQ%40mail.gmail.com.

.

On Friday, 23 March 2018 15:12:11 CST Mingxin Wang wrote:
> The problem is that `volatile` only works at compile-time, rather than at
> runtime, and the processor optimization may also perform reordering. If my
> understanding is right, the only way to prohibite runtime reordering,
> guaranteed by the standard, is to use atomics and fences.

Sure it works at runtime. You use volatile in memory regions where the
processor is configured not to coalesce, use caches or delay writebacks.
Basically, you use volatile in UC MMIO memory.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1622054.9qo2sSbJHP%40tjmaciei-mobl1.

.

------=_Part_7112_1345781931.1521982352345
Content-Type: multipart/alternative;
 boundary="----=_Part_7113_392569146.1521982352345"

------=_Part_7113_392569146.1521982352345
Content-Type: text/plain; charset="UTF-8"

While all of this is true volatile sees very little use compared to its
rather large effects on the standard. I'm pretty sure that if we had a
fresh start
handling of memory mapped IO would be relegated to a few library
intrinsics. Maybe it could even be deprecated eventually if such intrinsics
were introduced in the next standard. Then again, now that we have taken
volatile this far it may not be worth the while to get rid of.

Den fredag 23 mars 2018 kl. 12:40:24 UTC+1 skrev Thiago Macieira:
>
> On Friday, 23 March 2018 15:12:11 CST Mingxin Wang wrote:
> > The problem is that `volatile` only works at compile-time, rather than
> at
> > runtime, and the processor optimization may also perform reordering. If
> my
> > understanding is right, the only way to prohibite runtime reordering,
> > guaranteed by the standard, is to use atomics and fences.
>
> Sure it works at runtime. You use volatile in memory regions where the
> processor is configured not to coalesce, use caches or delay writebacks.
> Basically, you use volatile in UC MMIO memory.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8f73ba25-08d7-40a7-9bf8-9adf7cb9235f%40isocpp.org.

------=_Part_7113_392569146.1521982352345
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While all of this is true volatile sees very little use co=
mpared to its rather large effects on the standard. I&#39;m pretty sure tha=
t if we had a fresh start<div>handling of memory mapped IO would be relegat=
ed to a few library intrinsics. Maybe it could even be deprecated eventuall=
y if such intrinsics were introduced in the next standard. Then again, now =
that we have taken volatile this far it may not be worth the while to get r=
id of.<br><br>Den fredag 23 mars 2018 kl. 12:40:24 UTC+1 skrev Thiago Macie=
ira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, 23 March 2018 1=
5:12:11 CST Mingxin Wang wrote:
<br>&gt; The problem is that `volatile` only works at compile-time, rather =
than at
<br>&gt; runtime, and the processor optimization may also perform reorderin=
g. If my
<br>&gt; understanding is right, the only way to prohibite runtime reorderi=
ng,
<br>&gt; guaranteed by the standard, is to use atomics and fences.
<br>
<br>Sure it works at runtime. You use volatile in memory regions where the=
=20
<br>processor is configured not to coalesce, use caches or delay writebacks=
..=20
<br>Basically, you use volatile in UC MMIO memory.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8f73ba25-08d7-40a7-9bf8-9adf7cb9235f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8f73ba25-08d7-40a7-9bf8-9adf7cb9235f=
%40isocpp.org</a>.<br />

------=_Part_7113_392569146.1521982352345--

------=_Part_7112_1345781931.1521982352345--

.

--001a114b332c0d25d205683c9d67
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 25, 2018, 8:52 AM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> While all of this is true volatile sees very little use compared to its
> rather large effects on the standard. I'm pretty sure that if we had a
> fresh start
> handling of memory mapped IO would be relegated to a few library
> intrinsics.
>

I've had to use volatile distressingly often, and it has nothing to do with
memory-mapped IO.  I use it to force assignments to floating-point
variables to be written to memory, denying the compiler permission to use
the value from an extended-precision register instead.  Volatile can go
only when this permission is revoked (or gcc is changed to obey the rules
properly, which won't happen because of optimizationism).

>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYiQvDvijZVMhpV%3D4k_nv3S8oZbrxXWPwjjCH0KmK4LXQ%40mail.gmail.com.

--001a114b332c0d25d205683c9d67
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Sun, Mar 25, 2018, 8:52 AM Bengt Gustafsson &lt;<a href=3D"mailto:bengt.=
gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">While all of this is tr=
ue volatile sees very little use compared to its rather large effects on th=
e standard. I&#39;m pretty sure that if we had a fresh start<div>handling o=
f memory mapped IO would be relegated to a few library intrinsics.<br></div=
></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#=
39;ve had to use volatile distressingly often, and it has nothing to do wit=
h memory-mapped IO.=C2=A0 I use it to force assignments to floating-point v=
ariables to be written to memory, denying the compiler permission to use th=
e value from an extended-precision register instead.=C2=A0 Volatile can go =
only when this permission is revoked (or gcc is changed to obey the rules p=
roperly, which won&#39;t happen because of optimizationism).</div><div clas=
s=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div></div></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYiQvDvijZVMhpV%3D4k_nv3S8oZbrx=
XWPwjjCH0KmK4LXQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYiQvDvij=
ZVMhpV%3D4k_nv3S8oZbrxXWPwjjCH0KmK4LXQ%40mail.gmail.com</a>.<br />

--001a114b332c0d25d205683c9d67--

.

On Sunday, 25 March 2018 21:26:54 CST Hyman Rosen wrote:
> On Sun, Mar 25, 2018, 8:52 AM Bengt Gustafsson <
>
> bengt.gustafsson@beamways.com> wrote:
> > While all of this is true volatile sees very little use compared to its
> > rather large effects on the standard. I'm pretty sure that if we had a
> > fresh start
> > handling of memory mapped IO would be relegated to a few library
> > intrinsics.
>
> I've had to use volatile distressingly often, and it has nothing to do with
> memory-mapped IO.  I use it to force assignments to floating-point
> variables to be written to memory, denying the compiler permission to use
> the value from an extended-precision register instead.  Volatile can go
> only when this permission is revoked (or gcc is changed to obey the rules
> properly, which won't happen because of optimizationism).

While I don't subscribe to Hyman's philosophy regarding optimisation, he does
have a point on ensuring memory reads and writes. std::atomic is specified
with methods both volatile and non-volatile and that makes a difference.
Atomicity and volatility are not the same concept, especially for base
operations like load and store.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2227963.hioahn4QJE%40tjmaciei-mobl1.

.

------=_Part_12324_840114800.1522031657316
Content-Type: multipart/alternative;
 boundary="----=_Part_12325_43049536.1522031657316"

------=_Part_12325_43049536.1522031657316
Content-Type: text/plain; charset="UTF-8"

On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Macieira wrote:
>
> While I don't subscribe to Hyman's philosophy regarding optimisation, he
> does
> have a point on ensuring memory reads and writes. std::atomic is specified
> with methods both volatile and non-volatile and that makes a difference.
> Atomicity and volatility are not the same concept, especially for base
> operations like load and store.
>

As far as I am concerned, there seems to be no guarantee in the standard
that `volatile` could prevent using cache, although some compilers promise
that.

By the way, is there any meaningful use case where the atomics shall be
declared `volatile`?

Thank you for the comment!

--
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a990c3f5-89f4-4811-b17b-041e53a744ff%40isocpp.org.

------=_Part_12325_43049536.1522031657316
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">While I don&#39;t s=
ubscribe to Hyman&#39;s philosophy regarding optimisation, he does=20
<br>have a point on ensuring memory reads and writes. std::atomic is specif=
ied=20
<br>with methods both volatile and non-volatile and that makes a difference=
..=20
<br>Atomicity and volatility are not the same concept, especially for base=
=20
<br>operations like load and store.
<br></blockquote><div><br></div><div>As far as I am concerned, there seems =
to be no guarantee in the standard that `volatile` could prevent using cach=
e, although some compilers promise that.</div><div><br></div><div>By the wa=
y, is there any meaningful use case where the atomics shall be declared `vo=
latile`?</div><div><br></div><div>Thank you for the comment!</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br><br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a990c3f5-89f4-4811-b17b-041e53a744ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a990c3f5-89f4-4811-b17b-041e53a744ff=
%40isocpp.org</a>.<br />

------=_Part_12325_43049536.1522031657316--

------=_Part_12324_840114800.1522031657316--

.

------=_Part_2530_1043614503.1522048502644
Content-Type: multipart/alternative;
 boundary="----=_Part_2531_1161454340.1522048502644"

------=_Part_2531_1161454340.1522048502644
Content-Type: text/plain; charset="UTF-8"

volatile T *p = ..;
assert(*p == *p);

This assert can fire for volatile pointer but never for non-volatile.

It's because the compiler must load the value twice (that can change
between loads). For no-volatile case only one load can be done.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69bb7963-841f-41a6-bda2-81fc056ef869%40isocpp.org.

------=_Part_2531_1161454340.1522048502644
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">volatile T *p =3D ..;<br>assert(*p =3D=3D *p);<br><br>This=
 assert can fire for volatile pointer but never for non-volatile.<br><br>It=
&#39;s because the compiler must load the value twice (that can change betw=
een loads). For no-volatile case only one load can be done.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69bb7963-841f-41a6-bda2-81fc056ef869%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69bb7963-841f-41a6-bda2-81fc056ef869=
%40isocpp.org</a>.<br />

------=_Part_2531_1161454340.1522048502644--

------=_Part_2530_1043614503.1522048502644--

.

--000000000000f464e205684c0792
Content-Type: text/plain; charset="UTF-8"

On Mon, 26 Mar 2018 at 13:34 Mingxin Wang <wmx16835vv@163.com> wrote:

> On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Macieira wrote:
>>
>> While I don't subscribe to Hyman's philosophy regarding optimisation, he
>> does
>> have a point on ensuring memory reads and writes. std::atomic is
>> specified
>> with methods both volatile and non-volatile and that makes a difference.
>> Atomicity and volatility are not the same concept, especially for base
>> operations like load and store.
>>
>
> As far as I am concerned, there seems to be no guarantee in the standard
> that `volatile` could prevent using cache, although some compilers promise
> that.
>
>
How a compiler handles volatile and lack of optimization is implementation
defined. If an implementation did read the cache instead of the memory
location and the side-effect from reading that memory location was not
preserved, then it's a bug in the implementation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEJ4JGxGUMZgNO8N8wPB8EO%2BT00Y_YsYbnGnvsj5ude0N2fDwg%40mail.gmail.com.

--000000000000f464e205684c0792
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 26 Mar 2018 at 13:34 Mingxin Wang &lt;<a href=3D"mailto:wmx16835vv@163.co=
m">wmx16835vv@163.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">While I don&#39;t subs=
cribe to Hyman&#39;s philosophy regarding optimisation, he does=20
<br>have a point on ensuring memory reads and writes. std::atomic is specif=
ied=20
<br>with methods both volatile and non-volatile and that makes a difference=
..=20
<br>Atomicity and volatility are not the same concept, especially for base=
=20
<br>operations like load and store.
<br></blockquote><div><br></div></div><div dir=3D"ltr"><div>As far as I am =
concerned, there seems to be no guarantee in the standard that `volatile` c=
ould prevent using cache, although some compilers promise that.</div><div><=
br></div></div></blockquote><div><br></div><div>How a compiler handles vola=
tile and lack of optimization is implementation defined. If an implementati=
on did read the cache instead of the memory location and the side-effect fr=
om reading that memory location was not preserved, then it&#39;s a bug in t=
he implementation.</div><div>=C2=A0</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEJ4JGxGUMZgNO8N8wPB8EO%2BT00Y_YsYbn=
Gnvsj5ude0N2fDwg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEJ4JGxGUMZgNO=
8N8wPB8EO%2BT00Y_YsYbnGnvsj5ude0N2fDwg%40mail.gmail.com</a>.<br />

--000000000000f464e205684c0792--

.

On 23/03/18 12:05, Miguel Ojeda wrote:
> On Fri, Mar 23, 2018 at 8:32 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> On 23 March 2018 at 09:21, Nicolas Lesser <blitzrakete@gmail.com> wrote:
>>> I would be highly surprised if a processor reorders instructions as a form
>>> of optimization. I know it can execute multiple loop bodies at the same time
>>> and other such optimization, such as speculative execution, but they don't
>>> change the effective order of instructions.The instructions are still
>>> executed as-if they are executed in order.
>>>
>>> I'm pretty sure that the processor will not change the effective order of
>>> instructions, as that would make any program behave in odd ways, regardless
>>> of whether volatile is used or not. Do you have an example of such a
>>> optimization?
>>>
>>> Also, if the processor can reorder instructions, then it could also reorder
>>> the instructions that were supposed to be protected by a fence/barrier/...
>>
>>
>> *bats eyelids* huh what? This
>> https://en.wikipedia.org/wiki/Out-of-order_execution has been a thing
>> for decades. The processor doesn't reorder around fences and barriers
>> because the compiler lays
>> down instructions that prevent the processor from doing so.
>
> Indeed, modern processors effectively rewrite the program, not just
> "reorder" the instructions. However, Nicolas is correct in the sense
> that however that is performed, the external behavior must be
> preserved w.r.t. the guarantees that the architecture gives for each
> instruction. The same way optimizing C++ compilers can perform all
> kinds of transformations as long as the program behaves within the
> promises the specification gives.
>
> Of course, volatile has always been in both C and C++ a hairy subject
> because implementations may choose to give it stronger/different
> semantics than required by the standard because users de facto gave
> them those semantics and now they don't want to break their clients'
> code.
>

When your code uses volatile reads and writes, the compiler will issue
exactly as many reads and writes as given, in the order given.  That is
the basic principle of "volatile" in C and C++.  Compilers can give
/more/ than that - some treat any volatile access as a memory fence, for
example.  And there are differences in complicated things like volatile
bitfields, volatile read-modify-write expressions (like "vol++;"), etc.
 It is usually best to avoid these.  Also, the standards don't make it
clear that using a "pointer to volatile" is a volatile access - though
every compiler known to man treats it that way.

The cpu may re-order instructions and memory accesses in all sorts of
ways - other than for a few architectures, it does not know that an
access is "volatile".

But if you are using "volatile" correctly, you are using it for things
like memory mapped peripherals (where MMU settings generally enforce
access orderings) or in combination with synchronisation and fence
instructions (from before C++11 or C11).  Using "volatile" alone is not
safe for threading or SMP.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/p9andm%24pl6%241%40blaine.gmane.org.

.

On segunda-feira, 26 de mar=C3=A7o de 2018 10:34:17 CST Mingxin Wang wrote:
> On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Macieira wrote:
> > While I don't subscribe to Hyman's philosophy regarding optimisation, h=
e
> > does
> > have a point on ensuring memory reads and writes. std::atomic is specif=
ied
> > with methods both volatile and non-volatile and that makes a difference=
..
> > Atomicity and volatility are not the same concept, especially for base
> > operations like load and store.
>=20
> As far as I am concerned, there seems to be no guarantee in the standard
> that `volatile` could prevent using cache, although some compilers promis=
e
> that.

There isn't. Volatile is a tool you use when your specific memory type=20
requires it. If you need to make that particular memory region non-cached, =
you=20
need to read your architecture system manual.

> By the way, is there any meaningful use case where the atomics shall be
> declared `volatile`?

I just said one: loads and stores.

 std::atomic<int> a;
 a.store(0);
 a.store(1);
 a.load();
 return a.load();

Since this isn't volatile, even if a is a global variable, the compiler is=
=20
allowed to perform optimisations. None of them may do so right now, but the=
y=20
may in the future and further drive Hyman crazy.

IA-64 may even require it, to avoid a write-after-write collision (unless i=
t=20
adds a stop bit between the two stores).

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3193822.uToWOrWuY4%40tjmaciei-mobl1.

.

--001a113ce2a4faf7bb05685bad1e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 26, 2018 at 8:56 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On segunda-feira, 26 de mar=C3=A7o de 2018 10:34:17 CST Mingxin Wang wrot=
e:
> > On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Macieira wrote:
> > > While I don't subscribe to Hyman's philosophy regarding optimisation,
> he
> > > does
> > > have a point on ensuring memory reads and writes. std::atomic is
> specified
> > > with methods both volatile and non-volatile and that makes a
> difference.
> > > Atomicity and volatility are not the same concept, especially for bas=
e
> > > operations like load and store.
> >
> > As far as I am concerned, there seems to be no guarantee in the standar=
d
> > that `volatile` could prevent using cache, although some compilers
> promise
> > that.
>
> There isn't. Volatile is a tool you use when your specific memory type
> requires it. If you need to make that particular memory region non-cached=
,
> you
> need to read your architecture system manual.
>
> > By the way, is there any meaningful use case where the atomics shall be
> > declared `volatile`?
>
> I just said one: loads and stores.
>
>         std::atomic<int> a;
>         a.store(0);
>         a.store(1);
>         a.load();
>         return a.load();
>
> Since this isn't volatile, even if a is a global variable, the compiler i=
s
> allowed to perform optimisations. None of them may do so right now, but
> they
> may in the future and further drive Hyman crazy.
>


They are already starting.
https://www.youtube.com/watch?v=3DIB57wIf9W1k


P.S. Linux might (soon or already) use atomics + volatile in the kernel,
but only if we can't find something better (like fixing
memory_order_consume, etc).



>
> IA-64 may even require it, to avoid a write-after-write collision (unless
> it
> adds a stop bit between the two stores).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/3193822.uToWOrWuY4%40tjmaciei-mobl1.
>



--=20
Be seeing you,
Tony

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbiuQFoaihmcbhVbm%2BGAScC3m%3D7XMm2C2Gt97gUH=
ycKskAg%40mail.gmail.com.

--001a113ce2a4faf7bb05685bad1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Mar 26, 2018 at 8:56 PM, Thiago Macieira <span dir=3D"ltr">&lt;=
<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><span class=3D"gmail-">On segunda-feira, 26 de mar=C3=A7o de 2018 10:34:1=
7 CST Mingxin Wang wrote:<br>
&gt; On Sunday, March 25, 2018 at 9:48:03 PM UTC+8, Thiago Macieira wrote:<=
br>
&gt; &gt; While I don&#39;t subscribe to Hyman&#39;s philosophy regarding o=
ptimisation, he<br>
&gt; &gt; does<br>
&gt; &gt; have a point on ensuring memory reads and writes. std::atomic is =
specified<br>
&gt; &gt; with methods both volatile and non-volatile and that makes a diff=
erence.<br>
&gt; &gt; Atomicity and volatility are not the same concept, especially for=
 base<br>
&gt; &gt; operations like load and store.<br>
&gt;<br>
&gt; As far as I am concerned, there seems to be no guarantee in the standa=
rd<br>
&gt; that `volatile` could prevent using cache, although some compilers pro=
mise<br>
&gt; that.<br>
<br>
</span>There isn&#39;t. Volatile is a tool you use when your specific memor=
y type<br>
requires it. If you need to make that particular memory region non-cached, =
you<br>
need to read your architecture system manual.<br>
<span class=3D"gmail-"><br>
&gt; By the way, is there any meaningful use case where the atomics shall b=
e<br>
&gt; declared `volatile`?<br>
<br>
</span>I just said one: loads and stores.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::atomic&lt;int&gt; a;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a.store(0);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a.store(1);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a.load();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return a.load();<br>
<br>
Since this isn&#39;t volatile, even if a is a global variable, the compiler=
 is<br>
allowed to perform optimisations. None of them may do so right now, but the=
y<br>
may in the future and further drive Hyman crazy.<br></blockquote><div><br><=
br>They are already starting.<br><a href=3D"https://www.youtube.com/watch?v=
=3DIB57wIf9W1k">https://www.youtube.com/watch?v=3DIB57wIf9W1k</a><br><br><b=
r></div><div>P.S. Linux might (soon or already) use atomics + volatile in t=
he kernel, but only if we can&#39;t find something better (like fixing memo=
ry_order_consume, etc).<br></div><div><br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
IA-64 may even require it, to avoid a write-after-write collision (unless i=
t<br>
adds a stop bit between the two stores).<br>
<span class=3D"gmail-"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/3193822.uToWOrWuY4%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/3193822.uToWOrWuY4%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuQFoaihmcbhVbm%2BGAScC3m%3D7XM=
m2C2Gt97gUHycKskAg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuQFoai=
hmcbhVbm%2BGAScC3m%3D7XMm2C2Gt97gUHycKskAg%40mail.gmail.com</a>.<br />

--001a113ce2a4faf7bb05685bad1e--

.

--f4f5e80a1b1481d41f05685e92b9
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 26, 2018 at 8:56 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Since this isn't volatile, even if a is a global variable, the compiler is
> allowed to perform optimisations. None of them may do so right now, but
> they
> may in the future and further drive Hyman crazy.


Driving *me* crazy isn't really the problem:
<
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
>

Optimizationism turns reliable and predictable behavior into a game of
telephone,
where the programmer's instructions get more and more scrambled until the
result
is a mess that doesn't do what the programmer wanted.  But it sure does it
a lot faster!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZPXw0m34WR3KLcAkugGk2d0SWb6Kdj7nJ1uH%2BoHFv08w%40mail.gmail.com.

--f4f5e80a1b1481d41f05685e92b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 26, 2018 at 8:56 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Since this isn&#39;t volatile, even if a is a global variable, the compiler=
 is<br>
allowed to perform optimisations. None of them may do so right now, but the=
y<br>
may in the future and further drive Hyman crazy.</blockquote><div><br>Drivi=
ng *me* crazy isn&#39;t really the problem:<br>&lt;<a href=3D"https://rando=
mascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/">=
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-th=
e-xbox-360/</a>&gt;<br><br>Optimizationism turns reliable and predictable b=
ehavior into a game of telephone,<br>where the programmer&#39;s instruction=
s get more and more scrambled until the result<br>is a mess that doesn&#39;=
t do what the programmer wanted.=C2=A0 But it sure does it a lot faster!</d=
iv></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZPXw0m34WR3KLcAkugGk2d0SWb6Kdj=
7nJ1uH%2BoHFv08w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZPXw0m34=
WR3KLcAkugGk2d0SWb6Kdj7nJ1uH%2BoHFv08w%40mail.gmail.com</a>.<br />

--f4f5e80a1b1481d41f05685e92b9--

.

------=_Part_20379_942400489.1522193976897
Content-Type: multipart/alternative;
 boundary="----=_Part_20380_289708334.1522193976898"

------=_Part_20380_289708334.1522193976898
Content-Type: text/plain; charset="UTF-8"



On Tuesday, March 27, 2018 at 7:58:00 AM UTC+2, Hyman Rosen wrote:
>
> On Mon, Mar 26, 2018 at 8:56 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>>
>> Since this isn't volatile, even if a is a global variable, the compiler is
>> allowed to perform optimisations. None of them may do so right now, but
>> they
>> may in the future and further drive Hyman crazy.
>
>
> Driving *me* crazy isn't really the problem:
> <
> https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
> >
>
> Optimizationism turns reliable and predictable behavior into a game of
> telephone,
> where the programmer's instructions get more and more scrambled until the
> result
> is a mess that doesn't do what the programmer wanted.  But it sure does it
> a lot faster!
>

I probably read different article, where is any mention of compiler
optimization?
We have only case of bugged instruction that cause bad effect even if not
executed directly.

BTW optimization is problem if you try be clever and work against it, if
you write code that
expect optimization then you can stop waste time writing manual
optimizations and your code will run faster.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8e3dd79-24dc-4989-9546-33a1534cbda8%40isocpp.org.

------=_Part_20380_289708334.1522193976898
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 27, 2018 at 7:58:00 AM UTC+2, Hy=
man Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Mon, Mar 26, 2018 at 8:56 PM, Thiago =
Macieira <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"9XA-RzVFAwAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">thi...@macieira.org</a>&gt;</span> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
Since this isn&#39;t volatile, even if a is a global variable, the compiler=
 is<br>
allowed to perform optimisations. None of them may do so right now, but the=
y<br>
may in the future and further drive Hyman crazy.</blockquote><div><br>Drivi=
ng *me* crazy isn&#39;t really the problem:<br>&lt;<a href=3D"https://rando=
mascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://=
www.google.com/url?q\x3dhttps%3A%2F%2Frandomascii.wordpress.com%2F2018%2F01=
%2F07%2Ffinding-a-cpu-design-bug-in-the-xbox-360%2F\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEkD3V6Hc6ye4h7ij1XiE9MGzOswQ&#39;;return true;" onclick=3D=
"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Frandomascii=
..wordpress.com%2F2018%2F01%2F07%2Ffinding-a-cpu-design-bug-in-the-xbox-360%=
2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEkD3V6Hc6ye4h7ij1XiE9MGzOswQ&#39=
;;return true;">https://randomascii.<wbr>wordpress.com/2018/01/07/<wbr>find=
ing-a-cpu-design-bug-in-<wbr>the-xbox-360/</a>&gt;<br><br>Optimizationism t=
urns reliable and predictable behavior into a game of telephone,<br>where t=
he programmer&#39;s instructions get more and more scrambled until the resu=
lt<br>is a mess that doesn&#39;t do what the programmer wanted.=C2=A0 But i=
t sure does it a lot faster!</div></div></div></div></blockquote><div><br>I=
 probably read different article, where is any mention of compiler optimiza=
tion?<br>We have only case of bugged instruction that cause bad effect even=
 if not executed directly.<br><br>BTW optimization is problem if you try be=
 clever and work against it, if you write code that<br>expect optimization =
then you can stop waste time writing manual optimizations and your code wil=
l run faster.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8e3dd79-24dc-4989-9546-33a1534cbda8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8e3dd79-24dc-4989-9546-33a1534cbda8=
%40isocpp.org</a>.<br />

------=_Part_20380_289708334.1522193976898--

------=_Part_20379_942400489.1522193976897--

.

--001a11497574e5b005056871bb8e
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 27, 2018 at 7:39 PM, <inkwizytoryankes@gmail.com> wrote:
>
> I probably read different article, where is any mention of compiler
> optimization?
>

You think optimizationism affects (or infects...) only compiler writers?

BTW optimization is problem if you try be clever and work against it
>

Compiler optimization is a problem when it subverts the clear intent of the
programmer in order to make the wrong code faster.  Whenever a compiler
says "the programmer could not have meant to say this, so I'll ignore it" it
is making a grave error.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZBJBESyPBiX1t30bQTwp5%3D6HJPUCDeTwD%2Bb6o4%3DGzK-g%40mail.gmail.com.

--001a11497574e5b005056871bb8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 27, 2018 at 7:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I probab=
ly read different article, where is any mention of compiler optimization?<b=
r></div></div></blockquote><div><br>You think optimizationism affects (or i=
nfects...) only compiler writers?<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>BTW optimization is problem if you try be clever a=
nd work against it</div></div></blockquote><div><br>Compiler optimization i=
s a problem when it subverts the clear intent of the<br>programmer in order=
 to make the wrong code faster.=C2=A0 Whenever a compiler<br>says &quot;the=
 programmer could not have meant to say this, so I&#39;ll ignore it&quot; i=
t<br>is making a grave error.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZBJBESyPBiX1t30bQTwp5%3D6HJPUC=
DeTwD%2Bb6o4%3DGzK-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZBJB=
ESyPBiX1t30bQTwp5%3D6HJPUCDeTwD%2Bb6o4%3DGzK-g%40mail.gmail.com</a>.<br />

--001a11497574e5b005056871bb8e--

.

--94eb2c08b3489eadab0568e33ae9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Short answer is: the number and order of reads and writes to a volatile
object must be preserved as programmed, in the user thread; if the compiler
strictly follows the standards, any read or write from/to the volatile
object must accesses the actual memory location. This is different from
synchronization mechanisms where normally the atomicity of a
read>modify>write sequence is implied - either systemwide or process wide.
I can hardly imagine any other use case than external hardware
communication such as DMA or memory mapped IO. In the embedded world and
system/peripheral programming, this usage of the keyword becomes bold.

Regards,
FM.

=D8=AF=D8=B1 =D8=AA=D8=A7=D8=B1=DB=8C=D8=AE =DB=B2=DB=B3 =D9=85=D8=A7=D8=B1=
=D8=B3 =DB=B2=DB=B0=DB=B1=DB=B8 =DB=B1=DB=B0:=DB=B5=DB=B1 =D9=82=D8=A8=D9=
=84=E2=80=8C=D8=A7=D8=B2=D8=B8=D9=87=D8=B1=D8=8C "Mingxin Wang" <wmx16835vv=
@163.com>
=D9=86=D9=88=D8=B4=D8=AA:

I am confusing about the necessity of the keyword `volatile` in C++, as we
already have the atomics, and this keyword is not able to deal with
processor optimizations. Is there any meaningful use case that depends on
this keyword in C++ (except for the atomic library in C)? If not, I think
it shall be deprecated or removed, like the keyword `register`.

I am looking forward to your comments!

Mingxin Wang

--=20
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-=
4ce3-a5e2-3a23c1c0d678%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313=
-4ce3-a5e2-3a23c1c0d678%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter=
>
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALDL7dE7cun_r-TjMmEMuFxeMTVhJ5E-8n%3DOfSGynO8-p=
EmE-g%40mail.gmail.com.

--94eb2c08b3489eadab0568e33ae9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Short answer is: the number and order of reads and writes=
 to a volatile object must be preserved as programmed, in the user thread; =
if the compiler strictly follows the standards, any read or write from/to t=
he volatile object must accesses the actual memory location. This is differ=
ent from synchronization mechanisms where normally the atomicity of a read&=
gt;modify&gt;write sequence is implied - either systemwide or process wide.=
=C2=A0<div dir=3D"auto">I can hardly imagine any other use case than extern=
al hardware communication such as DMA or memory mapped IO. In the embedded =
world and system/peripheral programming, this usage of the keyword becomes =
bold.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards,</div><div=
 dir=3D"auto">FM.=C2=A0=C2=A0</div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">=D8=AF=D8=B1 =D8=AA=D8=A7=D8=B1=DB=8C=D8=AE =DB=B2=
=DB=B3 =D9=85=D8=A7=D8=B1=D8=B3 =DB=B2=DB=B0=DB=B1=DB=B8 =DB=B1=DB=B0:=DB=
=B5=DB=B1 =D9=82=D8=A8=D9=84=E2=80=8C=D8=A7=D8=B2=D8=B8=D9=87=D8=B1=D8=8C &=
quot;Mingxin Wang&quot; &lt;<a href=3D"mailto:wmx16835vv@163.com">wmx16835v=
v@163.com</a>&gt; =D9=86=D9=88=D8=B4=D8=AA:<br type=3D"attribution"><blockq=
uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">I am confusing about the necessity of th=
e keyword `volatile` in C++, as we already have the atomics, and this keywo=
rd is not able to deal with processor optimizations. Is there any meaningfu=
l use case that depends on this keyword in C++ (except for the atomic libra=
ry in C)? If not, I think it shall be deprecated or removed, like the keywo=
rd `register`.<br><div><br></div><div>I am looking forward to your comments=
!</div><div class=3D"signature-text"><div><br></div><div>Mingxin Wang</div>=
</div></div><div class=3D"signature-text">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/044dfdd3-2313-4ce3-a5e2-3a23c1c0d678%40isocpp.org</a>.<br>
</div></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dE7cun_r-TjMmEMuFxeMTVhJ5E-8n%3=
DOfSGynO8-pEmE-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dE7cun_r-=
TjMmEMuFxeMTVhJ5E-8n%3DOfSGynO8-pEmE-g%40mail.gmail.com</a>.<br />

--94eb2c08b3489eadab0568e33ae9--

.

--001a1147c34c01e6ae0568e3b464
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 2, 2018 at 4:13 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:
>
> I can hardly imagine any other use case than external hardware
> communication such as DMA or memory mapped IO.
>

As I already said earlier in the thread, my main use for it has been, and
continues
to be, forcing the compiler to write floating-point expressions to memory
in those
cases where I need precisely specified results.  Otherwise the compiler may
keep
evaluated expressions in higher precision registers so that they do not
have their
exactly specified correct values.

<https://gcc.gnu.org/wiki/FloatingPointMath>






*For legacy x86 processors without SSE2 support, and for m68080
processors,GCC is only able to fully comply with IEEE 754 semantics for the
IEEE doubleextended (long double) type. Operations on IEEE double precision
and IEEEsingle precision values are performed using double extended
precision.In order to have these operations rounded correctly, GCC would
have to savethe FPU control and status words, enable rounding to 24 or 53
mantissa bitsand then restore the FPU state. This would be far too
expensive.*

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfOer8tg6PsmpUn6-SCFgMGs2_Y6adcf_w%2BGNnWRa_%2BA%40mail.gmail.com.

--001a1147c34c01e6ae0568e3b464
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 2, 2018 at 4:13 PM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=3D"=
mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com</=
a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><div dir=3D"auto">I can hardly imagine any other use case than=
 external hardware communication such as DMA or memory mapped IO.</div></di=
v></blockquote><div><br>As I already said earlier in the thread, my main us=
e for it has been, and continues<br>to be, forcing the compiler to write fl=
oating-point expressions to memory in those<br>cases where I need precisely=
 specified results.=C2=A0 Otherwise the compiler may keep<br>evaluated expr=
essions in higher precision registers so that they do not have their<br>exa=
ctly specified correct values.<br><br>&lt;<a href=3D"https://gcc.gnu.org/wi=
ki/FloatingPointMath">https://gcc.gnu.org/wiki/FloatingPointMath</a>&gt;<br=
><i>For legacy x86 processors without SSE2 support, and for m68080 processo=
rs,<br>GCC is only able to fully comply with IEEE 754 semantics for the IEE=
E double<br>extended (long double) type. Operations on IEEE double precisio=
n and IEEE<br>single precision values are performed using double extended p=
recision.<br>In order to have these operations rounded correctly, GCC would=
 have to save<br>the FPU control and status words, enable rounding to 24 or=
 53 mantissa bits<br>and then restore the FPU state. This would be far too =
expensive.</i><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfOer8tg6PsmpUn6-SCFgMGs2_Y6ad=
cf_w%2BGNnWRa_%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfOer8=
tg6PsmpUn6-SCFgMGs2_Y6adcf_w%2BGNnWRa_%2BA%40mail.gmail.com</a>.<br />

--001a1147c34c01e6ae0568e3b464--

.

------=_Part_13370_2036745202.1522746098441
Content-Type: text/plain; charset="UTF-8"

For the particular use of floating point precision control volatile seems very inefficient as you don't really need writing and reading main memory. Maybe an intrinsic std::preserve_precision() would be a good thing to propose?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9bc32039-04fe-42cd-abc4-49040cf3a6dc%40isocpp.org.

------=_Part_13370_2036745202.1522746098441--

.

--001a114b332c46a5b10568f1cfb5
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> For the particular use of floating point precision control volatile seems
> very inefficient as you don't really need writing and reading main memory.
> Maybe an intrinsic std::preserve_precision() would be a good thing to
> propose?


On the contrary, if the compiler is going to insist on doing the wrong thing
on behalf of the optimizationists, volatile gives me just the control I need
(i.e., on particular results) and does it in a standard-conforming way
that's
already in the language, and in C as well, since the problem exists there
also.

I believe the language standards already specify that casts to float and
double
and assignments to variables are supposed to use the precision of the
target.
But gcc refuses to honor that.  It does honor volatile, though.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbJzNpUAsH%2BP1PAPv2UO2v-KEFrecC36rMSwQuvKQHc1w%40mail.gmail.com.

--001a114b332c46a5b10568f1cfb5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsso=
n@beamways.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For =
the particular use of floating point precision control volatile seems very =
inefficient as you don&#39;t really need writing and reading main memory. M=
aybe an intrinsic std::preserve_precision() would be a good thing to propos=
e?</blockquote><div><br>On the contrary, if the compiler is going to insist=
 on doing the wrong thing<br>on behalf of the optimizationists, volatile gi=
ves me just the control I need<br>(i.e., on particular results) and does it=
 in a standard-conforming way that&#39;s<br>already in the language, and in=
 C as well, since the problem exists there also.<br><br>I believe the langu=
age standards already specify that casts to float and double<br>and assignm=
ents to variables are supposed to use the precision of the target.<br>But g=
cc refuses to honor that.=C2=A0 It does honor volatile, though.</div></div>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbJzNpUAsH%2BP1PAPv2UO2v-KEFrec=
C36rMSwQuvKQHc1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbJzNpUAs=
H%2BP1PAPv2UO2v-KEFrecC36rMSwQuvKQHc1w%40mail.gmail.com</a>.<br />

--001a114b332c46a5b10568f1cfb5--

.

On 04/03/18 16:37, Hyman Rosen wrote:
> On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson
> <bengt.gustafsson@beamways.com <mailto:bengt.gustafsson@beamways.com>>
> wrote:
>
>     For the particular use of floating point precision control volatile
>     seems very inefficient as you don't really need writing and reading
>     main memory. Maybe an intrinsic std::preserve_precision() would be a
>     good thing to propose?
>
> On the contrary, if the compiler is going to insist on doing the wrong thing
> on behalf of the optimizationists, volatile gives me just the control I need
> (i.e., on particular results) and does it in a standard-conforming way
> that's
> already in the language, and in C as well, since the problem exists
> there also.

AFAICS, C allows to perform operations with increased precision, see C11
6.3.1.8/2. I do not find a similar grant in C++ though, but I consider
it a very useful one, which allows things like FMA.

I'm struggling to see a use case where I would want reduced precision of
math operations where they could potentially be more precise for free.
Your use of volatile for this purpose is certainly unusual and, I'd
wager, not the intended use case for it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ff48755d-ef5a-4f6d-7ac1-a408ac2ddfaa%40gmail.com.

.

------=_Part_21902_1555681968.1522767655645
Content-Type: multipart/alternative;
 boundary="----=_Part_21903_1131949008.1522767655646"

------=_Part_21903_1131949008.1522767655646
Content-Type: text/plain; charset="UTF-8"



On Tuesday, April 3, 2018 at 10:48:59 AM UTC-4, Andrey Semashev wrote:
>
> On 04/03/18 16:37, Hyman Rosen wrote:
> > On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson
> > <bengt.gu...@beamways.com <javascript:> <mailto:bengt.gu...@beamways.com
> <javascript:>>>
> > wrote:
> >
> >     For the particular use of floating point precision control volatile
> >     seems very inefficient as you don't really need writing and reading
> >     main memory. Maybe an intrinsic std::preserve_precision() would be a
> >     good thing to propose?
> >
> > On the contrary, if the compiler is going to insist on doing the wrong
> thing
> > on behalf of the optimizationists, volatile gives me just the control I
> need
> > (i.e., on particular results) and does it in a standard-conforming way
> > that's
> > already in the language, and in C as well, since the problem exists
> > there also.
>
> AFAICS, C allows to perform operations with increased precision, see C11
> 6.3.1.8/2. I do not find a similar grant in C++ though, but I consider
> it a very useful one, which allows things like FMA.
>
> I'm struggling to see a use case where I would want reduced precision of
> math operations where they could potentially be more precise for free.
>

There have been cases where I've needed, not "reduced" precision, but
*consistent* precision: computations that give binary-identical results
across implementations and even CPUs. Basically, "follow the IEEE-754
standard exactly". You can get that with integer math, but with floats,
it's a lot harder.


> Your use of volatile for this purpose is certainly unusual and, I'd
> wager, not the intended use case for it.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ad3421e1-ce25-4839-9be0-00337a025de9%40isocpp.org.

------=_Part_21903_1131949008.1522767655646
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, April 3, 2018 at 10:48:59 AM UTC-4, An=
drey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 04/03/1=
8 16:37, Hyman Rosen wrote:
<br>&gt; On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson=20
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"lYaaLT-IBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">bengt.gu...@beamways.com</a> &lt;mailto:<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"lYaaLT-IBQAJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.=
href=3D&#39;javascript:&#39;;return true;">bengt.gu...@<wbr>beamways.com</a=
>&gt;&gt;=20
<br>&gt; wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 For the particular use of floating point precision c=
ontrol volatile
<br>&gt; =C2=A0 =C2=A0 seems very inefficient as you don&#39;t really need =
writing and reading
<br>&gt; =C2=A0 =C2=A0 main memory. Maybe an intrinsic std::preserve_precis=
ion() would be a
<br>&gt; =C2=A0 =C2=A0 good thing to propose?
<br>&gt;=20
<br>&gt; On the contrary, if the compiler is going to insist on doing the w=
rong thing
<br>&gt; on behalf of the optimizationists, volatile gives me just the cont=
rol I need
<br>&gt; (i.e., on particular results) and does it in a standard-conforming=
 way=20
<br>&gt; that&#39;s
<br>&gt; already in the language, and in C as well, since the problem exist=
s=20
<br>&gt; there also.
<br>
<br>AFAICS, C allows to perform operations with increased precision, see C1=
1=20
<br><a href=3D"http://6.3.1.8/2" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2F6.3.1.=
8%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHiZ5FIyq9spzvjhvuwKGfJFpgHKw&=
#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\=
x3dhttp%3A%2F%2F6.3.1.8%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHiZ5FIy=
q9spzvjhvuwKGfJFpgHKw&#39;;return true;">6.3.1.8/2</a>. I do not find a sim=
ilar grant in C++ though, but I consider=20
<br>it a very useful one, which allows things like FMA.
<br>
<br>I&#39;m struggling to see a use case where I would want reduced precisi=
on of=20
<br>math operations where they could potentially be more precise for free.<=
br></blockquote><div><br>There have been cases where I&#39;ve needed, not &=
quot;reduced&quot; precision, but <i>consistent</i> precision: computations=
 that give binary-identical results across implementations and even CPUs. B=
asically, &quot;follow the IEEE-754 standard exactly&quot;. You can get tha=
t with integer math, but with floats, it&#39;s a lot harder.<br>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">Your use of volatile for this=
 purpose is certainly unusual and, I&#39;d=20
<br>wager, not the intended use case for it.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad3421e1-ce25-4839-9be0-00337a025de9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad3421e1-ce25-4839-9be0-00337a025de9=
%40isocpp.org</a>.<br />

------=_Part_21903_1131949008.1522767655646--

------=_Part_21902_1555681968.1522767655645--

.

--001a11497574da48d00568f36b35
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 3, 2018 at 11:00 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> AFAICS, C allows to perform operations with increased precision, see C11
>> 6.3.1.8/2. I do not find a similar grant in C++ though, but I consider
>> it a very useful one, which allows things like FMA.
>>
>
[expr]/13 in N4700


*The values of the floating operands and the results of floating
expressions maybe represented in greater precision and range than that
required by the type;the types are not changed thereby.*


>
>> I'm struggling to see a use case where I would want reduced precision of
>> math operations where they could potentially be more precise for free.
>>
>
> There have been cases where I've needed, not "reduced" precision, but
>
*consistent* precision: computations that give binary-identical results
> across
>
implementations and even CPUs. Basically, "follow the IEEE-754 standard
>
exactly". You can get that with integer math, but with floats, it's a lot
> harder.
>

Yes.  In my use cases, this usually happens around conversions between
binary and decimal, which are extraordinarily delicate computations.  Having
the compiler inject arbitrary precision is bad.  We had similar issues
trying to
convert a fractional number of seconds as a double into an integer pair of
seconds and nanoseconds and to get the same results everywhere.  (On all
of our platforms, doubles use the same IEEE-754 representation, and it is
simply unacceptable to us that a number with an exact value will convert to
different results on different platforms.  We regard that as an error, and
using
volatile helped us fix the problem.)

Your use of volatile for this purpose is certainly unusual and, I'd
>> wager, not the intended use case for it.
>
>
I don't care what anyone intended.  It works, and it's portable.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapfp2ErhDEyZ877Vqx-%3DnfMBv6sjgtZWe-62NL4eW8%2BQ%40mail.gmail.com.

--001a11497574da48d00568f36b35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Apr 3, 2018 at 11:00 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"m_53091=
70674039202556gmail-">AFAICS, C allows to perform operations with increased=
 precision, see C11=20
<br><a href=3D"http://6.3.1.8/2" rel=3D"nofollow" target=3D"_blank">6.3.1.8=
/2</a>. I do not find a similar grant in C++ though, but I consider=20
<br>it a very useful one, which allows things like FMA.
<br></span></blockquote></div></blockquote><div><br>[expr]/13 in N4700<br><=
div><i>The values of the floating operands and the results of floating expr=
essions may<br>be represented in greater precision and range than that requ=
ired by the type;<br>the types are not changed thereby.</i></div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><span class=3D"m_53091706740392=
02556gmail-">
<br>I&#39;m struggling to see a use case where I would want reduced precisi=
on of=20
<br>math operations where they could potentially be more precise for free.<=
br></span></blockquote><div><br>There have been cases where I&#39;ve needed=
, not &quot;reduced&quot; precision, but</div></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><i>consistent=
</i> precision: computations that give binary-identical results across</div=
></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>implementations and even CPUs. Basically, &quot;follow the=
 IEEE-754 standard</div></div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>exactly&quot;. You can get that wit=
h integer math, but with floats, it&#39;s a lot harder.<br></div></div></bl=
ockquote><div><br>Yes.=C2=A0 In my use cases, this usually happens around c=
onversions between<br>binary and decimal, which are extraordinarily delicat=
e computations.=C2=A0 Having<br>the compiler inject arbitrary precision is =
bad.=C2=A0 We had similar issues trying to</div><div>convert a fractional n=
umber of seconds as a double into an integer pair of<br>seconds and nanosec=
onds and to get the same results everywhere.=C2=A0 (On all<br>of our platfo=
rms, doubles use the same IEEE-754 representation, and it is<br>simply unac=
ceptable to us that a number with an exact value will convert to<br>differe=
nt results on different platforms.=C2=A0 We regard that as an error, and us=
ing<br>volatile helped us fix the problem.)<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"m_53091706=
74039202556gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Your u=
se of volatile for this purpose is certainly unusual and, I&#39;d=20
<br>wager, not the intended use case for it.</blockquote></span></div></blo=
ckquote><div><br>I don&#39;t care what anyone intended.=C2=A0 It works, and=
 it&#39;s portable.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapfp2ErhDEyZ877Vqx-%3DnfMBv6sj=
gtZWe-62NL4eW8%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapfp2E=
rhDEyZ877Vqx-%3DnfMBv6sjgtZWe-62NL4eW8%2BQ%40mail.gmail.com</a>.<br />

--001a11497574da48d00568f36b35--

.

--00000000000044e0410568f46296
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 3, 2018 at 7:48 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 04/03/18 16:37, Hyman Rosen wrote:
>
>> On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson <
>> bengt.gustafsson@beamways.com <mailto:bengt.gustafsson@beamways.com>>
>> wrote:
>>
>>     For the particular use of floating point precision control volatile
>>     seems very inefficient as you don't really need writing and reading
>>     main memory. Maybe an intrinsic std::preserve_precision() would be a
>>     good thing to propose?
>>
>> On the contrary, if the compiler is going to insist on doing the wrong
>> thing
>> on behalf of the optimizationists, volatile gives me just the control I
>> need
>> (i.e., on particular results) and does it in a standard-conforming way
>> that's
>> already in the language, and in C as well, since the problem exists there
>> also.
>>
>
> AFAICS, C allows to perform operations with increased precision, see C11
> 6.3.1.8/2. I do not find a similar grant in C++ though, but I consider it
> a very useful one, which allows things like FMA.
>
> I'm struggling to see a use case where I would want reduced precision of
> math operations where they could potentially be more precise for free. Your
> use of volatile for this purpose is certainly unusual and, I'd wager, not
> the intended use case for it.


Reproducibility and consistency.

For example, if a debug build contains a statement that causes the flushing
of the x87 register but which otherwise does not touch non-debug numerical
data, it will perturb the numerical results, leading the application
developer to bang their head against the wall because the debug build gives
different answers than the production build.

For example, if somebody is running a code on x86 and PowerPC platforms,
they expect to get the same answer if the code does not depend on the
architecture.  If the x86 execution uses x87, it may lead to different
results.

The latter example is similar to the case of FMA.  There are application
developers who use std::fma on systems that lack hardware support in order
to get numerical reproducibility in spite of the cost of implementing the
singly-rounded fma in software.

In many cases, these are not academic issues.  Some of the users involved
in the aforementioned examples are required to implement numerically
reproducible and/or numerically consistent code for regulatory reasons.

Jeff

--
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJYj380J4M2Jk3Rgc2da3QTEK%3Dc%2BsO1uFwDJEN76bNw0w%40mail.gmail.com.

--00000000000044e0410568f46296
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Apr 3, 2018 at 7:48 AM, Andrey Semashev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semash=
ev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/=
03/18 16:37, Hyman Rosen wrote:<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson &lt;<a href=3D"mailto:beng=
t.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beamways.com<=
/a> &lt;mailto:<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_=
blank">bengt.gustafsson@beamw<wbr>ays.com</a>&gt;&gt; wrote:<br>
<br>
=C2=A0 =C2=A0 For the particular use of floating point precision control vo=
latile<br>
=C2=A0 =C2=A0 seems very inefficient as you don&#39;t really need writing a=
nd reading<br>
=C2=A0 =C2=A0 main memory. Maybe an intrinsic std::preserve_precision() wou=
ld be a<br>
=C2=A0 =C2=A0 good thing to propose?<br>
<br>
On the contrary, if the compiler is going to insist on doing the wrong thin=
g<br>
on behalf of the optimizationists, volatile gives me just the control I nee=
d<br>
(i.e., on particular results) and does it in a standard-conforming way that=
&#39;s<br>
already in the language, and in C as well, since the problem exists there a=
lso.<br>
</blockquote>
<br></span>
AFAICS, C allows to perform operations with increased precision, see C11 <a=
 href=3D"http://6.3.1.8/2" rel=3D"noreferrer" target=3D"_blank">6.3.1.8/2</=
a>. I do not find a similar grant in C++ though, but I consider it a very u=
seful one, which allows things like FMA.<br>
<br>
I&#39;m struggling to see a use case where I would want reduced precision o=
f math operations where they could potentially be more precise for free. Yo=
ur use of volatile for this purpose is certainly unusual and, I&#39;d wager=
, not the intended use case for it.</blockquote><div><br></div><div>Reprodu=
cibility and consistency.</div><div><br></div><div>For example, if a debug =
build contains a statement that causes the flushing of the x87 register but=
 which otherwise does not touch non-debug numerical data, it will perturb t=
he numerical results, leading the application developer to bang their head =
against the wall because the debug build gives different answers than the p=
roduction build.</div><div><br></div><div>For example, if somebody is runni=
ng a code on x86 and PowerPC platforms, they expect to get the same answer =
if the code does not depend on the architecture.=C2=A0 If the x86 execution=
 uses x87, it may lead to different results.</div><div><br></div><div>The l=
atter example is similar to the case of FMA.=C2=A0 There are application de=
velopers who use std::fma on systems that lack hardware support in order to=
 get numerical reproducibility in spite of the cost of implementing the sin=
gly-rounded fma in software.</div><div><br></div><div>In many cases, these =
are not academic issues.=C2=A0 Some of the users involved in the aforementi=
oned examples are required to implement numerically reproducible and/or num=
erically consistent code for regulatory reasons.</div><div><br></div><div>J=
eff=C2=A0</div></div><div><br></div>-- <br><div class=3D"gmail_signature" d=
ata-smartmail=3D"gmail_signature">Jeff Hammond<br><a href=3D"mailto:jeff.sc=
ience@gmail.com" target=3D"_blank">jeff.science@gmail.com</a><br><a href=3D=
"http://jeffhammond.github.io/" target=3D"_blank">http://jeffhammond.github=
..io/</a></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJYj380J4M2Jk3Rgc2da3QTEK%3Dc=
%2BsO1uFwDJEN76bNw0w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJY=
j380J4M2Jk3Rgc2da3QTEK%3Dc%2BsO1uFwDJEN76bNw0w%40mail.gmail.com</a>.<br />

--00000000000044e0410568f46296--

.

On 04/03/18 19:41, Jeff Hammond wrote:
>=20
>=20
> On Tue, Apr 3, 2018 at 7:48 AM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     On 04/03/18 16:37, Hyman Rosen wrote:
>=20
>         On Tue, Apr 3, 2018 at 5:01 AM, Bengt Gustafsson
>         <bengt.gustafsson@beamways.com
>         <mailto:bengt.gustafsson@beamways.com>
>         <mailto:bengt.gustafsson@beamways.com
>         <mailto:bengt.gustafsson@beamways.com>>> wrote:
>=20
>          =C2=A0 =C2=A0 For the particular use of floating point precision=
 control
>         volatile
>          =C2=A0 =C2=A0 seems very inefficient as you don't really need wr=
iting and
>         reading
>          =C2=A0 =C2=A0 main memory. Maybe an intrinsic std::preserve_prec=
ision()
>         would be a
>          =C2=A0 =C2=A0 good thing to propose?
>=20
>         On the contrary, if the compiler is going to insist on doing the
>         wrong thing
>         on behalf of the optimizationists, volatile gives me just the
>         control I need
>         (i.e., on particular results) and does it in a
>         standard-conforming way that's
>         already in the language, and in C as well, since the problem
>         exists there also.
>=20
>=20
>     AFAICS, C allows to perform operations with increased precision, see
>     C11 6.3.1.8/2 <http://6.3.1.8/2>. I do not find a similar grant in
>     C++ though, but I consider it a very useful one, which allows things
>     like FMA.
>=20
>     I'm struggling to see a use case where I would want reduced
>     precision of math operations where they could potentially be more
>     precise for free. Your use of volatile for this purpose is certainly
>     unusual and, I'd wager, not the intended use case for it.
>=20
> Reproducibility and consistency.
>=20
> For example, if a debug build contains a statement that causes the=20
> flushing of the x87 register but which otherwise does not touch=20
> non-debug numerical data, it will perturb the numerical results, leading=
=20
> the application developer to bang their head against the wall because=20
> the debug build gives different answers than the production build.
>=20
> For example, if somebody is running a code on x86 and PowerPC platforms,=
=20
> they expect to get the same answer if the code does not depend on the=20
> architecture.=C2=A0 If the x86 execution uses x87, it may lead to differe=
nt=20
> results.

I think, that expectation is wrong. The language doesn't give you such=20
guarantees.

> In many cases, these are not academic issues.=C2=A0 Some of the users=20
> involved in the aforementioned examples are required to implement=20
> numerically reproducible and/or numerically consistent code for=20
> regulatory reasons.

Personally, I try to never depend on the exact result when FP is=20
involved. I consider it my design mistake if such need arises and=20
rewrite the code to avoid that. This follows from the nature of FP in=20
C/C++, including that the language does not guarantee that FP is=20
implemented as IEEE-754 in the first place. So, given this my rule of=20
thumb, I do not care if the result is more or less precise, in the=20
reasonable/acceptable error range. More precise is better, though.

I realize there must be scientific applications which are more demanding=20
wrt. result accuracy, but even there I find it hard to imagine that a=20
strict binary equivalence of results are needed. More likely, the=20
acceptable error is less, and if that error is nearing FP precision,=20
most likely you need to use a specialized library for high precision math.

I'm not sure what kind of regulatory reasons you mean, but if those are=20
of non-technical nature then, well, tough luck. I guess, using a=20
specialized library in such case is an appropriate solution as well.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d62b5256-3b1f-5df8-f64a-35aa35648bab%40gmail.com=
..

.

--001a1147c34c65f9810568f8e761
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 3, 2018 at 5:28 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
>
> I think, that expectation is wrong. The language doesn't give you such
> guarantees.


I write programs to achieve certain results.  Those results must be
achieved.
If the basic constructs of the language can achieve those results, fine.
Otherwise the inability of the language must be circumvented.

Personally, I try to never depend on the exact result when FP is involved.


That's nice.  You don't, however, get to tell me what I need my code to do.

 well, tough luck


Yes, that summarizes the optimizationist viewpoint in a nutshell.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9cxdhr2mTmMQ%3DWA%40mail.gmail.com.

--001a1147c34c65f9810568f8e761
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Apr 3, 2018 at 5:28 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think, that expectation is wrong. The language doesn&#39;t give you such =
guarantees.</blockquote><div><br>I write programs to achieve certain result=
s.=C2=A0 Those results must be achieved.<br>If the basic constructs of the =
language can achieve those results, fine.<br>Otherwise the inability of the=
 language must be circumvented.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Personally, I try to never depend on the exact result when FP is involved.<=
/blockquote><div><br>That&#39;s nice.=C2=A0 You don&#39;t, however, get to =
tell me what I need my code to do.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">=C2=A0well, tough luck</blockquote><div><br>Yes, that summarizes the op=
timizationist viewpoint in a nutshell.=C2=A0</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9=
cxdhr2mTmMQ%3DWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQ=
SC4srXSP3oznBgnjGBBBE9cxdhr2mTmMQ%3DWA%40mail.gmail.com</a>.<br />

--001a1147c34c65f9810568f8e761--

.

--f403045c11e44d30700568f8eea3
Content-Type: text/plain; charset="UTF-8"

It's not the "optimizationists" fault if you want to do something the
language doesn't guarantee. You aren't writing c++ at that point, you are
writing to the compiler specifications.

On Tue, Apr 3, 2018, 18:05 Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Tue, Apr 3, 2018 at 5:28 PM, Andrey Semashev <andrey.semashev@gmail.com
> > wrote:
>>
>> I think, that expectation is wrong. The language doesn't give you such
>> guarantees.
>
>
> I write programs to achieve certain results.  Those results must be
> achieved.
> If the basic constructs of the language can achieve those results, fine.
> Otherwise the inability of the language must be circumvented.
>
> Personally, I try to never depend on the exact result when FP is involved.
>
>
> That's nice.  You don't, however, get to tell me what I need my code to do.
>
>  well, tough luck
>
>
> Yes, that summarizes the optimizationist viewpoint in a nutshell.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9cxdhr2mTmMQ%3DWA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9cxdhr2mTmMQ%3DWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-EWQPOciJdnVR6OCrx8N9hEVQKBkafDedJr-gBxh2MfA%40mail.gmail.com.

--f403045c11e44d30700568f8eea3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">It&#39;s not the &quot;optimizationists&quot; fault if yo=
u want to do something the language doesn&#39;t guarantee. You aren&#39;t w=
riting c++ at that point, you are writing to the compiler specifications.=
=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 3, =
2018, 18:05 Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com">hyman.=
rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, =
Apr 3, 2018 at 5:28 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:andrey.semashev@gmail.com" target=3D"_blank" rel=3D"noreferrer">andrey=
..semashev@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think, that expectation is wrong. The language doesn&#39;t give you such =
guarantees.</blockquote><div><br>I write programs to achieve certain result=
s.=C2=A0 Those results must be achieved.<br>If the basic constructs of the =
language can achieve those results, fine.<br>Otherwise the inability of the=
 language must be circumvented.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Personally, I try to never depend on the exact result when FP is involved.<=
/blockquote><div><br>That&#39;s nice.=C2=A0 You don&#39;t, however, get to =
tell me what I need my code to do.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">=C2=A0well, tough luck</blockquote><div><br>Yes, that summarizes the op=
timizationist viewpoint in a nutshell.=C2=A0</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9=
cxdhr2mTmMQ%3DWA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAHSYqdZ-BHgNWQSC4srXSP3oznBgnjGBBBE9cxdhr2mTmMQ%=
3DWA%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-EWQPOciJdnVR6OCrx8N9hEVQKBkaf=
DedJr-gBxh2MfA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-EWQPOciJd=
nVR6OCrx8N9hEVQKBkafDedJr-gBxh2MfA%40mail.gmail.com</a>.<br />

--f403045c11e44d30700568f8eea3--

.

On 04/04/18 01:05, Hyman Rosen wrote:
> On Tue, Apr 3, 2018 at 5:28 PM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     Personally, I try to never depend on the exact result when FP is
>     involved.
>=20
> That's nice.=C2=A0 You don't, however, get to tell me what I need my code=
 to do.

I never did.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1aa78f07-2875-8178-63a4-4698472fc48c%40gmail.com=
..

.

On ter=C3=A7a-feira, 3 de abril de 2018 08:00:55 PDT Nicol Bolas wrote:
> > I'm struggling to see a use case where I would want reduced precision o=
f
> > math operations where they could potentially be more precise for free.
>=20
> There have been cases where I've needed, not "reduced" precision, but
> *consistent* precision: computations that give binary-identical results
> across implementations and even CPUs. Basically, "follow the IEEE-754
> standard exactly". You can get that with integer math, but with floats,
> it's a lot harder.

That's usually the case. The extra precision may be beneficial, except when=
=20
you're writing bit-exact unit tests.

I was discussing this with some colleagues who maintain the Mesa library an=
d=20
they mentioned an upgrade from GCC 6 to 7 broke their unit tests on 32-bit=
=20
x86, for the same sources. They tracked down to the extra precision, a prob=
lem=20
they worked around with -mfpmath=3Dsse.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1786200.LnV3syU5vJ%40tjmaciei-mobl1.

.

On ter=C3=A7a-feira, 3 de abril de 2018 17:37:16 PDT Thiago Macieira wrote:
> > There have been cases where I've needed, not "reduced" precision, but
> > *consistent* precision: computations that give binary-identical results
> > across implementations and even CPUs. Basically, "follow the IEEE-754
> > standard exactly". You can get that with integer math, but with floats,
> > it's a lot harder.
>=20
> That's usually the case. The extra precision may be beneficial, except wh=
en
> you're writing bit-exact unit tests.

You may also have a problem when an algorithm converges or fails to do so d=
ue=20
to numeric instability. This was more common in the days where 32-bit x86 w=
as=20
more relevant for development, when algorithms would work with the extended=
=20
intermediate precision, but would fail if run on other platforms due to=20
accumulation of errors.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/15384951.Pf9ho5MXkc%40tjmaciei-mobl1.

.

------=_Part_24953_2110069976.1522817451418
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Hyman: My intention was that the library function would be an indication t=
o the compiler that the extended precision has to be truncated. Otherwise i=
t would only be a nop. Implementation could be a few assembly instructions =
or, better, integrated into the compiler to affect code generation to achie=
ve the desired result. On architectures without extra precision it would be=
 correct for it to be a nop though.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6eb497fe-8297-48b0-9ee9-112b6ce94580%40isocpp.or=
g.

------=_Part_24953_2110069976.1522817451418--

.

------=_Part_26024_200480721.1522835699379
Content-Type: multipart/alternative;
 boundary="----=_Part_26025_2110787459.1522835699379"

------=_Part_26025_2110787459.1522835699379
Content-Type: text/plain; charset="UTF-8"

You are using the wrong tool for that purpose.

Every current compiler is able to support the full IEEE754 compliance if
told so (even the greatest evil optimizationist compiler ever: icc).
If you want the compiler to generate loads and stores between floating
point operations on x87, gcc has -ffloat-store which will do exactly what
you want without the overhead of volatile.
But according to gcc, if you don't have SSE, it's near to impossible to
have bit correct results for that (double rounding issue):
https://gcc.gnu.org/wiki/FloatingPointMath#Note_on_x86_and_m68080_floating-point_math
Please note that even if you use volatile, you can run into the double
rounding issue.

But now, we can safely assume your hardware supports SSE, so -mfpmath=sse
-msse2 will do the trick (for x86_64, it is the default, and is not
needed). And then, you are good: you can write bit accurate floating point
code that will give the exact same results on every single architecture (as
long as it is IEEE754 compliant).

So no and no, volatile is neither needed for this, nor giving you the right
answer.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86233b28-199d-462d-b105-81aa3184895b%40isocpp.org.

------=_Part_26025_2110787459.1522835699379
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You are using the wrong tool for that purpose.<br><br>Ever=
y current compiler is able to support the full IEEE754 compliance if told s=
o (even the greatest evil optimizationist compiler ever: icc).<br>If you wa=
nt the compiler to generate loads and stores between floating point operati=
ons on x87, gcc has <span style=3D"font-family: courier new, monospace;">-f=
float-store</span> which will do exactly what you want without the overhead=
 of <span style=3D"font-family: courier new, monospace;">volatile</span>.<b=
r>But according to gcc, if you don&#39;t have SSE, it&#39;s near to impossi=
ble to have bit correct results for that (double rounding issue): https://g=
cc.gnu.org/wiki/FloatingPointMath#Note_on_x86_and_m68080_floating-point_mat=
h<br>Please note that even if you use <span style=3D"font-family: courier n=
ew, monospace;">volatile</span>, you can run into the double rounding issue=
..<br><br>But now, we can safely assume your hardware supports SSE, so <span=
 style=3D"font-family: courier new, monospace;">-mfpmath=3Dsse -msse2</span=
> will do the trick (for x86_64, it is the default, and is not needed). And=
 then, you are good: you can write bit accurate floating point code that wi=
ll give the exact same results on every single architecture (as long as it =
is IEEE754 compliant).<br><br>So no and no, <span style=3D"font-family: cou=
rier new, monospace;">volatile</span> is neither needed for this, nor givin=
g you the right answer.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/86233b28-199d-462d-b105-81aa3184895b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86233b28-199d-462d-b105-81aa3184895b=
%40isocpp.org</a>.<br />

------=_Part_26025_2110787459.1522835699379--

------=_Part_26024_200480721.1522835699379--

.

--001a1147c34c9b619e05690775f1
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 4, 2018 at 5:54 AM, <florian.csdt@gmail.com> wrote:

> You are using the wrong tool for that purpose.
>
> Every current compiler is able to support the full IEEE754 compliance if
> told so (even the greatest evil optimizationist compiler ever: icc).
> If you want the compiler to generate loads and stores between floating
> point operations on x87, gcc has -ffloat-store which will do exactly what
> you want without the overhead of volatile.
>

In a production environment, it can be significantly more difficult to
specialize
compilation flags for specific files than to modify the code not to require
such
flags.

So no and no, volatile is neither needed for this, nor giving you the right
> answer.
>

And yet, it is working as the language specifies it to work, it works just
as we expect it
to, and it gives us the answers we want.  (We have not encountered problems
due to
double rounding in our tests, but that may be accidental.  We have tested
"difficult"
numbers, such as found here: <
http://www.icir.org/vern/papers/testbase-report.pdf>)

Apparently "this is the language specification, you have to accept it" is
only good for
the features people like.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdab%3D%3DO-UTZGuQpXCXq03jGYrGai8nBzN%3DpkZOQoKKt3Kg%40mail.gmail.com.

--001a1147c34c9b619e05690775f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 4, 2018 at 5:54 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:floria=
n.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>You are using the wrong tool for that purpose.<br><br>Every current compil=
er is able to support the full IEEE754 compliance if told so (even the grea=
test evil optimizationist compiler ever: icc).<br>If you want the compiler =
to generate loads and stores between floating point operations on x87, gcc =
has <span style=3D"font-family:&quot;courier new&quot;,monospace">-ffloat-s=
tore</span> which will do exactly what you want without the overhead of <sp=
an style=3D"font-family:&quot;courier new&quot;,monospace">volatile</span>.=
<br></div></blockquote><div><br>In a production environment, it can be sign=
ificantly more difficult to specialize<br>compilation flags for specific fi=
les than to modify the code not to require such<br>flags.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">So no and no=
, <span style=3D"font-family:&quot;courier new&quot;,monospace">volatile</s=
pan> is neither needed for this, nor giving you the right answer.</div></bl=
ockquote><div><br>And yet, it is working as the language specifies it to wo=
rk, it works just as we expect it<br>to, and it gives us the answers we wan=
t.=C2=A0 (We have not encountered problems due to<br>double rounding in our=
 tests, but that may be accidental.=C2=A0 We have tested &quot;difficult&qu=
ot;<br>numbers, such as found here: &lt;<a href=3D"http://www.icir.org/vern=
/papers/testbase-report.pdf">http://www.icir.org/vern/papers/testbase-repor=
t.pdf</a>&gt;)<br><br>Apparently &quot;this is the language specification, =
you have to accept it&quot; is only good for<br>the features people like.</=
div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdab%3D%3DO-UTZGuQpXCXq03jGYrGai=
8nBzN%3DpkZOQoKKt3Kg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdab%3=
D%3DO-UTZGuQpXCXq03jGYrGai8nBzN%3DpkZOQoKKt3Kg%40mail.gmail.com</a>.<br />

--001a1147c34c9b619e05690775f1--

.

------=_Part_1554_883100891.1522879302516
Content-Type: multipart/alternative;
 boundary="----=_Part_1555_1506205690.1522879302516"

------=_Part_1555_1506205690.1522879302516
Content-Type: text/plain; charset="UTF-8"



On Wednesday, April 4, 2018 at 5:27:25 PM UTC+2, Hyman Rosen wrote:
>
> On Wed, Apr 4, 2018 at 5:54 AM, <floria...@gmail.com <javascript:>> wrote:
>
>> You are using the wrong tool for that purpose.
>>
>> Every current compiler is able to support the full IEEE754 compliance if
>> told so (even the greatest evil optimizationist compiler ever: icc).
>> If you want the compiler to generate loads and stores between floating
>> point operations on x87, gcc has -ffloat-store which will do exactly
>> what you want without the overhead of volatile.
>>
>
> In a production environment, it can be significantly more difficult to
> specialize
> compilation flags for specific files than to modify the code not to
> require such
> flags.
>
> So no and no, volatile is neither needed for this, nor giving you the
>> right answer.
>>
>
> And yet, it is working as the language specifies it to work, it works just
> as we expect it
> to, and it gives us the answers we want.  (We have not encountered
> problems due to
> double rounding in our tests, but that may be accidental.  We have tested
> "difficult"
> numbers, such as found here: <
> http://www.icir.org/vern/papers/testbase-report.pdf>)
>
> Apparently "this is the language specification, you have to accept it" is
> only good for
> the features people like.
>

One question, how many `volatile` your code use? IMHO it should be used
only in one function:
float std_precision(float f) { volatile float h = f; return h;  }
And this could be replaced by some compiler intrinsic or asm block.
This this will be more portable than trying rally on guaranties that nobody
wants to give you.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/525c1ba4-fdb3-4996-b1ac-2043aff6ec75%40isocpp.org.

------=_Part_1555_1506205690.1522879302516
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, April 4, 2018 at 5:27:25 PM UTC+2, H=
yman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Apr 4, 2018 at 5:54 AM,  <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"atYrnuzYBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">floria...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">You are using the wrong t=
ool for that purpose.<br><br>Every current compiler is able to support the =
full IEEE754 compliance if told so (even the greatest evil optimizationist =
compiler ever: icc).<br>If you want the compiler to generate loads and stor=
es between floating point operations on x87, gcc has <span style=3D"font-fa=
mily:&quot;courier new&quot;,monospace">-ffloat-store</span> which will do =
exactly what you want without the overhead of <span style=3D"font-family:&q=
uot;courier new&quot;,monospace">volatile</span>.<br></div></blockquote><di=
v><br>In a production environment, it can be significantly more difficult t=
o specialize<br>compilation flags for specific files than to modify the cod=
e not to require such<br>flags.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">So no and no, <span style=3D"font-fami=
ly:&quot;courier new&quot;,monospace">volatile</span> is neither needed for=
 this, nor giving you the right answer.</div></blockquote><div><br>And yet,=
 it is working as the language specifies it to work, it works just as we ex=
pect it<br>to, and it gives us the answers we want.=C2=A0 (We have not enco=
untered problems due to<br>double rounding in our tests, but that may be ac=
cidental.=C2=A0 We have tested &quot;difficult&quot;<br>numbers, such as fo=
und here: &lt;<a href=3D"http://www.icir.org/vern/papers/testbase-report.pd=
f" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fwww.icir.org%2Fvern%2Fpapers%2Ftestb=
ase-report.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuPogVrZwBQniL5xN0pV=
409JZA_A&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwww.icir.org%2Fvern%2Fpapers%2Ftestbase-report.pdf=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuPogVrZwBQniL5xN0pV409JZA_A&#39;;=
return true;">http://www.icir.org/vern/<wbr>papers/testbase-report.pdf</a>&=
gt;)<br><br>Apparently &quot;this is the language specification, you have t=
o accept it&quot; is only good for<br>the features people like.</div></div>=
</div></div></blockquote><div><br>One question, how many `volatile` your co=
de use? IMHO it should be used only in one function:<br><div style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pretty=
print"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> std_precision</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">volatile</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> h </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> h</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div>And this could be replaced by some compiler intrinsic or asm block.<br=
>This this will be more portable than trying rally on guaranties that nobod=
y wants to give you. </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/525c1ba4-fdb3-4996-b1ac-2043aff6ec75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/525c1ba4-fdb3-4996-b1ac-2043aff6ec75=
%40isocpp.org</a>.<br />

------=_Part_1555_1506205690.1522879302516--

------=_Part_1554_883100891.1522879302516--

.

--f4f5e80a1b144b452505690de5c5
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 4, 2018 at 6:01 PM, <inkwizytoryankes@gmail.com> wrote:
>
> One question, how many `volatile` your code use? IMHO it should be used
> only in one function:
> float std_precision(float f) { volatile float h = f; return h;  }
> And this could be replaced by some compiler intrinsic or asm block.
>

I just declare variables to be volatile when I need the precision guarantee,
and comment those cases.  They are relatively rare.


> This this will be more portable than trying rally on guaranties that
> nobody wants to give you.
>

The guarantees are given to me by the standards.  I understand that there
are
people (optimizationists, I assume) who want to take them away, but they are
still there.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbVpU1CHvRdtFkQJQVKD4JHAb2n%3D0gndUsndQ_r0bHSCQ%40mail.gmail.com.

--f4f5e80a1b144b452505690de5c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 4, 2018 at 6:01 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwiz=
ytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;<=
/span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>One quest=
ion, how many `volatile` your code use? IMHO it should be used only in one =
function:<br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px" class=3D"m_11035813732=
71853563prettyprint"><code class=3D"m_1103581373271853563prettyprint"><div =
class=3D"m_1103581373271853563subprettyprint"><span style=3D"color:#008" cl=
ass=3D"m_1103581373271853563styled-by-prettify">float</span><span style=3D"=
color:#000" class=3D"m_1103581373271853563styled-by-prettify"> std_precisio=
n</span><span style=3D"color:#660" class=3D"m_1103581373271853563styled-by-=
prettify">(</span><span style=3D"color:#008" class=3D"m_1103581373271853563=
styled-by-prettify">float</span><span style=3D"color:#000" class=3D"m_11035=
81373271853563styled-by-prettify"> f</span><span style=3D"color:#660" class=
=3D"m_1103581373271853563styled-by-prettify">)</span><span style=3D"color:#=
000" class=3D"m_1103581373271853563styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_1103581373271853563styled-by-prettify">{</span><=
span style=3D"color:#000" class=3D"m_1103581373271853563styled-by-prettify"=
> </span><span style=3D"color:#008" class=3D"m_1103581373271853563styled-by=
-prettify">volatile</span><span style=3D"color:#000" class=3D"m_11035813732=
71853563styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_1=
103581373271853563styled-by-prettify">float</span><span style=3D"color:#000=
" class=3D"m_1103581373271853563styled-by-prettify"> h </span><span style=
=3D"color:#660" class=3D"m_1103581373271853563styled-by-prettify">=3D</span=
><span style=3D"color:#000" class=3D"m_1103581373271853563styled-by-prettif=
y"> f</span><span style=3D"color:#660" class=3D"m_1103581373271853563styled=
-by-prettify">;</span><span style=3D"color:#000" class=3D"m_110358137327185=
3563styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_11035=
81373271853563styled-by-prettify">return</span><span style=3D"color:#000" c=
lass=3D"m_1103581373271853563styled-by-prettify"> h</span><span style=3D"co=
lor:#660" class=3D"m_1103581373271853563styled-by-prettify">;</span><span s=
tyle=3D"color:#000" class=3D"m_1103581373271853563styled-by-prettify"> =C2=
=A0</span><span style=3D"color:#660" class=3D"m_1103581373271853563styled-b=
y-prettify">}</span><span style=3D"color:#000" class=3D"m_11035813732718535=
63styled-by-prettify"><br></span></div></code></div>And this could be repla=
ced by some compiler intrinsic or asm block.<br></div></div></blockquote><d=
iv><br>I just declare variables to be volatile when I need the precision gu=
arantee,<br>and comment those cases.=C2=A0 They are relatively rare.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This this wil=
l be more portable than trying rally on guaranties that nobody wants to giv=
e you.</div></div></blockquote><div><br>The guarantees are given to me by t=
he standards.=C2=A0 I understand that there are<br>people (optimizationists=
, I assume) who want to take them away, but they are<br>still there.</div><=
/div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbVpU1CHvRdtFkQJQVKD4JHAb2n%3D0=
gndUsndQ_r0bHSCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbVpU1CHv=
RdtFkQJQVKD4JHAb2n%3D0gndUsndQ_r0bHSCQ%40mail.gmail.com</a>.<br />

--f4f5e80a1b144b452505690de5c5--

.

On Wednesday, 4 April 2018 16:07:45 PDT Hyman Rosen wrote:
> > One question, how many `volatile` your code use? IMHO it should be used
> > only in one function:
> > float std_precision(float f) { volatile float h = f; return h;  }
> > And this could be replaced by some compiler intrinsic or asm block.
>
> I just declare variables to be volatile when I need the precision guarantee,
> and comment those cases.  They are relatively rare.

You may want to apply the suggestion, if nothing else to centralise an #ifdef
for 387 and m68k math. Otherwise, you're incurring a high latency memory spill
compared to register-only.

> The guarantees are given to me by the standards.  I understand that there
> are
> people (optimizationists, I assume) who want to take them away, but they are
> still there.

No one is asking to take this one away. What we're suggesting is that there
may be better ways to do this by eventually shifting the requirement to the
compiler.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2814602.YRCL0oQ9OI%40tjmaciei-mobl1.

.

--001a1149892827b921056913744d
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 4, 2018 at 7:30 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
> Otherwise, you're incurring a high latency memory spill compared to
> register-only.
>

Most of this stuff is in tiny components of huge systems.  I would be
astonished if
it was on anyone's critical path.  And we deal with strings, vectors, maps,
not to
mention networking, xml and json encoding, and complex financial
calculations.
Code is reading and writing memory all the time.  One more variable isn't
going
to get super-optimized treatment unless it's a proven bottleneck.

When conversion to decimal floating-point actually was a bottleneck, we came
up with the proverbial better algorithm that improved performance for a
restricted
range of values that happened to cover most of the important use cases.

No one is asking to take this one away. What we're suggesting is that there
> may be better ways to do this by eventually shifting the requirement to the
> compiler.


The compiler already has this requirement.  It has chosen to ignore it.
According
to the standard, casting to a floating-point type or assigning to a
floating-point
variable must do the downscaling.  Gcc does not to do that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZo_0uOhwyiaRciuJ6Fk1Zx5nL0wFu97PohcqHy3keVyw%40mail.gmail.com.

--001a1149892827b921056913744d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 4, 2018 at 7:30 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Otherwise, you&#39;re incurr=
ing a high latency memory spill compared to register-only.<br></blockquote>=
<div><br>Most of this stuff is in tiny components of huge systems.=C2=A0 I =
would be astonished if<br>it was on anyone&#39;s critical path.=C2=A0 And w=
e deal with strings, vectors, maps, not to<br>mention networking, xml and j=
son encoding, and complex financial calculations.<br>Code is reading and wr=
iting memory all the time.=C2=A0 One more variable isn&#39;t going<br>to ge=
t super-optimized treatment unless it&#39;s a proven bottleneck.<br><br>Whe=
n conversion to decimal floating-point actually was a bottleneck, we came<b=
r>up with the proverbial better algorithm that improved performance for a r=
estricted<br>range of values that happened to cover most of the important u=
se cases.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No one is asking to t=
ake this one away. What we&#39;re suggesting is that there<br>
may be better ways to do this by eventually shifting the requirement to the=
<br>
compiler.</blockquote><div><br>The compiler already has this requirement.=
=C2=A0 It has chosen to ignore it.=C2=A0 According<br>to the standard, cast=
ing to a floating-point type or assigning to a floating-point<br>variable m=
ust do the downscaling.=C2=A0 Gcc does not to do that.</div></div></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZo_0uOhwyiaRciuJ6Fk1Zx5nL0wFu9=
7PohcqHy3keVyw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZo_0uOhwyi=
aRciuJ6Fk1Zx5nL0wFu97PohcqHy3keVyw%40mail.gmail.com</a>.<br />

--001a1149892827b921056913744d--

.

------=_Part_3725_527954684.1522921263059
Content-Type: multipart/alternative;
 boundary="----=_Part_3726_2048999583.1522921263060"

------=_Part_3726_2048999583.1522921263060
Content-Type: text/plain; charset="UTF-8"



> The compiler already has this requirement.  It has chosen to ignore it.
> According
> to the standard, casting to a floating-point type or assigning to a
> floating-point
> variable must do the downscaling.  Gcc does not to do that.
>

Actually, GCC does... for non-x87 targets...
The most frustrating and simple I have (requires C++11 or newer) is:
float square(float x) {
  return std::pow(x, 2);
}

This is fully optimized by GCC, but the output is: converts x to double,
multiply it by itself, and converts back to float.
So here, in this case, GCC does respect the requirements (int cannot be
promoted to float, but can be promoted to double, so the standard requires
here that both get promoted to double).
And if you use this inside a big chain of computation using only floats, I
can assure you that the double conversion is kept.

I think your main problem is: x87 is not maintained anymore. (and also: x87
is crap compared to what we have now, but this has nothing to do with the
compiler)
That's why your best bet here would be to use SSE2 when targeting x86
32bits. Doing that, you will have full IEEE754 compliance you need (and
will most likely be faster). And I really doubt you still need to target
machines with x87 and without SSE2.

Just to clarify, I'm *not* saying we should remove volatile, but just that
you have a volatile-based hack that appears to work, while there are proper
solutions to your problem (in that case).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ba7a320-f7e2-43bf-8dcf-97c669d9a599%40isocpp.org.

------=_Part_3726_2048999583.1522921263060
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>The compiler already has this=
 requirement.=C2=A0 It has chosen to ignore it.=C2=A0 According<br>to the s=
tandard, casting to a floating-point type or assigning to a floating-point<=
br>variable must do the downscaling.=C2=A0 Gcc does not to do that.</div></=
div></div></div></blockquote><div><br></div><div>Actually, GCC does... for =
non-x87 targets...</div><div>The most frustrating and simple I have (requir=
es C++11 or newer) is:</div><div><div style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> square</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">pow</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span></div></code></div></div><div><br></div><=
div>This is fully optimized by GCC, but the output is: converts <span style=
=3D"font-family: courier new, monospace;">x</span> to <span style=3D"font-f=
amily: courier new, monospace;">double</span>, multiply it by itself, and c=
onverts back to <span style=3D"font-family: courier new, monospace;">float<=
/span>.</div><div>So here, in this case, GCC does respect the requirements =
(<span style=3D"font-family: courier new, monospace;">int</span> cannot be =
promoted to <span style=3D"font-family: courier new, monospace;">float</spa=
n>, but can be promoted to <span style=3D"font-family: courier new, monospa=
ce;">double</span>, so the standard requires here that both get promoted to=
 <span style=3D"font-family: courier new, monospace;">double</span>).<br></=
div><div>And if you use this inside a big chain of computation using only f=
loats, I can assure you that the double conversion is kept.<br></div><div><=
br></div><div>I think your main problem is: x87 is not maintained anymore. =
(and also: x87 is crap compared to what we have now, but this has nothing t=
o do with the compiler)<br></div><div>That&#39;s why your best bet here wou=
ld be to use SSE2 when targeting x86 32bits. Doing that, you will have full=
 IEEE754 compliance you need (and will most likely be faster). And I really=
 doubt you still need to target machines with x87 and without SSE2.<br></di=
v><div><br></div><div>Just to clarify, I&#39;m <i>not</i> saying we should =
remove <span style=3D"font-family: courier new, monospace;">volatile</span>=
, but just that you have a <span style=3D"font-family: courier new, monospa=
ce;">volatile</span>-based hack that appears to work, while there are prope=
r solutions to your problem (in that case).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ba7a320-f7e2-43bf-8dcf-97c669d9a599%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ba7a320-f7e2-43bf-8dcf-97c669d9a599=
%40isocpp.org</a>.<br />

------=_Part_3726_2048999583.1522921263060--

------=_Part_3725_527954684.1522921263059--

.

--001a114798d236346a05691aa04f
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 5, 2018 at 5:41 AM, <florian.csdt@gmail.com> wrote:

>
> The compiler already has this requirement.  It has chosen to ignore it.
>> According
>> to the standard, casting to a floating-point type or assigning to a
>> floating-point
>> variable must do the downscaling.  Gcc does not to do that.
>>
>
> Actually, GCC does... for non-x87 targets...
>
> This is the source of this entire discussion, I guess?
https://gcc.gnu.org/wiki/x87note

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxft5x78q4Cx2AiX6_7NzvFsqgM56TZP_LVkQwSskYyyvFg%40mail.gmail.com.

--001a114798d236346a05691aa04f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Apr 5, 2018 at 5:41 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:floria=
n.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><span class=3D"gmail-"><br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The compiler alrea=
dy has this requirement.=C2=A0 It has chosen to ignore it.=C2=A0 According<=
br>to the standard, casting to a floating-point type or assigning to a floa=
ting-point<br>variable must do the downscaling.=C2=A0 Gcc does not to do th=
at.</div></div></div></div></blockquote><div><br></div></span><div>Actually=
, GCC does... for non-x87 targets...</div><div><br></div></div></blockquote=
><div>This is the source of this entire discussion, I guess?<br><a href=3D"=
https://gcc.gnu.org/wiki/x87note">https://gcc.gnu.org/wiki/x87note</a></div=
><div>=C2=A0</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALEPxft5x78q4Cx2AiX6_7NzvFsqgM56TZP_=
LVkQwSskYyyvFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxft5x78q4Cx2=
AiX6_7NzvFsqgM56TZP_LVkQwSskYyyvFg%40mail.gmail.com</a>.<br />

--001a114798d236346a05691aa04f--

.

------=_Part_4596_164486917.1522940256829
Content-Type: multipart/alternative;
 boundary="----=_Part_4597_1773326835.1522940256829"

------=_Part_4597_1773326835.1522940256829
Content-Type: text/plain; charset="UTF-8"



> This is the source of this entire discussion, I guess?
> https://gcc.gnu.org/wiki/x87note
>
>
Well, yes...

My point is: Hyman's problem is (apparently?) only for x87 targets.
However, GCC devs don't maintain x87 anymore (this part of the
documentation is very old, and contradicts itself here and there).
So everything he said is basically right, but only for an old, deprecated
(and buggy) architecture.
But for other still maintained architectures, nothing he said holds.
Currently, compilers do respect floating constraints (by default on GCC,
with compiler flags on ICC).

While I'm pretty it is still relatively easy to find places where old x86
(32 bits) machines not supporting SSE4 are needed, I doubt those are old
enough to not support SSE2.
Thus, I think the proper fix is to compile with SSE support, not (ab)using
volatile.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f104748a-ab24-4e6a-acd7-39e7c61f1b3c%40isocpp.org.

------=_Part_4597_1773326835.1522940256829
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>This is the source of this en=
tire discussion, I guess?<br><a href=3D"https://gcc.gnu.org/wiki/x87note" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fwiki%2Fx87note\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFyc-9BIIjPnpjXXlQbnXyV3Dt-JA&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fgcc.gnu.org%2Fwiki%2Fx87note\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFyc=
-9BIIjPnpjXXlQbnXyV3Dt-JA&#39;;return true;">https://gcc.gnu.org/wiki/<wbr>=
x87note</a></div><div>=C2=A0</div></div></div></div></blockquote><div>Well,=
 yes...</div><div><br></div><div>My point is: Hyman&#39;s problem is (appar=
ently?) only for x87 targets.</div><div>However, GCC devs don&#39;t maintai=
n x87 anymore (this part of the documentation is very old, and contradicts =
itself here and there).</div><div>So everything he said is basically right,=
 but only for an old, deprecated (and buggy) architecture.</div><div>But fo=
r other still maintained architectures, nothing he said holds.</div><div>Cu=
rrently, compilers do respect floating constraints (by default on GCC, with=
 compiler flags on ICC).<br></div><div><br></div><div>While I&#39;m pretty =
it is still relatively easy to find places where old x86 (32 bits) machines=
 not supporting SSE4 are needed, I doubt those are old enough to not suppor=
t SSE2.</div><div>Thus, I think the proper fix is to compile with SSE suppo=
rt, not (ab)using <span style=3D"font-family: courier new, monospace;">vola=
tile</span>.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f104748a-ab24-4e6a-acd7-39e7c61f1b3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f104748a-ab24-4e6a-acd7-39e7c61f1b3c=
%40isocpp.org</a>.<br />

------=_Part_4597_1773326835.1522940256829--

------=_Part_4596_164486917.1522940256829--

.

--001a1147c34c56a3e905691be79b
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 5, 2018 at 5:41 AM, <florian.csdt@gmail.com> wrote:
>
> The compiler already has this requirement.  It has chosen to ignore it.
>> According
>> to the standard, casting to a floating-point type or assigning to a
>> floating-point
>> variable must do the downscaling.  Gcc does not to do that.
>>
>
> Actually, GCC does... for non-x87 targets...
>

We have legacy systems and legacy compilers, and we still build for x87.
The errors I have dealt with were reported from the field.  And as I said,
it
is easy for me to make changes in the code, but much more difficult to make
changes in the build environment.

The most frustrating and simple I have (requires C++11 or newer) is:
> float square(float x) {
>   return std::pow(x, 2);
> }
>
> This is fully optimized by GCC, but the output is: converts x to double,
> multiply it by itself, and converts back to float.
> So here, in this case, GCC does respect the requirements (int cannot be
> promoted to float, but can be promoted to double, so the standard
> requires here that both get promoted to double).
> And if you use this inside a big chain of computation using only floats, I
> can assure you that the double conversion is kept.
>

I don't understand how this applies to my problem.  But I adapted your code:

#include <cmath>
#include <cstdio>
#include <iostream>
#include <iomanip>

using std::pow;

void a(const char *a, const char *b)
{
    float f;
    int   n;
    sscanf(a, "%f", &f);
    sscanf(b, "%d", &n);
    float g = f;
    float p = std::pow(f, n);
    g += p;
    std::cout << std::setprecision(17) << g << "\n";
}

void b(const char *a, const char *b)
{
    float f;
    int   n;
    sscanf(a, "%f", &f);
    sscanf(b, "%d", &n);
    volatile float g = f;
    volatile float p = std::pow(f, n);
    g += p;
    std::cout << std::setprecision(17) << g << "\n";
}

int main(int c, char **v)
{
    if (c > 2) {
        a(v[1], v[2]);
        b(v[1], v[2]);
    }
}

I compiled it with a version 7.3 g++, using g++ -std=c++17 -mfpmath=387 -O1.
When run with the command line arguments .1 and 2, it produces
0.11000000219792128
0.10999999940395355

I think your main problem is: x87 is not maintained anymore.
>

My main problem, as illustrated by the code above, is that g++ disobeys the
standard when doing floating-point arithmetic.

That's why your best bet here would be to use SSE2 when targeting x86
> 32bits. Doing that, you will have full IEEE754 compliance you need (and
> will most likely be faster). And I really doubt you still need to target
> machines with x87 and without SSE2.
>

I do not control my company's build environment, and we do build in x87
mode.
Perhaps at some point we won't, but that day hasn't arrived yet.

Just to clarify, I'm *not* saying we should remove volatile, but just that
> you have
>
a volatile-based hack that appears to work, while there are proper
> solutions to
>
your problem (in that case).
>

Notice how optimizationism poisons everything.  Not only does the standard
make
poor choices that privilege potential efficiency over code clarity and
consistency, but
even when the standard makes the correct choice, that choice is ignored in
order to
again privilege that potential efficiency.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbfioM3dZvookSaZbwVdbxoySuT%3DEEnKFB6-JaL9LGySg%40mail.gmail.com.

--001a1147c34c56a3e905691be79b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Apr 5, 2018 at 5:41 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:floria=
n.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>&gt;</span> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The compiler already has t=
his requirement.=C2=A0 It has chosen to ignore it.=C2=A0 According<br>to th=
e standard, casting to a floating-point type or assigning to a floating-poi=
nt<br>variable must do the downscaling.=C2=A0 Gcc does not to do that.</div=
></div></div></div></blockquote><div><br></div></span><div>Actually, GCC do=
es... for non-x87 targets...</div></div></blockquote><div><br>We have legac=
y systems and legacy compilers, and we still build for x87.<br>The errors I=
 have dealt with were reported from the field.=C2=A0 And as I said, it<br>i=
s easy for me to make changes in the code, but much more difficult to make<=
br>changes in the build environment.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>The most frustrating and sim=
ple I have (requires C++11 or newer) is:</div><div><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px" class=3D"gmail-m_-6846581893248705262prettyprint"><code cla=
ss=3D"gmail-m_-6846581893248705262prettyprint"><div class=3D"gmail-m_-68465=
81893248705262subprettyprint"><span style=3D"color:rgb(0,0,136)" class=3D"g=
mail-m_-6846581893248705262styled-by-prettify">float</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-6846581893248705262styled-by-prettify"> =
square</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6846581=
893248705262styled-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" =
class=3D"gmail-m_-6846581893248705262styled-by-prettify">float</span><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6846581893248705262styled-by-p=
rettify"> x</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-68=
46581893248705262styled-by-prettify">)</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-6846581893248705262styled-by-prettify"> </span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6846581893248705262styled-b=
y-prettify">{</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6846=
581893248705262styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:r=
gb(0,0,136)" class=3D"gmail-m_-6846581893248705262styled-by-prettify">retur=
n</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6846581893248705=
262styled-by-prettify"> std</span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-6846581893248705262styled-by-prettify">::</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6846581893248705262styled-by-pretti=
fy">pow</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-684658=
1893248705262styled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_-6846581893248705262styled-by-prettify">x</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6846581893248705262styled-by-pr=
ettify">,</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-68465818=
93248705262styled-by-prettify"> </span><span style=3D"color:rgb(0,102,102)"=
 class=3D"gmail-m_-6846581893248705262styled-by-prettify">2</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6846581893248705262styled-by-=
prettify">);</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-68465=
81893248705262styled-by-prettify"><br></span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-6846581893248705262styled-by-prettify">}</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6846581893248705262styled-b=
y-prettify"> </span></div></code></div></div><div><br></div><div>This is fu=
lly optimized by GCC, but the output is: converts <span style=3D"font-famil=
y:&quot;courier new&quot;,monospace">x</span> to <span style=3D"font-family=
:&quot;courier new&quot;,monospace">double</span>, multiply it by itself, a=
nd converts back to <span style=3D"font-family:&quot;courier new&quot;,mono=
space">float</span>.</div><div>So here, in this case, GCC does respect the =
requirements (<span style=3D"font-family:&quot;courier new&quot;,monospace"=
>int</span> cannot be promoted to <span style=3D"font-family:&quot;courier =
new&quot;,monospace">float</span>, but can be promoted to <span style=3D"fo=
nt-family:&quot;courier new&quot;,monospace">double</span>, so the standard=
 requires here that both get promoted to <span style=3D"font-family:&quot;c=
ourier new&quot;,monospace">double</span>).<br></div><div>And if you use th=
is inside a big chain of computation using only floats, I can assure you th=
at the double conversion is kept.<br></div></div></blockquote><div><br>I do=
n&#39;t understand how this applies to my problem.=C2=A0 But I adapted your=
 code:<br><br></div></div></div><span style=3D"font-family:monospace,monosp=
ace">#include &lt;cmath&gt;</span><br><span style=3D"font-family:monospace,=
monospace">#include &lt;cstdio&gt;</span><br><span style=3D"font-family:mon=
ospace,monospace">#include &lt;iostream&gt;</span><br><span style=3D"font-f=
amily:monospace,monospace">#include &lt;iomanip&gt;</span><br><font face=3D=
"monospace, monospace"><br></font><span style=3D"font-family:monospace,mono=
space">using std::pow;</span><br><font face=3D"monospace, monospace"><br></=
font><span style=3D"font-family:monospace,monospace">void a(const char *a, =
const char *b)</span><br><span style=3D"font-family:monospace,monospace">{<=
/span><br><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 flo=
at f;</span><br><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=
=A0 int=C2=A0 =C2=A0n;</span><br><span style=3D"font-family:monospace,monos=
pace">=C2=A0 =C2=A0 sscanf(a, &quot;%f&quot;, &amp;f);</span><br><span styl=
e=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 sscanf(b, &quot;%d&quot=
;, &amp;n);</span><br><span style=3D"font-family:monospace,monospace">=C2=
=A0 =C2=A0 float g =3D f;</span><br><span style=3D"font-family:monospace,mo=
nospace">=C2=A0 =C2=A0 float p =3D std::pow(f, n);</span><br><span style=3D=
"font-family:monospace,monospace">=C2=A0 =C2=A0 g +=3D p;</span><br><span s=
tyle=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 std::cout &lt;&lt; s=
td::setprecision(17) &lt;&lt; g &lt;&lt; &quot;\n&quot;;</span><br><span st=
yle=3D"font-family:monospace,monospace">}</span><br><font face=3D"monospace=
, monospace"><br></font><span style=3D"font-family:monospace,monospace">voi=
d b(const char *a, const char *b)</span><br><span style=3D"font-family:mono=
space,monospace">{</span><br><span style=3D"font-family:monospace,monospace=
">=C2=A0 =C2=A0 float f;</span><br><span style=3D"font-family:monospace,mon=
ospace">=C2=A0 =C2=A0 int=C2=A0 =C2=A0n;</span><br><span style=3D"font-fami=
ly:monospace,monospace">=C2=A0 =C2=A0 sscanf(a, &quot;%f&quot;, &amp;f);</s=
pan><br><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 sscan=
f(b, &quot;%d&quot;, &amp;n);</span><br><span style=3D"font-family:monospac=
e,monospace">=C2=A0 =C2=A0 volatile float g =3D f;</span><br><span style=3D=
"font-family:monospace,monospace">=C2=A0 =C2=A0 volatile float p =3D std::p=
ow(f, n);</span><br><span style=3D"font-family:monospace,monospace">=C2=A0 =
=C2=A0 g +=3D p;</span><br><span style=3D"font-family:monospace,monospace">=
=C2=A0 =C2=A0 std::cout &lt;&lt; std::setprecision(17) &lt;&lt; g &lt;&lt; =
&quot;\n&quot;;</span><br><span style=3D"font-family:monospace,monospace">}=
</span><br><font face=3D"monospace, monospace"><br></font><span style=3D"fo=
nt-family:monospace,monospace">int main(int c, char **v)</span><br><span st=
yle=3D"font-family:monospace,monospace">{</span><br><span style=3D"font-fam=
ily:monospace,monospace">=C2=A0 =C2=A0 if (c &gt; 2) {</span><br><span styl=
e=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 a(v[1], v=
[2]);</span><br><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 b(v[1], v[2]);</span><br><span style=3D"font-family:monos=
pace,monospace">=C2=A0 =C2=A0 }</span><br><font face=3D"monospace, monospac=
e">}</font><br><br><font face=3D"arial, helvetica, sans-serif">I compiled i=
t with a version 7.3 g++, using </font><font face=3D"monospace, monospace">=
g++ -std=3Dc++17 -mfpmath=3D387 -O1</font><font face=3D"arial, helvetica, s=
ans-serif">.<br>When run with the command line arguments </font><font face=
=3D"monospace, monospace">.1</font><font face=3D"arial, helvetica, sans-ser=
if"> and </font><font face=3D"monospace, monospace">2</font><font face=3D"a=
rial, helvetica, sans-serif">, it produces</font><br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div><div><font face=3D"monospace, monospac=
e">0.11000000219792128</font></div><div><font face=3D"monospace, monospace"=
>0.10999999940395355<br><br></font></div></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>I think your main problem is: x=
87 is not maintained anymore.</div></div></blockquote><div><br>My main prob=
lem, as illustrated by the code above, is that g++ disobeys the<br>standard=
 when doing floating-point arithmetic.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div>That&#39;s why your best b=
et here would be to use SSE2 when targeting x86 32bits. Doing that, you wil=
l have full IEEE754 compliance you need (and will most likely be faster). A=
nd I really doubt you still need to target machines with x87 and without SS=
E2.<br></div></div></blockquote><div><br>I do not control my company&#39;s =
build environment, and we do build in x87 mode.<br>Perhaps at some point we=
 won&#39;t, but that day hasn&#39;t arrived yet.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Just to clarify,=
 I&#39;m <i>not</i> saying we should remove <span style=3D"font-family:&quo=
t;courier new&quot;,monospace">volatile</span>, but just that you have</div=
></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>a <span style=3D"font-family:&quot;courier new&quot;,monos=
pace">volatile</span>-based hack that appears to work, while there are prop=
er solutions to</div></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>your problem (in that case).</div></di=
v></blockquote><div><br>Notice how optimizationism poisons everything.=C2=
=A0 Not only does the standard make<br>poor choices that privilege potentia=
l efficiency over code clarity and consistency, but<br>even when the standa=
rd makes the correct choice, that choice is ignored in order to<br>again pr=
ivilege that potential efficiency.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbfioM3dZvookSaZbwVdbxoySuT%3DE=
EnKFB6-JaL9LGySg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbfioM3dZ=
vookSaZbwVdbxoySuT%3DEEnKFB6-JaL9LGySg%40mail.gmail.com</a>.<br />

--001a1147c34c56a3e905691be79b--

.

--001a114446fab9077205691c0cc9
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 5, 2018 at 10:57 AM, <florian.csdt@gmail.com> wrote:
>
> So everything he said is basically right, but only for an old, deprecated
> (and buggy) architecture.
>

You compute on the architecture you have, not on the architecture you want.
There isn't anything about the x87 architecture that precludes g++ from
doing
the right thing, given that using volatile in fact does the right thing.
The authors
of g++ deliberately chose to do the wrong thing for the sake of
optimizationism;
they preferred to produce the incorrect, non-standard-complying result
because
they could do that faster than producing the correct, standard-complying
result.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbsudKrW4yTv8CBE1Rf5%3D0a8Gd3-t5hvFF-L9jKWqm2sg%40mail.gmail.com.

--001a114446fab9077205691c0cc9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Apr 5, 2018 at 10:57 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:flori=
an.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>&gt;</span> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So everything he=
 said is basically right, but only for an old, deprecated (and buggy) archi=
tecture.</div></div></blockquote><div><br>You compute on the architecture y=
ou have, not on the architecture you want.<br>There isn&#39;t anything abou=
t the x87 architecture that precludes g++ from doing<br>the right thing, gi=
ven that using volatile in fact does the right thing.=C2=A0 The authors<br>=
of g++ deliberately chose to do the wrong thing for the sake of optimizatio=
nism;<br>they preferred to produce the incorrect, non-standard-complying re=
sult because<br>they could do that faster than producing the correct,=C2=A0=
s<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:=
small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">tandard-complying result.</span></div></div></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbsudKrW4yTv8CBE1Rf5%3D0a8Gd3-t=
5hvFF-L9jKWqm2sg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbsudKrW4=
yTv8CBE1Rf5%3D0a8Gd3-t5hvFF-L9jKWqm2sg%40mail.gmail.com</a>.<br />

--001a114446fab9077205691c0cc9--

.

------=_Part_4850_1604193329.1522945658904
Content-Type: multipart/alternative;
 boundary="----=_Part_4851_1784684717.1522945658904"

------=_Part_4851_1784684717.1522945658904
Content-Type: text/plain; charset="UTF-8"



>
> The most frustrating and simple I have (requires C++11 or newer) is:
>> float square(float x) {
>>   return std::pow(x, 2);
>> }
>>
>> This is fully optimized by GCC, but the output is: converts x to double,
>> multiply it by itself, and converts back to float.
>> So here, in this case, GCC does respect the requirements (int cannot be
>> promoted to float, but can be promoted to double, so the standard
>> requires here that both get promoted to double).
>> And if you use this inside a big chain of computation using only floats,
>> I can assure you that the double conversion is kept.
>>
>
> I don't understand how this applies to my problem.
>

My point here is, if you do compile with SSE support this square function,
GCC does keep the double conversion, and so respects IEEE754 despite
optimizationism:

float square(float x) {
  return std::pow(x, 2);
}
gives (for x86_64):
square(float):
  cvtss2sd %xmm0, %xmm0
  mulsd %xmm0, %xmm0
  cvtsd2ss %xmm0, %xmm0
  ret

As you can see: the multiplication is done in double precision, exactly as
it should be in that very case, while a compiler that would not comply with
IEEE754 would do the multiplication in single precision.

In the same vein, but probably easier:
float dotprod(const float* A, int n) {
  float s = 0.f;
  for (int i = 0; i < n; i++) {
    s += A[i];
  }
  return s;
}
This is not vectorizable by GCC (unless you use -ffast-math) because this
would change the result.


So, GCC has the correct behavior.
But as x87 is not maintained anymore, you are using very old GCC code, and
this code was not respecting this.
They have made a choice long ago that was exactly what you describe. (Could
they do better at that point? I'm not even sure)

But what I say is: they change their mind and corrected this on newer code,
but as you use deprecated architecture, you use part of GCC that was not
fixed (and will probably never be fixed).


I think your main problem is: x87 is not maintained anymore.
>>
>
> My main problem, as illustrated by the code above, is that g++ disobeys the
> standard when doing floating-point arithmetic.
>

Because you are targeting an architecture that is not maintained anymore.
All the others are perfectly fine...
BTW, you use a buggy architecture: it is normal to encounter bugs at that
point (and yes, x87 *is* buggy on its own).


> Notice how optimizationism poisons everything.  Not only does the standard
> make
> poor choices that privilege potential efficiency over code clarity and
> consistency, but
> even when the standard makes the correct choice, that choice is ignored in
> order to
> again privilege that potential efficiency.
>

If you do it right, the compiler also does it right.
In the past, things were different. But now, compilers (especially GCC) are
really good at respecting both your code and the standard.
But if your intent is different from your code, don't be surprise that the
compiler does not give what you expect.

You compute on the architecture you have, not on the architecture you want.
> There isn't anything about the x87 architecture that precludes g++ from
> doing
> the right thing, given that using volatile in fact does the right thing.
> The authors
> of g++ deliberately chose to do the wrong thing for the sake of
> optimizationism;
> they preferred to produce the incorrect, non-standard-complying result
> because
> they could do that faster than producing the correct, standard-complying
> result.
>

Do you really still have Pentium 3 and older machines?
If GCC does not maintain x87 anymore (and thus is buggy here), it is
simple: this architecture is buggy, and not use for quite a long time now.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a4da63ed-713e-4d79-94cf-eff6738122c5%40isocpp.org.

------=_Part_4851_1784684717.1522945658904
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>The most frustrating and simple I have (=
requires C++11 or newer) is:</div><div><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px"><code><div><span style=3D"color:rgb(0,0,136)">float</span><span style=
=3D"color:rgb(0,0,0)"> square</span><span style=3D"color:rgb(102,102,0)">(<=
/span><span style=3D"color:rgb(0,0,136)">float</span><span style=3D"color:r=
gb(0,0,0)"> x</span><span style=3D"color:rgb(102,102,0)">)</span><span styl=
e=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span=
><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rg=
b(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> std</span><span =
style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">po=
w</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,0)">x</span><span style=3D"color:rgb(102,102,0)">,</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">2</span>=
<span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"=
color:rgb(0,0,0)"> </span></div></code></div></div><div><br></div><div>This=
 is fully optimized by GCC, but the output is: converts <span style=3D"font=
-family:&quot;courier new&quot;,monospace">x</span> to <span style=3D"font-=
family:&quot;courier new&quot;,monospace">double</span>, multiply it by its=
elf, and converts back to <span style=3D"font-family:&quot;courier new&quot=
;,monospace">float</span>.</div><div>So here, in this case, GCC does respec=
t the requirements (<span style=3D"font-family:&quot;courier new&quot;,mono=
space">int</span> cannot be promoted to <span style=3D"font-family:&quot;co=
urier new&quot;,monospace">float</span>, but can be promoted to <span style=
=3D"font-family:&quot;courier new&quot;,monospace">double</span>, so the st=
andard requires here that both get promoted to <span style=3D"font-family:&=
quot;courier new&quot;,monospace">double</span>).<br></div><div>And if you =
use this inside a big chain of computation using only floats, I can assure =
you that the double conversion is kept.<br></div></div></blockquote><div><b=
r>I don&#39;t understand how this applies to my problem.<br></div></div></d=
iv></div></blockquote><div><br></div><div>My point here is, if you do compi=
le with SSE support this square function, GCC does keep the double conversi=
on, and so respects IEEE754 despite optimizationism:</div><div><br></div><d=
iv><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-=
word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">float=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> square</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">po=
w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
 class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div>gives (for x86_64):</div><div><div style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pret=
typrint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">square</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">):</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 cvtss2sd </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">%</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">xmm0</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">%</span><span style=3D"color: #000;" class=3D"styled-by-prettify">xmm0<br=
>=C2=A0 mulsd </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">%</span><span style=3D"color: #000;" class=3D"styled-by-prettify">xmm0<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">%</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">xmm0<br>=C2=A0 cvtsd2ss </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">%</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">xmm0</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">%</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">xmm0<br>=C2=A0 ret<br></span></div></code></div><br></div><div>As=
 you can see: the multiplication is done in double precision, exactly as it=
 should be in that very case, while a compiler that would not comply with I=
EEE754 would do the multiplication in single precision.</div><div><br></div=
><div>In the same vein, but probably easier:</div><div><div style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> dotprod</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">float</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> s </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">0.f</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">++)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 s </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an></div></code></div>This is not vectorizable by GCC (unless you use -ffas=
t-math) because this would change the result.<br><br></div><div><br></div><=
div>So, GCC has the correct behavior.</div><div>But as x87 is not maintaine=
d anymore, you are using very old GCC code, and this code was not respectin=
g this.</div><div>They have made a choice long ago that was exactly what yo=
u describe. (Could they do better at that point? I&#39;m not even sure)<br>=
</div><div><br></div><div>But what I say is: they change their mind and cor=
rected this on newer code, but as you use deprecated architecture, you use =
part of GCC that was not fixed (and will probably never be fixed).<br></div=
><div><br></div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>I think your main problem is: x87 is =
not maintained anymore.</div></div></blockquote><div><br>My main problem, a=
s illustrated by the code above, is that g++ disobeys the<br>standard when =
doing floating-point arithmetic.<br></div></div></div></div></blockquote><d=
iv><br></div><div>Because you are targeting an architecture that is not mai=
ntained anymore. All the others are perfectly fine...</div><div>BTW, you us=
e a buggy architecture: it is normal to encounter bugs at that point (and y=
es, x87 <b>is</b> buggy on its own).<br></div><br><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><=
br>Notice how optimizationism poisons everything.=C2=A0 Not only does the s=
tandard make<br>poor choices that privilege potential efficiency over code =
clarity and consistency, but<br>even when the standard makes the correct ch=
oice, that choice is ignored in order to<br>again privilege that potential =
efficiency.</div></div></div></div></blockquote><div><br></div><div>If you =
do it right, the compiler also does it right.</div><div>In the past, things=
 were different. But now, compilers (especially GCC) are really good at res=
pecting both your code and the standard.</div><div>But if your intent is di=
fferent from your code, don&#39;t be surprise that the compiler does not gi=
ve what you expect.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;"><div>You compute on the architecture you have, n=
ot on the architecture you want.<br>There isn&#39;t anything about the x87 =
architecture that precludes g++ from doing<br>the right thing, given that u=
sing volatile in fact does the right thing.=C2=A0 The authors<br>of g++ del=
iberately chose to do the wrong thing for the sake of optimizationism;<br>t=
hey preferred to produce the incorrect, non-standard-complying result becau=
se<br>they could do that faster than producing the correct,=C2=A0s<span sty=
le=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font=
-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);float:none;display:inline">tandard-complying resul=
t.</span></div></blockquote><div><br></div><div>Do you really still have Pe=
ntium 3 and older machines?</div><div>If GCC does not maintain x87 anymore =
(and thus is buggy here), it is simple: this architecture is buggy, and not=
 use for quite a long time now.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a4da63ed-713e-4d79-94cf-eff6738122c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a4da63ed-713e-4d79-94cf-eff6738122c5=
%40isocpp.org</a>.<br />

------=_Part_4851_1784684717.1522945658904--

------=_Part_4850_1604193329.1522945658904--

.

On 04/05/2018 07:45 AM, Hyman Rosen wrote:
> The compiler already has this requirement.  It has chosen to ignore it.  According
> to the standard, casting to a floating-point type or assigning to a floating-point
> variable must do the downscaling.  Gcc does not to do that.

We have very little requirements on floating-point arithmetic in the C++ standard.

[basic.fundamental] p8 says (for example):

"[ Note: This document imposes no requirements on the accuracy of floating-point
operations; see also 21.3. -- end note ]"

What normative statement in the standard makes you believe that
"casting to a floating-point type [...] must do the downscaling"?

Jens


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5AC66322.50207%40gmx.net.

.

On Thursday, 5 April 2018 07:57:36 PDT florian.csdt@gmail.com wrote:
> While I'm pretty it is still relatively easy to find places where old x86
> (32 bits) machines not supporting SSE4 are needed, I doubt those are old
> enough to not support SSE2.

Intel has produced recent CPUs without SSE2. But they also lack 387 FPU too,
so you need software FP emulation anyway.

It's the Quark line of microcontrollers.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4839633.QWdSXA90f1%40tjmaciei-mobl1.

.

--001a114b332c07a35305691f0705
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 5, 2018 at 1:55 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>
> What normative statement in the standard makes you believe that
> "casting to a floating-point type [...] must do the downscaling"?


In N4700, [expr]/13 says

*The values of the floating operands and the results of floating
expressionsmay be represented in greater *
*precision and range than that required bythe type; the types are not
changed thereby.64*

The associated footnote says


*64) The cast and assignment operators must still perform their
specificconversions as described in 8.4, 8.2.9 and 8.18.*

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYF3mSv99Z0r68j4Ser8i7XVtbEC0M2gdKVCvOd5ugUAQ%40mail.gmail.com.

--001a114b332c07a35305691f0705
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Apr 5, 2018 at 1:55 PM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What normative statement in the standard makes you believe that<br>
&quot;casting to a floating-point type [...] must do the downscaling&quot;?=
</blockquote><div><br>In N4700, [expr]/13 says<br><i>The values of the floa=
ting operands and the results of floating expressions<br>may be represented=
 in greater=C2=A0</i><i>precision and range than that required by<br>the ty=
pe; the types are not changed thereby.<font size=3D"1"><b>64</b></font></i>=
</div><div><br>The associated footnote says<br><i><font size=3D"1"><b>64</b=
></font>) The cast and assignment operators must still perform their specif=
ic<br>conversions as described in 8.4, 8.2.9 and 8.18.<font size=3D"1"><br>=
</font></i></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYF3mSv99Z0r68j4Ser8i7XVtbEC0M2=
gdKVCvOd5ugUAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYF3mSv99Z0=
r68j4Ser8i7XVtbEC0M2gdKVCvOd5ugUAQ%40mail.gmail.com</a>.<br />

--001a114b332c07a35305691f0705--

.

On Thursday, 5 April 2018 12:34:05 PDT Hyman Rosen wrote:
> On Thu, Apr 5, 2018 at 1:55 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> > What normative statement in the standard makes you believe that
> > "casting to a floating-point type [...] must do the downscaling"?
>
> In N4700, [expr]/13 says
>
> *The values of the floating operands and the results of floating
> expressionsmay be represented in greater *
> *precision and range than that required bythe type; the types are not
> changed thereby.64*
>
> The associated footnote says
>
>
> *64) The cast and assignment operators must still perform their
> specificconversions as described in 8.4, 8.2.9 and 8.18.*

In other words:

 a = b * c + d;

is allowed to use extra precision in intermediary results, like using an FMA
hardware instruction. But

 a = b * c;
 a += d;

is not, because there was an assignment to a and the footnote says the
assignment must perform the conversion.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2883813.Kr4A9NVv0x%40tjmaciei-mobl1.

.