[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Liberty-eiffel] Trying to learn the C-generator....

From: Hans Zwakenberg | Ocean Consulting GmbH
Subject: [Liberty-eiffel] Trying to learn the C-generator....
Date: Fri, 15 Aug 2014 16:52:29 +0200 (CEST)

Hi Group,
as an exercise for me to get to know the C-code emitter better:
Consider the following three functions that are present in compile-to-c1.c:
int se_cmpT351(T351* o1,T351* o2){
int R=0;
R = R || ((o1->_mangling) != (o2->_mangling));
return R;

int se_cmpT706(T706* o1,T706* o2){
int R=0;
return R;

int se_cmpT789(T789* o1,T789* o2){
int R=0;
R = R || ((o1->_hashed_string_memory) != (o2->_hashed_string_memory));
R = R || ((o1->_column) != (o2->_column));
R = R || ((o1->_line) != (o2->_line));
return R;
Clearly se_cmpT706() is breaking the mold set by the other two functions, i.e. it's doing nothing productive (and the compiler justly complains about the two function arguments not being used).  I guess at least three scenarios are possible:
- the function should be kept as perhaps it is being called by other code, even if it does nothing, in which case the existence of this function is merely justified by avoiding error messages
- the function should have been optimised away alltogether
- the function should really do a comparison, and the code the C-emitter generates is at fault
My concrete question:  where do I look in the Eiffen and C sources to determine which of the above assumptions is correct?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]