2007-03-07

GCC gems

Everybody using GCC on a daily basis must have run into one of its hidden gems. Error messages that could be poetry, in a foreign language, written backwards. The message tells you pretty much - nothing. When you have found the problem and fixed you still wonder what GCC really meant and why it could not tell you something in English...

One of my personal favourites was when I was using C and wrote:

typedef struct { ... } Foo;

void function()
{
struct Foo foo;

...
}


Did you spot the mistake? GCC did - and told me this:

storage size of 'foo' isn't known

After much work I found that Foo wasn't a struct, but a typedefed struct. Just skipping the word struct in the declaration of foo solved it.

What are your favorites? Comment!

11 Comments:

At 12:13 PM, Anonymous Anonymous said...

I like this one:

error: ‘struct Foo’ has a previous declaration as ‘struct Foo’

This is about a forward declaration so the error message is not very helpful. But it's valid...

 
At 12:31 PM, Anonymous Manu said...

Maybe the message makes perfect sense in other context or it did sense a long time ago. Did you report this [*]?

I think one of the reasons why GCC diagnostics are lame sometimes is that most people prefer to waste 15 minutes bitching about it in a blog or mailing list rather than spending 5 minutes reporting the bug.

[*] http://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

An interesting project would be to setup a KDE page with a list of most-hated "broken" diagnostics in GCC. It will make a nice Google Summer of Code project and improve the mood and overall work of KDE developers.

 
At 12:35 PM, Blogger Johan Thelin said...

Actually, I'm working on such a page - but the site is not ready for public use yet - I need to tighten the installation up first.

 
At 12:51 PM, Anonymous Manu said...

Why not in the KDE wiki? That way, any KDE programmer could easily add his/her own. Also, people could keep a list of which ones have already been reported to GCC and which ones have been fixed since a particular release.

http://wiki.kde.org/#_For_Programmers

(In my previous email, the nice Summer of Code project would be to fix the diagnostics, not to setup the webpage. If such page existed, it could be linked from http://gcc.gnu.org/wiki/SummerOfCode).

 
At 12:57 PM, Blogger Johan Thelin said...

Putting it in the KDE wiki would limit myself to KDE and C++, missing C and other libs (for example Boost)

 
At 2:25 PM, Anonymous Anonymous said...

While I dislike the GCC (considering it bloatware), I feel like defending it in this case: what your compilator did was actually perfectly reasonable, IMHO. Lemme explain:

(Disclaimer: I've been reading relevant docs some time ago, my interpretation may be wrong)

the `typedef struct { ... } Foo;' bit creates a new type, named Foo. It doesn't really matter you used ``struct'' in this definition, it's just a new type. The `struct Foo foo;' line creates instance of a structure Foo. While it happens to bear same name as type Foo you created earlier, mind that per C's specification, there are two distinct namespaces for structures and types. This, actually, is a feature, which can be leveraged. So, while there is a TYPE Foo, there was no STRUCTURE Foo, when GCC encountered `struct Foo foo;'. And now again, per language specification, creating instance of a structure defines it, if it's not defined yet. As an incomplete structure. (This also is a feature, and prolly you can make a reasonable use out of it, too.) Incomplete, in turn, means that size is not known yet. Thus, the error message.


To sum up, the catch was in C's specs rather than in GCC itself. Should GCC warn you? Don't think so. That kind of use is perfectly legal, and comparing (possibly very many) names in both namespaces isn't really reasonable, IMHO. Also, this mistake isn't as common as the dreaded `if ( a = b )'.


--
dexen deVries,
dexen@STUPID-FILTER@internet-industry.pl

 
At 2:26 PM, Anonymous Anonymous said...

I've got used to most GCC errors.

I think the worse aspect of it's error reporting, is that "Control reaches the end of a non-void function." is a warning!

I mean, come on! That causes random crashes in random places in the program and is just about the most annoying thing to debug ever!

 
At 7:38 PM, Anonymous Matt Smith said...

I guess GCC only gives errors as such when it hits invalid code. If not returning a value in a non-void function is valid C/C++, even if it's dangerous to run, then it would merit a warning, much as memory leaks and other security issues cause warnings rather than errors.

 
At 9:57 PM, Blogger Jason said...

Ideally, you should treat all warnings (except unused variables) as serious, i.e. compile with -Werror. Or even just -Werror=return-type.

 
At 1:04 AM, Anonymous dexen deVries said...

Got this during compilation of QEmu 0.9.0, GCC v 3.4.6. Looks like ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp to me :P

../softmmu_template.h: In function `__stq_mmu':
../softmmu_template.h:260: error: unable to find a register to spill in class `GENERAL_REGS'
../softmmu_template.h:260: error: this is the insn:
(insn:HI 337 317 338 13 ../softmmu_template.h:287 (parallel [
(set (reg:DI 0 ax [214])
(lshiftrt:DI (reg/v:DI 59 [ val ])
(subreg:QI (reg:SI 235) 0)))
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 309 {lshrdi3_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil))))
../softmmu_template.h:260: confused by earlier errors, bailing out
make[1]: *** [op_helper.o] Error 1
make[1]: *** Waiting for unfinished jobs....




dexen deVries,
dexen@STUPID-FILTER@internet-industry.pl

 
At 7:32 AM, Blogger Johan Thelin said...

Ah, that's a good one - and actuall compiler failure... nice :-)

 

Post a Comment

<< Home