Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When the Compiler Bites

nullprogram.com

Post reply on HN
Print view View original

11–20 of 40 posts

Re: When the Compiler Bites

#11

Post by tom_ »

unwind wrote: post #3

This was interesting, but I don't get this part of the example code: if (w == 0 || h To me, that condition is just super-strange: if w is zero, the product w x h is zero too, so the entire allocation becomes pointless. Surely it should be: if (w != 0 && h or something? Having these kinds of discussions based on code that is confusing in itself just becomes too much, for me.

malloc(0) is implementation-defined: https://port70.net/~nsz/c/c11/n1570.html#7.22.3p1

One might, I suppose, decide that new_image will be exactly equivalent to the system malloc in this respect, in which case malloc(0) should be called when appropriate.

Re: When the Compiler Bites

#12

Post by vardump »

GCC float comparison: since C doesn't have a portable way to denote single precision float constants, it's a good idea to cast them in order to avoid implementation specific differences. See: https://godbolt.org/g/t7UYoi

  int
  float_compare(void)
  {
      float x = 1.3f;
      return x == (float) 1.3f;
  }
This correctly returns 1 on all compilers I cared to check.

Couldn't reproduce clang calloc removal bug with that code. Tried clang 6.0, -O1, -O3.

Clang did remove calloc when there were no new_image calls where parameter "shade" could be zero. But that's to be expected, as it is a static function, only accessible from same compilation unit. Entirely correct behavior.

https://godbolt.org/g/FfV7G2

When it comes to the filed clang bug, I fail to see any bug at all: https://bugs.llvm.org/show_bug.cgi?id=37304

When calloc return value is not stored (or used), how could it be accessed or even freed at all? I think compiler is right to remove whole call.

Re: When the Compiler Bites

#13

Post by _pmf_ »

maccard wrote: post #9

I’m amazed that we still have people being bitten by exact floating point comparisons in 2018 really. Nobody working with floating point numbers should be surprised by the behaviour in the post. This article [0] is over 6 years old and is a follow up from I don’t know when, talking about this exact subject. [0] https://randomascii.wordpress.com/2012/02/25/comparing-float...

1st/2nd semester stuff, but requesting a CS degree or equivalent qualification is against the SJW agenda.

Re: When the Compiler Bites

#14

Post by mannykannot »

maccard wrote: post #9

I’m amazed that we still have people being bitten by exact floating point comparisons in 2018 really. Nobody working with floating point numbers should be surprised by the behaviour in the post. This article [0] is over 6 years old and is a follow up from I don’t know when, talking about this exact subject. [0] https://randomascii.wordpress.com/2012/02/25/comparing-float...

I think the point here is to provide an example showing how different compilers implement certain aspects of source code. There is no implication that you should be able to depend on exact floating-point comparisons in programs.

We avoid depending on exact floating-point comparisons, not because of any inherent indeterminism in that comparison, but because it does not generally yield exactly what our algorithm needs.

Re: When the Compiler Bites

#15

Post by bloat »

maccard wrote: post #9

I’m amazed that we still have people being bitten by exact floating point comparisons in 2018 really. Nobody working with floating point numbers should be surprised by the behaviour in the post. This article [0] is over 6 years old and is a follow up from I don’t know when, talking about this exact subject. [0] https://randomascii.wordpress.com/2012/02/25/comparing-float...

The first example is about optimizing away multiplication by zero. The second is about GCC treating float literals with greater than float precision, and the third is about dead code elimination.

Not convinced your comment is relevant.

Re: When the Compiler Bites

#16

Post by LandR »

maccard wrote: post #9

I’m amazed that we still have people being bitten by exact floating point comparisons in 2018 really. Nobody working with floating point numbers should be surprised by the behaviour in the post. This article [0] is over 6 years old and is a follow up from I don’t know when, talking about this exact subject. [0] https://randomascii.wordpress.com/2012/02/25/comparing-float...

You'd be surprised how many devs nowadays still have no idea about floating point numbers.

Re: When the Compiler Bites

#17

Post by unwind »

vardump wrote: post #12

GCC float comparison: since C doesn't have a portable way to denote single precision float constants, it's a good idea to cast them in order to avoid implementation specific differences. See: https://godbolt.org/g/t7UYoi int float_compare(void) { float x = 1.3f; return x == (float) 1.3f; } This correctly returns 1 on all compilers I cared to check. Couldn't reproduce clang calloc removal bug with that code. Tried cla…

