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

21–30 of 40 posts

Re: When the Compiler Bites

#21

Post by enqk »

vardump wrote: post #18
unwind wrote: post #17

Earlier quoted context omitted.

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…

You might have encountered in the past is C/C++ silently promoting your floats to double.

An example, `printf("%f", float_value)` will actually promote float_value to a double. Or calling a function from `math.h` with a float constant

Re: When the Compiler Bites

#22

Post by Ded7xSEoPKYNsDd »

mar77i wrote: post #2

I was once told that optimizations in the sense of dead code elimination the way clang does it could be bypassed by making a variable volatile... Wouldn't that help here as well? volatile unsigned char *p = malloc(w * h); ...

The volatile modified on a pointer tells the compiler that reads and writes to it can have side-effects -- it is meant for memory-mapped hardware registers. Because of those (presumed) side-effects, reads and writes to that volatile pointer cannot be optimized away by dead code elimination.

Changing the address where such a variable points to, will still be optimized away when it isn't used later on.

Re: When the Compiler Bites

#23

Post by giomasce »

It strikes me that the System V amd64 ABI is not defined on such an (apparently) obvious point as padding of values smaller than a word. Is there a reason why it does not get fixed?

Re: When the Compiler Bites

#24

Post by dooglius »

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…

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

The calloc return value _is_ used, to calculate the return value.

Re: When the Compiler Bites

#25

Post by TheRealPomax »

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.

pointless, but not wrong: calloc on a zero width image should still yield a memory pointer, even if it points to a zero length stretch of memory. It would be strictly wrong to return a null pointer just because (one of) the dimensions happens to be zero.

It might read a little funny, but it's actually quite correct with respects to what the code path should be expected to do. Valid dimensions should yield a valid pointer. Even if they're validly zero =)

Re: When the Compiler Bites

#26

Post by kps »

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

What every computer scientist should know about floating-point arithmetic is readily available online.

Re: When the Compiler Bites

#28

Post by dooglius »

mar77i wrote: post #2

I was once told that optimizations in the sense of dead code elimination the way clang does it could be bypassed by making a variable volatile... Wouldn't that help here as well? volatile unsigned char *p = malloc(w * h); ...

Not quite, what you want is

  unsigned char * volatile p = malloc(w * h);
This indicates that p itself is a volatile variable, rather than a pointer to memory that is volatile.

Re: When the Compiler Bites

#30

Post by tom_ »

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 doubt I'm the only person a bit surprised to discover that the same literal float in source code won't always result in the same value in the program...
Post reply on HN