search for: undefinedness

There's another point that hasn't been raised yet here, which is that the undefinedness of calling (void*) 0 is a property of C, not necessarily of the LLVM abstract language. I think you can make an excellent case that the standard optimizations should not be enforcing C language semantics, or at least should allow such optimizations to be disabled. Case in point — calls/loads/st...

> Dale Johannesen wrote: >> Paul Schlie wrote: >>> Dale Johannesen wrote: >>>> Marius Wachtler wrote: >>>> ... >>>> The call to address 0 gets removed. >>>> >>>> define i32 @t(i32 %a) noreturn nounwind readnone { >>>> entry: >>>> unreachable >>>> } >>>>

...even so has no net effect: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml Somehow gcc3 sees these but everyone else including gcc4 fails. 6. Here llvm-gcc and gcc, but not clang, exploit undefinedness of integer overflow to eliminate most of the code in a function: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/82/82A5CC31.shtml Most likely this is not what the authors of the code intended, but the compilers are correct. 7. Cute elimination of useless varargs code: http://emb...

2009/6/10 John McCall <rjmccall at apple.com> > There's another point that hasn't been raised yet here, which is that > the > undefinedness of calling (void*) 0 is a property of C, not necessarily > of > the LLVM abstract language. I think you can make an excellent case that > the standard optimizations should not be enforcing C language semantics, > or at least should allow such optimizations to be disabled. All sorts o...

...://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml > > Somehow gcc3 sees these but everyone else including gcc4 fails. > > 6. > > Here llvm-gcc and gcc, but not clang, exploit undefinedness of integer > overflow to eliminate most of the code in a function: > > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/82/82A5CC31.shtml > > Most likely this is not what the authors of the code intended, but the > compilers are correct. LLVM doesn't handle correla...

On Jun 10, 2009, at 1:18 PM, Nick Lewycky wrote: > 2009/6/10 John McCall <rjmccall at apple.com> > There's another point that hasn't been raised yet here, which is that > the > undefinedness of calling (void*) 0 is a property of C, not necessarily > of > the LLVM abstract language. I think you can make an excellent case > that > the standard optimizations should not be enforcing C language > semantics, > or at least should allow such optimizations to be disabled....

...ortant performance implications in practice. Not for the kernel of course. Now we can endlessly debate how (non)practical it is to write HPC code in C or C++, but there we are. > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Perhaps if these undefinednesses wouldn't have been put into the standard, people wouldn't have written HPC code, and if that were so the world would be a nicer place sometimes (certainly for the compiler). Alas, it isn't. Ciao, Michael.

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf <markus at trippelsdorf.de> wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard C. > All these options also have a negative