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:
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...
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.
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.
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).
Putting it in the KDE wiki would limit myself to KDE and C++, missing C and other libs (for example Boost)
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
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!
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.
Ideally, you should treat all warnings (except unused variables) as serious, i.e. compile with -Werror. Or even just -Werror=return-type.
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
Ah, that's a good one - and actuall compiler failure... nice :-)
Post a Comment
<< Home