search for: subclauses

The transformation in LibCallSimplifier::replacePowWithSqrt with respect to -Inf uses a select instruction, which based on the observed behaviour, incorporates the side effects of the unchosen branch. This means that (for pow) a call to sqrt(-Inf) is materialized. Such a call is specified as having a domain error (C17 subclause 7.12.7.5) since the operand is less than zero. Contrast this with

On Mon, Sep 14, 2020 at 12:45 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, that looks like a bug. The transform is ok in general for negative > numbers, but -Inf is a special-case for pow(), right? > If so, we probably need an extra check of the input with > "isKnownNeverInfinity()". > There is an extra check there already, but it uses

Sorry - I misread your example and the problem. I see now where LibCallSimplifier creates the select...but we are immediately erasing that select with the code from the godbolt example. Does the real motivating case have no uses of the pow() result value? On Mon, Sep 14, 2020 at 1:03 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, I mean just bail out on the transform in >

Reid Spencer wrote: > On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: > >> Hello, I have a question about the constant folding for fdiv instructions. >> For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I >> think this should be nan. Can anyone tell me why it is not nan? >> > > I think the specification says that it is

...eader inclusion. >> >> Neil. > > What section of the C standard do I need to refresh myself on here? > Good question (referring to the original question). The answer appears to be 7.1.3/1, fourth bullet: "All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage." Daveed

On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > Jonathan S. Shapiro wrote:- > > Is there a requirement somewhere in the C *Language* Specification that > > ties all of this together in the required way? > > Reserved identifiers and header inclusion. > > Neil. What section of the C standard do I need to refresh myself on here?

Jeff Cohen wrote: > Reid Spencer wrote: >> On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: >> >>> Hello, I have a question about the constant folding for fdiv instructions. >>> For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I >>> think this should be nan. Can anyone tell me why it is not nan? >>>

...tion > >>> that > >>> ties all of this together in the required way? > > Good question (referring to the original question). The answer > appears to be 7.1.3/1, fourth bullet: > > "All identifiers with external linkage in any of the following > subclauses (including the future library directions) are always > reserved for use as identifiers with external linkage." First, thank you. I apologize if I have been acting like a language lawyer, but I'm about to be working on static analysis tools and I'm discovering that my understandi...

On Mon, Feb 13, 2017 at 10:07 AM, Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Mon, Feb 13, 2017 at 2:23 AM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >>> I don't think this fully solves the problem -- you'll also need to fix >>> getMostGenericTBAA. That is, even if you implement the above scheme,

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

[CC bollu, mferguson, shil] Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour < bmahjour at ca.ibm.com>: > Thanks David and Michael for the clarification. > > I think I understand the rational behind those checks in delinearization > now. > > > Some other languages have stronger guarantees about their array > dimensions accesses being in range. But this being

> > > I don't think this fully solves the problem -- you'll also need to fix > getMostGenericTBAA. That is, even if you implement the above scheme, > say you started out with: > > union U { > int i; > float f; > }; > > float f(union U *u, int *ii, float *ff, bool c) { > if (c) { > *ii = 10; > *ff = 10.0; > } else { >

On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: > Hello, I have a question about the constant folding for fdiv instructions. > For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I > think this should be nan. Can anyone tell me why it is not nan? I think the specification says that it is "undefined" so any value will do. inf is just as undefined

If I copy or set zero bytes with memcpy(), memmove(), or memset(), can the <dest> and <src> arguments be null? Can they be invalid pointers? Regards, Jon

Hello, I have a question about the constant folding for fdiv instructions. For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I think this should be nan. Can anyone tell me why it is not nan? Thanks. Leo _________________________________________________________________ Exercise your brain! Try Flexicon.

Jeff Cohen wrote: > Jeff Cohen wrote: >> Reid Spencer wrote: >>> On Thu, 2007-03-22 at 15:50 -0700, leo han wrote: >>> >>>> Hello, I have a question about the constant folding for fdiv instructions. >>>> For the instruction "fdiv double 0.0, 0.0", the folded result is inf. I >>>> think this should be nan. Can anyone tell

v2: - Moved the btrfs available test into the subclause where it is used. Note I got tired of fighting emacs indentation mode and I pushed a whitespace only patch which fixes the indentation to be 4 spaces instead of 2 spaces: https://github.com/libguestfs/libguestfs/commit/df54c75d4c53ed580e5269306e11e0758d169452 This v2 patch requires that one. Rich.

Hi all, when I call the llvm.memcpy/memmove/memset.* intrinsics, typically I have to pass in valid (non-dangling, non-NULL pointers) of the given alignment. However, to what extent to these rules apply when the count is 0? Concretely (for any variant of the three aforementioned intrinsics): Is it UB to call them on a dangling pointer when count is 0? On a pointer of less than the given

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison macros > that facilitate writing > efficient code that accounts for NaNs without suffering the > ‘‘invalid’’ floating-point exception. >...

On Tue, Feb 14, 2017 at 5:51 AM, Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Mon, Feb 13, 2017 at 10:39 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Mon, Feb 13, 2017 at 10:07 AM, Hubert Tong < >> hubert.reinterpretcast at gmail.com> wrote: >> >>> On Mon, Feb 13, 2017 at 2:23 AM, Daniel