--- 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
: 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
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 must use Sun's ld.
Andrew
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=38727
: 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
--- 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: This should be detected
)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host
--- 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
: 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-solaris2.11
GCC target triplet: i386-pc-solaris2.11
--- 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 (and numerous problems
--- 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: undefined
reference
--- 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/local/i386-pc
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
--- 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
making Can you try 4.3.2
--- 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/bugzilla
: 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 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 Unreachable statement turns
--- Comment #12 from rob1weld at aol dot com 2008-09-18 22:21 ---
(In reply to comment #11)
Subject: Bug 32581
Author: hubicka
Date: Sat Sep 13 21:39:44 2008
New Revision: 140349
Modified:
trunk/gcc/tree-profile.c
...
Fixed by my patch.
I have since switched target
--- Comment #8 from rob1weld at aol dot com 2008-08-05 16:59 ---
Ralf Wildenhues 2008-08-05 wrote:
Rob, please let's not play ping pong with the severity of this bug.
?
OK, I'll leave it with you.
GCC configury mostly assumes that available commands respect POSIX
The default
--- Comment #6 from rob1weld at aol dot com 2008-08-04 13:44 ---
Andrew John Hughes 2008-06-20 14:34:
What is this bug waiting on?
Tom Tromey 2007-05-24 17:18:
I think gjdoc only recently got support for generics and annotations.
So an older gjdoc is expected to fail. I haven't
--- Comment #3 from rob1weld at aol dot com 2008-08-04 13:50 ---
Changed severity back up to normal (from minor) since this bug has sat open for
a year with no reply, and there is something to fix.
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #2 from rob1weld at aol dot com 2008-08-04 17:18 ---
Ralf Wildenhues 2008-08-04 08:57 wrote:
I see the egrep issue.
Would you click the CONFIRMED button please.
Can you please specify for which grep and sed commands you see errors?
I need to build some dependencies
--- Comment #3 from rob1weld at aol dot com 2008-08-04 17:21 ---
Created an attachment (id=16014)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16014action=view)
gdiff of Origonal gcc-4.2.3/libjava/configure vs. repaired version
gdiff -Naur config_Origonal_configure.log
--- Comment #3 from rob1weld at aol dot com 2008-08-04 18:44 ---
I wrote:
It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.
But then I would not have to try fixing this ...
The boehm-gc directory built correctly
--- Comment #5 from rob1weld at aol dot com 2008-08-05 02:42 ---
Andrew Pinski 2008-08-04 18:53 wrote:
Not if they want to call their OS a POSIX or UNIX OS really. POSIX actually
makes a standard about programs too.
If you want Posix conformant commands (not necessarily GNU
--- Comment #6 from rob1weld at aol dot com 2008-08-05 05:07 ---
The grep/sed problem occurs during the boehm-gc configury and in
libjava/classpath also. It is also missing iconv whereas the main configure
picks it up (due to: --with-libiconv-prefix=/opt/csw):
Adding multilib support
--- Comment #3 from rob1weld at aol dot com 2008-08-03 06:29 ---
Reopened - Broken in 4.2.2 and 4.2.3 also.
--
rob1weld at aol dot com changed:
What|Removed |Added
Priority: 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
--- Comment #2 from rob1weld at aol dot com 2008-08-04 01:28 ---
Is there a reason why you are not using just --enable-threads=pthreads?
A few reasons.
1. I test _all_ of gcc's configure options, submit bug reports and email test
results - --enable-threads=solaris is a valid choice
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 com
GCC build triplet: i386-pc-solaris2.11
GCC
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: i386-pc-solaris2.11
http
--- Comment #2 from rob1weld at aol dot com 2008-08-03 05:12 ---
4.2.1 is history and is completely and utterly unsupported.
OK.
Directory ftp://ftp.gnu.org/gnu/gcc/ says the date is 07/20/07 so it is barely
over one year old. I desire to build a 4.2.x series so I'll move up one minor
--- Comment #4 from rob1weld at aol dot com 2008-06-29 05:26 ---
I don't understand the last comment. Do you still have a bug to report?
Yes.
If no, then please close this, if yes, then please state what is different
from the successful build you used to obtain the test results
--- Comment #6 from rob1weld at aol dot com 2008-06-29 05:28 ---
Created an attachment (id=15824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15824action=view)
./libtool --tag=CXX --config tag_CXX.txt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31845
--- Comment #7 from rob1weld at aol dot com 2008-06-29 05:30 ---
Created an attachment (id=15825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15825action=view)
./libtool --tag=GCJ --config tag_GCJ.txt
Attached two outputs from libtool.
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from rob1weld at aol dot com 2008-06-29 05:37 ---
Note: Ignore those two attachments they are for a different bug report. For
some reason when I made an attachment to a different bug report bugzilla put
them here.
Janis:
Someone else reported the same problem in another
--- Comment #5 from rob1weld at aol dot com 2008-06-29 05:40 ---
Created an attachment (id=15826)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15826action=view)
./libtool --tag=CXX --config tag_CXX.txt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36640
--- Comment #6 from rob1weld at aol dot com 2008-06-29 05:41 ---
Created an attachment (id=15827)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15827action=view)
./libtool --tag=GCJ --config tag_GCJ.txt
Attached two outputs from libtool
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from rob1weld at aol dot com 2008-06-27 08:42 ---
Test results are here:
Results for 4.2.1 testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg02160.html
Everything passed (and failed) as expected for this version of gcc when
configured
Severity: blocker
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
--- Comment #1 from rob1weld at aol dot com 2008-06-26 17:52 ---
Correction: The finally ending with this section should read:
---
.LPR2 0x123aa1.libs/gnu-xml.o
.LPR2 0x123ba1.libs/gnu-xml.o
ld: fatal: relocations
...' of
file
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc
--- Comment #8 from rob1weld at aol dot com 2007-08-06 06:44 ---
GCC 4.2.2 20070804 is able to compile newer kernels as is 4.2.1 20070628. I
guess 4.3 and 4.1 are the only series lacking this ability.
I am not allowed to change the Summary: to add [4.3 Regression] to the
begining
: Test results script contrib/test_summary broken ?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot
--- Comment #6 from rob1weld at aol dot com 2007-08-06 04:27 ---
Thanks DJ. That only leaves this in gcc-4_3-trunk/libiberty/configure.ac :
(Line 360):
# These are neither executed nor required, but they help keep
# autoheader happy without adding a bunch of text to acconfig.h
--- Comment #2 from rob1weld at aol dot com 2007-08-06 05:10 ---
Why do the other reports show no FAIL lines and no line like # of unexpected
failures 122 ? Was the C compiler _perfect_ yesterday?
You may need to fix this again:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783#c4
--- Comment #7 from rob1weld at aol dot com 2007-08-02 17:24 ---
Created an attachment (id=14010)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14010action=view)
Example of kernel file that causes inlining failed error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
--- Comment #6 from rob1weld at aol dot com 2007-08-02 17:18 ---
I can confirm this too. Here is the bug report I was to post - but I searched
to see if this was already reported ;) - Here are my notes:
tree-inline.c - sorry, unimplemented: inlining failed ... function body
--- Comment #4 from rob1weld at aol dot com 2007-07-17 12:56 ---
(In reply to comment #3)
They are duplicated because they are different sections of the case
statement.
Nothing we can do about this.
that one is an autoconf issue an not the way we coded configure.ac
That is what I
--- Comment #7 from rob1weld at aol dot com 2007-07-17 13:04 ---
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-07/msg00721.html
--
http
--- Comment #15 from rob1weld at aol dot com 2007-07-17 13:05 ---
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-07/msg00721.html
: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32781
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783
--- Comment #2 from rob1weld at aol dot com 2007-07-16 22:15 ---
I may be enabling more features than others are using ;)
I re-did ./configure and make clean and make and got a thousand lines
further, now I am here:
make[7]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu
--- Comment #3 from rob1weld at aol dot com 2007-07-16 22:53 ---
make[6]: Leaving directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/jni/gtk-peer'
Making all in qt-peer
make[6]: Entering directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/jni
--- Comment #6 from rob1weld at aol dot com 2007-07-17 00:49 ---
Another DEBUG just showed up in gcc version 4.3.0 20070716:
gcc-4_3-trunk/libjava/gnu/classpath/Configuration.h
...
static ::java::lang::String * CLASSPATH_VERSION;
static jboolean DEBUG;
static const jboolean
--- Comment #14 from rob1weld at aol dot com 2007-07-17 01:09 ---
(In reply to comment #11)
ping...
This is known and will not be fixed until 4.2.
Now that 4.2 is released and it still doesn't work, can we get this working in
4.3?
Thats the spirit guys! So many threads have
--- Comment #6 from rob1weld at aol dot com 2007-07-17 01:26 ---
Thank you Andrew. !
This bug report was about a blocker - the build breaking, unable to continue.
I altered the Makefile to use moc-qt4 (instead of moc) and the build
continued past that point perfectly well
--- Comment #2 from rob1weld at aol dot com 2007-07-17 02:52 ---
In file: gcc-4_3-trunk/libiberty/configure.ac
line 364 and line 369 both have gettimeofday
Another occurance (in configure.ac) is here:
*-*-msdosdjgpp)
for f in atexit basename bcmp bcopy bsearch bzero calloc
--- Comment #2 from rob1weld at aol dot com 2007-07-17 03:01 ---
It shows on pages 9 and 10 a list of IPA and inlining options that exceed our
-fipa-pta and friends. They also use different default values in some cases
where 'similar' features are offered.
If no auto-tuning (which do
--- Comment #2 from rob1weld at aol dot com 2007-07-17 03:08 ---
We might want to test -mfixed-range=REGISTER-RANGE while we are checking
this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32267
--- Comment #37 from rob1weld at aol dot com 2007-07-17 03:10 ---
We might want to test -mfixed-range=REGISTER-RANGE while we are checking that
this bug is completely fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #14 from rob1weld at aol dot com 2007-07-13 07:27 ---
Comment #13 From Eric Botcazou 2007-07-12 06:00 [reply] ---
Please do not pollute this ticket with unrelated stuff.
I posted here after previously searching many messages, and again re-searching
more messages to see
: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32754
--- Comment #12 from rob1weld at aol dot com 2007-07-12 00:55 ---
I am building on target i686-pc-linux-gnu and have not noticed this problem
with this target. It does NOT occur for a 'regular' make, only seems to
happen with this last make profiledbootstrap that I did:
We have
: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
--- Comment #3 from rob1weld at aol dot com 2007-07-10 17:09 ---
I was told in my other bug report to file my 'java problem' seperatly - so I
did.
gcc-4.2 file.java
gcc: error trying to exec 'ecj1': execvp: No such file or directory
How is it not a bug for GCC 4.3 to attempt
/ltconfig: No such file or directory
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC
--- Comment #1 from rob1weld at aol dot com 2007-07-09 20:27 ---
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.
There is still the annoyance of the build re
--- Comment #4 from rob1weld at aol dot com 2007-07-09 21:01 ---
Comment #2 From Andrew Pinski 2007-07-09 02:53 [reply] ---
No include for string.h or cstring.
Andrew, I'm not an expert at C++ but I did my best to attempt to make a couple
of reduced testcases where I felt I
--- Comment #6 from rob1weld at aol dot com 2007-07-10 04:31 ---
Comment #5 From Paolo Carlini 2007-07-09 21:19 [reply] ---
The last issue simply doesn't make sense.
On page http://gcc.gnu.org/bugs.html#need it says:
the preprocessed file (*.i*) that triggers the bug, generated
--- Comment #7 from rob1weld at aol dot com 2007-07-10 04:55 ---
--- Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] ---
Note that in 4.3 the header dependencies have been streamlined and it's well
possible that some projects around are failing to include required
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
--- Comment #1 from rob1weld at aol dot com 2007-07-09 02:49 ---
Created an attachment (id=13873)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13873action=view)
A few example .ii files (from a list of many) that have errors when compiled
using GCC == 4.3 --- but do not have any
--- Comment #3 from rob1weld at aol dot com 2007-07-07 16:41 ---
A bug report has been filed with 'hal'.
What had happened was that CIL had optimized away, in some cases, and created
incorrect code in other cases; based on what it read of the GCC 4.3 sources. It
then fed the C2C back
--- Comment #10 from rob1weld at aol dot com 2007-07-07 18:05 ---
I compiled the program I was working on using GCC 4.2 that was configured using
the option --enable-concept-checks and one file would not compile; giving
this error:
/usr/include/c++/4.2/bits/boost_concept_check.h
--- Comment #9 from rob1weld at aol dot com 2007-07-06 08:13 ---
Also occurs in 4.2 and 4.3
Discussed here:
http://lists.boost.org/Archives/boost/2002/03/27238.php
http://lists.boost.org/Archives/boost/2002/03/27274.php
Seems to end with this:
http://lists.boost.org/Archives/boost
--- Comment #1 from rob1weld at aol dot com 2007-07-07 03:03 ---
This is a duplicate of 32004 - That is fixed and so is this.
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #2 from rob1weld at aol dot com 2007-07-07 03:10 ---
There is a whole list of these optimizations at:
http://graphics.stanford.edu/~seander/bithacks.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32648
--- Comment #8 from rob1weld at aol dot com 2007-07-07 04:05 ---
I searched the last 30 reports using
http://gcc.gnu.org/bugzilla/buglist.cgi?product=gccversion=4.3.0chfieldfrom=2007-07-06chfieldto=2007-07-07chfieldvalue=cmdtype=doitorder=Bug+Number
to find the best place to put
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
--- Comment #1 from rob1weld at aol dot com 2007-07-02 17:47 ---
I re-configured with exactly the same command line options, except I removed
ada from --enable-languages=, and re-started make.
On this second attempt the file building timing was similar to what was
previously reported
301 - 400 of 623 matches
Mail list logo
