From Jim.Grisanzio at Sun.COM  Thu Feb 17 15:56:49 2005
From: Jim.Grisanzio at Sun.COM (Jim Grisanzio)
Date: Thu, 17 Feb 2005 15:56:49 -0800
Subject: [gcc] OpenSolaris gcc Project Opens
Message-ID: <42152F41.7060509@sun.com>

Guys ...

Some of you have mentioned at various times using gcc to build Solaris. 
Well, we also think it's important, and we'd like to begin work on this.

We opened a mail list (gcc at opensolaris.org) for discussion. Keith has 
done some research and will send out his preliminary findings as to what 
we need to do. We are looking for people who have familiarity with gcc 
and experience with specific areas that Keith outlines. Also, if anyone 
has written any tools that could be useful in this effort or has started 
  work toward building OpenSolaris with gcc, we'd love to hear from you. 
And, of course, we'd like to make sure you have the first opportunity to 
test the resulting changes and report any problems.

Interested?

If so, look for Keith's mail shortly and we'll get started. Sign up to 
the gcc at opensolaris.org list and respond there.


Jim


From keith.wesolowski at sun.com  Thu Feb 17 16:17:23 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 17 Feb 2005 16:17:23 -0800
Subject: [gcc] Initial gcc project worklist
Message-ID: <20050218001723.GA165606@sun.com>

As Jim mentioned, we're looking to start work making OpenSolaris build
with gcc for all supported architectures rather than just amd64.
Since there have been several discussions on this topic, we'd like to
open up the project to community participation from the beginning.

The included document is an initial attempt to assess what will be
needed to get a working OpenSolaris.  I expect it will grow as we
discover additional issues; if you have a specific concern, please be
sure to respond so that we can add it to the list.  This document is
also posted on the wiki at
https://www.opensolaris.org/projects/Wiki.jsp?page=Gcc; unfortunately
JSPWiki requires such heavy markup to get this kind of information to
display properly that it's not worth the effort.  This will presumably
encourage me to work on my AI to install TWiki on opensolaris.org. :-)

If you're interested in working on this or in following its progress,
or know of additional issues, please join gcc at opensolaris.org and
continue the discussion.  Reply-To is set to that list; please respect
that and spare the other opensolaris-discuss readers.

Thanks for your interest.

---8<---

Known Issues: Using gcc 3.4.3-csl to build ON on non-amd64

This document describes the known problems building ON with gcc.  It
is likely that once these problems are addressed, others will be
found, most notably in generated code.  Such problems, if encountered,
will require additional time to fix or work around, and may require
additional gcc work by CodeSourcery (CSL).

1. CTF tools

a. ctfconvert and ctfmerge do not understand the stabs format output
by gcc.  The workaround in place is to use DWARF2 instead; however
libdwarf and gcc appear to have at least one interoperability problem
(see below).  Either the CTF tools must be improved to understand
gcc's stabs format or the libdwarf-gcc interaction must be corrected.
It is probably quicker and easier to fix the DWARF2 interaction, since
I have already determined the high-level cause of the problem and
created a possible workaround in gcc.

Details: sun4u/genassym ctfstabs fails with messages about being
unable to find member named <lots of things>:

ctfstabs: Line 151: Couldn't find member named lwp_stime
ctfstabs: Line 151: Error found: skipping to the next blank line
ctfstabs: Line 173: Couldn't find member named rw_local
...

The problem here is that libdwarf (on SPARC at least) doesn't
understand the indirect strings (DW_FORM_strp) gcc gives it.

This problem is SPARC-specific.  GCC emits something like the
following for indirect strings:

        .section ".debug_info"
        .word   .L0
        .word   .L1
        .word   .L2
        .section ".debug_str"
.L0:
        .asciz  "broken"
.L1:
        .asciz  "hosed"
.L2:
        .asciz  "b0rk3d"

On SPARC, the assembler inserts relocations into .debug_info against
.L0, .L1, and .L2:

