From benr at cuddletech.com Wed Mar 2 22:16:51 2005 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 02 Mar 2005 22:16:51 -0800 Subject: [gcc] Request for status Message-ID: <4226ABD3.8090205@cuddletech.com> So where are we with the GCC turn over? I've been a SPARC guy playing with AMD64 here and there. It was my understanding that AMD64 was already building with GCC, which leaves me wondering what the target platforms for transition are? What tools are people using (such as the Forte "gcc translator")? What is already done? What is most important? Who's the lead for this project? Etc. Thanks. benr. From keith.wesolowski at sun.com Thu Mar 3 20:04:41 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Thu, 3 Mar 2005 20:04:41 -0800 Subject: [gcc] Request for status In-Reply-To: <4226ABD3.8090205@cuddletech.com> References: <4226ABD3.8090205@cuddletech.com> Message-ID: <20050304040440.GB8430@sun.com> On Wed, Mar 02, 2005 at 10:16:51PM -0800, Ben Rockwood wrote: > So where are we with the GCC turn over? I've been a SPARC guy playing > with AMD64 here and there. It was my understanding that AMD64 was > already building with GCC, which leaves me wondering what the target > platforms for transition are? What tools are people using (such as the > Forte "gcc translator")? What is already done? What is most > important? Who's the lead for this project? Etc. Ben, Thanks for asking. I'll address each of your questions and then provide some additional information. The target ISAs are i386, sparc, and sparcv9. The broad statement of purpose is that it should be possible to build a functional set of ON bits on a system that has no access to any part of the SUNWspro directory. This means that both the SPARC and x86 builds should be able to complete using only gcc. The compiler wrapper (usr/src/tools/cw) is still the preferred route rather than modifying 2800 makefiles, and this is what I'm pursuing. I have a version of cw updated to accept the SPARC flags, and I'll be making this code available shortly (probably tomorrow). I've also adjusted a few makefiles so that it's possible to bootstrap with gcc. course, at this point, most code does not actually build on SPARC due to warnings, CTF/DWARF interaction problems, and a variety of other issues. My complete, current analysis is attached; it lists the known technical issues. What's been done? My cw work is nearly ready for testing. The first round will verify that the commands given to cc (and for amd64 gcc) are the same as without my changes when __GNUC is not set. It is crucial that we do not interfere with or alter the behaviour of the build when this variable is not defined, so that existing production builds will continue to function. The project is not sufficiently large to require a formal structure including a tech lead, but for practical purposes you may assume I'm fulfilling some of those functions. I'm attaching the current analysis, questions and answers I got from senior members of the amd64 team which provide some information about the decisions we've made, and a schedule estimating the amount of work for each item (substitute my name for Roger A. Faulkner's and ignore the dates; they are generally meaningless). The best way to help is to fix warnings. When I post my diffs, you'll be able to start seeing them, and presumably start fixing them. It's probably best to start with the commands, since they offer the lowest risk of breakage and the greatest volume of change. If you decide to work on this, please let me know so I can coordinate your efforts with others. I can also get you a list of files and warnings along with my recommendations for fixing them if you like. Thanks very much for participating! -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" -------------- next part -------------- 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 : 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. -------------- next part -------------- 1. What should we do about libgcc? The options I've identified so far are to cause it to be linked in when building with gcc, try to eliminate the 64-bit arithmetic that makes gcc generate calls into it, or write our own replacements for those functions. >> Preferred way is to add code to libc for these functions. 2. What header file changes were required for amd64? How much work was needed? >> Minimal. 3. How is compatibility between Vulcan-built binaries and the shipping gcc binaries (especially libraries) being addressed? What about for C++ libraries, if there are any? Do you know of any tools that could be used to verify ABI compatibility with Studio-generated code? Does the SCD test suite cover this on SPARC? >> We have a tool that is incomplete for assessing this. SCD is relevant. 4. Is it possible to build C++ libraries in such a way that they can be linked with Studio-generated code? If not, how do we hide the incompatibilities? >> No, but the working assumption (needs to be verified) is that we don't ship >> any libraries with public C++ interfaces. This just leaves us with the >> libstdc++ issue to sort out. 5. If we build C++ libraries with g++, we will need to provide libstdc++. How do we manage the stability of the libstdc++ interfaces and how will that affect our ability to ship newer gcc versions in the future? >> TBD. 6. None of the changes I saw from CSL seem necessary for SPARC. Do you know of any additional work we would need CSL to do? >> No. The work should be complete. 7. All the gcc-compiled code is now assembled with gas. Should we consider using gas for 32-bit x86 binaries? If so, what about SPARC? Did you ever try using gcc with DevPro as, and if so, what problems did you encounter (on SPARC, we have issue 8b at least)? >> Stick with as for now (though /usr/sfw/bin/gcc uses gas, hmm...). Issue 8b >> now has an open bug filed. Long term, consider having CSL or someone get >> SPARC docs and keep gas up to date. 8. Do you know of any problems or risks associated with the .il to gcc-style inline-asm conversion? How much work was required? >> Lots of subtlety, allocate a few weeks... 9. Are you aware of any SPARC code relying on the abs64 code model? >> No. The medium code model should also be adequate for all code. abs64 is >> not used. -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-sched.pdf.bz2 Type: application/octet-stream Size: 11229 bytes Desc: not available URL: From keith.wesolowski at sun.com Tue Mar 22 12:08:26 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Tue, 22 Mar 2005 12:08:26 -0800 Subject: [gcc] Current diffs Message-ID: <20050322200826.GA18839@sun.com> Here are the current diffs against the OpenSolaris build 10 (20050310) release. Building with gcc (which does not work) is enabled by setting the __GNUC environment variable to the empty value. Unsetting it restores the usual build behaviour. That is: $ __GNUC= ; export __GNUC turns it on and $ unset __GNUC turns it off. See Makefile.master to learn how this works. The most important changes are to usr/src/tools/cw/cw.c to support gcc on SPARC. You will need to build cw first and install it in /opt/onbld/bin/sparc if you want to build with gcc on SPARC. You will also need a modified gcc on SPARC (the one in /usr/sfw is not quite good enough). The patch for gcc is attached as well. Configure with: ../gcc-3.4.3/configure --prefix=/usr/sfw --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/usr/ccs/bin/as --enable-languages=c,c++ --enable-shared and build with gmake. I'll try to get you the actual makefiles used to build this (which I believe Joerg was asking for) later. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" -------------- next part -------------- A non-text attachment was scrubbed... Name: os-gcc.diff.bz2 Type: application/octet-stream Size: 17247 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-3.4.3-on.diff.bz2 Type: application/octet-stream Size: 1497 bytes Desc: not available URL: From kritter at eng.sun.com Tue Mar 22 12:51:32 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Tue, 22 Mar 2005 12:51:32 -0800 Subject: [gcc] [Fwd: notes from gcc work meeting (3/16)] Message-ID: <42408554.90902@eng.sun.com> Several of the Sun engineers assigned to help with the gcc work had a meeting last week to ensure they had all of the appropriate information to start the work. I apologize for not sending the email out to the alias immediately -- it was an oversight. All of the Sun engineers are now on this alias, and we will have project discussions here from now on. I'll forward you the two emails which have been sent out on this topic. Please let me know if you have any questions about the notes. We're still working on getting some of the files associated with this work released under CDDL right away. Unfortunately most of them require cleanup, so there has been a delay in making them available. Thanks, Karyn -------- Original Message -------- Subject: notes from gcc work meeting (3/16) Date: Wed, 16 Mar 2005 15:50:19 -0800 From: Karyn Ritter To: Andrei Dorofeev , Matt Simmons , Craig Mohrman , mike_s at eng.sun.com, Keith Wesolowski CC: Linda Bernal Agenda: * Review project logistics (e.g., project gate) [Keith] * Clarification of the work that needs to be done [all] * Other questions/issues you want to raise [all] * How best to manage the project work [Karyn/all] AIs: 03162005-01: Keith will send out a pointer to the project gate and the special version of gcc he is using. Due date: 3/17/05 Status: 03162005-02: Keith will talk to tpm about the libgcc functions that were implemented in the kernel for AMD-64, and will send out the appropriate details. Due date: 3/17/05 Status: DONE Follow up information from Keith on AI 03162005-02: The amd64 team got the kernel building (not all of userland) with some functions from BSD. These can be found at /net/tread/export/gates/amd64-boot/usr/src/uts/intel/ia32/ml. Only those functions are there which were needed to generate a working kernel; libc or other userland code may generate additional calls. I would recommend putting these in common/ (the bignum stuff used by openssl is a good example). These functions can be optimized by checking whether the upper 32 bits of the argument(s) are zero and performing regular operations instead. They could perhaps be rewritten in assembly if they still prove to be a bottleneck. See also related bug 6220152. Fixing this bug may or may not be a necessary component of the C++ work. 03162005-03: Keith to send Matt and Karyn the bug number for the CTF issue(s). Due date: 3/17/05 Status: DONE 03162005-04: Keith will check on the use of as vs. gas for 32-bit x86, and will follow up with Andrei on any issues. Due date: 3/17/05 Status: DONE 03162005-05: Keith will talk to Rod Evans/Mike Walker about the rtldboot (gas/as). Due date: 3/17/05 Status: 03162005-06: Karyn will check in with everyone at least once a week to see how things are going. Due date: ongoing Status: Discussion summary: Keith reviewed the work that has been done and what needs to be done. We decided that setting up a weekly meeting is unnecessary. As questions come up, everyone will talk to Keith. If needed, we can schedule a meeting. Karyn will follow up with everyone on a regular (at least weekly) basis to check progress. Verified that the schedule estimates were pretty accurate. Attendees: Linda Bernal Andrei Dorofeev Craig Mohrman Matt Simmons Mike Sullivan Keith Wesolowski From kritter at eng.sun.com Tue Mar 22 12:51:42 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Tue, 22 Mar 2005 12:51:42 -0800 Subject: [gcc] [Fwd: gcc: gate and compilers] Message-ID: <4240855E.7020908@eng.sun.com> Here's Keith's follow up regarding the work he was doing. My next message will be a pdf version of the gcc schedule in case that is useful to you all. Thanks, Karyn -------- Original Message -------- Subject: gcc: gate and compilers Date: Thu, 17 Mar 2005 19:08:35 -0800 From: Keith Wesolowski To: Karyn Ritter CC: Andrei Dorofeev , Matt Simmons , Craig Mohrman , mike_s at eng.sun.com, Linda Bernal References: <4238C63B.3060605 at eng.sun.com> On Wed, Mar 16, 2005 at 03:50:19PM -0800, Karyn Ritter wrote: > 03162005-01: Keith will send out a pointer to the project gate and the > special version of gcc he is using. The project gate is at /net/tonic-gate.eng/tonic/gcc-gate. I'll be updating it daily or as close to daily as possible. It includes fixes for the following bugs: 6241280 cw should support SPARC 6241282 cw should be bootstrappable with gcc 6241287 g++ doesn't want wchar_t under any circumstances 6241296 kernel files must include sys/note.h rather than note.h 6241298 gcc flag -mcmodel=small is not appropriate for 32-bit builds 6241304 x86 bitmap header needs typo fix 6241310 ssc100 has incorrect format string 6241313 codereview should be lint and cstyle clean 6241972 cscope-fast should build with gcc 6241980 movw applies to %ax rather than %eax 6241984 isa_defs.h should not redefine _LP64 6241993 SPARC siglongjump symbol aliasing is wrong 6241995 warnings in sgs should be fixed 6242262 ON should build with gcc This is basically the workspace I've been working on with a few incomplete and temporary workarounds that would conflict with ongoing work removed. The fix for the last RFE is obviously incomplete. The other fixes will be put back into onnv fairly soon. Here is the list of additional diffs which may make testing easier. All are available in /net/tonic-gate/tonic/gcc-gate/public/: ctf-war.diff Workarounds for CTF DWARF handling on SPARC gcc-patches/* Additional gcc patches (not needed) nightly-gcc.diff Add -g to nightly to build with gcc utswarn.diff Fix kernel warnings/errors triggered by gcc cw-libgcc.diff Link in libgcc along with libc userwarn.diff Fix userland warnings/errors triggered by gcc x86-stand.diff Attempt to build x86 stand and psm with gcc Compiler packages for SPARC are at /net/foobazco.eng/export/ws/sfwnv-gcc/packages/. You will need both the gcc runtime and gcc packages. These differ from the standard SFW packages as follows: - configured to use as instead of gas (6241292) - patched to support Nevada (uname -r == 5.10.1) - patched to emit only one copy of each weak symbol assignment Other changes to gcc will be followed up through CodeSourcery. I'll communicate any future compiler upgrades in advance. NOTES ON BUILDING: * gcc building is toggled by use of the __GNUC environment variable. Setting this variable to the empty value triggers the use of gcc. Unsetting the variable yields the existing behaviour (gcc for amd64, DevPro for everything else). Setting it to any other value will confuse make. * The onbld tools in /ws/onnv-tools do not include a SPARC cw. You have the following options: - get cw from /net/tonic-gate/tonic/gcc-gate/public/cw.sparc and install it locally - rebuild your tools with DevPro, then set ONBLD_TOOLS to your tools proto area - modify cw to link in libgcc (diffs are in /net/tonic-gate/tonic/gcc-gate/public/cw-libgcc.diff), then build with either DevPro or gcc. This allows you to use nightly -t with gcc and get a working set of tools. * By default, the build uses gcc from /usr/sfw. If you are working on SPARC and install the modified compiler in another directory, you must set GNU_ROOT to point to that directory. Let me know if you have any questions. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From kritter at eng.sun.com Tue Mar 22 12:51:49 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Tue, 22 Mar 2005 12:51:49 -0800 Subject: [gcc] gcc schedule Message-ID: <42408565.4020504@eng.sun.com> As promised, attached is the schedule we're currently operating toward for gcc. I expect it to change slightly based on actual delivery dates. Please let me know if you have any questions. Thanks, Karyn -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-sched.pdf Type: application/pdf Size: 184154 bytes Desc: not available URL: From keith.wesolowski at sun.com Tue Mar 22 13:46:08 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Tue, 22 Mar 2005 13:46:08 -0800 Subject: [gcc] [Fwd: gcc: gate and compilers] In-Reply-To: <4240855E.7020908@eng.sun.com> References: <4240855E.7020908@eng.sun.com> Message-ID: <20050322214607.GA19017@sun.com> On Tue, Mar 22, 2005 at 12:51:42PM -0800, Karyn Ritter wrote: > The project gate is at /net/tonic-gate.eng/tonic/gcc-gate. > > I'll be updating it daily or as close to daily as possible. It > includes fixes for the following bugs: > > 6241280 cw should support SPARC > 6241282 cw should be bootstrappable with gcc > 6241287 g++ doesn't want wchar_t under any circumstances > 6241296 kernel files must include sys/note.h rather than note.h > 6241298 gcc flag -mcmodel=small is not appropriate for 32-bit builds > 6241304 x86 bitmap header needs typo fix > 6241310 ssc100 has incorrect format string > 6241313 codereview should be lint and cstyle clean > 6241972 cscope-fast should build with gcc > 6241980 movw applies to %ax rather than %eax > 6241984 isa_defs.h should not redefine _LP64 > 6241993 SPARC siglongjump symbol aliasing is wrong > 6241995 warnings in sgs should be fixed > 6242262 ON should build with gcc In case it isn't apparent, the diffs I sent previously generate the OpenSolaris equivalent of this workspace. There are two files modified that still aren't included, so those portions of the diffs are removed so that they will apply cleanly. Otherwise the result should be the same. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From benr at cuddletech.com Tue Mar 22 14:45:03 2005 From: benr at cuddletech.com (Ben Rockwood) Date: Tue, 22 Mar 2005 14:45:03 -0800 Subject: [gcc] [Fwd: notes from gcc work meeting (3/16)] In-Reply-To: <42408554.90902@eng.sun.com> References: <42408554.90902@eng.sun.com> Message-ID: <42409FEF.7020805@cuddletech.com> Karyn, Thank you very much for putting us directly in the loop reguarding this project. This will eleviate much of my fear of duplication and give me the direction needed to proceed on a charted path. This is exactly the type of cooperation I've been excited about. Question reguarding the project finish date of 6/17/05: Is that the tenative Tonic release date? benr. Karyn Ritter wrote: > Several of the Sun engineers assigned to help with the gcc work had a > meeting last week to ensure they had all of the appropriate > information to start the work. > > I apologize for not sending the email out to the alias immediately -- > it was an oversight. All of the Sun engineers are now on this alias, > and we will have project discussions here from now on. I'll forward > you the two emails which have been sent out on this topic. > > Please let me know if you have any questions about the notes. We're > still working on getting some of the files associated with this work > released under CDDL right away. Unfortunately most of them require > cleanup, so there has been a delay in making them available. > > Thanks, > > Karyn > > -------- Original Message -------- > Subject: notes from gcc work meeting (3/16) > Date: Wed, 16 Mar 2005 15:50:19 -0800 > From: Karyn Ritter > To: Andrei Dorofeev , Matt Simmons > , Craig Mohrman , > mike_s at eng.sun.com, Keith Wesolowski > CC: Linda Bernal > > Agenda: > * Review project logistics (e.g., project gate) [Keith] > * Clarification of the work that needs to be done [all] > * Other questions/issues you want to raise [all] > * How best to manage the project work [Karyn/all] > > AIs: > > 03162005-01: Keith will send out a pointer to the project gate and the > special version of gcc he is using. > Due date: 3/17/05 > Status: > > 03162005-02: Keith will talk to tpm about the libgcc functions that > were implemented in the kernel for AMD-64, and will send > out the appropriate details. > Due date: 3/17/05 > Status: DONE > > Follow up information from Keith on AI 03162005-02: > The amd64 team got the kernel building (not all of userland) with > some functions from BSD. These can be found at > /net/tread/export/gates/amd64-boot/usr/src/uts/intel/ia32/ml. Only > those functions are there which were needed to generate a working > kernel; libc or other userland code may generate additional calls. > I would recommend putting these in common/ (the bignum stuff used by > openssl is a good example). These functions can be optimized by > checking whether the upper 32 bits of the argument(s) are zero and > performing regular operations instead. They could perhaps be > rewritten in assembly if they still prove to be a bottleneck. > > See also related bug 6220152. Fixing this bug may or may not be a > necessary component of the C++ work. > > 03162005-03: Keith to send Matt and Karyn the bug number for the CTF > issue(s). > Due date: 3/17/05 > Status: DONE > > 03162005-04: Keith will check on the use of as vs. gas for 32-bit x86, > and will follow up with Andrei on any issues. > Due date: 3/17/05 > Status: DONE > > 03162005-05: Keith will talk to Rod Evans/Mike Walker about the > rtldboot (gas/as). > Due date: 3/17/05 > Status: > > 03162005-06: Karyn will check in with everyone at least once a week to > see how things are going. > Due date: ongoing > Status: > > Discussion summary: > > Keith reviewed the work that has been done and what needs to be done. > > We decided that setting up a weekly meeting is unnecessary. As > questions come up, everyone will talk to Keith. If needed, we can > schedule a meeting. > > Karyn will follow up with everyone on a regular (at least weekly) > basis to check progress. > > Verified that the schedule estimates were pretty accurate. > > Attendees: > Linda Bernal > Andrei Dorofeev > Craig Mohrman > Matt Simmons > Mike Sullivan > Keith Wesolowski > > _______________________________________________ > gcc mailing list > gcc at opensolaris.org > https://www.opensolaris.org/mailman/listinfo/gcc From kritter at eng.sun.com Tue Mar 22 15:06:57 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Tue, 22 Mar 2005 15:06:57 -0800 Subject: [gcc] [Fwd: notes from gcc work meeting (3/16)] In-Reply-To: <42409FEF.7020805@cuddletech.com> References: <42408554.90902@eng.sun.com> <42409FEF.7020805@cuddletech.com> Message-ID: <4240A511.7000707@eng.sun.com> > Karyn, Thank you very much for putting us directly in the loop > reguarding this project. This will eleviate much of my fear of > duplication and give me the direction needed to proceed on a charted > path. This is exactly the type of cooperation I've been excited about. > > Question reguarding the project finish date of 6/17/05: Is that the > tenative Tonic release date? > No, that's just the day we're planning to be done with this work. Our hope/plan has always been to get the SOS10 compilers to be freely available, and gcc support would be a secondary option for people. So, we may launch earlier if there is a decision about the SOS10 compilers in the next several weeks. Everyone on the OpenSolaris team wishes we had something more definitive to say about the launch date and the availability of this stuff, but it is out of our hands. :( Of course, if we don't get a decision about the SOS10 compilers, we would launch sometime shortly after the gcc work is done. The only thing I know for certain is that my bosses and I will be in trouble if we don't launch before July 1. :) Thanks, Karyn From schilling at fokus.fraunhofer.de Tue Mar 22 15:18:24 2005 From: schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Wed, 23 Mar 2005 00:18:24 +0100 Subject: [gcc] [Fwd: notes from gcc work meeting (3/16)] In-Reply-To: <4240A511.7000707@eng.sun.com> References: <42408554.90902@eng.sun.com> <42409FEF.7020805@cuddletech.com> <4240A511.7000707@eng.sun.com> Message-ID: <4240A7C0.nail3TT17MP5C@burner> Karyn Ritter wrote: > Everyone on the OpenSolaris team wishes we had something more definitive > to say about the launch date and the availability of this stuff, but it > is out of our hands. :( > > Of course, if we don't get a decision about the SOS10 compilers, we > would launch sometime shortly after the gcc work is done. The only thing > I know for certain is that my bosses and I will be in trouble if we > don't launch before July 1. :) > Good luck for June 30th. I would prefer a late launch together with an early clean up of the boot code and a chance for us to make a bootable and useful pure OpenSolaris distibution possible. I also hope that the GCC talk will help to find a useful SOS10 compiler decision ;-) 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 stonent at gmail.com Tue Mar 22 16:04:37 2005 From: stonent at gmail.com (Jason Wohgemuth) Date: Tue, 22 Mar 2005 18:04:37 -0600 Subject: [gcc] gcc schedule In-Reply-To: <42408565.4020504@eng.sun.com> References: <42408565.4020504@eng.sun.com> Message-ID: Out of curiosity, which release of GCC is going to be the target? GCC 3.3.x is pretty standard in most Linux Distros GCC 3.4.x is what most new ones have. (It was what we were using for Portage on Solaris) GCC 4.0-snapshot is what is going in the next "beta" of Fedora core. I'm using GCC 4.0-snapshot (updating once a week) in Gentoo right now. Having vectorization on processors with SIMD is nice (I think SSE, SSE2 and Altivec are supported currently, but maybe with some help from Sun, VIS could be supported as well). On the other hand, GCC-4 is very strict about code. It errors out on a lot of code "shortcuts" that people do like improper declarations of things. As I am not very familiar with Sun's compiler, this may not be a big issue if it wants strict ANSI C. On Tue, 22 Mar 2005 12:51:49 -0800, Karyn Ritter wrote: > As promised, attached is the schedule we're currently operating toward > for gcc. I expect it to change slightly based on actual delivery dates. > > Please let me know if you have any questions. > > Thanks, > > Karyn From keith.wesolowski at sun.com Tue Mar 22 19:55:52 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Tue, 22 Mar 2005 19:55:52 -0800 Subject: [gcc] gcc schedule In-Reply-To: References: <42408565.4020504@eng.sun.com> Message-ID: <20050323035551.GA19314@sun.com> On Tue, Mar 22, 2005 at 06:04:37PM -0600, Jason Wohgemuth wrote: > Out of curiosity, which release of GCC is going to be the target? The one we currently ship, 3.4.3. > I'm using GCC 4.0-snapshot (updating once a week) in Gentoo right now. > Having vectorization on processors with SIMD is nice (I think SSE, > SSE2 and Altivec are supported currently, but maybe with some help > from Sun, VIS could be supported as well). On the other hand, GCC-4 `-mvis' `-mno-vis' With `-mvis', GCC generates code that takes advantage of the UltraSPARC Visual Instruction Set extensions. The default is `-mno-vis'. This has been around a long time, at least during 3.x and maybe 2.95. > is very strict about code. It errors out on a lot of code > "shortcuts" that people do like improper declarations of things. As I > am not very familiar with Sun's compiler, this may not be a big issue > if it wants strict ANSI C. What we want and what we have are two different matters. :-) It would be nice to have everything be strict ISO C99. A few parts already do use this mode, but most don't. Fixing the 17000+ warnings that even gnu89 mode finds will be one step down that path. There's still a lot of code lacking even ANSI prototypes. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From stonent at gmail.com Tue Mar 22 22:59:32 2005 From: stonent at gmail.com (Jason Wohgemuth) Date: Wed, 23 Mar 2005 00:59:32 -0600 Subject: [gcc] gcc schedule In-Reply-To: <20050323035551.GA19314@sun.com> References: <42408565.4020504@eng.sun.com> <20050323035551.GA19314@sun.com> Message-ID: Well this -ftree-vectorize flag allows a loop to be vectorized like ICC can do to work with one of the various SIMD implementations. Right now -ftree-vectorize is only suppored with SSE,SSE2 and Altivec. http://gnu.mirror.fr/software/gcc/projects/tree-ssa/vectorization.html#vectorizab > > `-mvis' > `-mno-vis' > With `-mvis', GCC generates code that takes advantage of the > UltraSPARC Visual Instruction Set extensions. The default is > `-mno-vis'. > > This has been around a long time, at least during 3.x and maybe 2.95. From kritter at eng.sun.com Wed Mar 23 14:09:12 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Wed, 23 Mar 2005 14:09:12 -0800 Subject: [gcc] status? Message-ID: <4241E908.5040605@eng.sun.com> OK, I know it hasn't even been a week since you all got started on your respective pieces of the gcc work, but I would still like to know how things are going and whether or not you're on track. Matt I got your message about being ready to putback to the project gate on Friday (3/25). Please let me know if you aren't on track for this date. Andrei Are you on track for 4/14? Will you be done sooner (she asks hopefully)? Craig Are you on track for 4/5? Mike What have you learned from your C++ evaluation? What work is needed? If so, who should I try to get to help? Keith Are you finished with the bugs you were working on? Have they been putback? When will be starting on the test plan? I'm still trying to get some additional resources assigned to help fix the warnings. My approach is to work with the owners of the functionality/files to do the work. We should definitely talk about how best to divvy up the files between internal and external members of the community. Of course, we need to release them first... :) Thanks, Karyn From mike_s at yavin.Eng.Sun.COM Wed Mar 23 14:12:49 2005 From: mike_s at yavin.Eng.Sun.COM (Mike Sullivan) Date: Wed, 23 Mar 2005 14:12:49 -0800 (PST) Subject: [gcc] status? Message-ID: <200503232212.j2NMCmvb191526@yavin.Eng.Sun.COM> >X-Original-To: gcc at opensolaris.org >Delivered-To: gcc at opensolaris.org >Date: Wed, 23 Mar 2005 14:09:12 -0800 >From: Karyn Ritter >To: gcc at opensolaris.org >MIME-version: 1.0 >Content-transfer-encoding: 7BIT >X-Accept-Language: en-us, en >User-Agent: Mozilla Thunderbird 0.5 (X11/20040210) >Cc: Linda Bernal >Subject: [gcc] status? >X-BeenThere: gcc at opensolaris.org >X-Mailman-Version: 2.1.4 >List-Id: GCC porting discussion >List-Unsubscribe: , >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >OK, I know it hasn't even been a week since you all got started on your >respective pieces of the gcc work, but I would still like to know how >things are going and whether or not you're on track. > > Matt I got your message about being ready to putback to the > project gate on Friday (3/25). Please let me know if you > aren't on track for this date. > > Andrei Are you on track for 4/14? Will you be done sooner (she asks > hopefully)? > > Craig Are you on track for 4/5? > > Mike What have you learned from your C++ evaluation? What work is > needed? If so, who should I try to get to help? I just brought over a workspace. Next is probably to learn C++ :) Mike > > Keith Are you finished with the bugs you were working on? Have > they been putback? When will be starting on the test plan? > >I'm still trying to get some additional resources assigned to help fix >the warnings. My approach is to work with the owners of the >functionality/files to do the work. We should definitely talk about how >best to divvy up the files between internal and external members of the >community. Of course, we need to release them first... :) > >Thanks, > >Karyn >_______________________________________________ >gcc mailing list >gcc at opensolaris.org >https://www.opensolaris.org/mailman/listinfo/gcc From keith.wesolowski at sun.com Wed Mar 23 14:39:19 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Wed, 23 Mar 2005 14:39:19 -0800 Subject: [gcc] status? In-Reply-To: <4241E908.5040605@eng.sun.com> References: <4241E908.5040605@eng.sun.com> Message-ID: <20050323223918.GB106072@sun.com> On Wed, Mar 23, 2005 at 02:09:12PM -0800, Karyn Ritter wrote: > Keith Are you finished with the bugs you were working on? Have > they been putback? When will be starting on the test plan? Yes, the work is done. No, it's not putback yet. I started on the test plan yesterday and should have something reasonable by the end of the week. Anyone who wants to provide input on the test plan is welcome to do so. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From dorofeev at gmail.com Wed Mar 23 16:29:11 2005 From: dorofeev at gmail.com (Andrei Dorofeev) Date: Wed, 23 Mar 2005 16:29:11 -0800 Subject: [gcc] status? In-Reply-To: <4241E908.5040605@eng.sun.com> References: <4241E908.5040605@eng.sun.com> Message-ID: I should be done with assembly inlines by 4/14. If I can get it done sooner, you'll be the first to know about it :-) On Wed, 23 Mar 2005 14:09:12 -0800, Karyn Ritter wrote: > OK, I know it hasn't even been a week since you all got started on your > respective pieces of the gcc work, but I would still like to know how > things are going and whether or not you're on track. > > Matt I got your message about being ready to putback to the > project gate on Friday (3/25). Please let me know if you > aren't on track for this date. > > Andrei Are you on track for 4/14? Will you be done sooner (she asks > hopefully)? > > Craig Are you on track for 4/5? > > Mike What have you learned from your C++ evaluation? What work is > needed? If so, who should I try to get to help? > > Keith Are you finished with the bugs you were working on? Have > they been putback? When will be starting on the test plan? > > I'm still trying to get some additional resources assigned to help fix > the warnings. My approach is to work with the owners of the > functionality/files to do the work. We should definitely talk about how > best to divvy up the files between internal and external members of the > community. Of course, we need to release them first... :) > > Thanks, > > Karyn > _______________________________________________ > gcc mailing list > gcc at opensolaris.org > https://www.opensolaris.org/mailman/listinfo/gcc > From Craig.Mohrman at eng.sun.com Thu Mar 24 10:56:07 2005 From: Craig.Mohrman at eng.sun.com (Craig Mohrman) Date: Thu, 24 Mar 2005 10:56:07 -0800 (PST) Subject: [gcc] status? Message-ID: <200503241856.j2OIu6cv241176@jurassic.eng.sun.com> > Craig Are you on track for 4/5? > I don't know where I'm at. I'm running several days behind so just starting today on this. Leave the 4/5 date until I know better. craig From keith.wesolowski at sun.com Tue Mar 29 17:27:45 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Tue, 29 Mar 2005 17:27:45 -0800 Subject: [gcc] Test plan draft Message-ID: <20050330012745.GA101116@sun.com> Here's my draft outline for testing gcc bits. I've tried to resist the temptation to throw every conceivable test at it because although a compiler switch could conceivably cause almost any kind of problem, it's likely that any problems it does cause will be sufficiently systemic as to make detection unavoidable. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From kupfer at athyra.eng.sun.com Thu Mar 31 10:17:19 2005 From: kupfer at athyra.eng.sun.com (Mike Kupfer) Date: Thu, 31 Mar 2005 10:17:19 -0800 Subject: [gcc] Test plan draft In-Reply-To: Message from Keith M Wesolowski of "Tue, 29 Mar 2005 17:27:45 PST." <20050330012745.GA101116@sun.com> Message-ID: <200503311817.j2VIHJp0187301@athyra.eng.sun.com> Overall looks reasonable to me. > 2.3 Assumptions ... > We assume that the ON code does rely on nonstandard DevPro > features in providing its functionality. Should that be "does not rely on"? > 5.3 Conformance Testing I think SVVS is limited to SVID conformance. We have other conformance test suites that might be more interesting (e.g., VSX/VSU, MSTC). > 5.4 Stress Testing Section 5.2 raises a concern about libc and threading. If you're concerned about multithreaded code being correct, then I'd also look at stress testing beyond what PIT does. > 6.1 Hardware Test Configurations > > We will test only a fraction of the x86 systems listed in Solaris HCL (for > both desktop/server systems and laptops). The final list will be based on > hardware availability. We should state in writing that we'll test both ia32 and amd64 systems. cheers, mike From kritter at eng.sun.com Thu Mar 31 10:22:25 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Thu, 31 Mar 2005 10:22:25 -0800 Subject: [gcc] Test plan draft In-Reply-To: <200503311817.j2VIHJp0187301@athyra.eng.sun.com> References: <200503311817.j2VIHJp0187301@athyra.eng.sun.com> Message-ID: <424C3FE1.8010803@eng.sun.com> Mike, >>5.4 Stress Testing > > > Section 5.2 raises a concern about libc and threading. If you're > concerned about multithreaded code being correct, then I'd also look at > stress testing beyond what PIT does. > Can you recommend any teams or types of stress tests that are available outside of PIT? I was thinking about approaching the PAE, iForce, system test, and/or any other groups around that test all of Solaris in a variety of ways rather than relying on O/N-only testing. Of course, at some point we hit the law of diminishing returns... Thanks, Karyn From kupfer at athyra.eng.sun.com Thu Mar 31 10:47:19 2005 From: kupfer at athyra.eng.sun.com (Mike Kupfer) Date: Thu, 31 Mar 2005 10:47:19 -0800 Subject: [gcc] Test plan draft In-Reply-To: Message from Karyn Ritter of "Thu, 31 Mar 2005 10:22:25 PST." <424C3FE1.8010803@eng.sun.com> Message-ID: <200503311847.j2VIlJQl187581@athyra.eng.sun.com> >>>>> "Karyn" == Karyn Ritter writes: >>> 5.4 Stress Testing >> Section 5.2 raises a concern about libc and threading. If you're >> concerned about multithreaded code being correct, then I'd also >> look at stress testing beyond what PIT does. Karyn> Can you recommend any teams or types of stress tests that are Karyn> available outside of PIT? I can tell you what the NFS group did when I worked on NFS. The main stress tests that we had were a program called lock_stress, and full builds. lock_stress might be in PIT, but I vaguely recall something about dialing down some of the parameters so that the test would finish more quickly. As for the builds, we'll obviously be doing some of that just as part of normal development. But we might look at doing builds using configurations that we don't normally use (e.g., over NFS, or on systems we wouldn't normally use as a build system). Karyn> I was thinking about approaching the PAE, iForce, system Karyn> test, and/or any other groups around that test all of Solaris Karyn> in a variety of ways rather than relying on O/N-only testing. PAE sounds good, since they could also flag performance regressions (if there are any). Dunno about the others. I'd check with Bart and maybe with the DTrace team to see if they have any suggestions. Karyn> Of course, at some point we hit the law of diminishing Karyn> returns... Agreed. I'd try to get a list of 6-10 tests and then pick the top 3 or so, trying to maximize code coverage. mike From keith.wesolowski at sun.com Thu Mar 31 12:15:20 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Thu, 31 Mar 2005 12:15:20 -0800 Subject: [gcc] Test plan draft In-Reply-To: <200503311817.j2VIHJp0187301@athyra.eng.sun.com> References: <20050330012745.GA101116@sun.com> <200503311817.j2VIHJp0187301@athyra.eng.sun.com> Message-ID: <20050331201520.GB763@sun.com> On Thu, Mar 31, 2005 at 10:17:19AM -0800, Mike Kupfer wrote: > > We assume that the ON code does rely on nonstandard DevPro > > features in providing its functionality. > > Should that be "does not rely on"? Yes, thanks. > > 5.3 Conformance Testing > > I think SVVS is limited to SVID conformance. We have other conformance > test suites that might be more interesting (e.g., VSX/VSU, MSTC). I think we should definitely add MSTC, and I've done so. I can't seem to find VSX or VSU anywhere; can you give me a pointer? I did look at VSC and decided it wasn't likely to be useful. > We should state in writing that we'll test both ia32 and amd64 systems. Added, thanks. I also explicitly noted that BSST should be run in addition to SVVS. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From kupfer at athyra.eng.sun.com Thu Mar 31 12:57:13 2005 From: kupfer at athyra.eng.sun.com (Mike Kupfer) Date: Thu, 31 Mar 2005 12:57:13 -0800 Subject: [gcc] Test plan draft In-Reply-To: Message from Keith M Wesolowski of "Thu, 31 Mar 2005 12:15:20 PST." <20050331201520.GB763@sun.com> Message-ID: <200503312057.j2VKvDig188426@athyra.eng.sun.com> >>>>> "Keith" == Keith M Wesolowski writes: Keith> I can't seem to find VSX or VSU anywhere; can you give me a Keith> pointer? http://stds-test.eng/ You might find that MSTC already covers most or all of what VSX covers; maybe VSU, too. mike