Alexey,
> Glad to hear that this effort was made and that some x86 features went it.
> I'm mostly concerned about sparc side.
>
> Let's see:
> -fno-jump-tables for x86 - IN
> -mno-integer-ldd-std for sparc - not in
> -fno-constant-pools for x86 - not in
> -fno-dwarf2-indirect-strings - not in (no longer needed by ON?)
> ...
>
> Yep. ongoing need for the branch.
it depends: maybe some of those changes can be avoided on the ON side of
things, or the GCC maintainers could be persuaded to let them into
mainline.
> I guess that means we cannot test with mainline. Unless somebody is crazy
> enough to merge mainline with those extra features everytime ON needs to
> be build.
I don't think so. Those changes are probably pretty localized, so
semi-regular merges from mainline to an opensolaris branch shouldn't be
hard.
> So the question is whether we want csl managed branch with these extra
> features or our own ?
Since this is not only a CodeSourcery effort, but should be backed by the
OpenSolaris community, the branch names should reflect that. We need some
GCC contributors (perhaps including csl) to do the work, though.
> The version to be branched is secondary question.
Not really: we should decide what releases we need such branches from. It
should always be mainline to keep the changes up to date and develop new
ones if necessary (and unacceptable for GCC mainline), just the way ON
development goes: first develop on mainline, later backport if necessary.
> For the sparc side we'd like it to be our own GCCfss.
Why do you think this would be useful: if one wants the Studio backend, one
can use Studio cc directly. GCCfss is certainly useful for Solaris/SPARC
users, but I don't really see the benefit for ON.
> Anyway the ON changes will most certainly be independent of the compiler.
> The biggest gap is to go from 3.4 to 4.0
> All the subsequent releases are about the same from ON sources point of view.
Probably.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