Relocation Section:  .rela.debug_info
        type                          offset     addend  section        with res
pect to
        R_SPARC_32                         0          0  .rela.debug_in .debug_s
tr (section)  
        R_SPARC_32                       0x4        0x7  .rela.debug_in .debug_s
tr (section)  
        R_SPARC_32                       0x8        0xd  .rela.debug_in .debug_s
tr (section)  

Therefore, until linking, all offsets will appear as 0 when read by
ctfconvert or dwarfdump.

A GCC-based fix is to add DWARF_NO_INDIRECT_STRINGS to
gcc/config/sparc/sparc.h and then always return DW_FORM_string in
dwarf2out.c:AT_string_form if that's defined.  This eliminates the
problem with the CTF tools but causes binaries built with gcc -g to
increase in size, possibly by a lot.  Note that DevPro cc in DWARF mode
uses this approach; it never emits DW_FORM_strp at all.

Alternately, genoffsets can be modified to run the compiled objects through
ld before passing them to ctfconvert.  This option requires more testing
but avoids the bloated-binary problem.

b. CTF's DWARF2 handler only knows about x86 real types.  They may be
(and are) different sizes on SPARC.  This causes ctfconvert to fail
with:

 ERROR: ctfconvert: die 684: unrecognised real type size 16

The fix is to add knowledge of real type sizes for all four platforms
to usr/src/tools/ctf/cvt/dwarf.c:die_base_type2enc.

c. ctfmerge segfaults when run on genunix built with gcc.  This
problem has not been root-caused.

/usr/ccs/bin/ld -r  -o obj64/platmod obj64/platmod.o
/local/nevada-gcc/usr/src/tools/proto/opt/onbld/bin/sparc/ctfmerge -L VERSION -d
 ../../sun4u/genunix/obj64/genunix -o obj64/platmod obj64/platmod.o 
*** Error code 139
The following command caused the error:
label="-L VERSION" ;  if [ -z "#" ] ; then  uniq="-D BASE" ;  set -- `/local/nev
ada-gcc/usr/src/tools/proto/opt/onbld/bin/ctffindmod -n -r -t  obj64/platmod` ; 
 if [ "X$1" != "X-" ] ; then  label="-l $1" ;  if [ "$2" != "fcs" ] ; then  uniq
="-D $2" ;  fi ;  fi ;  fi ;  mergecmd="/local/nevada-gcc/usr/src/tools/proto/op
t/onbld/bin/sparc/ctfmerge " ;  cmd="$mergecmd $label -d ../../sun4u/genunix/obj
64/genunix $uniq -o obj64/platmod" ;  echo $cmd "obj64/platmod.o " ;  $cmd obj64
/platmod.o 
*** Error code 1

2. Header Files

Minor tweaks to several headers may be required, either to add __GNUC
dependencies where they exist, or to account for additional built-in
definitions present in gcc.  For example, isa_defs.h defines _LP64
unconditionally, but for 64-bit builds, gcc has a built-in definition
for it.  In some cases, we may instead wish to remove the built-in
definition present in gcc.

3. Build flags/makefiles.

A small number of variables in the makefiles will need tweaking to use
cw instead of cc.  Additionally, side effects must be handled; for
example, GOFLAGS needs -_noecho for cw to work with genassym.

4. Compiler flag mappings

The makefiles have lots of SPARC compiler flags which have no obvious
gcc mappings.  Examples include -Qiselect..., -Lt, -Rcond_elim,
-W0,..., -W2,...  and more.  Someone will need to evaluate these
flags, many of which are undocumented, and determine which are needed
and how to translate them to gcc.  In some cases, new options may need
to be added to gcc.

5. Warnings

There are over 17000 warnings when ON is built on SPARC.  If we use
-Werror, as the amd64 port does and as we traditionally have on all
platforms, these will need to be fixed or disabled.

The most common warnings:

