search for: n1570

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I wanted to say.  We know that programs like this

...strict y = x + N; *x = *y; } } Both Jeroen's and Hal's implementation (the intrinsic-based one) will say "NoAlias" for the accesses in assign2() but shouldn't x and y be in the same restrictness "bucket" since y is based on x? [1] http://port70.net/~nsz/c/c11/n1570.html#6.7.3.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200214/f91a6da6/attachment.html>

...2][y2] = nx2+y2 = 3*0+3=3 > > ``` > > > > Hence, the array elements `B[x1][y1]` and `B[x2][y2]` _can alias_, and > > so the transformation proposed in `ex1_opt` is unsound in general. > > I'm unsure your example actually showcases the problem: > > C standard, N1570 draft, Page 560, Appendix J.2 Undefined Behavior: > > An array subscript is out of range, even if an object is apparently > accessible with the given subscript (as in the lvalue expression a[1][7] > given the declaration inta[4][5]) (6.5.6). GEP requires an array type, which in LLVM h...

...} > } > > Both Jeroen's and Hal's implementation (the intrinsic-based one) will say > "NoAlias" for the accesses in assign2() but shouldn't x and y be in the > same restrictness "bucket" since y is based on x? > > [1] http://port70.net/~nsz/c/c11/n1570.html#6.7.3.1 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__port70.net_-7Ensz_c_c11_n1570.html-236.7.3.1&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-OSzxlGOXXSfAvOLT6E8iPwwJk&m=xMDqkSAlj-YCOS4JMDXAENpBS-eaCcLYSkIm1qK68fs&s=B3LRzqpd9bD1724nvhG0FtpFh3QPsQ4F...

On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote: > On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> A problem arises, and I am not sure if it is really a problem or just >> weird C-compliant behavior. >> >> int a; // or, equally, int a=0; >> >> int main(){ >> int b; >> if

...ealloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard <https://port70.net/~nsz/c/c11/n1570.html#6.2.4p2> we have: "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime" Is this enough to infer that we can safely mark realloc as noalias? -- Regards Bhatu -------------- next part -------------- An HTML atta...

...---------------- > Yes, gcc should assume p and q point to anything, however, the result contradict to the assumption -- > It promote the p->x expression. Assuming above is C11 code, I think the relevant section in the C spec is the following: This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into a...

...gcc should assume p and q point to anything, however, the result contradict to the assumption -- >> It promote the p->x expression. > > > Assuming above is C11 code, I think the relevant section in the C spec is the following: > > This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into a...

On 07/02/2015 04:44 PM, David Keaton wrote: > On 07/02/2015 03:17 AM, Kuperstein, Michael M wrote: >> You want to redefine ["won't break the program"], by specifying a new >> abstract machine, which is >> more conservative than standard C/C++. The proper way to do that would, >> I believe, be to work towards setting up a working group within the >>

...ume p and q point to anything, however, the result contradict to the assumption -- >>> It promote the p->x expression. >> >> Assuming above is C11 code, I think the relevant section in the C spec is the following: >> >> This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into a...

> On 08 Apr 2015, at 19:25, James <lista at xdrv.co.uk> wrote: > > On 08/04/2015 15:24, J?rgen Obermann wrote: > > Hello J?rgen, > >> here are two problems I get when I compile dovecot 2.2.16 under Solaris >> 10 with Studio 11 Compiler: > > Is there a reason to use a 10 year old compiler? Try 12.4: > >

> The program I gave was well typed :) Hi, Daniel: Thank you for sharing your insight. I didn't realized it is well-typed -- I'm basically a big nut of any std. I'd admit std/spec is one of the most boring material on this planet:-). So, if I understand correct, your point is: if a std call a type-casting (could be one which is in bad-taste:-), TBAA has to

...ter ptr (unless another allocation function happened to > result in a pointer value equal to ptr) > > This seems to suggest that there is no UB... However, I couldn't find the > corresponding line or relevant part on latest C std, > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf > > Regards, > Kevin > > On Tue, Apr 11, 2017 at 4:27 PM, Sanjoy Das <sanjoy at playingwithpointers. > com> wrote: > >> Hi Kevin, >> >> On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: >> > So only "non-freed&...

...to look at https://msdn.microsoft.com/fr-fr/library/f9ezhzhs(v=vs.110).aspx is useless, because R on windows uses Mingw-W64 integer types and not the MS version. Then, I tried to find information in such as Write Portable Code by Brian Hook and C11 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). They do recommend to use the macro SCNu64 (reserved for scanf family) rather than PRIu64 reserved for printf family functions. Unfortunately when I check the package with R-devel, I still have the warning. On GitHub, there are a version of mingw64 sources : https://github.com/Alexpux/ming...

FWIW Microsoft provides evaluation version of Windows that can be easily installed using VirtualBox and runs for 180 days. One that I believe is the closest to the CRAN setup (Windows 2008) is: https://www.microsoft.com/en-nz/download/details.aspx?id=11093 You just tell VB to setup a Windows 2008 VM then, select the downloaded ISO as CD-ROM drive and install from it. The installation is fairly

Hello, We would like to begin discussions around a new set of intrinsics, to better express multi-dimensional array indexing within LLVM. The motivations and a possible design are sketched out below. Rendered RFC link here <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> Raw markdown: # Introducing a new multidimensional array indexing intrinsic ## The