This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR target/16344
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: geoffk at geoffk dot org (Geoff Keating)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 5 Jul 2004 14:55:57 -0400 (EDT)
- Subject: Re: [PATCH] Fix PR target/16344
> > - if (v.pch_init != &pch_init)
> > + if (v.pch_init != (void *) &pch_init || v.pch_init != &pch_init)
> > {
> > if (cpp_get_options (pfile)->warn_invalid_pch)
> > cpp_error (pfile, CPP_DL_WARNING,
>
>
> I would suggest just comparing the pointers as cast to 'void *'; or
> even using memcmp. If the pointers are bit-for-bit identical, there is
> no need to perform any canonicalized comparison.
Ok, will change to just use the pointers as cast to 'void *'.
> You do understand that you are patching the symptoms of the bug, not
> fixing the actual bug itself? The actual bug is that the PCH file is
> being built and used with different compiler binaries, probably because
> of the long-standing problem that libstdc++'s Makefile doesn't say that
> the PCH file depends on the compiler executable, and therefore doesn't
> rebuild it when the compiler is changed.
Yes, although I consider the SIGSEGV a bug. I was assuming that the
cause of the problem was a mmap issue. This was based on the fact that
the largefile.c test fails with 2.4 linux kernels. This is also a problem
under hpux. I haven't figured out what to do with this.
I'm fairly certain that I did a clean build. If the PCH file depends
on the compiler executable, this suggests that we aren't using the
newly built compiler to build the PCH file, or we aren't using the
PCH file that we think we are.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)