5445  warning: return type defaults to `int'
2459  warning: cast to pointer from integer of different size
1544  warning: `return' with no value, in function returning non-void
1433  warning: cast from pointer to integer of different size
 612  warning: integer constant is too large for "long" type
 592  warning: operation on `_oam_msg_base_' may be undefined
 324  warning: useless keyword or type name in empty declaration
 298  warning: type defaults to `int' in declaration of `i'
 204  warning: long long unsigned int format, pointer arg 
 194  warning: unsigned int format, pointer arg 
 159  warning: 
 155  warning: braces around scalar initializer
 152  warning: long long unsigned int format, uint64_t arg 
 130  warning: comparison is always false due to limited range of data type

By far the most common cause of these warnings is K&R-type function
declarations, which should be eliminated.

The casts between pointers and integers of different sizes can either
be corrected by changing all instances of:

	void *foo;
	uint64_t bar;
	...
	bar = (uint64_t)foo;

into

	bar = (uint64_t)(uintptr_t)foo;

or by adding the ability to disable this warning (by default, it
cannot be disabled).  I have already done the latter for both cast
directions; however, casting from a smaller integer to a pointer is
potentially dangerous and we should take the opportunity to have an
engineer review these cases.

Another common source of warnings are code which is built for both 32
and 64 bit versions of the same library but is not fully 64-bit safe
in gcc's eyes.  Specifically, building a 32-bit object from code which
includes constants longer than 32 bits without `ULL' will trigger
warnings.

For each warning type, we must decide whether to change ON, change
gcc, or disable the warning (if possible).

I have already fixed all of usr/src/tools to build with gcc, since
building the tools is necessary to attempt to build the rest.

6. CSL's gcc changes for amd64/S10

Port necessary changes for sol2-10 to sparc/sparc64.  Most of their
changes either are to generic code or are specific to i386/amd64
multilib support, but some are for S10 specifically.  I believe I have
ported most or all of this, but CSL should verify its completeness,
write test cases, and update the documentation.

7. Update cw

Independent of the work in (4) to understand the undocumented compiler
flags, cw currently lacks any support for SPARC.  This is not difficult
to correct; I have a prototype implementation.  It does however depend
on several patches to gcc, including a large one that affects the
behaviour of the -mtune, -mcpu, and -march options to be compatible with
their x86 semantics.  Instead, cw needs to account for these and other
differences, such as SPARC's greater number of ISA and code model
variants.

8. Weak symbols

a. libc will not build on SPARC; there is a conflict between
synonyms.h and an ISO header for the weak definition of setjmp.  It
appears this affected amd64 also, and their fix appears to be valid
for SPARC also.  Someone needs to review this fix and any similar
instances found.

b. DevPro as doesn't like:

	.weak foo
	foo = _foo
	.weak foo
	foo = _foo

while gas is ok with it.  Since the #pragma weak directive causes one
such assembly fragment to be emitted for each declaration on all
platforms, we must either get the tools group to make as
gas-compatible in this regard or make gcc stop emitting duplicate
.weak directives.  I have made a gcc patch for this; however, it
should be evaluated and tested by CSL.

c. Unbound weak symbols

There is code in usr/src/uts/sfmmu/vm (at least) that checks whether a
weak symbol is bound before calling/using it.  To ensure that this is
not optimised away, we have -Wd,-xsafe=unboundsym in CFLAGS for SPARC.
This is one the the CFLAGS that has no obvious translation to gcc.
Although gcc does not appear to optimise away the test, in some cases
it issues an ominous warning instead, such as

../../../sfmmu/vm/hat_sfmmu.c:8385: warning: the address of `mmu_fixup_large_pages', will always evaluate as `true'

This implies that the weak symbol is not handled correctly.  This will
most likely need to be evaluated by CSL.

9. libgcc (64-bit arithmetic using 32-bit registers)

This mainly seems to affect libc, but can be expected to affect
anything built with -xarch=v8* and linked with ld instead of gcc.  The
symptom is:

