After doing some research, I have discovered (I think) the reason EPIC always
crashes at random if you compile it with gcc -O2. It has to do not with
bugs in epic, or bugs in gcc, but in assumptions gcc mades at -O2.
The gcc -O2 optimization level turns on strict alias optimizations. Alias
safety is a new c99 concept which essentially forbids the use of congruent
structs to write ad hoc object oriented code, which is permitted in C90. [1]
Perhaps "forbid" is too strong a term, but rather, the result of using these
techniques is now explicitly undefined behavior.
EPIC makes strong use of these object oriented techniques (specifically,
alists), and therefore forgoing them is not an option since they are
perfectly legitimite C90, but undefined C99. Gcc3 and 4 now seem to assume
c99 by default, unless you say otherwise, and -O2 seems to really put the
screws down to code that isn't alias safe (ie, epic).
Therefore, I propose making it official policy that epic is not compatable
with gcc -O2 because -O2 only works properly on code that conforms to C99's
rules about alias safety: epic is a c90 program and does not conform.
Comments, questions, discussion?
Jeremy
[1] Example of object oriented technique in C90, forbidden by C99:
struct s1 { int x,y; };
struct s2 { int x,y; float f };
int func (struct s2 *ptr) { ptr->x = 5; }
int main (void)
{
struct s1 *ptr;
struct s2 var;
var.x = 1;
ptr = (struct s1 *)&var;
func(ptr);
printf("%d\n", var.x);
}
In C90, the results of the printf is 5. In C99, it is undefined (could be 1,
could be 5).
_______________________________________________
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
