This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
pch on sparc64
- From: ja2morri at csclub dot uwaterloo dot ca (James A. Morrison)
- To: gcc at gcc dot gnu dot org
- Cc: davem at redhat dot com
- Date: 06 Nov 2004 11:58:01 -0500
- Subject: pch on sparc64
Hi,
The recent VIS patch I sent seems to tickle a couple new pch failures on
sparc64-linux. I tried setting TRY_EMPTY_VM_SPACE to 0x60000000 for all
sparc targets. This fixes the largefile testcase on sparc and sparc64.
However, on the save-temps-1.c at low optimization levels, e.g. -O0 -g,
pch fails because it can't allocate at the given address.
What I find strange about these failures is that the allocated memory
is only 1 page off of the target memory and for the failure cases the offset
passed to mmap_gt_pch_use_address is 8192 larger than the offset passed to
mmap_gt_pch_use_address when the testcase passes, e.g. at -O2.
Here is the output from gcc.db/pch/save-temps-1.c failing
0x8000002000, 0x8000000000: 40960
<built-in>:0: fatal error: had to relocate PCH
compilation terminated.
FAIL: gcc.dg/pch/save-temps-1.c -O0 -g (test for excess errors)
However, when the testcase is passing we get something more like:
0x8000000000, 0x8000000000: 32768
0x8000000000, 0x8000000000: 32768
To explain the random numbers I am posting, I have mmap_gt_use_pch_address
printing out: addr, base: offset . Base is what is expected, addr is what
we get and offset is the offset passed to mmap.
Anyone have any ideas what the proper fix to this is? I tried adding
MAP_FIXED to the mmap call in mmap_gt_pch_use_address and that fixed the
problem.
--
Thanks,
Jim
http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim