--- Comment #3 from rob1weld at aol dot com 2008-12-31 00:49 ---
Right.
(In reply to comment #2)
> The .java source part of the java front-end was removed in 4.3.x and above so
> closing as won't fix.
>
(In comment #0 Rob said)
>> _THIS_ bug report is only on &q
: classmap.db is zero bytes long in 64 bit directory
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot
--- Comment #3 from rob1weld at aol dot com 2009-01-01 12:09 ---
(In reply to comment #1)
> Can you try 4.3.2?
No, I don't have it, and next I was planning on build-testing the trunk.
The reason for reporting "so old a version" (_if_ that is the point you are
m
--- Comment #4 from rob1weld at aol dot com 2009-01-01 12:40 ---
(In reply to comment #1)
> Can you try 4.3.2?
This person ( http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01766.html ) has
recently built 4.3.2 on my platform; you could ask them.
--
http://gcc.gnu.org/bugzi
Summary: gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses
"USE_GAS" which is undefined
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-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=38693
--- Comment #1 from rob1weld at aol dot com 2009-01-02 13:46 ---
Prior to changing "gcc/config/i386/sol2-10.h":
u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v
-B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/loc
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: java
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-s
--- Comment #2 from rob1weld at aol dot com 2009-01-03 19:15 ---
Since this bug is related to the assembler I tried setting the "--with-gnu-as
--with-as=" options for configure and while that allowed the build to continue
it then went down a path of uncharted waters (an
--- Comment #33 from rob1weld at aol dot com 2009-01-03 19:53 ---
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: undefin
r gcc ...
Running chapter l ...
=== acats Summary ===
# of expected passes 2307
# of unexpected failures8
*** FAILURES: c34009l c761006 ce3410a ce3410e cxa5a05 cxa5a06 cxg2004 cxg2013
...
--
Thanks,
Rob
--
Summary: gcc 4.4.0 20090104 - "make -i check" - over 60 FAILs in
"C" compiler
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
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=38730
--- Comment #2 from rob1weld at aol dot com 2009-01-05 17:07 ---
I noticed this is a "P1".
> Rainer Orth says:
> Building current mainline on Solaris 11/SPARC with GNU ld 2.19 and
> Sun as fails when building libgomp:
The Official Position of Sun is: "You mus
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 triplet:
;make install" is relinking
`libgij.la'
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
Repor
--- Comment #17 from rob1weld at aol dot com 2009-01-05 22:58 ---
(In reply to comment #16)
> ping...
> This missed 4.3 again, it should probably get in now before 4.4 enters freeze
> mode...
How about 4.5 ?
> Re the moc -> moc-qt4 change suggested in comment #14:
Summary: gcc 4.4.0 20090104 - OpenSolaris can enable libmudflaps
(if gcc is configured to use GNU ld)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libmudflap
AssignedT
--- 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
--- 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
--- 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 r
--- 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
/bin/sh uses ksh, gawk fails
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
--- 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-solaris
--- 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
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-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. Som
src/gcc_trunk/libobjc/../gcc/gthr-posix.h: In function
'__gthread_objc_thread_detach':
/usr/share/src/gcc_trunk/libobjc/../gcc/gthr-posix.h:394: warning: cast to
pointer from integer of different size
/usr/share/src/gcc_trunk/libobjc/../gcc/gthr-posix.h: In function
'__gthread_objc_thread_i
--- 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
: P3
Component: middle-end
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=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 direc
--- 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
--- 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 c
--- 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
--- 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
--- 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 leng
src/gcc_build'
gmake[2]: Leaving directory `/usr/share/src/gcc_build'
gmake[2]: Entering directory `/usr/share/src/gcc_build'
Configuring stage profile in ./intl
--
Summary: gcc 4.4.0 20090104
Product: gcc
Version: 4.4.0
Status: UNC
Leaving directory `/usr/share/src/gcc_build'
gmake[1]: *** [stageprofile-bubble] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2
--
Summary: gcc 4.4.0 20090109 - Configure with "--enable-
coverage=noopt" bre
--- 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_
build does not
terminate "make" (b19 'ld')
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot o
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
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=38783
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
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=38784
--- 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 &qu
--- 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/i3
ot; is too likely to run into an "-Werror"
_or_ run the user out of memory, _most_ of the time. This makes it of limited
use in this situation. We should make it more usable (bring it up to "usable").
Rob
--
Summary: gcc 4.4.0 20090109 - Configure with "--enable-
intermodule" 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-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=38788
--- 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
--- 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 (
--- 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 giv
--- 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 fi
--- 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
--- 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 libgc
--- 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
e good that we
do not use _all_ of the "C" compiler to compile gcc and that we won't be
ripping out all the code we don't use. Loss of this feature means loss of
nothing since we can always use the Makefile the old-way if we would wish to.
Questions?
Thanks for reading this,
Rob
--
--- 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
remove amd64/ */* fixincludes/* and /gnattools/*
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol
--- 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 c
--- 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 an
uld they please
clean-up the re-direction of the output of the check for: "checking for
unzip... /usr/bin/unzip".
--
Summary: [4.4 regression] Configure with "--enable-java-awt=x"
requires Escher
Product: gcc
Version: 4.4.0
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-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&
--- 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 h
--- 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 -
--- 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
-
--- 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 m
--- 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 cla
--- 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
--
ro
ndocumented
Product: gcc
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 m
--- 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 direc
--- 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 poste
--
Summary: [4.2/4.3/4.4 Regression] During "make -i check" we set
GCC_EXEC_PREFIX="/usr/local/lib/gcc/"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Compone
d
Product: gcc
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
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
--- 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', 'b
--- 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 ...
On
--- 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 li
--- 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 --
--- 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 sho
--- 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 makefil
--- 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
d correctly would go a long way towards future maintenance ease.
Thanks for reading this,
Rob
--
Summary: RFE - Need Makefile to test coverage of Testsuite
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
--- 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=17099&action=view)
Memory Usage Report for "classpath/tools/.libs/libgcj_tools_la-tools.o"
(In reply to comment #
--- 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 ther
--- 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 mult
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38866
tus: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38867
target `all'"
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: i
Rob
--
Summary: gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error:
request for member 'frame_type' in ...
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-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
bffi guesses sizeof 'long double'
incorrectly (32bit/64bit)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot
1 - 100 of 633 matches
Mail list logo
