This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcj/sparc64?
- From: Brian Dessent <brian at dessent dot net>
- To: Jay <jayk123 at hotmail dot com>
- Cc: Andrew Haley <aph at redhat dot com>, tromey at redhat dot com, gcc at gcc dot gnu dot org
- Date: Sun, 10 Aug 2008 01:49:05 -0700
- Subject: Re: gcj/sparc64?
- References: <1216680495.31069.ezmlm@gcc.gnu.org> <COL101-W834B0BE1410DDD2EA7AF9EE6870@phx.gbl> <m3k5fbl4ly.fsf@fleche.redhat.com> <488B3E30.1090008@redhat.com> <COL101-W81D72D008BD8C93AC10988E6760@phx.gbl>
- Reply-to: gcc at gcc dot gnu dot org
Jay wrote:
> /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in
> ternal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
This stack exhaustion is PR36218 which was supposedly fixed on
mainline. Two problems: the fix needs to be extended to Cygwin as well
as MinGW, and you're not building mainline.
> I wish Windows code was PIC, then wouldn't worry about base addresses and
> the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g. vtables).
With --enable-auto-image-base this becomes nearly a non-issue. Libtool
has been enabling that by default on PE for a long time. There was also
a patch several years ago to support a variant of ELF-style PIC on
Windows, but it was never reviewed nor commented on. The ABI
implications probably make this infeasible anyway. In any case this has
zero to do with the topic of this thread.
Brian