Are you aware of bug 14206? Maybe it is not your problem, but before we start 
investigating...

So is exec-shield-randomize your problem?

Unfortunately, I have no idea what you are refering to. 
 
I am running Suse 9.0 with a stock 2.4.21-192 kernel. There is no entry named 
exec-shield or similar in the proc filesystem. As well, there is no variable of 
that name in one of the kernel configuration modules of Yast2, Suse's 
administration tool. 
 
(In reply to comment #2) 
> So is exec-shield-randomize your problem? 
 
 

Retargeted to 3.4.0 in the hopes that we can understand what's going on before
the release.

Can you try with a newer 3.4.0 as this issue might have been PR 14137.

It is not fixed: 
 
gcc -v -c -include qt -pipe -Wall -W -O2 -fPIC -DQT_SHARED -DQT_NO_DEBUG 
-DQT_NO_CUPS -D_LARGEFILE_SOURCE -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 
-DQT_NO_IMAGEIO_MNG -DQT_NO_IMAGEIO_JPEG -DQT_NO_STYLE_MAC -DQT_NO_STYLE_AQUA 
-DQT_NO_STYLE_INTERLACE -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_COMPACT 
-DQT_NO_STYLE_POCKETPC -I/home/peter/gnu/qt-x11-free-3.3.0/mkspecs/linux-g++ 
-I. -I/usr/include/freetype2 -I3rdparty/libpng -I3rdparty/zlib -I3rdparty/
opentype -I../include -I/usr/X11R6/include -I.moc/release-shared/ -o .obj/
release-shared/pngrtran.o 3rdparty/libpng/pngrtran.c 
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/specs 
Configured with: ../gcc/configure --enable-threads=posix --enable-languages=c,c
++,f77,objc --enable-__cxa_atexit --enable-libstdcxx-debug 
Thread model: posix 
gcc version 3.4.0 20040326 (prerelease) 
 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.0/cc1 -quiet -v -I/home/peter/
gnu/qt-x11-free-3.3.0/mkspecs/linux-g++ -I. -I/usr/include/freetype2 
-I3rdparty/libpng -I3rdparty/zlib -I3rdparty/opentype -I../include -I/usr/
X11R6/include -I.moc/release-shared/ -DQT_SHARED -DQT_NO_DEBUG -DQT_NO_CUPS 
-D_LARGEFILE_SOURCE -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -DQT_NO_IMAGEIO_MNG 
-DQT_NO_IMAGEIO_JPEG -DQT_NO_STYLE_MAC -DQT_NO_STYLE_AQUA 
-DQT_NO_STYLE_INTERLACE -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_COMPACT 
-DQT_NO_STYLE_POCKETPC -include qt 3rdparty/libpng/pngrtran.c -quiet -dumpbase 
pngrtran.c -mtune=pentiumpro -auxbase-strip .obj/release-shared/pngrtran.o -O2 
-Wall -W -version -fPIC -o - | 
 as -V -Qy -o .obj/release-shared/pngrtran.o - 
ignoring nonexistent directory "NONE/include" 
ignoring nonexistent directory "/usr/local/lib/gcc/
i686-pc-linux-gnu/3.4.0/../../../../i686-pc-linux-gnu/include" 
#include "..." search starts here: 
#include <...> search starts here: 
 /home/peter/gnu/qt-x11-free-3.3.0/mkspecs/linux-g++ 
 . 
 /usr/include/freetype2 
 3rdparty/libpng 
 3rdparty/zlib 
 3rdparty/opentype 
 ../include 
 /usr/X11R6/include 
 .moc/release-shared/ 
 /usr/local/include 
 /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/include 
 /usr/include 
End of search list. 
GNU C version 3.4.0 20040326 (prerelease) (i686-pc-linux-gnu) 
	compiled by GNU C version 3.4.0 20040326 (prerelease). 
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64274 
GNU assembler version 2.14.90.0.5 (i586-suse-linux) using BFD version 
2.14.90.0.5 20030722 (SuSE Linux) 
In file included from 3rdparty/libpng/png.h:329, 
                 from 3rdparty/libpng/pngrtran.c:17: 
3rdparty/zlib/zlib.h:75: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
 
 

I was able to recreate this problem with the 3.4 branch compiler.  The problem
is that the PCH is loaded at an address which is not the address at which it was
saved.  On the 3.4 branch this leads to a segmentation violation, because of
some code which uses mincore to check whether an address is available.  mincore
on Linux does not work as expected, so that code loads the PCH on top of memory
space which is already being used.  The result is a crash.  This particular
problem does not occur on mainline, because the code which calls mincore has
been moved to host-solaris.c, and thus is not called on Linux.

If I change line 610 of ggc-common.c to
#if HAVE_MINCORE && ! defined (__linux__)
then I get a sorry() message.

Now, why does the mmap return a different value?  It is because the input file
is large--142253 bytes.  The input file is loaded into memory in
c_common_post_options.  The -include command line option is processed by
finish_options(), called just before c_parse_file().  Since the input file is so
large, the memory map is changed before gcc tries to load the PCH.  The effect
is that the PCH winds up at the wrong address.

I suspect that this is a general problem with PCH, and that the problem will
also occur with mainline.  However, I haven't tried it yet.

I don't see any good fix for this at the moment.  I suspect that PCH is going to
generally break when used with large input files, except on Darwin which does
not use the mmap scheme.  But I haven't verified it.

I believe I saw this on Darwin before implementing the scheme it uses now.  I don't believe there's any 
solution to the general problem that doesn't know more about the host's memory map; the current 
generic solution is just a heuristic and is not reliable.  For reliable operation, *especially* on x86-linux-
gnu, I recommend implementing a solution like Darwin's.  That would also fix 14206.

This is not a problem that you can solve with a 'quick fix'.  It's possible to have an arbitrary amount of 
memory allocated before the PCH file is loaded, even if you do something special for the main input 
file.  All you need to do is ensure that more memory is allocated before the PCH file is loaded than was 
allocated before it was saved.  I would suggest a test case where the PCH file is empty, and the main 
input file looks like

#define FOO_1 "1234567890"
#define FOO_2 "1234567891"
...
#define FOO_1000 "1234568889"
#include "empty.h"

maybe with more complicated macro definitions, to use as much memory as possible.
 

Subject: Re:  Cannot compile qt-x11-free-3.3.0

"geoffk at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> I believe I saw this on Darwin before implementing the scheme it uses now.  I don't believe there's any 
> solution to the general problem that doesn't know more about the host's memory map; the current 
> generic solution is just a heuristic and is not reliable.  For reliable operation, *especially* on x86-linux-
> gnu, I recommend implementing a solution like Darwin's.  That would also fix 14206.

PR 14206 is fixed on mainline by RTH's patch.  For 3.4 I put in a doc
fix.

> This is not a problem that you can solve with a 'quick fix'.

Perhaps for 3.4 we should disable PCH for any target other than
Darwin.  It seems to me that it is a bad idea to include an unreliable
feature.  It's particularly unfortunate that it causes gcc 3.4 to fail
to build a popular package (qt-x11-free) on a popular platform
(GNU/Linux).  It's even more unfortunate that the failure currently
shows up as a random compiler crash.

I will investigate further on mainline.

Ian

Subject: Re:  Cannot compile qt-x11-free-3.3.0


On Mar 29, 2004, at 11:06 PM, Ian Lance Taylor wrote:

> "geoffk at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>
>> I believe I saw this on Darwin before implementing the scheme it uses 
>> now.  I don't believe there's any
>> solution to the general problem that doesn't know more about the 
>> host's memory map; the current
>> generic solution is just a heuristic and is not reliable.  For 
>> reliable operation, *especially* on x86-linux-
>> gnu, I recommend implementing a solution like Darwin's.  That would 
>> also fix 14206.
>
> PR 14206 is fixed on mainline by RTH's patch.  For 3.4 I put in a doc
> fix.

I've now caught up enough that I read RTH's patch (I've been on 
vacation).  Yes, that patch should fix this problem too.  I'd suggest 
backporting it to 3.4.

Subject: Re:  Cannot compile qt-x11-free-3.3.0

"geoffk at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

> On Mar 29, 2004, at 11:06 PM, Ian Lance Taylor wrote:

> > PR 14206 is fixed on mainline by RTH's patch.  For 3.4 I put in a doc
> > fix.

> I've now caught up enough that I read RTH's patch (I've been on 
> vacation).  Yes, that patch should fix this problem too.  I'd suggest 
> backporting it to 3.4.

We can do that.  However, I am still troubled by the fact that the
default fallback for gt_pch_get_address/gt_pch_use_address is
unreliable.  RTH's patch may well fix the problem on GNU/Linux for all
but strange cases.  But it seems to me that with that patch PCH will
work reasonably on GNU/Linux and on Darwin, but will not work reliably
on any other system.

That is, I don't think that any system can reliably use
mmap_gt_pch_get_address/mmap_gt_pch_use_address, although they are the
default functions on a system which supports mmap.

Is it better to have PCH which unpredictably fails or PCH which
reliably fails?  Right now, in mainline, I think we have the former,
except on GNU/Linux and Darwin.

Ian

Subject: Re:  Cannot compile qt-x11-free-3.3.0


On 02/04/2004, at 7:17 AM, Ian Lance Taylor wrote:

> "geoffk at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
>
>> On Mar 29, 2004, at 11:06 PM, Ian Lance Taylor wrote:
>
>>> PR 14206 is fixed on mainline by RTH's patch.  For 3.4 I put in a doc
>>> fix.
>
>> I've now caught up enough that I read RTH's patch (I've been on
>> vacation).  Yes, that patch should fix this problem too.  I'd suggest
>> backporting it to 3.4.
>
> We can do that.  However, I am still troubled by the fact that the
> default fallback for gt_pch_get_address/gt_pch_use_address is
> unreliable.  RTH's patch may well fix the problem on GNU/Linux for all
> but strange cases.  But it seems to me that with that patch PCH will
> work reasonably on GNU/Linux and on Darwin, but will not work reliably
> on any other system.
>
> That is, I don't think that any system can reliably use
> mmap_gt_pch_get_address/mmap_gt_pch_use_address, although they are the
> default functions on a system which supports mmap.
>
> Is it better to have PCH which unpredictably fails or PCH which
> reliably fails?  Right now, in mainline, I think we have the former,
> except on GNU/Linux and Darwin.

I think that PCH that fails on one case out of a thousand is better 
than PCH that fails in one thousand cases out of one thousand.  
However, it would be better if we could make failure even less frequent 
by tweaking the heuristic.  Ian, you've studied the problem, do you 
have any suggestions for a better heuristic?  Maybe gt_pch_get_address 
should map, say, 32M of unused memory before trying to allocate space 
for the PCH.

Subject: Re:  Cannot compile qt-x11-free-3.3.0

Geoffrey Keating <geoffk@apple.com> writes:

> I think that PCH that fails on one case out of a thousand is better
> than PCH that fails in one thousand cases out of one thousand.

Any thoughts on how difficult it would be to, when a PCH can not be
loaded at the correct address, skip the PCH and try for the original
header files?  We'd want to issue a warning, but the result will still
be better then a compiler crash, particularly since the crash will be
awkward to work around without manually removing the PCH.  Of course,
the result will not necessarily be equivalent--the original headers
might not be present, or might have been modified since the PCH was
created.

Ian

I've confirmed that 3.3.3 can build qt-x11-free-3.3.0 on i686-pc-linux-gnu, so
this is a 3.4 regression.  I suspect that it is also a 3.5 regression on some
systems, but I have not yet confirmed that.

Subject: Re:  Cannot compile qt-x11-free-3.3.0

On Saturday, April 3, 2004, at 07:38 PM, Ian Lance Taylor wrote:
> Any thoughts on how difficult it would be to, when a PCH can not be
> loaded at the correct address, skip the PCH and try for the original
> header files?

Just move the call that tries the mmap of the pch file to the 
validation routine.  The issue there is we'd need to think about trying 
to mmap twice.  Currently, we only ever do it once.  We would try and 
mmap more than once when there are multiple PCH files for the same 
source, as we run thought all of them, trying to validate each one.

> Of course, the result will not necessarily be equivalent--the original 
> headers
> might not be present, or might have been modified since the PCH was 
> created.

This issue is known and expected and not an issue.

Subject: Re:  Cannot compile qt-x11-free-3.3.0


On Apr 3, 2004, at 7:38 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@apple.com> writes:
>
>> I think that PCH that fails on one case out of a thousand is better
>> than PCH that fails in one thousand cases out of one thousand.
>
> Any thoughts on how difficult it would be to, when a PCH can not be
> loaded at the correct address, skip the PCH and try for the original
> header files?  We'd want to issue a warning, but the result will still
> be better then a compiler crash, particularly since the crash will be
> awkward to work around without manually removing the PCH.  Of course,
> the result will not necessarily be equivalent--the original headers
> might not be present, or might have been modified since the PCH was
> created.

The primary difficulty that I see would be in documenting this, that is 
that the result is not convenient to use.  At the moment, the 
documentation for PCH describes everything that you need to do to use a 
PCH, and it's agreed that cases where it does not work are bugs.  
Adding an extra clause that says "oh, and even if you follow these 
rules, on some platforms the compiler might just decide it doesn't like 
your PCH" does not seem very helpful.  Especially if it doesn't come 
with a list of those platforms.

The other difficulty is that I'm not sure that you can always back out 
of the address-space allocation.  I would probably have to see a patch 
before I could say how difficult that might be.

Again, my experience is that on all unix-like platforms, you *can* 
always get a suitable chunk of address space in some fashion, if you 
try hard enough.  For example, HP-UX was quoted as an OS on which it is 
difficult to do this, yet with less than ten minutes' searching the 
web, I found 
<http://docs.hp.com/hpux/onlinedocs/5965-4642/5965-4642.html> which 
seems to give sufficient information under 'Space apportioned to a 
Process"; apparently on HP-UX 10.x in 32-bit mode, data lives beween 
0x40000000 and 0x7fffffff, with a default stack size of 80Mb, so 
probably mapping the PCH so that its end was at 0x6fffffff would work.

Subject: Re:  Cannot compile qt-x11-free-3.3.0

Geoff Keating <geoffk@apple.com> writes:

> On Apr 3, 2004, at 7:38 PM, Ian Lance Taylor wrote:
> 
> > Any thoughts on how difficult it would be to, when a PCH can not be
> > loaded at the correct address, skip the PCH and try for the original
> > header files?  We'd want to issue a warning, but the result will still
> > be better then a compiler crash, particularly since the crash will be
> > awkward to work around without manually removing the PCH.  Of course,
> > the result will not necessarily be equivalent--the original headers
> > might not be present, or might have been modified since the PCH was
> > created.

...

> Again, my experience is that on all unix-like platforms, you *can*
> always get a suitable chunk of address space in some fashion, if you
> try hard enough.

Even if that turns out to be true, it doesn't really help us with a
gcc release when in actual fact that work has only been done on two
platforms, namely Darwin and GNU/Linux.  Nobody is working to fix this
on mainline, much less for 3.4.

You didn't like the idea of disabling PCH on other platforms, so we
have to consider the case in which there is no platform specific
implementation, and the default implementation of PCH, using mmap,
fails.  Right now, in that case, the compiler simply fails, either
with a segmentation violation or a call to sorry, and it is rather
difficult to work around the crash without simply discarding the PCH.

Ian

Confirmed that mainline fails to compile qt-x11-free-3.3.0 on i386-netbsdelf.

Can QT be compiled if PCH is explicitly not used?

In other words, could the QT Makefiles work around this problem by not using a
PCH file?

Based on the kinds of problems that people are seeing with our current PCH
implementation, I'm planning to add a note to the documentation that indicates
that the PCH implementation is an experimental "technology preview".

Geoff's opinions on the desirable tradeoffs in terms of reliability don't seem
to line up with mine or Ian's.  I suspect that part of the issue is that PCH is
most reliable on Darwin, and so the perception there is that it's very solid,
where as on most (all?) other operating systems the kind of problem described in
this bug report is relatively frequent.

By adjusting the documentation, I think we can leave the feature enabled, but
still caution people against relying upon it.

well, currently Qt >= 3.3.0 enables PCH support if it detects that the 
compiler is gcc and that it supports the -x option. I think you can manually 
disable the pch support with the configure script.  
 
There are a few possible solutions:  
 
a) make the default for PCH to off in newer Qt 3.3 releases. I guess 
TT would do that change if asked to.  
 
