Re: Converting the gcc backend to a library?

[Jeffrey A Law <law at cygnus dot com>]

  In message <200001110910.BAA10070@lotus.CS.Berkeley.EDU>you write:
  > And "Martin v. Loewis" writes:
  >  - 
  >  - Can you please give me (or the list) a pointer to the software you are
  >  - talking about? (unless you'd violate your license agreement by doing
  >  - so, of course).
  > 
  > Tera's compilers:  www.tera.com
Really?

  > To be fair, I'm probably being paranoid about the backend.  I used 
  > some bugs I recalled to break the automatic parallelization, but
  > those bugs could well have been re-invented (or different but triggered
  > in similar ways).  The hw architecture is extremely different from 
  > anything gcc supports.
Yes, the hardware architecture is radically different than what GCC normally
targets.  And I do suspect you're being a little over-paranoid.

  > And the Edison-Group-based front-end is a separate executable, just as 
  > cc1, et al. are.  There are some extra c++ symbols in the tcc executable 
  > that aren't used in gcc.c, but they looked relatively unimportant.  I 
  > didn't press for the source beyond the initial ``no, look, it's only 
  > gcc.c''; I didn't have the time and I don't think I communicated my 
  > request well.  (And to think I wanted to help find their bugs.  Silly me.)
If all they're using is gcc, then it's not that big of a deal (personal
opinion).  They still have to give you that source under the terms of the
GPL, but gcc.c isn't really the compiler, it's just a driver that knows how
to start up cpp, cc1, as, ld, etc.

If indeed they were using GNU cc1 which was reading output from the EDG
front-end, then they must give you the source for cc1 under the terms of the
GPL.


  > It's much more likely that they did exactly what RMS doesn't want
  > initially... 
I doubt it.  More likely they never wrote code which reads/writes trees or
RTL to feed into GNU cc1 but just replaced cc1 with their own and continued
to use the gcc.c driver.

  > IDA/SRC seems to like starting with gcc)
Of course.  Why re-invent the wheel?  When I was with SRC we certainly hacked
GCC as our needs dictated.  But there wasn't anyone with a strong enough GCC
background to do the kinds of things that people have suggested here.

That doesn't mean that IDA/SRC couldn't have hired or grown these kinds of
hackers over the years (I left long ago), but I would be rather surprised.

jeff