--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-03-09
15:07 ---
(In reply to comment #4)
> Sorry, pex_run & co aren't the reason for this issue. By further debugging I
> found that for bigger functions using alloca with variable sizes wrong code is
--- Comment #2 from r dot emrich at de dot tecosim dot com 2009-03-04
09:07 ---
(In reply to comment #1)
> Huh. It's not even compiling.
>
You're right.
OTOH the sequence
$ gcc -v -S hello.c
$ gcc -v -c hello.s
$ gcc -v -o hello hello.o
builds correctly.
Anyw
/../../x86_64-pc-mingw32/lib/crtend.o
hello.c: file not recognized: File format not recognized
collect2: ld gab 1 als Ende-Status zurück
--
Summary: assembler isn't called
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Pri
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-02-05
16:34 ---
(In reply to comment #5)
> It does get called when building that i686-pc-linux-gnu -> i686-pc-mingw32
> crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
> the
--- Comment #18 from r dot emrich at de dot tecosim dot com 2009-01-29
11:34 ---
(In reply to comment #17)
> (In reply to comment #16)
> > Created an attachment (id=17208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208&action=view) [edit]
> > gcc44-pr3
--- Comment #17 from r dot emrich at de dot tecosim dot com 2009-01-29
10:47 ---
(In reply to comment #16)
> Created an attachment (id=17208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208&action=view) [edit]
> gcc44-pr39002.patch
>
> As MS_ABI sser
--- Comment #13 from r dot emrich at de dot tecosim dot com 2009-01-28
19:06 ---
The changes in revision 143118 to revesion 143120 are causing the fault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #12 from r dot emrich at de dot tecosim dot com 2009-01-28
18:04 ---
fault came up between 2nd and 9th of January.
With visual c++ 2005 there is no problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #11 from r dot emrich at de dot tecosim dot com 2009-01-28
17:06 ---
I vote for P1 because it's a secondary platform.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #10 from r dot emrich at de dot tecosim dot com 2009-01-28
17:01 ---
Created an attachment (id=17202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17202&action=view)
assembler source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #9 from r dot emrich at de dot tecosim dot com 2009-01-28
17:01 ---
Created an attachment (id=17201)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17201&action=view)
preproccesed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #8 from r dot emrich at de dot tecosim dot com 2009-01-28
16:52 ---
Created an attachment (id=17200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17200&action=view)
self contained testcase
cross compiled to target x86_64-pc-mingw32 segfaults.
commandline: x8
--- Comment #7 from r dot emrich at de dot tecosim dot com 2009-01-28
14:57 ---
Anyway I will try to create a self contained small testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-01-28
14:45 ---
(In reply to comment #3)
> We need the preprocessed source of a *complete* (including main) program to be
> able to reproduce this.
>
That's a little bit difficult here. It's a reall
--- Comment #4 from r dot emrich at de dot tecosim dot com 2009-01-28
14:27 ---
What I can try is finding the revision which causes the fault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #2 from r dot emrich at de dot tecosim dot com 2009-01-28
14:22 ---
Created an attachment (id=17198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17198&action=view)
assembler source which segfaults
This one segfaults at ret statment at the end.
--
--- Comment #1 from r dot emrich at de dot tecosim dot com 2009-01-28
14:20 ---
Created an attachment (id=17197)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17197&action=view)
assembler source
This one works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
c snapshot and for trunk.
--
Summary: codegen bug?
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot
--- Comment #47 from r dot emrich at de dot tecosim dot com 2009-01-23
10:50 ---
Created an attachment (id=17165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17165&action=view)
chatr output for the resulting object
As you can see there is one dependency to libdl.1 wha
--- Comment #46 from r dot emrich at de dot tecosim dot com 2009-01-23
10:45 ---
Created an attachment (id=17164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17164&action=view)
Verbose output of static link step
As you can see for all libraries except libdld archives a
--- Comment #41 from r dot emrich at de dot tecosim dot com 2009-01-22
18:15 ---
(In reply to comment #40)
> Subject: Re: link/execute fails for cross gcc from linux to target
> hppa64-hp-hpux11.00
> > configuring with
> >
> > --disable-symvers
>
>
--- Comment #8 from r dot emrich at de dot tecosim dot com 2009-01-20
15:12 ---
(In reply to comment #7)
> (In reply to comment #4)
> > I don't think that this has anything to do with the crossconfig.m4
> >
> > At least until revision 143362 trunk used to
--- Comment #7 from r dot emrich at de dot tecosim dot com 2009-01-20
14:58 ---
(In reply to comment #4)
> I don't think that this has anything to do with the crossconfig.m4
>
> At least until revision 143362 trunk used to build cross compiler from
> x86_64-unknown-
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-01-20
13:00 ---
Benjamin,
you have only
#include
in both math_stubs_float.cc and math_stubs_long_double.cc.
Then you use something like
#ifndef _GLIBCXX_HAVE_FABSL
I don't see any definition in scope.
--
--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-01-20
11:50 ---
Benjamin, I suspect that your changes on the 15th are causing the trouble.
FYI, for libgfortran all the math test are performed at least for the
x86_64-pc-mingw32 target even in a cross build.
--
http
--- Comment #4 from r dot emrich at de dot tecosim dot com 2009-01-20
11:41 ---
I don't think that this has anything to do with the crossconfig.m4
At least until revision 143362 trunk used to build cross compiler from
x86_64-unknown-linux-gnu to both mingw targets x86_64-pc-mi
--- Comment #37 from r dot emrich at de dot tecosim dot com 2009-01-19
10:54 ---
Created an attachment (id=17143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17143&action=view)
C++ compile static log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #36 from r dot emrich at de dot tecosim dot com 2009-01-19
10:53 ---
Created an attachment (id=17142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17142&action=view)
C++ compile log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #35 from r dot emrich at de dot tecosim dot com 2009-01-19
10:53 ---
Created an attachment (id=17141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17141&action=view)
C compile static log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #34 from r dot emrich at de dot tecosim dot com 2009-01-19
10:52 ---
Created an attachment (id=17140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17140&action=view)
C compile log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #33 from r dot emrich at de dot tecosim dot com 2009-01-19
10:51 ---
(In reply to comment #32)
>
> Dave, thank you for the explanation.
> Next week I will try to build some functional C++ application.
> Then we will see if there are remaining issues.
>
>
--- Comment #32 from r dot emrich at de dot tecosim dot com 2009-01-16
18:33 ---
(In reply to comment #31)
>
> Probably, the warning needs to be suppressed. The warning is correct
> in that the encoding currently used contains dynamic relocations
> preventing the c
--- Comment #30 from r dot emrich at de dot tecosim dot com 2009-01-16
16:51 ---
(In reply to comment #21)
> I dont't know if the warnings at the end of this message are a result of this
> issue or different one. The linker complains about fde encoding in
> .libs/bitm
--- Comment #29 from r dot emrich at de dot tecosim dot com 2009-01-16
16:45 ---
Created an attachment (id=17120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17120&action=view)
fix file magic regex for HP-UX hosts
updated patch for all HP-UX hosts.
--
r dot emric
--- Comment #28 from r dot emrich at de dot tecosim dot com 2009-01-16
16:17 ---
Created an attachment (id=17119)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17119&action=view)
fix file magic regex for hppa*64*
updated patch
--
r dot emrich at de dot tecosim
--- Comment #26 from r dot emrich at de dot tecosim dot com 2009-01-16
16:07 ---
(In reply to comment #24)
> (In reply to comment #23)
> > This patch fixes the file magic regex for hppa*64*.
> > All dependent files have to be regenerated.
> >
> > This modi
--- Comment #23 from r dot emrich at de dot tecosim dot com 2009-01-16
15:01 ---
Created an attachment (id=17118)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118&action=view)
fix file magic regex for hppa*64*
This patch fixes the file magic regex for hppa*64*.
All de
--- Comment #22 from r dot emrich at de dot tecosim dot com 2009-01-15
13:07 ---
(In reply to comment #21)
> libtool uses the following regex:
> "(s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]"
> This matches for the native file command
--- Comment #21 from r dot emrich at de dot tecosim dot com 2009-01-14
18:47 ---
The link step for libstdc++.la gives warnings for failed file format test using
a file magic. This is wrong!
The problem results from different output of native file command and the linux
file command
--- Comment #20 from r dot emrich at de dot tecosim dot com 2009-01-14
13:58 ---
(In reply to comment #18)
> Ranier, this should be working now. Can you try to cross-compile as before,
> but
> with updated gcc sources?
>
Now it builds, but there are some issues.
Will
--- Comment #10 from r dot emrich at de dot tecosim dot com 2009-01-06
10:20 ---
(In reply to comment #8)
> What I would suggest doing is looking at the generated c++config.h file from a
> native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are
> defined. If
--- Comment #6 from r dot emrich at de dot tecosim dot com 2008-12-29
17:11 ---
Build and Host is x86_64-unknown-linux-gnu.
I compared to a cross-build for ia64-unknown-linux-gnu target.
In that case the tests are working.
So, I'm a litlle bit confused.
I may upload the confi
--- Comment #2 from r dot emrich at de dot tecosim dot com 2008-12-29
15:43 ---
Can't check anymore, no hardware!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35580
--- Comment #4 from r dot emrich at de dot tecosim dot com 2008-12-29
12:14 ---
Created an attachment (id=16999)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16999&action=view)
libstdc++/config.log
The tests for the mathematical functions are skipped all together.
Does
--- Comment #2 from r dot emrich at de dot tecosim dot com 2008-12-08
17:08 ---
(In reply to comment #1)
> Created an attachment (id=16815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815&action=view) [edit]
> preproccesed source
>
> the following
--- Comment #1 from r dot emrich at de dot tecosim dot com 2008-12-03
16:30 ---
Created an attachment (id=16815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16815&action=view)
preproccesed source
the following looks weired for me:
# 31 "/opt/gnu/src/gcc/gcc-4.4.0-
t: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #1 from r dot emrich at de dot tecosim dot com 2008-12-03
16:09 ---
Created an attachment (id=16814)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16814&action=view)
possible patch
That works for me. But someone has to verify that it doesn't cause re
mrich at de dot tecosim dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
--- Comment #6 from r dot emrich at de dot tecosim dot com 2008-07-22
07:53 ---
(In reply to comment #5)
> For me it is working today
>
I don't Know if it's related but today (rev. 138048) I get the following on
x86_64-unknown-linux-gnu:
/SCRATCH/tmp.haKcfD9964/Linu
--- Comment #1 from r dot emrich at de dot tecosim dot com 2008-03-14
11:43 ---
seems to be the same as Bug 30071
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32005
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triplet: hppa2.0w-hp
--- Comment #24 from r dot emrich at de dot tecosim dot com 2007-12-13
17:01 ---
Created an attachment (id=14744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14744&action=view)
preprocessed source
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-
--- Comment #22 from r dot emrich at de dot tecosim dot com 2007-12-13
14:09 ---
Created an attachment (id=14743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14743&action=view)
assembler code
rtl.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #21 from r dot emrich at de dot tecosim dot com 2007-12-13
14:08 ---
Created an attachment (id=14742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14742&action=view)
assembler code
ggc-none.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #19 from r dot emrich at de dot tecosim dot com 2007-12-13
12:06 ---
/usr/ccs/bin/nm build/rtl.o
Symbols from build/rtl.o:
NameValue Scope TypeSubspace
$$dyncall | |undef |milli |
$CODE$ | 0|static|data
--- Comment #18 from r dot emrich at de dot tecosim dot com 2007-12-13
11:58 ---
Here the complete linker step. I added the -v -t +vallcompatwarnings command
line switches.
/usr/ccs/bin/ld -v -L/lib/pa1.1 -L/usr/lib/pa1.1 -z -u main -u __gcc_plt_call
-o build/genconstants /usr/ccs/lib
--- Comment #17 from r dot emrich at de dot tecosim dot com 2007-12-11
12:26 ---
I'm completly lost. On the same machine:
Actual 4.2 branch works fine. Bootstrapping without java and using the
resulting gcc as bootstrap compiler for both configurations
hppa2.0w-hp-hpux11.00 and h
--- Comment #15 from r dot emrich at de dot tecosim dot com 2007-11-09
15:06 ---
Created an attachment (id=14515)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14515&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #14 from r dot emrich at de dot tecosim dot com 2007-11-09
14:40 ---
nm ggc-none.o
Symbols from ggc-none.o:
NameValue Scope TypeSubspace
$CODE$ | 0|static|data |$CODE$
$CODE$ | 0|static|data |$CODE
--- Comment #13 from r dot emrich at de dot tecosim dot com 2007-11-09
10:33 ---
Your right, seems to be platform-specific. hppa64-hp-hpux11.00 is ok.
I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #11 from r dot emrich at de dot tecosim dot com 2007-11-07
10:58 ---
Created an attachment (id=14494)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14494&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #10 from r dot emrich at de dot tecosim dot com 2007-11-07
10:57 ---
Patch solves the problem for rtl.c in gcc-4.3.0, but later:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing
--- Comment #7 from r dot emrich at de dot tecosim dot com 2007-11-06
14:22 ---
Created an attachment (id=14489)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14489&action=view)
preprocessed source
gcc-4.2.2 yields the same problem
--
http://gcc.gnu.org/b
--- Comment #6 from r dot emrich at de dot tecosim dot com 2007-11-06
12:02 ---
Takes a few minutes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #4 from r dot emrich at de dot tecosim dot com 2007-11-06
11:35 ---
(In reply to comment #3)
> I think 4.2 is also broken.
>
4.2.2 is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #1 from r dot emrich at de dot tecosim dot com 2007-11-06
10:23 ---
Created an attachment (id=14488)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14488&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
mbols: ggc_free
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build tripl
--- Comment #4 from r dot emrich at de dot tecosim dot com 2007-04-17
07:54 ---
Created an attachment (id=13377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13377&action=view)
Patch
Proposed patch. I added a new target (install-exec-am) to Makefile.am to
enforce th
--- Comment #3 from r dot emrich at de dot tecosim dot com 2007-02-19
16:16 ---
> Could you try adding this to Makefile.am and then re-running automake?
> (If you can't re-run automake, let me know and I will send you a patch.)
>
> install-binPROGRAMS: install-toole
--- Comment #2 from r dot emrich at de dot tecosim dot com 2007-01-30
08:55 ---
Subject: Re: make install fails for libjava
> Could you try adding this to Makefile.am and then re-running automake?
> (If you can't re-run automake, let me know and I will send you a patch.
make install fails for libjava
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim
--- Comment #1 from r dot emrich at de dot tecosim dot com 2006-10-31
11:06 ---
(In reply to comment #0)
>
> jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
>
similiar problem here.
hppa2.0w-hp-hpux11.00
gcc-4.2.0 revison 118176
/SCRATCH/gcc-bu
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triplet: hppa64-hp-hpux11.00
GCC host triplet: hppa64-hp-hpux11.00
GC
--- Comment #11 from r dot emrich at de dot tecosim dot com 2006-02-23
16:17 ---
Subject: Re: gcj seems not to pass the option to ld correctly
Andrew Haley schrieb:
> Rainer Emrich writes:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
>
--- Comment #9 from r dot emrich at de dot tecosim dot com 2006-02-23
14:45 ---
Subject: Re: gcj seems not to pass the option to ld correctly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Haley schrieb:
> Rainer Emrich writes:
> > The config.log in libjava has tw
--- Comment #7 from r dot emrich at de dot tecosim dot com 2006-02-23
11:04 ---
Subject: Re: gcj seems not to pass the option to ld correctly
The config.log in libjava has two entries for libiconv:
LIBICONV
which is
LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gn
--- Comment #18 from r dot emrich at de dot tecosim dot com 2006-02-07
16:35 ---
Created an attachment (id=10796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10796&action=view)
fixes bootstrap failure in libgfortran/instrisics/c99_functions.c for
mips-sgi-irix6.5 second
--- Comment #16 from r dot emrich at de dot tecosim dot com 2006-02-07
10:00 ---
(In reply to comment #15)
> Created an attachment (id=10794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10794&action=view) [edit]
> fixes bootstrap failure in ligfortran/instrisics/c9
--- Comment #15 from r dot emrich at de dot tecosim dot com 2006-02-07
09:55 ---
Created an attachment (id=10794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10794&action=view)
fixes bootstrap failure in ligfortran/instrisics/c99_functions.c for
mips-sgi-irix6.5
It
--- Comment #14 from r dot emrich at de dot tecosim dot com 2006-02-06
17:58 ---
Subject: Re: libgfortran build failure on mips-sgi-irix6.5
Okay, I will try!
Is there a preprocessor macro defined, which identifies IRIX?
As I see, there are two macros which are candidates IMHO
--- Comment #12 from r dot emrich at de dot tecosim dot com 2006-02-02
18:01 ---
Subject: Re: libgfortran build failure on mips-sgi-irix6.5
fxcoudert at gcc dot gnu dot org schrieb:
> --- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-01-12 13:08
> ---
> T
--- Comment #8 from r dot emrich at de dot tecosim dot com 2006-01-12
10:22 ---
Subject: Re: link failure for several acats tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
for gcc-4.2 20060109:
termination of testsuite run at c52103x with the following error:
gmake: *** [check
--- Comment #7 from r dot emrich at de dot tecosim dot com 2006-01-11
16:23 ---
Subject: Re: link failure for several acats tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
laurent at guerby dot net schrieb:
> --- Comment #5 from laurent at guerby dot net 2006-01-06 22
--- Comment #6 from r dot emrich at de dot tecosim dot com 2006-01-09
09:19 ---
Subject: Re: link failure for several acats tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
laurent at guerby dot net schrieb:
> --- Comment #5 from laurent at guerby dot net 2006-01-06 22
--- Comment #4 from r dot emrich at de dot tecosim dot com 2005-11-30
14:28 ---
Subject: link failure for several acats tests
Here's the link failure:
splitting
/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/testsuite/ada/acats/tests/a/a83a02b.ada
--- Comment #2 from r dot emrich at de dot tecosim dot com 2005-11-30
09:37 ---
Michael Weiser supplied two patches to binutils-2.16.1 which resolve the
libpthread issue.
see http://sourceware.org/bugzilla/show_bug.cgi?id=1150
I used the MIPS_OPTIONAL.patch and the binutils-2.16.1
--- Comment #18 from r dot emrich at de dot tecosim dot com 2005-11-08
07:47 ---
Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++.
Testsuite still in progress.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #17 from r dot emrich at de dot tecosim dot com 2005-11-07
16:25 ---
Sorry, for the delay.
I had a machine fault on the weekend.
So, I'm trying the snapshot from 5th of november now!
Look's good so far, already in stage 2.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #16 from r dot emrich at de dot tecosim dot com 2005-11-03
16:38 ---
(In reply to comment #15)
I'm trying the patch!
Result will follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #4 from r dot emrich at de dot tecosim dot com 2005-11-01
11:02 ---
Also fails on at least tree-data-ref.c and tree-cfg.c with xgcc: Internal
error: Trace/BPT/RangeErr/DivZero/Ovflow trap (program cc1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #3 from r dot emrich at de dot tecosim dot com 2005-11-01
09:46 ---
Created an attachment (id=10097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10097&action=view)
assembler output
I compiled c-parser.c with the exact same commandline as in the bootstrap,
--- Comment #1 from r dot emrich at de dot tecosim dot com 2005-10-31
17:37 ---
same for gcc-4.1-20051029
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triplet: mips-sgi-irix6.5
GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #1 from r dot emrich at de dot tecosim dot com 2005-10-21
08:03 ---
(In reply to comment #0)
The relevant binutils PR 1150:
http://sourceware.org/bugzilla/show_bug.cgi?id=1150
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
e for several acats tests
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot emrich at de dot tecosim dot com
GCC build triple
96 matches
Mail list logo
