Re: [RFA] Invalid mmap(2) assumption in pch (ggc-common.c)

[Stuart Hastings]

On Apr 23, 2005, at 5:42 PM, Matt Thomas wrote:
Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64
results in most tests failing like:
:1: fatal error: had to relocate PCH
compilation terminated.
compiler exited with status 1
This is due to a misassumption in ggc-common.c:654
(mmap_gt_pch_use_address):
   This version assumes that the kernel honors the START operand of 
mmap
   even without MAP_FIXED if START through START+SIZE are not currently
   mapped with something.

That is not true for NetBSD.  Due to MMU idiosyncracies, some 
architecures
(like sparc and sparc64) will align mmap requests that don't have 
MAP_FIXED
set for architecture specific reasons).

Is there a reason why MAP_FIXED isn't used even though it probably
should be?
I can't speak directly to your question, but you might try the version 
in config/host-darwin.[ch].  This implementation statically allocates a 
1G array in the bss, unmaps it, and maps the PCH there.  As the 
commentary indicates, it looks kludgy, but it does seem to make PCH 
more reliable.

I'm not absolutely clear on the details anymore, but I think you need 
host-darwin.c in your link, and host-darwin.h must be #included 
wherever you initialize your host langhooks.

(You could also try MAP_FIXED yourself; that's certainly easier than my 
suggestion above.  :-)

stuart hastings
Apple Computer

pr11135: make PIC register a pseudo

[Stuart Hastings]

Regarding

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135

How much effort would it take to fix this, at least for x86 (32-bit)?

stuart hastings
Apple Computer

strict aliasing issue

[Stuart Hastings]

Here's my reduced testcase:

typedef long GLint;
extern void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
  const int *blist;
  int list[32];
  if (alistp)
blist = alistp;
  else {
list[3] = 42;   /* this store disappears with -O1 -fstrict- 
aliasing */

blist = list;
  }
  aglChoosePixelFormat((GLint*)blist);
}

(The original testcase is C++, from the FLTK project.)

If I compile this with -O1 -fstrict-aliasing, the "= 42" store  
disappears.  I've confirmed this on mainline PPC and x86.


I'm not a language lawyer; is this a legal program?  (If the program  
is legal, should I file a PR?)


stuart hastings
Apple Computer