James Carlson wrote: > "C. Bergstr?m" writes: > >> James Carlson wrote: >> >> ... > Do you mean the www.open64.net "open research compiler?" If so, then > I don't doubt that there'll be issues. > > I don't know what the other consolidations are doing, but for ON, we > intentionally committed to supporting only two C/C++ compilers: Sun's > WorkShop and gcc. Even at that, we support only very specific > versions of each, and changing versions is a big deal, requiring > extensive testing, and often some code rework. Supporting a brand new > compiler in the chain would be quite hard. > > Real support here means not just getting it to compile once. Nor is > it sufficient to integrate fixes and hope for the best in the future. > To get real support, all of the contributors need to build and test > with all of the supported compilers (so that they know they're not > contributing things that will break others), and the gatekeepers as > well have to build regularly with all of the supported build > environments. It's a change of process as well as a change of code. > > It sounds like an interesting project, but unless there's some buy-in > from the others who'd be affected, I think you might be talking about > a fork of the code. > >
I'm not sure I would call it a brand new compiler since open64 shares the same frontend as gcc and cw/aw would function the same, but the code generation on the backend certainly would change.. I've fairly optimistic experience with the PathScale backend and optimization tools for it, but that's another discussion. /we/ are not planning to fork the code, but will almost certainly be an external gate.. it will start as a slave and then if/when we get contributions which meet the level of engineering/licensing (be that patches/bug fixes or new implementations..) we'll merge it.. QA/auto build and other things are planned because frankly I trust a centralized approach in *addition* to developer check to add another layer. imho Sun should at the very least eat their own dog food and support whatever the latest SSX is available as well. I mean.. why release that if it can't even compile onnv-gate.. there's _SSNEXT variable in Makefile.master just for this.. why it's not used.. ? I appreciate the input.. if you want to elaborate on the political situation for any potentially soon to be open sourced bits that could benefit my/others efforts I'm all ears.. Cheers, ./Christopher
