Re: Parma Polyhedra Library 0.11.1
> > We announce the availability of PPL 0.11.1, a new release of the Parma > Polyhedra Library. This release includes several important bug fixes > and performance improvements. I was awaiting this. I will now try this on Solaris. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
[Fwd: GCC 4.6.0 Released]
Seems to be working well on Solaris 8 Sparc thus far. No surprises. I'll
post a result set once the tests are complete but for now I see the output
from hello.c is exactly as expected :
# pwd
/tmp/test
# cat -n hello.c
1 #include
2
3 int
4 main(int argc, char *argv[])
5 {
6 printf ( "Hello World!\n" );
7 return (0);
8 }
# gcc --version
gcc (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# gcc -mcpu=v8 -mno-app-regs -mno-vis -m32 -S -o hello.s hello.c
# cat hello.s
.file "hello.c"
.section".rodata"
.align 8
.LLC0:
.asciz "Hello World!"
.section".text"
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -96, %sp
st %i0, [%fp+68]
st %i1, [%fp+72]
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %o0
callputs, 0
nop
mov 0, %g1
mov %g1, %i0
restore
jmp %o7+8
nop
.size main, .-main
.ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
This is precisely the same as the output from 4.5.2 :
# diff /export/medusa/dclarke/build/test/hello_gcc_sparcv7.s hello.s
25c25
< .ident "GCC: (Blastwave.org Inc. Thu Dec 16 18:30:45 GMT 2010)
4.5.2"
---
> .ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
Thus all is well.
GCC is the ultimate open source project in my opinion in that it gives
birth to everything else. Well, that makes binutils the pen-ultimate I
guess. :-)
Thank you to the massive collection of Red Hat guys and volunteers and
to a massive colleection of truely gifted programmers and the FSF for
making GCC possible.
--
Dennis Clarke
dcla...@opensolaris.ca <- related to the open source Solaris
dcla...@blastwave.org <- related to open source for Solaris
pub 1024D/FA35B44B 2008-08-17
fingerprint = B766 3250 1511 40C8 088A 12B9 1D93 6C72 FA35 B44B
--
/~\ The ASCII Ribbon Campaign
\ /No HTML/RTF in email
X No Word docs in email
/ \ Respect for open standards
Thought du jour
---
In fact, my main conclusion after spending ten
years of my life working on the TeX project is
that software is hard. It.s harder than anything
else I.ve ever had to do. Donald E. Knuth, 5 Oct 2001,
Professor Emeritus of The Art of Computer Programming
at the Technische Universitat M�chen in a lecture
entitled "All Questions Answered".
123456789+123456789+123456789+123456789+123456789+123456789+1234
MESSAGE ENDS --
Original Message
Subject: GCC 4.6.0 Released
From:"Jakub Jelinek"
Date:Mon, March 28, 2011 03:25
To: gcc-annou...@gcc.gnu.org
Cc: gcc@gcc.gnu.org
--
The GNU Compiler Collection version 4.6.0 has been released.
GCC 4.6.0 is a major release, containing substantial new functionality
not available in GCC 4.5.x or previous GCC releases.
The "link-time optimization" framework introduced in GCC 4.5.0 has been
significantly improved in this release, it is now possible to compile
very large applications like Mozilla or GCC itself with LTO.
GCC can now partially inline functions, inlining just hot short path
to exit and keeping the rest of the function out of line.
Support for the upcoming C++0x standard has been notably improved,
Fortran 2003 and 2008 has been greatly extended and many other frontends
undergone substantial changes as well.
Many other improvements have been added and more than thousand of bugs
have been fixed in various parts of the compiler collection.
See:
http://gcc.gnu.org/gcc-4.6/changes.html
for more information about changes in GCC 4.6.0.
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in gcc/gcc-4.6.0/ subdirectory.
If you encounter difficulties using GCC 4.6, please do not contact me
directly. Instead, please visit http://gcc.gnu.org for information
about getting help.
As always, a vast number of people contributed to this GCC releases --
far too many to thank individually!
Re: GCC 4.6.0 Released
> On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote: >> Ryan Hill writes: >> >> > Does anyone know since when (if) running make check with more than one >> job >> > has been supported? IIRC back in the 3.x days it caused issues so >> we've >> > been forcing -j1 here forever. If we could run it in parallel that >> would be a >> > big timesaver. >> >> Jakub fixed it back in 2008 for gcc 4.4. It is indeed a big timesaver. > > Fixed just in the sense that the testing is more parallelized. > I've been using make -jN -k check for more than a decade and I don't > remember problems with that, mudflap tests are flaky and tend to fail > more often under load, but mudflap has only been added in 4.0. > Of course the N keeps changing over time, but currently testing certainly > works with -j48 that I'm using daily. > > Jakub Do you know if anyone has ever tested that on Solaris ? Lately Solaris is where open source goes to die ( blame Larry for that ) so I figure I may as well give it a shot, but before I do .. tell me know if this little trick works at all. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >> Do you know if anyone has ever tested that on Solaris ? Lately Solaris >> is >> where open source goes to die ( blame Larry for that ) so I figure I may >> as well give it a shot, but before I do .. tell me know if this little >> trick works at all. > > Why shouldn't it? No idea, and in the absence of data, I just am not sure yet. > I'm using it all the way from Solaris 8 to 11, with N > from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket > NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120. > awesome ... I am running it right now with N=2 and I have to assume that it will do the *exact* same results for my testsuite results. I already posted this : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02960.html So right now the very same machine, with no changes at all, is runnung with N=2. Thus far it looks to be quite busy : mpstat 5 says . . . CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 4552 1 151 623 235 399 100 80 820 4185 50 46 4 0 1 4538 1 225 286 49 360 106 76 810 3200 59 38 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3836 1 213 582 282 316 93 62 620 3375 62 34 3 0 1 4463 0 142 378 81 348 108 57 640 3655 62 36 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3180 1 141 521 220 286 81 56 440 3363 65 32 2 1 1 2895 0 150 258 38 298 93 59 490 2791 67 30 2 0 . . . > The only caveat are strange errors with gmake: > > make[3]: write error > > See CR 6938116GNU make highly unreliable: `write error' message. > > I've hacked around this by ignoring the error in misc.c (close_stdout) ;-) > It seems odd that gmake would pass every test in its own testsuite and then get an odd little message like that. Oh well, if you feel it can be ignored then I'm so very happy to see this. By the way, I just want to say thank you for posting results on Solaris because I review them and use them for comparison all the time. I am still fascinated that GCC can post different results on two servers running the same OS and probably with the same revs of tools avail. Consider this on Sol 8 i386 : === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html === gcc Summary === # of expected passes74529 # of unexpected failures1 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1031 /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) I decided to toss caution to the wind and run my build with as and ld in /usr/ccs/bin and I was happy to see a decent result set. I often wonder if we *need* GNU as or just *want* GNU as in an older Solaris release like 8. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >>> The only caveat are strange errors with gmake: >>> >>> make[3]: write error >>> >>> See CR 6938116 GNU make highly unreliable: `write error' message. >>> >>> I've hacked around this by ignoring the error in misc.c (close_stdout) >>> ;-) >>> >> >> It seems odd that gmake would pass every test in its own testsuite and >> then get an odd little message like that. Oh well, if you feel it can be > > It only happens once in a while, and primarily for Solaris 11 NFS > servers. Even more rarely, it occurs on Solaris 11 locally. I generally build my prod things on Solaris 8 with the assumption that the Solaris ABI stability will provide what I need up to Solaris 9. Then I rebuild again on Solaris 10 for AMD64/x86_64 functionality. This has worked well thus far. I avoid Solaris 11 Express entirely as I just don't see it as a valid release yet. If the OpenSolaris project was still alive and the bug process was open then I'd may feel differently but with thing being as they are ... I avoid Sol 11 for now. > >> ignored then I'm so very happy to see this. > > I think it is harmless enough to be ignored in this particular case, but > this deviation from pre-S11 behaviour is bad. Suddenly expecting every > single piece of software to handle EINTR all over the place when you > didn't need to before and don't need it on any other platform isn't > exactly a winning proposition to me ;-( I'll try to pursue this with > Solaris engineering. How is that going ? I have filed bugs in the past regarding Studio 11 Update 1 and was not exactly thrilled with the response. However .. dropping an email to Daryl Gove can generally get things moving. >> By the way, I just want to say thank you for posting results on Solaris >> because I review them and use them for comparison all the time. I am >> still >> fascinated that GCC can post different results on two servers running >> the >> same OS and probably with the same revs of tools avail. >> >> Consider this on Sol 8 i386 : >> >> === gcc Summary === >> >> # of expected passes72652 >> # of unexpected failures18 >> # of expected failures 212 >> # of unresolved testcases 1 >> # of unsupported tests 1874 >> /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 >> (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) >> >> This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html >> >> === gcc Summary === >> >> # of expected passes 74529 >> # of unexpected failures 1 >> # of expected failures 212 >> # of unresolved testcases1 >> # of unsupported tests 1031 >> /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) > > One would have to compare gcc.sum in detail to know what's going on. > Well my testsuite run with N=2 finished and the results look like : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03106.html === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) Exact same as before ! This is a very good sign. OKay .. so my days of running gmake -k check as a single thread are over. Thank you very much! >> I decided to toss caution to the wind and run my build with as and ld in >> /usr/ccs/bin and I was happy to see a decent result set. I often wonder >> if >> we *need* GNU as or just *want* GNU as in an older Solaris release like >> 8. > > IMO you want gas on Solaris/x86 before 10 because as lacks several > features there (like visibility support). On Solaris 10/x86 and up, as > is mostly fine (primarily COMDAT group support is missing, but I'm > working on that with the assembler and linker engineers as we speak). > Unfortunately, a recent as patch broke several -gstabs tests, but this > is expected to be fixed soon. > > On Solaris/SPARC I usually do the production builds with as; there seems > little reason to go for gas instead. > > Hope this helps. Very much so, thank you. I'll go back and rebuild on x86 with gas and leave my Sparc build as is. I generally do a double bootstrap merely to see what happens when GCC 4.6.0 is built with GCC 4.6.0 after it has already been bootstrapped. If I see any significant changes in the testsuite results then I assume something funky is afoot. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: I've successfully build 4.5.3 on Solaris x86
> uname -a : > SunOS devsolx86 5.10 Generic_139556-08 i86pc i386 i86pc Solaris > > config.guess output: > i386-pc-solaris2.10 > > gcc -v output: > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/usr_local/gcc4/bin/../libexec/gcc/i386-pc-solaris2.10/4.5.3/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: ../configure --with-gnu-as --with-as=/usr/sfw/bin/gas > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared > --enable-languages=c,c++ --with-gmp=/usr/local --with-mpfr=/usr/local > --prefix=/usr/local/gcc4 > Thread model: posix > gcc version 4.5.3 (GCC) > > Only enabled C/C++ > > Had to install mpc-0.8.1 (newer one didn't compile). Â used gmp-5.0.2, > mpfr-3.0.1 > see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00795.html New mpc compiles fine on Solaris 8 and 10 on Sparc v7, v8, v9 and on i386 and AMD64. I have not bothered with Intel i7 as I don't see it as any different from an x86_64 build on AMD Opterons. At least, the result is the same. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
gcc-4.6.2-RC-20111019 build problem in stage 2
uot;/usr/include/stdio.h" 3 4
typedef __longlong_t fpos64_t;
# 137 "/usr/include/stdio.h" 3 4
extern unsigned char _sibuf[], _sobuf[];
# 179 "/usr/include/stdio.h" 3 4
extern unsigned char *_bufendtab[];
extern FILE *_lastbuf;
# 215 "/usr/include/stdio.h" 3 4
extern void setbuffer(FILE *, char *, size_t);
extern int setlinebuf(FILE *);
extern int snprintf(char *, size_t, const char *, ...);
extern int vsnprintf(char *, size_t, const char *, __va_list);
# 236 "/usr/include/stdio.h" 3 4
extern FILE *fdopen(int, const char *);
extern char *ctermid(char *);
extern int fileno(FILE *);
# 262 "/usr/include/stdio.h" 3 4
extern FILE *popen(const char *, const char *);
extern char *cuserid(char *);
extern char *tempnam(const char *, const char *);
extern int getopt(int, char *const *, const char *);
extern int getsubopt(char **, char *const *, char **);
extern char *optarg;
extern int optind, opterr, optopt;
extern int getw(FILE *);
extern int putw(int, FILE *);
extern int pclose(FILE *);
extern int fseeko(FILE *, off_t, int);
extern off_t ftello(FILE *);
# 291 "/usr/include/stdio.h" 3 4
extern FILE *fopen64(const char *, const char *);
extern FILE *freopen64(const char *, const char *, FILE *);
extern FILE *tmpfile64(void);
extern int fgetpos64(FILE *, fpos64_t *);
extern int fsetpos64(FILE *, const fpos64_t *);
extern int fseeko64(FILE *, off64_t, int);
extern off64_t ftello64(FILE *);
# 2 "/export/medusa/dclarke/build/test/hello.c" 2
int
main(int argc, char *argv[])
{
printf ( "Hello World!\n" );
return (0);
}
Execution times (seconds)
TOTAL : 0.02 0.00 0.07
103 kB
#
#
looks good to me.
Somewhere in the Makefile the -liconv is absent and the breaks the build.
Let me vi Makefile and modify this :
# Libs and linker options needed for plugin support
PLUGINLIBS = -ldl
to this :
# Libs and linker options needed for plugin support
PLUGINLIBS = -ldl -liconv
Then run gmake again and see what I get.
# rm cc1
# cd ..
# pwd
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build
#
# ptime gmake
A few minutes later I see
.
.
.
gmake[3]: Entering directory
`/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/gcc'
.
.
.
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/xgcc
-B/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/
-B/opt/bw/sparc-sun-solaris2.8/bin/ -B/opt/bw/sparc-sun-solaris2.8/bin/
-B/opt/bw/sparc-sun-solaris2.8/lib/ -isystem
/opt/bw/sparc-sun-solaris2.8/include -isystem
/opt/bw/sparc-sun-solaris2.8/sys-include -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o
c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o
c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
sol2-c.o \
cc1-checksum.o main.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/opt/bw/lib/sparcv8 -lmpc -lmpfr -lgmp -ldl -liconv -L../zlib -lz
/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/xgcc
-B/opt/bw/src/GCC/gcc-4.6.2-RC-20111019-build/./prev-gcc/
-B/opt/bw/sparc-sun-solaris2.8/bin/ -B/opt/bw/sparc-sun-solaris2.8/bin/
-B/opt/bw/sparc-sun-solaris2.8/lib/ -isystem
/opt/bw/sparc-sun-solaris2.8/include -isystem
/opt/bw/sparc-sun-solaris2.8/sys-include-c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6.2-RC-20111019/gcc
-I../../gcc-4.6.2-RC-20111019/gcc/.
-I../../gcc-4.6.2-RC-20111019/gcc/../include -I./../intl
-I../../gcc-4.6.2-RC-20111019/gcc/../libcpp/include -I/opt/bw/include
-I../../gcc-4.6.2-RC-20111019/gcc/../libdecnumber
-I../../gcc-4.6.2-RC-20111019/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.6.2-RC-20111019/gcc/gcov.c -o gcov.o
.
.
.
etc etc and life goes on.
Seems as if -liconv got dropped somewhere and that was what was needed.
Did I miss something here ?
Dennis clarke
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
# of unexpected failures 768 ?
I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am seeing a really large increase in the number of "unexpected failures" on various tests. With 4.6.1 and Solaris I was able to get reasonable results : http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html Then if I use the resultant compiler from a 4.6.1 build I get a massive increase in failures on both i386 and Sparc : http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html and thus far on Sparc I see : === gcc Summary === # of expected passes69236 # of unexpected failures768 # of expected failures 235 # of unresolved testcases 1 # of unsupported tests 1240 /opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/xgcc version 4.6.2 (Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011) and : === g++ Summary === # of expected passes26251 # of unexpected failures101 # of unexpected successes 1 # of expected failures 169 # of unresolved testcases 1 # of unsupported tests 496 /opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/testsuite/g++/../../g++ version 4.6.2 (Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011) This seems blatantly wrong. At what point does one throw out the result of a bootstrap as not-acceptable ? With any non-zero value for "unexpected failures" ? Also, I see bucket loads of these : FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error) What should I think about an "internal compiler error" ? Dennis ( concerned in Solaris world ) -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> On 31 October 2011 15:33, Rainer Orth wrote: >> As an asside, I'd suggest to considerably reduce your set of configure >> options: many of them are the default (like --without-gnu-ld >> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix, >> --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8 >> --build=i386-pc-solaris2.8) or unnecessary >> (--enable-stage1-languages=c). > > Yes, adding completely redundant options looks like cargo cult > programming and just confuses anyone using the compiler who tries to > work out how it was configured. > >> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it >> might be better to keep the default of pentiumpro instead. > > Solaris 8 won't run on anything less than pentium, I recently > convinced someone else to stop building GCC for i386 on Solaris: > > http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html The Os is on Vintage support until March 2012. Also, I never had problems with it before. As for "completely redundant options" I have been building gcc like this for a while. also never a problem before. This is a case of "magic configure incantation" required ? I certainly hope not. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> These `I've used them for ever' options tend to do more harm than good, > and confuse other users that check how your copy of gcc was built. This > is especially bad for distributors like yourself, since the number of > confused people is far larger than for some company-internal build ;-) > > Rainer * nod * Will redo ... and see what I get. Thanks for the input. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-----------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> > Actually, it is uname showing the 'i386' on Solaris: > $ uname -p # Prints the current host's ISA or processor type. > i386 > $ uname -i # Prints the name of the platform. > i86pc > > So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any > difference here. > > Just my 2 cents. no prob. Actually on Solaris you will always get 'i386' even if you are running on a top of the line AMD Opteron 16-core machine with 8 sockets. It still reports that it is a i386 and not x86_64 or even amd64. Now isainfo and isalist are a whole other matter. Personally I'd like to see conffigure take advantage of that data as it is much more rich. On sparc you get this sort of data : # isalist -a sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc # isainfo -v 64-bit sparcv9 applications 32-bit sparc applications On some old pentium box you get this : Sun Microsystems Inc. SunOS 5.8 Generic February 2000 $ $ isalist -a pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 $ isainfo -v 32-bit i386 applications $ Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
>> It's redundant if you *want* to build for that host, but the whole >> point is that building for i386 is usually a very bad idea, so >> --host=i586-pc-solaris2.8 would be better. > > Erm - what I want to say is that I would really wonder if it does have > /any/ > influence (binary-wise) to gcc on Solaris (unlike Linux) whether to > configure > for i386 or i586 (via '--host' or even '--target'). > Oh, well, that would be a worthwhile experiment I think. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +---------+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Ian Lance Taylor writes: > >> Michael Haubenwallner writes: >> >>> But still: given that x86-solaris started with some Pentium, I just >>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now. >>> >>> Especially as i386 (from config.guess) is the default too. >> >> I'm not sure why you don't believe it. It is what I would expect. >> >> If we want to make this work more normally for ordinary users, I think >> the right thing to do would be to patch config.guess to compute a better >> value for the build system CPU on Solaris systems. > > Please no: alpha went this route, and the consequence is that your > self-built gcc will generate code for the build system. This breaks > completely if you have a heterogeneous collection of systems, and the > GCC build system isn't the least common denominator of them. This > single-system mindset creates unnecessary trouble in this scenario. > GCC's configure has enough control over the default target CPU, even > without messing with config.guess, and most other programs won't care > about this at all. > > Personally I am all for "it ain't broke, don't fix it". Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Rainer Orth writes: > >> Ian Lance Taylor writes: >> >>> Michael Haubenwallner writes: >>> >>>> But still: given that x86-solaris started with some Pentium, I just >>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now. >>>> >>>> Especially as i386 (from config.guess) is the default too. >>> >>> I'm not sure why you don't believe it. It is what I would expect. >>> >>> If we want to make this work more normally for ordinary users, I think >>> the right thing to do would be to patch config.guess to compute a >>> better >>> value for the build system CPU on Solaris systems. >> >> Please no: alpha went this route, and the consequence is that your >> self-built gcc will generate code for the build system. This breaks >> completely if you have a heterogeneous collection of systems, and the >> GCC build system isn't the least common denominator of them. This >> single-system mindset creates unnecessary trouble in this scenario. >> GCC's configure has enough control over the default target CPU, even >> without messing with config.guess, and most other programs won't care >> about this at all. > > Oh, I completely agree that it would be wrong to have config.guess > produce the exact CPU used on the build system. > > But having config.guess produce "i386" for an OS which does not even run > on a vanilla i386 is also wrong. A much better choice here would be the > earliest CPU value which the OS actually supports. $ isalist -v pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 I would suggest pentium_pro if one can still find one running out there. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
# of unexpected failures 790
Well at this point I am getting results like this : === gcc Summary === # of expected passes74735 # of unexpected failures790 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1039 /opt/bw/src/GCC/gcc-4.6.2_SunOS5.8_i386/gcc/xgcc version 4.6.2 (Blastwave.org Inc. Sat Oct 29 20:12:45 GMT 2011) I am going to scrap the entire stack, start over from scratch with nothing but XPG4 tools ( ls, cp etc ) and a compiler such as Sun Studio 11. I can not recall ever trying to build gcc with Sun Studio but it is probably impossible. I'll give it a go anyways. This can't get worse. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
presence... yes checking for malloc.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking for feof_unlocked... no checking for fgets_unlocked... no checking for getc_unlocked... yes checking for getcwd... yes checking for getegid... yes checking for geteuid... yes checking for getgid... yes checking for getuid... yes checking for mempcpy... no checking for munmap... yes checking for putenv... yes checking for setenv... no checking for setlocale... yes checking for stpcpy... no checking for strcasecmp... yes checking for strdup... yes checking for strtoul... yes checking for tsearch... yes checking for __argz_count... no checking for __argz_stringify... no checking for __argz_next... no checking for __fsetlocking... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... install-shextern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes checking for bison... bison checking version of bison... 2.4.3, ok checking whether NLS is requested... yes checking whether included gettext is requested... no checking for GNU gettext in libc... no checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader configure: updating cache ./config.cache configure: creating ./config.status /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: ./conf4075subs.sh: file is too large configure: error: could not make ./config.status gmake[2]: *** [configure-stage1-intl] Error 1 gmake[2]: Leaving directory `/opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2_SunOS5.8_i386' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2_SunOS5.8_i386' gmake: *** [all] Error 2 real 49.639 user1.259 sys 0.381 titan$ I can not figure out why I would be seeing a error like that. baffled on Solaris , Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am >> seeing a really large increase in the number of "unexpected failures" on >> various tests. >> >> With 4.6.1 and Solaris I was able to get reasonable results : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html >> >> Then if I use the resultant compiler from a 4.6.1 build I get a massive >> increase in failures on both i386 and Sparc : >> >> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html > > FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden > > All the scan-not-hidden failures are usually an indication that objdump > isn't in your PATH. Right, thank you. On i386 I rectified that situation with binutils however on Sparc this was not an issue. See results : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html Only the new "go" language seems to be a major issue now. >> This seems blatantly wrong. At what point does one throw out the result >> of >> a bootstrap as not-acceptable ? With any non-zero value for "unexpected >> failures" ? > > There's no such number, only comparisons to other testsuite results. In > many cases (e.g. in the scan-not-hidden failures above), there's nothing > wrong with the compiler, just with the test environment. And in your > case, only two problems account for the vast majority of the failures. > >> Also, I see bucket loads of these : >> >> FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error) >> >> What should I think about an "internal compiler error" ? > > This seems fundamentally broken on your machine. With the exception of > the largefile.c testcases, those pass everywhere else, so you'd have to > debug what's going on there. Any "internal compiler error" mean throw the whole thing out and start over. At least that is the only safe course of action in my mind. > FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler > error) > [...] > FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess > errors) > WARNING: program timed out. > > Those test cases have excessive stack space or runtime requirements and > are known to fail on slow machines or those with default resource > limits. Those are known testcase bugs, but nobody cared about this so > far ;-( I'm so happy to hit those special cases :-) > Overall, your results don't look bad to me, once you've installed > objdump and investigated the PCH failures. yep ... I have been digging. On Sparc things are going much better but on i386 I have tossed the whole scenario out and am starting over from first principles. Build everything from scratch with the Sun Studio compiler until I hit things that need gcc. Like libgmp etc. > As an asside, I'd suggest to considerably reduce your set of configure > options: many of them are the default (like --without-gnu-ld > --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix, > --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8 > --build=i386-pc-solaris2.8) or unnecessary > (--enable-stage1-languages=c). > > I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it > might be better to keep the default of pentiumpro instead. Yep, did that. Thank you. However on i386 things got worse, not better. I have to toss that out and start over. On Sparc things are much better with the exception of "go". Thank you for the input. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> This should probably be on the gcc-help list. I never really know which direction to go as the issues seem to be related to how limits-exprparen.c gets tested. However, no problem, I'll jump ship and get out of this ml. > On 7 November 2011 01:08, Dennis Clarke wrote: >> >> Well, dear GCC users I am now seeing behavior that falls in the arean of >> the bizarre. No sense in talking much about it but here is the error >> message : >> >> /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: >> ./conf4075subs.sh: file is too large >> configure: error: could not make ./config.status > > Have you checked your ulimit? I was thinking that too! I just recently increased the stack size limit to 16 MB : $ ulimit -a time(seconds)unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes)16384 coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited I am sure "unlimited" will work fine :-\ > And of course disk space? yep, got lots. Thanks for the input. I'll keep working on this until I get a clean bootstrap and if that takes a month, then fine. The results are always worth it and somewhat critical to have a compiler I trust. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> Only the new "go" language seems to be a major issue now. > > The implementation of Go in the 4.6 releases does not support Solaris. > > Go on Solaris works on mainline. Well, I would not have seen that coming. I should look more closely at the various README's and changelogs. To be honest, I scrapped my Solaris Sparc resultant compiler here : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html ... and am starting over. With no go, and no pun inteneded. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> Message from Dennis Clarke at 2011-11-07 > 06:38:47 -- >> > Have you checked your ulimit? >> >>I was thinking that too! I just recently increased the stack size limit >> to >>16 MB : > > The 'fix' in mainline set it higher: > > 2011-07-22 Jakub Jelinek > > PR c++/49756 > * gcc.c (main): Call stack_limit_increase (64MB). > * toplev.c (toplev_main): Likewise. Well things seem to be working well on sparc and still very poorly on x86 so I am scrapping my whole stack on x86. Starting over one step at a time and carefully looking into testsuite results on every piece as I climb up the requirements. As for sparc, I expect to post good results, minus "go", in about 72 hours. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: bootstrap regression on sparc
> > While building libstdc++ I get an assertion failure in haifa-sched.c, > specifically the assertion on line 3437 is failing: I am seeing no major problems on Sparc at all. What rev of GCC are you referring to please? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
> The Go language is closing in what we are calling Go version 1. This > will be a long-term stable release of Go, with no language or library > API changes. Go 1 is described here: > > https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE per that doc : The Go 1 release will be available in source and binary form for at least these platforms: FreeBSD 7+: amd64, 386 Linux 2.6+: amd64, 386, arm OS X (Snow Leopard + Lion): amd64, 386 Windows (2000 + later): amd64, 386 Therefore not on Solaris 10 or even a baseline Solaris 8 at all. That seems to be an issue given this : People should be able to write Go programs and expect that they will continue to compile and run without change, on a timescale of years. In keeping with the spirit of that vision what are the issues that block a port to Solaris today? Are there specific bugids I can look at ? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
Re "go" for Solaris I see this : http://code.google.com/p/gofrontend/issues/detail?id=6 Not sure what the status in the mainline is but I am willing to do a checkout and build and see what goes wrong. I have 4.6.2 well done on Sparc Solaris 8 and that seems like a good place to start. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
4.7 RC ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any expected date on a 4.7 RC ? - -- - -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) iEYEARECAAYFAk8O6ugACgkQHZNscvo1tEuVHACfU3BP6IvjF6ifEqH9VM/emDfH EDMAn1dOUcNOelZU+z9Z81IWrQLE8foV =tWIW -END PGP SIGNATURE-
Re: 4.7 RC ?
>> Any expected date on a 4.7 RC ? > > When it's ready. Which we'd usually expect it to be around the > beginning of April. cool. thank you. -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
> Joel Sherrill writes:
>
>> On 01/12/2012 12:16 PM, Andreas Schwab wrote:
>>> Ian Lance Taylor writes:
>>>
>>>> The functions required are makecontext, getcontext, and setcontext.
>>> Note that these functions are obsolescent in POSIX.1-2004 and removed
>>> from POSIX.1-2008.
>> Are there any alternatives? It is bad that Go is already starting
>> out dependent on obsolete methods. :(
>
> I would be glad to use alternatives but I'm not aware of any.
>
> The getcontext and setcontext functions are easy. The harder one is
> makecontext. POSIX appears to be assuming that any use of makecontext
> can be replaced with pthread_create, but if you care about efficiency
> that simply isn't true.
>
> Ian
>
Stuff from the opensolaris project isn't going to help here is it ?
void
makecontext(ucontext_t *ucp, void (*func)(), int argc, ...)
{
greg_t *reg;
long *tsp;
char *sp;
int argno;
va_list ap;
size_t size;
reg = ucp->uc_mcontext.gregs;
reg[REG_PC] = (greg_t)func;
reg[REG_nPC] = reg[REG_PC] + 0x4;
/*
* Reserve enough space for a frame and the arguments beyond the
* sixth; round to stack alignment.
*/
size = sizeof (struct frame);
size += (argc > 6 ? argc - 6 : 0) * sizeof (long);
/*
* The legacy implemenation of makecontext() on sparc has been to
* interpret the uc_stack.ss_sp member incorrectly as the top of the
* stack rather than the base. We preserve this behavior here, but
* provide the correct semantics in __makecontext_v2().
*/
sp = (char *)(((uintptr_t)ucp->uc_stack.ss_sp - size) &
~(STACK_ALIGN - 1));
/*
* Copy all args to the stack, and put the first 6 args into the
* ucontext_t. Zero the other fields of the frame.
*/
/* LINTED pointer cast may result in improper alignment */
tsp = &((struct frame *)sp)->fr_argd[0];
bzero(sp, sizeof (struct frame));
va_start(ap, argc);
for (argno = 0; argno < argc; argno++) {
if (argno < 6)
*tsp++ = reg[REG_O0 + argno] = va_arg(ap, long);
else
*tsp++ = va_arg(ap, long);
}
va_end(ap);
reg[REG_SP] = (greg_t)sp - STACK_BIAS; /* sp (when done) */
reg[REG_O7] = (greg_t)resumecontext - 8;/* return pc */
}
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Go in gcc 4.7
> Dennis Clarke writes:
>
>> for (argno = 0; argno < argc; argno++) {
>> if (argno < 6)
>> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long);
>> else
>> *tsp++ = va_arg(ap, long);
>
> This is broken. The arguments are of type int, not long.
To be more compliant with IEEE Std 1003.1-2001 ( ISO/IEC 9899:1999
standard, Section 6.2.5 ) they should be int32_t or similar as
per stdint.h.
But hey, I was just thinking out loud and more concerned about a
functional go compiler in gcc 4.7 RC. I am currently digging around
in snapshots 4.7-20120107.
Dennis
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-----+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Memory corruption due to word sharing
> I have actually tried exactly this earlier today (because while looking at
> this, I had an idea that putting volatile in place could be a workaround,
> causing gcc to generate a saner code), but it doesn't work either:
>
> # cat x.c
> struct x {
> long a;
> volatile unsigned int lock;
> unsigned int full:1;
> };
>
> void
> wrong(struct x *ptr)
> {
> ptr->full = 1;
> }
>
> int main()
> {
> wrong(0);
> }
> In my opinion, this is a clear bug in gcc (while the original problem,
> without explitict volatile, is not a C spec violation per se, it's just
> very inconvenient :) ).
As a data point, the exact same code on a Solaris 8 pentium III box:
$ gcc -S -o x.s x.c
$ cat x.s
.file "x.c"
.text
.globl wrong
.type wrong, @function
wrong:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movzbl 8(%eax), %edx
orl $1, %edx
movb%dl, 8(%eax)
popl%ebp
ret
.size wrong, .-wrong
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$4, %esp
movl$0, (%esp)
callwrong
leave
ret
.size main, .-main
.ident "GCC: (Blastwave.org Inc. Thu Dec 16 18:05:01 GMT 2010) 4.5.2"
$ gcc -o x x.c
$ file x
x: ELF 32-bit LSB executable 80386 Version 1, dynamically linked,
not stripped
$ ldd x
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
$ ./x
Segmentation Fault(coredump)
$ ls -l core
-rw--- 1 dclarke csw71384 Feb 1 17:26 core
71384 bytes core is complete thus :
$ elfdump -p core | tail -6
Program Header[12]:
p_vaddr: 0xdfbf3000 p_flags:[ PF_X PF_W PF_R ]
p_paddr: 0 p_type: [ PT_LOAD ]
p_filesz: 0x1000 p_memsz:0x1000
p_offset: 0x106d8 p_align:0
$ /opt/studio/SOS11/SUNWspro/bin/dbx -c "print 0x1000 + 0x106d8; quit"
dbx: warning: unknown language, 'c' assumed
0x1000+0x106d8 = 71384
what caused the seg fault ?
$ /opt/studio/SOS11/SUNWspro/bin/dbx x core
Reading x
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x08050672: wrong+0x0006: movzbl 0x0008(%eax),%edx
(dbx) where
=>[1] wrong(0x0, 0x8047b70, 0x805057d, 0x1, 0x8047b7c, 0x8047b84), at 0x8050672
[2] main(0x1, 0x8047b7c, 0x8047b84), at 0x8050690
However Sun Studio 5.8 does no better :
$ /opt/studio/SOS11/SUNWspro/bin/cc -Xc -o x_Sun_Studio_5.8 x.c
$ ./x_Sun_Studio_5.8
Segmentation Fault(coredump)
$ ls -l core
-rw--- 1 dclarke csw71384 Feb 1 17:48 core
$ /opt/studio/SOS11/SUNWspro/bin/dbx x_Sun_Studio_5.8 core
dbx: warning: core object name "x_Sun_Studio_5." matches
object name "x_Sun_Studio_5.8" within the limit of 14. assuming they match
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x080506ae: wrong+0x000e: movl 0x0008(%ecx),%eax
(dbx) where
=>[1] wrong(0x0), at 0x80506ae
[2] main(0x1, 0x8047b4c, 0x8047b54), at 0x80506ca
(dbx) quit
$ /opt/studio/SOS11/SUNWspro/bin/cc -V
cc: Sun C 5.8 Patch 121016-08 2009/04/20
usage: cc [ options] files. Use 'cc -flags' for details
$
dc
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
> Eric Botcazou writes: > >> > I was looking through the gcc-4.5 primary and secondary platform list >> > to ensure we have coverage for MPC testing. It occurs to me that some >> > of the OS versions are outdated. >> > >> > I've included the list from the page >> > http://gcc.gnu.org/gcc-4.5/criteria.html >> > >> > Should we update: >> > >> > 1. solaris2.10 -> 2.11 >> >> Why move to a not-yet-released version? > > Indeed: while I regularly test on Solaris 11/SPARC at the moment, it's > still so much of a moving target that this doesn't make any sense. The issue may be one of "de facto" vs "defined as being" released. There is no such thing as a released Solaris revision that responds to uname with SunOS5.11 yet. When Sun/Oracle actually releases something AND you can buy a support contract for it then you have a valid platform in commercial use. Having said that .. I see roughly 30% of all my traffic from SunOS5.11 users on either Solaris Nevada or OpenSolaris beta releases. The question should be ... do we in the community end user world see SunOS5.11 as being a de facto release? I would say yes. Solaris 10 is the enterprise class commercial grade Solaris release and it is staying put for a long long long time yet. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
>> you can buy a support contract for it then you have a valid platform in >> commercial use. > > You can get support for the OpenSolaris distribution if you like I just went and looked ... you are correct, they have three levels in fact. It looks like $1080 for premium, $720 is standard business hours $324 is patches and updates with email tech support I think. So that makes it a real commercial platform in my mind. > is still very much work in progress, not a stable platform we can rely on. However, Solaris 10 was also a moving platoform in its first few releases but no one would debate it as a commercial grade release or not. I think Opensolaris must be looked at as viable and commercial grade. I am not at all biased in this regardless of the fact that I have been involved one way or another in the OpenSolaris project since day one. I'm very much an outside guy that just loves to experiment and perhaps even attempt to help where I can. >> Having said that .. I see roughly 30% of all my traffic from SunOS5.11 >> users on either Solaris Nevada or OpenSolaris beta releases. >> >> The question should be ... do we in the community end user world see >> SunOS5.11 as being a de facto release? I would say yes. > > Certainly not, even if it is widely used (primarily on laptops, I > suppose). Well, would Fedora Core on PowerPC or Ubuntu or Debian ( any release ) be considered a platform or does that just fall under a wide umbrella of "Linux" ? Some of those are barely used at all anymore. Consider running Linux on a DEC Alpha. Who does that anymore? Is this a popularity measurement or is this based on something more tangible and quantitative like "commercially supported"? >> Solaris 10 is the enterprise class commercial grade Solaris release and >> it is staying put for a long long long time yet. > > Indeed, and even if we chose sparc-sun-solaris2.10 as the primary platform > doesn't mean that *-*-solaris2.11 doesn't work, quite the contrary: I > regularly test both and try to keep them working. I test everything on *-*-solaris2.8 which by way of the ABI golden rule instantly qualifies as tested on anything up to SunOS2.10. It does not imply SunOS2.11 however. -- Dennis
Re: WTF?
> On Wed, 25 Nov 2009, Dave Korn wrote: >> Joseph S. Myers wrote: >> > Doing it right at the end of branch-to-trunk merges for a release >> (which >> > is where we are right now, just after merges from Graphite) is >> probably >> > the optimal timing in terms of minimising the amount of branches that >> will >> > need fixing up. The problem is doing it without warning or consensus. >> >> Yep. Given that, maybe we should make a global whitespace cleanup an >> official part of the release branching process? It would be nice to >> keep it >> from all building up again, and we could avoid the pain if it was >> regular and >> predictable. > > What is the _point_ in doing this? Is there _any_ positive effect > of removing trailing whitespace? Does it looks like there are no bugs to > fix in gcc so that the pointless task of removing trailing whitespace > looks appealing?? Gentlemen, a point of order please. Many people read these lists and we place high regard on the quality of the GCC project as well as the people involved. A personal slight as well as an error may happen from time to time but this is simply the nature of working as a software engineer. Let us not degrade into a base argument with words traded and thus undermine the great name that GCC and open source has. I am sure that this issue can be resolved without any damage done to the most precious resource we have, good people that work together openly and with respect and dignity. Having said that, I firmly would defend any of you as truely awesome engineers and good people that work to benefit the state of mankind. -- Dennis Clarke http://www.blastwave.org/ dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
trivial trailing whitespace issue
May I make a subject line change please ? This issue is trivial trailing whitespace changes I think and procedures, process and notice of such changes. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris Original Message Subject: [ Three letter acronym deleted ] From:"Richard Guenther" Date:Wed, November 25, 2009 14:43 To: "Richard Kenner" Cc: m...@suse.de gcc@gcc.gnu.org hongjiu...@intel.com l...@redhat.com -- On Wed, 25 Nov 2009, Richard Guenther wrote: > On Wed, 25 Nov 2009, Richard Kenner wrote: > > > > In my mind it's very simple: trailing whitespace poses exactly _no_ > > > problem (except of being against the coding standard), > > > But different timing or a notice wouldn't fix one of my no longer > applying patches. If you can offer advice on how to teach quilt > (which I belive uses patch) to ignore whitespace changes when > applying patches then more power to you - the only tool that > seems to be able to ignore whitespace changes is diff. Btw, I'd be happy with a commit hook that forces you to fix whitespace in the area you patch (basically just make sure there is no trailing whitespace in ^[+ ] lines of a unified diff (maybe even only in ^+ lines to not cause continuous rejects if you fixup the ^ lines in your patch and drag in more context). Anyone willing to implement that? I still see no point in fixing up the existing source just for the sake of it. Richard.
Re: A bug?
c4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
$ cat foo.s
.file "foo.c"
.section".text"
.align 4
.global s
.type s, #function
.proc 010
s:
save%sp, -136, %sp
ld [%fp+64], %l0
mov 72, %g1
stb %g1, [%fp-36]
stb %g0, [%fp-35]
mov %l0, %g1
add %fp, -36, %g2
mov 20, %g3
mov %g1, %o0
mov %g2, %o1
mov %g3, %o2
callmemcpy, 0
nop
mov %l0, %i0
restore
jmp %o7+12
nop
.size s, .-s
.section".rodata"
.align 8
.LLC0:
.asciz "%s\n"
.section".text"
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -168, %sp
add %fp, -36, %g1
st %g1, [%sp+64]
calls, 0
nop
unimp 20
ld [%fp-36], %g1
st %g1, [%fp-64]
ld [%fp-32], %g1
st %g1, [%fp-60]
ld [%fp-28], %g1
st %g1, [%fp-56]
ld [%fp-24], %g1
st %g1, [%fp-52]
ld [%fp-20], %g1
st %g1, [%fp-48]
add %fp, -64, %g2
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %o0
mov %g2, %o1
callprintf, 0
nop
restore
jmp %o7+8
nop
.size main, .-main
.ident "GCC: (GNU) 4.3.2"
$
$
$ /opt/csw/gcc4/bin/gcc -o foo foo.s
$ ./foo
H
works right ?
Dennis Clarke
http://www.blastwave.org/
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
>
> On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.world[0]='H';
>> r.world[1]='\0';
>> return r;
>> }
>>
>> int main(){
>> printf("%s\n",s().world);
>> }
>>
>> Assigning s() to a variable and then using the variable avoids the
>> segfault.
>
> Had you compiled with -Wall would you have noticed:
>
> e.c:13: warning: format â%sâ expects type âchar *â, but
> argument 2 has type âchar[20]â
>
> And when there is a type mismatch, a crash is pretty likely.
> Not that I can say why gcc does not convert it to char* but g++ does.
>
> Now what happens? The following augmented snippet shows it:
> ---<8---
> #include
> #include
> #include
> struct Hello {
>char world[20];
> };
> struct Hello s(void)
> {
> struct Hello r;
> strcpy(r.world, "Hello");
> return r;
> }
> static void dump(const char *fmt, ...)
> {
> va_list argp;
> va_start(argp, fmt);
> char *p = va_arg(argp, char *);
> printf("%p\n", p);
> va_end(argp);
> }
> int main(void)
> {
> dump("", s().world);
> return 0;
> }
> --->8---
>
> I get 0x6c6c6548, which is obviously part of the string Hello. So
> passing a char[20] into a varargs function seems not to convert it to
> char* when done through a non-visibile temporary (the result of s()
> is hidden on the stack of main).
On a baseline test machine ( Solaris 8 sun4m ) I get this with GCC 4.3.2 :
$ gcc -o foo2_gcc foo2.c
foo2.c: In function 'dump':
foo2.c:16: error: '__builtin_va_alist' undeclared (first use in this
function)
foo2.c:16: error: (Each undeclared identifier is reported only once
foo2.c:16: error: for each function it appears in.)
If I use very very old Sun Studio 8 I get this :
$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.5 Patch 112760-19 2007/08/02
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/SUNWspro/bin/cc -o foo2 foo2.c
$ mcs -p foo2
foo2:
@(#)stdarg.h1.4599/08/10 SMI
@(#)stdarg_iso.h1.1 99/08/09 SMI
@(#)va_list.h 1.1299/05/04 SMI
@(#)stdio.h 1.7899/12/08 SMI
@(#)stdio_iso.h 1.2 99/10/25 SMI
@(#)feature_tests.h 1.1899/07/26 SMI
@(#)isa_defs.h 1.2099/05/04 SMI
@(#)stdio_tag.h 1.3 98/04/20 SMI
@(#)stdio_impl.h1.8 99/06/10 SMI
@(#)string.h1.2499/08/10 SMI
@(#)string_iso.h1.2 99/11/09 SMI
acomp: Sun C 5.5 Patch 112760-19 2007/08/02
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.302
$ ./foo2
ec50
With Sun Studio 12 on Solaris 10 ( AMD64 this time ) I get
$ uname -a
SunOS isis 5.10 Generic_137138-09 i86pc i386 i86pc
$ cat /etc/release
Solaris 10 5/08 s10x_u5wos_10 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
$ /opt/studio/SOS12/SUNWspro/bin/cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/studio/SOS12/SUNWspro/bin/cc -o foo2 foo2.c
$ ./foo2
8047d70
so .. pretty wildly different results.
Dennis
--
Dennis Clarke
gcc-4.3.3 bootstrap fails on old Sun Sparc
This is on an old Sun Sparc machine running Solaris 8. I had CFLAGS set thus : $ echo $CFLAGS -mcpu=v7 -m32 -mno-app-regs -pthreads I was using gcc version 4.2.4 to perform this bootstrap and I set the configure options for non-GNU as and ld thus : $ ../gcc-4.3.3/configure --with-as=/usr/ccs/bin/as \ > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 \ > --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local \ > --with-local-prefix=/export/home/dclarke/local --enable-shared \ > --enable-languages=c,c++,objc,fortran \ > --with-gmp=/export/home/dclarke/local \ > --with-mpfr=/export/home/dclarke/local \ > --enable-bootstrap Phase one of the boot strap results in this : $ /export/nfs/build/gnu/GCC/gcc-4.3.3-build/gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local --with-local-prefix=/export/home/dclarke/local --enable-shared --enable-languages=c,c++,objc,fortran --with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local --enable-bootstrap Thread model: posix gcc version 4.3.3 (GCC) Shortly into what looks like phase 2 I see the process fails thus : /export/nfs/build/gnu/GCC/gcc-4.3.3-build/./gcc/xgcc -B/export/nfs/build/gnu/GCC/gcc-4.3.3-build/./gcc/ -B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ -B/export/home/dclarke/local/sparc-sun-solaris2.8/lib/ -isystem /export/home/dclarke/local/sparc-sun-solaris2.8/include -isystem /export/home/dclarke/local/sparc-sun-solaris2.8/sys-include -g -fkeep-inline-functions -m64 -O2 -O2 -g -mcpu=v7 -m32 -mno-app-regs -pthreads -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I../../../../gcc-4.3.3/libgcc -I../../../../gcc-4.3.3/libgcc/. -I../../../../gcc-4.3.3/libgcc/../gcc -I../../../../gcc-4.3.3/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.3.3/libgcc/../gcc/libgcc2.c \ xgcc: may not use both -m32 and -m64 make[5]: *** [_muldi3.o] Error 1 make[5]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/sparcv9/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/libgcc' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build/sparc-sun-solaris2.8/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/export/nfs/build/gnu/GCC/gcc-4.3.3-build' make: *** [all] Error 2 I do not know why the option -m64 is in there. I certainly didn't ask for it. Any thoughts on this ? -- Dennis Clarke
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> On Tue, Jan 27, 2009 at 04:53:09PM -0800, Dennis Clarke wrote: >> >> This is on an old Sun Sparc machine running Solaris 8. >> >> I had CFLAGS set thus : >> >> $ echo $CFLAGS >> -mcpu=v7 -m32 -mno-app-regs -pthreads > > That's your problem. Try again without this setting. > >> Shortly into what looks like phase 2 I see the process fails thus : >> ... > >> xgcc: may not use both -m32 and -m64 > > It blew up when trying to build 64-bit code, when you'd set CFLAGS > to -m32. First ... thank you for the reply. I know that you do a great deal of work with GCC on Solaris and Sparc and I compare my testsuite data to your reports at every opportunity. That sort of makes your results my benchmark. Now, the issue is that I don't want 64-bit code. At all. Period. This is old 32-bit Sparc so I don't think 64-bit code will serve any purpose here. Am I wallowing in ignorance and missing something obvious? Please feel free to hit me with a brick if that is the case :-) Dennis
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> On Tue, Jan 27, 2009 at 05:24:36PM -0800, Dennis Clarke wrote: >> This is old 32-bit Sparc so I don't think 64-bit code will serve any >> purpose here. > > Specifying --disable-multilib at configure time should keep it from > building the 64-bit libraries. I'll give that a try thank you ! My objective here is to build a basic sparc compiler package first and then use that resultant compiler to build a full package. One of the things I have had no joy with is figuring out how to include the ada component but that is a battle for another day. Dennis
Re: gcc-4.3.3 bootstrap fails on old Sun Sparc
> Andreas Schwab writes: > >> Dennis Clarke writes: >> >> > One of the things I have had no joy with is figuring out how to >> > include the ada component but that is a battle for another day. >> >> To build ada you need a good ada compiler to start with. If you don't >> have one natively you need to build a cross compiler on a system that >> has one and then build the native ada compiler with this cross >> compiler. Then you can rebootstrap with ada enabled. > > Probably lots of hassle. If needed, I can provide bootstrap GNAT for both > Solaris/SPARC and x86, since I (sort of) regularly test on both platforms > with Ada included. > > Rainer Dear Sir : Would there be any way that I could invite you into the community build farm at Blastwave.org for this purpose ? I think it would be great if we could get a GCC package built ( with ada ) that passes a set of QC/QA steps and then release it to the Solaris world. Clearly I'll need a bit of help with the ada portion. All I would need is a public key from you and then you could ssh in through the gateway and into the server farm on any architecture or OS level that you want. This is something that Blastwave does for community open source people for years and it works rather well. Dennis
Re: GCC 4.3.3 Released
> On Sun, 2009-02-01 at 12:15 +0100, Richard Guenther wrote: >> The GNU Compiler Collection version 4.3.3 has been released. >> >> GCC 4.3.3 is a bug-fix release containing fixes for regressions and >> serious bugs in GCC 4.3.2. This release is available from the >> FTP servers listed at: >> >> http://www.gnu.org/order/ftp.html >> >> Please do not contact me directly regarding questions or comments about >> this release. Instead, use the resources available from >> http://gcc.gnu.org. >> >> As always, a vast number of people contributed to this GCC release -- >> far >> too many to thank individually! > > Unpatched release results on various architectures running linux from > the compile farm: > > x86_64=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00081.html > i686 => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00126.html > powerpc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00125.html > mipsel=> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00210.html > sparc => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00168.html > armv5tel => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00281.html > alpha => http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html > > I'll try sparc64, powerpc64 and ia64 when the machines are available. I can probably help you with the Sparc64 requirement. To be precise, do you need Sun UltraSparc or are you looking for the multicore SPARC64 processor which is a ( slightly ) different beast? Dennis Clarke http://www.blastwave.org/
Re: GCC 4.3.3 Released
>> > I'll try sparc64, powerpc64 and ia64 when the machines are available. >> >> I can probably help you with the Sparc64 requirement. To be precise, do >> you need Sun UltraSparc or are you looking for the multicore SPARC64 >> processor which is a ( slightly ) different beast? > > Thanks for your offer. > > I do have access to a sparc64, in fact it's the same machine that I used > for the sparc (32 bits) report in the farm, but it is down since since > morning and will probably be up again in the next few days. I am always a very careful with the 32-bit Sparc build because I often end up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such. Thus I use a genuine old old Sparc to build GCC with. # uname -a SunOS fossil 5.8 Generic_117350-56 sun4m sparc SUNW,SPARCstation-20 # isalist -v sparcv8 sparcv8-fsmuld sparcv7 sparc # file /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc: ELF 32-bit MSB executable , dynamically linked, not stripped see the "SPARC Version 1" there? That is my assurance that this will work on everything from old Sparc to the latest Niagara procs. It won't be fast .. but it will work. # /opt/build/GCC/gcc-4.3.3-build/prev-gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /export/nfs/build/gnu/GCC/gcc-4.3.3/configure --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix --enable-nls --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --enable-shared --enable-multilib --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-languages=c,c++,f95,objc,ada --enable-bootstrap Thread model: posix gcc version 4.3.3 (GCC) Dennis
make install fails to create gcc ?
This is a strange result, I seem to have everything I wanted, fortran and ada etc but no actual gcc file. If I look at the final output in the $DEST/bin ddir I see this, sorted by inodes numbers with blank lines added for clarity : # ls -lapin bin | sort -n | sed 's/^[ \t]*//' otal 92092 117274 drwxr-xr-x 8 01512 Feb 6 20:05 ../ 320544 drwxr-xr-x 2 01512 Feb 6 20:15 ./ 320545 -rwxr-xr-x 1 014180292 Feb 6 19:56 gnatbind 320546 -rwxr-xr-x 1 01 68796 Feb 6 19:56 gnatbl 320547 -rwxr-xr-x 1 012541072 Feb 6 19:57 gnatchop 320548 -rwxr-xr-x 1 015640680 Feb 6 19:57 gnat 320549 -rwxr-xr-x 1 01 658096 Feb 6 19:57 gnatkr 320550 -rwxr-xr-x 1 011861876 Feb 6 19:57 gnatlink 320551 -rwxr-xr-x 1 012227308 Feb 6 19:57 gnatls 320552 -rwxr-xr-x 1 017927520 Feb 6 19:58 gnatmake 320553 -rwxr-xr-x 1 014314000 Feb 6 19:58 gnatname 320554 -rwxr-xr-x 1 012946072 Feb 6 19:58 gnatprep 320555 -rwxr-xr-x 1 012401060 Feb 6 19:58 gnatxref 320556 -rwxr-xr-x 1 012403280 Feb 6 19:58 gnatfind 320557 -rwxr-xr-x 1 015429992 Feb 6 19:59 gnatclean 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 c++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 g++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 sparc-sun-solaris2.8-c++ 320558 -rwxr-xr-x 4 01 586632 Feb 6 20:05 sparc-sun-solaris2.8-g++ 320559 -rwxr-xr-x 2 01 589612 Feb 6 20:05 gfortran 320559 -rwxr-xr-x 2 01 589612 Feb 6 20:05 sparc-sun-solaris2.8-gfortran 320560 -rwxr-xr-x 1 01 188324 Feb 6 20:15 gcov 320561 -rwxr-xr-x 1 01 16191 Feb 6 20:15 gccbug 320562 -rwxr-xr-x 1 01 583720 Feb 6 20:15 cpp The thing that is missing entirely is gcc and then sparc-sun-solaris2.8-gcc and sparc-sun-solaris2.8-gcc-4.3.3 which are all hardlinks on the same inode number. In the build directory I do have an xgcc and it looks to be fine : $ gcc/xgcc --version xgcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ls -lap gcc/xgcc -rwxr-xr-x 1 dclarke csw 580900 Feb 6 05:08 gcc/xgcc Now then ... I kept a detailed log of the entired build/bootstrap process as well as the insatll process. I did see this in the logs : /export/nfs/build/gnu/GCC/gcc-4.3.3/install-sh: gprmake does not exist. gmake[2]: [ada.install-common] Error 1 (ignored) I also saw : /export/nfs/build/gnu/GCC/gcc-4.3.3/install-sh: gnatdll does not exist. gmake[2]: [ada.install-common] Error 1 (ignored) not too sure what the implications of that are. In any case . .the gcc binary is missing in action .. did make install fail in some weird way ? Dennis
fixincludes "fixes" Xlibint.h in an unknown way.
This is just a question. Hopefully someone can shed some light on what the fixincludes stage of "make install" does. I am making the assumption that the "make install" stage is where these headers get mangled or modified. This is on Solaris 8 by the way. Once make install has finished its job I see symlinks down deep in strange places thus : $ ls -lap $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/ | grep "^lrwx" lrwxrwxrwx 1 dclarke csw 28 Feb 7 17:19 X11 -> root/usr/openwin/include/X11/ lrwxrwxrwx 1 dclarke csw 22 Feb 7 17:19 Xm -> root/usr/dt/include/Xm/ lrwxrwxrwx 1 dclarke csw 29 Feb 7 17:19 kcms -> root/usr/openwin/include/kcms/ lrwxrwxrwx 1 dclarke csw 28 Feb 7 17:19 xil -> root/usr/openwin/include/xil/ These guys point to a dir entry called "root" which seems odd also but there it is. Way down deep in there I see this ( for example ) : $ ls -lap $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/root/usr/openwin/include/X11/ total 166 drwxr-xr-x 3 dclarke csw 512 Feb 7 09:37 ./ drwxr-xr-x 5 dclarke csw 512 Feb 7 09:37 ../ drwxr-xr-x 2 dclarke csw 512 Feb 7 09:37 DPS/ -rw-r--r-- 1 dclarke csw 4087 Feb 7 09:37 Xfuncs.h -rw-r--r-- 1 dclarke csw39002 Feb 7 09:37 Xlibint.h -rw-r--r-- 1 dclarke csw 6025 Feb 7 09:37 Xos.h -rw-r--r-- 1 dclarke csw 2980 Feb 7 09:37 Xosdefs.h -rw-r--r-- 1 dclarke csw10184 Feb 7 09:37 Xthreads.h -rw-r--r-- 1 dclarke csw 8847 Feb 7 09:37 dni.h -rw-r--r-- 1 dclarke csw 8366 Feb 7 09:37 nmdefs.h That all looks to be copies of *standard* headers found in the OS vendors /usr/openwin/share/include/X11 area. What changed ? $ diff /usr/openwin/share/include/X11/Xlibint.h $DEST/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/root/usr/openwin/include/X11/Xlibint.h 0a1,9 > /* DO NOT EDIT THIS FILE. > > It has been auto-edited by fixincludes from: > > "/usr/include/X11/Xlibint.h" > > This had to be done to correct non-standard usages in the > original, manufacturer supplied header file. */ > 882c891 < #ifdef sun /* added by SUNSOFT */ --- > #ifdef __sun__ /* added by SUNSOFT */ So the entire change is a comment and one line which both say "added by SUNSOFT" in them. Xfuncs.h is somewhat more interesting : < #if (__STDC__ && !defined(X_NOT_STDC_ENV) && !defined(sun) && !defined(macII) && !defined(apollo)) || defined(SVR4) || defined(hpux) || defined(_IBMR2) || defined(_SEQUENT_) --- > #if (__STDC__ && !defined(X_NOT_STDC_ENV) && !defined(__sun__) && !defined(macII) && !defined(apollo)) || defined(SVR4) || defined(hpux) || defined(_IBMR2) || defined(_SEQUENT_) 88c97 < #if !defined(X_NOT_STDC_ENV) && (!defined(sun) || defined(SVR4)) --- > #if !defined(X_NOT_STDC_ENV) && (!defined(__sun__) || defined(SVR4)) 96c105 < #if defined(SYSV) || defined(luna) || defined(sun) || defined(__sxg__) --- > #if defined(SYSV) || defined(luna) || defined(__sun__) || defined(__sxg__) $ It looks like anywhere you find the string "defined(sun)" you change it to "defined(__sun__)". That is an observation. But what did this ? Was it fixincludes or was it the mkheaders script ? and why ? -- Dennis Clarke
Re: fixincludes "fixes" Xlibint.h in an unknown way.
>> Was it fixincludes or was it the mkheaders script ? >> >> and why ? > > Because system headers should not define something in the users namespace, > certainly not a non-uglified three-letter name such as "sun". > > Consider > > #include > > int sun; > > which will not build otherwise. I did find this .. and I see it in the 4.0.2 GCC tree also that I have here : $ cat /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/README This README file is copied into the directory for GCC-only header files when fixincludes is run by the makefile for GCC. Many of the files in this directory were automatically edited from the standard system header files by the fixincludes process. They are system-specific, and will not work on any other kind of system. They are also not part of GCC. The reason we have to do this is because GCC requires ANSI C headers and many vendors supply ANSI-incompatible headers. Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient". simply put .. it all looks good. I simply need to figure out how to release things to users or do I force a fixincludes/make headers script event during install or what. How does Debian and Ubuntu handle this ? When a user installs a pre-compiled ready to run GCC package do they get the headers "fixed" on the fly or do they get delivered ... -- Dennis Clarke
Re: make install fails to create gcc ?
>> In any case . .the gcc binary is missing in action .. did make install >> fail in some weird way ? > > Possibly, but make should have failed also. > I re-ran the whole bootstrap process and this time was rewarded with everything I wanted. I don't know what the issue was earlier. Oh well. Dennis
Re: GCC Compile Farm News: 12 architectures now available
> Hi, > > Thanks to many donors of both hosting and machines the architecture > coverage of the GCC Compile Farm has been greatly expanded > in the recent monthes: > > http://gcc.gnu.org/wiki/CompileFarm I think this is excellent. Will you be installing baseline Solaris machines that ensure testing is done for the vast number of Solaris comercial users out there? When I say "commercial" I mean the older legacy Solaris 8 releases. We currently cover this at Blastwave.org all the way back to the very old Sun Sparc sun4m architecture and in this way we know that anything we compile will run across the whole Solaris suite from Solaris 8 upwards on anything with a Sparc chip. The x86 world is somewhat more messy and in this regard we use a Pentium III based machine with Solaris 8. I note that you have Solaris 10 there in your farm but only for Sparc and no representation for Solaris on x86 or OpenSolaris for that matter. Therefore your test farm will not verify functionality on anything older than Solaris 10 and only on Sparc. That should be "good enough" but not exactly what I would call commercial grade testing. Is this because only Sparc Solaris is on your Primary Platform List? Dennis Clarke dcla...@blastwave.org Director Blastwave.org 905 - 373 - 9441 Open Source Services for Solaris http://www.blastwave.org - Further Info at http://en.wikipedia.org/wiki/Blastwave
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> A successful build on Open Solaris 2008.11: > > $../gcc-4.4.0/config.guess > i386-pc-solaris2.11 > > $ gcc-4.4.0t -v > Using built-in specs. > Target: i386-pc-solaris2.11 > Configured with: ../gcc-4.4.0/configure > --enable-languages=c,c++,fortran --disable-multilib > --program-suffix=-4.4.0t --disable-nls --with-gnu-as > --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld > Thread model: posix > gcc version 4.4.0 (GCC) > > Note that the host/target is one number higher that that listed in the > installation notes, i.e., the one ther is "*solaris2.10" while this > host/target is "*solaris2.11" > > I had problems later building ppl and cloog to incorporate into g++. > I have asked about this on the gcc-help mailing list. well done, do you have a full testsuite report ? Dennis
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> On Sat, Apr 25, 2009 at 9:09 PM, Dennis Clarke > wrote: >> >>> A successful build on Open Solaris 2008.11: >>> >>> $../gcc-4.4.0/config.guess >>> i386-pc-solaris2.11 >>> >>> $ gcc-4.4.0t -v >>> Using built-in specs. >>> Target: i386-pc-solaris2.11 >>> Configured with: ../gcc-4.4.0/configure >>> --enable-languages=c,c++,fortran --disable-multilib >>> --program-suffix=-4.4.0t --disable-nls --with-gnu-as >>> --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld >>> Thread model: posix >>> gcc version 4.4.0 (GCC) >>> >>> Note that the host/target is one number higher that that listed in the >>> installation notes, i.e., the one ther is "*solaris2.10" while this >>> host/target is "*solaris2.11" >>> >>> I had problems later building ppl and cloog to incorporate into g++. >>> I have asked about this on the gcc-help mailing list. >> >> well done, do you have a full testsuite report ? > > Thanks, Dennis, I feel lucky! > > No, but I'll fire one off now before I go to bed. It'll probably take > all night since it's a virtual host running on Linux Centos 5.3 x86_64 > (Intel Core 2 duo 1.86 GHz). ha ! I can relate to that! I have builds that run all night and day and then you get a result set where you look at it and wonder .. gee, what went wrong and you have to go do it all over again. I admire people that have the patience to see this through to the end *and* focus on quality. -- Dennis Clarke
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> On Sat, Apr 25, 2009 at 9:55 PM, Dennis Clarke > wrote: > ... >>>> well done, do you have a full testsuite report ? > > Well, Dennis, I have problems running the testsuite. I think I'm > missing some of the prereqs, so it will be a while. I'll report back > unless someone finishes first.. I am in progress but being very careful with each step. This may take a while. -- Dennis Clarke
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> Attached is a shortened test report with the following lines removed: > excellent, now we have a benchmark/comparison to look at. Well done, excellent work. What did you use to build libgmp and mpfr ? I am curious because most people that try wwith Sun Studio Express or Sun Studio 12 fail pretty badly unless you use the stlport4 libs. How did you did it ? Inquiring minds want to know! :-) Dennis
Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
Re: http://gcc.gnu.org/gcc-4.3/buildstat.html I was looking for testsuite results to compare with on Solaris and I saw that nearly every report for GCC 4.3.3 was done by Tom G. Christensen. All GCC 4.3.3 reports on Solaris from one person : i386-pc-solaris2.6 Test results: 4.3.3 i386-pc-solaris2.8 Test results: 4.3.3 i386-pc-solaris2.9 Test results: 4.3.3 i386-pc-solaris2.10 Test results: 4.3.3 sparc-sun-solaris2.6Test results: 4.3.3 sparc-sun-solaris2.7Test results: 4.3.3 sparc-sun-solaris2.8Test results: 4.3.3 I think it is great we have any report at all but for the sake of diversity and some comparison data I'll add mine in there : Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8 http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html I'll get the i386 reports later this week. -- Dennis Clarke http://www.blastwave.org/
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: >> Re: http://gcc.gnu.org/gcc-4.3/buildstat.html >> >> I was looking for testsuite results to compare with on Solaris and I saw >> that nearly every report for GCC 4.3.3 was done by Tom G. Christensen. >> >> All GCC 4.3.3 reports on Solaris from one person : >> > > You better get cracking on 4.4.0 aswell since I posted most of those > reports too ;) no rest for the weary .. you have been very busy indeed. How did you do with the new PPL bits ? That went smoothly ? >> I think it is great we have any report at all but for the sake of >> diversity and some comparison data I'll add mine in there : >> > More testresults are always welcome. I think a few datapoints are always better than one. Tough to plot a trend or do comparison with one datapoint. >> Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8 >> http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html >> > Thank you. > >> I'll get the i386 reports later this week. >> > Sounds good. > > The testresults will be added with the next round of updates which I > plan to do early next week. > cool :-) Dennis
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: > > How did you do with the new PPL bits ? That went smoothly ? >> > They're not mandatory for 4.4.x so I've simply ignored them for now. ah .. how very tricky of you :-) Dennis
Re: GCC 4.4.4 Released
> The GNU Compiler Collection version 4.4.4 has been released. Please provide MD5/SHA1/SHA256 hash sums for the release files in your release announcement. Those would be the reference standard for people to check as opposed to mirror sites which may be all over the world and sysadmins from who knows where. Just a suggestion. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.4.4 Released
> On Sun, May 02, 2010 at 01:41:10PM -0400, Dennis Clarke wrote: >> >> > The GNU Compiler Collection version 4.4.4 has been released. >> >> Please provide MD5/SHA1/SHA256 hash sums for the release files in your >> release announcement. Those would be the reference standard for people >> to >> check as opposed to mirror sites which may be all over the world and >> sysadmins from who knows where. >> >> Just a suggestion. > > You can download md5.sum files directly from gcc.gnu.org: > ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.4.4/md5.sum > ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.4.4/diffs/md5.sum > or, if you download from ftp.gnu.org or its mirrors, you can check > the tarballs and diffs using gpg. > Yes, of course. I agree. However, merely a gentle suggestion that those be in the cleartext of the announcement message as well as perhaps your message can be GPG signed. This is, afterall, the GNU C compiler which is the single most important bit of open source in the world in my ( not so humble ) opinion. All others ( like entire operating systems ) are built with it right? If you see my meaning. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> > A release canidate for GCC 4.5.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.1-RC-20100722/ > > and shortly its mirrors. It has been generated from SVN revision 162408. > > I have sofar bootstrapped and tested the release candidate on > x86_64-unknown-linux-gnu. Please test it and report any issues to > bugzilla. > > The branch remains frozen and all checkins until after the final > release of GCC 4.5.1 require explicit RM approval. > > If all goes well, I'd like to release 4.5.1 before Aug 1st. > FYI , bug 44455 is a show stopper in the Solaris world. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455 -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes:
>
>> FYI , bug 44455 is a show stopper in the Solaris world.
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
>
> This is
>
> bootstrap/44455 GCC fails to build if MPFR 3.0.0 (Release Candidate) is
used
>
> Why would this be a showstopper? Who forces you to build and install
mpfr 3.0.0? OpenSolaris comes with 2.4.1, and older versions don't
OpenSolaris is not a production release run by anyone anywhere :-)
> have mpfr bundled at all, so just use a version that works with GCC,
building it in-tree if you must.
OKay .. I guess details are needed.
If I place the latest mpfr and gmp and mpc and ppl and cloog in tree then
the build fails in stage one very early with bizarre warning about not
being able to find gmp rev greater than 4.3.1 despite the face that I have
already built and tested :
GMP: include 4.3.2, lib 4.3.2
MPFR: include 3.0.0-p3, lib 3.0.0-p3
MPC: include 0.8.2, lib 0.8.2
Those would all be installed in /usr/local with no surprises.
Regardless .. the build fails with the same message as bugid 44455.
Of course I try with gmp-5.0.1 first and that also fails so long as ppl is
around in the tree.
So I throw away ppl and cloog ( which I have *never* seen build on Solaris
10 anyways ) and then the build fails a little later with :
make[3]: Leaving directory
`/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/gcc'
mkdir i386-pc-solaris2.10/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in i386-pc-solaris2.10/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722/install-sh -c
checking for gawk... nawk
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for i386-pc-solaris2.10-ar... ar
checking for i386-pc-solaris2.10-lipo... lipo
checking for i386-pc-solaris2.10-nm...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/nm
checking for i386-pc-solaris2.10-ranlib... ranlib
checking for i386-pc-solaris2.10-strip... strip
checking whether ln -s works... yes
checking for i386-pc-solaris2.10-gcc...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-include
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-includeaccepts -g... yes
checking for
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-includeoption to accept ISO
C89... none needed
checking how to run the C preprocessor...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/xgcc
-B/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/./gcc/
-B/usr/local/gcc4/i386-pc-solaris2.10/bin/
-B/usr/local/gcc4/i386-pc-solaris2.10/lib/ -isystem
/usr/local/gcc4/i386-pc-solaris2.10/include -isystem
/usr/local/gcc4/i386-pc-solaris2.10/sys-include-E
checking whether decimal floating point is supported... no
checking whether fixed-point is supported... no
checking for __attribute__((visibility("hidden")))... no
checking whether the target assembler supports thread-local storage... yes
checking whether the thread-local storage support is from emutls... no
configure: updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default commands
Adding multilib support to Makefile in
../../../gcc-4.5.1-RC-20100722/libgcc
multidirs=amd64
with_multisubdir=
Running configure in multilib subdirs amd64
pwd:
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/i386-pc-solaris2.10/libgcc
Running configure in multilib subdir amd64
pwd:
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722-001/i386-pc-solaris2.10
mkdir amd64
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install...
/export/home/dclarke/build/GCC/gcc-4.5.1-RC-20100722/install-sh -c
checking for gawk... nawk
checking build system type... i386-pc-solaris2.10
checking host system type... i3
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> If I go back and rebuild gmp mpfr and mpc thus : >> >> >> GMP: include 5.0.1, lib 5.0.1 >> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >> MPC: include 0.8.2, lib 0.8.2 > > Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do > not build these libraries in-tree. I built and tested them separate. -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
GMP: include 5.0.1, lib 5.0.1 MPFR: include 3.0.0-p3, lib 3.0.0-p3 MPC: include 0.8.2, lib 0.8.2 >>> >>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >>> not build these libraries in-tree. >> >> I built and tested them separate. > > You forgot to set LD_LIBRARY_PATH. > > That is considered evil on Solaris. http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the http://blogs.sun.com/rie/entry/tt_ld_library_path_tt I did set LD_RUN_PATH and LD_OPTIONS however. -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> On Jul 23, 2010, at 9:58 AM, Dennis Clarke > wrote: >>>>>> GMP: include 5.0.1, lib 5.0.1 >>>>>> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >>>>>> MPC: include 0.8.2, lib 0.8.2 >>>>> >>>>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or >>>>> do >>>>> not build these libraries in-tree. >>>> >>>> I built and tested them separate. >>> >>> You forgot to set LD_LIBRARY_PATH. >>> >>> >> >> That is considered evil on Solaris. >> >> http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the >> >> http://blogs.sun.com/rie/entry/tt_ld_library_path_tt >> >> I did set LD_RUN_PATH and LD_OPTIONS however. > > -R and run path has bigger issues than ld library path. But then you > should look into config.log and see why it fails. I bet a beer it is > not finding the shared libraries. Now this is serious ! Would you bet a case of beer ? gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../gcc-4.4.4/configure --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386 --with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron --enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/usr/local --enable-threads=posix --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --prefix=/usr/local/gcc4 --with-local-prefix=/usr/local --enable-shared --enable-multilib --with-system-zlib --with-pkgversion='Blastwave.org Inc. Fri Jul 23 15:32:37 GMT 2010' --with-bugurl=http://www.blastwave.org/support --enable-languages=c,c++,objc,fortran --enable-bootstrap Thread model: posix gcc version 4.4.4 (Blastwave.org Inc. Fri Jul 23 15:32:37 GMT 2010) $ I'll run the testsuite , post the results and then make install. Then I'll rebuild binutils and try gcc 4.5.1 release candidate again with the exact same environment settings. By the way .. I did not use LD_LIBRARY_PATH at all. I was thinking Grolsch. I love that stuff and the bottles are cool. -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Richard Guenther wrote: > >> On Fri, 23 Jul 2010, Dennis Clarke wrote: > >>> GMP: include 4.3.2, lib 4.3.2 >>> MPFR: include 3.0.0-p3, lib 3.0.0-p3 >>> MPC: include 0.8.2, lib 0.8.2 > > fails, > > Richard recommends: > >> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >> not build these libraries in-tree. > > Recently, I was thrown back to Debian Lenny, out of a mistake of my own > regard 1) (which dates back to 14 February 2009, so over 1.5 years ago). > > What I did was downloading: > > gmp-4.3.2.tar.bz2 > mpfr-2.4.2.tar.bz2 > mpc-0.8.2.tar.gz > > unpack them into their own directories and adding: > > lrwxrwxrwx 1 toon toon 15 2010-07-14 15:19 gmp -> ../../gmp-4.3.2 > lrwxrwxrwx 1 toon toon 15 2010-07-14 14:51 mpc -> ../../mpc-0.8.2 > lrwxrwxrwx 1 toon toon 16 2010-07-14 15:24 mpfr -> ../../mpfr-2.4.2 > > as those source directories were two levels up from my 'gcc' source > directory. > > That worked (I never got it working with mpfr 3.0.0 and gmp 5.0.x) > [ You can't imagine the pain working with a 1.5 year old OS ] > Have you seen Solaris 8 ? [titan]uname -a SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc [titan]cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 [titan] [titan]psrinfo -v Status of virtual processor 0 as of: 07/23/10 17:46:33 on-line since 06/15/10 20:44:18. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 07/23/10 17:46:33 on-line since 06/15/10 20:44:22. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. [titan] -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> Use GMP from the 4.2.x series and MPFR from the 2.3.x series. Or do >> not build these libraries in-tree. > > Yes, and verify that GMP and MPFR are correctly compiled with > "make check". Recent versions are miscompiled on SPARC/Solaris > by GCC 4.3.x for x < 3 or 4. > > The recommended versions (GMP 4.3.2, MPFR 2.4.2, MPC 0.8.1) also > work fine if compiled by the latest GCC 4.3.x compilers (or > compilers of later series). === gcc Summary === # of expected passes57009 # of unexpected failures67 # of unexpected successes 7 # of expected failures 197 # of unsupported tests 518 === g++ Summary === # of expected passes20118 # of unexpected failures29 # of unexpected successes 4 # of expected failures 158 # of unsupported tests 136 Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
>> === gcc Summary === >> >> # of expected passes57009 >> # of unexpected failures67 >> # of unexpected successes 7 >> # of expected failures 197 >> # of unsupported tests 518 >> >> === g++ Summary === >> >> # of expected passes20118 >> # of unexpected failures29 >> # of unexpected successes 4 >> # of expected failures 158 >> # of unsupported tests 136 > > I meant "make check" for GMP and MPFR, not for GCC. > did that too :-) -- Dennis
Re: GCC 4.5.1 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes: > >> FYI , bug 44455 is a show stopper in the Solaris world. >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455 > > This is > > bootstrap/44455 GCC fails to build if MPFR 3.0.0 (Release Candidate) is > used > > Why would this be a showstopper? Who forces you to build and install > mpfr 3.0.0? OpenSolaris comes with 2.4.1, and older versions don't > have mpfr bundled at all, so just use a version that works with GCC, > building it in-tree if you must. > Sorted things out and all is well now : http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02266.html Thanks all for the lectures/pointers/edification :-) -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: Parma Polyhedra Library 0.11
>> Roberto Bagnara Patricia M. Hill Enea Zaffanella >> >> Applied Formal Methods Laboratory >> Department of Mathematics >> University of Parma, Italy >> > > cool.. just downloaded it.. just curious if I need to install ppl and > cloog on the system then build gcc? right now with the latest snapshot > of gcc, mpfr gmp are in the source tree and build fine but as soon as I > add cloog ppl and mpc I crapp out at ppl telling me it cant find gmp > > keep in mind this is my first attempt to build gcc with all these > packages in the source tree of gcc rather than building them separately. > On a number of occasions I have tried to build ppl and Cloog and watched the process fail repeatedly. I have yet to see it complete with any degree of success. Perhaps this is due to some strange issue with gmp and mpfr header versions and a false error message about libgmp versions is generally seen early in the build process. If this fault in the ppl/cloog code has been fixed then I'll be quite glad to see it. If not then I shall continue to work with GCC without either ppl or cloog as their absence seems to not matter a bit. This is entirely based on my experiences within the Solaris world where we still have issues with the GNU Binutils ld linker also. -- Dennis
Re: GCC 4.5.1 Released
> > The GNU Compiler Collection version 4.5.1 has been released. > > GCC 4.5.1 is a bug-fix release containing fixes for regressions and > serious bugs in GCC 4.5.0. This release is available from the > FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments about > this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release -- far > too many to thank individually! Based on what I have seen thus far ( I know time will tell ) it seems to be one of the very best releases in years. Works well in the Solaris world also and even on i386-pc-solaris2.8 and that is saying something. :-) -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Regarding the GCC Binaries and Build status pages
Dear GCC Team : This is just a friendly letter. There probably will not be another GCC update from the Sunfreeware site ( which is still showing 3.4.6 ) for a long time now that Oracle has pulled finances. The same sad state of affairs affects the OpenSolaris project as a whole. I do expect that the Blastwave site will release formal 4.5.1 packages to the world sometime in the next week and there should be at least some mention on this page given that we have released packages for GCC ver 4.x ( 4.0.1 and 4.3.4 etc ) for four years now : http://gcc.gnu.org/install/binaries.html Also, we have some excellent GCC 4.5.1 test results on Solaris 8 Sparc as well as i386 ( 32-bit ) thus : http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01024.html http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01023.html We have a team of people that perform GCC builds and tests on the Solaris production releases and we are happy to release these packages in SVR4 spec format to the Solaris user world. It would be nice if there were some mention on the "Binaries" page that we have been doing this service. Any reference to the test suite results is always nice also. We have been building 4.5.1 since the pre-release and it just seems to be an excellent compiler. In fact, we are moving our entire build process internally over to GCC 4.5.1 and saying goodbye to Sun Studio now that Oracle has stepped in and taken over Sun. Any questions or need for Solaris based test accounts, please feel free to ask. -- Dennis Clarke 2010 OpenSolaris Governance Board Member dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >> > This was built against ppl 0.10.2 and cloog 0.15.10. Have you tried a bootstrap with neither ppl nor cloog ? I have yet to see their value and I generally exclude them. This results ( thus far ) in nice clean bootstrap builds. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote: >> >> > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >> >> >> > This was built against ppl 0.10.2 and cloog 0.15.10. >> >> Have you tried a bootstrap with neither ppl nor cloog ? I have yet to >> see >> their value and I generally exclude them. This results ( thus far ) in >> nice clean bootstrap builds. >> > > Dennis, >Considering that distros like Fedora ship their gcc's with graphite > support built-in, allowing graphite to regress like this between gcc > maintenance releases doesn't seem like a very good idea. > Jack Of course I agree completely. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> On Wed, 8 Dec 2010, Jack Howarth wrote: >> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote: >> > > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >> > >> >> > > This was built against ppl 0.10.2 and cloog 0.15.10. >> > >> > Have you tried a bootstrap with neither ppl nor cloog ? I have yet to >> see >> > their value and I generally exclude them. This results ( thus far ) in >> > nice clean bootstrap builds. >> Dennis, >>Considering that distros like Fedora ship their gcc's with graphite >> support built-in, allowing graphite to regress like this between gcc maintenance releases doesn't seem like a very good idea. > > The SUSE builds look fine. You have to investigate why it doesn't work for you, but it won't hold the 4.5.2 release. Are your > ppl and cloog testsuite runs clean? Did you by chance build them with a different GCC release (and thus libstdc++)? > > Thanks, > Richard. Good question ! I generally do a double bootstrap in which my first build is done with a previous version of GCC. Once I see reasonable testsuite results I then use the resultant compiler from the first bootstrap to build the "release" version. This then explains why the compiler that build GCC 4.5.1 on Solaris 8 is in fact, GCC 4.5.1 : http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02183.html However, having said all this I have yet to see either the ppl or cloog software components build once on the legacy Solaris platform I must support baseline legacy Solaris 8 which in turn assures functionality upwards to Solaris 10 and possibly 11. http://www.blastwave.org/jir/pkgcontents.ftd?software=gcc4&style=brief&state=5&arch=sparc -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org
> > > Dennis Clarke-2 wrote: >> >> >>> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote: >>>> >>> This was built against ppl 0.10.2 and cloog 0.15.10. >> >> Have you tried a bootstrap with neither ppl nor cloog ? I have yet to >> see >> their value and I generally exclude them. This results ( thus far ) in >> nice clean bootstrap builds. >> > > i sucessfully bootstraped on powerpc64-unknown-linux-gnu and > powerpc-unknown-linux-gnu but > as i've ppl-0.11 i still need this configure hack: > sed -i "/ppl_minor_version=/s#10#11#" $name-$version/configure > excellent. I love PowerPC. :-) On other fronts I have been working for days to get ppl to compile and pass its own basic testsuite on Solaris ( i386 and Sparc ) and thus far all attempts have failed. I have been in contact with Roberto Bagnara and I have his next release candidate on my systems ( at Blastwave.org Inc. ) and I am sure we will work it out and then get GCC 4.5.2 ( RC or otherwise ) up and running. This will be a week of work at least however. :-\ -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
GCC 4.5.2 Release Candidate : WARNING: program timed out.
While running the testsuite I see a number of warnings related to timeouts. Is there some way to avoid these annoyances? Thus : === gcc tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /export/medusa/dclarke/build/GCC/4.5.2-RC/RC-20101208/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /export/medusa/dclarke/build/GCC/4.5.2-RC/RC-20101208/gcc/testsuite/gcc.c-torture/compile/compile.exp ... WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O1 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O3 -g (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -Os (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 -flto (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 -fwhopr (test for excess errors) . . . -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.5.2 Release Candidate : WARNING: program timed out.
> Dennis Clarke writes: > >> WARNING: program timed out. >> FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) > > This is likely a bug in your assembler. Well, the assembler is this : # file /usr/local/bin/as /usr/local/bin/as: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped # /usr/local/bin/as --version GNU assembler (GNU Binutils) 2.20.1.20100303 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `i386-pc-solaris2.8'. So if the bug is there it would affect more than just some small Solaris i386 server I would think. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
4.5.2 20101213 (prerelease) ??
Dear GCC folks : I have been closely watching the testsuite results as they come in and I have yet to see anyone do anything with the 4.5.2 RC for Solaris. Other than me of course. I have seen some work by Laurent GUERBY on 4.5.2 RC 20101213 ( on Linux ) which is NOT what I see at ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.5/ So how does an outside community style hard working guy like me get the absolute latest ? Subversion only ? I'm just trying to do tests before the actual release and thus far I am seeing wonderful results : http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01062.html http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01063.html If there is some other snapshot or RC that I should be testing please let me know. Thank you dear GCC folks. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: 4.5.2 20101213 (prerelease) ??
> On 13 December 2010 15:31, Dennis Clarke wrote: >> Dear GCC folks : >> >> I have been closely watching the testsuite results as they come in and I >> have yet to see anyone do anything with the 4.5.2 RC for Solaris. Other >> than me of course. I have seen some work by Laurent GUERBY on 4.5.2 RC >> 20101213 ( on Linux ) which is NOT what I see at >> ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.5/ >> >> So how does an outside community style hard working guy like me get the >> absolute latest ? Subversion only ? I'm just trying to do tests before >> the >> actual release and thus far I am seeing wonderful results : >> >> http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01062.html >> >> http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01063.html >> >> If there is some other snapshot or RC that I should be testing please >> let >> me know. Thank you dear GCC folks. > > You get the latest gcc-4_5-branch (as always) from Subversion, but as > the branch is frozen you shouldn't need to. The only change I see > since the RC (rev 167585) is the daily bump to update the date in the > version string: > http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/?sortby=rev&sortdir=down#dirlist > > In that case we are all on the same page and just waiting for the official code drop :-) excellent. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
gcc-4.5.2-RC-20101208 warning in fold-const.c
I'm doing a bootstrap with on Debian squeeze with --enable-stage1-checking=all and --enable-checking=all and in stage 2 I see this sort of thing about an "unsafe" issue : ../../gcc-4.5.2-RC-20101208/gcc/fold-const.c: In function 'fold_checksum_tree': ../../gcc-4.5.2-RC-20101208/gcc/fold-const.c:14267:3: warning: new qualifiers in middle of multi-level non-const cast are unsafe This is probably filed as a bug somewhere but I couldn't find it. -- Dennis
GCC 4.5.2 ?
It is Wed now. Will we see a official release this week ? -- Dennis
Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
> On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth > wrote: >> Sebastian, >> It appears that the official tarballs are now posted at >> http://www.cloog.org/ >> for cloog and cloog-parma 0.16. Do you plan on placing those both in the >> infrastructure >> directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball >> should be added >> as well. If those files are updated, we should be set to switch gcc >> trunk to require >> ppl >= 0.11, cloog >= 0.16 and the default cloog backend from legacy >> cloog-ppl to >> cloog-isl. > > I don't think this is a very good idea at this point. I think ppl is in a stae of change and between releases. I have not yet seen it compile cleanly once with any version of GCC on Solaris. It certainly never passes its own testsuites without a coredump or some significant failure. Roberto Bagnara is aware of this and I am going to work with him on this to get something valid in the POSIX/UNIX world and hopefully a new release of ppl will come out that is solid for integration into GCC. As for ClooG, I have no data at this time. This is merely an observation from someone that tries to be very very careful with testing and with testsuite results. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris ps: thus far GCC 4.5.2 is beautiful on Solaris however on Debian Squeeze it seems to be a nightmare. Testsuite has been running for three days on Intel i7 with many many failures. I'll report data when I have it.
Really poor 4.5.2 results on Debian Squeeze with Intel i7
ess errors) WARNING: 23_containers/unordered_set/requirements/exception/generation_prohibited.cc compilation failed to produce executable WARNING: program timed out. FAIL: 23_containers/unordered_set/requirements/exception/propagation_consistent.cc (test for excess errors) WARNING: 23_containers/unordered_set/requirements/exception/propagation_consistent.cc compilation failed to produce executable WARNING: program timed out. FAIL: 23_containers/vector/cons/2.cc (test for excess errors) WARNING: 23_containers/vector/cons/2.cc compilation failed to produce executable WARNING: program timed out. FAIL: 23_containers/vector/requirements/exception/basic.cc (test for excess errors) WARNING: 23_containers/vector/requirements/exception/basic.cc compilation failed to produce executable WARNING: program timed out. FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc (test for excess errors) WARNING: 23_containers/vector/requirements/exception/generation_prohibited.cc compilation failed to produce executable WARNING: program timed out. FAIL: 23_containers/vector/requirements/exception/propagation_consistent.cc (test for excess errors) WARNING: 23_containers/vector/requirements/exception/propagation_consistent.cc compilation failed to produce executable WARNING: program timed out. FAIL: 26_numerics/complex/inserters_extractors/char/1.cc (test for excess errors) WARNING: 26_numerics/complex/inserters_extractors/char/1.cc compilation failed to produce executable WARNING: program timed out. FAIL: 26_numerics/complex/inserters_extractors/wchar_t/1.cc (test for excess errors) WARNING: 26_numerics/complex/inserters_extractors/wchar_t/1.cc compilation failed to produce executable Compiler version: 4.5.2 (Blastwave.org Inc. Tue Dec 28 09:38:16 GMT 2010) Platform: x86_64-pc-linux-gnu configure flags: --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-gnu-as --with-as=/usr/local/bin/gas --with-gnu-ld --with-ld=/usr/local/bin/gld --with-cpu=opteron --enable-stage1-languages=c --enable-stage1-checking=all --enable-nls --enable-threads=posix --enable-multilib --prefix=/usr/local/gcc4 --with-local-prefix=/usr/local --enable-shared --enable-languages=c,c++,objc,fortran --with-system-zlib --enable-clocale=gnu --with-arch-32=i586 --with-tune=generic --enable-checking=all --enable-libssp --enable-objc-gc--enable-__cxa_atexit --with-included-gettext --with-pkgversion='Blastwave.org Inc. Tue Dec 28 09:38:16 GMT 2010' --with-bugurl=http://www.blastwave.org/support --enable-bootstrap EOF After three days ... I gave up waiting. comments welcome . -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: error in gcc version 4.6.2 ???
>
> Hello good day !
>
> I know, that gcc 4.7 is now out ... !
>
> gcc 4.6.2 has somewhat "strange" failure-announcements ... I think it is
> a bug !
interesting :
mimas-sparc-SunOS5.8 $ gcc --version
gcc (Blastwave.org Inc Mon Nov 7 16:53:21 GMT 2011) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mimas-sparc-SunOS5.8 $ gcc -E -o foobar.i foobar.c
foobar.c:38:9: warning: missing terminating " character [enabled by default]
foobar.c:40:14: warning: missing terminating " character [enabled by default]
foobar.c:47:10: warning: missing terminating " character [enabled by default]
foobar.c:48:25: warning: missing terminating " character [enabled by default]
foobar.c:51:10: warning: missing terminating " character [enabled by default]
foobar.c:52:25: warning: missing terminating " character [enabled by default]
mimas-sparc-SunOS5.8 $ ls -lap foobar.i
-rw-r--r-- 1 sysadmin sysadmin 38785 Feb 23 18:01 foobar.i
mimas-sparc-SunOS5.8 $ gcc -o foobar foobar.i
foobar.c: In function 'main':
foobar.c:38:9: warning: missing terminating " character [enabled by default]
foobar.c:38:2: error: missing terminating " character
foobar.c:39:2: error: 'pointers' undeclared (first use in this function)
foobar.c:39:2: note: each undeclared identifier is reported only once for each
function it appears in
foobar.c:39:10: error: expected ')' before ':' token
foobar.c:40:2: error: stray '\' in program
foobar.c:40:14: warning: missing terminating " character [enabled by default]
foobar.c:40:2: error: missing terminating " character
foobar.c:47:10: warning: missing terminating " character [enabled by default]
foobar.c:47:3: error: missing terminating " character
foobar.c:48:4: error: invalid suffix "lX" on integer constant
foobar.c:48:3: error: stray '\' in program
foobar.c:48:3: error: stray '\' in program
foobar.c:48:20: error: invalid suffix "lX" on integer constant
foobar.c:48:25: warning: missing terminating " character [enabled by default]
foobar.c:48:3: error: missing terminating " character
foobar.c:51:10: warning: missing terminating " character [enabled by default]
foobar.c:51:3: error: missing terminating " character
foobar.c:52:4: error: invalid suffix "lX" on integer constant
foobar.c:52:3: error: stray '\' in program
foobar.c:52:3: error: stray '\' in program
foobar.c:52:20: error: invalid suffix "lX" on integer constant
foobar.c:52:25: warning: missing terminating " character [enabled by default]
foobar.c:52:3: error: missing terminating " character
foobar.c:55:2: error: expected ';' before '}' token
foobar.c: At top level:
foobar.c:57:2: warning: data definition has no type or storage class [enabled
by default]
foobar.c:58:2: warning: data definition has no type or storage class [enabled
by default]
foobar.c:59:2: warning: data definition has no type or storage class [enabled
by default]
foobar.c:60:2: warning: data definition has no type or storage class [enabled
by default]
foobar.c:62:9: error: expected declaration specifiers or '...' before string
constant
foobar.c:64:2: error: expected identifier or '(' before 'return'
foobar.c:66:1: error: expected identifier or '(' before '}' token
mimas-sparc-SunOS5.8 $
mimas-sparc-SunOS5.8 $
--
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-+---+
| Dennis Clarke | Solaris and Linux and Open Source |
| dcla...@blastwave.org | Respect for open standards. |
+-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> > GCC 4.7.0 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.7.0 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 > > and shortly its mirrors. It has been generated from SVN revision 184777. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. > > If all goes well, I'd like to release 4.7.0 in about three weeks. I'll drop it on Solaris. Give it a push. Do we realy really need that ppl/cloog stuff? I have never seen it build and pass any tests, ever, even once, on Solaris with or without Sun Studio compilers or GCC or prayer and geek magic under a full moon. Seriously. So really, it that stuff a "need" or a "nice to have" ? dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>> If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> I'll drop it on Solaris. Give it a push. Do we realy really need that >> ppl/cloog stuff? I have never seen it build and pass any tests, ever, >> even once, on Solaris with or without Sun Studio compilers or GCC or >> prayer and geek magic under a full moon. Seriously. > > Given that PPL is a C++ library, you need to build it with g++ since > Studio CC and g++ aren't ABI-compatible. > > That said, I'm using them in my Solaris GCC bootstraps, although it > admittedly took some effort to build initially and using it requires you > to jump through hoops to get the configure options right. I agree that > this is an incredible mess right now. I found it too be entirely too much work to be trusted and considered stable long term. So therefore I generally kick ppl/cloog to the curb and focus on core c,c++ gfortan and ada with objc thrown in without the ppl/cloog bits at all. I have been very happy with my results and the recent 4.6.3 RC was the most clean and pure results I have seen to date, on Solaris 8 old Sparc no less : http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02786.html >> So really, it that stuff a "need" or a "nice to have" ? > > install.texi documents them as optional: > > Necessary to build GCC with the Graphite loop optimizations. > > but that sentence could probably be clarified. Would be cool to say "entirely optional". dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> Dennis Clarke writes: > >>> GCC 4.7.0 Release Candidate available from gcc.gnu.org >>> >>> The first release candidate for GCC 4.7.0 is available from >>> >>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >>> >>> and shortly its mirrors. It has been generated from SVN revision 184777. >>> >>> I have so far bootstrapped and tested the release candidate on >>> x86_64-linux. Please test it and report any issues to bugzilla. >>> >>> If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> I'll drop it on Solaris. Give it a push. Do we realy really need that >> ppl/cloog stuff? I have never seen it build and pass any tests, ever, >> even once, on Solaris with or without Sun Studio compilers or GCC or >> prayer and geek magic under a full moon. Seriously. > > Given that PPL is a C++ library, you need to build it with g++ since > Studio CC and g++ aren't ABI-compatible. > > That said, I'm using them in my Solaris GCC bootstraps, although it > admittedly took some effort to build initially and using it requires you > to jump through hoops to get the configure options right. I agree that > this is an incredible mess right now. > >> So really, it that stuff a "need" or a "nice to have" ? > > install.texi documents them as optional: > > Necessary to build GCC with the Graphite loop optimizations. > > but that sentence could probably be clarified. > > Rainer Well this topic is in play for me right now and I'd love your input also. I just finished a prep for bootstrapping gcc 4.6.3 and 4.7.0-RC1 on Solaris 8 sparc and i386 here. One of the initial steps is to ensure we have gmp/mpfr/mpc flawless which I do : . . . PASS: tsub_ui PASS: ttan PASS: ttanh PASS: tui_div PASS: tui_ui_sub GMP: include 5.0.4, lib 5.0.4 MPFR: include 3.1.0, lib 3.1.0 MPC: include 0.9, lib 0.9 PASS: tget_version === All 60 tests passed === gmake[2]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests' gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests' Making check in doc gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc' gmake[1]: Nothing to be done for `check'. gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc' gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001' gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001' $ $ uname -a SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc $ cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 $ psrinfo -v Status of virtual processor 0 as of: 03/02/12 20:25:50 on-line since 04/28/11 17:39:44. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 03/02/12 20:25:50 on-line since 04/28/11 17:39:48. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. $ So I have had no issues with old Solaris 8 and Sparc32 or Sparc 64-bit regardless if it is Sparc64 Fujitsu, Niagara T2 or old UltraSparc II. I know I have to compile for x86_64 on Solaris 10. That is a given. The question on my mind that requires ( or begs ) your input is should I continue to trust the golden rule of the ABI and build, test and release based on Solaris 8? I don't really want to do the same process over and over on Solaris 10 or 11 when I *know* that old Solaris 8 is rock solid stable and the baseline ABI to be used. Your thoughts ? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> On 03/02/2012 08:40 PM, Dennis Clarke wrote: >>>>> If all goes well, I'd like to release 4.7.0 in about three weeks. >>>> >>>> I'll drop it on Solaris. Give it a push. Do we realy really need that >>>> ppl/cloog stuff? I have never seen it build and pass any tests, ever, >>>> even once, on Solaris with or without Sun Studio compilers or GCC or >>>> prayer and geek magic under a full moon. Seriously. >>> >>> Given that PPL is a C++ library, you need to build it with g++ since >>> Studio CC and g++ aren't ABI-compatible. >>> >>> That said, I'm using them in my Solaris GCC bootstraps, although it >>> admittedly took some effort to build initially and using it requires you >>> to jump through hoops to get the configure options right. I agree that >>> this is an incredible mess right now. >> >> I found it too be entirely too much work to be trusted and considered >> stable long term. So therefore I generally kick ppl/cloog to the curb >> and focus on core c,c++ gfortan and ada with objc thrown in without >> the ppl/cloog bits at all. I have been very happy with my results and >> the recent 4.6.3 RC was the most clean and pure results I have seen >> to date, on Solaris 8 old Sparc no less : >> >> http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02786.html > > Hi Dennis, > > I am planning to update graphite to a newer version of CLooG, which does > not rely on PPL (but uses isl, a plain c library). > > Is the C++ issue the only problem on solaris or are there further > problems with CLooG? It would be good to know or test this in advance. > Unfortunately I do not have any solaris machine and there is also none > on the compile farm. Would you mind testing cloog 0.17 [1] and reporting > if 'make check' succeeds. > > Thanks a lot > Tobi > > [1] > http://www.bastoul.net/cloog/pages/download/count.php3?url=./cloog-0.17.0.tar.gz > be happy to test and grant you an account on servers here. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
fine grained control over testsuite
Q: is there a way to prevent a test timing out ? I see a lot of this sort of thing : Running /opt/bw/src/gcc-4.5.3/gcc/testsuite/gcc.c-torture/compile/compile.exp ... WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O1 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/pr46534.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: program timed out. . . . Somewhat annoying as I am in no particular hurry. :-) dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: >> On Wed, 7 Mar 2012, NightStrike wrote: >> >>> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: >>> > >>> > GCC 4.7.0 Release Candidate available from gcc.gnu.org >>> > >>> > The first release candidate for GCC 4.7.0 is available from >>> > >>> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >>> > >>> > and shortly its mirrors. It has been generated from SVN revision 184777. >>> > >>> > I have so far bootstrapped and tested the release candidate on >>> > x86_64-linux. Please test it and report any issues to bugzilla. >>> > >>> > If all goes well, I'd like to release 4.7.0 in about three weeks. >>> >>> >>> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step >>> with the current version of mpfr version 3.1.0, out since last >>> October, and mpc, version 0.9, out since Feb of 2011. I'm guessing >>> the sources moved or something. >>> >>> For instance, just to get the configure step to pass, I had to change >>> the last line of the configure step in the generated Makefile from >>> this: >>> >>> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >>> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >>> --with-mpfr-include=$$s/mpfr >>> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >>> >>> to this: >>> >>> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >>> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >>> --with-mpfr-include=$$s/mpfr/src >>> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >>> >>> >>> The key section is adding /src on the end of >>> --with-mpfr-include=$$s/mpfr/src >>> >>> >>> That gets the build further, but it still doesn't work. >>> >>> This same problem affects 4.6. >> >> The suggested versions of the packages in doc/install.texi are >> older than the ones you tried. >> >> Feel free to propose a patch for trunk, changing the recommended >> versions there. >> >> Richard. > > Ok. But does that mean that to fix configure, we have to increase the > minimum version of mpfr? I have tested builds of gmp/mpfr/mpc on : 1) x86_64-Linux2.6.18-274.17.1.el5 2) x86_64-Linux2.6.32-220.4.1.el6.x86_64 3) sparc-SunOS5.10 4) plus various others ( ppc970 et al ) seen no major problems thus far. Also, gmp,mpfr,mpc all build fine with all tests passed even on a very very old : titan-i386-SunOS5.8 $ uname -X System = SunOS Node = titan Release = 5.8 KernelID = Generic_127722-03 Machine = i86pc BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 titan-i386-SunOS5.8 $ psrinfo -v Status of virtual processor 0 as of: 03/12/12 11:47:00 on-line since 04/28/11 17:39:44. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 03/12/12 11:47:00 on-line since 04/28/11 17:39:48. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. titan-i386-SunOS5.8 $ cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 So I have not seen a gmp mpfr or mpc issue, anywhere. HOWEVER, I do use the very latest revs of mpfr,gmp and mpc. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
strange error during make install of 4.6.3
I was surprised to see this pop up during make install : . . . rm -f /opt/bw/share/info/gcc.info if [ -f doc/gcc.info ]; then \ for f in doc/gcc.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gcc.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gcc.info; \ else true; fi; \ else true; fi; if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I . -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/cppinternals.info ../../gcc-4.6.3/gcc/doc/cppinternals.texi; \ fi rm -f /opt/bw/share/info/cppinternals.info if [ -f doc/cppinternals.info ]; then \ for f in doc/cppinternals.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/cppinternals.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/cppinternals.info; \ else true; fi; \ else true; fi; if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/gccinstall.info ../../gcc-4.6.3/gcc/doc/install.texi; \ fi rm -f /opt/bw/share/info/gccinstall.info if [ -f doc/gccinstall.info ]; then \ for f in doc/gccinstall.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gccinstall.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gccinstall.info; \ else true; fi; \ else true; fi; build/genhooks \ ../../gcc-4.6.3/gcc/doc/tm.texi.in > tmp-tm.texi case `echo X|tr X '\101'` in \ A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ esac mv tmp2-tm.texi tmp-tm.texi /bin/bash ../../gcc-4.6.3/gcc/../move-if-change tmp-tm.texi tm.texi if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I . -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/gccint.info ../../gcc-4.6.3/gcc/doc/gccint.texi; \ fi rm -f /opt/bw/share/info/gccint.info if [ -f doc/gccint.info ]; then \ for f in doc/gccint.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gccint.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gccint.info; \ else true; fi; \ else true; fi; gmake ada/doctools/xgnatugn gmake[3]: Entering directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' mkdir -p ada/doctools cp -p ../../gcc-4.6.3/gcc/ada/xgnatugn.adb ada/doctools cd ada/doctools && gnatmake -q xgnatugn gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile gnatmake: "xgnatugn.adb" compilation error gmake[3]: *** [ada/doctools/xgnatugn] Error 4 gmake[3]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[2]: *** [doc/projects.texi] Error 2 gmake[2]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[1]: *** [install-gcc] Error 2 gmake[1]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386' gmake: *** [install] Error 2 $ Weird. Never saw that on sparc nor anywhere else. There is a pre-existing GCC 4.5.3 as that was the compiler used in stage 1 of the bootstrap. Any thoughts anyone ? dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: strange error during make install of 4.6.3
Also : http://gcc.gnu.org/ml/gcc-help/2010-02/msg00153.html > > I was surprised to see this pop up during make install : >
gcc-4.6.3 ICE
thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html === gcc tests === Running target unix FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler error) I'd like to extend my stack size a bit and re-run the gcc tests only. At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c run again. In detail. What would the procedure for that be ? -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
> On 19 March 2012 14:56, Dennis Clarke wrote: >> >> thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html >> >> === gcc tests === >> >> >> Running target unix >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (internal compiler error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (test for excess errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler >> error) >> >> >> I'd like to extend my stack size a bit and re-run the gcc tests only. >> At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c >> run >> again. In detail. > > The full output of those tests should still be in a .log file > somewhere under the build dir. > >> What would the procedure for that be ? > > See http://gcc.gnu.org/install/test.html and > http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run > specific tests. > > I think you should be able to do something like: > > make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c > Thank you for the quick reply. Hr, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 which is where I see the familiar old friend : titan-i386-SunOS5.8 $ cat ../gcc-4.6.3/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c #define LBR1 ( ( ( ( ( ( ( ( ( ( #define LBR2 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 #define LBR3 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 #define LBR4 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 #define LBR5 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 #define LBR6 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 #define RBR1 ) ) ) ) ) ) ) ) ) ) #define RBR2 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 #define RBR3 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 #define RBR4 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 #define RBR5 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 #define RBR6 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 int q5_var = LBR4 0 RBR4; This really comes down to the users stack size and a ulimit -s X for X=16384 or even 32768 solves it if I recall. I think I may just run the whole testsuite again, there are other pieces of ICE that I'd like to see melt away. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
>> Hr, tried that and didn't get very far probably because the >> srcdir is at ../gcc-4.6.3 > > I don't think that's the problem. > > Maybe you need > make check RUNTESTFLAGS=compile.exp=limits-exprparen.c > or > make check RUNTESTFLAGS=compile.exp=*/limits-exprparen.c > or some other variation on that theme. > Well, too late now, I already incanted make -j 2 -k check and can expect results in a few hours. Thank you for helping. dc
Re: gcc-4.6.3 ICE
>> Thank you for the quick reply. >> OKay, follow up from a few days ago. I ran the testsuite again however with a stack size of 32Mb and now there are no ICE issues. See : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html What I find interesting is why we see an internal compiler error as opposed to something more reasonable when the user stack size is too small. Really, this is not a compiler fault at all but a user environment issue and thus the ICE is a false alarm. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile
I have hit a rather annoying issue during "make install" thus : . . . gmake ada/doctools/xgnatugn gmake[3]: Entering directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' mkdir -p ada/doctools cp -p ../../gcc-4.6.3/gcc/ada/xgnatugn.adb ada/doctools cd ada/doctools && gnatmake -q xgnatugn gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile gnatmake: "xgnatugn.adb" compilation error gmake[3]: *** [ada/doctools/xgnatugn] Error 4 gmake[3]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[2]: *** [doc/projects.texi] Error 2 gmake[2]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[1]: *** [install-gcc] Error 2 gmake[1]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386' gmake: *** [install] Error 2 I'm not sure what the issue really is. This was a nice clean three stage bootstrap build with good test results however install fails as seen above. Any enlightened thoughts would be welcome. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-----+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
go in 4.7.0 seems to fail quite badly
esting/quick FAIL: unicode/utf16 FAIL: unicode/utf8 === libgo Summary === # of expected passes1 # of unexpected failures122 /home/dclarke/build/GCC/gcc-4.7.0-build-pass1/./gcc/gccgo version 4.7.0 (Blastwave.org Inc. Sat Apr 28 14:46:05 UTC 2012) === libgomp tests === Running target unix === libgomp Summary === # of expected passes2950 === libitm tests === Running target unix === libitm Summary === # of expected passes26 # of expected failures 3 # of unsupported tests 1 === libmudflap tests === Running target unix FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test === libmudflap Summary === # of expected passes1435 # of unexpected failures1 === libstdc++ tests === Running target unix === libstdc++ Summary === # of expected passes8178 # of expected failures 43 # of unsupported tests 475 Compiler version: 4.7.0 (Blastwave.org Inc. Sat Apr 28 14:46:05 UTC 2012) Platform: x86_64-unknown-linux-gnu configure flags: --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --with-cpu=k8 --enable-__cxa_atexit --enable-stage1-languages=c --enable-libssp --enable-targets=x86_64-unknown-linux-gnu --with-gc=page --disable-multilib --enable-nls --enable-threads=posix --prefix=/usr/local --enable-shared --libdir=/usr/local/lib --with-system-zlib --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib --with-mpfr-include=/usr/local/include --with-mpfr-lib=/usr/local/lib --with-mpc-include=/usr/local/include --with-mpc-lib=/usr/local/lib --libexecdir=/usr/local/libexec --with-local-prefix=/usr/local/include --with-gxx-include-dir=/usr/local/include --with-pkgversion='Blastwave.org Inc. Sat Apr 28 14:46:05 UTC 2012' --with-bugurl=http://www.blastwave.org/support --enable-languages=c,c++,objc,fortran,go --enable-bootstrap EOF Would love to hear from others that have seen better results. Thank you .. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +---------+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Deprecate 32-bits HP-PA for GCC 4.8?
> Hello, > > GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals > for targets to be deprecated. All 32-bit Sun Microsystems sun4m systems such as the old SPARCstation 20 and 10 units. These are still running out there however Solaris 9 was the last OS to support them. All support for Solaris 9 has dropped into "legacy" mode from Oracle. I think all support for sun4d and sun4c was dropped a long time ago in the GCC project and if not, then they should be. The 64-bit systems such as Sun Ultra 1 upwards still have life in them and they will run either 32-bit Solaris 8 and 9 or 64-bit Solaris 8 and 9. Some people have run Solaris 10 also which is purely a 64-bit kernel. In any case, those are just my thoughts on old legacy Sun gear. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+-------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
the struggle to create a 64-bit gcc on Solaris 10
I have been trying repeatedly and in incrementally more rewarding stages towards building a purely 64-bit GCC compiler on Solaris 10 sparc. I have no need for the 32-bit libs at all and my entire toolchain is 64-bit only. There are no 32-bit libs in /usr/local/lib nor do there need to be. Thus far things have gone well with this approach but I have been using the Oraccle Studio compilers to get to this point. Now I need to get to GCC and then never look back. This has been a struggle as I have needed to hand edit Makefiles over and over and regardless of what I do I end up stopping within stage one of the 3-stage bootstrap with a problem dealing with GMP libs. I have the sources to gmp, mpfr and mpc extracted in the gcc-4.7.2 source directory. No problem there. I have hand edited Makefiles after configure to ensure that ABI=64 in every Makefile that needs it. Thus : $ find . -type f -name Makefile | xargs grep "^ABI" ./gmp/mpq/Makefile:ABI = 64 ./gmp/tune/Makefile:ABI = 64 ./gmp/scanf/Makefile:ABI = 64 ./gmp/mpf/Makefile:ABI = 64 ./gmp/printf/Makefile:ABI = 64 ./gmp/mpn/Makefile:ABI = 64 ./gmp/mpz/Makefile:ABI = 64 ./gmp/cxx/Makefile:ABI = 64 ./gmp/Makefile:ABI = 64 ./gmp/tests/devel/Makefile:ABI = 64 ./gmp/tests/Makefile:ABI = 64 ./gmp/tests/misc/Makefile:ABI = 64 ./gmp/tests/rand/Makefile:ABI = 64 ./gmp/tests/cxx/Makefile:ABI = 64 ./gmp/tests/mpn/Makefile:ABI = 64 ./gmp/tests/mpz/Makefile:ABI = 64 ./gmp/tests/mpf/Makefile:ABI = 64 ./gmp/tests/mpq/Makefile:ABI = 64 ./gmp/tests/mpbsd/Makefile:ABI = 64 ./gmp/mpbsd/Makefile:ABI = 64 ./gmp/demos/calc/Makefile:ABI = 64 ./gmp/demos/Makefile:ABI = 64 ./gmp/demos/expr/Makefile:ABI = 64 ./gmp/doc/Makefile:ABI = 64 After doing this and running gmake I eventually get stopped and see these guys : $ find . -type f | xargs file | grep ELF | grep -v 64 ./gmp/gen-bases: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-psqr: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-fac_ui: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-fib: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-trialdivtab: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped All of which were somehow compiled as 32-bit binaries. No idea where they are coming from and why they did not respect the CFLAGS of "-m64 -mptr64 " which I have hand edited into Makefiles everywhere. As an example : $ diff ./Makefile.backup Makefile 414c414 < STAGE_CFLAGS = $(BOOT_CFLAGS) --- > STAGE_CFLAGS = -m64 -mptr64 -I/usr/local/include:/opt/csw/gcc4/include > $(BOOT_CFLAGS) 417c417 < POSTSTAGE1_CONFIGURE_FLAGS = --enable-build-with-cxx --- > POSTSTAGE1_CONFIGURE_FLAGS = -m64 -mptr64 --enable-build-with-cxx 421,422c421,422 < STAGE1_CFLAGS = $(STAGE_CFLAGS) < STAGE1_CXXFLAGS = $(CXXFLAGS) --- > STAGE1_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE1_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 424,425c424,425 < STAGE1_CXXFLAGS = $(STAGE1_CFLAGS) < STAGE1_TFLAGS = $(STAGE_TFLAGS) --- > STAGE1_CXXFLAGS = -m64 -mptr64 $(STAGE1_CFLAGS) > STAGE1_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 432,433c432,433 < STAGE2_CFLAGS = $(STAGE_CFLAGS) < STAGE2_CXXFLAGS = $(CXXFLAGS) --- > STAGE2_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE2_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 435c435 < STAGE2_CXXFLAGS = $(STAGE2_CFLAGS) --- > STAGE2_CXXFLAGS = -m64 -mptr64 $(STAGE2_CFLAGS) 443,444c443,444 < STAGE3_CFLAGS = $(STAGE_CFLAGS) < STAGE3_CXXFLAGS = $(CXXFLAGS) --- > STAGE3_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE3_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 446,447c446,447 < STAGE3_CXXFLAGS = $(STAGE3_CFLAGS) < STAGE3_TFLAGS = $(STAGE_TFLAGS) --- > STAGE3_CXXFLAGS = -m64 -mptr64 $(STAGE3_CFLAGS) > STAGE3_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 454,455c454,455 < STAGE4_CFLAGS = $(STAGE_CFLAGS) < STAGE4_CXXFLAGS = $(CXXFLAGS) --- > STAGE4_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE4_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 457,458c457,458 < STAGE4_CXXFLAGS = $(STAGE4_CFLAGS) < STAGE4_TFLAGS = $(STAGE_TFLAGS) --- > STAGE4_CXXFLAGS = -m64 -mptr64 $(STAGE4_CFLAGS) > STAGE4_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 493c493 < STAGE1_CFLAGS = -g -fkeep-inline-functions --- > STAGE1_CFLAGS = -m64 -mptr64 -g -fkeep-inline-functions A bit messy I know. However this is pass 1 with hopes that by the third time I do this it will be a fine art. Any pointers at all as to the error of my ways ? Dennis ps: I am using gcc 4.5.1 to perform the bootstrap and this release has been very well tested : $ which gcc /opt/csw/gcc4/bin/gcc $ $ $CC --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Re: the struggle to create a 64-bit gcc on Solaris 10
> > Any pointers at all as to the error of my ways ? > > http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 nope. Been there .. done that and that fails badly .. in fact worse than before : Configure .. look good but lies : $ ../gcc-4.7.2/configure --build=sparc64-sun-solaris2.10 --target=sparc64-sun-solaris2.10 \ > --with-as=/usr/ccs/bin/as --without-gnu-ld \ > --with-ld=/usr/ccs/bin/ld --disable-multilib --enable-nls \ > --enable-threads=posix --prefix=/usr/local/gcc4 --enable-shared \ > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > --libexecdir=/usr/local/gcc4/lib > --with-gxx-include-dir=/usr/local/gcc4/include \ > --with-pkgversion=Blastwave.org\ Inc.\ Fri\ Nov\ \ 9\ 21\:55\:41\ UTC\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... /opt/csw/gcc4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/csw/gcc4/bin/gcc accepts -g... yes checking for /opt/csw/gcc4/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /opt/csw/gcc4/bin/g++ accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for sparc64-sun-solaris2.10-cc... no checking for cc... cc checking for sparc64-sun-solaris2.10-c++... no checking for c++... c++ checking for sparc64-sun-solaris2.10-gcc... no checking for gcc... gcc checking for sparc64-sun-solaris2.10-gcj... no checking for gcj... no checking for sparc64-sun-solaris2.10-gfortran... no checking for gfortran... gfortran checking for sparc64-sun-solaris2.10-gccgo... no checking for gccgo... no checking for ar... no checking for sparc64-sun-solaris2.10-ar... no checking for ar... ar checking for as... no checking for sparc64-sun-solaris2.10-as... no checking for as... as checking for dlltool... no checking for sparc64-sun-solaris2.10-dlltool... no checking for dlltool... no checking for ld... no checking for sparc64-sun-solaris2.10-ld... no checking for ld... ld checking for lipo... no checking for sparc64-sun-solaris2.10-lipo... no checking for lipo... no checking for nm... no checking for sparc64-sun-solaris2.10-nm... no checking for nm... nm checking for objdump... no checking for sparc64-sun-solaris2.10-objdump... no checking for objdump... no checking for ranlib... no checking for sparc64-sun-solaris2.10-ranlib... no checking for ranlib... ranlib checking for readelf... no checking for sparc64-sun-solaris2.10-readelf... no checking for readelf... no checking for strip... no checking for sparc64-sun-solaris2.10-strip... no checking for strip... strip checking for windres... no checking for sparc64-sun-solaris2.10-windres... no checking for windres... no checking for windmc... no checking for sparc64-sun-solaris2.10-windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... j
Re: the struggle to create a 64-bit gcc on Solaris 10
> > nope. Been there .. done that and that fails badly .. in fact worse > than > > before : > > Yet this is the standard way and works flawlessly if done correctly... I can not see my error here and am wondering what the issue is. > > However I am way way open to suggestion here. > > You need to configure everything with --build=sparc64-sun-solaris2.10 > and > compile everything with a 64-bit compiler, i.e. all compilers ever > invoked > must generate 64-bit code *by default*. This can mean setting CC and > CXX to > appropriate values, e.g. "gcc -m64" and "g++ -m64" or the Sun equivalent. I am using gcc and g++ here. So, in any case .. looks like I am back to square zero. Thanks for the input. dc
Re: the struggle to create a 64-bit gcc on Solaris 10
> Eric wrote: > > > Any pointers at all as to the error of my ways ? > > > > http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 > You're up against three factors here. First, the sparc64 platform ABI > specifies 32-bit executables unless the user specifically asks for > 64-bit. I'm really unclear on why you think that's a bad thing (spacv9 It isn't. In fact, it has never been a problem for me in the past. Furthermore I have been doingbuilds of GCC on Solaris for a long long time now. Decade. Maybe more. Can't recall to be honest. Usually I have no problem and like to post my results. See solaris 8 results at http://gcc.gnu.org/gcc-4.7/buildstat.html However, Solaris 8 was the old gold standard. anything that built there, ran everywhere in the Solaris world. At least for anything in the last ten years. Consider the compiler I am using here : $ ls -lap $CC -rwxr-xr-x 1 root bin 640388 Aug 11 2010 /opt/csw/gcc4/bin/gcc $ file /opt/csw/gcc4/bin/gcc /opt/csw/gcc4/bin/gcc: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ elfdump -vd $CC Version Needed Section: .SUNW_version fileversion libc.so.1 SUNW_1.18.1 Dynamic Section: .dynamic index tagvalue [0] NEEDED0x2973 libc.so.1 [1] INIT 0x36150 [2] FINI 0x3616c [3] RUNPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [4] RPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [5] HASH 0x100e8 [6] STRTAB0x13ce0 [7] STRSZ 0x29d9 [8] SYMTAB0x114f0 [9] SYMENT0x10 [10] CHECKSUM 0x88ef [11] VERNEED 0x166bc [12] VERNEEDNUM0x1 [13] PLTRELSZ 0x48c [14] PLTREL0x7 [15] JMPREL0x16730 [16] RELA 0x166dc [17] RELASZ0x4e0 [18] RELAENT 0xc [19] DEBUG 0 [20] FEATURE_1 0x1 [ PARINIT ] [21] FLAGS 0 0 [22] FLAGS_1 0 0 [23] PLTGOT0x63544 [24] NULL 0 $ See that version need section in the output binary gcc ? To me this compiler works just fine and has for a few years now. It is really well tested and was released a while back. Note, however, the version needed for libc.so.1. See that SUNW_1.18.1 ? Well to someone in the know, that is a dead give away that this was compiled on Solaris 8. That version "NEEDED" was released quite a while ago. If you had a baseline version of Solaris 8 and then patched it up to date you would have a libc no higher than 1.18.1 or maybe 1.19. This means the resultant binaries created on that platform are assured to have access to the system calls and baseline functions provided in all libraries that follow in Solaris 9 and 10 and even Solaris 11. Let's take a look at the libc in Solaris 10 : $ ls -lapb /lib/libc.so.1 -rwxr-xr-x 1 root bin 1653368 Aug 21 17:34 /lib/libc.so.1 $ elfdump -vd /lib/libc.so.1 Version Definition Section: .SUNW_version index version dependency [1] libc.so.1[ BASE ] [2] SUNW_1.23 SUNW_1.22.7 [3] SUNW_1.22.7 SUNW_1.22.6 [4] SUNW_1.22.6 SUNW_1.22.5 [5] SUNW_1.22.5 SUNW_1.22.4 [6] SUNW_1.22.4 SUNW_1.22.3 [7] SUNW_1.22.3 SUNW_1.22.2 [8] SUNW_1.22.2 SUNW_1.22.1 [9] SUNW_1.22.1 SUNW_1.22 [10] SUNW_1.22 SUNW_1.21.3 [11] SUNW_1.21.3 SUNW_1.21.2 [12] SUNW_1.21.2 SUNW_1.21.1 [13] SUNW_1.21.1 SUNW_1.21 [14] SUNW_1.21 SUNW_1.20.4 [15] SUNW_1.20.4 SUNW_1.20.1 [16] SUNW_1.20.1 SUNW_1.20 [17] SUNW_1.20 SUNW_1.19 [18] SUNW_1.19 SUNW_1.18.1 [19] SUNW_1.18.1 SUNW_1.18
Re: the struggle to create a 64-bit gcc on Solaris 10
> > The last (very annoying) issue is that when gcc bootstraps itself, the
> > freshly-built compiler doesn't generate 64-bit binaries by default.
> > BOOT_CFLAGS can work around that: http://gcc.gnu.org/install/build.html.
>
> That isn't true at all.
>
> > CC='cc -m64' CXX='CC -m64' ../gmp-5.0.1-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared
> > CC='cc -m64' CXX='CC -m64' ../mpfr-3.1.1-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared --with-gmp=$HOME/apps/gcc-4.7.2
> > CC='cc -m64' CXX='CC -m64' ../mpc-0.8.2-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared --with-{gmp,mpfr}=$HOME/apps/gcc-4.7.2
> > CC='cc -m64' CXX='CC -m64' ../gcc-4.7.2-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-multilib --with-{gmp,mpfr,mpc}=$HOME/apps/gcc-4.7.2
> > --without-gnu-{as,ld}
> > make {CFLAGS_FOR_TARGET,BOOT_CFLAGS}='-m64 -O2'
>
> No, don't mess with CFLAGS_FOR_TARGET or BOOT_CFLAGS, just type 'make'.
I would have to edit that as I use gcc to bootstrap gcc. Hoever, I am very
willing to give your method a try. However, my prediction is that Oracle
Studio 12.3 will have a fit .. early.
Dennis
Re: the struggle to create a 64-bit gcc on Solaris 10
> > The last (very annoying) issue is that when gcc bootstraps itself, the > > freshly-built compiler doesn't generate 64-bit binaries by default. > > BOOT_CFLAGS can work around that: http://gcc.gnu.org/install/build.html. > > That isn't true at all. okay .. I'll just nod my head and agree. > > CC='cc -m64' CXX='CC -m64' ../gmp-5.0.1-src/configure > > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10 > > --disable-shared What isn't clear is where that is run. I decided that I will take your approach and try to follow the magic incantations to the very letter. OKay, sort of. I may expand on the CFLAGS just a little bit and I have to assume, in the absence of any data, that I shall run these "config ; make; make check" incantations inside the GCC build dir. After all, I already have gmp/mpfr/mpc built, tested and installed therefore I have to assume this is a way to avoid needing them in the gcc source tree. Here is what I did with gmp : $ ls $SRC/gmp* /usr/local/src/gmp-5.0.5.tar.bz2 $ /opt/schily/bin/star -x -bz -xdir -xdot -U -fs=16m file=/usr/local/src/gmp-5.0.5.tar.bz2 star: 1262 blocks + 0 bytes (total of 12922880 bytes = 12620.00k). $ mv gmp-5.0.5 gmp-5.0.5_SunOS5.10_sparcv9-for-gcc-4.7.2 $ mkdir gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou $ cd gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou So now that I am in the gcc build dir ( named after you actually ) I do this : $ CC='gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO' \ > CXX='g++ -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS > -D_LARGEFILE64_SOURCE -D_TS_ERRNO' \ > ../gmp-5.0.5_SunOS5.10_sparcv9-for-gcc-4.7.2/configure ABI=64 --enable-cxx > --prefix=/usr/local/gcc4 \ > --libdir=/usr/local/gcc4/lib --build=sparc64-sun-solaris2.10 checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gmp-5.0.5_SunOS5.10_sparcv9-for-gcc-4.7.2/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ../gmp-5.0.5_SunOS5.10_sparcv9-for-gcc-4.7.2/install-sh -c -d checking for gawk... gawk checking whether /usr/local/bin/gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking compiler gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/include:/opt/csw/gcc4/include... yes checking compiler gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO has sizeof(long)==8... yes checking for gcc... gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO accepts -g... yes checking for gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO option to accept ISO C89... none needed checking for gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO option to accept ISO C99... -std=gnu99 checking for gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking how to run the C preprocessor... gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -std=gnu99 -E checking build system compiler gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -std=gnu99... yes checking for build system preprocessor... gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -std=gnu99 -E checking for build system executable suffix... checking whether build system compiler is ANSI... yes checking for build system compiler math library... -lm checking whether we are using the GNU C++ compiler... yes checking whether g++ -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO accepts -g... yes checking C++ compiler g++ -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/include:/opt/csw/gcc4/include -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PT
