similar to: [LLVMdev] LLVMdev Digest, Vol 76, Issue 43

On 10/25/2010 6:31 PM, Peter Lawrence wrote: >> The above logic makes sense when you're talking about non-volatile >> loads >> and stores. To me, it doesn't make sense for volatile loads and >> stores. >> >> The whole point of volatile is to tell the compiler that its >> assumptions >> about how memory works doesn't apply to this load or

On Oct 25, 2010, at 5:13 PMPDT, Kenneth Boyd wrote: > On 10/25/2010 6:31 PM, Peter Lawrence wrote: >> >> Your objection is like saying that it isn't kosher to ignore the >> "register" keyword, because >> "I know what I am doing and you don't.....". > What isn't kosher, is making side effects disappear from a C program. > >

>> >> Your objection is like saying that it isn't kosher to ignore the >> "register" keyword, because >> "I know what I am doing and you don't.....". > What isn't kosher, is making side effects disappear from a C program. > > Kenneth > Ken, to have a valid complaint you have to demonstrate a program that behaves

On 10/25/2010 7:33 PM, Dale Johannesen wrote: > On Oct 25, 2010, at 5:13 PMPDT, Kenneth Boyd wrote: >> On 10/25/2010 6:31 PM, Peter Lawrence wrote: >>> Your objection is like saying that it isn't kosher to ignore the >>> "register" keyword, because >>> "I know what I am doing and you don't.....". >> What isn't kosher, is

On Mon, Oct 25, 2010 at 10:52 AM, John Criswell <criswell at illinois.edu> wrote: > On 10/25/10 10:43 AM, Duncan Sands wrote: >> Hi John, >> >>> As for instructions, I don't know of an instruction which does nothing, >>> won't be removed by optimization, and yet does not inhibit >>> optimization.  Perhaps a local alloca and a volatile load or

On 10/26/10 3:11 AM, Duncan Sands wrote: > Hi Torok, > >>>> Well...strictly as LLVM IR I find externally visible incorrect >>>> behavior unlikely, it's just a "different definition". For C and >>>> C++, I'd be looking at more complicated variations of >>>> >>>> int main() >>>> { >>>>

Hi Torok, >>> Well...strictly as LLVM IR I find externally visible incorrect >>> behavior unlikely, it's just a "different definition". For C and >>> C++, I'd be looking at more complicated variations of >>> >>> int main() >>> { >>> volatile int i = 1; >>> return 0; >>> } >>>

Hi all. I've recently uploaded a package (bnlearn) to CRAN. It builds fine on both Linux (32 and 64 bit) and Windows, but fails on MacOSX ix86 because of C90 vs C99 issues: http://www.r-project.org/nosvn/R.check/r-patched-macosx-ix86/bnlearn-00install.html Since I've no MacOSX machine at hand, I would like to ask you: why is C99 not the default for gcc on MacOSX ix86? Is it safe to

On 11/14/2012 2:22 AM, Shuxin Yang wrote: > I do some google, I cannot find the answer... > I check C std, I cannot find answer either. The C++11 standard explicitly allows compilers to assume that all loops will eventually terminate: [intro.multithread] 24: The implementation may assume that any thread will eventually do one of the following: — terminate, — make a call to a library I/O

I agree, this is a bug. John On 6/7/19 11:48 AM, JF Bastien via llvm-dev wrote: > > >> On Jun 5, 2019, at 2:28 PM, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> I don’t see any particular reason to guarantee that a volatile

Hi Kenneth, > Well...strictly as LLVM IR I find externally visible incorrect behavior > unlikely, it's just a "different definition". For C and C++, I'd be > looking at more complicated variations of > > int main() > { > volatile int i = 1; > return 0; > } > > It's clear that the LLVM IR representation of i cannot be simply >

> This is a matter of presentation, but some of the "GCC extensions" are > standard C99 (now, at least). I noticed long long, C++-style comments > and designated initializers. > > I have plenty of complaints about the GCC documentation you're > pointing at, but this probably isn't the right forum for that. I do > think dropping "as fast as

On Tue, 26 Oct 2010 10:00:32 +0200 Duncan Sands <baldrick at free.fr> wrote: > Hi Kenneth, > > > Well...strictly as LLVM IR I find externally visible incorrect > > behavior unlikely, it's just a "different definition". For C and > > C++, I'd be looking at more complicated variations of > > > > int main() > > { > >

> On Jun 11, 2019, at 6:27 AM, Guillaume Chatelet <gchatelet at google.com> wrote: > > I spent some time reading the C standard <https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf>: > > 5.1.2.3 Program execution > 2. Accessing a volatile object, modifying an object, modifying a file, or calling

Daveed: Perhaps I am looking at the wrong version of the specification. Section 5.1.2.3 appears to refer to objects having volatile-qualified type. The type of malloc() is not volatile qualified in the standard library definition. In general, calls to procedures that are outside the current unit of compilation are presumed to involve side effects performed in the body of the external procedure

On Tue, Jun 9, 2015 at 12:32 PM, David Majnemer <david.majnemer at gmail.com> wrote: > 'load volatile i32 addrspace(1)* null' seems fine to me. However, it > looks like instcombine will turn: > define i32 @foo() { > entry: > %std_ld.i = load volatile i32, i32 addrspace(1)* null > ret i32 %std_ld.i > } > > into: > define i32 @foo() { > entry:

While doing a make on the recently checkout version: I got the following errors: [ 68%] Built target dd [ 68%] Built target compiler-rt-headers [ 68%] Building C object projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/floatdidf.c.o In file included from /home/tthtlc/llvm/llvm/projects/compiler-rt/lib/builtins/x86_64/floatdidf.c:9:0:

On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote: > Daveed: > > Perhaps I am looking at the wrong version of the specification. > Section > 5.1.2.3 appears to refer to objects having volatile-qualified type. > The > type of malloc() is not volatile qualified in the standard library > definition. More importantly, malloc() is not specified to access a volatile

libFLAC has several places like this: if(0 == (ptr = realloc(ptr, size))) return false; which results in memory leaks if realloc fails (the old value of ptr is lost). The patch should fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: realloc_memleak_fix.patch Type: application/octet-stream Size: 6272 bytes Desc: not available Url :

I do some google, I cannot find the answer... I check C std, I cannot find answer either. Delete infinite empty loop is boring, but if C/C++ lawyers could tell it is safe to to so, it would obviate the need to prove a non-countable loop infinite or not before DCE can delete it. That is the answer I'm waiting for to delete a disgusting dead non-countable loop in my way. On 11/14/2012