__lshrdi3                           pics/_Q_lltoq.o
__divdi3                            pics/lldiv.o
__floatdidf                         pics/aconvert.o
__moddi3                            pics/lldiv.o
__ashldi3                           pics/_Q_lltoq.o
__ashrdi3                           pics/_Q_lltoq.o
__udivdi3                           pics/lltostr.o
__umoddi3                           pics/assfail.o

and similar undefined references at link time.  These functions are
present in libgcc, a static library built as part of gcc.  Our options
are to cause that library to be linked in when needed, try to
eliminate the arithmetic that causes these function calls to be
emitted, or write our own libgcc.

There is no license problem with linking with libgcc:

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine executable.)

10. Inlines

Convert all inlines (.il) to regular gcc-style inlines in headers.
There are 12 such files in the non-amd64 sources.  The amd64 sources
have good examples of how to do this, and neither the gcc assembly
format nor the assembly fragments themselves are especially difficult.

11. Binary compatibility

We need to find a way to run a rigorous binary compatibility check,
making sure all structs/unions, members, stack arguments, and
floating-point types have the same sizes, offsets, and alignments as
with DevPro.  It may be to our advantage to develop a tool especially
for this purpose (extend intf_check?)  Especially troubling will be
any libraries not compiled with -dalign.

12. Code models

The DevPro compiler supports an "abs64" code model that gcc appears
not to.  We need to verify that all code models used by ON code are
supported by gcc.  Since abs64 does not appear to be used by any ON
code, this appears likely.  If we do find problems, we will either
need to change the code model or have CSL add support for the model to
gcc.

13. C++

There are many problems with C++.  High on the list is incompatibility
between binaries built with g++ and CC.  Also, libstdc++ will need to
be shipped for each ISA, and we would also be required to provide
sources for it.

The amd64 team reports that they had some success building libraries
with -fno-rtti -fno-exceptions.  We will need to explore this in
greater detail; since most C++ libraries are built 32-bit only, the
amd64 team was not affected in many cases.

Andy also suggests there may be template incompatibilities between g++
and CC.  We will need to evaluate these incompatibilities, if they
exist, and do one of: select compiler options that alleviate them,
modify our code, or have CSL modify g++ and/or its template libraries.

The man(1) command shipped with ON is said to rely on files
distributed with CC as well.  I have not investigated this
sufficiently to determine what fixes may be appropriate.

Fortunately, g++ appears to be invoked only 174 times during a SPARC
build.  This may increase somewhat once other problems are corrected;
there are approximately 257 C++ files in the Nevada gate.

14. Testing/soak

Considering the subtlety of bugs that compilers can introduce, a long
period of active use on multiple busy machines seems in order.  Once we
have a tree that builds with gcc, we will need to throw the kitchen sink
at it.  This means we will need to develop a comprehensive test plan
that includes both test suite execution and soaking on busy systems,
probably including our gate machine.



-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From rich.teer at rite-group.com  Thu Feb 17 16:20:53 2005
From: rich.teer at rite-group.com (Rich Teer)
Date: Thu, 17 Feb 2005 16:20:53 -0800 (PST)
Subject: [gcc] Re: [Opensolaris-discuss] OpenSolaris gcc Project Opens
In-Reply-To: <42152F41.7060509@sun.com>
References: <42152F41.7060509@sun.com>
Message-ID: <Pine.SOL.4.58.0502171620130.7717@zen.rite-group.com>

On Thu, 17 Feb 2005, Jim Grisanzio wrote:

> Guys ...
>
> Some of you have mentioned at various times using gcc to build Solaris.
> Well, we also think it's important, and we'd like to begin work on this.

That's great news, although personally I'd rather Sun makes its C compiler
available for $0...

-- 
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich


From keith.wesolowski at sun.com  Thu Feb 17 16:38:22 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 17 Feb 2005 16:38:22 -0800
Subject: [gcc] Re: [Opensolaris-discuss] OpenSolaris gcc Project Opens
In-Reply-To: <Pine.SOL.4.58.0502171620130.7717@zen.rite-group.com>
References: <42152F41.7060509@sun.com>
	<Pine.SOL.4.58.0502171620130.7717@zen.rite-group.com>
