BSD Dissatisfied with gcc... why?
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.
Posted Nov 18, 2008 1:49 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (3 responses)
Granted, since I follow Linux much, much more closely than BSD, I tend to hear it from the Linux kernel guys. Here's a thread that captures what I'm talking about.
Posted Nov 18, 2008 17:24 UTC (Tue)
by daney (guest, #24551)
[Link] (2 responses)
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.
Posted Nov 18, 2008 17:38 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (1 responses)
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...).
Posted Nov 18, 2008 19:07 UTC (Tue)
by dlang (guest, #313)
[Link]
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)
Posted Nov 18, 2008 10:42 UTC (Tue)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (3 responses)
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?
Posted Nov 19, 2008 14:36 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
Wrong. I think you were thinking of the "register" keyword.
Posted Nov 19, 2008 20:57 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Nov 20, 2008 10:34 UTC (Thu)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link]
No, I was and am still talking of "volatile".
volatile unsigned ethernet_status;
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...
BSD Dissatisfied with gcc... why?
Nice example...
Nice example...
Nice example...
BSD Dissatisfied with gcc... why?
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?
"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?
with the single rare exception of global register variables (a GCC
extension).
BSD Dissatisfied with gcc... why?
> Wrong. I think you were thinking of the "register" keyword.
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:
/* -> 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)));
}
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.