Documentation

[Asher]

What is wrong with gcc?

JM

Mostly:
- It's historically played fast and loose with the standards resulting in horrible code being written for decades and difficult porting jobs.
- Almost all of the commercial compilers generate better code. Visual C++, Intel C++, and IBM's XL C++ are all typically much faster.

GCC is portable and free. That's its only strength. Which, for most academics, open source advocates, etc makes it perfect. But for professionals in the real world, using gcc is frequently like slumming it.

GCC4 and higher were big improvements across the board. But it's still trying to play catchup with better-funded competitions with more talented developers and researchers. Hell, gcc 3.2 doesn't even get to claim 100% x86/IA32 ABI compliance due to bugs/design quirks.

[Asher]

Here's another example, from this week: I fixed a bug in our app in Windows, submitted the patch and went home. In the morning I got an email saying the patch broke the compilation process on Mac. We're currently using gcc to build on MacOS (we're transitioning away from it, like Apple has...but we've not had time yet).

How could this be? I was writing 100% standards-compliant C++. I was making two function calls.

The problem is gcc is stupid. The parameters I was passing were references to a STL multimap object, which contained pointers to some Boost objects. gcc got completely confused and gave me cryptic errors about syntax, telling me function prototype was expecting a reference and I was giving it a pointer (when I was giving it a reference).

I fixed it by adding a temporary variable right before the function call, the contents of which I just copy/pasted from the function parameters. Then I passed that variable as the parameter. Now that the syntax was simpler, gcc could understand it. I didn't change one ounce of functionality of the code, and I was writing standards-compliant code that whole time which compiled just fine under VC++, but gcc couldn't figure it out. It's aggravating, mickey-mouse **** like that which sends me into fits of rage with gcc.

[Jon Miller]

Hmm, maybe some of my problems taht I can never figure out are gcc problems?

JM

[Fve Crathva]

My teammate last term sent me this awesome bit of C code early on in the development process:

void _add(op1,op2,op_size,result)
    array_t *op1, *op2, *result;
    int op_size;
{
    int i, temp, remainder = 0;

    for (i = 0; i<op_size; i++) {
        temp =      get_val(op1, i) 
                +   get_val (op2, i) 
                +   remainder;

        if (temp & 0x1)
            set(result, i);
        else 
            reset(result, i);
    
        remainder = (temp & 0x2) ? 1 : 0;
    }
}/* _add */

I have no idea what that is, but gcc seemed to understand it.

SP

[BlackCat]

May I suggest that you simply put a bullet in your teammates head ?

[Kuciwalker]

Erm, that function is kind of obvious? It uses a slightly archaic form of function declaration and you have to infer set/reset/get_val from context, but otherwise it's not really that complicated.

[Kuciwalker]

That said, it's a really stupid function. He's implemented bigint addition bitwise. Obvious you should just use the CPU's built-in 32- or 64-bit adder and handle overflow manually...

[BlackCat]

But it doesn't handle overflow

[Kuciwalker]

Neither does +. So what?

[Fve Crathva]

That said, it's a really stupid function. He's implemented bigint addition bitwise. Obvious you should just use the CPU's built-in 32- or 64-bit adder and handle overflow manually...

Yes, I optimized his add, subtract, shift, and compare functions and brought the running time for a 12-bit exponentiation down from 8 hours to around 100 ms (on a 206 MHz ARM simulator). And so long as we're nitpicking to make ourselves sound smart, overflow is handled automatically because ARM has an instruction for it (he rewrote the add, subtract, and shift functions in assembly and the exponentiation ran in around 8 ms).

SP

[BlackCat]

Writing your private version of + and not handling overflow is a bit stupid.

[Fve Crathva]

Not if there's nothing you can do with the last carry bit. Sometimes you just have to let it overflow.

SP

[BlackCat]

You can crash the program telling the user that data can't be handled correct - a bit better than produce wrong results

[Kuciwalker]

dude, it would be ****ing stupid to make + crash on overflow

[Fve Crathva]

Rule 0 of embedded systems: don't crash the program.

The default add instruction in ARM doesn't even set the carry flag, it just overflows silently.

SP