Re: [dev] GCC situation

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Mon, 24 Nov 2014 21:05:29 +0100

On Mon, Nov 24, 2014 at 11:01:13AM +0100, koneu wrote:
> On November 24, 2014 6:35:51 AM CET, Markus Wichmann <nullplan_AT_gmx.net> wrote:
> >that this asumption removes most overflow checking code.
>
> This behaviour is a pro, not a con, of GCC. If you rely on undefined behaviour to
> check for ... well ... undefined behaviour there is a compiler flag to enable it.
>

Buried in the manpage somewhere. But sure, it's there. Somewhere below
the architecture options for the VAX, and somewhere in the middle of all
the other optimizers. And that's if you even remember what to search
for.

> >something, but... well, the problem is, most code out there is not
> >strictly conforming to the C standard.
>
> Fix the code instead of breaking the compiler.
>

Assume I'm compiling something like sabotage or LFS. I have about 20
packages to build to get a remotely usable system. And in that situation
compiling with -O3 will result in some broken binaries. Somewhere. Why?
Because in the thousands of code lines somewhere there is a bug. I know
I won't look for it. It is unlikely I'll even be able to identify the
malfunctioning component. All I'll know is that something doesn't work,
and if it is something in those early components it's likely that just
"something breaks" and then the whole system doesn't work. Great!

OTOH I could just only use suckless software and write everything that's
missing myself. But you'll have to forgive me for wanting to connect to
my WiFi sometime before next year (because I've read wpa-supplicant, and
I don't like it, but I lack the expertise to rewrite it sucklessly
myself).

> >By now, the only thing that really bugs me is that GCC's optimizers
> >make
> >code undebuggable.
>
> -O0 and -g are your best friends.
>
>

Yes, it's the -O0 that bothers me there. I'd like to debug the code that
actually runs in production.

One big problem is that at -O3 almost every value is "optimized out".
Now, all that means is that no register or memory location with that
exact variable exists, but from the code I know that clearly _some_
value based on the variables and parameters has to be saved somewhere.
But gdb offers no way to display those. I know that with optimization
control flow may be very different from the flow I wrote into the source
code, but at least let me see my values!

But no, so I'll have to put in debug outputs, which of course changes
the program, and kills the timing, and if I'm debugging a race condition
(in the sucky code I have to write at work) that's exactly what I don't
need. Oh, and I'll have to remember to remove them.

Ciao,
Markus
Received on Mon Nov 24 2014 - 21:05:29 CET