http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572
--- Comment #4 from Rob rob1weld at aol dot com 2012-09-08 15:17:11 UTC ---
Thank you, one and all.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804
--- Comment #13 from Rob rob1weld at aol dot com 2011-07-24 19:19:22 UTC ---
(In reply to comment #12)
It has always been the case that configure needs to be able to execute code
for all multilibs. If you have a target where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738
--- Comment #8 from Rob rob1weld at aol dot com 2011-06-28 06:18:04 UTC ---
Thanks for FIXing, every little bit helps.
Rob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28734
Rob rob1weld at aol dot com changed:
What|Removed |Added
CC||rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
Rob rob1weld at aol dot com changed:
What|Removed |Added
CC||rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #22 from Rob rob1weld at aol dot com 2011-01-05 16:26:43 UTC ---
(In reply to comment #21)
At long last.
It was only 2 years... I have some older than that.
Thank you for your work on my Bug Report,
Rob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39655
Rob rob1weld at aol dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
--- Comment #37 from rob1weld at aol dot com 2010-07-23 08:43 ---
(In reply to comment #31)
Please refrain from fiddling with the bug status: whoever does the backport
will
do this himself.
Thanks.
Rainer
I have no interest in your posts and have marked your emails to me
--- Comment #19 from rob1weld at aol dot com 2010-07-22 11:50 ---
(In reply to comment #10)
Adding an additional 64-bit default configuration
(like amd64-pc-solaris2* or whatever) doubles the testing burden on me for
no
real benefit. In fact, I believe that the sparcv9-sun
--- Comment #18 from rob1weld at aol dot com 2010-07-21 23:17 ---
(In reply to comment #17)
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only
i386-solaris*).
--- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 ---
(In reply to comment #15
--- Comment #30 from rob1weld at aol dot com 2010-07-20 18:46 ---
(In reply to comment #28)
Subject: Bug 38946
Author: jvdelisle
Date: Fri Jun 25 21:32:37 2010
New Revision: 161416
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161416
Log:
2010-06-25 Jerry DeLisle jvdeli
--- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 ---
(In reply to comment #15)
(In reply to comment #13)
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only
i386-solaris*).
--- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20
--- Comment #3 from rob1weld at aol dot com 2010-07-19 08:25 ---
... this does not get parallelized at all ...
Also see 34501
Perhaps we could make some use of Pluto. It is a fully automatic (C to OpenMP
C) parallelizer that makes code amenable to auto-vectorization.
http://pluto
--- Comment #10 from rob1weld at aol dot com 2010-07-16 14:31 ---
(In reply to comment #7)
Subject: Bug 32062
Author: hjl
Date: Thu May 24 14:12:18 2007
New Revision: 125025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125025
Log:
2007-05-24 H.J. Lu hongjiu...@intel.com
--- Comment #9 from rob1weld at aol dot com 2010-07-14 17:27 ---
Thanks for working on this guys,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #20 from rob1weld at aol dot com 2010-06-20 02:05 ---
(In reply to comment #16)
Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.
Thanks for looking into this,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #2 from rob1weld at aol dot com 2010-06-20 02:10 ---
(In reply to comment #1)
Fails on 64-bit Solaris 10, 11/SPARC, too.
Tossing Regression onto the Summary, thanks for confirming,
Rob
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #15 from rob1weld at aol dot com 2010-05-17 02:34 ---
(In reply to comment #13)
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only
i386-solaris*).
--- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ---
This is an Enhancement
--- Comment #7 from rob1weld at aol dot com 2010-05-04 06:37 ---
Rainer Orth
Please try this with an absolute path to configure. Perhaps we should simply
document that relative paths aren't supported here.
Rainer, I noticed this is marked as Waiting. If it is waiting
--- Comment #5 from rob1weld at aol dot com 2010-05-04 06:52 ---
Rainer: Fixed for 4.5.0.
Thanks to our Solaris Expert for fixing that.
It is (was) great fun to have to build (at least we used to, have to) gcc
with both GNU's ld and Sun's to ensure there is (was) no breakage
--- Comment #6 from rob1weld at aol dot com 2010-05-04 07:00 ---
Unless there are very important reasons (and I don't see any since the
underlying libthread and libpthread implementation on Solaris 2 is
identical, just the interfaces differ), please stick with the default,
posix
--- Comment #8 from rob1weld at aol dot com 2010-05-04 07:05 ---
As I've said before: please file *clear individual bug reports* for each
single
issue you find. Dealing with reports like this, with dozens of issues and
non-
issues mixed, is close to impossible.
I'll stick
--- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ---
... the time it takes to analyze and fix problems. This is practically
doubled if you have two different configurations to test, and I simply
cannot afford that, given that this is a spare-time activity. That's
--- Comment #26 from rob1weld at aol dot com 2010-04-12 01:54 ---
(In reply to comment #25)
I understand that this is INVALID because all the points raised by comment
#21.
If crlibm is better than what we have, but we cannot use it, it is the same as
if it didn't exist
--- Comment #5 from rob1weld at aol dot com 2010-04-12 02:23 ---
(In reply to comment #4)
Rob, this is very old. Is it still a problem?
Thank you kindly for being the one to reply to my Report.
Due to the fact that it often takes a year for some replies, and in this case
three years
--- Comment #10 from rob1weld at aol dot com 2010-03-25 10:29 ---
(In reply to comment #9)
I don't think you have any bug. Enjoy your DLL!
Thanks for fixing this _2_ year old Bug.
GCC 4.2.x (especially 4.2.1) is an important version of our compiler since:
* It is able to compile
--- Comment #2 from rob1weld at aol dot com 2009-10-16 10:46 ---
Thanks,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38816
--- Comment #4 from rob1weld at aol dot com 2009-10-07 11:21 ---
(In reply to comment #1)
Yes GPU libraries would be nice but this needs a lot of work to begin with.
First you have to support the GPUs. This also amounts to doubling the
support.
If you really want them, since
--- Comment #6 from rob1weld at aol dot com 2009-10-04 10:25 ---
(In reply to comment #5)
I see. This particular issue should be fixed as libelf and the clone from
elfutils use different SONAMEs and the configure test in GCC checks for the
actual features it uses with a link test
--- Comment #12 from rob1weld at aol dot com 2009-09-25 23:58 ---
(In reply to comment #11)
Fixed.
Thanks,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
--- Comment #4 from rob1weld at aol dot com 2009-07-17 06:43 ---
(In reply to comment #2)
Confirmed. The proposed fix is not correct, though, as the type of the first
argument to munmap _is_ void* according to POSIX.
Thanks for applying the patch. I've not looked at 'LTO' source
--- Comment #3 from rob1weld at aol dot com 2009-05-20 13:10 ---
Some of the newest cards will run at over a PetaFLOP ...
I meant a TeraFLOP :( .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
--- Comment #2 from rob1weld at aol dot com 2009-05-18 17:36 ---
(In reply to comment #1)
Yes GPU libraries would be nice but this needs a lot of work to begin with.
First you have to support the GPUs. This also amounts to doubling the
support. If you really want them, since
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *
GCC host triplet
--- Comment #40 from rob1weld at aol dot com 2009-04-21 12:30 ---
(In reply to comment #0)
I've found a major performance regression in gcc 4.0.0's optimization ...
(In reply to comment #11)
We need more analysis on these kinds of issues.
So, we're doing a worse job on register
--- Comment #1 from rob1weld at aol dot com 2009-04-18 12:49 ---
Thanks for adjusting the Severity for me Andrew. There have
been _small_ improvements in the Testsuite Results recently.
The C compiler has gone from 828 errors a couple of months ago to a
new low of only 742, but the C
Version: 4.5.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
--- Comment #39 from rob1weld at aol dot com 2009-04-17 23:32 ---
(In reply to comment #38)
Maybe fixed now (the reduced testcase is). Please re-open if not.
Confirmed. Thank you Richard.
# uname -a
OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386
Host Compiler:
# egcc -v
Reading
--- Comment #27 from rob1weld at aol dot com 2009-04-11 17:01 ---
Ping: gcc version 4.5.0 20090407 trunk revision 145649
gcc_trunk/libiberty/cplus-dem.c:2651: warning: offset 3 outside bounds of
constant string
Noticed while building binutils (with -Werror):
../binutils-2.19.1/bfd
--- Comment #25 from rob1weld at aol dot com 2009-04-09 15:16 ---
That is good news, (that hppa2.0w-hp-hpux11.11 (PA-RISC 2.0.), which we
claim is supported, is not the same/similar to hpux-ia64, which has two
ZCX = False entries). We don't want to break that. Nice machine
--- Comment #22 from rob1weld at aol dot com 2009-04-09 03:51 ---
(In reply to comment #21)
It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86, ...
...
You can exclude all cross platforms; moreover hpux-ia64 is not really
supported.
URL http://gcc.gnu.org/gcc-4.5
--- Comment #20 from rob1weld at aol dot com 2009-04-07 04:00 ---
(In reply to comment #8)
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets? Otherwise this bug
should be closed as INVALID.
(In reply to comment #12)
As for the backend issue
--- Comment #5 from rob1weld at aol dot com 2009-04-05 09:46 ---
(In reply to comment #4)
(In reply to comment #1)
...
Broken: 145350
Working: 145300
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #6 from rob1weld at aol dot com 2009-04-05 17:08 ---
(In reply to comment #3)
The Ada compiler hasn't been ported to OpenBSD yet.
While we may not have ported Ada, the OpenBSD Group has it in Ports.
# pkg_add gnat-3.3.6p9
# egcc -v
Reading specs from /usr/local/lib/gcc
--- Comment #7 from rob1weld at aol dot com 2009-04-05 17:31 ---
I can build gcc with the Ada Language using Trunk revision 145337
but the changes made in the next revision cause the build to fail.
The Changelog indicates Richard Guenther made the changes on 2009-03-31.
There were
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-unknown-openbsd4.5
GCC host triplet: i386-unknown-openbsd4.5
--- Comment #14 from rob1weld at aol dot com 2009-04-05 20:03 ---
(In reply to comment #10)
I think this should be kept open as an enhancement request, if we have a
willing tester on openbsd I'll try to help.
I'll do my best to help but I know that there are numerous people who
--- Comment #15 from rob1weld at aol dot com 2009-04-05 20:10 ---
(In reply to comment #9)
Using the BSD Ports I was able to build Ada, up until revision 145338 .
While I do not use Ada it would be unfortunate to lose this Language.
This language is not supported in the FSF tree
--- Comment #17 from rob1weld at aol dot com 2009-04-05 20:53 ---
I've found machines and hosting to add i686
What a great guy!
More patches / support files / etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717
ports/lang/gcc/4.3/patches/
http://www.openbsd.org/cgi-bin/cvsweb
--- Comment #2 from rob1weld at aol dot com 2009-04-04 17:26 ---
(In reply to comment #1)
Working: 144400
While '144400' compiled properly the Testsuite was not as kind:
Results for 4.4.0 20090224 (experimental) [trunk revision 144400] (GCC)
testsuite on i386-unknown-openbsd4.5
http
--- Comment #3 from rob1weld at aol dot com 2009-04-03 13:53 ---
(In reply to comment #2)
Thanks. Patch commited as rev 144905 of MELT branch.
Closing, FIXED.
Rob
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #4 from rob1weld at aol dot com 2009-04-03 13:59 ---
(In reply to comment #3)
Subject: Re: The Driver hides undefined reference messages from shared
libs (but not object files) in linker phase
Sent from my iPhone
On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com
and 455 which are marked as MUST COALESCE.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot
--- Comment #2 from rob1weld at aol dot com 2009-04-03 15:27 ---
There has been some progress in this Bug Report:
http://gcc.gnu.org/viewcvs/trunk/gcc/ada/?sortby=date
mlib-tgt-specific-solaris.adb144324 5 weeks jakub Update Copyright
years for files modified in 2008
--- Comment #1 from rob1weld at aol dot com 2009-04-04 01:59 ---
Broken: 145488
Working: 144400
I'll continue to narrow it down some more.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
: major
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/bugzilla/show_bug.cgi?id=39616
: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-unknown-openbsd4.5
GCC host triplet: i386-unknown-openbsd4.5
GCC target triplet: i386-unknown-openbsd4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-unknown-openbsd4.5
GCC host triplet: i386-unknown-openbsd4.5
GCC target triplet: i386-unknown-openbsd4.5
http://gcc.gnu.org/bugzilla
--- Comment #4 from rob1weld at aol dot com 2009-03-30 23:35 ---
I ran into this Bug on the Trunk for Platform x64_86-unknown-openbsd4.5 .
I tried the test C code from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25255#c1
and got this:
/home/user/gcc_build/test_gcc_2.c:18: error
--- Comment #8 from rob1weld at aol dot com 2009-03-30 03:37 ---
(In reply to comment #7)
fopencookie is removed in rev145010 of MELT branch.
I'm using a temporary kludge , calling an unstable function inside PPL.
So You'll need a recent PPL snapshot (obtained thru GIT).
http
Severity: enhancement
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: x86_64-unknown-openbsd4.5
GCC host triplet: x86_64-unknown-openbsd4.5
GCC target triplet: x86_64-*-openbsd
--- Comment #3 from rob1weld at aol dot com 2009-03-29 04:31 ---
(In reply to comment #1)
How did you configure GCC and how did you invoke make?
I am getting the exact same error on the Trunk for OpenBSD 4.5 .
# gmake
... (Errors)
# gcc/xgcc -v
Using built-in specs.
Target: i686
--- Comment #4 from rob1weld at aol dot com 2009-03-29 04:38 ---
Another person has the same complaint as Andrey here:
http://www.mail-archive.com/g...@gcc.gnu.org/msg23970.html
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #6 from rob1weld at aol dot com 2009-03-22 09:26 ---
This Bug has been FIXED by Revision 144917.
http://gcc.gnu.org/viewcvs/*checkout*/branches/melt-branch/gcc/ChangeLog.melt?revision=144917
Rob
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #4 from rob1weld at aol dot com 2009-03-22 09:57 ---
I am aware that the _r issues have been addressed and will test the
'soon to arrive' fopencookie() code next week on i386-pc-solaris2.11
to ensure that non-Linux Platforms have a chance to vompile 'melt'.
Rob
--- Comment #5 from rob1weld at aol dot com 2009-03-18 06:19 ---
Nearly perfect results: (better than the Trunk last week)
Results for 4.4.0 20090313 (experimental) [melt-branch revision 144923] (GCC)
testsuite on i686-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2009-03
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
--- Comment #1 from rob1weld at aol dot com 2009-03-17 15:45 ---
Created an attachment (id=17478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17478action=view)
Patch ggc-zone.c to support ggc_collect_1()'s call to
ggc_mark_roots_extra_marking()
--
http://gcc.gnu.org/bugzilla
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
--- Comment #2 from rob1weld at aol dot com 2009-03-17 17:48 ---
Created an attachment (id=17479)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17479action=view)
A patch to ignore NULL *mi-iniframp from VEC_iterate() - shortcuts the issue
I am very unfamiliar with this branch
--- Comment #4 from rob1weld at aol dot com 2009-03-17 22:30 ---
(In reply to comment #3)
I applied a slightly simplified variant of melt-patch-2.patch above as
rev144917
Thanks Rob. It probably works!
Great. The code may receive a better following if there were fewer warnings
--- Comment #2 from rob1weld at aol dot com 2009-03-16 22:08 ---
My next difficulty (on OpenSolaris) is the lack of a fopencookie()
function (and the related support in FILE). I'm now building melt
on i686-pc-linux-gnu and running into a few other errors; thus melt
does need some fixing
--- Comment #4 from rob1weld at aol dot com 2009-03-15 07:57 ---
(In reply to comment #2)
From ka...@gcc.gnu.org
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
: 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=39470
--- Comment #6 from rob1weld at aol dot com 2009-03-13 20:30 ---
Confirmed on the Trunk.
In the Bug mentioned at http://bugs.gentoo.org/54738 and here
this fails on gcc version 4.4.0 20090312 [trunk revision 144821].
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
--- Comment #2 from rob1weld at aol dot com 2009-03-14 03:54 ---
(In reply to comment #1)
Subject: Re: New: The Driver hides undefined reference messages from
shared libs (but not object files) in linker phase
Sent from my iPhone
Hurray for Phones with large screens.
On Mar 11
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: driver
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
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:36 ---
Also in contrib/test_summary :
# (C) 1998, 1999, 2000, 2002 Free Software Foundation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:40 ---
Fix:
/* munmap ((void *)computed_offset, computed_len); */
munmap ((caddr_t)computed_offset, computed_len);
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39279
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:22 ---
(In reply to comment #3)
Dismal Testsuite results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
Rob
Great results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:27 ---
(In reply to comment #3)
(In reply to comment #1)
MIRO: Mudflap Improved with Referent Objects - Works on OpenSolaris also.
http://gcc.gnu.org/wiki/MIRO
Results for gcc version 4.4.0 20080520 (experimental) [miro
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 ---
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
After the workaround we get 10 failures on i686 and 33 failures
on x86_64 when compiling trunk revision 144629, results here:
Results
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=39382
Severity: major
Priority: P3
Component: bootstrap
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
GCC target triplet: i686-pc-linux-gnu
http
--- Comment #1 from rob1weld at aol dot com 2009-03-05 22:23 ---
Created an attachment (id=17402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17402action=view)
Edited diff of comparison between Multilibs produced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39388
--- Comment #8 from rob1weld at aol dot com 2009-03-05 22:59 ---
(In reply to comment #7)
(In reply to comment #6)
Broken: x86_64-pc-linux-gnu
Works: i686-pc-linux-gnu
Rob
Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu):
Results for 4.4.0 20090218
--- Comment #2 from rob1weld at aol dot com 2009-03-02 11:00 ---
(In reply to comment #1)
Subject: Re: New: [LTO] ICE: in make_decl_rtl, at
varasm.c:1288
Thanks for the bug reports.
At this stage, I'm not sure if it's useful to file a bug report for
every test
--- Comment #7 from rob1weld at aol dot com 2009-03-02 03:19 ---
(In reply to comment #6)
Broken: x86_64-pc-linux-gnu
Works: i686-pc-linux-gnu
Rob
Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu):
Results for 4.4.0 20090218 (experimental) [lto revision
--- Comment #21 from rob1weld at aol dot com 2009-02-28 14:10 ---
(In reply to comment #20)
Created an attachment (id=13766)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13766action=view) [edit]
Patch main configure script to use mpfr 2.2.1, also detect mpfr library and
header
--- Comment #6 from rob1weld at aol dot com 2009-02-28 17:34 ---
I rebooted Debian and chose the 32-bit Kernel, then re-configured in
an _identical_ manner. I rebuilt gcc (using un-modified source) with
no extra effort with the 32-Bit Kernel.
Host Compiler:
# gcc -v
Using built
--- Comment #5 from rob1weld at aol dot com 2009-02-28 03:53 ---
(In reply to comment #4)
In addition to the lack of -L... this is also a 'spec' issue :
...
The issue with the spec file is caused by this in the Makefile.in:
# Dump a specs file to make -B./ read these specs over
)
Product: gcc
Version: lto
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: x86_64-unknown
--- Comment #6 from rob1weld at aol dot com 2009-02-26 23:01 ---
(In reply to comment #5)
Any chance you could narrow this down? The revision stated as problematic has
nothing to do with libstdc++. The file implicated, cfenv, has not had a change
in 3 months.
Was this a temporary
--- Comment #1 from rob1weld at aol dot com 2009-02-26 23:44 ---
This Bug Report is about the failure to detect that the proper
headers and libraries are present _before_ building can be attempted.
Even after the extra effort to install libelf (to ensure that
the scripts would work
: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #3 from rob1weld at aol dot com 2009-02-27 01:29 ---
I'm running Debian Lenny 5.0 released 14 Feb 2009, with updates.
# ld --version
GNU ld (GNU Binutils for Debian) 2.18.0.20080103
# as --version
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
Simply tossing
--- Comment #4 from rob1weld at aol dot com 2009-02-27 06:08 ---
# uname -m
x86_64
In addition to the lack of -L... this is also a 'spec' issue :
Original (head -2 ../lto_build/prev-gcc/specs) :
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64
--- Comment #5 from rob1weld at aol dot com 2009-02-24 16:53 ---
On OpenSolaris 2009.06 (snv_106) I get improved results with the Patch.
Before my Patch (awful, posted for comparison purposes only):
Results for 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged
with rev
--- Comment #3 from rob1weld at aol dot com 2009-02-23 14:52 ---
Dismal Testsuite results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
Version: lto
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: i386-pc-solaris2.11
GCC host triplet: i386-pc
1 - 100 of 623 matches
Mail list logo
