similar to: How and where optimizing of undefined behavior happens

Sean, Many thanks for taking the time to respond. I didn’t make myself clear, I will try to be brief... > On Jun 28, 2017, at 7:48 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 28, 2017 at 3:33 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Chandler, >

On Aug 22, 2008, at 9:34 AM, Chris Lattner wrote: > C has a way to express this: signed integers are defined to never > overflow, unsigned integers are defined to wrap gracefully on > overflow. And gcc has yet more fun in it: -fstrict-overflow Allow the compiler to assume strict signed overflow rules, depending on the language being compiled. For C

I use OpenSSH server on an embedded arm using GCC7 cross toolchain. I found that spamming connection attempts sometimes causes aborts in sshd. Upon getting this up in gdb I found that the pointer subtraction inside openbsd-compat/{strlcat.c,strlcpy.c} (and maybe elsewhere) causes the 32 bit pointer difference to wrap which triggers the abort because of the -ftrapv option. This example illustrates

Thanks! This is all very interesting, and tells me that LLVM has a way to go to fully support all of these capabilities (if that is the right thing to do, which isn't clear). OTOH, it looks like a lot of real-world software that is using LLVM already doesn't seem to be affected by the lack of them. Does anyone know of any C/C++ programs that require integer overflow on signed

Yes, the hairy-edges of undefined behaviour - UB is UB. It does mean that given: __attribute__((noinline)) int foo(int a, int b) { return a + b; } int bar1(int x) { return foo(x, INT_MIN); } int bar2(int x) { return x + INT_MIN; } 'bar1' and 'bar2' have different outcomes. However, I think that the new optimisation is neat and valid and I am not suggesting that it should

Hi Sanjoy, Yes these are C tests (from 'gcc.c-torture/execute'), and as I indicated in my original message, the tests are not valid because the behaviour is undefined. However, it was while investigating these new failures in these tests that I realised that this optimisation existed. The optimisation itself is perfectly valid, but it does mean that integer underflow will no longer be

On Aug 22, 2008, at 9:30 AM, Vikram S. Adve wrote: > In the general case, I think you have to be conservative about this > because programmers may deliberately want this kind of "wraparound" > behavior, e.g., with periodic boundary conditions. But 99.9% of > programs probably don't need that so it would be bad to penalize them > for this corner case. In such a

Chandler, where we disagree is in whether the current project is moving the issue forward. It is not. It is making the compiler more complex for no additional value. The current project is not based in evidence, I have asked for any SPEC benchmark that shows performance gain by the compiler taking advantage of “undefined behavior” and no one can show that. The current project

Not sure the semantics of "used" you propose is sufficient. AFAIU the proposal, "used" could only be used in cases where the function will always trigger UB if poison is passed as argument. The semantics of attributes is usually the other way around, since function calls need to have UB as strong as the worst behavior of the function. If a function may for some reason trigger

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

I think calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull deviate from other

> > > Message: 5 > Date: Tue, 25 Jul 2017 00:12:35 -0700 > From: Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> > Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, John Regehr >

> So, the pointer arguments of memcpy *shall* (a violation of a shall > clause is UB, per §4/2) have valid values, even though the function will > copy zero characters. This is true in C but the question was about LLVM intrinsics. Since the LangRef does not mention any such restriction, I would assume that memcpy(0,0,0) is not UB in LLVM. If it is UB then we must update the LangRef

On Oct 24, 2015, at 6:02 PM, Chris Lattner <clattner at apple.com> wrote: > > >> On Oct 23, 2015, at 7:43 PM, Matthew Fernandez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> On 21/10/15 00:15, Stephen Canon wrote: >>> Yup, this is UB. If you want to propose a patch, I would do something like the following: >>> >>> rep_t sign

Thanks for the confirmation, Steve. Your suggestion looks good to me, but I don't have an environment set up to build the test suite so it may take me a little while to get back to you with a validated patch. A bit of creative grepping yields the following that also look problematic to me: compiler-rt/test/builtins/Unit/absvsi2_test.c: expected = -expected;

Richard, I think adding the runtime undefined behavior checking and unifying the diagnostic output format is a great idea. This would probably be of interest to the LLVM Dev list as well. Anna. On Aug 10, 2012, at 7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like to make improvements to Clang's

Hi, There are cases where LLVM is able to detect some UB but clang is not. For example, unsigned int foo(unsigned int x) { int ret = 0; for(int i = 0; i <= 32; ++i) ret += x >> i; return ret; } When the loop is unrolled, LLVM InstructionSimplify will catch it and return a UNDEF value. How can we let LLVM report some warning message to help developers correct the error?

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

On 26/10/15 02:54, Joerg Sonnenberger wrote: > On Sun, Oct 25, 2015 at 06:46:48AM -0400, Steve Canon via llvm-dev wrote: >> On Oct 24, 2015, at 6:02 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> >>>> On Oct 23, 2015, at 7:43 PM, Matthew Fernandez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>>> On 21/10/15 00:15,