Live data from Hacker News

When the Compiler Bites

nullprogram.com

1–10 of 40 posts

Re: When the Compiler Bites

#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);
    ...

Re: When the Compiler Bites

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

Re: When the Compiler Bites

#4
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); ...

I tested it. It doesn't help on Clang.

Re: When the Compiler Bites

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

You're right. The way you wrote is how I would have too. Author has written it weirdly.

Re: When the Compiler Bites

#6
The unit test issues in my real program, which was a bit more sophisticated than what was presented here, gave me artificial intelligence vibes. It’s that situation where a computer algorithm did something really clever and I felt it outsmarted me.

As someone who has been reading compiler output for many years, it seems like these "flashes of inspiration" are relatively sparse compared to the bulk plain-stupid code they normally produce; once in a while you'll see something and think "that's clever... really clever", followed immediately by something so stupid it makes you wonder how it managed to generate such code. You can easily distinguish between that and human-written Asm that way. The latter may not have as much "peak cleverness" but certainly keeps up its average level of efficiency.

Re: When the Compiler Bites

#7
post #4
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); ...

I tested it. It doesn't help on Clang.

Why do you try to allocate if w is zero? I'm assuming w stands for width.

Re: When the Compiler Bites

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

Re: When the Compiler Bites

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

My guess would be that they were thinking h <= SIZE_MAX / w, and added the most obvious logic to avoid a division by zero.
Post reply on HN