Message-ID: <20050218003822.GA165665@sun.com>

On Thu, Feb 17, 2005 at 04:20:53PM -0800, Rich Teer wrote:

> That's great news, although personally I'd rather Sun makes its C compiler
> available for $0...

That we are beginning work to build with gcc should not be taken as a
statement of direction on compilers.  I'll reiterate what we've been
saying all along: we will make sure the tools needed to build a
working OpenSolaris are available free of charge.

It has not been determined whether that means we'll be using gcc
exclusively or releasing Studio compilers, nor under what license if
the latter.  When a decision is made, we'll let you know.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From sommerfeld at sun.com  Thu Feb 17 16:54:47 2005
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu, 17 Feb 2005 19:54:47 -0500
Subject: [gcc] Re: [Opensolaris-discuss] Initial gcc project worklist
In-Reply-To: <20050218001723.GA165606@sun.com>
References: <20050218001723.GA165606@sun.com>
Message-ID: <1108688087.25320.11.camel@thunk>

On Thu, 2005-02-17 at 19:17, Keith M Wesolowski wrote:

> 14. Testing/soak
> 
> Considering the subtlety of bugs that compilers can introduce, a long
> period of active use on multiple busy machines seems in order.  Once we
> have a tree that builds with gcc, we will need to throw the kitchen sink
> at it.  This means we will need to develop a comprehensive test plan
> that includes both test suite execution and soaking on busy systems,
> probably including our gate machine.

there are multiple aspects to this:

 1) verifying that the changes to allow building with gcc do not cause
builds with Studio to fail or produce binaries that fail to work.

 2) verifying that the gcc-built bits work.

I'd think that certain types of changes (particularly, the elimination of
old style function declarations in sparc code) do not need to happen all
at once, and putting them back incrementally would allow for more
"production" soak time of the changes, and avoid the "big bang" impact of a
really large integration on the short-term stability of solaris.

I've seen evidence that we've taken this incremental approach to compiler
version switches in the past (putting back fixes which involve code not
compiling with the new version well before we throw the big switch). 

						- Bill









From Jim.Grisanzio at Sun.COM  Fri Feb 18 09:17:35 2005
From: Jim.Grisanzio at Sun.COM (Jim Grisanzio)
Date: Fri, 18 Feb 2005 09:17:35 -0800
Subject: [gcc] Re: [Opensolaris-discuss] OpenSolaris gcc Project Opens
In-Reply-To: <4215C2A2.nailDS971Q3L1@burner>
References: <42152F41.7060509@sun.com> <4215C2A2.nailDS971Q3L1@burner>
Message-ID: <4216232F.20909@sun.com>

Joerg Schilling wrote:

> Is this an attempt to avoid making Sun Studio C available for free?
> 
> J?rg

Nope. It's just an attempt to recognize the needs of community and be as 
flexible as possible. We are considering all options with tools, and 
this is one we are implementing now. It doesn't exclude anything.

Jim


From Cyril.Plisko at CLLF.COM  Fri Feb 18 10:32:22 2005
From: Cyril.Plisko at CLLF.COM (Cyril Plisko)
Date: Fri, 18 Feb 2005 20:32:22 +0200
Subject: [gcc] Re: [Opensolaris-discuss] OpenSolaris gcc Project Opens
In-Reply-To: <4216232F.20909@sun.com>
References: <42152F41.7060509@sun.com> <4215C2A2.nailDS971Q3L1@burner>
	<4216232F.20909@sun.com>
Message-ID: <421634B6.5000301@CLLF.COM>

Jim Grisanzio wrote:
> Joerg Schilling wrote:
> 
>> Is this an attempt to avoid making Sun Studio C available for free?
>>
>> J?rg
> 
> 
> Nope. It's just an attempt to recognize the needs of community and be as 
> flexible as possible. We are considering all options with tools, and 
> this is one we are implementing now. It doesn't exclude anything.