b) disable -x flag unless -yes-i-know-it-is-buggy flag is given. this way 
the configure would fail, and not enable PCH.  
 
right now the only problem I see with PCH except this bug is however that 
you cannot combine the PCH header for C and C++ compilations.  
 

Subject: Re:  [3.4/3.5 regression] Cannot compile qt-x11-free-3.3.0

"mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> Can QT be compiled if PCH is explicitly not used?
> 
> In other words, could the QT Makefiles work around this problem by not using a
> PCH file?

I have confirmed that, if I comment out the line in the QT configure
script where QT tests for PCH support, the build gets past the
previous point of failure, using the 3.4 branch compiler on
i686-pc-linux-gnu.  QT takes forever to build on my system; I will
report back in this PR if there is any failure later in the build.
Pending that, the answer to your question is "yes."

For the record, the change I made to the configure script was to
comment out this line:

$unixtests/precomp.test $XQMAKESPEC $OPT_VERBOSE || QMAKE_CONFIG="$QMAKE_CONFIG precompile_header"

precomp.test is a fairly simple test which checks to see whether the
compiler accepts "-x c-header" and "-x c++-header".  I don't see any
obvious way to use a command line argument to affect the test result.

Subject: Re:  [3.4/3.5 regression] Cannot compile qt-x11-free-3.3.0

