BSD Dissatisfied with gcc... why? [LWN.net]

BSD Dissatisfied with gcc... why?

Posted Nov 18, 2008 0:42 UTC (Tue) by qg6te2 (guest, #52587)
In reply to: BSD Dissatisfied with gcc... why? by jzbiciak
Parent article: pcc seeks contributions to reach 1.0 milestone

it seems like nearly every major GCC release seems to break something subtly somewhere that was relying on a stronger guarantee than is offered by the standard.

"Stronger guarantee than offered by the standard"? I don't think such a thing exists. Not following standards is a very slippery path. If one writes code that does not follow the standard but rather some bastardised version of it, the resulting code is by default non-portable and likely to break across compilers (even on the same architecture). I've seen non-portable trickery where the entire point was to get a 5% speedup on a particular version of a compiler.

(Log in to post comments)

Nice example...

Posted Nov 18, 2008 17:24 UTC (Tue) by daney (subscriber, #24551) [Link]

That is an excellent example, one that clearly shows that the GCC developers being responsive by carefully analysing the situation and changing their compiler to address the concerns raised by the Linux kernel developers.

There was some initial contention, but once the situation was well understood, the desired results were obtained. There are some who argue based on the axiom that GCC == BAD, but I don't think it holds in the case you mention.

Nice example...

Posted Nov 18, 2008 17:38 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]

I don't come down on the side of "GCC == BAD" at all. What I was pointing out, though, is that the C standard and its wiggle room are at odds with things like kernels and multithreaded programs. If you can only rely on what the C standard guarantees, then it's much harder to do useful things efficiently.

More aggressive optimizations will rely on this wiggle room and sometimes break things. That's a headache for kernel developers. Sure, GCC may get fixed, but breaking to begin with was an annoyance. If the break causes subtle problems, diagnosing the issue could be very difficult.

This is where a simpler compiler can be more effective. If it provides very simple semantics (rather than the extraordinary wiggle room the standard provides), it becomes easier to reason about the correctness of the program. Yes, it's less portable to other compilers, but as long as the compiler itself is portable, what's the issue?

After all, you don't see many Linux builds that don't use GCC (although there are a few...).

Nice example...

Posted Nov 18, 2008 19:07 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

multi-threaded programming will be in much better shape (standards wise) in a couple years.

defining this area is one of the bigger changes in the new POSIX, C, and C++ standards that are nearing completion (POSIX is complete, C is expected next year, C++ sometime after that)

BSD Dissatisfied with gcc... why?

Posted Nov 18, 2008 10:42 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

> Not following standards is a very slippery path.

Even when the standards are very unclear, like volatile structure of bitfields considered by GCC (in C) as structure of volatile bitfields, resulting in reads of volatiles on an "C" whole structure write?
Moreover, I still do not understand how in C++ I am supposed to use volatile integers - when I want to write a non volatile integer to it or read it into a non volatile integer - i.e. the basic use of volatile (register mapped) integers. Obviously I do not want warnings or a cast of my volatile register mapped integer into non volatile...

BSD Dissatisfied with gcc... why?

Posted Nov 19, 2008 14:36 UTC (Wed) by dgm (subscriber, #49227) [Link]

> the basic use of volatile (register mapped) integers

Wrong. I think you were thinking of the "register" keyword.
"Volatile" means that the contents of a variable can be changed externally at any time. Think, for instance, of a memory mapped hardware register. Basically it instructs the compiler to avoid certain optimizations based on knowledge of the previous value, and forces it to read it every time.

BSD Dissatisfied with gcc... why?

Posted Nov 19, 2008 20:57 UTC (Wed) by nix (subscriber, #2304) [Link]

In particular, 'volatile' is still useful. 'register' is, basically, not,
with the single rare exception of global register variables (a GCC
extension).

BSD Dissatisfied with gcc... why?

Posted Nov 20, 2008 10:34 UTC (Thu) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

> > the basic use of volatile (register mapped) integers
> Wrong. I think you were thinking of the "register" keyword.

No, I was and am still talking of "volatile".
The problem is that the C++ standard treats all attributes the same way, and gives examples with "const".
I do understand that to overwrite the "const" attribute, I need to do a dirty cast to non-const, but the basic use of volatile is to copy them into standard variables, at a controled place of the software:

volatile unsigned ethernet_status;
/* -> address of ethernet_status defined in the linker file */
int fct(void) {
unsigned status = ethernet_status; // single read of "ethernet_status"
return ((status & 1) || ((status & 2) ^ (status & 4)));
}

Now tell me how to put ethernet_status and fct() into a class and compile without warning and without casting ethernet_status to non-volatile...

But the worst for me is still considering a volatile structure of bitfields as a structure of volatile bitfields, even if I see no problem to consider a constant structure of bitfields as a structure of constant bitfields...
For instance:
volatile struct color_s { char red, green, blue, transparent; } volcolor;
int fct (void) {
struct color_s color = volcolor;
return color.red == color.blue;
}
Because volcolor is considered as a structure of volatile fields, volcolor is read twice (two byte access) when optimising.