I think gcc support is a good thing, since it is the only compiler
available for polaris right now (and it doesn't seem to going to change)

Cyril

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3672 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.opensolaris.org/pipermail/gcc/attachments/20050218/68e191a6/attachment.bin>

From schilling at fokus.fraunhofer.de  Fri Feb 18 02:25:38 2005
From: schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Fri, 18 Feb 2005 11:25:38 +0100
Subject: [gcc] Re: [Opensolaris-discuss] OpenSolaris gcc Project Opens
In-Reply-To: <42152F41.7060509@sun.com>
References: <42152F41.7060509@sun.com>
Message-ID: <4215C2A2.nailDS971Q3L1@burner>

Jim Grisanzio <Jim.Grisanzio at Sun.COM> wrote:

> Some of you have mentioned at various times using gcc to build Solaris. 
> Well, we also think it's important, and we'd like to begin work on this.
>
> We opened a mail list (gcc at opensolaris.org) for discussion. Keith has 
> done some research and will send out his preliminary findings as to what 
> we need to do. We are looking for people who have familiarity with gcc 
> and experience with specific areas that Keith outlines. Also, if anyone 
> has written any tools that could be useful in this effort or has started 
>   work toward building OpenSolaris with gcc, we'd love to hear from you. 
> And, of course, we'd like to make sure you have the first opportunity to 
> test the resulting changes and report any problems.

Is this an attempt to avoid making Sun Studio C available for free?

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  
       schilling at fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


From kritter at eng.sun.com  Wed Feb 23 17:20:17 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Wed, 23 Feb 2005 17:20:17 -0800
Subject: [gcc] introduction and question
Message-ID: <421D2BD1.5010709@eng.sun.com>

Hello everyone!

I am the engineering manager for the OpenSolaris program, working for 
Stephen Harpster and with the core team that you interact with here.

My deepest apologies for not introducing myself sooner.

Now on to my question...

It is wonderful to see the community interest in making the OpenSolaris 
code buildable with gcc. My next (obvious) question is: Who wants to help?

We're in the process of staffing up the work internally, but don't want 
to leave you all out if you're interested in contributing. Please let me 
know right away if you are interested.

We all think it would be great to have at least 2 people from the 
community help with this work. In addition to the vast experience you 
all have, this can help us improve our development processes and start 
the working development relationship between Sun and non-Sun engineers.

You'll be hearing more from me soon -- I've got so many questions for 
you all!

Thanks,

Karyn

P.S. If everyone needs/wants to know more about me, let me know. I 
didn't want to bore even more people than I do already by talking about 
myself unnecessarily. :)


From kritter at eng.sun.com  Wed Feb 23 17:42:36 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Wed, 23 Feb 2005 17:42:36 -0800
Subject: [gcc] Re: [Opensolaris-discuss] introduction and question
In-Reply-To: <421D2D45.8060105@cuddletech.com>
References: <421D2BD1.5010709@eng.sun.com> <421D2D45.8060105@cuddletech.com>
Message-ID: <421D310C.5090904@eng.sun.com>

Ben,

Thanks for your note. In my opinion (which is shared by a few others), 
making our code buildable with gcc is good -- regardless of what happens 
with the Forte compilers. At a minimum, anyone doing a port is going to 
need gcc support. We always planned to do this work at some point, and 
we decided it would be good to start it now.

All I can say about the Forte stuff is that we are still working it, but 
we don't have a decision yet.

Thanks,

Karyn