Ian Lance Taylor wrote:

>"mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>
>  
>
>>Can QT be compiled if PCH is explicitly not used?
>>
>>In other words, could the QT Makefiles work around this problem by not using a
>>PCH file?
>>    
>>
>
>I have confirmed that, if I comment out the line in the QT configure
>script where QT tests for PCH support, the build gets past the
>previous point of failure, using the 3.4 branch compiler on
>i686-pc-linux-gnu.  QT takes forever to build on my system; I will
>report back in this PR if there is any failure later in the build.
>Pending that, the answer to your question is "yes."
>  
>
Thanks for the research.

Given that, I'll adopt the documentation approach to this problem.  PCH 
seems to be useful for lots of people, but we ought to warn people that 
there are problems.

Thanks,

This is not really a regression as PCH was not in 3.3.3 at all, the building of qt is the regression.

Subject: Re:  Cannot compile qt-x11-free-3.3.0

Huh?  This is definitely a regression.  gcc 3.3.3 can build
qt-x11-free-3.3.0.  gcc 3.4.0 can not.

Yes, the underlying problem is a PCH problem, and gcc 3.3.3 does not
have PCH.  But being unable to build qt-x11-free-3.3.0 is a clear
regression.  The PR exists because the ability to build qt-x11-free
was a release criterion for 3.4, according to the initial PR
submission.

