[Ecls-list] GCC's builtins

[Juan Jose Garcia-Ripoll]

On Thu, Feb 4, 2010 at 5:38 PM, Stelian Ionescu <sionescu at cddr.org> wrote:

> I get warnings like these(complete log at http://tinyurl.com/y9g5xwa):
>
> /home/hechee/tmp/ecl/src/c/error.d: In function 'init_error':
> /home/hechee/tmp/ecl/src/c/error.d:327: warning: passing argument 2 of
> 'ecl_def_c_function_va' from incompatible pointer type
> ./ecl/external.h:412: note: expected 'cl_objectfn' but argument is of type
> 'union cl_lispunion * (*)(cl_narg,  union cl_lispunion *, union cl_lispunion
> *, union cl_lispunion *)'
> /home/hechee/tmp/ecl/src/c/error.d: In function 'FEinvalid_function':
> /home/hechee/tmp/ecl/src/c/error.d:223: warning: 'noreturn' function does
> return
>

This is ok. FEinvalid_function does not return but the compiler does not
have a way to know this.


> /home/hechee/tmp/ecl/src/c/read.d: In function 'read_VV':
> /home/hechee/tmp/ecl/src/c/read.d:2469: warning: passing argument 1 of
> 'ecl_make_cfun' from incompatible pointer type
> ./ecl/external.h:406: note: expected 'cl_objectfn_fixed' but argument is of
> type 'cl_objectfn'
>

Again no problem: we have to store all function pointers in the same field,
but later on they are coerced back to the right type.


> /home/hechee/tmp/ecl/src/c/unixint.d: In function 'si_catch_signal':
> /home/hechee/tmp/ecl/src/c/unixint.d:712: warning: passing argument 2 of
> 'mysignal' from incompatible pointer type
> /home/hechee/tmp/ecl/src/c/unixint.d:209: note: expected 'void (*)(int,
>  struct siginfo_t *, void *)' but argument is of type 'void (*)(int)'
>

It is a problem with the prototype for mysignal. But again harmless.


> dpp: /home/hechee/tmp/ecl/src/c/threads.d -> tmp.c
> Keyword not found: count.
> Unknown symbol: mp:make-semaphore
> Unknown symbol: mp:make-semaphore
> Unknown symbol: mp::semaphore
> Unknown symbol: mp::semaphore
> Unknown symbol: mp::semaphore
> Unknown symbol: mp::semaphor
>

The preprocessor parses all special symbols such as @'mp:make-semaphore'
even if they appear in sections of the C code that will never be compiled.


> Btw, colorgcc(http://schlueters.de/colorgcc.html) is very useful in
> spotting warnings/errors in long builds


I use emacs and it does something quite the same in my setup.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100204/c6e91591/attachment.html>