Ben Rockwood wrote:
> Hello Karyn.
> 
>  As has been asked several times before on this list, clarification on 
> the future of Sun Studio needs to be made.  GCC builds are a good thing, 
> but I'd much rather use Forte and don't see a need to invest huge 
> ammounts of time into it unless the possibility of providing Forte to 
> the world has been pulled completely.  If Forte is free/open then I 
> don't know of too many people that would rather use GCC... however, if 
> Forte stays closed and for-fee then we don't really have a choice.
> 
> benr.
> 
> 
> Karyn Ritter wrote:
> 
>> Hello everyone!
>>
>> I am the engineering manager for the OpenSolaris program, working for 
>> Stephen Harpster and with the core team that you interact with here.
>>
>> My deepest apologies for not introducing myself sooner.
>>
>> Now on to my question...
>>
>> It is wonderful to see the community interest in making the 
>> OpenSolaris code buildable with gcc. My next (obvious) question is: 
>> Who wants to help?
>>
>> We're in the process of staffing up the work internally, but don't 
>> want to leave you all out if you're interested in contributing. Please 
>> let me know right away if you are interested.
>>
>> We all think it would be great to have at least 2 people from the 
>> community help with this work. In addition to the vast experience you 
>> all have, this can help us improve our development processes and start 
>> the working development relationship between Sun and non-Sun engineers.
>>
>> You'll be hearing more from me soon -- I've got so many questions for 
>> you all!
>>
>> Thanks,
>>
>> Karyn
>>
>> P.S. If everyone needs/wants to know more about me, let me know. I 
>> didn't want to bore even more people than I do already by talking 
>> about myself unnecessarily. :)
>> _______________________________________________
>> Opensolaris-discuss mailing list
>> Opensolaris-discuss at www.opensolaris.org
>> https://www.opensolaris.org/mailman/listinfo/opensolaris-discuss
> 
> 
> 


From benr at cuddletech.com  Wed Feb 23 17:26:29 2005
From: benr at cuddletech.com (Ben Rockwood)
Date: Wed, 23 Feb 2005 17:26:29 -0800
Subject: [gcc] Re: [Opensolaris-discuss] introduction and question
In-Reply-To: <421D2BD1.5010709@eng.sun.com>
References: <421D2BD1.5010709@eng.sun.com>
Message-ID: <421D2D45.8060105@cuddletech.com>

Hello Karyn.

  As has been asked several times before on this list, clarification on 
the future of Sun Studio needs to be made.  GCC builds are a good thing, 
but I'd much rather use Forte and don't see a need to invest huge 
ammounts of time into it unless the possibility of providing Forte to 
the world has been pulled completely.  If Forte is free/open then I 
don't know of too many people that would rather use GCC... however, if 
Forte stays closed and for-fee then we don't really have a choice.

 benr.


Karyn Ritter wrote:

> Hello everyone!
>
> I am the engineering manager for the OpenSolaris program, working for 
> Stephen Harpster and with the core team that you interact with here.
>
> My deepest apologies for not introducing myself sooner.
>
> Now on to my question...
>
> It is wonderful to see the community interest in making the 
> OpenSolaris code buildable with gcc. My next (obvious) question is: 
> Who wants to help?
>
> We're in the process of staffing up the work internally, but don't 
> want to leave you all out if you're interested in contributing. Please 
> let me know right away if you are interested.
>
> We all think it would be great to have at least 2 people from the 
> community help with this work. In addition to the vast experience you 
> all have, this can help us improve our development processes and start 
> the working development relationship between Sun and non-Sun engineers.
>
> You'll be hearing more from me soon -- I've got so many questions for 
> you all!
>
> Thanks,
>
> Karyn
>
> P.S. If everyone needs/wants to know more about me, let me know. I 
> didn't want to bore even more people than I do already by talking 
> about myself unnecessarily. :)
> _______________________________________________
> Opensolaris-discuss mailing list
> Opensolaris-discuss at www.opensolaris.org
> https://www.opensolaris.org/mailman/listinfo/opensolaris-discuss




From schilling at fokus.fraunhofer.de  Thu Feb 24 07:33:15 2005
From: schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Thu, 24 Feb 2005 16:33:15 +0100
Subject: [gcc] Re: [Opensolaris-discuss] introduction and question
In-Reply-To: <421D310C.5090904@eng.sun.com>
References: <421D2BD1.5010709@eng.sun.com>
	<421D2D45.8060105@cuddletech.com> <421D310C.5090904@eng.sun.com>