Ian

Just a note that 3.4 completes the build of qt-x11-free-3.3.0 when the configure
script is edited to make it appear that PCH is not supported.

Since there is a workaround (disabling PCH), I've postponed this until 3.4.1.

Does this problem still exist?

Subject: Re:  Cannot compile qt-x11-free-3.3.0

"geoffk at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> Does this problem still exist?

Yes, on mainline we still have a problem compiling qt-x11-free-3.3.0
on, e.g., i386 NetBSD.  It crashes when using the PCH.  There is a
brief note in the PR on 2004-04-06.

You've suggested some approaches which I expect will work, but I
haven't implemented anything yet.  (Not that I want to have a monopoly
on fixing this problem, of course.)

Ian

Subject: Re:  Cannot compile qt-x11-free-3.3.0


On 12/04/2004, at 3:06 PM, Ian Lance Taylor wrote:

> "geoffk at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>
>> Does this problem still exist?
>
> Yes, on mainline we still have a problem compiling qt-x11-free-3.3.0
> on, e.g., i386 NetBSD.  It crashes when using the PCH.  There is a
> brief note in the PR on 2004-04-06.
>
> You've suggested some approaches which I expect will work, but I
> haven't implemented anything yet.  (Not that I want to have a monopoly
> on fixing this problem, of course.)

