I am building gcc 4.4.0 [trunk revision 144083] for OpenSolaris 2009.06 . I have ./configured using: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local ---------- When (some) other people build for a 64-Bit Operating System and they submit Testsuite Results the results _sometimes_ have entries like these in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01039.html ... Native configuration is x86_64-unknown-linux-gnu === g++ tests === Running target unix/-m32 === g++ Summary for unix/-m32 === # of expected passes 6810 # of expected failures 28 # of unsupported tests 10 Running target unix === g++ Summary for unix === # of expected passes 6763 # of expected failures 28 # of unsupported tests 20 === g++ Summary === # of expected passes 38731 # of expected failures 282 # of unsupported tests 346 /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../g++ version 4.4.0 20090210 (experimental) [trunk revision 144083] (GCC) ... ---------- When I built gcc and submitted my Testsuite Results I do NOT get "multilib Tests", see: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01013.html When I 'file' gcc (built, booted in 64-Bit Mode) using the "file" command I see: # file /usr/local/bin/gcc /usr/local/bin/gcc: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped I see that as 'acceptable' but technically it is wrong. What is _great_ is that the executable will run in both 32 and 64 bit Boot Mode. So let us _not_ fix that portion of this Bug. The "Bug" in gcc 4.4.0 [trunk revision 144083] is that the "config.guess" (and other related files, EG: config.host) only support the 'HTB' of i386-pc-solaris2.* and do not support (without a little modification) either the 'pseudo-name' (it is renamed) amd64-pc-solaris2.* _or_ the Target x86_64-pc-solaris2.* . This issue starts in ../gcc_trunk/config.guess (near line 333): ... i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*) eval $set_cc_for_build SUN_ARCH="i386" # If there is a compiler, see if it is configured for 64-bit objects. # Note that the Sun cc does not turn __LP64__ into 1 like gcc does. # This test works for both compilers. if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then SUN_ARCH="x86_64" fi fi # I added this section, see: http://defect.opensolaris.org/bz/show_bug.cgi?id=2820#c6 case "`isainfo -k`" in amd64) SUN_ARCH="amd64";; *) SUN_ARCH="i386";; esac echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` exit ;; ... Please notice that (according to the notes in the code) the supposed purpose of that code is to determine if "it is configured for 64-bit objects". The code I added checks the Boot Mode (and assumes that the compiler will work in the mode it is booted in). In doing so it alters the Target from 'i386-pc-solaris2.11 to 'x86_64-pc-solaris2.11'. A few fixes to files '../gcc_trunk/libjava/classpath/config.guess', '../gcc_trunk/libgcc/config.host' and '../gcc_trunk/gcc/config.gcc' and we are all set ... I hope that once I have built gcc with a few small mods that I will then be able to run the full "multilib Testsuite". Mine (for now), Fixing, back with the diffs and Test Results, Rob
How is this major, this is an enhancement to the build system. i386-solaris is a multi arch target so it includes the x86_64 solaris target also.
(In reply to comment #1) > How is this major, this is an enhancement to the build system. i386-solaris is > a multi arch target so it includes the x86_64 solaris target also. It could be called an "enhancement to the build system". I call it a "fault of the build system" and a subsequent "fault of the test system" in that this Operating System has 2 ABIs and much of gcc seems to rely on 'uname' to determine the HTB, that is a mistake. The correct manner for gcc to decide that the HOST is the so-called "x86_64-pc-solaris2.11" host is to correctly query the Boot Mode. That is something that gcc does not do correctly on this Platform. I do not know that it is an "enhancement" that this Platform should build and test in the the same manner as other Platforms. I call it a major Bug. I guess it is a matter of semantics. Rob
Here is another person who makes the same complaint (with a patch): http://hackage.haskell.org/trac/ghc/ticket/2951
Googling for "amd64-pc-solaris2.11" gives a few hits. Googling for "x86_64-pc-solaris2.11" gives a dozen hits. That is not many. Perhaps there is 'no such word'. It seems there are a few others who discovered this problem: http://osdir.com/ml/linux.debian.devel.dpkg.bugs/2006-04/msg00106.html http://gcc.gnu.org/ml/gcc/2004-12/msg00461.html http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?msg=47;bug=1191 Rob
Results for 4.4.0 20090215 (experimental) [trunk revision 144190] (GCC) testsuite on x86_64-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html Rob
this sounds like bug #30726 for what it's worth, my updated patches for gcc-4.4 can be found here: http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys-devel/gcc/files/4.4.0/gcc-4.4.1-solaris-x86_64.patch?format=txt (sorry for the download)
As long as there are any Solaris 2/x86 versions supported with 32-bit kernels, we'll need to keep the i386-pc-solaris2* configurations, which handles creating 64-bit binaries just fine. Adding an additional 64-bit default configuration (like amd64-pc-solaris2* or whatever) doubles the testing burden on me for no real benefit. In fact, I believe that the sparcv9-sun-solaris2 configurations were a mistake and should be removed, rather than adding this for Solaris 2/x86, too. I'll probably refuse patches to add them since they complicate the port for little apparent benefit. With respect to multilib testing, this isn't enabled by default on any platform; you either need a dejagnu config file for that, or run % make -k RUNTESTFLAGS='--target_board "unix{,-m64}"' You're right that this should be properly documented in the testing instructions. Please file a new PR for that issue.
As stated: closing as WONTFIX.
*** Bug 30726 has been marked as a duplicate of this bug. ***
> Adding an additional 64-bit default configuration > (like amd64-pc-solaris2* or whatever) doubles the testing burden on me for no > real benefit. In fact, I believe that the sparcv9-sun-solaris2 configurations > were a mistake and should be removed, rather than adding this for Solaris > 2/x86, too. While the advantages of sparc64-sun-solaris2.* are limited, I don't think we should remove it now since it can handle more memory and 64-bit computing is becoming the norm. Similarly, I think adding a 64-bit compiler on x86 would be desirable. And it would be faster than the 32-bit one because of the 64-bit ABI. As a matter of fact, we already have the few required patches at AdaCore.
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). > ------- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-04-28 22:09 ------- > While the advantages of sparc64-sun-solaris2.* are limited, I don't think we > should remove it now since it can handle more memory and 64-bit computing is > becoming the norm. I have no actual intention of doing so, although it increases the complexity of the target headers. > Similarly, I think adding a 64-bit compiler on x86 would be desirable. And it > would be faster than the 32-bit one because of the 64-bit ABI. As a matter of > fact, we already have the few required patches at AdaCore. Patches have been floating around, and I'm sure I could get them into shape. My problem (apart from the same complexity problem as on SPARC) isn't primarily cpu power of my testfarm, but rather the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that, given that this is a spare-time activity. That's why I'm even opposed to take patches, since than I'm forced to deal with issues as well. Since the Sun Studio compilers are still exclusively 32-bit as wall, I see no strong reason for GCC to be different. Rainer
>> ... the time it takes to analyze and fix problems. This is practically >> doubled if you have two different configurations to test, and I simply >> cannot afford that, given that this is a spare-time activity. That's >> why I'm even opposed to take patches, since than I'm forced to deal >> with issues as well. We hear you on that. This is an "Enhancement" (EG: I wish (someday in the future) that we had this feature) and I would have preferred it remain open until the need for the feature exceeded the lack of available time to implement it (as Eric pointed out we may cross that line shortly). I can settle for this being re-opening in the future and will accept WONTFIX for now, (since it would be a fair bit of work to get everything working correctly). Rob
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). > ------- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ------- > This is an "Enhancement" (EG: I wish (someday in the future) that we had this > feature) and I would have preferred it remain open until the need for the > feature exceeded the lack of available time to implement it (as Eric pointed > out we may cross that line shortly). But what's the *point* of having such a configuration, except as a prove of `we can do that'? Any actual problem that would be solved this way? Rainer
> But what's the *point* of having such a configuration, except as a prove > of `we can do that'? Any actual problem that would be solved this way? Same as on Linux: the compiler will be faster and able to handle more memory.
(In reply to comment #13) > Subject: Re: Configure scripts have no 64-Bit Solaris defined (only > i386-solaris*). > > > ------- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ------- > > > This is an "Enhancement" (EG: I wish (someday in the future) that we had this > > feature) and I would have preferred it remain open ... > > But what's the *point* of having such a configuration, except as a prove > of `we can do that'? Any actual problem that would be solved this way? > > Rainer > (In reply to comment #13) > Same as on Linux: the compiler will be faster and able to handle more memory. OpenSolaris is 64 Bit; it's ability to run on older Hardware is a convenience, not a requirement. Similarly gcc could output 80286 / 80387 code ONLY, for Intel Platforms, as that would be easier also ... Support for both modes (and more to come) is not so much "proof we can do that" as it is the "normal thing" (compared to other Platforms) to do. The inability of the "Build Mechanism" to operate in a similar manner (logic) as it does on Linux is support of a third way of building gcc rather than proof that doing it one way is easier. OpenSolaris recently added support for the ARM Processor, so that adds a few more 'multi-lib modes' that need to be supported, along with the expanded line of SPARC Processors now being supported. The OpenSolaris Group also has a 'call for Ports', so in theory our mechanism _must_ be general enough to support any possible Processor (in the future, you don't need to do everything today!). I would be more than happy to request from Oracle a "gcc Team" be created and dispatched here. The result of a successful request _might_ be a tiny Team of experts (OS Design / Compiler Writers) that would assist with Testing, Patching, Solaris Expertise, and bring with them an assignment to a share of the Server Farm. They have such a Liaison for most larger Programs and supported Hardware. I can foresee one or two getting "assigned" and a half dozen or so volunteer when they hear of your hardship ("... rather the time it takes to analyze and fix problems. This is practically doubled if you have two different configurations to test, and I simply cannot afford that ..."). Do one of you wish to ask or shall I ? (Note: It might take 3-6 months to get approved as some may be paid; so lets get started). Rob
(In reply to comment #15) > (In reply to comment #13) > > Subject: Re: Configure scripts have no 64-Bit Solaris defined (only > > i386-solaris*). > > > > > ------- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ------- > > > > > This is an "Enhancement" (EG: I wish (someday in the future) that we had this > > > feature) and I would have preferred it remain open ... > > > > ... > > > OpenSolaris recently added support for the ARM Processor, so that adds a few > more 'multi-lib modes' that need to be supported, along with the expanded line > of SPARC Processors now being supported. The OpenSolaris Group also has a 'call > for Ports', so in theory our mechanism _must_ be general enough to support any > possible Processor ... > ... > Rob Additional note for this RFE (which _might_ get re-opened, someday): OpenSolaris now runs on mips-sun-solaris2.11 http://hub.opensolaris.org/bin/view/Project+mips/Tools Rob
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*). > ------- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 ------- > (In reply to comment #15) >> (In reply to comment #13) >> OpenSolaris recently added support for the ARM Processor, so that adds a few >> more 'multi-lib modes' that need to be supported, along with the expanded line True, but irrelevant: each port only supports the multilibs it needs, and not several different configurations with each from the set of multilibs becoming the default. >> of SPARC Processors now being supported. The OpenSolaris Group also has a 'call >> for Ports', so in theory our mechanism _must_ be general enough to support any >> possible Processor ... The mechanism is, of course. > Additional note for this RFE (which _might_ get re-opened, someday): > > OpenSolaris now runs on mips-sun-solaris2.11 > http://hub.opensolaris.org/bin/view/Project+mips/Tools Far from it: there are minimal binutils and gcc patches yet, nothing more. Rainer
(In reply to comment #17) > Subject: Re: Configure scripts have no 64-Bit Solaris defined (only > i386-solaris*). > > > ------- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 ------- > > (In reply to comment #15) > >> (In reply to comment #13) > > >> OpenSolaris recently added support for the ARM Processor, so that adds a few > >> more 'multi-lib modes' that need to be supported, along with the expanded line > > True, but irrelevant: each port only supports the multilibs it needs, > and not several different configurations with each from the set of > multilibs becoming the default. > Arm has thumb, and not, and either endian. It is not irrelevant and we do understand you don't want the extra work - even reading the prior posts in this thread. Noted. > >> of SPARC Processors now being supported. The OpenSolaris Group also has a 'call > >> for Ports', so in theory our mechanism _must_ be general enough to support any > >> possible Processor ... > > The mechanism is, of course. If it were, we (meaning more people than only you and I) would not be debating this. > > Additional note for this RFE (which _might_ get re-opened, someday): > > > > OpenSolaris now runs on mips-sun-solaris2.11 > > http://hub.opensolaris.org/bin/view/Project+mips/Tools > > Far from it: there are minimal binutils and gcc patches yet, nothing > more. > > Rainer > More for you to do ;) . We wish you all the best, happy programming. Rob
(In reply to comment #10) > > Adding an additional 64-bit default configuration > > (like amd64-pc-solaris2* or whatever) doubles the testing burden on me for no > > real benefit. In fact, I believe that the sparcv9-sun-solaris2 configurations > > were a mistake and should be removed, rather than adding this for Solaris > > 2/x86, too. > While the advantages of sparc64-sun-solaris2.* are limited, I don't think we > should remove it now since it can handle more memory and 64-bit computing is > becoming the norm. > Similarly, I think adding a 64-bit compiler on x86 would be desirable. And it > would be faster than the 32-bit one because of the 64-bit ABI. As a matter of > fact, we already have the few required patches at AdaCore. Eric, here were my results when I tried a year and a half ago. Not too bad, actually fairly good for a first attempt: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html Rob
I know this PR is closed, and don't want to reopen it or anything; sorry for being late to the party. But the information missing from it is that ../gcc/configure CC='gcc -m64' ... should allow config.guess to infer 64-bit mode. If install.texi does not recommend putting ABI flags in $CC, then it probably should.
Mine, patch posted.
Author: ro Date: Thu Jul 7 09:24:16 2011 New Revision: 175958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175958 Log: gcc: PR target/39150 * configure.ac (gcc_cv_as_hidden): Also accept x86_64-*-solaris2.1[0-9]*. (gcc_cv_as_cfi_directive): Likewise. (gcc_cv_as_comdat_group_group): Likewise. (set_have_as_tls): Likewise. * configure: Regenerate. * config.gcc (i[34567]86-*-solaris2*): Also handle x86_64-*-solaris2.1[0-9]*. * config.host (i[34567]86-*-solaris2*): Likewise. * config/sparc/sol2.h (ASM_CPU_DEFAULT_SPEC): Remove. * config/sol2-bi.h (ASM_CPU_DEFAULT_SPEC): Redefine. [USE_GLD] (ARCH_DEFAULT_EMULATION): Define. (TARGET_LD_EMULATION): Use it. * config/i386/sol2.h (ASM_CPU_DEFAULT_SPEC): Define. (SUBTARGET_CPU_EXTRA_SPECS): Add asm_cpu_default. * config/i386/sol2-bi.h (ASM_CPU32_DEFAULT_SPEC): Define. (ASM_CPU64_DEFAULT_SPEC): Define. (ASM_CPU_SPEC): Use %(asm_cpu_default). (ASM_SPEC): Redefine. (DEFAULT_ARCH32_P): Define using TARGET_64BIT_DEFAULT. * config/host-solaris.c [__x86_64__] (TRY_EMPTY_VM_SPACE): Reduce. * doc/install.texi (Specific, amd64-*-solaris2.1[0-9]*): Document. (Specific, i?86-*-solaris2.10): Mention x86_64-*-solaris2.1[0-9]* configuration. (Specific, x86_64-*-solaris2.1[0-9]*): Document. gcc/ada: PR target/39150 * gcc-interface/Makefile.in: Handle x86_64-solaris2. libgcc: PR target/39150 * config.host (*-*-solaris2*): Handle x86_64-*-solaris2.1[0-9]* like i?86-*-solaris2.1[0-9]*. (i[34567]86-*-solaris2*): Also handle x86_64-*-solaris2.1[0-9]*. * configure.ac (i?86-*-solaris2*): Likewise. * configure: Regenerate. gcc/testsuite: PR target/39150 * gcc.misc-tests/linkage.exp: Handle x86_64-*-solaris2.1[0-9]*. toplevel: PR target/39150 * configure.ac (i[3456789]86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. * configure: Regenerate. boehm-gc: PR target/39150 * configure.ac (i?86-*-solaris2.[89]): Also accept x86_64-*-solaris2.1?. * configure: Regenerate. gnattools: PR target/39150 * configure.ac (*86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. * configure: Regenerate. libcpp: PR target/39150 * configure.ac (host_wide_int): Handle x86_64-*-solaris2.1[0-9] like i[34567]86-*-solaris2.1[0-9]*. * configure: Regenerate. libgo: PR target/39150 * config/libtool.m4: Handle x86_64-*-solaris2.1[0-9]* like i?86-*-solaris*. * configure: Regenerate. libjava: PR target/39150 * configure.host (x86_64-*): Add -Usun to libgcj_flags. (x86_64-*-solaris2.1[0-9]*): New case. (i?86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. Modified: trunk/ChangeLog trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/config/host-solaris.c trunk/gcc/config/i386/sol2-bi.h trunk/gcc/config/i386/sol2.h trunk/gcc/config/sol2-bi.h trunk/gcc/config/sparc/sol2.h trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/install.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.misc-tests/linkage.exp trunk/gnattools/ChangeLog trunk/gnattools/configure trunk/gnattools/configure.ac trunk/libcpp/ChangeLog trunk/libcpp/configure trunk/libcpp/configure.ac trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libgo/config/libtool.m4 trunk/libgo/configure trunk/libjava/ChangeLog trunk/libjava/configure.host
Fixed for 4.7.0.
*** Bug 39186 has been marked as a duplicate of this bug. ***