This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch/RFC] Enable PCH for mingw32
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 04 Jun 2004 01:46:57 +0100
- Subject: Re: [Patch/RFC] Enable PCH for mingw32
- References: <000c01c446b4$d11db860$dd6d65da@DANNY><jm4qpwv5iw.fsf@desire.geoffk.org> <87vfictqc7.fsf@taltos.codesourcery.com><000b01c447c9$e8f07d90$996d65da@DANNY> <jmvfi8tjn7.fsf@desire.geoffk.org>
- Reply-to: Danny Smith <dannysmith at users dot sourceforge dot net>
"Geoff Keating" <geoffk@geoffk.org> writes:
|
| Danny Smith <dannysmith@clear.net.nz> writes:
| > Hello Zack, Geoff.
| >
| > Thanks for your help. I have followed your suggestions and now all pch
| > testsuite pass! I have also simplified mingw32_gt_pch_use_address, to
| > simply return 0 if called with size == 0.
| >
| > I do not like the idea of changing the pch file to text mode on windows
| > host. Changing asm_out_file to 'b' is a safer option for mingw32, since
| > the MS runtime fseek and ftell are not reliable in text mode (according to
| > MS docs and a lot of mingw bug reports) because of CRLF<->LF translations
| > and the CTRL-Z EOF marker
| >
| > Revised patch is attached.
|
| The patch is OK.
|
| ISO C requires that fseek and ftell work in text mode, in the sense
| that you can ftell and then fseek to that number; there is also
| fsetpos and fgetpos.
According to MS docs, msvcrt version of fseek in text mode is quarantted to
work when seeking from the beginning of the file with an offset value returned
from a call to ftell, so that would work..
|I'm pretty sure the code to copy the asm file
| around is *not* valid on all platforms; I'd encourage you to rewrite
| it portably.
Can you be more specific?
I noticed in ggc_common.c:gt_pch_save, there is an fseek past EOF
to mmi.offset, followed by a fwrite in ggc_[page|zone].c:ggc_pch_write_object.
Is it necessary that this offset padding be zero'd out. On WinNT it is.
On Win9x it is not, but filled with whatever happens to be in memory.
|I'm worried that someone has a Windows environment in which
| they use some other assembler, which doesn't accept LF only.
AFAICT GCC for windows hosts/targets has always been fairly
dependent on GAS. All windows targets include i386/gas.h.
I don't know of any AT&T style assembler that doesn't accept LF only
Come to think of it, even the windows native compiler (which has integrated assembler)
accepts LF-only source files.
Danny
|
| --
| - Geoffrey Keating <geoffk@geoffk.org>