Topic: uint16_t data =x= static_cast<uint16_t>(1) + 1;
Author: rianquinn@gmail.com
Date: Tue, 18 Oct 2016 16:11:27 -0700 (PDT)
Raw View
------=_Part_795_67081596.1476832287209
Content-Type: multipart/alternative;
boundary="----=_Part_796_609066021.1476832287210"
------=_Part_796_609066021.1476832287210
Content-Type: text/plain; charset=UTF-8
Writing a hypervisor in C++, and at least on Intel that are a lot of things
that require 8 and 16 bit integers. To my surprise, this generates a
warning about conversions:
uint16_t data1 = 1;
uint16_t data2 = data1 + 1; // warning on possible overflow
The reason is, in C++, when you perform arithmetic, the compiler is allowed
to up-cast for you to an int if it results in a performance improvement. So
the compiler changes the result of data1 + 1 to an int, and then complains
because you could lose data if you store an int back into something
smaller, even though the programmer never intended it to be an int in the
first place. The following also fails which gets rid of the 1 which is
technically an int (although no warnings are fired when you store 1 into
something smaller.. only when you use it in arithmetic):
uint16_t data1 = 1;
uint16_t data2 = 1;
uint16_t data3 = data1 + data2; // warning on possible overflow
Now... one might think.. that warning is valid because adding 1 to anything
could result in an overflow, except that the same is not true for an int.
int data1 = 1;
int data2 = 1;
int data3 = data1 + data2; // compiles fine
Has there ever been a proposal to fix this? At least in our code, this one
fix would get rid of a LOT of gsl::narrow_casts as it seems to me the
warning is a bit overkill as the programmer's intent is valid, it's the
compiler doing wonky things.
Thanks a ton,
- Rian
--
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/47e7f79f-8676-4a63-b7d3-09d64219d575%40isocpp.org.
------=_Part_796_609066021.1476832287210
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Writing a hypervisor in C++, and at least on Intel th=
at are a lot of things that require 8 and 16 bit integers. To my surprise, =
this generates a warning about conversions:</div><div><br></div><div>uint16=
_t data1 =3D 1;</div><div>uint16_t data2 =3D data1 + 1; =C2=A0// warning on=
possible overflow<br></div><div><br></div>The reason is, in C++, when you =
perform arithmetic, the compiler is allowed to up-cast for you to an int if=
it results in a performance improvement. So the compiler changes the resul=
t of data1 + 1 to an int, and then complains because you could lose data if=
you store an int back into something smaller, even though the programmer n=
ever intended it to be an int in the first place. The following also fails =
which gets rid of the 1 which is technically an int (although no warnings a=
re fired when you store 1 into something smaller.. only when you use it in =
arithmetic):<div><br></div><div><div>uint16_t data1 =3D 1;</div><div>uint16=
_t data2 =3D 1;</div><div>uint16_t data3 =3D data1 + data2; // warning on p=
ossible overflow<br></div></div><div><div><br></div><div>Now... one might t=
hink.. that warning is valid because adding 1 to anything could result in a=
n overflow, except that the same is not true for an int.=C2=A0</div><div><b=
r></div><div>int data1 =3D 1;</div><div>int data2 =3D 1;</div><div>int data=
3 =3D data1 + data2; // compiles fine<br></div></div><div><br></div><div>Ha=
s there ever been a proposal to fix this? At least in our code, this one fi=
x would get rid of a LOT of gsl::narrow_casts as it seems to me the warning=
is a bit overkill as the programmer's intent is valid, it's the co=
mpiler doing wonky things. =C2=A0</div><div><br></div><div>Thanks a ton,</d=
iv><div>- Rian</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/47e7f79f-8676-4a63-b7d3-09d64219d575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575=
%40isocpp.org</a>.<br />
------=_Part_796_609066021.1476832287210--
------=_Part_795_67081596.1476832287209--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 18 Oct 2016 19:31:55 -0400
Raw View
--001a114e27a01801e0053f2c193a
Content-Type: text/plain; charset=UTF-8
Isn't this a QOI issue, not a standard one?
On Tue, Oct 18, 2016 at 7:11 PM, <rianquinn@gmail.com> wrote:
> Writing a hypervisor in C++, and at least on Intel that are a lot of
> things that require 8 and 16 bit integers. To my surprise, this generates a
> warning about conversions:
>
> uint16_t data1 = 1;
> uint16_t data2 = data1 + 1; // warning on possible overflow
>
> The reason is, in C++, when you perform arithmetic, the compiler is
> allowed to up-cast for you to an int if it results in a performance
> improvement. So the compiler changes the result of data1 + 1 to an int, and
> then complains because you could lose data if you store an int back into
> something smaller, even though the programmer never intended it to be an
> int in the first place. The following also fails which gets rid of the 1
> which is technically an int (although no warnings are fired when you store
> 1 into something smaller.. only when you use it in arithmetic):
>
> uint16_t data1 = 1;
> uint16_t data2 = 1;
> uint16_t data3 = data1 + data2; // warning on possible overflow
>
> Now... one might think.. that warning is valid because adding 1 to
> anything could result in an overflow, except that the same is not true for
> an int.
>
> int data1 = 1;
> int data2 = 1;
> int data3 = data1 + data2; // compiles fine
>
> Has there ever been a proposal to fix this? At least in our code, this one
> fix would get rid of a LOT of gsl::narrow_casts as it seems to me the
> warning is a bit overkill as the programmer's intent is valid, it's the
> compiler doing wonky things.
>
> Thanks a ton,
> - Rian
>
> --
> 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/47e7f79f-8676-4a63-
> b7d3-09d64219d575%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575%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/CAMD6iD_1gasqnLRYbTSZJto0iuQDMZoVUhLnqFs3H3r90xbNMg%40mail.gmail.com.
--001a114e27a01801e0053f2c193a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Isn't this a QOI issue, not a standard one?</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Oct 18, 2016 a=
t 7:11 PM, <span dir=3D"ltr"><<a href=3D"mailto:rianquinn@gmail.com" ta=
rget=3D"_blank">rianquinn@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Writing a hypervisor in C++, and at =
least on Intel that are a lot of things that require 8 and 16 bit integers.=
To my surprise, this generates a warning about conversions:</div><div><br>=
</div><div>uint16_t data1 =3D 1;</div><div>uint16_t data2 =3D data1 + 1; =
=C2=A0// warning on possible overflow<br></div><div><br></div>The reason is=
, in C++, when you perform arithmetic, the compiler is allowed to up-cast f=
or you to an int if it results in a performance improvement. So the compile=
r changes the result of data1 + 1 to an int, and then complains because you=
could lose data if you store an int back into something smaller, even thou=
gh the programmer never intended it to be an int in the first place. The fo=
llowing also fails which gets rid of the 1 which is technically an int (alt=
hough no warnings are fired when you store 1 into something smaller.. only =
when you use it in arithmetic):<div><br></div><div><div>uint16_t data1 =3D =
1;</div><div>uint16_t data2 =3D 1;</div><div>uint16_t data3 =3D data1 + dat=
a2; // warning on possible overflow<br></div></div><div><div><br></div><div=
>Now... one might think.. that warning is valid because adding 1 to anythin=
g could result in an overflow, except that the same is not true for an int.=
=C2=A0</div><div><br></div><div>int data1 =3D 1;</div><div>int data2 =3D 1;=
</div><div>int data3 =3D data1 + data2; // compiles fine<br></div></div><di=
v><br></div><div>Has there ever been a proposal to fix this? At least in ou=
r code, this one fix would get rid of a LOT of gsl::narrow_casts as it seem=
s to me the warning is a bit overkill as the programmer's intent is val=
id, it's the compiler doing wonky things. =C2=A0</div><div><br></div><d=
iv>Thanks a ton,</div><div>- Rian</div></div><span class=3D"HOEnZb"><font c=
olor=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/47e7=
f79f-8676-4a63-<wbr>b7d3-09d64219d575%40isocpp.org</a><wbr>.<br>
</font></span></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" 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_1gasqnLRYbTSZJto0iuQDMZoVUhLn=
qFs3H3r90xbNMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_1gasqnLRY=
bTSZJto0iuQDMZoVUhLnqFs3H3r90xbNMg%40mail.gmail.com</a>.<br />
--001a114e27a01801e0053f2c193a--
.
Author: mihailnajdenov@gmail.com
Date: Wed, 19 Oct 2016 03:18:27 -0700 (PDT)
Raw View
------=_Part_125_1305372504.1476872307081
Content-Type: multipart/alternative;
boundary="----=_Part_126_483839719.1476872307081"
------=_Part_126_483839719.1476872307081
Content-Type: text/plain; charset=UTF-8
The first problem is not surprising, because 1 literal is an int. You can
fix this with a user defined literal or constructor like uint16(1).
The second problem is because the operation is performed on wider int in
case you have 0xffff + 0xffff. It has nothing to do with 1.
I am not sure what tricks the compiler does to silence the warning in
the int + int case however.
I any case, I don't believe it can be fixed.
My advise is, to use ints until you need to store the result, then cast it.
The performance will be optimal and you will need to cast once.
This what I do.
--
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/ee2382be-6d48-4cd0-9f8f-3f9bc992a380%40isocpp.org.
------=_Part_126_483839719.1476872307081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The first problem is not surprising, because 1 litera=
l is an int. You can fix this with a user defined literal or constructor li=
ke uint16(1).</div><div><br></div><div>The second problem is because the op=
eration is performed on wider int in case you have 0xffff + 0xffff. It has =
nothing to do with 1.</div><div>I am not sure what tricks the compiler does=
to silence the warning in the=C2=A0int +=C2=A0int case however. </div><div=
><br></div><div>I any case, I don't believe it can be fixed. </div><div=
><br></div><div>My advise is, to use ints until you need to store the resul=
t, then cast it. The performance will be optimal and you will need to cast =
once.</div><div>This what I do.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ee2382be-6d48-4cd0-9f8f-3f9bc992a380%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee2382be-6d48-4cd0-9f8f-3f9bc992a380=
%40isocpp.org</a>.<br />
------=_Part_126_483839719.1476872307081--
------=_Part_125_1305372504.1476872307081--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Oct 2016 09:31:42 -0300
Raw View
--94eb2c0bf85e1da557053f36fee3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 18, 2016 at 8:11 PM, <rianquinn@gmail.com> wrote:
> Writing a hypervisor in C++, and at least on Intel that are a lot of
> things that require 8 and 16 bit integers. To my surprise, this generates=
a
> warning about conversions:
>
> uint16_t data1 =3D 1;
> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>
Interestingly, g++ (5.4) does not complain with that snippet, until you do
{ } initialization:
uint16_t data1{1};
uint16_t data2{data1 + 1};
....then:
warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2=80=99 from =
=E2=80=98int=E2=80=99 to
=E2=80=98uint16_t {aka short unsigned int}=E2=80=99 inside { } [-Wnarrowing=
]
uint16_t data2{data1 + 1};
^
Are you using g++ as well? I'm thinking about patching gcc about this. I
can't get rid off the warning even by explicitly casting the 1 to uint16_t.
I think that a type promotion due to performance reasons should be
considered differently that one explicitly performed, in the way that it
should be immediately demoted to the original type. Different is the case
of a multiplication.
I'm thinking out loud from the compiler maintainer point of view.
IOW, I think the compiler could do:
constexpr uint16_t add_u16(uint16_t x, uint16_t y)
{
return uint16_t(uint32_t(x) + uint32_t(y));
}
in this very case, as a QoI thing.
>
> The reason is, in C++, when you perform arithmetic, the compiler is
> allowed to up-cast for you to an int if it results in a performance
> improvement. So the compiler changes the result of data1 + 1 to an int, a=
nd
> then complains because you could lose data if you store an int back into
> something smaller, even though the programmer never intended it to be an
> int in the first place. The following also fails which gets rid of the 1
> which is technically an int (although no warnings are fired when you stor=
e
> 1 into something smaller.. only when you use it in arithmetic):
>
> uint16_t data1 =3D 1;
> uint16_t data2 =3D 1;
> uint16_t data3 =3D data1 + data2; // warning on possible overflow
>
> Now... one might think.. that warning is valid because adding 1 to
> anything could result in an overflow, except that the same is not true fo=
r
> an int.
>
> int data1 =3D 1;
> int data2 =3D 1;
> int data3 =3D data1 + data2; // compiles fine
>
> Has there ever been a proposal to fix this? At least in our code, this on=
e
> fix would get rid of a LOT of gsl::narrow_casts as it seems to me the
> warning is a bit overkill as the programmer's intent is valid, it's the
> compiler doing wonky things.
>
> Thanks a ton,
> - Rian
>
> --
> 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/47e7f79f-8676-4a63-
> b7d3-09d64219d575%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47e7f79f-86=
76-4a63-b7d3-09d64219d575%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/CAFdMc-1RPatYOmggBx%3D_4uHTMo1hei9npMhXcmyo4VA0m=
uT0gg%40mail.gmail.com.
--94eb2c0bf85e1da557053f36fee3
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, Oct 18, 2016 at 8:11 PM, <span dir=3D"ltr"><<a href=3D"mail=
to:rianquinn@gmail.com" target=3D"_blank">rianquinn@gmail.com</a>></span=
> wrote:<br><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"l=
tr"><div>Writing a hypervisor in C++, and at least on Intel that are a lot =
of things that require 8 and 16 bit integers. To my surprise, this generate=
s a warning about conversions:</div><div><br></div><div>uint16_t data1 =3D =
1;</div><div>uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible ove=
rflow<br></div></div></blockquote><div><br></div><div>Interestingly, g++ (5=
..4) does not complain with that snippet, until you do { } initialization:<b=
r>uint16_t data1{1};<br>uint16_t data2{data1 + 1};<br><br></div><div>...the=
n:<br><br>warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2=
=80=99 from =E2=80=98int=E2=80=99 to =E2=80=98uint16_t {aka short unsigned =
int}=E2=80=99 inside { } [-Wnarrowing]<br>=C2=A0uint16_t data2{data1 + 1};<=
br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 ^<br></div><div>Are you using g++ as well? I'm think=
ing about patching gcc about this. I can't get rid off the warning even=
by explicitly casting the 1 to uint16_t.<br></div><div><br></div><div>I th=
ink that a type promotion due to performance reasons should be considered d=
ifferently that one explicitly performed, in the way that it should be imme=
diately demoted to the original type. Different is the case of a multiplica=
tion.<br></div><div>I'm thinking out loud from the compiler maintainer =
point of view.<br></div><div>IOW, I think the compiler could do:<br></div><=
div>constexpr uint16_t add_u16(uint16_t x, uint16_t y)<br>{<br></div><div>=
=C2=A0=C2=A0=C2=A0 return uint16_t(uint32_t(x) + uint32_t(y));<br></div><di=
v>}<br></div><div>in this very case, as a QoI thing.<br></div><div><br></di=
v><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div></div><div><br></div>The reason is, in C++, when you pe=
rform arithmetic, the compiler is allowed to up-cast for you to an int if i=
t results in a performance improvement. So the compiler changes the result =
of data1 + 1 to an int, and then complains because you could lose data if y=
ou store an int back into something smaller, even though the programmer nev=
er intended it to be an int in the first place. The following also fails wh=
ich gets rid of the 1 which is technically an int (although no warnings are=
fired when you store 1 into something smaller.. only when you use it in ar=
ithmetic):<div><br></div><div><div>uint16_t data1 =3D 1;</div><div>uint16_t=
data2 =3D 1;</div><div>uint16_t data3 =3D data1 + data2; // warning on pos=
sible overflow<br></div></div><div><div><br></div><div>Now... one might thi=
nk.. that warning is valid because adding 1 to anything could result in an =
overflow, except that the same is not true for an int.=C2=A0</div><div><br>=
</div><div>int data1 =3D 1;</div><div>int data2 =3D 1;</div><div>int data3 =
=3D data1 + data2; // compiles fine<br></div></div><div><br></div><div>Has =
there ever been a proposal to fix this? At least in our code, this one fix =
would get rid of a LOT of gsl::narrow_casts as it seems to me the warning i=
s a bit overkill as the programmer's intent is valid, it's the comp=
iler doing wonky things. =C2=A0</div><div><br></div><div>Thanks a ton,</div=
><div>- Rian</div></div><span class=3D"gmail-HOEnZb"><font color=3D"#888888=
">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/47e7=
f79f-8676-4a63-<wbr>b7d3-09d64219d575%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>One gu=
ess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br=
>Who never shows a bit of temperament?<br>Who's never wrong but always =
right?<br>Who'd never dream of starting a fight?<br>Who get stuck with =
all the bad luck? </div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAFdMc-1RPatYOmggBx%3D_4uHTMo1hei9npM=
hXcmyo4VA0muT0gg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1RPatYOm=
ggBx%3D_4uHTMo1hei9npMhXcmyo4VA0muT0gg%40mail.gmail.com</a>.<br />
--94eb2c0bf85e1da557053f36fee3--
.
Author: rianquinn@gmail.com
Date: Wed, 19 Oct 2016 05:41:10 -0700 (PDT)
Raw View
------=_Part_39_826757272.1476880870769
Content-Type: multipart/alternative;
boundary="----=_Part_40_251886712.1476880870770"
------=_Part_40_251886712.1476880870770
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes I am using GCC, and IIRC I think Clang had a similar issue (not idea=20
about VS). And we had the same thing, casting 1 to a unit16_t doesn't=20
change the issue as the result of data1 + data2 =3D=3D int even though data=
1=20
and data2 are both uint16_t. That fact that the compiler is turning this=20
into an int is fine... but it should not warn about a conversion if your=20
storing the result back into the same type, as in that case, the=20
programmer's intent was good, especially when it's fine if all the types=20
are an int or higher.=20
On Wednesday, October 19, 2016 at 6:31:49 AM UTC-6, dgutson wrote:
>
>
>
> On Tue, Oct 18, 2016 at 8:11 PM, <rian...@gmail.com <javascript:>> wrote:
>
>> Writing a hypervisor in C++, and at least on Intel that are a lot of=20
>> things that require 8 and 16 bit integers. To my surprise, this generate=
s a=20
>> warning about conversions:
>>
>> uint16_t data1 =3D 1;
>> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>>
>
> Interestingly, g++ (5.4) does not complain with that snippet, until you d=
o=20
> { } initialization:
> uint16_t data1{1};
> uint16_t data2{data1 + 1};
>
> ...then:
>
> warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2=80=99 fro=
m =E2=80=98int=E2=80=99 to=20
> =E2=80=98uint16_t {aka short unsigned int}=E2=80=99 inside { } [-Wnarrowi=
ng]
> uint16_t data2{data1 + 1};
> ^
> Are you using g++ as well? I'm thinking about patching gcc about this. I=
=20
> can't get rid off the warning even by explicitly casting the 1 to uint16_=
t.
>
> I think that a type promotion due to performance reasons should be=20
> considered differently that one explicitly performed, in the way that it=
=20
> should be immediately demoted to the original type. Different is the case=
=20
> of a multiplication.
> I'm thinking out loud from the compiler maintainer point of view.
> IOW, I think the compiler could do:
> constexpr uint16_t add_u16(uint16_t x, uint16_t y)
> {
> return uint16_t(uint32_t(x) + uint32_t(y));
> }
> in this very case, as a QoI thing.
>
> =20
>
>>
>> The reason is, in C++, when you perform arithmetic, the compiler is=20
>> allowed to up-cast for you to an int if it results in a performance=20
>> improvement. So the compiler changes the result of data1 + 1 to an int, =
and=20
>> then complains because you could lose data if you store an int back into=
=20
>> something smaller, even though the programmer never intended it to be an=
=20
>> int in the first place. The following also fails which gets rid of the 1=
=20
>> which is technically an int (although no warnings are fired when you sto=
re=20
>> 1 into something smaller.. only when you use it in arithmetic):
>>
>> uint16_t data1 =3D 1;
>> uint16_t data2 =3D 1;
>> uint16_t data3 =3D data1 + data2; // warning on possible overflow
>>
>> Now... one might think.. that warning is valid because adding 1 to=20
>> anything could result in an overflow, except that the same is not true f=
or=20
>> an int.=20
>>
>> int data1 =3D 1;
>> int data2 =3D 1;
>> int data3 =3D data1 + data2; // compiles fine
>>
>> Has there ever been a proposal to fix this? At least in our code, this=
=20
>> one fix would get rid of a LOT of gsl::narrow_casts as it seems to me th=
e=20
>> warning is a bit overkill as the programmer's intent is valid, it's the=
=20
>> compiler doing wonky things. =20
>>
>> Thanks a ton,
>> - Rian
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47e7f79f-86=
76-4a63-b7d3-09d64219d575%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47e7f79f-8=
676-4a63-b7d3-09d64219d575%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --=20
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?=20
>
--=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/8bb7b811-f25c-47a9-bddc-51b315123821%40isocpp.or=
g.
------=_Part_40_251886712.1476880870770
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes I am using GCC, and IIRC I think Clang had a similar i=
ssue (not idea about VS). And we had the same thing, casting 1 to a unit16_=
t doesn't change the issue as the result of data1 + data2 =3D=3D int ev=
en though data1 and data2 are both uint16_t. That fact that the compiler is=
turning this into an int is fine... but it should not warn about a convers=
ion if your storing the result back into the same type, as in that case, th=
e programmer's intent was good, especially when it's fine if all th=
e types are an int or higher.=C2=A0<div><br>On Wednesday, October 19, 2016 =
at 6:31:49 AM UTC-6, dgutson 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"ltr"><br><div><br><div class=3D"gmail_quote">On Tue, Oct =
18, 2016 at 8:11 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Qr9dgEbbBgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">rian...@gmail.com</a>></span> wr=
ote:<br><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>Writing a hypervisor in C++, and at least on Intel that are a lot of t=
hings that require 8 and 16 bit integers. To my surprise, this generates a =
warning about conversions:</div><div><br></div><div>uint16_t data1 =3D 1;</=
div><div>uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible overflo=
w<br></div></div></blockquote><div><br></div><div>Interestingly, g++ (5.4) =
does not complain with that snippet, until you do { } initialization:<br>ui=
nt16_t data1{1};<br>uint16_t data2{data1 + 1};<br><br></div><div>...then:<b=
r><br>warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2=80=99=
from =E2=80=98int=E2=80=99 to =E2=80=98uint16_t {aka short unsigned int}=
=E2=80=99 inside { } [-Wnarrowing]<br>=C2=A0uint16_t data2{data1 + 1};<br><=
/div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<wbr>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 ^<br></div><div>Are you using g++ as well? I'm th=
inking about patching gcc about this. I can't get rid off the warning e=
ven by explicitly casting the 1 to uint16_t.<br></div><div><br></div><div>I=
think that a type promotion due to performance reasons should be considere=
d differently that one explicitly performed, in the way that it should be i=
mmediately demoted to the original type. Different is the case of a multipl=
ication.<br></div><div>I'm thinking out loud from the compiler maintain=
er point of view.<br></div><div>IOW, I think the compiler could do:<br></di=
v><div>constexpr uint16_t add_u16(uint16_t x, uint16_t y)<br>{<br></div><di=
v>=C2=A0=C2=A0=C2=A0 return uint16_t(uint32_t(x) + uint32_t(y));<br></div><=
div>}<br></div><div>in this very case, as a QoI thing.<br></div><div><br></=
div><div>=C2=A0<br></div><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></div><div><br></div>The reason is, in C++, when you =
perform arithmetic, the compiler is allowed to up-cast for you to an int if=
it results in a performance improvement. So the compiler changes the resul=
t of data1 + 1 to an int, and then complains because you could lose data if=
you store an int back into something smaller, even though the programmer n=
ever intended it to be an int in the first place. The following also fails =
which gets rid of the 1 which is technically an int (although no warnings a=
re fired when you store 1 into something smaller.. only when you use it in =
arithmetic):<div><br></div><div><div>uint16_t data1 =3D 1;</div><div>uint16=
_t data2 =3D 1;</div><div>uint16_t data3 =3D data1 + data2; // warning on p=
ossible overflow<br></div></div><div><div><br></div><div>Now... one might t=
hink.. that warning is valid because adding 1 to anything could result in a=
n overflow, except that the same is not true for an int.=C2=A0</div><div><b=
r></div><div>int data1 =3D 1;</div><div>int data2 =3D 1;</div><div>int data=
3 =3D data1 + data2; // compiles fine<br></div></div><div><br></div><div>Ha=
s there ever been a proposal to fix this? At least in our code, this one fi=
x would get rid of a LOT of gsl::narrow_casts as it seems to me the warning=
is a bit overkill as the programmer's intent is valid, it's the co=
mpiler doing wonky things. =C2=A0</div><div><br></div><div>Thanks a ton,</d=
iv><div>- Rian</div></div><span><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Qr9dgEbbBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Qr9dgEbbBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/47e7f79f-8676-4a63-b7d3-09d64219d575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/47e7f79f-8676-4a63-b7d3-09d64219d575%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/47e7f79f-8676-4a63-<wbr>b7d3-=
09d64219d575%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div>Who=
=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=80=99s who?<=
br>Who=E2=80=99d never, ever start an argument?<br>Who never shows a bit of=
temperament?<br>Who's never wrong but always right?<br>Who'd never=
dream of starting a fight?<br>Who get stuck with all the bad luck? </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" 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/8bb7b811-f25c-47a9-bddc-51b315123821%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8bb7b811-f25c-47a9-bddc-51b315123821=
%40isocpp.org</a>.<br />
------=_Part_40_251886712.1476880870770--
------=_Part_39_826757272.1476880870769--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 19 Oct 2016 20:55:03 +0800
Raw View
--Apple-Mail=_EDA24AED-E6E2-4202-BDCA-172979AE1275
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <danielgutson@gmail.=
com> wrote:
>=20
>=20
>=20
> On Tue, Oct 18, 2016 at 8:11 PM, <rianquinn@gmail.com <mailto:rianquinn@g=
mail.com>> wrote:
> Writing a hypervisor in C++, and at least on Intel that are a lot of thin=
gs that require 8 and 16 bit integers. To my surprise, this generates a war=
ning about conversions:
>=20
> uint16_t data1 =3D 1;
> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>=20
> Interestingly, g++ (5.4) does not complain with that snippet, until you d=
o { } initialization:
I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and couldn=
=E2=80=99t get any diagnoses.
With braces, the narrowing conversion makes the program ill-formed. It is c=
onforming to issue a warning for an ill-formed program, but it is nonconfor=
ming to be quiet. The standard doesn=E2=80=99t usually differentiate betwee=
n error messages and warning messages.
To silence the warning requires a static_cast on the sum: data2{ static_cas=
t< uint16_t >( data1 + 1 ) }.
It would be nice to redo C++ without integer promotion, but perhaps allowin=
g the same optimization as a matter of undefined overflow, much as floating=
-point computations don=E2=80=99t have guaranteed imprecision. Unfortunatel=
y, we=E2=80=99re pretty much stuck with it.
--=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/15C675BC-1FAC-4196-9978-FAB54B0DE897%40gmail.com=
..
--Apple-Mail=_EDA24AED-E6E2-4202-BDCA-172979AE1275
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9310=
=E2=80=9319, at 8:31 PM, dgutson . <<a href=3D"mailto:danielgutson@gmail=
..com" class=3D"">danielgutson@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><br cl=
ass=3D""><div class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quot=
e">On Tue, Oct 18, 2016 at 8:11 PM, <span dir=3D"ltr" class=3D""><<a hr=
ef=3D"mailto:rianquinn@gmail.com" target=3D"_blank" class=3D"">rianquinn@gm=
ail.com</a>></span> wrote:<br class=3D""><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 dir=3D"ltr" class=3D""><div class=3D"">Writing a hy=
pervisor in C++, and at least on Intel that are a lot of things that requir=
e 8 and 16 bit integers. To my surprise, this generates a warning about con=
versions:</div><div class=3D""><br class=3D""></div><div class=3D"">uint16_=
t data1 =3D 1;</div><div class=3D"">uint16_t data2 =3D data1 + 1; // =
warning on possible overflow<br class=3D""></div></div></blockquote><div cl=
ass=3D""><br class=3D""></div><div class=3D"">Interestingly, g++ (5.4) does=
not complain with that snippet, until you do { } initialization:<br class=
=3D""></div></div></div></div></div></blockquote><div><br class=3D""></div>=
<div>I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and co=
uldn=E2=80=99t get any diagnoses.</div><div><br class=3D""></div><div>With =
braces, the narrowing conversion makes the program ill-formed. It is confor=
ming to issue a warning for an ill-formed program, but it is nonconforming =
to be quiet. The standard doesn=E2=80=99t usually differentiate between err=
or messages and warning messages.</div><div><br class=3D""></div><div>To si=
lence the warning requires a static_cast on the sum: <font face=3D"Courier"=
class=3D"">data2{ static_cast< uint16_t >( data1 + 1 ) }</font>.</di=
v><div><br class=3D""></div><div>It would be nice to redo C++ without integ=
er promotion, but perhaps allowing the same optimization as a matter of und=
efined overflow, much as floating-point computations don=E2=80=99t have gua=
ranteed imprecision. Unfortunately, we=E2=80=99re pretty much stuck with it=
..</div><div><br class=3D""></div></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/15C675BC-1FAC-4196-9978-FAB54B0DE897%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15C675BC-1FAC-4196-9978-FAB54B0DE897%=
40gmail.com</a>.<br />
--Apple-Mail=_EDA24AED-E6E2-4202-BDCA-172979AE1275--
.
Author: rianquinn@gmail.com
Date: Wed, 19 Oct 2016 05:59:32 -0700 (PDT)
Raw View
------=_Part_35_87710164.1476881972850
Content-Type: multipart/alternative;
boundary="----=_Part_36_1039713435.1476881972850"
------=_Part_36_1039713435.1476881972850
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
These are the flags that we are using:
-Wall -Wextra -Wpedantic -Wctor-dtor-privacy -Wshadow -Wnon-virtual-dtor=20
-Wold-style-cast -Wcast-align -Woverloaded-virtual -Wconversion=20
-Wsign-conversion -DGSL_THROW_ON_CONTRACT_VIOLATION -fpic -fexceptions=20
-fstack-protector-strong -mstackrealign -mmmx -msse -msse2 -msse3 -mssse3=
=20
-msse4.1 -msse4.2 -msse4 -mavx -maes -ffreestanding -mno-red-zone
I think -Wconversion is the offending flag.=20
- Rian
On Wednesday, October 19, 2016 at 6:55:09 AM UTC-6, David Krauss wrote:
>
>
> On 2016=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <daniel...@gmail.com=
<javascript:>>=20
> wrote:
>
>
>
> On Tue, Oct 18, 2016 at 8:11 PM, <rian...@gmail.com <javascript:>> wrote:
>
>> Writing a hypervisor in C++, and at least on Intel that are a lot of=20
>> things that require 8 and 16 bit integers. To my surprise, this generate=
s a=20
>> warning about conversions:
>>
>> uint16_t data1 =3D 1;
>> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>>
>
> Interestingly, g++ (5.4) does not complain with that snippet, until you d=
o=20
> { } initialization:
>
>
> I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and=20
> couldn=E2=80=99t get any diagnoses.
>
> With braces, the narrowing conversion makes the program ill-formed. It is=
=20
> conforming to issue a warning for an ill-formed program, but it is=20
> nonconforming to be quiet. The standard doesn=E2=80=99t usually different=
iate=20
> between error messages and warning messages.
>
> To silence the warning requires a static_cast on the sum: data2{=20
> static_cast< uint16_t >( data1 + 1 ) }.
>
> It would be nice to redo C++ without integer promotion, but perhaps=20
> allowing the same optimization as a matter of undefined overflow, much as=
=20
> floating-point computations don=E2=80=99t have guaranteed imprecision.=20
> Unfortunately, we=E2=80=99re pretty much stuck with it.
>
>
--=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/6a135136-1acf-465d-994e-fc3c60fb2764%40isocpp.or=
g.
------=_Part_36_1039713435.1476881972850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">These are the flags that we are using:<div><br></div><div>=
-Wall -Wextra -Wpedantic -Wctor-dtor-privacy -Wshadow -Wnon-virtual-dtor -W=
old-style-cast -Wcast-align -Woverloaded-virtual -Wconversion -Wsign-conver=
sion -DGSL_THROW_ON_CONTRACT_VIOLATION -fpic -fexceptions -fstack-protector=
-strong -mstackrealign -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 =
-msse4 -mavx -maes -ffreestanding -mno-red-zone</div><div><br></div><div>I =
think -Wconversion is the offending flag.=C2=A0</div><div><br></div><div>- =
Rian</div><div><br></div><div><br><br>On Wednesday, October 19, 2016 at 6:5=
5:09 AM UTC-6, David Krauss wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite=
"><div>On 2016=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wlSLVIzcBgAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">daniel...@gmai=
l.com</a>> wrote:</div><br><div><div dir=3D"ltr"><br><div><br><div class=
=3D"gmail_quote">On Tue, Oct 18, 2016 at 8:11 PM, <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wlSLVIzcBg=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">rian...=
@gmail.com</a>></span> wrote:<br><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>Writing a hypervisor in C++, and at least =
on Intel that are a lot of things that require 8 and 16 bit integers. To my=
surprise, this generates a warning about conversions:</div><div><br></div>=
<div>uint16_t data1 =3D 1;</div><div>uint16_t data2 =3D data1 + 1; =C2=A0//=
warning on possible overflow<br></div></div></blockquote><div><br></div><d=
iv>Interestingly, g++ (5.4) does not complain with that snippet, until you =
do { } initialization:<br></div></div></div></div></div></blockquote><div><=
br></div><div>I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowi=
ng and couldn=E2=80=99t get any diagnoses.</div><div><br></div><div>With br=
aces, the narrowing conversion makes the program ill-formed. It is conformi=
ng to issue a warning for an ill-formed program, but it is nonconforming to=
be quiet. The standard doesn=E2=80=99t usually differentiate between error=
messages and warning messages.</div><div><br></div><div>To silence the war=
ning requires a static_cast on the sum: <font face=3D"Courier">data2{ stati=
c_cast< uint16_t >( data1 + 1 ) }</font>.</div><div><br></div><div>It=
would be nice to redo C++ without integer promotion, but perhaps allowing =
the same optimization as a matter of undefined overflow, much as floating-p=
oint computations don=E2=80=99t have guaranteed imprecision. Unfortunately,=
we=E2=80=99re pretty much stuck with it.</div><div><br></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" 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/6a135136-1acf-465d-994e-fc3c60fb2764%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a135136-1acf-465d-994e-fc3c60fb2764=
%40isocpp.org</a>.<br />
------=_Part_36_1039713435.1476881972850--
------=_Part_35_87710164.1476881972850--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Oct 2016 09:59:51 -0300
Raw View
--94eb2c05b49e85ede6053f376245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 19, 2016 at 9:55 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2016=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <danielgutson@gmail.=
com> wrote:
>
>
>
> On Tue, Oct 18, 2016 at 8:11 PM, <rianquinn@gmail.com> wrote:
>
>> Writing a hypervisor in C++, and at least on Intel that are a lot of
>> things that require 8 and 16 bit integers. To my surprise, this generate=
s a
>> warning about conversions:
>>
>> uint16_t data1 =3D 1;
>> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>>
>
> Interestingly, g++ (5.4) does not complain with that snippet, until you d=
o
> { } initialization:
>
>
> I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and
> couldn=E2=80=99t get any diagnoses.
>
> With braces, the narrowing conversion makes the program ill-formed.
>
Is this ill-formed?
uint16_t data2{data1 + uint16_t(1)};
Accordint to what paragraph?
> It is conforming to issue a warning for an ill-formed program, but it is
> nonconforming to be quiet. The standard doesn=E2=80=99t usually different=
iate
> between error messages and warning messages.
>
> To silence the warning requires a static_cast on the sum: data2{
> static_cast< uint16_t >( data1 + 1 ) }.
>
> It would be nice to redo C++ without integer promotion, but perhaps
> allowing the same optimization as a matter of undefined overflow, much as
> floating-point computations don=E2=80=99t have guaranteed imprecision.
> Unfortunately, we=E2=80=99re pretty much stuck with 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/15C675BC-1FAC-4196-
> 9978-FAB54B0DE897%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15C675BC-1F=
AC-4196-9978-FAB54B0DE897%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
> .
>
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/CAFdMc-1qTmorx8NpEkL5vDcbjXRwo0w31simYy878KcPKyM=
T1Q%40mail.gmail.com.
--94eb2c05b49e85ede6053f376245
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 Wed, Oct 19, 2016 at 9:55 AM, David Krauss <span dir=3D"ltr"><<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:br=
eak-word"><br><div><span class=3D""><blockquote type=3D"cite"><div>On 2016=
=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <<a href=3D"mailto:danielg=
utson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>> wrote:</d=
iv><br class=3D"m_-3620126428693785008Apple-interchange-newline"><div><div =
dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Tue, Oct 18, 2016 at 8:11 PM, <span dir=3D"ltr"><<a href=3D"mailto:ri=
anquinn@gmail.com" target=3D"_blank">rianquinn@gmail.com</a>></span> wro=
te:<br><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>Writing a hypervisor in C++, and at least on Intel that are a lot of th=
ings that require 8 and 16 bit integers. To my surprise, this generates a w=
arning about conversions:</div><div><br></div><div>uint16_t data1 =3D 1;</d=
iv><div>uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible overflow=
<br></div></div></blockquote><div><br></div><div>Interestingly, g++ (5.4) d=
oes not complain with that snippet, until you do { } initialization:<br></d=
iv></div></div></div></div></blockquote><div><br></div></span><div>I tried =
GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and couldn=E2=80=99=
t get any diagnoses.</div><div><br></div><div>With braces, the narrowing co=
nversion makes the program ill-formed. </div></div></div></blockquote><div>=
<br></div><div>Is this ill-formed?<br><br></div><div>uint16_t data2{data1 +=
uint16_t(1)};<br><br></div><div>Accordint to what paragraph?<br><br></div>=
<div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap=
:break-word"><div><div>It is conforming to issue a warning for an ill-forme=
d program, but it is nonconforming to be quiet. The standard doesn=E2=80=99=
t usually differentiate between error messages and warning messages.</div><=
div><br></div><div>To silence the warning requires a static_cast on the sum=
: <font face=3D"Courier">data2{ static_cast< uint16_t >( data1 + 1 ) =
}</font>.</div><div><br></div><div>It would be nice to redo C++ without int=
eger promotion, but perhaps allowing the same optimization as a matter of u=
ndefined overflow, much as floating-point computations don=E2=80=99t have g=
uaranteed imprecision. Unfortunately, we=E2=80=99re pretty much stuck with =
it.</div><div><br></div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/15C675BC-1FAC-4196-9978-FAB54B0DE897%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/15C67=
5BC-1FAC-4196-<wbr>9978-FAB54B0DE897%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got the sweetest d=
isposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever =
start an argument?<br>Who never shows a bit of temperament?<br>Who's ne=
ver wrong but always right?<br>Who'd never dream of starting a fight?<b=
r>Who get stuck with all the bad luck? </div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAFdMc-1qTmorx8NpEkL5vDcbjXRwo0w31sim=
Yy878KcPKyMT1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1qTmorx8Np=
EkL5vDcbjXRwo0w31simYy878KcPKyMT1Q%40mail.gmail.com</a>.<br />
--94eb2c05b49e85ede6053f376245--
.
Author: rianquinn@gmail.com
Date: Wed, 19 Oct 2016 06:03:33 -0700 (PDT)
Raw View
------=_Part_51_27726418.1476882213680
Content-Type: multipart/alternative;
boundary="----=_Part_52_824848434.1476882213680"
------=_Part_52_824848434.1476882213680
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Here is a an actual example from my project:
https://github.com/Bareflank/hypervisor/blob/master/bfvmm/src/serial/src/se=
rial_port_intel_x64.cpp#L119
If I change this code to the following:
void
serial_port_intel_x64::set_data_bits(data_bits_t bits) noexcept
{
auto reg =3D portio::inb(m_port + LINE_CONTROL_REG);
reg &=3D gsl::narrow_cast<decltype(reg)>(~LINE_CONTROL_DATA_MASK);
reg |=3D gsl::narrow_cast<decltype(reg)>(bits & LINE_CONTROL_DATA_MASK)=
;
portio::outb(m_port + LINE_CONTROL_REG, reg);
}
I get this:
/home/user/hypervisor/bfvmm/src/serial/src/serial_port_intel_x64.cpp: In=20
member function =E2=80=98void=20
serial_port_intel_x64::set_data_bits(serial_port_intel_x64::data_bits_t)=E2=
=80=99:
/home/user/hypervisor/bfvmm/src/serial/src/serial_port_intel_x64.cpp:123:9:=
=20
error: conversion to =E2=80=98unsigned char=E2=80=99 from =E2=80=98int=E2=
=80=99 may alter its value=20
[-Werror=3Dconversion]
reg &=3D gsl::narrow_cast<decltype(reg)>(~LINE_CONTROL_DATA_MASK);
^
/home/user/hypervisor/bfvmm/src/serial/src/serial_port_intel_x64.cpp:124:9:=
=20
error: conversion to =E2=80=98unsigned char=E2=80=99 from =E2=80=98int=E2=
=80=99 may alter its value=20
[-Werror=3Dconversion]
reg |=3D gsl::narrow_cast<decltype(reg)>(bits & LINE_CONTROL_DATA_MASK=
);
^
cc1plus: all warnings being treated as errors
On Wednesday, October 19, 2016 at 6:59:53 AM UTC-6, dgutson wrote:
>
>
>
> On Wed, Oct 19, 2016 at 9:55 AM, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:
>
>>
>> On 2016=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <daniel...@gmail.co=
m <javascript:>>=20
>> wrote:
>>
>>
>>
>> On Tue, Oct 18, 2016 at 8:11 PM, <rian...@gmail.com <javascript:>> wrote=
:
>>
>>> Writing a hypervisor in C++, and at least on Intel that are a lot of=20
>>> things that require 8 and 16 bit integers. To my surprise, this generat=
es a=20
>>> warning about conversions:
>>>
>>> uint16_t data1 =3D 1;
>>> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>>>
>>
>> Interestingly, g++ (5.4) does not complain with that snippet, until you=
=20
>> do { } initialization:
>>
>>
>> I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and=20
>> couldn=E2=80=99t get any diagnoses.
>>
>> With braces, the narrowing conversion makes the program ill-formed.=20
>>
>
> Is this ill-formed?
>
> uint16_t data2{data1 + uint16_t(1)};
>
> Accordint to what paragraph?
>
>
> =20
>
>> It is conforming to issue a warning for an ill-formed program, but it is=
=20
>> nonconforming to be quiet. The standard doesn=E2=80=99t usually differen=
tiate=20
>> between error messages and warning messages.
>>
>> To silence the warning requires a static_cast on the sum: data2{=20
>> static_cast< uint16_t >( data1 + 1 ) }.
>>
>> It would be nice to redo C++ without integer promotion, but perhaps=20
>> allowing the same optimization as a matter of undefined overflow, much a=
s=20
>> floating-point computations don=E2=80=99t have guaranteed imprecision.=
=20
>> Unfortunately, we=E2=80=99re pretty much stuck with it.
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15C675BC-1F=
AC-4196-9978-FAB54B0DE897%40gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15C675BC-1=
FAC-4196-9978-FAB54B0DE897%40gmail.com?utm_medium=3Demail&utm_source=3Dfoot=
er>
>> .
>>
>
>
>
> --=20
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?=20
>
--=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/ef262b32-d6d5-40ca-931c-04c25f06ece0%40isocpp.or=
g.
------=_Part_52_824848434.1476882213680
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here is a an actual example from my project:<div><br></div=
><div>https://github.com/Bareflank/hypervisor/blob/master/bfvmm/src/serial/=
src/serial_port_intel_x64.cpp#L119<br></div><div><br></div><div>If I change=
this code to the following:</div><div><br></div><div><div>void</div><div>s=
erial_port_intel_x64::set_data_bits(data_bits_t bits) noexcept</div><div>{<=
/div><div>=C2=A0 =C2=A0 auto reg =3D portio::inb(m_port + LINE_CONTROL_REG)=
;</div><div><br></div><div>=C2=A0 =C2=A0 reg &=3D gsl::narrow_cast<d=
ecltype(reg)>(~LINE_CONTROL_DATA_MASK);</div><div>=C2=A0 =C2=A0 reg |=3D=
gsl::narrow_cast<decltype(reg)>(bits & LINE_CONTROL_DATA_MASK);<=
/div><div><br></div><div>=C2=A0 =C2=A0 portio::outb(m_port + LINE_CONTROL_R=
EG, reg);</div><div>}</div></div><div><br></div><div>I get this:</div><div>=
<br></div><div><div>/home/user/hypervisor/bfvmm/src/serial/src/serial_port_=
intel_x64.cpp: In member function =E2=80=98void serial_port_intel_x64::set_=
data_bits(serial_port_intel_x64::data_bits_t)=E2=80=99:</div><div>/home/use=
r/hypervisor/bfvmm/src/serial/src/serial_port_intel_x64.cpp:123:9: error: c=
onversion to =E2=80=98unsigned char=E2=80=99 from =E2=80=98int=E2=80=99 may=
alter its value [-Werror=3Dconversion]</div><div>=C2=A0 =C2=A0 =C2=A0reg &=
amp;=3D gsl::narrow_cast<decltype(reg)>(~LINE_CONTROL_DATA_MASK);</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^</div><div>/home/user/hypervisor/=
bfvmm/src/serial/src/serial_port_intel_x64.cpp:124:9: error: conversion to =
=E2=80=98unsigned char=E2=80=99 from =E2=80=98int=E2=80=99 may alter its va=
lue [-Werror=3Dconversion]</div><div>=C2=A0 =C2=A0 =C2=A0reg |=3D gsl::narr=
ow_cast<decltype(reg)>(bits & LINE_CONTROL_DATA_MASK);</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^</div><div>cc1plus: all warnings being t=
reated as errors</div></div><div><br></div><div><br><br>On Wednesday, Octob=
er 19, 2016 at 6:59:53 AM UTC-6, dgutson wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">O=
n Wed, Oct 19, 2016 at 9:55 AM, David Krauss <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"xiG6lM7cBgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"=
word-wrap:break-word"><br><div><span><blockquote type=3D"cite"><div>On 2016=
=E2=80=9310=E2=80=9319, at 8:31 PM, dgutson . <<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"xiG6lM7cBgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">daniel...@gmail.com</a>> wr=
ote:</div><br><div><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"=
>On Tue, Oct 18, 2016 at 8:11 PM, <span dir=3D"ltr"><<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"xiG6lM7cBgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">rian...@gmail.com</a>&g=
t;</span> wrote:<br><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>Writing a hypervisor in C++, and at least on Intel that ar=
e a lot of things that require 8 and 16 bit integers. To my surprise, this =
generates a warning about conversions:</div><div><br></div><div>uint16_t da=
ta1 =3D 1;</div><div>uint16_t data2 =3D data1 + 1; =C2=A0// warning on poss=
ible overflow<br></div></div></blockquote><div><br></div><div>Interestingly=
, g++ (5.4) does not complain with that snippet, until you do { } initializ=
ation:<br></div></div></div></div></div></blockquote><div><br></div></span>=
<div>I tried GCC and Clang with -Wall -Wextra -Woverflow -Wnarrowing and co=
uldn=E2=80=99t get any diagnoses.</div><div><br></div><div>With braces, the=
narrowing conversion makes the program ill-formed. </div></div></div></blo=
ckquote><div><br></div><div>Is this ill-formed?<br><br></div><div>uint16_t =
data2{data1 + uint16_t(1)};<br><br></div><div>Accordint to what paragraph?<=
br><br></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div><div>It is conforming to issue a warning f=
or an ill-formed program, but it is nonconforming to be quiet. The standard=
doesn=E2=80=99t usually differentiate between error messages and warning m=
essages.</div><div><br></div><div>To silence the warning requires a static_=
cast on the sum: <font face=3D"Courier">data2{ static_cast< uint16_t >=
;( data1 + 1 ) }</font>.</div><div><br></div><div>It would be nice to redo =
C++ without integer promotion, but perhaps allowing the same optimization a=
s a matter of undefined overflow, much as floating-point computations don=
=E2=80=99t have guaranteed imprecision. Unfortunately, we=E2=80=99re pretty=
much stuck with it.</div><div><br></div></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
xiG6lM7cBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"xiG6lM7cBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/15C675BC-1FAC-4196-9978-FAB54B0DE897%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/15C675BC-1FAC-4196-9978-FAB54B0DE897%40gm=
ail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" oncl=
ick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/15C675BC-1FAC-4196-9978-FAB54B0DE897%40gmail.com?utm_medium\x3dem=
ail\x26utm_source\x3dfooter';return true;">https://groups.google.com/a/=
<wbr>isocpp.org/d/msgid/std-<wbr>proposals/15C675BC-1FAC-4196-<wbr>9978-FAB=
54B0DE897%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div>Who=E2=80=99s got =
the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99=
d never, ever start an argument?<br>Who never shows a bit of temperament?<b=
r>Who's never wrong but always right?<br>Who'd never dream of start=
ing a fight?<br>Who get stuck with all the bad luck? </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" 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/ef262b32-d6d5-40ca-931c-04c25f06ece0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef262b32-d6d5-40ca-931c-04c25f06ece0=
%40isocpp.org</a>.<br />
------=_Part_52_824848434.1476882213680--
------=_Part_51_27726418.1476882213680--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 19 Oct 2016 06:27:51 -0700 (PDT)
Raw View
------=_Part_17_1132574777.1476883671281
Content-Type: multipart/alternative;
boundary="----=_Part_18_1724840791.1476883671281"
------=_Part_18_1724840791.1476883671281
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
>
> Is this ill-formed?
>
> uint16_t data2{data1 + uint16_t(1)};
>
> Accordint to what paragraph?
>
>
>
[dcl.init.list]/3.7:
=E2=80=94 Otherwise, if the initializer list has a single element of type E=
and=20
either T is not a reference type or its
referenced type is reference-related to E, the object or reference is=20
initialized from that element (by
copy-initialization for copy-list-initialization, or by=20
direct-initialization for direct-list-initialization); if a
narrowing conversion (see below) is required to convert the element to T,=
=20
the program is ill-formed.
[ Example:
int x1 {2}; // OK
int x2 {2.0}; // error: narrowing
=E2=80=94end example ]
Where a narrowing conversion includes conversions
=E2=80=94 from an integer type or unscoped enumeration type to an integer t=
ype that=20
cannot represent all the
values of the original type, except where the source is a constant=20
expression whose value after integral
promotions will fit into the target type.=20
--=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/6daefe47-c583-4283-95cf-cdef3a75808d%40isocpp.or=
g.
------=_Part_18_1724840791.1476883671281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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 class=3D"gmail_quote"><div><br></div><div>Is this ill-formed?<br><=
br></div><div>uint16_t data2{data1 + uint16_t(1)};<br><br></div><div>Accord=
int to what paragraph?<br><br></div><div></div></div><br></div></blockquote=
><div><br></div><div>[dcl.init.list]/3.7:</div><div><br></div><div><div>=E2=
=80=94 Otherwise, if the initializer list has a single element of type E an=
d either T is not a reference type or its</div><div>referenced type is refe=
rence-related to E, the object or reference is initialized from that elemen=
t (by</div><div>copy-initialization for copy-list-initialization, or by dir=
ect-initialization for direct-list-initialization); if a</div><div>narrowin=
g conversion (see below) is required to convert the element to T, the progr=
am is ill-formed.</div><div>[ Example:</div><div>int x1 {2}; // OK</div><di=
v>int x2 {2.0}; // error: narrowing</div><div>=E2=80=94end example ]</div><=
/div><div><br></div><div>Where a narrowing conversion includes conversions<=
/div><div><br></div><div>=E2=80=94 from an integer type or unscoped enumera=
tion type to an integer type that cannot represent all the</div><div>values=
of the original type, except where the source is a constant expression who=
se value after integral</div><div>promotions will fit into the target type.=
=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6daefe47-c583-4283-95cf-cdef3a75808d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6daefe47-c583-4283-95cf-cdef3a75808d=
%40isocpp.org</a>.<br />
------=_Part_18_1724840791.1476883671281--
------=_Part_17_1132574777.1476883671281--
.
Author: rianquinn@gmail.com
Date: Wed, 19 Oct 2016 06:32:42 -0700 (PDT)
Raw View
------=_Part_37_1081197982.1476883962880
Content-Type: multipart/alternative;
boundary="----=_Part_38_1620495002.1476883962881"
------=_Part_38_1620495002.1476883962881
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Does that explain why this causes a conversion warning?
auto reg =3D portio::inb(m_port + LINE_CONTROL_REG);
reg &=3D gsl::narrow_cast<decltype(reg)>(~LINE_CONTROL_DATA_MASK);
reg |=3D gsl::narrow_cast<decltype(reg)>(bits & LINE_CONTROL_DATA_MASK)=
;
Currently, my code does this to get rid of the conversion warning, which=20
should (I thought) identical:
auto reg =3D portio::inb(m_port + LINE_CONTROL_REG);
reg =3D reg & gsl::narrow_cast<decltype(reg)>(~LINE_CONTROL_DATA_MASK);
reg =3D reg | gsl::narrow_cast<decltype(reg)>(bits &=20
LINE_CONTROL_DATA_MASK);
It might just a be a compiler bug, but googling the topic, others have seen=
=20
this, and the answers I have seen have been quotes to the spec suggesting=
=20
this is intended which is why I asked if someone had attempted to write a=
=20
proposal to address this as it seems like there are a couple of edge cases=
=20
here that just need to be cleaned up.=20
- Rian
On Wednesday, October 19, 2016 at 7:27:51 AM UTC-6, Barry Revzin wrote:
>
>
>> Is this ill-formed?
>>
>> uint16_t data2{data1 + uint16_t(1)};
>>
>> Accordint to what paragraph?
>>
>>
>>
> [dcl.init.list]/3.7:
>
> =E2=80=94 Otherwise, if the initializer list has a single element of type=
E and=20
> either T is not a reference type or its
> referenced type is reference-related to E, the object or reference is=20
> initialized from that element (by
> copy-initialization for copy-list-initialization, or by=20
> direct-initialization for direct-list-initialization); if a
> narrowing conversion (see below) is required to convert the element to T,=
=20
> the program is ill-formed.
> [ Example:
> int x1 {2}; // OK
> int x2 {2.0}; // error: narrowing
> =E2=80=94end example ]
>
> Where a narrowing conversion includes conversions
>
> =E2=80=94 from an integer type or unscoped enumeration type to an integer=
type=20
> that cannot represent all the
> values of the original type, except where the source is a constant=20
> expression whose value after integral
> promotions will fit into the target type.=20
>
--=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/7ee1fdae-127c-4965-ba81-d70896f1a2f3%40isocpp.or=
g.
------=_Part_38_1620495002.1476883962881
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Does that explain why this causes a conversion warning?<di=
v><br></div><div><div>=C2=A0 =C2=A0 auto reg =3D portio::inb(m_port + LINE_=
CONTROL_REG);</div><div><br></div><div>=C2=A0 =C2=A0 reg &=3D gsl::narr=
ow_cast<decltype(reg)<wbr>>(~LINE_CONTROL_DATA_MASK);</div><div>=C2=
=A0 =C2=A0 reg |=3D gsl::narrow_cast<decltype(reg)<wbr>>(bits & L=
INE_CONTROL_DATA_MASK);</div><div><br></div><div>Currently, my code does th=
is to get rid of the conversion warning, which should (I thought) identical=
:</div><div><br></div><div><div>=C2=A0 =C2=A0 auto reg =3D portio::inb(m_po=
rt + LINE_CONTROL_REG);</div><div><br></div><div>=C2=A0 =C2=A0 reg =3D reg =
& gsl::narrow_cast<decltype(reg)<wbr>>(~LINE_CONTROL_DATA_MASK);<=
/div><div>=C2=A0 =C2=A0 reg =3D reg | gsl::narrow_cast<decltype(reg)<wbr=
>>(bits & LINE_CONTROL_DATA_MASK);</div></div><div><br></div><div>It=
might just a be a compiler bug, but googling the topic, others have seen t=
his, and the answers I have seen have been quotes to the spec suggesting th=
is is intended which is why I asked if someone had attempted to write a pro=
posal to address this as it seems like there are a couple of edge cases her=
e that just need to be cleaned up.=C2=A0</div><div><br></div><div>- Rian</d=
iv><div><br></div><br>On Wednesday, October 19, 2016 at 7:27:51 AM UTC-6, B=
arry Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><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 class=3D=
"gmail_quote"><div><br></div><div>Is this ill-formed?<br><br></div><div>uin=
t16_t data2{data1 + uint16_t(1)};<br><br></div><div>Accordint to what parag=
raph?<br><br></div><div></div></div><br></div></blockquote><div><br></div><=
div>[dcl.init.list]/3.7:</div><div><br></div><div><div>=E2=80=94 Otherwise,=
if the initializer list has a single element of type E and either T is not=
a reference type or its</div><div>referenced type is reference-related to =
E, the object or reference is initialized from that element (by</div><div>c=
opy-initialization for copy-list-initialization, or by direct-initializatio=
n for direct-list-initialization); if a</div><div>narrowing conversion (see=
below) is required to convert the element to T, the program is ill-formed.=
</div><div>[ Example:</div><div>int x1 {2}; // OK</div><div>int x2 {2.0}; /=
/ error: narrowing</div><div>=E2=80=94end example ]</div></div><div><br></d=
iv><div>Where a narrowing conversion includes conversions</div><div><br></d=
iv><div>=E2=80=94 from an integer type or unscoped enumeration type to an i=
nteger type that cannot represent all the</div><div>values of the original =
type, except where the source is a constant expression whose value after in=
tegral</div><div>promotions will fit into the target type.=C2=A0</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" 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/7ee1fdae-127c-4965-ba81-d70896f1a2f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7ee1fdae-127c-4965-ba81-d70896f1a2f3=
%40isocpp.org</a>.<br />
------=_Part_38_1620495002.1476883962881--
------=_Part_37_1081197982.1476883962880--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Oct 2016 10:33:28 -0300
Raw View
--001a11449760c32f20053f37dafb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 19, 2016 at 10:27 AM, Barry Revzin <barry.revzin@gmail.com>
wrote:
>
>> Is this ill-formed?
>>
>> uint16_t data2{data1 + uint16_t(1)};
>>
>> Accordint to what paragraph?
>>
>>
>>
> [dcl.init.list]/3.7:
>
> =E2=80=94 Otherwise, if the initializer list has a single element of type=
E and
> either T is not a reference type or its
> referenced type is reference-related to E, the object or reference is
> initialized from that element (by
> copy-initialization for copy-list-initialization, or by
> direct-initialization for direct-list-initialization); if a
> narrowing conversion (see below) is required to convert the element to T,
> the program is ill-formed.
> [ Example:
> int x1 {2}; // OK
> int x2 {2.0}; // error: narrowing
> =E2=80=94end example ]
>
> Where a narrowing conversion includes conversions
>
>
What about adding an amendment to the following clause ("except" part) to
consider this case, something like...
> =E2=80=94 from an integer type or unscoped enumeration type to an integer=
type
> that cannot represent all the
> values of the original type, except where the source is a constant
> expression whose value after integral
> promotions will fit into the target type
>
... and optionally an arithmetic operation where the operands are such
constant expression and an operand of the T?
(sorry my "std English"). I think we could improve the clause because
beyond what it rules, this scenario is a valid conversion.
> .
>
> --
> 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/6daefe47-c583-4283-
> 95cf-cdef3a75808d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6daefe47-c5=
83-4283-95cf-cdef3a75808d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/CAFdMc-0-xBbA9RZ73vz%2BBWApFpBePwbT9C%3DFfSsSBGv=
rGnemxw%40mail.gmail.com.
--001a11449760c32f20053f37dafb
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 Wed, Oct 19, 2016 at 10:27 AM, Barry Revzin <span dir=3D"ltr"><<a=
href=3D"mailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmai=
l.com</a>></span> wrote:<br><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"><span class=3D""><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"lt=
r"><div class=3D"gmail_quote"><div><br></div><div>Is this ill-formed?<br><b=
r></div><div>uint16_t data2{data1 + uint16_t(1)};<br><br></div><div>Accordi=
nt to what paragraph?<br><br></div><div></div></div><br></div></blockquote>=
<div><br></div></span><div>[dcl.init.list]/3.7:</div><div><br></div><div><d=
iv>=E2=80=94 Otherwise, if the initializer list has a single element of typ=
e E and either T is not a reference type or its</div><div>referenced type i=
s reference-related to E, the object or reference is initialized from that =
element (by</div><div>copy-initialization for copy-list-initialization, or =
by direct-initialization for direct-list-initialization); if a</div><div>na=
rrowing conversion (see below) is required to convert the element to T, the=
program is ill-formed.</div><div>[ Example:</div><div>int x1 {2}; // OK</d=
iv><div>int x2 {2.0}; // error: narrowing</div><div>=E2=80=94end example ]<=
/div></div><div><br></div><div>Where a narrowing conversion includes conver=
sions</div><div><br></div></div></blockquote><div><br></div><div>What about=
adding an amendment to the following clause ("except" part) to c=
onsider this case, something like...</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>=E2=80=94 from an integer t=
ype or unscoped enumeration type to an integer type that cannot represent a=
ll the</div><div>values of the original type, except where the source is a =
constant expression whose value after integral</div><div>promotions will fi=
t into the target type</div></div></blockquote><div><br></div><div>.. and o=
ptionally an arithmetic operation where the operands are such constant expr=
ession and an operand of the T?</div><div><br></div><div>(sorry my "st=
d English"). I think we could improve the clause because beyond what i=
t rules, this scenario is a valid conversion.=C2=A0</div><div><br></div><di=
v>=C2=A0</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"><div>.=C2=A0<=
/div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6daefe47-c583-4283-95cf-cdef3a75808d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6dae=
fe47-c583-4283-<wbr>95cf-cdef3a75808d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who's never wrong but always right?<br>Who'd never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAFdMc-0-xBbA9RZ73vz%2BBWApFpBePwbT9C=
%3DFfSsSBGvrGnemxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0-xBbA=
9RZ73vz%2BBWApFpBePwbT9C%3DFfSsSBGvrGnemxw%40mail.gmail.com</a>.<br />
--001a11449760c32f20053f37dafb--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Oct 2016 11:09:05 -0700
Raw View
On ter=C3=A7a-feira, 18 de outubro de 2016 16:11:27 PDT rianquinn@gmail.com=
wrote:
> Writing a hypervisor in C++, and at least on Intel that are a lot of thin=
gs
> that require 8 and 16 bit integers. To my surprise, this generates a
> warning about conversions:
>=20
> uint16_t data1 =3D 1;
> uint16_t data2 =3D data1 + 1; // warning on possible overflow
>=20
> The reason is, in C++, when you perform arithmetic, the compiler is allow=
ed
> to up-cast for you to an int if it results in a performance improvement. =
So
Actually, the compiler is required to perform the cast to int, due to integ=
er=20
promotion rules. But the operation doesn't change either way.
If we performed the addition in 16-bit unsigned, the overflow is well defin=
ed=20
and adding 1 to 0xffff is expected and required to result in 0. If we perfo=
rm=20
the addition on 32-bit, then adding 1 to 0xffff results in 0x10000, which t=
hen=20
gets truncated to 16 bit in a well-defined form and also results in 0.
It's even the same in assembly:
movl $1, %reg1
addw %reg1w, %reg2w
and
movl $1, %reg1
addl %reg1, %reg2
Even if we started with %reg2 =3D 0xffff, the end result in %reg2w is 0. Th=
e=20
only difference is that the addw instruction would set the carry flag, wher=
eas=20
the addl instruction would clear it and set bit 16 on %reg2.
An important difference is performance. The addw instruction would leave th=
e=20
high 32 bits of %reg2 unchanged, which can cause a pipeline stall due to a=
=20
data dependency on what was there.
> Has there ever been a proposal to fix this? At least in our code, this on=
e
> fix would get rid of a LOT of gsl::narrow_casts as it seems to me the
> warning is a bit overkill as the programmer's intent is valid, it's the
> compiler doing wonky things.
There's nothing to be fixed, as far as the standard is concerned.
You have a QoI issue. Please talk to your compiler vendor.
--=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/1672903.oiJgXq1YU5%40tjmaciei-mobl1.
.
Author: rianquinn@gmail.com
Date: Wed, 19 Oct 2016 11:11:39 -0700 (PDT)
Raw View
------=_Part_160_352711224.1476900700105
Content-Type: multipart/alternative;
boundary="----=_Part_161_1873533064.1476900700105"
------=_Part_161_1873533064.1476900700105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Awesome, yeah that's what I wanted to clarify as others have blamed it on=
=20
the spec, so i wanted to get this clarified before reporting a bug.=20
Thanks,
- Rian
On Wednesday, October 19, 2016 at 12:09:17 PM UTC-6, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 18 de outubro de 2016 16:11:27 PDT rian...@gmail.com=
=20
> <javascript:> wrote:=20
> > Writing a hypervisor in C++, and at least on Intel that are a lot of=20
> things=20
> > that require 8 and 16 bit integers. To my surprise, this generates a=20
> > warning about conversions:=20
> >=20
> > uint16_t data1 =3D 1;=20
> > uint16_t data2 =3D data1 + 1; // warning on possible overflow=20
> >=20
> > The reason is, in C++, when you perform arithmetic, the compiler is=20
> allowed=20
> > to up-cast for you to an int if it results in a performance improvement=
..=20
> So=20
>
> Actually, the compiler is required to perform the cast to int, due to=20
> integer=20
> promotion rules. But the operation doesn't change either way.=20
>
> If we performed the addition in 16-bit unsigned, the overflow is well=20
> defined=20
> and adding 1 to 0xffff is expected and required to result in 0. If we=20
> perform=20
> the addition on 32-bit, then adding 1 to 0xffff results in 0x10000, which=
=20
> then=20
> gets truncated to 16 bit in a well-defined form and also results in 0.=20
>
> It's even the same in assembly:=20
>
> movl $1, %reg1=20
> addw %reg1w, %reg2w=20
>
> and=20
>
> movl $1, %reg1=20
> addl %reg1, %reg2=20
>
> Even if we started with %reg2 =3D 0xffff, the end result in %reg2w is 0. =
The=20
> only difference is that the addw instruction would set the carry flag,=20
> whereas=20
> the addl instruction would clear it and set bit 16 on %reg2.=20
>
> An important difference is performance. The addw instruction would leave=
=20
> the=20
> high 32 bits of %reg2 unchanged, which can cause a pipeline stall due to =
a=20
> data dependency on what was there.=20
>
> > Has there ever been a proposal to fix this? At least in our code, this=
=20
> one=20
> > fix would get rid of a LOT of gsl::narrow_casts as it seems to me the=
=20
> > warning is a bit overkill as the programmer's intent is valid, it's the=
=20
> > compiler doing wonky things.=20
>
> There's nothing to be fixed, as far as the standard is concerned.=20
>
> You have a QoI issue. Please talk to your compiler vendor.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
--=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/37a83997-8e2c-4da1-ad8d-cdf04b83c7cd%40isocpp.or=
g.
------=_Part_161_1873533064.1476900700105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Awesome, yeah that's what I wanted to clarify as other=
s have blamed it on the spec, so i wanted to get this clarified before repo=
rting a bug.=C2=A0<div><br></div><div>Thanks,</div><div>- Rian<br><br>On We=
dnesday, October 19, 2016 at 12:09:17 PM UTC-6, Thiago Macieira wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On ter=C3=A7a-feira, 18 de outubro =
de 2016 16:11:27 PDT <a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"EacRvLDtBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">rian...@gmail.com</a> wrote:
<br>> Writing a hypervisor in C++, and at least on Intel that are a lot =
of things
<br>> that require 8 and 16 bit integers. To my surprise, this generates=
a
<br>> warning about conversions:
<br>>=20
<br>> uint16_t data1 =3D 1;
<br>> uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible overflo=
w
<br>>=20
<br>> The reason is, in C++, when you perform arithmetic, the compiler i=
s allowed
<br>> to up-cast for you to an int if it results in a performance improv=
ement. So
<br>
<br>Actually, the compiler is required to perform the cast to int, due to i=
nteger=20
<br>promotion rules. But the operation doesn't change either way.
<br>
<br>If we performed the addition in 16-bit unsigned, the overflow is well d=
efined=20
<br>and adding 1 to 0xffff is expected and required to result in 0. If we p=
erform=20
<br>the addition on 32-bit, then adding 1 to 0xffff results in 0x10000, whi=
ch then=20
<br>gets truncated to 16 bit in a well-defined form and also results in 0.
<br>
<br>It's even the same in assembly:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0movl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$1, %reg1
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addw=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0%reg1w, %reg2w
<br>
<br>and
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0movl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$1, %reg1
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0%<wbr>reg1, %reg2
<br>
<br>Even if we started with %reg2 =3D 0xffff, the end result in %reg2w is 0=
.. The=20
<br>only difference is that the addw instruction would set the carry flag, =
whereas=20
<br>the addl instruction would clear it and set bit 16 on %reg2.
<br>
<br>An important difference is performance. The addw instruction would leav=
e the=20
<br>high 32 bits of %reg2 unchanged, which can cause a pipeline stall due t=
o a=20
<br>data dependency on what was there.
<br>
<br>> Has there ever been a proposal to fix this? At least in our code, =
this one
<br>> fix would get rid of a LOT of gsl::narrow_casts as it seems to me =
the
<br>> warning is a bit overkill as the programmer's intent is valid,=
it's the
<br>> compiler doing wonky things.
<br>
<br>There's nothing to be fixed, as far as the standard is concerned.
<br>
<br>You have a QoI issue. Please talk to your compiler vendor.
<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'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';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'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<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" 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/37a83997-8e2c-4da1-ad8d-cdf04b83c7cd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/37a83997-8e2c-4da1-ad8d-cdf04b83c7cd=
%40isocpp.org</a>.<br />
------=_Part_161_1873533064.1476900700105--
------=_Part_160_352711224.1476900700105--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Wed, 19 Oct 2016 16:12:20 -0300
Raw View
--94eb2c05b49ea420a3053f3c961e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 19, 2016 at 3:11 PM, <rianquinn@gmail.com> wrote:
> Awesome, yeah that's what I wanted to clarify as others have blamed it on
> the spec, so i wanted to get this clarified before reporting a bug.
>
Sorry for the spam to others. Could you please paste here the link to the
bugzilla entry so we could watch the issue and/or get assigned?
>
> Thanks,
> - Rian
>
> On Wednesday, October 19, 2016 at 12:09:17 PM UTC-6, Thiago Macieira wrot=
e:
>
>> On ter=C3=A7a-feira, 18 de outubro de 2016 16:11:27 PDT rian...@gmail.co=
m
>> wrote:
>> > Writing a hypervisor in C++, and at least on Intel that are a lot of
>> things
>> > that require 8 and 16 bit integers. To my surprise, this generates a
>> > warning about conversions:
>> >
>> > uint16_t data1 =3D 1;
>> > uint16_t data2 =3D data1 + 1; // warning on possible overflow
>> >
>> > The reason is, in C++, when you perform arithmetic, the compiler is
>> allowed
>> > to up-cast for you to an int if it results in a performance
>> improvement. So
>>
>> Actually, the compiler is required to perform the cast to int, due to
>> integer
>> promotion rules. But the operation doesn't change either way.
>>
>> If we performed the addition in 16-bit unsigned, the overflow is well
>> defined
>> and adding 1 to 0xffff is expected and required to result in 0. If we
>> perform
>> the addition on 32-bit, then adding 1 to 0xffff results in 0x10000, whic=
h
>> then
>> gets truncated to 16 bit in a well-defined form and also results in 0.
>>
>> It's even the same in assembly:
>>
>> movl $1, %reg1
>> addw %reg1w, %reg2w
>>
>> and
>>
>> movl $1, %reg1
>> addl %reg1, %reg2
>>
>> Even if we started with %reg2 =3D 0xffff, the end result in %reg2w is 0.
>> The
>> only difference is that the addw instruction would set the carry flag,
>> whereas
>> the addl instruction would clear it and set bit 16 on %reg2.
>>
>> An important difference is performance. The addw instruction would leave
>> the
>> high 32 bits of %reg2 unchanged, which can cause a pipeline stall due to
>> a
>> data dependency on what was there.
>>
>> > Has there ever been a proposal to fix this? At least in our code, this
>> one
>> > fix would get rid of a LOT of gsl::narrow_casts as it seems to me the
>> > warning is a bit overkill as the programmer's intent is valid, it's th=
e
>> > compiler doing wonky things.
>>
>> There's nothing to be fixed, as far as the standard is concerned.
>>
>> You have a QoI issue. Please talk to your compiler vendor.
>>
>> --
>> 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/37a83997-8e2c-4da1-
> ad8d-cdf04b83c7cd%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a83997-8e=
2c-4da1-ad8d-cdf04b83c7cd%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/CAFdMc-3wxK0-N5ByM8PiNGqaQRjAWadx6%2BrpjK9mC0YFw=
jkkqA%40mail.gmail.com.
--94eb2c05b49ea420a3053f3c961e
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 Wed, Oct 19, 2016 at 3:11 PM, <span dir=3D"ltr"><<a href=3D"mail=
to:rianquinn@gmail.com" target=3D"_blank">rianquinn@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Awesome, yeah t=
hat's what I wanted to clarify as others have blamed it on the spec, so=
i wanted to get this clarified before reporting a bug.=C2=A0</div></blockq=
uote><div><br></div><div>Sorry for the spam to others. Could you please pas=
te here the link to the bugzilla entry so we could watch the issue and/or g=
et assigned?</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><br></div><div>Thanks,</div><div>- Rian<br><br>=
On Wednesday, October 19, 2016 at 12:09:17 PM UTC-6, Thiago Macieira wrote:=
<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On ter=C3=A7=
a-feira, 18 de outubro de 2016 16:11:27 PDT <a rel=3D"nofollow">rian...@gma=
il.com</a> wrote:
<br>> Writing a hypervisor in C++, and at least on Intel that are a lot =
of things
<br>> that require 8 and 16 bit integers. To my surprise, this generates=
a
<br>> warning about conversions:
<br>>=20
<br>> uint16_t data1 =3D 1;
<br>> uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible overflo=
w
<br>>=20
<br>> The reason is, in C++, when you perform arithmetic, the compiler i=
s allowed
<br>> to up-cast for you to an int if it results in a performance improv=
ement. So
<br>
<br>Actually, the compiler is required to perform the cast to int, due to i=
nteger=20
<br>promotion rules. But the operation doesn't change either way.
<br>
<br>If we performed the addition in 16-bit unsigned, the overflow is well d=
efined=20
<br>and adding 1 to 0xffff is expected and required to result in 0. If we p=
erform=20
<br>the addition on 32-bit, then adding 1 to 0xffff results in 0x10000, whi=
ch then=20
<br>gets truncated to 16 bit in a well-defined form and also results in 0.
<br>
<br>It's even the same in assembly:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0movl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$1, %reg1
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addw=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0%reg1w, %reg2w
<br>
<br>and
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0movl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0$1, %reg1
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addl=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0%r<wbr>eg1, %reg2
<br>
<br>Even if we started with %reg2 =3D 0xffff, the end result in %reg2w is 0=
.. The=20
<br>only difference is that the addw instruction would set the carry flag, =
whereas=20
<br>the addl instruction would clear it and set bit 16 on %reg2.
<br>
<br>An important difference is performance. The addw instruction would leav=
e the=20
<br>high 32 bits of %reg2 unchanged, which can cause a pipeline stall due t=
o a=20
<br>data dependency on what was there.
<br>
<br>> Has there ever been a proposal to fix this? At least in our code, =
this one
<br>> fix would get rid of a LOT of gsl::narrow_casts as it seems to me =
the
<br>> warning is a bit overkill as the programmer's intent is valid,=
it's the
<br>> compiler doing wonky things.
<br>
<br>There's nothing to be fixed, as far as the standard is concerned.
<br>
<br>You have a QoI issue. Please talk to your compiler vendor.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/37a83997-8e2c-4da1-ad8d-cdf04b83c7cd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/37a8=
3997-8e2c-4da1-<wbr>ad8d-cdf04b83c7cd%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who's never wrong but always right?<br>Who'd never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAFdMc-3wxK0-N5ByM8PiNGqaQRjAWadx6%2B=
rpjK9mC0YFwjkkqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3wxK0-N5=
ByM8PiNGqaQRjAWadx6%2BrpjK9mC0YFwjkkqA%40mail.gmail.com</a>.<br />
--94eb2c05b49ea420a3053f3c961e--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 19 Oct 2016 13:07:31 -0700 (PDT)
Raw View
------=_Part_746_1887381144.1476907651587
Content-Type: multipart/alternative;
boundary="----=_Part_747_793360568.1476907651587"
------=_Part_747_793360568.1476907651587
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 19, 2016 at 11:09:17 AM UTC-7, Thiago Macieira wrote:
>
> Actually, the compiler is required to perform the cast to int, due to
> integer
> promotion rules. But the operation doesn't change either way.
>
>
The promotion to int is also very important to consider in avoiding a
certain case of undefined behavior:
std::uint16_t x = 0xFFFF;
x *= x;
Melissa
--
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/f7ec0f51-3d35-464f-b18f-d27f27d35ac3%40isocpp.org.
------=_Part_747_793360568.1476907651587
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 19, 2016 at 11:09:17 AM UTC-7, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Actually, the=
compiler is required to perform the cast to int, due to integer=20
<br>promotion rules. But the operation doesn't change either way.
<br>
<br></blockquote><div><br>The promotion to int is also very important to co=
nsider in avoiding a certain case of undefined behavior:<br><br>std::uint16=
_t x =3D 0xFFFF;<br>x *=3D x;<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f7ec0f51-3d35-464f-b18f-d27f27d35ac3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7ec0f51-3d35-464f-b18f-d27f27d35ac3=
%40isocpp.org</a>.<br />
------=_Part_747_793360568.1476907651587--
------=_Part_746_1887381144.1476907651587--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Oct 2016 16:02:52 -0700
Raw View
Em quarta-feira, 19 de outubro de 2016, =C3=A0s 13:07:31 PDT, Myriachan esc=
reveu:
> On Wednesday, October 19, 2016 at 11:09:17 AM UTC-7, Thiago Macieira wrot=
e:
> > Actually, the compiler is required to perform the cast to int, due to
> > integer
> > promotion rules. But the operation doesn't change either way.
>=20
> The promotion to int is also very important to consider in avoiding a
> certain case of undefined behavior:
>=20
> std::uint16_t x =3D 0xFFFF;
> x *=3D x;
Indeed, this causes a signed integer overflow, which is UB.
If you'd written:
x *=3D unsigned(x);
Then this is no longer UB.
--=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/3106991.qNzeP8ykmy%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 20 Oct 2016 03:06:22 +0300
Raw View
On 10/20/16 02:02, Thiago Macieira wrote:
> Em quarta-feira, 19 de outubro de 2016, =C3=A0s 13:07:31 PDT, Myriachan e=
screveu:
>> On Wednesday, October 19, 2016 at 11:09:17 AM UTC-7, Thiago Macieira wro=
te:
>>> Actually, the compiler is required to perform the cast to int, due to
>>> integer
>>> promotion rules. But the operation doesn't change either way.
>>
>> The promotion to int is also very important to consider in avoiding a
>> certain case of undefined behavior:
>>
>> std::uint16_t x =3D 0xFFFF;
>> x *=3D x;
>
> Indeed, this causes a signed integer overflow, which is UB.
>
> If you'd written:
>
> x *=3D unsigned(x);
>
> Then this is no longer UB.
I've always wondered why the language had allowed the implicit=20
conversion to int in such cases. I mean, if it didn't the implementation=20
could have compiled the code to use full-width 32-bit instructions and=20
then slice the result and have the same performance anyway. But that=20
wouldn't introduce problems like in the OP or the UB above.
--=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/2f77b3f0-eb09-537d-6590-59f4d68875c3%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Oct 2016 21:36:20 -0700
Raw View
Em quinta-feira, 20 de outubro de 2016, =C3=A0s 03:06:22 PDT, Andrey Semash=
ev=20
escreveu:
> >> std::uint16_t x =3D 0xFFFF;
> >> x *=3D x;
> >=20
> > Indeed, this causes a signed integer overflow, which is UB.
> >=20
> > If you'd written:
> > x *=3D unsigned(x);
> >=20
> > Then this is no longer UB.
>=20
> I've always wondered why the language had allowed the implicit
> conversion to int in such cases. I mean, if it didn't the implementation
> could have compiled the code to use full-width 32-bit instructions and
> then slice the result and have the same performance anyway. But that
> wouldn't introduce problems like in the OP or the UB above.
The reason it does that is that most architectures (especially the RISC one=
s)=20
can only execute operations on a single register width. So the standard say=
s=20
that any operation operates on rank of at least that of int/unsigned. Small=
er=20
types (types of lesser rank) are used only for storage.
Also, the OP didn't have a problem.
--=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/3723142.7QgTQKzj5h%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 20 Oct 2016 11:15:56 +0300
Raw View
On 10/20/16 07:36, Thiago Macieira wrote:
> Em quinta-feira, 20 de outubro de 2016, =C3=A0s 03:06:22 PDT, Andrey Sema=
shev
> escreveu:
>>>> std::uint16_t x =3D 0xFFFF;
>>>> x *=3D x;
>>>
>>> Indeed, this causes a signed integer overflow, which is UB.
>>>
>>> If you'd written:
>>> x *=3D unsigned(x);
>>>
>>> Then this is no longer UB.
>>
>> I've always wondered why the language had allowed the implicit
>> conversion to int in such cases. I mean, if it didn't the implementation
>> could have compiled the code to use full-width 32-bit instructions and
>> then slice the result and have the same performance anyway. But that
>> wouldn't introduce problems like in the OP or the UB above.
>
> The reason it does that is that most architectures (especially the RISC o=
nes)
> can only execute operations on a single register width. So the standard s=
ays
> that any operation operates on rank of at least that of int/unsigned. Sma=
ller
> types (types of lesser rank) are used only for storage.
That doesn't preclude what I suggested.
> Also, the OP didn't have a problem.
I think, warnings with an innocent looking code and having to sprinkle=20
casts everywhere is a problem. I faced this problem myself. The fact=20
that the warnings are the result of the behavior allowed by the standard=20
indicates that this is not entirely QoI. Integers are hard in C++, much=20
too hard IMO.
--=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/f1d5f4e5-4bfd-2780-7d25-57005ce69f4d%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 20 Oct 2016 08:01:49 -0700
Raw View
Em quinta-feira, 20 de outubro de 2016, =C3=A0s 11:15:56 PDT, Andrey Semash=
ev=20
escreveu:
> > The reason it does that is that most architectures (especially the RISC
> > ones) can only execute operations on a single register width. So the
> > standard says that any operation operates on rank of at least that of
> > int/unsigned. Smaller types (types of lesser rank) are used only for
> > storage.
>=20
> That doesn't preclude what I suggested.
I think it does. The point is that the operation is always done on int on=
=20
those machines, whether you want it or not (and RISC machines are still the=
=20
majority, despite my employer's best efforts). So the standard says that th=
e=20
compiler does not have to emulate whatever behaviour would be necessary for=
=20
lesser-ranked types.
I can't think of which operation would be different on 16-bit than on 32-bi=
t,=20
but that doesn't mean one doesn't exist.
> > Also, the OP didn't have a problem.
>=20
> I think, warnings with an innocent looking code and having to sprinkle
> casts everywhere is a problem. I faced this problem myself. The fact
> that the warnings are the result of the behavior allowed by the standard
> indicates that this is not entirely QoI. Integers are hard in C++, much
> too hard IMO.
Sorry, let me be stricter: the OP didn't have a problem relating to the=20
*standard*. Melissa dd point out a case where a problem would exist, but it=
=20
was not one found in the OP's original code. I also agree that there are so=
me=20
"gotchas" with integers in C++, some of them serious (like Melissa's exampl=
e).
--=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/10119166.50qj7pOthg%40tjmaciei-mobl1.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 27 Oct 2016 14:54:16 -0700 (PDT)
Raw View
------=_Part_998_1876683084.1477605257162
Content-Type: multipart/alternative;
boundary="----=_Part_999_794905172.1477605257162"
------=_Part_999_794905172.1477605257162
Content-Type: text/plain; charset=UTF-8
On Thursday, October 20, 2016 at 8:02:12 AM UTC-7, Thiago Macieira wrote:
> Indeed, this causes a signed integer overflow, which is UB.
>
> If you'd written:
>
> x *= unsigned(x);
>
> Then this is no longer UB.
>
>
I recommend a different solution, one that someone on Stack Overflow
pointed out:
x = 1u * x * x;
Then you don't have to worry about "unsigned" being of smaller size than
"decltype(x)". This promotes to the higher-ranked of "unsigned" and
"decltype(x)", both of which are unsigned.
I think it does. The point is that the operation is always done on int on
> those machines, whether you want it or not (and RISC machines are still
> the
> majority, despite my employer's best efforts). So the standard says that
> the
> compiler does not have to emulate whatever behaviour would be necessary
> for
> lesser-ranked types.
>
>
I like promotion as a concept, but to me, promoting from unsigned to signed
is broken behavior. It should stay the same signedness. But it's decades
too late to do anything about that.
> I can't think of which operation would be different on 16-bit than on
> 32-bit,
> but that doesn't mean one doesn't exist.
>
>
In 16-bit MS-DOS, my undefined behavior case is just:
std::uint8_t x = 0xFF;
x *= x;
Melissa
--
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/68b70c61-b235-46ef-8128-123f073f80ef%40isocpp.org.
------=_Part_999_794905172.1477605257162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 20, 2016 at 8:02:12 AM UTC-7, Thiago =
Macieira wrote:<br><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;=
">Indeed, this causes a signed integer overflow, which is UB.
<br>
<br>If you'd written:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x *=3D unsigned(x);
<br>
<br>Then this is no longer UB.
<br></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>=C2=A0</div></blockquote>
<br>I recommend a different solution, one that someone on Stack Overflow po=
inted out:<br><br>x =3D 1u * x * x;<br><br>Then you don't have to worry=
about "unsigned" being of smaller size than "decltype(x)&qu=
ot;.=C2=A0 This promotes to the higher-ranked of "unsigned" and &=
quot;decltype(x)", both of which are unsigned.<br><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">I think it does. The point is that the operati=
on is always done on int on=20
<br>those machines, whether you want it or not (and RISC machines are still=
the=20
<br>majority, despite my employer's best efforts). So the standard says=
that the=20
<br>compiler does not have to emulate whatever behaviour would be necessary=
for=20
<br>lesser-ranked types.
<br>
<br></blockquote><div><br>I like promotion as a concept, but to me, promoti=
ng from unsigned to signed is broken behavior.=C2=A0 It should stay the sam=
e signedness.=C2=A0 But it's decades too late to do anything about that=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I can't t=
hink of which operation would be different on 16-bit than on 32-bit,=20
<br>but that doesn't mean one doesn't exist.
<br>
<br></blockquote><div><br>In 16-bit MS-DOS, my undefined behavior case is j=
ust:<br>std::uint8_t x =3D 0xFF;<br>x *=3D x;<br><br>Melissa <br></div></di=
v>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/68b70c61-b235-46ef-8128-123f073f80ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68b70c61-b235-46ef-8128-123f073f80ef=
%40isocpp.org</a>.<br />
------=_Part_999_794905172.1477605257162--
------=_Part_998_1876683084.1477605257162--
.