liberty-eiffel
[Top][All Lists]
Advanced

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

Re: [Liberty-eiffel] warning messages when compiling the germ with Pelle


From: Raphael Mack
Subject: Re: [Liberty-eiffel] warning messages when compiling the germ with Pelles-C
Date: Thu, 14 Aug 2014 21:58:45 +0000
User-agent: Internet Messaging Program (IMP) H5 (6.2.1)

I created some tickets:
https://savannah.gnu.org/bugs/?42990
https://savannah.gnu.org/bugs/?42991
https://savannah.gnu.org/bugs/?42992

For the unreachable code in compile_to_c104 I'm not sure what to do. It comes from the exec plugin, which uses different classes for the processes on POSIX systems and on windows systems (PROCESS_POSIX vs. PROCESS_WIN32). These instances are created in eiffel code, based on the value of basic_exec_system (which is a constant defined on C level, based on the system type, but on the eiffel side, the compiler doesn't know it's constant value and therefore can't remove the dead code). I somehow like the implementation from the abstract view, but on the other side, I hope that each C compiler recognizes the constness and removes the dead code and the unnecessary if-statements. A warning is expected here, but not very nice...


Unreachable code in compile_to_c110 seem GC-related. Cyril, do you have any comments?

All in all I think these are interesting findings and we should fix them, but they are not critical and if they do not make it into the bell release I still can sleep well.

Cheers,
Rapha


Zitat von Hans Zwakenberg  |  Ocean Consulting GmbH <address@hidden>:

Rapha,

enclosed the warning messages created by Pelles-C (32bit) on the _lowest_
warning level. The good news is that there are only warnings, no error messages
at all.  The germ compiled was pulled from github a couple of days ago, so it
should still be the current one.

To de-clutter the log, I removed all lines that constitute no warning messages. You'll notice that the very same error message (or groups of messages) pop up again and again - so I presume that a single code generating strategy is causing
this across all splitted C files...

cheers
Hans






reply via email to

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