The original bug was on i686-linux.  Does QT build on i686-linux?  If 
it does, could you open a new bug for the new problem(s)?

Subject: Re:  Cannot compile qt-x11-free-3.3.0

Geoffrey Keating <geoffk@apple.com> writes:

> The original bug was on i686-linux.  Does QT build on i686-linux?  If
> it does, could you open a new bug for the new problem(s)?

OK, if you find that useful, I opened PR 14940 for mainline.  I
phrased it in terms of the largefile test to make it easier to
recreate.

I believe that PR 14400 is fixed on mainline for i686-pc-linux-gnu,
though it is not fixed for 3.4.0.

Ian

So, the appropriate fix for *this* bug is to backport RTH's change to the 3.4 branch?

Subject: Re:  Cannot compile qt-x11-free-3.3.0

"geoffk at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> So, the appropriate fix for *this* bug is to backport RTH's change to the 3.4 branch?

I think we have some sort of mutual misunderstanding as to what this
PR represents.

If we interpret this PR as being specific to i686-pc-linux-gnu, then,
yes, backporting RTH's changes would fix it.

However, this bug exists because one of the gcc 3.4 release criteria
was that gcc 3.4 be able to compile QT, as described here:
    http://gcc.gnu.org/gcc-3.4/criteria.html

Personally, I would interpret that as meaning that QT should build on
each relevant primary evaluation platform, which includes
i386-unknown-freebsd among other non-GNU/Linux systems.

