search for: subclaus

...n 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 pow(-Inf, 0.5), which is specified by C17 subclause F.10.4.4 as having a result of +Inf (indicating an exact result for the operation and, since IEEE Std 754-2008 subclause 9.1.1 states that domain errors are to be indicated by a Na...

...qrt 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 pow(-Inf, 0.5), which is specified by C17 >> subclause F.10.4.4 as having a result of +Inf (indicating an exact result >> for the operation and, since IEEE Std 754-2008 subclause 9.1.1 states that >> domai...

...t 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 pow(-Inf, 0.5), which is >>>> specified by C17 subclause F.10.4.4 as having a result of +Inf (indicating >>>> an exact result for the operation and, since IEEE Std 754-2008 subclause >>...

...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 as nan. > > Reid. In IEEE Std 754-1985, subclause 7.2- Division by Zero, it says: /"If the divisor is zero and the dividend is a finite nonzero number, then the division by zero shall be signaled. The result, when no trap occurs, shall be a correctly signed (infinity symbol)(6.3)." /So LLVM is correct (assuming it handles signs corr...

...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?

...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 as nan. >> >> Reid. > > In IEEE Std 754-1985, subclause 7.2- Division by Zero, it says: > > /"If the divisor is zero and the dividend is a finite nonzero number, > then the division by zero shall be signaled. The result, when no trap > occurs, shall be a correctly signed (infinity symbol)(6.3)." > > /So LLVM is correct (as...

...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 understan...

...is pretty much wrong. You probably mean >> "necessary for a reasonable interpretation" or something. >> >> Because we would be *functionally correct* by the standard by destroying >> the program if you ever read the member you didn't set :) >> > C11 subclause 6.5.2.3 paragraph 3, has in footnote 95: > If the member used to read the contents of a union object is not the same > as the member last used to store a value in the object, the appropriate > part of the object representation of the value is reinterpreted as an > object representation...

> > 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.

...d 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 as nan. >>> >>> Reid. >> >> In IEEE Std 754-1985, subclause 7.2- Division by Zero, it says: >> >> /"If the divisor is zero and the dividend is a finite nonzero number, >> then the division by zero shall be signaled. The result, when no trap >> occurs, shall be a correctly signed (infinity symbol)(6.3)." >> >>...

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....

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. &gt...

...t;>> "necessary for a reasonable interpretation" or something. >>>> >>>> Because we would be *functionally correct* by the standard by >>>> destroying the program if you ever read the member you didn't set :) >>>> >>> C11 subclause 6.5.2.3 paragraph 3, has in footnote 95: >>> If the member used to read the contents of a union object is not the >>> same as the member last used to store a value in the object, the >>> appropriate part of the object representation of the value is reinterpreted >>...