Can you clarify this part:

[...] since C doesn't have a portable way to denote single precision float constants [...]

That sounds like the suffix 'f' which you're also using, how is that not a way to "denote single precision float constants"?

My draft copy of the C11 spec says:

An unsuffixed floating constant has type double. If suffixed by the letter f or F, it has type float. If suffixed by the letter l or L, it has type long double.

But this is not new syntax, I just looked in the most recent document I have.

Do you mean that C doesn't have a way to require IEEE 754 floating-point?

Re: When the Compiler Bites

#18

Post by vardump »

unwind wrote: post #17
vardump wrote: post #12

GCC float comparison: since C doesn't have a portable way to denote single precision float constants, it's a good idea to cast them in order to avoid implementation specific differences. See: https://godbolt.org/g/t7UYoi int float_compare(void) { float x = 1.3f; return x == (float) 1.3f; } This correctly returns 1 on all compilers I cared to check. Couldn't reproduce clang calloc removal bug with that code. Tried cla…

Can you clarify this part: [...] since C doesn't have a portable way to denote single precision float constants [...] That sounds like the suffix 'f' which you're also using, how is that not a way to "denote single precision float constants"? My draft copy of the C11 spec says: An unsuffixed floating constant has type double. If suffixed by the letter f or F, it has type float. If suffixed by the letter l or L, it ha…

See edit below. C99 allows greater precision than required by the type!

Hmm, you're right.

I think something similar bit me long ago and left me under impression f-suffix for a float is not portable.

Perhaps it's time to read the standard through once again...

Then again, explicit casts generate code that works on all compilers, standards compliant or not.

Edit: C99, 6.3.1.8.2: "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby."

So I guess explicit floating point casts are needed when explicit operations are wanted!

Re: When the Compiler Bites

#19

Post by pubby »

vardump wrote: post #12

GCC float comparison: since C doesn't have a portable way to denote single precision float constants, it's a good idea to cast them in order to avoid implementation specific differences. See: https://godbolt.org/g/t7UYoi int float_compare(void) { float x = 1.3f; return x == (float) 1.3f; } This correctly returns 1 on all compilers I cared to check. Couldn't reproduce clang calloc removal bug with that code. Tried cla…

Regarding calloc, the issue is this:

- Since C++14, SIZE_MAX is the maximum size of any valid object; any object larger is ill-formed.

- calloc(SIZE_MAX, SIZE_MAX) is an attempt at creating an invalid object of size SIZE_MAX^2.

- Thus, calloc(SIZE_MAX, SIZE_MAX) should always return null. Shouldn't it?

Compilers often remove malloc calls even if the allocated object is modified and freed. But they shouldn't change the program's visible semantics.

Re: When the Compiler Bites

#20

Post by vardump »

pubby wrote: post #19
vardump wrote: post #12

GCC float comparison: since C doesn't have a portable way to denote single precision float constants, it's a good idea to cast them in order to avoid implementation specific differences. See: https://godbolt.org/g/t7UYoi int float_compare(void) { float x = 1.3f; return x == (float) 1.3f; } This correctly returns 1 on all compilers I cared to check. Couldn't reproduce clang calloc removal bug with that code. Tried cla…

Regarding calloc, the issue is this: - Since C++14, SIZE_MAX is the maximum size of any valid object; any object larger is ill-formed. - calloc(SIZE_MAX, SIZE_MAX) is an attempt at creating an invalid object of size SIZE_MAX^2. - Thus, calloc(SIZE_MAX, SIZE_MAX) should always return null. Shouldn't it? Compilers often remove malloc calls even if the allocated object is modified and freed. But they shouldn't change th…

> Compilers often remove malloc calls even if the allocated object is modified and freed. But they shouldn't change the program's visible semantics.

What visible side effects there are for an allocation with an unused return value pointer (cast to a boolean)? There's no way to reference said memory, so there's no way it can affect execution of the abstract program.

If the allocation succeeded, there's no way to free the memory in any case. So even ignoring possible concurrent allocations elsewhere, it's useless for checking whether future malloc can succeed. Unless, of course, I missed something obvious.

Post reply on HN