--- Comment #4 from rob1weld at aol dot com 2009-01-06 03:01 ---
(In reply to comment #3)
And this is documented in the installation documentation.
(Confusion may also result if the compiler finds the GNU assembler but has
not
been configured with --with-gnu-as.)
http
--- Comment #3 from rob1weld at aol dot com 2009-01-06 03:05 ---
Thanks for fixing.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38727
--- Comment #2 from rob1weld at aol dot com 2009-01-06 03:10 ---
(In reply to comment #1)
Do you have virtual memory turned on because it sounds like you don't.
I do have it turned on. This OS uses a swap file that is by default 50%
of the size of the RAM. I installed on a 1024M
--- Comment #2 from rob1weld at aol dot com 2009-01-06 03:22 ---
(In reply to comment #1)
Final results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00488.html
The other testsuites did _surprisingly_ well, even libmudflaps (new!).
Rob
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from rob1weld at aol dot com 2009-01-06 03:39 ---
(In reply to comment #1)
Can you try 4.3.2?
Same in the trunk (4.4.0 20090104):
# ls -l /usr/local/lib/amd64/gcj-4.4.0-10/ /usr/local/lib/gcj-4.4.0-10/
/usr/local/lib/amd64/gcj-4.4.0-10/:
total 18
-rw-r--r-- 1 root root
--- Comment #4 from rob1weld at aol dot com 2009-01-06 03:53 ---
(In reply to comment #3)
Sun recommendations are not the issue here really. On other targets people
could use someone else's assembler but GNU ld and this will fail. It just
happen Solaris is the one that this happens
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host
--- Comment #2 from rob1weld at aol dot com 2009-01-06 04:21 ---
There is one other change I made, add this to the top of
libmudflaps/mf-hooks2.c :
/* OpenSolaris */
struct mntent {
char*mnt_fsname;/* file system name */
char*mnt_dir; /* file system
--- Comment #35 from rob1weld at aol dot com 2009-01-06 07:32 ---
(In reply to comment #33)
With gcc version 4.4.0 20090102 on i386-pc-solaris2.11 I'm getting:
# gcc -v -o test_gmp_1 test_gmp_1.cc -lgmp -lstdc++
/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../../libstdc++.so
--- Comment #6 from rob1weld at aol dot com 2009-01-06 07:55 ---
(In reply to comment #3)
And this is documented in the installation documentation.
(Confusion may also result if the compiler finds the GNU assembler but has
not
been configured with --with-gnu-as.)
http
: 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=38743
--- Comment #4 from rob1weld at aol dot com 2009-01-06 14:55 ---
Confirmed on i386-pc-solaris2.11, building gcc version 4.4.0 20090106.
In addition I get an ice-on-valid-code .
# gmake profiledbootstrap
...
/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/
-B/usr
--- Comment #11 from rob1weld at aol dot com 2009-01-06 15:54 ---
(In reply to comment #5)
Subject: Re: ICE passing fixed point to function
On Wed, 24 Dec 2008, pinskia at gcc dot gnu dot org wrote:
x86_64 does not support fixed point modes at all. Someone needs to come up
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-solaris2.11
GCC host
--- Comment #1 from rob1weld at aol dot com 2009-01-06 22:45 ---
With a Profiled Bootstrap these things come back to haunt you - hit by a
-Werror :
# make profiledbootstrap
...
/usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/
-B/usr/local/i386-pc
--- Comment #3 from rob1weld at aol dot com 2009-01-07 01:32 ---
Jakub Jelinek said:
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
documents that you need to configure with --disable-multilib in this case,
perhaps just this should be repeated also for i?86-sun-solaris2
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=38753
--- Comment #1 from rob1weld at aol dot com 2009-01-07 12:27 ---
The non-pic directory works much of the time but I also get the
occasional missing .gcda in the 'build'/libiberty directory; whereas
in the 'build'/libiberty/pic directory _all_ the .gcda files are
missing
--- Comment #2 from rob1weld at aol dot com 2009-01-07 13:11 ---
The intl directoy has only 4 missing files:
../../gcc_trunk/intl/dcngettext.c:55: note: file
/usr/share/src/gcc_build/intl/dcngettext.gcda not found, execution counts
estimated
../../gcc_trunk/intl/dngettext.c:57: note
--- Comment #3 from rob1weld at aol dot com 2009-01-07 17:34 ---
I configured using --without-system-zlib and _every_ file in gcc_build/zlib
failed to create it's accompanying .gcda files. The build continued into
the libcpp directory and thus far has been working OK in libcpp
--- Comment #5 from rob1weld at aol dot com 2009-01-07 20:57 ---
While building in ./gcc _almost_ all .gcda's are found, but a few are missed:
../../gcc_trunk/gcc/ebitmap.c:1018: note: file
/usr/share/src/gcc_build/gcc/ebitmap.gcda not found, execution counts estimated
../../gcc_trunk
--- Comment #6 from rob1weld at aol dot com 2009-01-07 21:07 ---
(In reply to comment #4)
Obviously during bootstrap not all the code is actually executed. I don't see
how that is a bug.
Note the messages generated by the compiler.
We need to do one or both of the following
--- Comment #3 from rob1weld at aol dot com 2009-01-08 06:18 ---
(In reply to comment #2)
../../gcc_trunk/gcc/config/i386/i386.c:18511: error: ISO C90 forbids variable
length array 'vec'
That was already fixed by:
2009-01-06 Jan Hubicka j...@suse.cz
PR target/38744
--- Comment #7 from rob1weld at aol dot com 2009-01-08 17:53 ---
I skirted the i386 file by adding this to the line 189 of the Makefile:
# Added - make profiledbootstrap is slow and we don't want to break the build
# i386.c - causes ISO C90 forbids variable length array 'vec'
i386.o
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
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
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: 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
--- Comment #1 from rob1weld at aol dot com 2009-01-09 08:27 ---
Adding ../prev-i386-pc-solaris2.11/libgcc/libgcov.a to the link:
# (OLD)
# /usr/share/src/gcc_build/prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-
gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -DIN_GCC -g -O2
Status: UNCONFIRMED
Severity: critical
Priority: 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
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=38783
with --enable-coverage=noopt
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot
--- Comment #1 from rob1weld at aol dot com 2009-01-09 15:46 ---
I re-checked _which_ gcov was actually being ran it was Sun's. Fixed,
by 1 and 2 invalid (old gcov does not read new files).
The third Bug is valid still:
'gcov can't find xgcc.gcno and xgcc.gcda because they are being
--- Comment #2 from rob1weld at aol dot com 2009-01-09 17:44 ---
After that repair the make breaks an hour later here:
# gmake
...
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libgcc'
gmake[3]: Leaving directory
`/usr/share/src/gcc_build/i386-pc
breaks build
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
GCC build triplet: i386-pc
--- Comment #2 from rob1weld at aol dot com 2009-01-09 21:23 ---
Perhaps if the -combine command for gcc had a complementary -split=
command that would attempt to make optimal splits of the tree at split
sized chunks.
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #3 from rob1weld at aol dot com 2009-01-09 21:49 ---
After the build breaks typing gmake simply restarts from the _begining_!
# gmake
...
gmake[2]: Entering directory `/usr/share/src/gcc_build'
Configuring stage feedback in ./intl
...
and all is well (for a few hours
--- Comment #9 from rob1weld at aol dot com 2009-01-09 22:04 ---
(In reply to comment #8)
The pic library is not used while compiling gcc so this warning is ok and
not a bug.
Reopened.
That bug would be fixed it the -fprofile-use option were not given in
the directories
--- Comment #4 from rob1weld at aol dot com 2009-01-09 22:16 ---
(In reply to comment #3)
You told the compiler to compile everything at the same time what do
you expect to cause out of memory issues?
It could create temporary files (like qsort) and shrink the size of
the file
--- Comment #2 from rob1weld at aol dot com 2009-01-10 03:08 ---
OK, I'm going to propose:
# gdiff -Naur config.BACKUP2.guess config.guess
--- config.BACKUP2.guess2009-01-09 19:01:21.178338502 -0800
+++ config.guess2009-01-09 19:04:59.921763936 -0800
@@ -4,7 +4,7
--- Comment #4 from rob1weld at aol dot com 2009-01-10 05:47 ---
Much further on in the build ...
...
# Early copyback; see all above for the rationale. The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/sh
--- Comment #6 from rob1weld at aol dot com 2009-01-10 05:56 ---
(In reply to comment #1)
--enable-intermodule is not well tested at all. And second --combine is way
broken and really should be removed along with --enable-intermodule.
(one of Rob's comments)
That is the whole idea
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *-*-*-*
GCC host triplet: *-*-*-*
GCC
--- Comment #3 from rob1weld at aol dot com 2009-01-10 23:59 ---
(In reply to comment #1)
Is this still true in newer GCC releases? Also this was removed in 4.3 and
above.
Yes, on trunk. Searching for dupe before starting a new Bug Report, came here.
We might close this Bug
--- Comment #5 from rob1weld at aol dot com 2009-01-11 02:50 ---
Breaks again here:
/usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/gcc_build/./prev-gcc/
-B/usr/local/i386-pc-solaris2.11/bin/ -c -g -O2 -fprofile-use -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes
: UNCONFIRMED
Severity: minor
Priority: 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
--- Comment #2 from rob1weld at aol dot com 2009-01-11 04:43 ---
(In reply to comment #1)
Coverage means -fprofile-arcs only while profiling means
-fprofile-generate/-fprofile-use. Coverage is only useful when you are
looking
into GCC's sources to see what code is being used
--- Comment #11 from rob1weld at aol dot com 2009-01-11 04:50 ---
(In reply to comment #10)
3. There is a -Werror to be fixed. Use: i386.o-warn = -Wno-error
I already mentioned this was really fixed in trunk already.
I re-read this entire thread and still do not see your prior
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?id
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=38804
--- Comment #5 from rob1weld at aol dot com 2009-01-11 15:02 ---
In libjava too, see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743
--- Comment #1 from rob1weld at aol dot com 2009-01-11 15:37 ---
sigh ...
and: trunk/libjava/classpath/configure
Doing this to find them all:
# { (exit 1); exit 1; }; }; }
# Added - OpenSolaris - not cross compiling
}; }
cross_compiling=no
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from rob1weld at aol dot com 2009-01-11 16:11 ---
Changed that hack to:
# { (exit 1); exit 1; }; }; }
# Added - OpenSolaris - not cross compiling
}; }
fi
fi
fi
cross_compiling=no
echo $as_me:$LINENO: result: yes 5
echo ${ECHO_T}yes 6
-
We do have
--- Comment #3 from rob1weld at aol dot com 2009-01-11 16:51 ---
There are a dozen occurances of this line in file: trunk/libjava/configure
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext
$LIBS 5'
I changed them to this and the hack let the build
--- Comment #7 from rob1weld at aol dot com 2009-01-11 19:52 ---
(In reply to comment #6)
Another DEBUG just showed up in gcc version 4.3.0 20070716:
...
ping: gcc 4.4.0 20090111 trunk revision 143259
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
--- Comment #8 from rob1weld at aol dot com 2009-01-11 20:11 ---
Another DEBUG just showed up in gcc version 4.3.0 20090111:
gcc_trunk/libjava/java/security/VMAccessController.h
# gmake
... (hours later)
libtool: compile: /usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc
-B/usr
--- Comment #3 from rob1weld at aol dot com 2009-01-12 00:09 ---
With 1400M (and 512M swap) it dies here:
gmake[5]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava'
if /bin/sh ./libtool --tag=GCJ --mode=compile /usr/share/src/gcc_build/gcc/gcj
-B/usr
--- Comment #7 from rob1weld at aol dot com 2009-01-12 04:24 ---
On i386-pc-solaris2.11 (OpenSolaris 2008.11) compiling gcc 4.4.0 20090104
I did NOT get this failure:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00488.html
Now when I compile: gcc version 4.4.0 20090111
--- Comment #3 from rob1weld at aol dot com 2009-01-12 05:17 ---
(In reply to comment #1)
FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -g (test for excess
This means that the __float128 to int functions are not included in libgcc not
a big deal because most folks don't use
--- Comment #4 from rob1weld at aol dot com 2009-01-12 12:47 ---
(In reply to comment #3)
With 1400M (and 512M swap) it dies here:
...
-g -O2 -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF
classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip
--- Comment #3 from rob1weld at aol dot com 2009-01-12 13:58 ---
I built gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] on
i386-pc-solaris2.11 (OpenSolaris 2008.11) and while I do have libssp I do NOT
have any Testsuite. Will those patches in the thread
http
--- Comment #3 from rob1weld at aol dot com 2009-01-12 14:09 ---
(In reply to comment #2)
The gcov data is based on the source name and not the executable now. So this
is invalid.
That is what I am saying. There should be an exclusion for that one file only.
Rob
--
rob1weld
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38816
--- Comment #2 from rob1weld at aol dot com 2009-01-12 23:35 ---
(In reply to comment #0)
With --enable-languages=c,fortran, system trys to build gnattools and fails
with this error:
...
Cannot build gnattools while gnatlib is out of date or unbuilt
...
That may occur if you use
--- Comment #3 from rob1weld at aol dot com 2009-01-13 00:14 ---
In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have
the: Cannot build gnattools while gnatlib is out of date or unbuilt Bug.
# gmake clean-gcc
...
# gmake
...
gmake[4]: Leaving directory
`/usr
--- Comment #5 from rob1weld at aol dot com 2009-01-13 02:52 ---
(In reply to comment #4)
Cannot build gnattools while gnatlib is out of date or unbuilt.
That bug is a different issue than this bug. Please don't confuse the two.
I searched before I posted to try to avoid a dupe
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet
Severity: major
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38821
--- Comment #6 from rob1weld at aol dot com 2009-01-13 07:16 ---
(In reply to comment #5)
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs are.
if test $cross_compiling = no test $multilib = yes \
test x${with_multisubdir
--- Comment #7 from rob1weld at aol dot com 2009-01-13 14:38 ---
Let me clarify the accuracy of my meaning:
When I said: Down in family is not cross compiling. I meant for the purposes
of being able to execute 'target' code on the 'host', 'build' or 'target'
platform (as when
--- Comment #2 from rob1weld at aol dot com 2009-01-13 14:44 ---
(In reply to comment #1)
fixincludes is already registered as PR 25470.
And really PR 3415 is the original bug for it.
*** This bug has been marked as a duplicate of 3415 ***
Hehe ...
Only a few years old
--- Comment #4 from rob1weld at aol dot com 2009-01-13 14:53 ---
(In reply to comment #3)
Coverage builds should not be bootstrapped.
Profiled bootstrap means build stage1 with no opts and then stage2 with
generating the profiling data and then build some target libraries (not all
--- Comment #8 from rob1weld at aol dot com 2009-01-13 14:58 ---
(In reply to comment #7)
Nobody builds using --enable-intermodule, it uses too much memory in general
anyways so closing as won't fix.
We can fix it by reopening this bug and removing --enable-intermodule
--- Comment #7 from rob1weld at aol dot com 2009-01-13 15:17 ---
(In reply to comment #6)
You should not be bootstrapping a --enable-coverage=noopt build, you should
only need to build stage1 gcc.
I only typed make.
If I set --enable-coverage=noopt it should build correctly when I
--- Comment #2 from rob1weld at aol dot com 2009-01-13 15:19 ---
(In reply to comment #1)
Well you don't understand any of these options it seems.
First --enable-coverage=nopt does nothing except changes the CFLAGS really.
There is nothing in the toplevel makefile or configure which
--- Comment #3 from rob1weld at aol dot com 2009-01-13 15:26 ---
(In reply to comment #2)
*** Bug 38746 has been marked as a duplicate of this bug. ***
I think the Bugs in 38746 are more serious (and against the Trunk) than these
discards qualifiers warnings and the ever annoying
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *-*-*-*
GCC host triplet
--- Comment #11 from rob1weld at aol dot com 2009-01-13 22:10 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
--- Comment #5 from rob1weld at aol dot com 2009-01-14 17:24 ---
Created an attachment (id=17099)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17099action=view)
Memory Usage Report for classpath/tools/.libs/libgcj_tools_la-tools.o
(In reply to comment #4)
(In reply to comment #3
--- Comment #3 from rob1weld at aol dot com 2009-01-14 17:54 ---
(In reply to comment #2)
Relinking in itself is not a bug. You can avoid it on some systems
(but likely not on yours) with --enable-fast-install.
On some systems it is simply necessary.
If there is a specific
--- Comment #1 from rob1weld at aol dot com 2009-01-14 18:06 ---
Built and tested with my hacks, works.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38803
--- Comment #9 from rob1weld at aol dot com 2009-01-15 22:03 ---
(In reply to comment #4)
Hmm, automake should have done the correct thing ...
(In reply to comment #5)
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs
at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38866
at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38867
: normal
Priority: 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
: 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=38892
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-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet
--- Comment #6 from rob1weld at aol dot com 2009-01-17 14:32 ---
Created an attachment (id=17126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17126action=view)
Screenshot of build shows libgcj_tools crashing (hogging memory)
Here we have a screenshot of gcc building
--- Comment #7 from rob1weld at aol dot com 2009-01-17 14:41 ---
Created an attachment (id=17127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17127action=view)
Screenshot of build shows libgcj_tools building (after reboot)
Before reboot:
# gmake
...
gmake[3]: Entering directory
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38898
--- Comment #3 from rob1weld at aol dot com 2009-01-18 12:52 ---
(In reply to comment #1)
for the pass-stratcliff.c failure, change:
#ifndef __FreeBSD__
to
#ifdef __gnu_linux__
And this should fix the issue there.
For pass47-frag.c failure, you need to either do a { dg-warning
--- Comment #11 from rob1weld at aol dot com 2009-01-18 17:04 ---
(In reply to comment #10)
Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log :
No, it is not broken at all. __sync_val_compare_and_swap_4 cannot be used
with
x86 explicit -march=i686 is used as the default
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
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
: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38911
--- Comment #3 from rob1weld at aol dot com 2009-01-19 16:26 ---
(In reply to comment #1)
Probably the Solaris /bin/sh misparses ${BOOT_CFLAGS+'print
BOOT_CFLAGS='${BOOT_CFLAGS}';'}. The autoconf manual describes a similar
bug in connection with ${foo='}'}.
There may well be some
--- Comment #4 from rob1weld at aol dot com 2009-01-19 16:39 ---
Ada has it's errors fixed but now it presents output that is not captured
and warned in the Testsuite reports. The extra messages are not reported.
Here is part of: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790
--- Comment #6 from rob1weld at aol dot com 2009-01-19 17:09 ---
The Trunk (143454) is now:
# gcc/xgcc -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
--disable-static
--- Comment #18 from rob1weld at aol dot com 2009-01-19 17:43 ---
With my fix I can configure with --enable-java-awt=gtk,xlib,qt,x, see:
Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009
--- Comment #8 from rob1weld at aol dot com 2009-01-19 17:46 ---
(In reply to comment #7)
After my moc-qt4 fix to the Makefile I have test results to prove it built:
Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007
--- Comment #4 from rob1weld at aol dot com 2009-01-19 18:01 ---
(In reply to comment #3)
Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
earlier versions.
Thank you for fixing this.
BTW: Between 4.2.1 and 4.2.2 the gcc compiler changed from supporting old
--- Comment #2 from rob1weld at aol dot com 2009-01-19 18:06 ---
(In reply to comment #1)
A few hours later and it failed for want of ltcf-c.sh and ltcf-cxx.sh. I ran
gcc_update again and that fixed the configure / makefile problem of not
copying
those files over.
I no longer get
--- Comment #4 from rob1weld at aol dot com 2009-01-20 04:05 ---
(In reply to comment #1)
I really don't think using solaris threads is that well supported anymore. Is
there a reason why you are not using just --enable-threads=pthreads?
I have another reason for the compiler
101 - 200 of 623 matches
Mail list logo
