--- Comment #9 from rob1weld at aol dot com 2009-01-20 13:54 ---
I was checking my Testsuite Results for UNSUPPORTED tests and arrived here.
I thought I would try the code on i386-pc-solaris2.11 with gcc version 4.4.0 .
When booted 32-bit and using -m64:
# gcc -O2 -m64 -fPIC test.c
--- Comment #1 from rob1weld at aol dot com 2009-01-20 15:48 ---
The Environment Variable GCC_EXEC_PREFIX _existed_ since long ago:
http://www.cygwin.com/ml/cygwin/1998-11/msg00777.html but I'm still
looking for the first occurrence of the actual Bug itself.
On Platform i686-pc-linux
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *-*-solaris2*
GCC host triplet: *-*-solaris2*
GCC target triplet: *-*-solaris2*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924
--- Comment #1 from rob1weld at aol dot com 2009-01-22 01:47 ---
With that dropped in gcc seems to build and test correctly. It _might_ be
that gcc builds Faster and uses Less memory during the two peaks in libjava
after this patch, more testing required.
Rob
--
http
--- Comment #9 from rob1weld at aol dot com 2009-01-22 01:51 ---
Confirmed, trunk, i386-pc-solaris2.11 - the gcc.log is:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/pch/common-1.c:3: internal
compiler error: in ggc_record_overhead, at ggc-common.c:873
/usr/share/src/gcc_trunk/gcc
--- Comment #1 from rob1weld at aol dot com 2009-01-22 02:24 ---
One we get to gcc version 4.4.0 20090121 (experimental) [trunk revision 143538]
this no longer occurs. Closing FIXED.
Rob
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #7 from rob1weld at aol dot com 2009-01-22 14:50 ---
Self Confirmed. Attempting to execute 64 bit code when booted 32 bit:
# gmake
...
/bin/sh ./libtool --tag=GCJ --mode=link /usr/share/src/gcc_build/gcc/gcj
-B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/
-B
--- Comment #8 from rob1weld at aol dot com 2009-01-22 15:12 ---
Applying gcc_trunk/gcc/config/sol2.h hack from this post:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38924
That is confirmed to workaround the problem but not fix it. Afterwards
it makes Bug 38728 by _far_ much worse
--- Comment #9 from rob1weld at aol dot com 2009-01-22 16:03 ---
Created an attachment (id=17162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17162action=view)
Screenshot of build shows libgcj_tools building (after patch from 38924)
Description of the Screenshot:
At the far
--- Comment #3 from rob1weld at aol dot com 2009-01-23 12:25 ---
From: Ben Elliston b...@air.net.au
To: rob1w...@aol.com
Sent: Thu, 22 Jan 2009 8:12 pm
Subject: Re: Patch for config.guess
Hi Rob,
Thanks for your report.
The script config.guess lumps together many of Sun's
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet
--- Comment #1 from rob1weld at aol dot com 2009-01-23 22:31 ---
The adding of these assertions to replace an error message might have been
first discussed here: http://gcc.gnu.org/ml/java-patches/2007-q1/msg00478.html
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38967
--- Comment #2 from rob1weld at aol dot com 2009-01-25 16:59 ---
(In reply to comment #1)
(In reply to comment #0)
=== gfortran tests ===
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
...
Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type
--- Comment #3 from rob1weld at aol dot com 2009-01-25 17:35 ---
# ./e_d_fmt.exe
Abort (core dumped)
# ldd ./e_d_fmt.exe
libgfortran.so.3 =
/usr/share/src/gcc_build/i386-pc-solaris2.11/./libgfortran/.libs/libgfortran.so.3
libm.so.2 = /usr/lib/libm.so.2
--- Comment #1 from rob1weld at aol dot com 2009-01-26 02:40 ---
This might become more important when you build gcc with cloog and without ppl
.
Note: A major upcoming improvement is the support of multiple backends,
not only PolyLib. CLooG will support PPL and already supports
(and our other problems with the cloog trunk)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
--- Comment #2 from rob1weld at aol dot com 2009-01-26 12:36 ---
I was just going to post this and got a mid-air:
It is possible (and would be unfortunate) that gcc will only build with
a 'special edition' cloog-ppl from: ftp://gcc.gnu.org/pub/gcc/infrastructure/ .
Thanks, if you can
--- Comment #2 from rob1weld at aol dot com 2009-01-27 15:13 ---
Same issue on Fedora 10
# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable
--- Comment #1 from rob1weld at aol dot com 2009-01-27 15:18 ---
Running trunk revision 143680 on Fedora 10 I get:
# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c
--- Comment #3 from rob1weld at aol dot com 2009-01-27 15:38 ---
(In reply to comment #2)
It's not a bug that GCC EXEC_PREFIX is defined when the testsuite is run, as
explained in these patches:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html
http://gcc.gnu.org/ml/gcc
--- Comment #6 from rob1weld at aol dot com 2009-01-27 15:50 ---
Here is a newer result on Fedora 10:
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes29107
# of expected failures 14
--- Comment #7 from rob1weld at aol dot com 2009-01-27 16:00 ---
(In reply to comment #5)
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685
Looks like this testcase should be xfailed on solaris also
--- Comment #8 from rob1weld at aol dot com 2009-01-27 16:18 ---
(In reply to comment #4)
(In reply to comment #3)
This is not so much an error in Fortran than it is an error in the
scripting and it's ability to add it's own LD_LIBRARY_PATH components.
No. The current linking
--- Comment #2 from rob1weld at aol dot com 2009-01-27 16:26 ---
(In reply to comment #1)
With that dropped in gcc seems to build and test correctly. It _might_ be
that gcc builds Faster and uses Less memory during the two peaks in libjava
after this patch, more testing required
--- Comment #1 from rob1weld at aol dot com 2009-01-27 16:30 ---
On Fedora 10 (i386-redhat-linux) trunk revision 143680 using:
# iconv --version
iconv (GNU libc) 2.9
# iconv -l | grep IBM1047
IBM1047//
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38910
--- Comment #1 from rob1weld at aol dot com 2009-01-27 17:00 ---
Trunk revision 143680 works on Fedora 10:
# gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable
--- Comment #36 from rob1weld at aol dot com 2009-01-27 21:12 ---
(In reply to comment #33)
*** Bug 38820 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
If I have an old gcc 4.4 installed on my machine, will setting
GCC_EXEC_PREFIX use the old installed gcc
--- Comment #37 from rob1weld at aol dot com 2009-01-27 21:26 ---
(In reply to comment #20)
(In reply to comment #19)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
hjl dot tools at gmail dot com wrote:
They sound to me the ideal usage
--- Comment #38 from rob1weld at aol dot com 2009-01-27 21:32 ---
Clearly, it is wrong:
# locate crtprec80.o
/mnt/drive2/gcc_build/gcc/crtprec80.o
/mnt/drive2/gcc_build/i386-redhat-linux/libgcc/crtprec80.o
/mnt/drive2/gcc_build/prev-gcc/crtprec80.o
/mnt/drive2/gcc_build/prev-i386
--- Comment #10 from rob1weld at aol dot com 2009-01-27 22:28 ---
(In reply to comment #1)
Note that some of the tests require specific features (such as denormalized
long doubles) and are ...
(In reply to comment #4)
(In reply to comment #3)
This is not so much an error in Fortran
--- Comment #11 from rob1weld at aol dot com 2009-01-27 22:45 ---
(In reply to comment #9)
Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to
silence
--- Comment #12 from rob1weld at aol dot com 2009-01-27 23:26 ---
(In reply to comment #11)
(In reply to comment #9)
Two alternatives are:
I guess there is three.
3. The gcc Testsuite is testing 'outside of gcc' and exercising the
libraries of the Operating System (maybe GNU libc
--- Comment #7 from rob1weld at aol dot com 2009-01-27 23:33 ---
Added Known to work 4.4.0 (gcc version 4.4.0 20090126 (experimental) [trunk
revision 143680]).
Tested on OpenSolaris 2008.11 i386-pc-solaris2.11 and Fedora 10
i386-redhat-linux-gnu .
Rob
--
rob1weld at aol dot com
--- Comment #13 from rob1weld at aol dot com 2009-01-27 23:47 ---
This post: http://gcc.gnu.org/ml/gcc/2008-12/msg00135.html says:
To get on the radar regressions have to be marked [4.4 Regression],
with the target milestone set to 4.4.0 ...
Changing Summary from / to:
[trunk
--- Comment #39 from rob1weld at aol dot com 2009-01-28 03:08 ---
H.J. Lu,
This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435#c25 ) requests
that Bug Report be modified restore to P3 if it affects non-Ada testsuites
or any case where the compiler exports GCC_EXEC_PREFIX
--- Comment #12 from rob1weld at aol dot com 2009-01-28 03:54 ---
On the Trunk using -O2 or -O3 can produce slower code.
I built gcc version 4.4.0 20090126 [trunk revision 143680] for
i386-redhat-linux
and was dismayed to find that libmudflaps had a few FAILs:
Results for 4.4.0
--- Comment #20 from rob1weld at aol dot com 2009-01-28 06:23 ---
(In reply to comment #17)
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
It's very clear to me by now that HOST_WIDE_INT should only depend
--- Comment #40 from rob1weld at aol dot com 2009-01-28 13:52 ---
Notes from 38820: I had Known to fail set to 4.4.0 4.3.2
Another 'proof' this is a Bug.
You are allowed to build GCC after you set (reasonable) Environment
variables. Examples are:
export set CC=gcc -v
export set CC=gcc
--- Comment #14 from rob1weld at aol dot com 2009-01-29 12:32 ---
(In reply to comment #5)
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685
Looks like this testcase should be xfailed on solaris also
--- Comment #41 from rob1weld at aol dot com 2009-01-29 15:01 ---
(In reply to comment #35)
In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
compiler being tested in the build directory is invoked with -B.
GCC_EXEC_PREFIX will only be used to find files
--- Comment #44 from rob1weld at aol dot com 2009-01-29 23:12 ---
(In reply to comment #43)
Rob, your various assertions do not show that there is a bug here. ...
...
I built GCC from 20090106, broke a couple of thing affecting cc1, float.h, and
libgcc.a, and installed it. Then I
--- Comment #15 from rob1weld at aol dot com 2009-01-30 03:24 ---
(In reply to comment #9)
Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to
silence one
--- Comment #3 from rob1weld at aol dot com 2009-01-30 04:31 ---
The building of Language Java is broken on (at least) two platforms.
Checking http://gcc.gnu.org/ml/gcc-testresults/2009-01/ it seems to
work on some other platforms. I'll investigate if it is my ./configure .
Rob
--- Comment #4 from rob1weld at aol dot com 2009-01-31 14:34 ---
Building trunk revision 143817 on i386-pc-solaris2.11 works, with fewer
options:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran
--- Comment #2 from rob1weld at aol dot com 2009-01-31 15:17 ---
Occurs in trunk revision 143660:
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/boehm-gc'
GC_push_all_stacks: sp not set!
/bin/sh: line 9: 28147: Abort(coredump)
FAIL: gctest
in libgcc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc
--- Comment #7 from rob1weld at aol dot com 2009-01-31 20:25 ---
Here is a GENERAL_REGS error for the Trunk.
# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--- Comment #8 from rob1weld at aol dot com 2009-01-31 21:01 ---
Sometimes you can skirt around the GENERAL_REGS error with other options.
When I use -O0, -O1, -O2, -O3, -Os I get different results.
Using -O0 produces no screen output _or_ compiled file (thus it 'looks'
as though
--- Comment #45 from rob1weld at aol dot com 2009-01-31 22:13 ---
Here is another attempt using gcc version 4.4.0 20090128 (experimental) [trunk
revision 143729] to compile gcc version 4.4.0 20090131 (experimental) [trunk
revision 143817].
I have an Athlon X2 running OpenSolaris in 32
--- Comment #9 from rob1weld at aol dot com 2009-02-01 00:49 ---
It can be compiled with ONE earlier version of gcc but not another - so this is
a regression.
Works on 4.0.2:
# /opt/csw/gcc4/bin/gcc -v
Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs
Target
--- Comment #2 from rob1weld at aol dot com 2009-02-05 03:43 ---
(In reply to comment #1)
You can use following (slightly wrapped...) patch to enable 128bit soft-fp on
Solaris:
Thanks, I'll try that this week (working on a P1).
Please read the ChangeLog:
../gcc_trunk/ChangeLog
--- Comment #47 from rob1weld at aol dot com 2009-02-05 04:06 ---
(In reply to comment #46)
As I understand it, the complaint here is that GCC_EXEC_PREFIX being set
affects HOSTCC, when HOSTCC is itself some other GCC. ...
It is true (for most of us in this thread
: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from rob1weld at aol dot com 2009-02-05 18:36 ---
Correction (not careful enough with the cut-and-pasting):
The BUG is this:
If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc
Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK
--- Comment #2 from rob1weld at aol dot com 2009-02-06 02:15 ---
There really is some trouble with the scripts in this area.
As you might expect simply restarting the make simply repeats the
trouble, shows the same errors and ends the build.
If you restart the build with gmake -i -k
--- Comment #3 from rob1weld at aol dot com 2009-02-06 13:19 ---
Despite all the problems Ada passes _all_ of it's Testsuite:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111
--- Comment #3 from rob1weld at aol dot com 2009-02-06 14:11 ---
I tossed in that patch and it cause gcc's build to fail here:
../../../gcc_trunk/libgcc/../gcc/config/soft-fp/floatditf.c:35: warning: no
previous prototype for '__floatditf'
/usr/share/src/gcc_build/./gcc/xgcc -B/usr
--- Comment #4 from rob1weld at aol dot com 2009-02-06 14:40 ---
Do we support TImode arithmetic on many platforms?, See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19493
I am booted in 32-bit mode (and building multilib).
Rob
--- Comment #7 from rob1weld at aol dot com 2009-02-06 22:29 ---
(In reply to comment #6)
(In reply to comment #4)
Do we support TImode arithmetic on many platforms?, ...
I am booted in 32-bit mode (and building multilib).
32bit i386 doesn't support TImode.
TImode soft-fp
--- Comment #8 from rob1weld at aol dot com 2009-02-07 04:21 ---
Here is: gcc 4.4.0 20090206 [trunk revision 143992] ./configured with:
../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static --enable-multilib --enable-decimal
--- Comment #3 from rob1weld at aol dot com 2009-02-07 05:24 ---
Works using: gcc version 4.4.0 20090204 [trunk revision 143918] when
./configured to use Sun's Linker:
../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static
--- Comment #2 from rob1weld at aol dot com 2009-02-07 05:37 ---
The 'build logic' was altered between revisions 143918 and 143984.
In gcc 4.4.0 20090204 trunk revision 143918 we have this:
# ggrep contrib/aotcompile.py made_17_log.txt
made_17e_log.txt:config.status: creating contrib
--- Comment #52 from rob1weld at aol dot com 2009-02-07 06:00 ---
(In reply to comment #48)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
rob1weld at aol dot com wrote:
One example is inherently derived from where we see it being set (wrongly
--- Comment #4 from rob1weld at aol dot com 2009-02-07 11:04 ---
(In reply to comment #3)
Despite all the problems Ada passes _all_ of it's Testsuite:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html
My Testsuite Submission bounced, please view these results instead:
http
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39125
--- Comment #14 from rob1weld at aol dot com 2009-02-07 16:18 ---
(In reply to comment #8)
Created an attachment (id=17173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17173action=view) [edit]
An extracted test case for this bug.
Hi tim, I extracted this test case from your
--- Comment #2 from rob1weld at aol dot com 2009-02-09 13:50 ---
I tried to lower the Priority but I can not alter my own Bug Reports.
(In reply to comment #1)
Subject: Re: New: trunk revision 143992 - Too many Testsuite
FAILs = email 400K = bounce
On Sat, 7 Feb 2009, rob1weld
--- Comment #1 from rob1weld at aol dot com 2009-02-11 20:54 ---
A workaround is to ./configure using --without-ppl which will cause
ppllibs to create an empty variable in the Makefiles. The output from
the initial configuring will look the same, but this Bug will be avoided.
I'm going
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from rob1weld at aol dot com 2009-02-12 13:36 ---
(In reply to comment #1)
How is this major, this is an enhancement to the build system. i386-solaris
is
a multi arch target so it includes the x86_64 solaris target also.
It could be called an enhancement
--- Comment #9 from rob1weld at aol dot com 2009-02-12 13:44 ---
(In reply to comment #8)
...
This patch is tested for i386-pc-solaris2.11 (OpenSolaris 2008.11 snv_101b)
when booted in 32-bit mode (on VirtualBox, on WinXP) using gcc revision 143992
using Sun's Linker (and GNU
directions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc
--- Comment #3 from rob1weld at aol dot com 2009-02-13 08:36 ---
Here is another person who makes the same complaint (with a patch):
http://hackage.haskell.org/trac/ghc/ticket/2951
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
--- Comment #4 from rob1weld at aol dot com 2009-02-13 09:11 ---
Googling for amd64-pc-solaris2.11 gives a few hits.
Googling for x86_64-pc-solaris2.11 gives a dozen hits.
That is not many. Perhaps there is 'no such word'.
It seems there are a few others who discovered this problem
--- Comment #8 from rob1weld at aol dot com 2009-02-13 15:55 ---
In revision 144149 we have this:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=i386-pc-solaris2.11
--enable-languages=ada,c,c
dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
--- Comment #2 from rob1weld at aol dot com 2009-02-14 01:19 ---
A quick hack in ../gcc_trunk/libgcc/configure (line 2065) to
add -m64 to the 'ac_compile' and 'ac_link' lines will allow
the build to proceed through libgcc to libgcov where it then
fails due to an issue unrelated
--- Comment #3 from rob1weld at aol dot com 2009-02-14 02:06 ---
The next issue is here:
../gcc_trunk/gcc/unwind-dw2.c and ../gcc_trunk/gcc/unwind-dw2-fde.c, etc ...
../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:44:21: error: pthread.h: No
such file or directory
--- Comment #4 from rob1weld at aol dot com 2009-02-14 02:08 ---
Correction, should have said:
-Thus, I conclude that the -m32 for
+Thus, I conclude that the -m64 for
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
--- Comment #5 from rob1weld at aol dot com 2009-02-14 02:48 ---
I forced that 32 bit and continued, failing here:
T=`${PWDCMD-pwd}`/ \
cd ../../.././gcc \
gmake GCC_FOR_TARGET=/usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11
--- Comment #6 from rob1weld at aol dot com 2009-02-14 03:39 ---
I wonder if I discovered a regression ...
If I compile with gcc version 4.4.0 20090213 (experimental) [trunk revision
144149] it produces a little of 32-bit code that is not going to get
compiled with all the -m64
--- Comment #7 from rob1weld at aol dot com 2009-02-14 04:17 ---
I grepped for CRT_GET_RFIB_DATA and found a definition at the tail of:
/usr/share/src/gcc_trunk/gcc/config/frv/frv.h .
Here is ../gcc_trunk/gcc/crtstuff.c :
static void __attribute__((used))
frame_dummy (void
--- Comment #8 from rob1weld at aol dot com 2009-02-14 04:36 ---
(In reply to comment #7)
...
Slowly I inch forward ...
and go back ...
/usr/local/bin/ld: /usr/share/src/gcc_build/./gcc/amd64/crtbegin.o: relocation
R_X86_64_32 against `__DTOR_END__' can not be used when making
: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *
GCC host triplet: *
GCC target triplet: *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39190
--- Comment #9 from rob1weld at aol dot com 2009-02-14 14:36 ---
The Beast raises it's head (just C only):
# x86_64-pc-solaris2.11-gcc -v
Using built-in specs.
Target: x86_64-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=x86_64-pc
--- Comment #9 from rob1weld at aol dot com 2009-02-14 17:28 ---
(In reply to comment #8)
Subject: Bug 31868
Author: hjl
Date: Sun Feb 10 22:25:24 2008
New Revision: 13
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=13
Log: 2008-02-10 H.J. Lu hongjiu...@intel.com
--- Comment #10 from rob1weld at aol dot com 2009-02-15 08:40 ---
Getting this working depended on re-fixing this Bug that is closed
(for other x86_64-* Targets) but affects this new Target:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
The Testsuite Results (NOT mailed) show
--- Comment #4 from rob1weld at aol dot com 2009-02-15 20:09 ---
(In reply to comment #2)
This sounds like you should be using $CONFIG_SHELL when invoking
contrib/test_summary . Not really a bug with the script since it works with a
real POSIX sh. Sun should get their head out
--- Comment #1 from rob1weld at aol dot com 2009-02-15 21:05 ---
I have ./configured thusly:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c
--- Comment #5 from rob1weld at aol dot com 2009-02-16 13:11 ---
Results for 4.4.0 20090215 (experimental) [trunk revision 144190] (GCC)
testsuite on x86_64-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #11 from rob1weld at aol dot com 2009-02-16 13:12 ---
Results for 4.4.0 20090215 (experimental) [trunk revision 144190] (GCC)
testsuite on x86_64-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01526.html
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #1 from rob1weld at aol dot com 2009-02-17 05:11 ---
This does not occur with:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215
Version: 4.4.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc
--- Comment #1 from rob1weld at aol dot com 2009-02-19 02:21 ---
New warning different GCC executable was just 'xgcc' instead of 'g++'.
Next error in 'extc++.h.gch/O2g.gch' is fixed by:
/usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc
-B/usr/share/src/gcc_build/./gcc -nostdinc++
-L
--- Comment #2 from rob1weld at aol dot com 2009-02-19 02:30 ---
That worked.
The build continues until it fails here:
# gmake
(5 minutes)
...
Making all in src
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src'
...
-DPIC -o .libs
--- Comment #3 from rob1weld at aol dot com 2009-02-19 02:36 ---
Even though I ./configured using --with-gnu-ld --with-ld=/usr/local/bin/ld
the scripts seemed to have decided to use the gcc-used-for-build's choice
of 'ld' instead of the main ./configure scripts settings ...
# gcc -v
--- Comment #2 from rob1weld at aol dot com 2009-02-19 05:09 ---
I don't know why it did NOT occur in revision 144203 but it re-occurs with:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4
--enable
201 - 300 of 623 matches
Mail list logo
