<div dir="ltr"><div>[CC bollu, mferguson, shil]</div><div dir="ltr"><br></div><div dir="ltr">Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour <<a href="mailto:bmahjour@ca.ibm.com">bmahjour@ca.ibm.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p><font size="2">Thanks David and Michael for the clarification. </font><br><br><font size="2">I think I understand the rational behind those checks in delinearization now.</font><br><br><tt><font size="2">> Some other languages have stronger guarantees about their array dimensions accesses being in range. But this being a flat C array, there is nothing out-of-bounds going on.</font></tt><br><br><font size="2">Hmm...perhaps some information about these guarantees can come from the IR that the front-ends produce. I'm wondering if the 'inrange' keyword (or maybe a new keyword) can be used for this purpose? </font></p></div></blockquote><div><br></div><div>If the source is C/C++, the inrange keyword cannot be used because of the language's semantics (see below).</div><div><br></div><div>Also, GetElementPtr will always only work with constant-sized array. A student from last year's GSoC (CC'd) is working on such an extension (with intended use by Chapel). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p><font size="2">I had a discussion about this syntax with some C standard experts and there seems to be disagreements on whether an out-of-bound access with respect to an individual dimension is defined behaviour or not. I do not mean to start that discussion here, especially because there may be code in the field relying on certain interpretation of the standard, but just want to mention that option-control maybe a good way to deal with complications like this.</font><br></p></blockquote><div><br></div><div>For clarification: In C, subscripts themselves have no semantics, they are defined as syntactic sugar:</div><div><br></div><div>C18, 6.5.2.1, 
§2</div><div><font face="arial, sans-serif"><span style="left: 144px; top: 1228.18px;">> The definition of the subscript operator</span><span style="left: 655.735px; top: 1228.53px;">[] </span><span style="left: 677.88px; top: 1228.18px;">is that </span><span style="left: 726.727px; top: 1228.53px;">E1[E2] </span><span style="left: 784.857px; top: 1228.18px;">is identical</span> <span style="left: 128.127px; top: 146.095px;">to</span><span style="left: 145.898px; top: 146.445px;">(</span><span style="left: 154.895px; top: 149.433px;">*</span><span style="left: 163.892px; top: 146.445px;">((E1)+(E2)))</span></font><br></div><div><br></div><div>Using arithmetic properties, &A[1][0] == (char*)A + 2 == &A[0][2] (for an array declared "<i>char</i> A[2][2]"). The indirection operator (*) is only undefined if it yields to an access to an invalid address (C18, note 104).</div><div><br></div><div>Michael</div><div> </div></div></div>