Message-ID: <421DF3BB.nailIH21RW8I@burner>

Karyn Ritter <kritter at eng.sun.com> wrote:

> Ben,
>
> Thanks for your note. In my opinion (which is shared by a few others), 
> making our code buildable with gcc is good -- regardless of what happens 
> with the Forte compilers. At a minimum, anyone doing a port is going to 
> need gcc support. We always planned to do this work at some point, and 
> we decided it would be good to start it now.

>From a perspective of doing this the the following two reasons, I could aggree:

-	Use a complete GCC build in order to check for other possible
	compiler warnings that might help to debug code.

	I am doing this from time to time with my private sources too

-	Because a significant amount of users may like to compile with GCC
	instead of Forte although the resulting binaries would be slower.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  
       schilling at fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


From maybird1776 at yahoo.com  Thu Feb 24 04:46:01 2005
From: maybird1776 at yahoo.com (ken mays)
Date: Thu, 24 Feb 2005 04:46:01 -0800 (PST)
Subject: [gcc] Re: [Opensolaris-discuss] introduction and question
In-Reply-To: <421D2D45.8060105@cuddletech.com>
Message-ID: <20050224124602.41404.qmail@web41826.mail.yahoo.com>


--- Ben Rockwood <benr at cuddletech.com> wrote:

> Hello Karyn.
> 
>   As has been asked several times before on this
> list, clarification on 
> the future of Sun Studio needs to be made.  GCC
> builds are a good thing, 
> but I'd much rather use Forte and don't see a need
> to invest huge 
> ammounts of time into it unless the possibility of
> providing Forte to 
> the world has been pulled completely. 

Ben,

I would like to see the OpenSolaris build results
documentation using:
Sun Studio 8
Sun Studio 9
GCC 3.4.3
Metrowerks CodeWarrior
PathScale EKOPath Suite

I think you've posted the Sun Studio 10 results? 

I think this would let us know how the playing field
is laid out amongest compilers and portability
efforts.
~ Ken Mays


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 


From keith.wesolowski at sun.com  Thu Feb 24 10:01:41 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 24 Feb 2005 10:01:41 -0800
Subject: [gcc] Re: [Opensolaris-discuss] introduction and question
In-Reply-To: <20050224124602.41404.qmail@web41826.mail.yahoo.com>
References: <421D2D45.8060105@cuddletech.com>
	<20050224124602.41404.qmail@web41826.mail.yahoo.com>
Message-ID: <20050224180140.GC27077@sun.com>

On Thu, Feb 24, 2005 at 04:46:01AM -0800, ken mays wrote:

> I would like to see the OpenSolaris build results
> documentation using:
> Sun Studio 8
> Sun Studio 9
> GCC 3.4.3
> Metrowerks CodeWarrior
> PathScale EKOPath Suite
> 
> I think you've posted the Sun Studio 10 results? 

Some people here also have Studio 10 working.  However, Studio 9 is a
non-starter; it issues a large number of warnings.  Perhaps the
changes needed for gcc will fix them all, but I doubt it.  In any
case, Studio 9 is pointless since it lacks a large number of
improvements for x86, notably amd64 support, that SOS10 has.

As for Metrowerks and PathScale, you would at minimum have to make
large changes to usr/src/tools/cw/cw.c and possibly also aw/aw.c to
make it support these compilers.  While it might be interesting to
have support for arbitrary compilers, and for the code to build with
any compiler, this is a non-goal of the initial gcc project.  It is a
possible future extension if there's sufficient interest, though -
most of the needed work has been done already or will be done during
the gcc project.  One thing you'll need to think about is whether
these compilers have equivalents to libgcc - I haven't used them, so I
don't know.  If so, how would you resolve the issue?  See my original
writeup for a detailed description.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!"