gobo-eiffel-develop

[gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Hello the GOBO team,

I tried to install the new GOBO (5.6) release and ran
immediately into trouble: my preferred C compiler is "cc"
but command "$GOBO/install.sh cc" stopped with the message

  Unknown C compiler: cc

It is really surprising that the native C compiler of many platforms
is not supported.

When trying the same with "gcc" then many warnings like the following
were issued:

  gec.c: In function `T202f63':
  gec.c:82734: warning: cast to pointer from integer of different size

Line 82734 in C code reads

  t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));

whereas "gevoid" is declared as

  extern int gevoid(T0* C, ...);

Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
on a Tru64 platform (as I'm working on). I think, the solution is
to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
Just for curiosity, what is "gevoid" good for? Its definition seems
to indicate that it is the check for void targets, but there is no test
(neither in the routine nor around its call), merely printing an error
message and aborting the program. And if aborting in any case has been
planned, why then a return value?

After the warnings an error message follows:

  as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments together 
exceed 64k bytes

Probably, the generated object file is too large.
(I had the same effect also earlier when bootstrapping the SE compiler
from a single C file instead from a split one.)

Then many errors of the form
  /usr/users13/wolfgang/eiffel/gobo/install.sh: 
/usr/users13/wolfgang/eiffel/gobo/bin/gec: not found
  /usr/users13/wolfgang/eiffel/gobo/install.sh: geant: not found

occurred, probably a consequence of the previous error.


Wolfgang


PS:
After adding the "cc" compiler to "install.sh" the outcome was
as follows:

  cc: Warning: gec.c, line 479288: Non-void function "gevoid" does not 
contain a return statement. (missingreturn)
  int gevoid(T0* C, ...)

The bad cast is not rejected and the compilation of "gec"
is successful. Then most of "geant", ... are compiled successfully
where C compilation is again done by "gcc" (to be seen by
the warnings concerning bad casts). Why "gcc"?
Compilation of "gelint" and "gexslt" fail because of large size.


-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Hi Wolfgang,

Wolfgang Jansen wrote:
> I tried to install the new GOBO (5.6) release and ran
> immediately into trouble: my preferred C compiler is "cc"
> but command "$GOBO/install.sh cc" stopped with the message
> 
>   Unknown C compiler: cc
> 
> It is really surprising that the native C compiler of many platforms
> is not supported.

The problem is that I only have access to Windows platform.
So I can only work and test on this platform. At some point
SourceForge made available other platforms through their
compile farm:

    http://en.wikipedia.org/wiki/Compiler_farm

But they don't provide this service anymore ;-( The reason
why only gcc was made available is because that's the only
C compiler that was available on SourceForge's compile farm
platforms as far as I know. But people are free to test gec
on other platforms and with other C compilers and give me
some feedbacks.

    http://www.gobosoft.com/eiffel/gobo/gec/platforms.html

BTW, what platform are you using?

> When trying the same with "gcc" then many warnings like the following
> were issued:
> 
>   gec.c: In function `T202f63':
>   gec.c:82734: warning: cast to pointer from integer of different size
> 
> Line 82734 in C code reads
> 
>   t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));
> 
> whereas "gevoid" is declared as
> 
>   extern int gevoid(T0* C, ...);
> 
> Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
> on a Tru64 platform (as I'm working on). I think, the solution is
> to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
> Just for curiosity, what is "gevoid" good for? Its definition seems
> to indicate that it is the check for void targets, but there is no test
> (neither in the routine nor around its call), merely printing an error
> message and aborting the program. And if aborting in any case has been
> planned, why then a return value?

'gevoid' is the result of the code optimizer. It means that in the
corresponding Eiffel code, no matter what, this call will result in
a call on Void target. For example:

      local
         s: STRING
      do
         s.append_string ("gobo")

'gevoid' is then emitted instead of the call. I think that the problem
above is that I tried to use the same 'gevoid' function to replace all
kinds of calls, be them procedures or functions with expanded or
reference result. I was hoping that explicit type cast would make the
C compiler happy, which it did with the compilers I tried. Apparently
I will have to rethink about it and find a better implementation.

> After the warnings an error message follows:
> 
>   as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments together 
> exceed 64k bytes
> 
> Probably, the generated object file is too large.
> (I had the same effect also earlier when bootstrapping the SE compiler
> from a single C file instead from a split one.)

Hmmm, I asked someone to test on Linux (Ubuntu 7.04) with gcc and
everything worked OK. It was not my intention to work on C file
splitting in the near future. I will probably have to reconsider.

> Then many errors of the form
>   /usr/users13/wolfgang/eiffel/gobo/install.sh: 
> /usr/users13/wolfgang/eiffel/gobo/bin/gec: not found
>   /usr/users13/wolfgang/eiffel/gobo/install.sh: geant: not found
> 
> occurred, probably a consequence of the previous error.

Yes.

> PS:
> After adding the "cc" compiler to "install.sh" the outcome was
> as follows:
> 
>   cc: Warning: gec.c, line 479288: Non-void function "gevoid" does not 
> contain a return statement. (missingreturn)
>   int gevoid(T0* C, ...)
> 
> The bad cast is not rejected and the compilation of "gec"
> is successful. Then most of "geant", ... are compiled successfully
> where C compilation is again done by "gcc" (to be seen by
> the warnings concerning bad casts). Why "gcc"?

You will have to configure gec to use cc as C compiler. See
section "Back-end C compiler" in:

    http://www.gobosoft.com/eiffel/gobo/gec/usage.html


What this install script does is just generate the binary files
in $GOBO/bin. For those of you who don't want to have to generate
them by themselves, I made available the binaries for Windows in:

   https://sourceforge.net/project/showfiles.php?group_id=24591

Anyone is welcome to provide the binaries for his platform so
that I can make them available on SourceForge as well.

Wolfgang, thank you for your feedback, and don't hesitate to
send me a cc.cfg file if you manage to make one working on
your platform.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
>
> BTW, what platform are you using?
It's an (formerly DEC) alpha under OSF1. OK, it is a rare platform nowadays.
Anyway, the best C compiler there I'm aware of is the "cc".
>
>>
>> Just for curiosity, what is "gevoid" good for? Its definition seems
>>
> 'gevoid' is the result of the code optimizer.
> corresponding Eiffel code, no matter what, this call will result in
> a call on Void target. For example:
>
>      local
>         s: STRING
>      do
>         s.append_string ("gobo")
>
> 'gevoid' is then emitted instead of the call.
Now, I understand. What about issuing a compiler warning
stimulating the programmer to eleminate the awkward construct?
>
> You will have to configure gec to use cc as C compiler. See
> section "Back-end C compiler" in:
>
>    http://www.gobosoft.com/eiffel/gobo/gec/usage.html
>
I did so and compilation was successful.

The attachments contain the configuration file for use
of the "cc" on alpha platforms and the adapted "install.sh".

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> 'gevoid' is the result of the code optimizer.
>> corresponding Eiffel code, no matter what, this call will result in
>> a call on Void target. For example:
>>
>>      local
>>         s: STRING
>>      do
>>         s.append_string ("gobo")
>>
>> 'gevoid' is then emitted instead of the call.
> Now, I understand. What about issuing a compiler warning
> stimulating the programmer to eleminate the awkward construct?

I don't like warnings when the code is valid. For example if
in a third-party library class we have:


    f (s: STRING) is
       do
           if s /= Void then
                print (s.as_upper)
           else
                print ("Void string")
           end
       end

and then in my application I have:

   x.f (Void)

the dynamic type set mechanism used by the Gobo optimizer will
tell me that `s' will always be Void in `f', therefore there is
no need to generate the code for `as_upper' and 'gevoid' will
used in the call instead. But there is nothing to be fixed because
the code will not be called anyway. The optimizer has no flow
analysis to determine that we are in an if-branch that can
never be entered. And there is nothing wrong with `f'
because as soon as we add the line:

   x.f ("gobo")

in our application 'gevoid' will not be emitted in the generated
C code anymore.

But I agree that sometimes it will be useful to have this
information as warning when the Eiffel code is really at fault.

> The attachments contain the configuration file for use
> of the "cc" on alpha platforms and the adapted "install.sh".

Thank you. I will add them to Gobo SVN.
BTW, what is 'icc'? Is it the same as what I found on wikipedia:

   http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> I don't like warnings when the code is valid.
> But I agree that sometimes it will be useful to have this
> information as warning when the Eiffel code is really at fault.
>
This was my intension. I did not expect that the compiler looks
across routine boundaries. I agree that in this case
a warning in one class because of a void reference in another
class is very misleading.

>
> BTW, what is 'icc'? Is it the same as what I found on wikipedia:
>
>   http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
>
Yes. Sometimes a friend gives me the access to a platform
where "icc" runs. My impression is that the compiler is
better that "cc" which in turn is much better than "gcc".
In other words, if a user of "gec" works on a platform
supporting "icc" then it is highly probable that he wants
to use the "icc" in connection with "gec".

PS
The attachment contains the binaries of "gec", ... to be added to
http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
Except for "gec", I did not test staff.

Computer: alpha
OS: OSF1 V5.1
CC: Compaq C V6.4
others: 64 bit, little endian, Tru64

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Wolfgang Jansen wrote:
>
> The attachment contains the binaries of "gec", ... to be added to
> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
> Except for "gec", I did not test staff.
>
> Computer: alpha
> OS: OSF1 V5.1
> CC: Compaq C V6.4
> others: 64 bit, little endian, Tru64
>
>   
Sorry, first I forgot the attachment, second it turns out
the the zipped binaries are too large for my web-browser.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Wolfgang Jansen wrote:
>> The attachment contains the binaries of "gec", ... to be added to
>> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
>> Except for "gec", I did not test staff.
>>
>> Computer: alpha
>> OS: OSF1 V5.1
>> CC: Compaq C V6.4
>> others: 64 bit, little endian, Tru64
>>
>>   
> Sorry, first I forgot the attachment, second it turns out
> the the zipped binaries are too large for my web-browser.

Your binaries (except gexslt which was too big) have now been
uploaded to SourceForge.
Thanks.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> The attachment contains the binaries of "gec", ...

You should probably not send it to the mailing list.
Either send it direclty to me or make it temporarily
available somewhere so that I can download it.

> to be added to
> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
> Except for "gec", I did not test staff.
> 
> Computer: alpha
> OS: OSF1 V5.1
> CC: Compaq C V6.4
> others: 64 bit, little endian, Tru64

I updated my version of the file (to be soon committed to SVN).

Thanks.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Hi Wolfgang,

Wolfgang Jansen wrote:
> When trying the same with "gcc" then many warnings like the following
> were issued:
> 
>   gec.c: In function `T202f63':
>   gec.c:82734: warning: cast to pointer from integer of different size
> 
> Line 82734 in C code reads
> 
>   t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));
> 
> whereas "gevoid" is declared as
> 
>   extern int gevoid(T0* C, ...);
> 
> Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
> on a Tru64 platform (as I'm working on). I think, the solution is
> to redefine "gevoid" like "T0* gevoid(T0* C, ...)".

I think that this problem should be solved now. gec now generates
a different "gevoid" function for each possible return type.
So, no bad type cast should occur anymore.

> After the warnings an error message follows:
> 
>   as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments together 
> exceed 64k bytes
> 
> Probably, the generated object file is too large.
> (I had the same effect also earlier when bootstrapping the SE compiler
> from a single C file instead from a split one.)

gec is now able to split the generated C code over several files.
I didn't change the bootstrap to use this new functionality yet.

>   cc: Warning: gec.c, line 479288: Non-void function "gevoid" does not 
> contain a return statement. (missingreturn)
>   int gevoid(T0* C, ...)

This should be solved as well.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Hi Eric,

some minutes ago I downloaded revision 6029 of 
/gobo/trunk/library/tools/eiffel
and tried to re-stall "gec". Up to one mistake things are fine.

Eric Bezault wrote:
> Hi Wolfgang,
>
> Wolfgang Jansen wrote:
>> When trying the same with "gcc" then many warnings like the following
>> were issued:
>>
>>   gec.c: In function `T202f63':
>>   gec.c:82734: warning: cast to pointer from integer of different size
>>
>> Line 82734 in C code reads
>>
>>   t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));
>>
>> whereas "gevoid" is declared as
>>
>>   extern int gevoid(T0* C, ...);
>>
>> Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
>> on a Tru64 platform (as I'm working on). I think, the solution is
>> to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
>
> I think that this problem should be solved now. gec now generates
> a different "gevoid" function for each possible return type.
> So, no bad type cast should occur anymore.
>
Yes, this works very well.
>> After the warnings an error message follows:
>>
>>   as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments 
>> together exceed 64k bytes
>>
>> Probably, the generated object file is too large.
>> (I had the same effect also earlier when bootstrapping the SE compiler
>> from a single C file instead from a split one.)
>
> gec is now able to split the generated C code over several files.
> I didn't change the bootstrap to use this new functionality yet.
Yes, this works very well either.
>
>>   cc: Warning: gec.c, line 479288: Non-void function "gevoid" does 
>> not contain a return statement. (missingreturn)
>>   int gevoid(T0* C, ...)
>
> This should be solved as well.
>
Yes, it is.

The remaining problem is C compilation. There are many errors of the form
  cc: Error: test.h, line 257: Missing ";". (nosemi)

Line 257 is
  extern T0* geboxed1(T1 a1);
and T0 in turn is defined in line 235 by
  #define T0 EIF_ANY
but EIF_ANY is not defined. Replacing the last definition
manually by
  #define T0 EIF_OBJECT
makes the C compiler happy.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Hi Eric,
> 
> some minutes ago I downloaded revision 6029 of 
> /gobo/trunk/library/tools/eiffel
> and tried to re-stall "gec". Up to one mistake things are fine.

[...]

> The remaining problem is C compilation. There are many errors of the form
>   cc: Error: test.h, line 257: Missing ";". (nosemi)
> 
> Line 257 is
>   extern T0* geboxed1(T1 a1);
> and T0 in turn is defined in line 235 by
>   #define T0 EIF_ANY
> but EIF_ANY is not defined. 

It should be defined. I guess it's because you didn't
checkout the files which are in:

    /gobo/trunk/tool

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Hi Eric,
>>
>> some minutes ago I downloaded revision 6029 of 
>> /gobo/trunk/library/tools/eiffel
>> and tried to re-stall "gec". Up to one mistake things are fine.
>
> [...]
>
>> The remaining problem is C compilation. There are many errors of the 
>> form
>>   cc: Error: test.h, line 257: Missing ";". (nosemi)
>>
>> Line 257 is
>>   extern T0* geboxed1(T1 a1);
>> and T0 in turn is defined in line 235 by
>>   #define T0 EIF_ANY
>> but EIF_ANY is not defined. 
>
> It should be defined. I guess it's because you didn't
> checkout the files which are in:
>
>    /gobo/trunk/tool
>
Thanks, this was the point.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...