<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">> The problem is that setting it bit-wise is platform dependent.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To expand on this slightly: This platform dependence includes config registers on the same processor. MIPS implementations often support both big and little-endian (selectable at boot time) which will write the halves of the double's in
opposite orders in the given example.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Sean Silva<br>
<b>Sent:</b> 01 July 2015 23:08<br>
<b>To:</b> Russell Wallace<br>
<b>Cc:</b> llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] C as used/implemented in practice: analysis of responses<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Jul 1, 2015 at 10:19 AM, Russell Wallace <<a href="mailto:russell.wallace@gmail.com" target="_blank">russell.wallace@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Your option 3 is the preferred way to handle your example, because it allows one to reason about the behaviour of the program. As a bonus, it does so without interfering in any way with optimisation.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The problem is that setting it bit-wise is platform dependent. For example, that concrete example (with 95 replaced by 94) would have padding after the char array depending on sizeof(long), so some of the stores might not even affect any
of the fields declared in the struct. So you're basically asking the compiler to do something pretty arbitrary and platform dependent, which is what it is already basically doing (minus a lot of the platform dependence). This is the sort of thing that I was
talking about upthread.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It could be argued that deleting the loop (which would lead to an obvious error immediately, with any basic testing) is better than a "works on my machine" situation where the latent bug is one due to bitwise layout differences -- I wouldn't
want to debug that. Obviously an intelligible static diagnosis of the situation is the ideal case, but doing so is a hard problem (and may be too noisy anyway).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What most users really want - and what many of them /expect/ even though it's currently not actually the case - is for C to behave like high-level assembly language, for code to translate straightforwardly into machine operations. Yes,
it would be nice to get consistent behaviour between compilers. But that's not going to happen. Failing that, given that there is no way to improve all compilers, improving one compiler would be much better than nothing.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Jul 1, 2015 at 5:58 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">On 1 July 2015 at 17:15, Russell Wallace <<a href="mailto:russell.wallace@gmail.com" target="_blank">russell.wallace@gmail.com</a>> wrote:<br>
> I'm proposing that LLVM unilaterally replace most undefined behaviour with<br>
> implementation-defined behaviour.<br>
<br>
That's precisely the problem. Which behaviour?<br>
<br>
Let's have an example:<br>
<br>
struct Foo {<br>
long a[95];<br>
char b[4];<br>
double c[2];<br>
};<br>
<br>
void fuzz(Foo &F) {<br>
for (int i=0; i<100; i++)<br>
F.a[i] = 123;<br>
}<br>
<br>
There are many ways I can do this "right":<br>
<br>
1. Only go up to 95, since you're using an integer to set the value.<br>
2. Go up to 96, since char is an integer type.<br>
2. Go all the way to 100, but casting "123" to double from 97 onwards, in pairs<br>
3. Go all the way to 100, and set integer 123 bitwise (for whatever fp<br>
representation that is) from 97<br>
4. Do any of above, and emit a warning<br>
5. Bail on error<br>
<br>
Compilers prefer not to bail on error, since the standard permits it.<br>
A warning would be a good thing, though.<br>
<br>
Now, since it's a warning, I *have* to output something. What? Even<br>
considering one compiler, you'll have to convince *most* <compilerX><br>
engineers to agree on something, and that's not trivial.<br>
<br>
Moreover, this loop is very easy to vectorise, and that would give me<br>
4x speed improvements for 4-way vectorization. That's too much for<br>
compilers to pass.<br>
<br>
If I create a vectorised loop that goes all the way to 92, I'll have<br>
to create a tail loop. If I don't want to create a tail loop, I have<br>
to override 'b' (and probably 'c') on a vector write. If I implement<br>
the variations where I can do that, the vectoriser will be very happy.<br>
People generally like when the vectoriser is happy.<br>
<br>
Now, you have a "safe mode" where these things don't happen. Let's say<br>
you and me agree that it should only go to 95, since this is "probably<br>
what the user wants". But some programmers *use* that as a feature,<br>
and the standard allow it, so we *have* to implement it *both*.<br>
<br>
Best case scenario, you have now implemented two completely different<br>
behaviours for every undefined behaviour in each standard. Worse<br>
still, you have divided the programmers in two classes: those that<br>
play it safe, and those that don't, essentially creating two different<br>
programming languages. Code that compiles and work with<br>
compilerA+safe_mode will not necessarily compile/work with<br>
compilerB+safe_mode or compilerA+full_mode either.<br>
<br>
C and C++ are already complicated enough, with so many standard levels<br>
to implement (C90, C99, C11, C++03, C++11, C++14, etc) that<br>
duplicating each and everyone of them, *per compiler*, is not<br>
something you want to do.<br>
<br>
That will, ultimately, move compilers away from each other, which is<br>
not what most users really want.<br>
<br>
cheers,<br>
--renato<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>