This PR was filed because of a test of the release criteria, not
because of a specific GNU/Linux issue.  See the initial report in the
PR.

Backporting RTH's fix would be a good idea.  And it would fix this PR
as narrowly construed.  But it would not fix the idea behind this PR,
which is that QT compile with gcc 3.4 on all relevant systems.  That's
why I haven't pushed to backport RTH's fix: because the PR, in the
general case, isn't fixed in mainline, either.  I think that fixing it
properly in mainline is a prerequisite to fixing it in 3.4.

Ian

I don't know if we have a mutual understanding.  This bug is "Cannot compile qt-x11-free-3.3.0" on 
"i686-pc-linux-gnu" because of "pch".  If backporting RTH's fix means that qt does build on i686-
linux (or at least doesn't fail because of pch), then backporting RTH's fix will fix this bug, and so the 
release criteria test as described in this PR should pass.

I don't know how to fix an idea.  That seems like it's outside the scope of software engineering.

I think that in the general case, this bug and similar bugs must be fixed in each specific case.  So it's 
not helpful to try to have a bug tracking the general case.

Geoff, Ian --

Let's not to try to do more than we can.  If we have a fix for this specific
problem, let's apply it, and close the PR.  I agree that there's more to do down
the road, probably, but we'll have made 3.4.1 more useful to more people, and
that's the goal.

-- Mark

It looks like the state is that nobody has fixed the more general problems with
PCH, and we still haven't applied the more targeted fix that might help on some
platforms.  How sad.

Postponing until GCC 3.4.2.

Postponed until GCC 3.4.3.

Postponed until GCC 3.4.4.

*** Bug 21013 has been marked as a duplicate of this bug. ***

Subject: Bug 14400

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ian@gcc.gnu.org	2005-08-02 19:03:46

Modified files:
	gcc            : ChangeLog c-pch.c config.host ggc-common.c 
	                 hooks.c hooks.h hosthooks-def.h hosthooks.h 
	gcc/config/rs6000: host-darwin.c 
	gcc/doc        : hostconfig.texi 
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gcc.dg/pch: pch.exp 
Added files:
	gcc/config     : host-linux.c host-solaris.c x-linux x-solaris 

Log message:
	./
	PR pch/14400
	Backport from mainline:
	
	2005-08-01  Ian Lance Taylor  <ian@airs.com>
	
	* config/host-linux.c (linux_gt_pch_get_address): Add new name
	randomize_va_space for virtual address randomization control.
	
	2005-02-15  James A. Morrison  <phython@gcc.gnu.org>
	
	PR pch/14940
	PR target/19300
	* config/host-linux.c (linux_gt_pch_use_address): Copy from
	config/pa/pa-host.c:pa_gt_pch_use_address.
	
	2004-11-09  James A. Morrison  <phython@gcc.gnu.org>
	
	PR pch/14940
	* config/host-linux.c (TRY_EMPTY_VM_SPACE): Add __sparc__
	definitions.
	
	2004-10-15  Jon Grimm <jgrimm2@us.ibm.com>
	
	* config/host-linux.c (TRY_EMPTY_VM_SPACE): Add __powerpc__
	definition.
	
	2004-04-24  Ulrich Weigand  <uweigand@de.ibm.com>
	
	* config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __s390__
	and __s390x__ hosts.
	
	2004-04-08  Ian Lance Taylor  <ian@wasabisystems.com>
	
	* config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address):
	Return 1 if file was successfully mapped.
	
	2004-03-15  Ian Lance Taylor  <ian@wasabisystems.com>
	
	* config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address):
	Fix the check for abort and only do the mmap if we can.
	
	2004-03-12  Andrew Pinski  <apinski@apple.com>
	
	* config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address):
	Use ret instead of result. Use addr instead of base.
	
	2004-03-10  Richard Henderson  <rth@redhat.com>
	
	* c-pch.c (c_common_no_more_pch): Update for gt_pch_use_address
	extra arguments.
	* config.host (*-*-solaris2*, *-*-linux*): Add out_host_hook_obj
	and host_xmake_file fragments.
	* ggc-common.c (gt_pch_save): Update for gt_pch_get_address change.
	(gt_pch_restore): Similarly for gt_pch_use_address.
	(default_gt_pch_get_address): New.
	(mmap_gt_pch_get_address): Split out of gt_pch_save.
	(default_gt_pch_use_address): Split out of gt_pch_restore.
	(mmap_gt_pch_use_address): Likewise.
	* hooks.c (hook_voidp_size_t_null): Remove.
	(hook_bool_voidp_size_t_false): Remove.
	* hooks.h: Likewise.
	* hosthooks-def.h (HOST_HOOKS_GT_PCH_GET_ADDRESS): Use one of the
	default_ or mmap_ definitions.
	(HOST_HOOKS_GT_PCH_USE_ADDRESS): Likewise.
	* hosthooks.h (struct host_hooks): Update gt_pch_get_address
	and gt_pch_use_address.
	* config/host-linux.c, config/host-solaris.c: New files.
	* config/x-linux, config/x-solaris: New files.
	* config/rs6000/host-darwin.c darwin_rs6000_gt_pch_get_address):
	Update for changed definition.
	(darwin_rs6000_gt_pch_use_address): Likewise.
	* doc/hostconfig.texi: Update docs.
	testsuite/
	PR pch/14400
	Backport from mainline:
	
	2004-04-07  Ian Lance Taylor  <ian@wasabisystems.com>
	
	* gcc.dg/pch/pch.exp: Add largefile test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.893&r2=2.2326.2.894
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pch.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.19.4.1&r2=1.19.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.host.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.7&r2=2.7.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ggc-common.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.78&r2=1.78.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hooks.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.22.10.2&r2=1.22.10.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hooks.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.23.10.2&r2=1.23.10.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hosthooks-def.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hosthooks.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.4&r2=1.4.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.11.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-solaris.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/x-linux.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.6.48.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/x-solaris.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.2.50.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/host-darwin.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/hostconfig.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.416&r2=1.3389.2.417
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pch/pch.exp.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.8&r2=1.8.18.1

Now fixed on 3.4 branch.  It was already fixed for 4.0 and later.