Trusting the compiler

>trusting the compiler

Other urls found in this thread:

pastebin.com/NmugQe4F
stackoverflow.com/questions/8415895/is-left-and-right-shifting-negative-integers-defined-behavior
twitter.com/NSFWRedditGif

>gcc

>gcc
>expecting efficiency out of communism

top kek

Use clang, it's freedom as in america.

>-fno-inline-small-functions

Is the compiler what's making these threads every day?

OP can you post the source, can't bother copying it by hand

For real OP, try with clang and post again

>the compiler does the best optimization on the logically most simple and common approaches to the problem
What exactly is wrong here?

pastebin.com/NmugQe4F
Here, try compiling it with clang and post the assembly.
It doesn't change the generated assembly, only the location.
It doesn't optimize the bad approaches, but people trust it to.

>It doesn't optimize the bad approaches, but people trust it to
Who trusts it to? I don't, and the programmers I know don't. I think it's pretty common knowledge that if you implement something in a cryptic and hacky way, it's far less likely that the baked-in compiler optimizations are going to apply to it.

>It doesn't optimize the bad approaches, but people trust it to.

The 2 averaging approaches are equal. Keep in mind that x+y might overflow so the compiler can't just delete it.

The point is that things like max_if_else_if_eq_avg are trivial to optimize, but it doesn't realize that x==y and then factor it. If it did, it would optimize like max_if_else_if_eq. Missing trivial optimizations like that means it can't be trusted.
Undefined behavior, it's fine to ignore.

Not gonna post the objdump output but here are the warnings that this code produces with gcc vs clang

GCC:
max.c:87:2: warning: implicit declaration of function 'srand'; did you mean 'scanf'? [-Wimplicit-function-declaration]
srand(getpid());
^~~~~
scanf
max.c:87:8: warning: implicit declaration of function 'getpid'; did you mean 'getline'? [-Wimplicit-function-declaration]
srand(getpid());
^~~~~~
getline
max.c:88:10: warning: implicit declaration of function 'rand' [-Wimplicit-function-declaration]
int x = rand();
^~~~

Clang:
clang: warning: optimization flag '-fno-inline-small-functions' is not supported [-Wignored-optimization-argument]
max.c:46:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
max.c:57:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
max.c:68:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
max.c:87:2: warning: implicit declaration of function 'srand' is invalid in C99 [-Wimplicit-function-declaration]
srand(getpid());
^
max.c:87:8: warning: implicit declaration of function 'getpid' is invalid in C99 [-Wimplicit-function-declaration]
srand(getpid());
^
max.c:88:10: warning: implicit declaration of function 'rand' is invalid in C99 [-Wimplicit-function-declaration]
int x = rand();
^

Fuck, should start with
#include
#include
#include
#include

>using c for anything other than embedded systems in 2017

>not using Rust and Forth for embedded systems

GCC > Clang.

integer overflow is not undefined behavior

Signed integer overflow is, unsigned integer overflow doesn't happen.

>Undefined behavior, it's fine to ignore.

left shifting is undefined behavior too

>if E1 has a signed type and non-negative value, and E1 × 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
>stackoverflow.com/questions/8415895/is-left-and-right-shifting-negative-integers-defined-behavior

That's true, and the only reason I included max_bithack_shift is since it's a well known bit hack.

>wasting your time with stupid shit
typical Sup Forums

>wahhh why is this technology board discussing and analyzing technology
go back to your phone posting thread you fucking mongoloid

clang compiles max_ternary, max_if, max_if_else, max_if_else_if_else, max_if_else_if_eq, and max_bithack_arithmetic exactly the same.
max_if_else_if_eq_avg and max_if_else_if_eq_avg_shift are almost the same as the rest, but use slightly different instructions and an offset trick. Still the same length.
max_bithack_xor is the same as the common assembly except that there are three additional xor instructions in it.
max_bithack_shift is the only one that compiles to entirely different instructions than the rest.

Post objdump -d. Do they all use cmov?

>Post objdump -d.
No
>Do they all use cmov?
All except for max_bithack_shift do

>unsigned integer overflow doesn't happen
What? Yes it does

No, the standard guarantees they're taken mod 2^n (& ((1

Right, the standard guarantees they'll overflow.

Well, I guess you could say that, but the standard describes it as "there's no overflow since it's masked"

Can you point out the section where the standard explicitly refers to overflow as "no overflow"?

Sure thing buddy!
6.2.5.9
>A computation involving unsigned operands can never overflow,
>because a result that cannot be represented by the resulting unsigned integer type is
>reduced modulo the number that is one greater than the largest value that can be
>represented by the resulting type.