nu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC host triplet: alphaev67-dec-osf5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2008-12-19
22:30 ---
Created an attachment (id=16948)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16948&action=view)
preprocessed file to demonstrate the problem
The "slightly modified" version o
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2008-12-30
01:46 ---
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01905.html caused the regression
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581
ath.h.
--
Summary: sco_math fixincl breaks math.h
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bu
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-06
00:45 ---
I'm using the version of inclhack.def from gcc-3_4-branch. I looked at the
changes in
http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/fixinc/inclhack.def?rev=100333&view=log
and don'
NCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia6
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-08
03:15 ---
(In reply to comment #1)
> See the thread on the gcc list discussing this bug.
> http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
>
> I suspect this is a bug in patches applied to the gcc-3
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2005-11-08
21:49 ---
(In reply to comment #3)
> I am not convinced that this is a bug. Was there an intentional change
> between
> 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but i
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2005-11-09
00:47 ---
(In reply to comment #5)
> Subject: Re: Shared libgcc not used for linking by default
>
> sje at cup dot hp dot com wrote:
> > --- Comment #3 from sje at cup dot hp dot com 2
--- Comment #12 from bugzilla-gcc at thewrittenword dot com 2005-11-11
21:58 ---
(In reply to comment #11)
> I have run into a problem with my testing, the link line looks good but I get
> warnings from the HP linker like:
>
> ld: (Warning) Cannot load library symbol tabl
--- Comment #13 from bugzilla-gcc at thewrittenword dot com 2005-11-11
22:00 ---
Created an attachment (id=10223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10223&action=view)
Backport of eh_dummy logic in gcc/mklibgcc.in from 4.0 (credit to Eric
Botcazou)
--
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:07 ---
(In reply to comment #19)
> Yes, I checked the installed libgcc_eh.a
> (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
> lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
>
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:59 ---
(In reply to comment #23)
> I build binutils 2.16 as part of my GCC build/test so I used that ar and
> ranlib
> when building GCC:
We're using the system ar/ranlib. I built binutils-
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:18 ---
(In reply to comment #25)
> I build binutils with --disable-shared and using flex/bison instead of
> lex/yacc, that is probably why my ar works. I experimented with the use of
> the
> system
--- Comment #28 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:29 ---
(In reply to comment #27)
> In your last comment you mention the binutils ar, but later the binutils as.
> I
> cannot reproduce the problem by just using the binutils ar command but I can
>
--- Comment #31 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:41 ---
Sure. I don't understand how Zack's patch works but as long as we have a
solution that works, fine by me. Eric might be interested in reviewing the
patch too.
--
http://gcc.gnu.or
--- Comment #33 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:51 ---
(In reply to comment #32)
> Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to
> use the same eh_dummy.c file (struct eh_dummy;) as 3.4.
4.0.2 had the same problem.
--
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2006-01-06
22:32 ---
(In reply to comment #3)
> Is 4.1 or 4.2 building there now?
Dunno. Will try and find some time to build 4.1 soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-01-06
23:18 ---
(In reply to comment #5)
> I see HP has a new libcl patch:
>
> PHSS_33903 - s700_800 11.23 LIBCL patch
>
> HP-UX series 700 11.X patch digest,HP-UX series 800 11.X patch digest
> HP-
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-01-10
17:32 ---
(In reply to comment #5)
> I'd like to either close this or change it to bootstrap, in the attempt to
> flag
> the attention of the top-level build people for this bug.
>
> I don'
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: powerpc-ibm-aix4.3.3.0
GCC host triplet: powerpc-ibm-aix4.3.3.0
GCC target triplet: powerpc-ibm-aix4.3.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33090
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2007-08-23
17:24 ---
(In reply to comment #1)
> Huh? The warnings should be ok. What exact error are you getting because I
> don't see -Werror on the command line so the warnings should not be stoping
> the
oduct: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: powerpc-ibm-aix5.1.0.0
GCC ho
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: ia64-hp-hpu
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2008-02-12
03:52 ---
(In reply to comment #1)
> ld is running at this time so I doubt this is a GCC bug.
The Pid it is referring to ("Pid 18929 received a SIGSEGV for stack growth
failure.") is /opt/build/ch
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: hppa2.0w-hp-hpux11.23
G
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-02-22
20:23 ---
Created an attachment (id=15208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15208&action=view)
patch to include string.h and strings.h (stolen from libcpp)
Patch does not include generate
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2008-02-24
07:09 ---
(In reply to comment #3)
> Created an attachment (id=15208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15208&action=view) [edit]
> patch to include string.h and strings.h (stole
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2008-02-25
18:55 ---
(In reply to comment #5)
> Patch looks ok to me (but I cannot approve it), can you please post it to
> gcc-patches for review?
>
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01193.htm
--- Comment #19 from bugzilla-gcc at thewrittenword dot com 2008-03-03
21:12 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00162.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-03-28
20:58 ---
(In reply to comment #2)
> (In reply to comment #1)
> > ld is running at this time so I doubt this is a GCC bug.
>
> The Pid it is referring to ("Pid 18929 received a SIGSEGV for st
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2008-03-29
02:21 ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > ld is running at this time so I doubt this is a GCC bug.
> >
> > The Pid it is refer
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2008-03-30
02:24 ---
Created an attachment (id=15398)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15398&action=view)
Patch for a generated file
This patch allowed the build to complete for us, unfortunately Make
--- Comment #36 from bugzilla-gcc at thewrittenword dot com 2009-02-11
19:03 ---
(In reply to comment #26)
> > We have filed case #65952072 with Sun to get this backported to Solaris 10.
>
> Do you have any news about this?
Sun just released patch 139574-03 for SPARC a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #142 from The Written Word
---
(In reply to Peter Bisroev from comment #133)
> The tests are from are binutils-2.32.
>
> - gas.log
> FAIL: .file file names
> FAIL: .file file names ordering
> FAIL: .equ redefinitions (ELF)
> FAIL: .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #143 from The Written Word
---
(In reply to Peter Bisroev from comment #131)
> ...
>
> After a bit of digging around looks
> like my ar and ranlib binaries from binutils are not working properly. For
> example:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #144 from The Written Word
---
(In reply to Peter Bisroev from comment #135)
> I just had a chance to do some testing tonight. So attempting to bootstrap
> 8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
The Written Word changed:
What|Removed |Added
Attachment #46623|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #146 from The Written Word
---
(In reply to The Written Word from comment #142)
> (In reply to Peter Bisroev from comment #133)
> > The tests are from are binutils-2.32.
> >
> > - gas.log
> > FAIL: .file file names
> > FAIL: .file f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #148 from The Written Word
---
(In reply to The Written Word from comment #144)
> We have a build running that seems to be going well. We are using gcc-4.9.4
> to build 8.3.0. I will attach the current patch set we are building again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #150 from The Written Word
---
(In reply to Peter Bisroev from comment #149)
> (In reply to The Written Word from comment #148)
> > (In reply to The Written Word from comment #144)
> > > We have a build running that seems to be going
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54091
--- Comment #3 from The Written Word
2012-10-05 21:36:42 UTC ---
(In reply to comment #1)
> Have you tried with a current release, 4.6 or 4.7?
>
> The 4.4 release series is closed and no longer maintained.
Sorry, missed this. I'll try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
--- Comment #1 from The Written Word
2011-01-27 20:06:40 UTC ---
John David Anglin pointed us to bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544 so we backported the patch to
4.4 and tried it.
With r163461 backported (compiler only built
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47852
Summary: crash with g++ -lpthread on irix
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
--- Comment #7 from The Written Word
2011-08-20 03:34:48 UTC ---
(In reply to comment #4)
> This should be fixed. Albert, can you confirm that the pthread active
> changes fixed this problem?
>
> Regarding comment #3, look at the libgomp test l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
Bug #: 53327
Summary: Invalid ASM being generated
Classification: Unclassified
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
--- Comment #1 from The Written Word
2012-05-11 18:30:02 UTC ---
Created attachment 27381
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27381
a.c from -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327
--- Comment #2 from The Written Word
2012-05-11 18:31:55 UTC ---
Created attachment 27382
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27382
Assembler file from -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54091
Bug #: 54091
Summary: internal compiler error in class method with many
string objects
Classification: Unclassified
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54100
Bug #: 54100
Summary: Problems building libjava on AIX 5.2
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54100
--- Comment #1 from The Written Word
2012-07-27 04:24:59 UTC ---
Tried building 4.7.1 on AIX 6.1 and 7.1 and get a similar error.
$ cd /opt/build/china
$ bzip2 -dc gcc-4.7.1.tar.bz2 | tar xf -
$ mkdir gcc-4.7.1-o
$ cd gcc-4.7.1-o
$ CONFIG_SHELL=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #74 from The Written Word
---
(In reply to C. Heide from comment #73)
> With that change, and some other cajoling (the previously mentioned
> duplicate symbols and operand64 problem, and -O1 to work around the ICE), I
> can now get g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #75 from The Written Word
---
(In reply to The Written Word from comment #74)
> (In reply to C. Heide from comment #73)
> > With that change, and some other cajoling (the previously mentioned
> > duplicate symbols and operand64 probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #76 from The Written Word
---
(In reply to The Written Word from comment #75)
> (In reply to The Written Word from comment #74)
> >
> > I'm getting further in the build on HP-UX 11.31/IA but when linking
> > libstdc++.la, I get lots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #78 from The Written Word
---
(In reply to dave.anglin from comment #77)
>
> I think you need to define _XOPEN_SOURCE_EXTENDED. See for example
> config/pa/pa-hpux11.h.
Yep. I forgot about PR66319.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #86 from The Written Word
---
(In reply to C. Heide from comment #79)
> (In reply to The Written Word from comment #75)
> >
> > I think a local patch might be doing this. Rebuild without it.
>
> I did have some other patches applie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #87 from The Written Word
---
(In reply to EML from comment #80)
> During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into
> the MPFR directory and re-run the same configure line from config.log, but
> add --disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #88 from The Written Word
---
(In reply to The Written Word from comment #78)
> (In reply to dave.anglin from comment #77)
> >
> > I think you need to define _XOPEN_SOURCE_EXTENDED. See for example
> > config/pa/pa-hpux11.h.
>
> Ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #95 from The Written Word
---
(In reply to dave.anglin from comment #92)
> On 2019-07-23 5:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > Yeah, we had PR64919 applied and backed out only th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #94 from The Written Word
---
Created attachment 46623
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46623&action=edit
gcc-8.3.0 patches
Patches currently being used to build gcc-8.3.0 on HP-UX/IA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #96 from The Written Word
---
(In reply to dave.anglin from comment #91)
> On 2019-07-23 5:53 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > In file included from
> > /opt/build/china/gcc-8.3.0/.obj/ia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #97 from The Written Word
---
(In reply to C. Heide from comment #73)
> With that change, and some other cajoling (the previously mentioned
> duplicate symbols and operand64 problem, and -O1 to work around the ICE), I
> can now get g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #99 from The Written Word
---
(In reply to C. Heide from comment #98)
> (In reply to The Written Word from comment #97)
> > (In reply to C. Heide from comment #73)
> > > With that change, and some other cajoling (the previously menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #11 from The Written Word
---
(In reply to dave.anglin from comment #10)
> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
> > Dave, are you aware of anybody testing ia64-hpux?
> > Should it be deprecated if nobody is maintai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #14 from The Written Word
---
(In reply to dave.anglin from comment #10)
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
We reached out to Jim Wilson in 2016 and got a reply back. He no longer has
access to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #13 from The Written Word
---
(In reply to dave.anglin from comment #12)
> It might help to compile stage1 with -O2 or -Os. This might reduce offset
> and get a newer version
> of gcc to build. gcc-8.3.0 seems to have built okay on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #15 from The Written Word
---
(In reply to dave.anglin from comment #12)
> It might help to compile stage1 with -O2 or -Os.
How does one do this? After ./configure, "gmake CFLAGS=-Os"? BOOT_CFLAGS
applies to stage2/3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #24 from The Written Word
---
(In reply to EML from comment #22)
> Thanks for the hints and options
>
> on IA64, I used the GNU AS (2.32), but the HP LD (ld: 92453-07 linker ld HP
> Itanium(R) B.12.65 IPF/IPF)
Do you have this pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #27 from The Written Word
---
(In reply to dave.anglin from comment #26)
> On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote:
> > If I replace those 3 lines and run the assembler+linker by hand - the
> > non-working foo.s will ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #28 from The Written Word
---
(In reply to EML from comment #17)
> Note that in certain cases, the MPFR library won't build depending on the
> CFLAGS used (in particular the default -g -O2), this is due to problems with
> thread loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #30 from The Written Word
---
(In reply to dave.anglin from comment #29)
> On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc
> > -B/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #38 from The Written Word
---
I rebuilt 8.3.0 with minimal patches and am seeing the same failure as before.
From /ia64-hp-hpux11.31/libstdc++-v3/config.log:
configure:7964: checking for ANSI C header files
configure:7984: /opt/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #39 from The Written Word
---
(In reply to EML from comment #25)
> I have applied the patch and tried your other suggestions, still the stage1
> compiler has the same problems generating executables.
>
> In analyzing the intermediat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #40 from The Written Word
---
Created attachment 46560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46560&action=edit
Revert PR60465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #41 from The Written Word
---
(In reply to The Written Word from comment #39)
> (In reply to EML from comment #25)
> > I have applied the patch and tried your other suggestions, still the stage1
> > compiler has the same problems gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #43 from The Written Word
---
(In reply to dave.anglin from comment #42)
> On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I can now duplicate what you're seeing:
> > $ diff -u gcc-4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #46 from The Written Word
---
(In reply to dave.anglin from comment #45)
>
> You could dump the RTL by adding "-da" to the compile options. Then, you
> could upload the "final" file.
I am uploading hello.c, hello.s, and hello.c.313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #47 from The Written Word
---
Created attachment 46563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46563&action=edit
Hello.c test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #48 from The Written Word
---
Created attachment 46564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46564&action=edit
hello.s assembly output of hello.c
/opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc
-B/opt/build/china/gcc-8.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #49 from The Written Word
---
Created attachment 46565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46565&action=edit
hello.c compiled with -da
/opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj-/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #51 from The Written Word
---
(In reply to dave.anglin from comment #50)
> On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
> I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #53 from The Written Word
---
(In reply to EML from comment #52)
> Note, regardless of reverting the gprel patch, GCC 8 puts the data in
> .rodata.
>
> However, doesn't gcc 4.9.x do the same thing, it just moves it to GOT with
> lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #54 from The Written Word
---
(In reply to EML from comment #52)
> objdump -h -s foo
> Contents of section .rodata:
> 40007f8 48656c6c 6f732057 6f726c64 00Hellos World.
>
>
> So gcc 4.9.x also puts the string into rodat
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-8.1.0 on AIX 5.3 as follows:
$ gtar Jxf gcc-8.1.0.tar.xz
$ cd gcc-8.1.0
$ mkdir .obj
$ cd .obj
$ PATH=/opt/TWWfsw/gcc47/bin:$PATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #1 from The Written Word
---
I get a similar failure on AIX 5.2 with gcc-7.2.0 and gcc-8.1.0.
: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-7.2.0 on AIX 5.3 as follows:
$ gtar Jxf gcc-7.2.0.tar.xz
$ cd gcc-7.2.0
$ mkdir .obj
$ cd .obj
$ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559
--- Comment #1 from The Written Word
---
Might be a duplicate of PR64081.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #2 from The Written Word
---
gcc-6.4.0 on AIX 5.3 exhibits a similar failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #5 from The Written Word
---
Created attachment 44405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44405&action=edit
Preprocessed source for math_stubs_long_double.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559
--- Comment #3 from The Written Word
---
(In reply to Jonathan Wakely from comment #2)
> (In reply to The Written Word from comment #1)
> > Might be a duplicate of PR64081.
>
> Wrong bug number?
I was looking at bug 64081 comment 31.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663
--- Comment #4 from The Written Word
---
(In reply to The Written Word from comment #3)
> (In reply to David Edelsohn from comment #2)
> > Group Bull, Perzl, and I have been able to build it. Are you using an up to
> > date AIX Assembler?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #9 from The Written Word
---
(In reply to Jonathan Wakely from comment #7)
> As I suspected, something is doing:
>
> #define fabsl(X) fabs((double) (X))
> #define acosl(X) acos((double) (X))
> etc.
/usr/include/math.h on this platf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #10 from The Written Word
---
(In reply to Jonathan Wakely from comment #8)
> Created attachment 44406 [details]
> Undefine macros for long double math functions
>
> Does this fix the build?
I am trying a similar patch. I basically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663
--- Comment #6 from The Written Word
---
(In reply to David Edelsohn from comment #5)
> GCC 4.9 is quite old now and out of service. If there is a bug in GCC 4.9,
> it will not be fixed because there are no bug fix releases planned.
Understood
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663
--- Comment #8 from The Written Word
---
(In reply to The Written Word from comment #6)
> gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build
> gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c
> successfully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663
--- Comment #9 from The Written Word
---
(In reply to David Edelsohn from comment #7)
> I use GCC 4.6 to bootstrap. It appears that the error is caused by the
> "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is
> generati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #11 from The Written Word
---
(In reply to Jonathan Wakely from comment #7)
> As I suspected, something is doing:
>
> #define fabsl(X) fabs((double) (X))
> #define acosl(X) acos((double) (X))
> etc.
>
> This would probably be solve
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-7.2.0 on HP-UX 11.31/PA as follows:
$ gtar Jxf gcc-7.2.0.tar.xz
$ cd gcc-7.2.0
$ mkdir .obj
$ cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #1 from The Written Word
---
I get a similar error with 8.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #35 from The Written Word
---
I am trying to build 4.9.4 with a patched 4.7.4 and am running into the
following failure:
/opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc
-B/opt/build/china/gcc-4.9.4/.obj/./gcc/
-B/opt/build/gcc49/ia64-hp-h
1 - 100 of 216 matches
Mail list logo
