Re: More DG/UX Intel Build info

[Robert Lipe <robertlipe at usa dot net>]

> I've looked closely at the test results from the testsuite after building on
> DG/UX 4.20MU03 on the Intel platform.  I have the same tests failing here as
> for the linux gcc platform [execute/980526-1.c, ieee/980619-1.c,
> gcc.dg/980626-1.c, gcc.dg/clobbers.c, gcc.failure/940409-1.c], plus one
> other set --  loop-2e.c, loop-2f.c, and loop-2g.c in gcc.c-torture/execute.
> It seems this is a deficiency in the mmap() system call on DG/UX, in that
> setting a MAP_FIXED memory map address overwrites memory somehow, resulting
> in the exit() call failing.  In other words, the test itself succeeds and
> exit() gets an error!

I was mystified by this for a while.  I asked about it (look in
http://www.cygnus.com/ml/egcs/1998-Aug/index.html and search for
"loop-2") and found that these tests were carefully crafted to arrange
a memory range that spanned the boundary between signed and unsigned
memory addresses.

It seems to be quite sensitive to the facilities of the underlying
mmap() implementation.  I've seen the failure come and go in the same
binary depending on the kernel behind it.

FWIW, I see no evidence that this test has failed on my targets in the
trunk since April 8.

> The fix I used was to change from a MAP_FIXED argument to letting the mmap()
> call assign its own starting memory address.  These tests now succeed, and

By removing MAP_FIXED, you made the test not test what it was trying to
test. :-)