[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Gcl-devel] Re: delayed pathname.d patch
From: |
Mike Thomas |
Subject: |
RE: [Gcl-devel] Re: delayed pathname.d patch |
Date: |
Tue, 4 May 2004 18:01:31 +1000 |
Hi there.
I said last week:
| | > These messages never appeared before and I have yet to track
| | them down - the
| | > intermediate files are being deleted and the names are not
| | being printed so
| | > I'll have to modify the code to go further after I've done more
| | on the path
| | > corruption problem.
| | >
| |
Camm replied:
| | This is very interesting, and I'd personally be interested in knowing
| | how your compiler flag setup wound up displaying these messages. I'd
| | taken some pains to make sure the generated C code had a clean -Wall
| | compile, but I'd noticed that no warning messages, only errors, were
| | displayed when I ran the compiler under lisp. In other words, I had
| | to run gcc on the command line on the output C files to see messages
| | like the above, so conceivably there could be many cases of -Wall
| | cleanups that I've missed. What was the lisp input here? I had
| | pushed the gcc warning display issue way down on the future TODO
| | list.
|
Here is the C compiler command line part of the story:
1> (COMPILER::COMPILER-COMMAND #p"gazonk3.c" #p"gazonk3.o")
<1 (COMPILER::COMPILER-COMMAND
"gcc -c -g -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -fno-
zero-initialized-in-bss -mms-bitfields -g -mcpu=i386 -march=i386 -Ic:/lang/
gcl261-ansi-3.3.1.exp/lib/gcl-2.6.1/unixport/../h -c gazonk3.c -o
gazonk3.o ")
gazonk3.c: In function `L1': gazonk3.c:5227: warning: `V1' might be used
uninitialized in this function
This is precisely the same command line as is passed with a normal Windows
build (ie with winnt available in *features*) so there must be something
suppressing warning messages from gcc. Haven't had time to look further.
As far as the lisp and intermediate files are concerned, I checked Paul D's
kind suggestion re "compile-file :c-file t :h-file t :data-file t" but the
random tester (rt.lsp, correct me if I'm wrong) uses "compile" rather than
"compile-file"; so I fed it ":LEAVE-GAZONK t" but unfortunately if those
files are being left, they are also being overwritten by subsequent
invocations of compile. When I get time I'll try adding a timestamp to the
file names so they are preserved as the RT runs or renaming them.
| likewise your earlier
| suggestion
| about the link time padding with respect to the stable branch instability
| which I had overlooked.
Reinstating this oddity did not change gcl's behaviour on Maxima with
"ignore-errors" or the randow-tester, configured with and without
"--enable-debug".
Cheers
Mike Thomas
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/05/03
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/05/03
- RE: [Gcl-devel] Re: delayed pathname.d patch,
Mike Thomas <=
- Re: [Gcl-devel] Re: delayed pathname.d patch, Michael Koehne, 2004/05/04
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/05/04
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/05/18
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/05/23
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/05/27
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/05/18
Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/05/18