http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572
--- Comment #4 from Rob 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 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 this is not possible (like
> Solaris or I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738
--- Comment #8 from Rob 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 changed:
What|Removed |Added
CC||rob1weld at aol dot com
--- Comment #10 from Rob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
Rob changed:
What|Removed |Added
CC||rob1weld at aol dot com
--- Comment #5 from Rob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
--- Comment #22 from Rob 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 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
--- 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
--- 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 ---
> >
--- 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
--- 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=gcc&view=rev&rev=161416
> Log:
&
--- 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://pl
--- 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=gcc&view=rev&rev=125025
>
--- 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 #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:
--- 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 #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 ---
&g
--- 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 s
--- 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 m
--- 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),
--- 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
--- 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 "Wa
--- 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 ye
--- 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
--- 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
--- 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
--- 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
--- 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 &
--- 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 th
eleration library to gcc
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 bui
--- 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
undefined reference to `unlikely'
Product: gcc
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
--- 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
--- 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
Read
--- 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 #3 from rob1weld at aol dot com 2009-04-11 03:21 ---
# grep offsetof /home/user/gcc_trunk/gcc/ginclude/stddef.h
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
Every other occurrence of stddef.h (in 'trunk', build, or in
/usr/include/stddef.h is
--- Comment #2 from rob1weld at aol dot com 2009-04-11 02:33 ---
(In reply to comment #1)
...
> This suggests the code is getting the wrong definition of offsetof. It
> should be getting the one in GCC's own or another one
> compatible with recent GCC (using __bu
--- Comment #27 from rob1weld at aol dot com 2009-04-11 02:27 ---
(In reply to comment #26)
> <<
> We still have the issue that all Platforms accept the (usually non-default)
> ./configure option "--enable-sjlj-exceptions" which leads to this Bug
> on suppo
--- 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
--- 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://
--- 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)
&g
--- 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-bi
--- 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
--- 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 numerou
k revision
145337
Product: gcc
Version: 4.5.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 trip
--- 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 no
--- 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
--- 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 #4 from rob1weld at aol dot com 2009-04-05 00:49 ---
(In reply to comment #1)
> Broken: 145488
> Working: 144400
>
> I'll continue to narrow it down some more.
>
> Rob
>
Broken: 145488
Working: 145000
Next up 145200,
Rob
--
h
--- 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-op
--- 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
--- 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 a
all-gnattools] Error 2
gmake[1]: Leaving directory `/usr/gcc_build'
gmake: *** [all] Error 2
Thanks,
Rob
--
Summary: Revision 145488 - Ada - Unable to coalesce ssa_names 96
and 455 which are marked as MUST COALESCE.
Product: gcc
Version: 4
--- 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,
--- 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 |Ad
tatus: UNCONFIRMED
Severity: blocker
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-un
Status: UNCONFIRMED
Severity: blocker
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/show_bug.cgi?id=39618
on: 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: *
GCC host triplet: *
GCC target triplet: *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39616
--- 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
--- 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 t
ty: major
Priority: P3
Component: target
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: i686-unknown-openbsd4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39584
--- 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 #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: i
rt for x86_64 OpenBSD
Product: gcc
Version: 4.5.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:
--- 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
--- 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 #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
--- 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 fe
--- 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=17479&action=view)
A patch to ignore NULL "*mi->iniframp" from VEC_iterate() - shortcuts the issue
I am very unfamil
nnot access memory at address 0x18
) at ../../melt-branch/gcc/main.c:35
(gdb)
I'm not familiar enough with this branch to offer a patch.
Thanks,
Rob
--
Summary: [melt] - revision 144904 - BASILYS INFORM [#198595]:
warmelt-first-1.c -> SIGSEGV
Pro
--- 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=17478&action=view)
Patch ggc-zone.c to support ggc_collect_1()'s call to
ggc_mark_roots_extra_marking()
--
http:/
Severity: major
Priority: P3
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=39483
--- 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 oth
--- Comment #1 from rob1weld at aol dot com 2009-03-15 23:18 ---
Workaround:
Define this at top of one file and export it in the other:
struct drand48_data
{
unsigned short int __x[3]; /* Current state. */
unsigned short int __old_x[3]; /* Old state. */
unsigned short
ot 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=39470
--- 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 b
--- 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 la
--- 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
ssages from
shared libs (but not object files) in linker phase
Product: gcc
Version: 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
GCC build triplet: *
GCC host triplet: *
GCC target triplet: *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
--- 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) [m
--- 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/msg0
--- 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 #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 #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:
Re
--- 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-g
--- 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=17402&action=view)
Edited diff of comparison between Multilibs produced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39388
e are the rest (of the libraries and alternate directories)
for the multilibs on Platform "i686-pc-linux-gnu" ?
See the attachment.
Rob
--
Summary: trunk revision 144629 - Multilibs missing
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severit
nassigned 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=39382
--- 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
--- 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
--- 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-in
--- 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=13766&action=view) [edit]
> Patch main configure script to use mpfr 2.2.1, also detect mpf
--- 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
--- 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,*:%
--- 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 to
Status: UNCONFIRMED
Severity: major
Priority: 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: x8
1 - 100 of 633 matches
Mail list logo
