[Bug c++/38581] New: Tru64 outputs non-virtual thunks as non-weak symbols

[bugzilla-gcc at thewrittenword dot com]

When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1
(alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about
duplicate non-virtual thunks, e.g. from qt:
/usr/ccs/bin/ld:
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
QDragMoveEvent::~QDragMoveEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
QDragMoveEvent::~QDragMoveEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
QDragEnterEvent::~QDragEnterEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
QDragEnterEvent::~QDragEnterEvent(): multiply defined

This appears to be because the non-virtual thunks are not output weak on this
platform, so, those that appear in multiple objects will cause linker errors
like this (in the above case, there are _ZThn16_N14QDragMoveEventD0Ev and
_ZThn16_N14QDragMoveEventD1Ev in both qdnd_x11.o and qmotifdnd_x11.o).

This is easily reproducible, for example, compiling a slightly modified version
of dllexport-MI1.C from the g++ testsuite.

With gcc-4.2.4:
% g++ -c -o dllexport-MI1.o dllexport-MI1.C; nm -wB dllexport-MI1.o | grep Thn
0x00 N  $_ZThn8_N3MI1D0Ev..ng
0x00 N  $_ZThn8_N3MI1D1Ev..ng
0x00 N  $_ZThn8_NK3MI12vfEv..ng
0x000854 T  _ZThn8_N3MI1D0Ev
0x000910 T  _ZThn8_N3MI1D1Ev
0x000208 T  _ZThn8_NK3MI12vfEv

When compared to gcc-3.4.3:
g++ -c -o dllexport-MI1.o dllexport-MI1.C; nm -wB dllexport-MI1.o | grep Thn
0x00 N  $_ZThn8_N3MI1D0Ev..ng
0x00 N  $_ZThn8_N3MI1D1Ev..ng
0x00 N  $_ZThn8_NK3MI12vfEv..ng
0x000344 T* _ZThn8_N3MI1D0Ev
0x000548 T* _ZThn8_N3MI1D1Ev
0x0001f0 T* _ZThn8_NK3MI12vfEv

The '*' in the nm output indicates a weak symbol.


-- 
   Summary: Tru64 outputs non-virtual thunks as non-weak symbols
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu 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

[Bug c++/38581] Tru64 outputs non-virtual thunks as non-weak symbols

[bugzilla-gcc at thewrittenword dot com]

--- 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 of dllexport-MI1.C (really just removed the
__attribute__ ((dllexport)), as they caused warnings).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581

[Bug target/38581] Tru64 outputs non-virtual thunks as non-weak symbols

[bugzilla-gcc at thewrittenword dot com]

--- 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

[Bug bootstrap/24688] New: sco_math fixincl breaks math.h

[bugzilla-gcc at thewrittenword dot com]

I'm trying to bootstrap gcc-3.4.3 on HP-UX 11.23/IA-64. I'm bootstrapping with
the HP C compiler. The system has patch PHSS_33351 installed. The tail of
/usr/include/math.h:
   inline int sqr(int __x) {return(__x*__x);}
   inline double sqr(double __x) {return(__x*__x);}
#  ifndef _STDLIB_INCLUDED
 inline int abs(int __d) { return (__d>0)?__d:-__d; }
#  endif /* _STDLIB_INCLUDED */
   inline double abs(double __d) { return fabs(__d); }
   inline double pow(double __d,int __expon) { return pow(__d,(double)__expon);
}
#endif

#endif /* _MATH_INCLUDED */

The tail of math.h after fixinc:
   inline double sqr(double __x) {return(__x*__x);}
#  ifndef _STDLIB_INCLUDED
 inline int abs(int __d) { return (__d>0)?__d:-__d; }
#  endif /* _STDLIB_INCLUDED */
#ifndef __GNUC__
   inline double abs(double __d) { return fabs(__d); }
   inline double pow(double __d,int __expon) { return pow(__d,(double)__expon);
}
#endif

#endif /* _MATH_INCLUDED */

Looking at inclhack.def, sco_math seems to be the cause of this. I replaced
'inline double abs' in select of sco_math with 'inline double _abs' and the
#ifndef __GNUC__ wasn't included in the new math.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: bugzilla-gcc at thewrittenword dot com
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688

[Bug bootstrap/24688] sco_math fixincl breaks math.h

[bugzilla-gcc at thewrittenword dot com]

--- 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't see anything relating to this.

Looking at the latest inclhack.def from gcc-3_4-branch, this sed line in
sco_math is causing the problem:
sed  = "/extern \"C\\+\\+\"/N;"
   "/inline double abs/i\\\n"
   "#ifndef __GNUC__\n";

I have no idea what math.h looks like on SCO so I have no idea how to fix. Why
don't we restrict sco_math to some mach="*sco*"?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688

[Bug driver/24718] New: Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
  $ gmake
  ...  
  gcc -v -o libperl.so -shared -fPIC perl.o  gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o
sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o
taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o
numeric.o locale.o pp_pack.o pp_sort.o  -lcl -lnsl -lnm -ldl -ldld -lm
-lsec -lpthread -lc
  ...
 /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2
+Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc
^^^

Notice the "-lgcc -lgcc" at the end of the collect2 command-line, not "-lgcc_s
-lgcc_s".

On HP-UX 11.23/PA-RISC, I get:
  /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2
-z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s

Using the HP pre-compiled binary of gcc-4.0.2, I get:
 /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2
-z +Accept TypeMismatch -b -o libperl.so
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../..
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s
-lunwind

The "*libgcc" line from the 3.4.3/3.4.4 specs file:
  *libgcc:
  %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M
-lunwind%{!shared-libgcc:-lgcc}

The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs):
  *libgcc:
  %{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}

Is the problem in the "*libgcc" entry? It seems !shared-libgcc is true, though
I don't know why.
  $ /opt/TWWfsw/gcc343/bin/gcc -v
  Reading specs from
  /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs
  Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as
  --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as
  --with-included-gettext --enable-shared
  --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77
  --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343
  Thread model: single
  gcc version 3.4.3 (TWW)


-- 
   Summary: Shared libgcc not used for linking by default
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  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: ia64-hp-hpux11.23


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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.4.x sources as I do 
> not
> see this problem in the FSF sources.

Note the HP gcc-3.4.4 binary had the same problem. I just built gcc-3.4.4 with
just one patch to fix the sco_math issue in PR24688:
  http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html

The new binary exhibits the same problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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 it
> seems like this might have happened, that in 3.4 (with C) -shared does not
> imply -shared-libgcc but in 4.0 it does.

If -shared did not imply -shared-libgcc, why does gcc -shared on HP-UX
10.20/PA, 11.00/PA, 11.11/PA, and 11.23/PA behave as if -shared-libgcc was
included? The question is why HP-UX 11.23/IA-64 is different than HP-UX/PA.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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  2005-11-08 21:22 ---
> > I am not convinced that this is a bug.
> 
> There is an obvious bug.  Have you actually looked at the specs in 
> question?  They have %{shared-libgcc ... %{static-libgcc ...}} which 
> can't possibly be right.
> 
> However, there is no bug in FSF gcc.  I suspect a bug in the gcc sources 
> being distributed from the HP web site.  I haven't checked that.

As indicated in comment #2, we built gcc-3.4.4 from the FSF sources and still
encountered the bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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 table in
> /proj/opensrc/sje/test2/gcc-ia
> 64-hp-hpux11.23-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a, it might be
> mis
> sing or corrupted. Skipping library
> /proj/opensrc/sje/test2/gcc-ia64-hp-hpux11.2
> 3-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a.
> 
> because libgcc_eh.a is empty.  For some reason on 3.4 this file is completely
> empty (nm returns nothing) but on ToT the file is mostly empty, but it has
> a symbol table and empty test/bss/data and debug sections in it.  On 3.4 I 
> have
> no symbol table in the file which is why I get the warning message.  I used 
> the
> same binutils for each compiler so I don't know yet why there is this
> difference.
> 

Look at gcc/mklibgcc.in in the 4.0 branch. They add a dummy eh_dummy.o file to
libgcc_eh.a to work around this. We had Eric Botcazou backport it to the 3.4
branch for us but a PR hasn't been created. I don't know if its considered a
safe enough fix. I haven't tested it yet but I'll attach the patch to this PR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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
> eh_dummy.o. I do not getting any warnings messages from ld when compiling and
> linking C or C++, with or without -mlp64 and with or without -shared.

Odd. We have the latest linker patch installed on our system (PHSS_33349) and
applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave
a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to
the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us.

Looking at Zack's patch, I don't see how eh_dummy.o would get added to
libgcc_eh.a on gcc-3.4 without adding it to $libgcc2_eh_static_objs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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-2.16 with _no_ patches but
ar doesn't work:
$ ./ar
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module
'/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module
'/usr/lib/hpux32/libl.so.1'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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 ar/ranlib by just building eh_dummy.o and .a by hand and they look OK 
> to
> me, I.e. they have a symbol table in them and thus should not get the warning
> message.

Ok, I have a working binutils-2.16 ar. And, binutils-2.16 ar creates a
libgcc_eh.a that does not cause linker errors whereas HP as does _not_, with
the _same_ eh_dummy.o file. Replace your libgcc_eh.a in your GCC tree with the
version created by the system ar and I expect you'll see the same as me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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
> reproduce it using the binutils as (assembler) command.  Which assembler are
> you using when you get the problem.

Oops. "HP as" -> "HP ar". So, with a eh_dummy.o created from an eh_dummy.c with
'struct eh_dummy;', libgcc_eh.a created by HP ar gives me a linker warning and
a libgcc_eh.a created by binutils-2.16 ar does not give me a linker warning.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug ada/24356] Unable to build gnatmake

[bugzilla-gcc at thewrittenword dot com]

--- 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

[Bug ada/24356] Unable to build gnatmake

[bugzilla-gcc at thewrittenword dot com]

--- 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-UX,UNIX 2005/12/22  s700_800 11.23 LIBCL patch

The list of changes relative to our current version PHSS_33405:
  JAGaf80041: Applications built with -Wl,-a,archive -z i
  result in a run time core dump
  JAGaf77560: f90 application aborting when trying to
  write shared common data to stdout

So, I don't expect the new patch to resolve this problem on 4.0.2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356

[Bug libstdc++/24345] libstdc++ build failure with IRIX ld(1)

[bugzilla-gcc at thewrittenword dot com]

--- 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't consider this a libstdc++ problem.

Ok.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24345

[Bug fortran/33090] New: Unable to build on AIX 4.3.3

[bugzilla-gcc at thewrittenword dot com]

gfortran won't build on AIX 4.3.3 as it doesn't have weak support:
...
/opt/build/gcc-4.1.2-objdir/./gcc/xgcc -B/opt/build/gcc-4.1.2-objdir/./gcc/
-B/o
pt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/bin/
-B/opt/TWWfsw/gcc41/powerpc-ibm-aix4
.3.3.0/lib/ -isystem /opt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/include -isystem
/
opt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/sys-include -DHAVE_CONFIG_H -I.
-I/opt/b
uild/gcc-4.1.2/libgfortran -I. -iquote/opt/build/gcc-4.1.2/libgfortran/io
-I/opt
/build/gcc-4.1.2/libgfortran/../gcc
-I/opt/build/gcc-4.1.2/libgfortran/../gcc/co
nfig -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissi
ng-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2
-pthread
 -c /opt/build/gcc-4.1.2/libgfortran/runtime/environ.c   -DPIC -o
.libs/environ.
o
In file included from /opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-aix.h:33,
 from ../../.././gcc/gthr-default.h:1,
 from /opt/build/gcc-4.1.2/libgfortran/../gcc/gthr.h:114,
 from /opt/build/gcc-4.1.2/libgfortran/runtime/../io/io.h:36,
 from /opt/build/gcc-4.1.2/libgfortran/runtime/environ.c:37:
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:92: warning: weak
declarati
on of '__gthrw_pthread_once' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:93: warning: weak
declarati
on of '__gthrw_pthread_getspecific' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:94: warning: weak
declarati
on of '__gthrw_pthread_setspecific' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:95: warning: weak
declarati
on of '__gthrw_pthread_create' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:96: warning: weak
declarati
on of '__gthrw_pthread_cancel' not supported
...

I am building with --enable-threads.


-- 
   Summary: Unable to build on AIX 4.3.3
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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

[Bug fortran/33090] Unable to build on AIX 4.3.3

[bugzilla-gcc at thewrittenword dot com]

--- 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
> build?

Oops. I'll rebuild and post the error. Sorry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33090

[Bug ada/35155] New: Ada not building on gcc-4.2.3

[bugzilla-gcc at thewrittenword dot com]

Ada in gcc-4.2.3 does not build with a pre-existing Ada build from gcc-3.4.3:
  $ bzip2 -dc gcc-4.2.3.tar.bz2 | tar xf -
  $ mkdir gcc-4.2.3-objdir
  $ cd gcc-4.2.3-objdir
  $ LIBPATH=/opt/TWWfsw/libgmp42/lib:/opt/TWWfsw/libmpfr22/lib CC=gcc bash
/opt/build/china/gcc-4.2.3/configure --enable-nls --with-included-gettext
--enable-shared --enable-threads --with-gmp=/opt/TWWfsw/libgmp42
--with-mpfr=/opt/TWWfsw/libmpfr23 --enable-languages="c,ada"
  ...
  $ LIBPATH=/opt/TWWfsw/libgmp42/lib:/opt/TWWfsw/libmpfr22/lib gmake bootstrap
  ...
  /opt/build/china/gcc-4.2.3-objdir/./prev-gcc/xgcc
-B/opt/build/china/gcc-4.2.3-objdir/./prev-gcc/
-B/usr/local/powerpc-ibm-aix5.1.0.0/bin/   -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H
-Wl,-bbigtoc gcov-dump.o version.o errors.o ../libcpp/libcpp.a
./../intl/libintl.a -liconv  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -o gcov-dump
  /opt/build/china/gcc-4.2.3-objdir/./prev-gcc/xgcc
-B/opt/build/china/gcc-4.2.3-objdir/./prev-gcc/
-B/usr/local/powerpc-ibm-aix5.1.0.0/bin/ -c -g -O2  -mminimal-toc -I- -I.
-Iada -I/opt/build/china/gcc-4.2.3/gcc/ada
/opt/build/china/gcc-4.2.3/gcc/ada/ada.ads -o ada/ada.o
  ada.ads:16:01: language defined units may not be recompiled


-- 
   Summary: Ada not building on gcc-4.2.3
   Product: 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 host triplet: powerpc-ibm-aix5.1.0.0
GCC target triplet: powerpc-ibm-aix5.1.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35155

[Bug bootstrap/35169] New: SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

IN_GCC   
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
-Wl,+h,libgcc_s.so.0 -o ./libgcc_s.so  libgcc/./__divxf3_s.o
libgcc/./__divdf3_s.o libgcc/./__divsf3_s.o libgcc/./__divdi3_s.o
libgcc/./__moddi3_s.o libgcc/./__udivdi3_s.o libgcc/./__umoddi3_s.o
libgcc/./__divsi3_s.o libgcc/./__modsi3_s.o libgcc/./__udivsi3_s.o
libgcc/./__umodsi3_s.o libgcc/./__save_stack_nonlocal_s.o
libgcc/./__nonlocal_goto_s.o libgcc/./__restore_stack_nonlocal_s.o
libgcc/./__trampoline_s.o libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o
libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o
libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o
libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o
libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o
libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o
libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o
libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o
libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o
libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o
libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o
libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o
libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o
libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o
libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o
libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o
libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o
libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o
libgcc/./quadlib_s.o libgcc/./floatunsitf_s.o -lunwind -lc && rm -f
./libgcc_s.so.0 && ln -s libgcc_s.so ./libgcc_s.so.0
/opt/build/china
Pid 18942 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz. 
/gcc-4.2.3-objdir/./gcc/xgcc -B/opt/build/china/gcc-4.2.3-objdir/./gcc/
-B/usr/local/ia64-hp-hpux11.23/bin/ -B/usr/local/ia64-hp-hpux11.23/lib/
-isystem /usr/local/ia64-hp-hpux11.23/include -isystem
/usr/local/ia64-hp-hpux11.23/sys-include -O2  -O2 -g  -DIN_GCC   
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I/opt/build/china/gcc-4.2.3/gcc
-I/opt/build/china/gcc-4.2.3/gcc/ -I/opt/build/china/gcc-4.2.3/gcc/../include
-I./../intl -I/opt/build/china/gcc-4.2.3/gcc/../libcpp/include 
-I/opt/build/china/gcc-4.2.3/gcc/../libdecnumber -I../libdecnumber -DSHARED
-mlp64 -DL__divxf3 -xassembler-with-cpp -c
/opt/build/china/gcc-4.2.3/gcc/config/ia64/lib1funcs.asm -o
libgcc/hpux64/__divxf3_s.o
gmake[4]: *** [libgcc/hpux64/__divxf3_s.o] Segmentation fault (core dumped)
gmake[4]: Leaving directory `/opt/build/china/gcc-4.2.3-objdir/gcc'
gmake[3]: *** [stmp-multilib] Error 2
gmake[3]: Leaving directory `/opt/build/china/gcc-4.2.3-objdir/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/opt/build/china/gcc-4.2.3-objdir'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/opt/build/china/gcc-4.2.3-objdir'
gmake: *** [bootstrap] Error 2

  $ limit
  cputime unlimited
  filesizeunlimited
  datasize1024MB
  stacksize   128MB
  coredumpsize2047MB
  residentunlimited
  descriptors 2048
  addressspaceunlimited
  cachedthreads   256
  aiooperations   unlimited
  aiomemorylocked unlimited
  RSESTACK8388608


-- 
   Summary: SIGSEGV for stack growth failure while building 4.2.3
   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-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169

[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

--- 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/china/gcc-4.2.3-objdir/./gcc/xgcc. I ran the command
under tusc (similar to truss(1) on Solaris or strace(1) on Redhat) and there is
no call to ld.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169

[Bug bootstrap/35216] New: Out of memory building java

[bugzilla-gcc at thewrittenword dot com]

We're trying to build 4.2.3 on HP-UX 11.23/PA and get an out of memory error:
  $ bzip2 -dc gcc-4.2.3.tar.bz2 | tar xf -
  $ mkdir gcc-4.2.3-objdir
  $ cd gcc-4.2.3-objdir
  $ CC=cc bash /opt/build/china/gcc-4.2.3/configure --with-included-gettext
--enable-shared --with-gnu-as
--with-as=/opt/build/china/gcc423/hppa2.0w-hp-hpux11.23/bin/as
--enable-languages="c,c++,java"
  ...
  $ gmake bootstrap
  ...
/bin/sh ./libtool --mode=compile /opt/build/china/gcc-4.2.3-objdir/gcc/gcj
-B/opt/build/china/gcc-4.2.3-objdir/hppa2.0w-hp-hpux11.23/libjava/
-B/opt/build/china/gcc-4.2.3-objdir/gcc/ -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.2.3-objdir/hppa2.0w-hp-hpux11.23/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni
-findirect-dispatch -fno-indirect-classes -c -o gnu-xml.lo @gnu-xml.list
/opt/build/china/gcc-4.2.3-objdir/gcc/gcj
-B/opt/build/china/gcc-4.2.3-objdir/hppa2.0w-hp-hpux11.23/libjava/
-B/opt/build/china/gcc-4.2.3-objdir/gcc/ -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.2.3-objdir/hppa2.0w-hp-hpux11.23/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni
-findirect-dispatch -fno-indirect-classes -c @gnu-xml.list -fPIC -o
.libs/gnu-xml.o

jc1: out of memory allocating 4072 bytes after a total of 657973552 bytes

  $ limit
cputime unlimited
filesizeunlimited
datasize2048MB
stacksize   128MB
coredumpsize2047MB
residentunlimited
descriptors 2048
addressspaceunlimited
cachedthreads   256
aiooperations   unlimited
aiomemorylocked unlimited
RSESTACK0

The build system has 2GB real memory and 4GB swap. How much memory does
building java require?


-- 
   Summary: Out of memory building java
   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
  GCC host triplet: hppa2.0w-hp-hpux11.23
GCC target triplet: hppa2.0w-hp-hpux11.23


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35216

[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'

[bugzilla-gcc at thewrittenword dot com]

--- 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 generated files (configure, config.h.in)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131

[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'

[bugzilla-gcc at thewrittenword dot com]

--- 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 (stolen from libcpp)
> 
> Patch does not include generated files (configure, config.h.in)
> 

To elaborate, the attached patch fixes it for us because strncasecmp is
declared in strings.h, which is not being included. At first we went with the
unconditional inclusion of strings.h, but that seemed inappropriate, so we
copied what was in libcpp for string.h and strings.h.


-- 

bugzilla-gcc at thewrittenword dot com changed:

   What|Removed |Added

 CC|            |bugzilla-gcc at
   |            |thewrittenword dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131

[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'

[bugzilla-gcc at thewrittenword dot com]

--- 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.html

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[bugzilla-gcc at thewrittenword dot com]

--- 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

[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

--- 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 stack growth
> failure.") is /opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc.


Seems to be recursing in cancel_option until stack runs out:
Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555)
at /opt/build/gcc-4.2.3/gcc/opts-common.c:118
118   if (cl_options [next_opt_idx].neg_index == opt_idx)
(gdb) n
121   if (cl_options [next_opt_idx].neg_index != orig_next_opt_idx)
(gdb) 
122 return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index,
(gdb) 

Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555)
at /opt/build/gcc-4.2.3/gcc/opts-common.c:118
118   if (cl_options [next_opt_idx].neg_index == opt_idx)
(gdb) 
121   if (cl_options [next_opt_idx].neg_index != orig_next_opt_idx)
(gdb) 
122 return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index,
(gdb) 

Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555)
at /opt/build/gcc-4.2.3/gcc/opts-common.c:118
118   if (cl_options [next_opt_idx].neg_index == opt_idx)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169

[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

--- 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 referring to ("Pid 18929 received a SIGSEGV for stack growth
> > failure.") is /opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc.
> 
> 
> Seems to be recursing in cancel_option until stack runs out:
>

All due to a bug in awk on ia64-hpux11.23. Using gawk allows the build to
complete. Here is a selection of a diff from options.c generated with awk and
gawk:
   { "-W",
 "This switch is deprecated; use -Wextra instead",
-N_OPTS, 1, 0,
+N_OPTS, 1, -1,
 CL_COMMON | CL_REJECT_NEGATIVE,
 0, CLVC_BOOLEAN, 0 },


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169

[Bug bootstrap/35216] Out of memory building java

[bugzilla-gcc at thewrittenword dot com]

--- 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 Makefile.in is a
generated file, as is sources.am, which is generated by makemake.tcl. We have
not come up with a usable patch for makemake.tcl yet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35216

[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0

[bugzilla-gcc at thewrittenword dot com]

--- 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 and 139575-03 for x86. We've built
gcc-4.2.4 with the x86 patch and it resolved the issue for us.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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: .set with expression
> FAIL: good .bss / .struct data allocation directives
> FAIL: gas/elf/missing-build-notes
> FAIL: ia64 xdata (ilp32)
> FAIL: ia64 unwind descriptors
> 
> - binutils.log (they look like gas related failures)
> FAIL: assembler generated build notes
> FAIL: --localize-hidden test 1
> FAIL: readelf -S bintest
> 
> Are any of these tests critical and would you want me to look at them in
> more detail?

I get the same test failures with binutils-2.32.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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:
> 
> $ ./ar --help
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module
> '/usr/lib/hpux32/libl.so.1'.
> /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module
> '/usr/lib/hpux32/libl.so.1'.
> Killed
> 
> But those symbols are present in libl.so from what I can see. For now I am
> still using HP's ar and ranlib, will take a look into what is going on with
> binutils ar and ranlib a bit later.

We solve this by setting LEXLIB in the environment to a static verison of the
flex library. You could probably also set LEXLIB="-L
-Wl,+b, -lfl".

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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
> been shown before. If I compile stage1 with '-O2' only, stage1 compiles, but
> straight away we get
> --
> /home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc
> -nostdinc /dev/null -S -o /dev/null
> -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests
> cc1: internal compiler error: Segmentation fault
> --

This succeeds with our gcc-8.3.0 build:
$ /opt/build/china/gcc-8.3.0/.obj/prev-gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj/prev-gcc -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=/opt/build/china/gcc-8.3.0/gcc/testsuite/selftests 
-fself-test: 40028 pass(es) in 1.02 seconds

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 against.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

The Written Word  changed:

   What|Removed |Added

  Attachment #46623|0   |1
is obsolete||

--- Comment #145 from The Written Word  
---
Created attachment 47799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47799&action=edit
gcc-8.3.0 patches v2

v2 of our patch set.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 file names ordering
> > FAIL: .equ redefinitions (ELF)
> > FAIL: .set with expression
> > FAIL: good .bss / .struct data allocation directives
> > FAIL: gas/elf/missing-build-notes
> > FAIL: ia64 xdata (ilp32)
> > FAIL: ia64 unwind descriptors
> > 
> > - binutils.log (they look like gas related failures)
> > FAIL: assembler generated build notes
> > FAIL: --localize-hidden test 1
> > FAIL: readelf -S bintest
> > 
> > Are any of these tests critical and would you want me to look at them in
> > more detail?
> 
> I get the same test failures with binutils-2.32.

For binutils-2.25.1, test failures are:
$ grep FAIL gas.log
FAIL: .file file names
FAIL: .equ redefinitions (ELF)
FAIL: .set with expression
FAIL: ia64 psn
FAIL: ia64 xdata (ilp32)
FAIL: ia64 unwind descriptors
FAIL: lns-duplicate
FAIL: lns-common-1

For binutils-2.26, test failures are:
$ grep FAIL gas.log
FAIL: .file file names
FAIL: .equ redefinitions (ELF)
FAIL: .set with expression
FAIL: ia64 unwind descriptors
FAIL: lns-duplicate
FAIL: lns-common-1

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 against.

We're running into the same issues as encountered in comment#74. I think this
is because of our patch to address PR66319 so I am attempting a build without
it. We will then probably run into the problem in comment#76 but I'll try to
fix that manually and continue the build.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 well. We are using 
> > > gcc-4.9.4
> > > to build 8.3.0. I will attach the current patch set we are building 
> > > against.
> > 
> > We're running into the same issues as encountered in comment#74. I think
> > this is because of our patch to address PR66319 so I am attempting a build
> > without it. We will then probably run into the problem in comment#76 but
> > I'll try to fix that manually and continue the build.
> 
> Did you build your 4.9.4 or you are using a pre-built one? I am trying to
> build 4.9.4 using my 4.7.4 but at the end of stage1 I get
> --
> conftest.c:15:3: internal compiler error: Illegal instruction
> --
> This is a similar error as described in comment#21.

We built 4.9.4. Try 4.9.3 and you might have more success. On 4.9.4, you need
to look at PR60465. I think comment#63 here also provides a workaround but we
chose to revert the commit that caused the problem.

[Bug c++/54091] internal compiler error in class method with many string objects

[bugzilla-gcc at thewrittenword dot com]

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 to build 4.7 and retest.

[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[bugzilla-gcc at thewrittenword dot com]

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 with --enable-languages=c this
time) we ran the libgomp testsuite 3 times, failed 11/248 tests, 0/248 tests
and 9/248 tests. So, still not fantastic, but the 0/248 was nice to see.

However, the big win for us is that perl-5.12.2 built with the compiler with
the backported patch fails no tests at all where it used to fail many.

[Bug driver/47852] New: crash with g++ -lpthread on irix

[bugzilla-gcc at thewrittenword dot com]

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.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com
CC: r...@cebitec.uni-bielefeld.de
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


gcc-4.4.5 on IRIX 6.5 produces an executable that crashes at runtime if
-lpthread appears before -lstdc++ on the link line.


% echo 'int main() {}' >a.cpp
% g++ a.cpp -lpthread -pthread; ./a.out; echo $?
zsh: segmentation fault (core dumped)  ./a.out
139


See also the discussion here:

http://gcc.gnu.org/ml/gcc-help/2011-02/msg00335.html

http://gcc.gnu.org/ml/gcc-help/2011-02/msg00368.html

[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[bugzilla-gcc at thewrittenword dot com]

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 log file to see why the
> tests are failing on alphaev68-dec-osf5.1a.  I'm certain the problem
> is different from the hppa2.0w-hp-hpux11.31 issue, so a new PR
> should be opened.

It should be fixed in 4.4.6? What revision fixed the problem?

[Bug c/53327] New: Invalid ASM being generated

[bugzilla-gcc at thewrittenword dot com]

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
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com


Created attachment 27380
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27380
Problematic C source file

We have a 64-bit build of GCC 4.4.6 on hppa64-hp-hpux11.31 that, when compiling
a particular .c file, is returning an "Invalid operands" error:
  % /opt/TWWfsw/gcc64-44/bin/gcc -v
  Reading specs from /opt/TWWfsw/gcc64-44/lib/gcc/hppa64-hp-hpux11.31/4.4/specs
  Target: hppa64-hp-hpux11.31
  Configured with: /opt/build/gcc-4.4.6/configure --with-included-gettext
--enable-shared --with-gnu-as
--with-as=/opt/TWWfsw/gcc64-44/hppa64-hp-hpux11.31/bin/as
--with-gmp-include=/opt/TWWfsw/libgmp43/include
--with-gmp-lib=/opt/TWWfsw/libgmp43/lib/pa20_64
--with-mpfr-include=/opt/TWWfsw/libmpfr30/include
--with-mpfr-lib=/opt/TWWfsw/libmpfr30/lib/pa20_64
--with-gmp-ldflags=-Wl,+s,+b,/opt/TWWfsw/libgmp43/lib/pa20_64
--with-mpfr-ldflags=-Wl,+s,+b,/opt/TWWfsw/libmpfr30/lib/pa20_64
--datadir=/opt/TWWfsw/gcc64-44/share --with-x --enable-java-awt=xlib
--build=hppa64-hp-hpux11.31 --host=hppa64-hp-hpux11.31
--with-local-prefix=/opt/TWWfsw/gcc64-44
--with-gxx-include-dir=/opt/TWWfsw/gcc64-44/include/c++
--prefix=/opt/TWWfsw/gcc64-44
  Thread model: posix

  % /opt/TWWfsw/gcc64-44/bin/gcc -O2 -c a.c  
  /var/tmp//cc8ArhN4.s: Assembler messages:
  /var/tmp//cc8ArhN4.s:30: Error: Invalid operands

[Bug c/53327] Invalid ASM being generated

[bugzilla-gcc at thewrittenword dot com]

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

[Bug c/53327] Invalid ASM being generated

[bugzilla-gcc at thewrittenword dot com]

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

[Bug c++/54091] New: internal compiler error in class method with many string objects

[bugzilla-gcc at thewrittenword dot com]

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
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com


Created attachment 27870
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27870
output of g++ -save-temps command from description...

$ g++ -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: /opt/build/gcc-4.4.6/configure --enable-nls
--with-included-gettext --enable-shared --enable-threads
--with-local-prefix=/opt/TWWfsw/gcc44 --with-gmp=/opt/TWWfsw/libgmp43
--with-mpfr=/opt/TWWfsw/libmpfr30 --with-gmp-ldflags='-Wl,-brtl
-Wl,-blibpath:/opt/TWWfsw/libgmp43/lib:/usr/lib' --with-mpfr-ldflags='-Wl,-brtl
-Wl,-blibpath:/opt/TWWfsw/libmpfr30/lib:/usr/lib'
--enable-languages=ada,c,c++,fortran --datadir=/opt/TWWfsw/gcc44/share
--with-gxx-include-dir=/opt/TWWfsw/gcc44/include/c++ --prefix=/opt/TWWfsw/gcc44
Thread model: aix
gcc version 4.4.6 [TWW] (GCC) 
$ g++ -save-temps
-I/opt/TWWfsw/libwxgtk28/lib/gcc44/wx/include/gtk2-unicode-release-2.8
-I/opt/TWWfsw/libwxgtk28/include/gcc44 -D__WXGTK__ -O2 -c ice.cpp
: In member function 'void Ice::Segv()':
:1139: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

ice.ii attached.

Data points:

 * This bug was found when compiling code blocks-10.05 against wxGTK-2.8.12, in
the file src/plugins/contrib/headerfixup/defaults.cpp, but I removed the
majority of noise except '#include ' which is needed to trip the
bug.
 * Preprocessing the file separately, and then compiling the output works
correctly.
 * Removing a single one of the 1126 identical lines in Ice:Segv changes the
error to an out of memory fault.
 * Reducing optimisation to -O1 allows the compile to succeed.
 * Trying to factor away the wxString type (replacing L"x" with "x" and
wxString with string) allows compilation to succeed.

[Bug java/54100] New: Problems building libjava on AIX 5.2

[bugzilla-gcc at thewrittenword dot com]

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
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com


Tried building gcc-4.6.3 with gcj on AIX 5.2 but it didn't work.

$ cd /opt/build/china
$ bzip2 -dc gcc-4.6.3.tar.bz2 | tar xf -
$ mkdir gcc-4.6.3-o
$ cd gcc-4.6.3-o
$ CONFIG_SHELL=/opt/fsw/bash42/bin/bash /opt/build/china/gcc-4.6.3/configure
CC=xlc --enable-nls --with-included-gettext --enable-libgcj --enable-shared
--enable-threads --with-local-prefix=/opt/TWWfsw/gcc46
--with-gmp=/opt/TWWfsw/libgmp43 --with-mpfr=/opt/TWWfsw/libmpfr30
--with-mpc=/opt/TWWfsw/libmpc09 --enable-languages=c,c++,fortran,java
--with-ecj-jar=/opt/TWWfsw/gcc46/lib/gcj/ecj.jar
--with-gxx-include-dir=/opt/TWWfsw/gcc46/include/c++ --prefix=/opt/TWWfsw/gcc46
$ LDR_CNTRL=MAXDATA=0x7000 CONFIG_SHELL=/opt/fsw/bash42/bin/bash
LIBPATH=/opt/TWWfsw/libgmp43:/opt/TWWfsw/libmpfr30:/opt/TWWfsw/libmpc09 gmake
...
/opt/fsw/bash42/bin/bash ./libtool --tag=GCJ   --mode=compile
/opt/build/china/gcc-4.6.3-o/./gcc/gcj
-B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.6.3-o/./gcc/
-B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/bin/
-B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/lib/ -isystem
/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/include -isystem
/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/sys-include  -maix64 -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.6.3/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2  -maix64  -c -o
gnu/java/awt/peer.lo
-fsource-filename=/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/classpath/lib/classes
-MT gnu/java/awt/peer.lo -MD -MP -MF gnu/java/awt/peer.deps
@gnu/java/awt/peer.list
libtool: compile:  /opt/build/china/gcc-4.6.3-o/./gcc/gcj
-B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.6.3-o/./gcc/
-B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/bin/
-B/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/lib/ -isystem
/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/include -isystem
/opt/TWWfsw/gcc46/powerpc-ibm-aix5.2.0.0/sys-include -maix64 -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.6.3/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c
-fsource-filename=/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava/classpath/lib/classes
-MT gnu/java/awt/peer.lo -MD -MP -MF gnu/java/awt/peer.deps
@gnu/java/awt/peer.list  -o gnu/java/awt/.libs/peer.o
Assembler:
/tmp//ccSBHZ6k.s: line 5597: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccSBHZ6k.s: line 5599: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
gmake[5]: *** [gnu/java/awt/peer.lo] Error 1
gmake[5]: Leaving directory
`/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/ppc64/libjava'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory
`/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/libjava'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory
`/opt/build/china/gcc-4.6.3-o/powerpc-ibm-aix5.2.0.0/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/opt/build/china/gcc-4.6.3-o'
gmake: *** [all] Error 2

[Bug libgcj/54100] Problems building libjava on AIX 5.2

[bugzilla-gcc at thewrittenword dot com]

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=/opt/fsw/bash42/bin/bash /opt/build/china/gcc-4.7.1/configure
--enable-nls --with-included-gettext --enable-libgcj --enable-shared
--enable-threads --with-local-prefix=/opt/TWWfsw/gcc47
--with-gmp=/opt/TWWfsw/libgmp43 --with-mpfr=/opt/TWWfsw/libmpfr30
--with-mpc=/opt/TWWfsw/libmpc09 --enable-languages=c,c++,fortran,java
--with-ecj-jar=/opt/TWWfsw/gcc47/lib/gcj/ecj.jar
--with-gxx-include-dir=/opt/TWWfsw/gcc47/include/c++ --prefix=/opt/TWWfsw/gcc47
$ LDR_CNTRL=MAXDATA=0x7000 CONFIG_SHELL=/opt/fsw/bash42/bin/bash
LIBPATH=/opt/TWWfsw/libgmp43:/opt/TWWfsw/libmpfr30:/opt/TWWfsw/libmpc09 gmake
...
/opt/fsw/bash42/bin/bash ./libtool --tag=GCJ   --mode=compile
/opt/build/china/gcc-4.7.1-o/./gcc/gcj
-B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.7.1-o/./gcc/
-B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/bin/
-B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/lib/ -isystem
/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/include -isystem
/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/sys-include  -maix64 -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.7.1/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2  -maix64  -c -o
gnu/java/awt/color.lo
-fsource-filename=/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/classpath/lib/classes
-MT gnu/java/awt/color.lo -MD -MP -MF gnu/java/awt/color.deps
@gnu/java/awt/color.list
libtool: compile:  /opt/build/china/gcc-4.7.1-o/./gcc/gcj
-B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/
-B/opt/build/china/gcc-4.7.1-o/./gcc/
-B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/bin/
-B/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/lib/ -isystem
/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/include -isystem
/opt/TWWfsw/gcc47/powerpc-ibm-aix6.1.0.0/sys-include -maix64 -fclasspath=
-fbootclasspath=/opt/build/china/gcc-4.7.1/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -maix64 -c
-fsource-filename=/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava/classpath/lib/classes
-MT gnu/java/awt/color.lo -MD -MP -MF gnu/java/awt/color.deps
@gnu/java/awt/color.list  -o gnu/java/awt/.libs/color.o
Assembler:
/tmp//ccAWagdt.s: line 2049: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2051: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2053: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2057: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2059: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2061: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2069: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2071: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2075: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2081: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2083: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
/tmp//ccAWagdt.s: line 2085: 1252-149 Instruction fsel is not implemented in
the current assembly mode PPC64.
gmake[5]: *** [gnu/java/awt/color.lo] Error 1
gmake[5]: Leaving directory
`/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/ppc64/libjava'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory
`/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/libjava'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory
`/opt/build/china/gcc-4.7.1-o/powerpc-ibm-aix6.1.0.0/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/opt/build/china/gcc-4.7.1-o'
gmake: *** [all] Error 2

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.
> 
> I haven't run the GCC testsuite yet, but it was able to build an internal
> C++ app and pass its unit tests, though it did still need the duplicate
> symbol workaround when linking (added -Wl,+allowdups).

I'm getting further in the build on HP-UX 11.31/IA but when linking
libstdc++.la, I get lots of:
ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in
files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
.libs/libstdc++.lax/libsupc++convenience.a/guard.o
ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in
files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
.libs/libstdc++.lax/libsupc++convenience.a/guard.o
ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error" in
files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
.libs/libstdc++.lax/libsupc++convenience.a/guard.o
...

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 problem, and -O1 to work around the ICE), I
> > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.
> > 
> > I haven't run the GCC testsuite yet, but it was able to build an internal
> > C++ app and pass its unit tests, though it did still need the duplicate
> > symbol workaround when linking (added -Wl,+allowdups).
> 
> I'm getting further in the build on HP-UX 11.31/IA but when linking
> libstdc++.la, I get lots of:
> ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in
> files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in
> files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error"
> in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> ...

I think a local patch might be doing this. Rebuild without it.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 of:
> > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in
> > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> > .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in
> > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> > .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> > ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error"
> > in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and
> > .libs/libstdc++.lax/libsupc++convenience.a/guard.o
> > ...
> 
> I think a local patch might be doing this. Rebuild without it.

Getting further. Now erroring out with:
/opt/build/china/gcc-8.3.0/.obj/./prev-gcc/xg++
-B/opt/build/china/gcc-8.3.0/.obj/./prev-gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -nostdinc++
-B/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-B/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs

-I/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
 -I/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include 
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++
-L/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I/opt/build/china/gcc-8.3.0/gcc -I/opt/build/china/gcc-8.3.0/gcc/.
-I/opt/build/china/gcc-8.3.0/gcc/../include -I./../intl
-I/opt/build/china/gcc-8.3.0/gcc/../libcpp/include
-I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include
-I/opt/TWWfsw/libmpc10/include 
-I/opt/build/china/gcc-8.3.0/gcc/../libdecnumber
-I/opt/build/china/gcc-8.3.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/opt/build/china/gcc-8.3.0/gcc/../libbacktrace
-I/opt/TWWfsw/libisl016/include  -o gcov-tool.o -MT gcov-tool.o -MMD -MP -MF
./.deps/gcov-tool.TPo /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c
/opt/build/china/gcc-8.3.0/gcc/gcov-tool.c: In function 'int
unlink_profile_dir(const char*)':
/opt/build/china/gcc-8.3.0/gcc/gcov-tool.c:85:23: error: invalid conversion
from 'int (*)(const char*, const stat*, int, FTW*)' to 'int (*)(const char*,
const stat*, int, FTW)' [-fpermissive]
 return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);
   ^~~~
In file included from /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c:39:
/usr/include/ftw.h:273:38: note:   initializing argument 2 of 'int nftw(const
char*, int (*)(const char*, const stat*, int, FTW), int, int)'
  inline int nftw(const char *a,int (*b)(const char *, const struct
~~^
   stat *, int, struct FTW), int c, int d)
   
gmake[3]: *** [gcov-tool.o] Error 1

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 applied from other PRs, from previous
> desperate attempts to get anything working, including PR90714, PR85412,
> PR87338, and tips from PR64919.
> 
> I'm doing some more testing with combinations of them, and so far I've found
> that if I start from a fresh 8.3 and apply only the essential ones, the fix
> here, the operand64 removal, the nftw workaround, and -O1 to work around the
> stage 2 ICE, I don't get the duplicate symbols but the compiler segfaults in
> libgcc configure tests in stage 2.
> 
> If I add the '#undef MAKE_DECL_ONE_ONLY' fix from PR64919 (is it even still
> relevant? It does seem to be for the stage 2 libgcc segfault symptom I
> see.), I start getting the duplicate symbols in stage 1 libstdc++.

Yeah, we had PR64919 applied and backed out only the "#undef
MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have
fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and
Debian's ia64-disable-selective-scheduling.patch applied, in addition to some
local -O2=>-O0 workarounds.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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-thread-safe.

We haven't had any issues with MPFR. We're using 3.1.6 built with the HP C
compiler.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.
> 
> Yep. I forgot about PR66319.

Ok, that fixed the nftw issue. Anyone encounter this:
gmake[5]: Entering directory
`/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include'
mkdir -p ./ia64-hp-hpux11.31/bits/stdc++.h.gch
/opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include-x c++-header -nostdinc++ -g
-O2 
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h \
-o ia64-hp-hpux11.31/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41:
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34:
internal compiler error: Segmentation fault
 struct __add_unsigned;
  ^

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 the "#undef
> > MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have
> > fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and
> > Debian's ia64-disable-selective-scheduling.patch applied, in addition to 
> > some
> > local -O2=>-O0 workarounds.
> Maybe you could upload your full patch set so others can see details.

Done.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43,
> >  from
> > /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41:
> > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34:
> > internal compiler error: Segmentation fault
> >  struct __add_unsigned;
> >   ^
> Disable precompiled headers for now.  This will make it easier to find
> problems.

Thanks. That worked. But the build failed again, with what looks like a similar
segfault:
libtool: compile:  /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=atexit_thread.lo -g -O2 -c
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o atexit_thread.o
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI,
which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
In file included from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/move.h:55,
 from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/nested_exception.h:40,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/exception:144,
 from /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/new:40,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc:26:
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:363:36:
internal compiler error: Segmentation fault
 struct __is_pointer_helper<_Tp*>
^

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.

No issues with PCH or libsupc++ like I'm seeing?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 mentioned
> > > duplicate symbols and operand64 problem, and -O1 to work around the ICE), 
> > > I
> > > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.
> > 
> > No issues with PCH or libsupc++ like I'm seeing?
> 
> No, but the only "working" build I've had so far was with the "#undef
> MAKE_DECL_ONE_ONLY" hack and had the duplicate symbol problem. If I remove
> that hack as recommended, I then get a segfault ICE even earlier than you
> do, where the stage 2 compiler seems completely broken and crashes even on a
> single empty function (haven't been able to do much with that yet).

What linker patch do you have installed?

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 maintaining it?
> I don't have or access to a ia64 box.
> 
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
> 
> Albert Chin  is the only person that I know who
> might be actively using it.
> 
> My access to the hppa box that I use for hppa-hpux support requires support
> from NRC Canada but
> all colleagues there have retired.  It was down for a few weeks until
> yesterday when I got a network person
> to reboot it.
> 
> So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.

We are still using it but haven't been able to build anything post 4.9.4. We
tried to find someone to pay to bring this port up-to-date but had no success.
Open to other suggestions but deprecating it might be the only way forward.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 any ia64 machines.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 Debian.  gcc-9 so
> far has failed to build on ia64.

Ok, I'll try. I'll try to reach out to the Debian/ia maintainers again.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 patch applied as you're using binutils 2.32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338?

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 run correctly
> So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined.  The configure
> script is
> likely not detecting this assembler capability correctly.
> 
> Are you using bash shell? If not, I suggest that you use it instead of HP
> shell.

It's set to 1 for us. We're getting a segfault while building libstdc++-v3 with
8.3.0:
configure:7964: checking for ANSI C header files
configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g  conftest.c >&5
configure:7984: $? = 0
configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i
a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include
-isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g  
conftest.c  >&5
configure:8057: $? = 0
configure:8057: ./conftest
/opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 Memoryfault(coredum
p)
configure:8057: $? = 139


Using the stage 1 8.3.0 compiler, we can get a simple "hello world" program to
compile.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 local storage. You can work around this by configuring MPFR with
> --disable-thread-safe

We are building GCC against mpfr-3.1.6 but MPFR wasn't a difficult build on
HP-UX/IA. We are building with the HP C compiler though. The MPFR testsuite
passed all but one test which was a PASS. And, ./configure shows
-DMPFR_USE_THREAD_SAFE=1.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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/opt/build/china/gcc-8.3.0/.obj/./gcc/
> > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i
> > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include
> > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 
> > -g  
> > conftest.c  >&5
> > configure:8057: $? = 0
> > configure:8057: ./conftest
> > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 
> > Memoryfault(coredum
> > p)
>
> The configure test needs to be debugged in the same manner as the "hello
> world" program.

Yeah, we've already looked at the difference between 4.9.4/8.3.0 assembly but
want to rebuild 8.3.0 with as few patches as possible to ensure the issue isn't
some patch we've introduced.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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/china/gcc-8.3.0/.obj/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g  conftest.c >&5
configure:7984: $? = 0
configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g  
conftest.c  >&5
configure:8057: $? = 0
configure:8057: ./conftest
/opt/build/china/gcc-8.3.0/libstdc++-v3/configure: line 1940: 18830
Segmentation fault  (core dumped) ./conftest$ac_exeext

If I compile the conftest.c program between gcc-4.9.4 and the 8.3.0 stage 1
compiler:
--- gcc-4.9.4/conftest.s  2019-07-05 04:50:23 +
+++ /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/conftest.s  
2019-07-05 04:50:13 +
@@ -27,42 +27,26 @@
;;
ld4 r14 = [r14]
;;
-   addp4 r14 = 0,r14
-   ;;
cmp.eq p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L3
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
-   ;;
-   addp4 r14 = 0,r14
ld4 r15 = [r34]
;;
shladd r15 = r15, 2, r0
;;
add r14 = r15, r14
;;
-   addp4 r14 = 0,r14
+   addp4 r14 = r14, r0
;;
ld4 r14 = [r14]
;;
and r14 = 64, r14
;;
cmp4.ne p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L4
br .L5
;;
@@ -73,33 +57,15 @@
mov r14 = r8
;;
cmp4.eq p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L5
 .L4:
ld4 r14 = [r34]
;;
cmp4.ge p6, p7 = 96, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L6
ld4 r14 = [r34]
;;
cmp4.lt p6, p7 = 122, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L6
 .L5:
addl r14 = @ltoffx(__SB_masks#), r1
@@ -108,42 +74,26 @@
;;
ld4 r14 = [r14]
;;
-   addp4 r14 = 0,r14
-   ;;
cmp.eq p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L7
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
-   ;;
-   addp4 r14 = 0,r14
ld4 r15 = [r34]
;;
shladd r15 = r15, 2, r0
;;
add r14 = r15, r14
;;
-   addp4 r14 = 0,r14
+   addp4 r14 = r14, r0
;;
ld4 r14 = [r14]
;;
and r14 = 64, r14
;;
cmp4.eq p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L8
br .L9
;;
@@ -154,33 +104,15 @@
mov r14 = r8
;;
cmp4.ne p6, p7 = 0, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L9
 .L8:
ld4 r14 = [r34]
;;
cmp4.ge p6, p7 = 96, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L9
ld4 r14 = [r34]
;;
cmp4.ge p6, p7 = 122, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L6
 .L9:
ld4 r36 = [r34]
@@ -190,22 +122,10 @@
ld4 r14 = [r34]
;;
cmp4.ge p6, p7 = 96, r14
-   ;;
-   (p6) adds r14 = 1, r0
-   ;;
-   (p7) adds r14 = 0, r0
-   ;;
-   tbit.nz p6, p7 = r14, 0
(p6) br.cond.dptk .L10
ld4 r14 = [r34]
;;
cmp4.lt p6, p7 = 122, r14
-   

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 intermediate files between working (gcc 4.93) and not
> (bootstrap 8.3), the intermediate files seem similar until the "mach" stage
> 
> The problem seems to be in out the compiler decides to reference a string in
> the source.
> 
> My program is:
> 
> #include 
> 
> int main()
> {
> printf("Hellos World\n");
> return 0;
> }
> 
> The generated .s file for Working does this:
> 
> .LC0:
> stringz "Hellos World"
> 
> 
> 
> addl r36 = @ltoffx(.LC0), r1
> ;;
> ld8.mov r36 = [r36], .LC0
> 
> The non-working .s file does this:
> 
> .LC0:
> stringz "Hellos World"
> 
> 
> 
> movl r36 = @gprel(.LC0)
> ;;
> add r36 = r1, r36
> 
> 
> If I replace those 3 lines and run the assembler+linker by hand - the
> non-working foo.s will run correctly

I can now duplicate what you're seeing:
$ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
--- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
@@ -1,5 +1,6 @@
.file   "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+   .section.text,  "ax",   "progbits"
.section.rodata,"a","progbits"
.align 8
 .LC0:
@@ -19,9 +20,9 @@
mov r32 = b0
mov r35 = r1
.body
-   addl r36 = @ltoffx(.LC0), r1
+   movl r36 = @gprel(.LC0)
;;
-   ld8.mov r36 = [r36], .LC0
+   add r36 = r1, r36
br.call.sptk.many b0 = puts#
mov r1 = r35
mov r14 = r0

$ grep LTOFF /gcc/config.status
D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 generating executables.
> > 
> > In analyzing the intermediate files between working (gcc 4.93) and not
> > (bootstrap 8.3), the intermediate files seem similar until the "mach" stage
> > 
> > The problem seems to be in out the compiler decides to reference a string in
> > the source.
> > 
> > My program is:
> > 
> > #include 
> > 
> > int main()
> > {
> > printf("Hellos World\n");
> > return 0;
> > }
> > 
> > The generated .s file for Working does this:
> > 
> > .LC0:
> > stringz "Hellos World"
> > 
> > 
> > 
> > addl r36 = @ltoffx(.LC0), r1
> > ;;
> > ld8.mov r36 = [r36], .LC0
> > 
> > The non-working .s file does this:
> > 
> > .LC0:
> > stringz "Hellos World"
> > 
> > 
> > 
> > movl r36 = @gprel(.LC0)
> > ;;
> > add r36 = r1, r36
> > 
> > 
> > If I replace those 3 lines and run the assembler+linker by hand - the
> > non-working foo.s will run correctly
> 
> I can now duplicate what you're seeing:
> $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
> --- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
> +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
> @@ -1,5 +1,6 @@
> .file   "hello.c"
> .pred.safe_across_calls p1-p5,p16-p63
> +   .section.text,  "ax",   "progbits"
> .section.rodata,"a","progbits"
> .align 8
>  .LC0:
> @@ -19,9 +20,9 @@
> mov r32 = b0
> mov r35 = r1
> .body
> -   addl r36 = @ltoffx(.LC0), r1
> +   movl r36 = @gprel(.LC0)
> ;;
> -   ld8.mov r36 = [r36], .LC0
> +   add r36 = r1, r36
> br.call.sptk.many b0 = puts#
> mov r1 = r35
> mov r14 = r0
> 
> $ grep LTOFF /gcc/config.status
> D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"

If I revert the patch for PR60465 (added as an attachment), then looking at the
difference between gcc-4.9.4/hello.s and gcc-8.3.0/hello.s gives:
--- gcc-4.9.4/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 11:25:09 +
@@ -1,5 +1,6 @@
.file   "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+   .section.text,  "ax",   "progbits"
.section.rodata,"a","progbits"
.align 8
 .LC0:

Reverting the patch doesn't bring us any closer to the segfault in libstdc++-v3
though.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.4/hello.s gcc-8.3.0/hello.s
> > --- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
> > +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
> > @@ -1,5 +1,6 @@
> > .file   "hello.c"
> > .pred.safe_across_calls p1-p5,p16-p63
> > +   .section.text,  "ax",   "progbits"
> > .section.rodata,"a","progbits"
> With 8.3.0 assembly output, what happens if you change ".rodata" to ".data"?
> It may
> be that hpux can't handle gprel in .rodata.
> 
> The other possibility is gp is wrong.
> > .align 8
> >  .LC0:
> > @@ -19,9 +20,9 @@
> > mov r32 = b0
> > mov r35 = r1
> > .body
> > -   addl r36 = @ltoffx(.LC0), r1
> > +   movl r36 = @gprel(.LC0)
> > ;;
> > -   ld8.mov r36 = [r36], .LC0
> > +   add r36 = r1, r36
> > br.call.sptk.many b0 = puts#
> > mov r1 = r35
> > mov r14 = r0

$ /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj-/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31
/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include hello.s
hello.s: Assembler messages:
hello.s:4: Warning: ignoring changed section attributes for .data
$ ./a.out
`

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.313r.dfinish.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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.0/.obj-/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include -S hello.c

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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-/./gcc/
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include -g -da hello.c

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 still puzzled why .LC0 ends up in .rodata.
> 
> (insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
> (minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2]   *.LC0>)
> (reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
>  (nil))

This is a diff of the RTL between two gcc-8.3.0 versions, one with PR60465
reverted and one without:
--- without-PR60465/hello.c.313r.dfinish2019-07-05 20:37:38 +
+++ with-PR60465/hello.c.313r.dfinish2019-07-05 20:26:13 +
@@ -31,16 +31,16 @@
 (note 22 21 2 2 NOTE_INSN_PROLOGUE_END)
 (note 2 22 30 2 NOTE_INSN_FUNCTION_BEG)
 (insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
-(plus:DI (high:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2]  ))
-(reg:DI 1 r1))) "hello.c":5 110 {*load_symptr_high}
+(minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2]  )
+(reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
  (nil))
 (insn 34 30 31 2 (unspec_volatile [
 (const_int 3 [0x3])
 ] UNSPECV_INSN_GROUP_BARRIER) "hello.c":5 364 {insn_group_barrier}
  (nil))
 (insn 31 34 32 2 (set (reg:DI 120 out0 [+-4 ])
-(lo_sum:DI (mem/u/c:DI (reg:DI 120 out0 [+-4 ]) [0  S8 A64])
-(symbol_ref/f:SI ("*.LC0") [flags 0x2]  ))) "hello.c":5 111 {*load_symptr_low}
+(plus:DI (reg:DI 1 r1)
+(reg:DI 120 out0 [+-4 ]))) "hello.c":5 206 {adddi3}
  (nil))
 (call_insn 32 31 33 2 (parallel [
 (set (reg:SI 8 r8)

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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
> ltoffx?
> 
> .file   "foo.c"
> .pred.safe_across_calls p1-p5,p16-p63
> .section.text,  "ax",   "progbits"
> .Ltext0:
> .section.rodata,"a","progbits"
> .align 8
> .LC0:
> stringz "Hellos World"
> .section.text,  "ax",   "progbits"
> 
> 
> Isn't LC0 here also in .rodata?
> 
> objdump -h -s fooContents of section .rodata:
>  40007f8 48656c6c 6f732057 6f726c64 00Hellos World.   
> 
> 
> So gcc 4.9.x also puts the string into rodata?
> 
> (Not sure I'm reading all the files correctly, so perhaps I'm just reading
> it all wrong)

gcc-4.4.6 does:
.file   "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

gcc-4.6.4 does:
.file   "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

gcc-4.7.4 does:
.pred.safe_across_calls p1-p5,p16-p63
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

gcc-4.8.5 does:
.pred.safe_across_calls p1-p5,p16-p63
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

gcc-4.9.4 (with gprel patch reverted) does:
.file   "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

gcc-8.3.0 (first stage) does:
.section.text,  "ax",   "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
stringz "Hellos World"
.section.text,  "ax",   "progbits"
.align 16

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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 rodata?
> 
> (Not sure I'm reading all the files correctly, so perhaps I'm just reading
> it all wrong)

I'm seeing the string in .rodata as well regardless of compiler version:
$ gobjdump -h -s -j .rodata a.out
a.out: file format elf32-ia64-hpux-big

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
 10 .rodata   000d  040007c8  040007c8  07c8  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
Contents of section .rodata:
 40007c8 48656c6c 6f732057 6f726c64 00Hellos World.   

And the HP C compiler has it in .rodata as well:
$ cc a.out
$ gobjdump -h -s -j .rodata a.out
a.out: file format elf32-ia64-hpux-big

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
 11 .rodata   000e  040007c0  040007c0  07c0  2**4
  CONTENTS, ALLOC, LOAD, READONLY, DATA
Contents of section .rodata:
 40007c0 48656c6c 6f732057 6f726c64 0a00  Hellos World..

[Bug libstdc++/86553] New: libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553

Bug ID: 86553
   Summary: libstdc++-v3 build failure on AIX 5.3
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  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 LDR_CNTRL=MAXDATA=0x7000 \
  ../configure SHELL=/opt/fsw/bash42/bin/bash LDFLAGS="-Wl,-brtl \
-Wl,-blibpath:/opt/TWWfsw/libisl016/lib:/opt/TWWfsw/libgmp61/lib:\
/opt/TWWfsw/libmpc10/lib:/opt/TWWfsw/libmpfr31/lib:/usr/lib" \
  --enable-nls --with-included-gettext --enable-shared \
  --enable-threads --enable-languages=c,c++ \
  --with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
  --with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
  --with-local-prefix=/tmp/gcc8 --prefix=/tmp/gcc8
  $ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 gmake

The build failed with the following:
/opt/fsw/bash42/bin/bash ../../libtool --tag CXX --tag disable-shared
--mode=compile /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.1.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include   
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include/powerpc-ibm-aix5.3.11.0
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/libsupc++   -std=gnu++98 -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once   -ffunction-sections
-fdata-sections  -frandom-seed=math_stubs_long_double.lo -g -O2  -c -o
math_stubs_long_double.lo
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc
libtool: compile:  /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.1.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include 
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include/powerpc-ibm-aix5.3.11.0
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/libsupc++ -std=gnu++98
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnosti
cs-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=math_stubs_long_double.lo -g -O2 -c
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o math_stubs_long_double.o
In file included from
/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++v3/include/cmath:45,
 from
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:25:
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:3:
error: 'long double fabs' redeclared as different kind of symbol
   fabsl(long double x)
   ^
/opt/build/china/gcc-8.1.0/.obj/gcc/include-fixed/math.h:312:16: note: previous
declaration 'double fabs(double)'
 extern  double fabs(double);
^~~~
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:9:
error: expected primary-expression before 'long'
   fabsl(long double x)
 ^~~~
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:9:
error: expected ')' before 'long'
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:3:
note: to match this '('
   fabsl(long double x)
   ^
gmake[6]: *** [math_stubs_long_double.lo] Error 1
gmake[6]: Leaving directory
`/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/c++98'
gmake[5]: *** [all-recursive] Error 1

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug c/86559] New: Build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559

Bug ID: 86559
   Summary: Build failure on AIX 5.3
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: 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=0x7000 \
  ../configure SHELL=/opt/fsw/bash42/bin/bash LDFLAGS="-Wl,-brtl \
-Wl,-blibpath:/opt/TWWfsw/libisl016/lib:/opt/TWWfsw/libgmp61/lib:\
/opt/TWWfsw/libmpc10/lib:/opt/TWWfsw/libmpfr31/lib:/usr/lib" \
  --enable-nls --with-included-gettext --enable-shared \
  --enable-threads --enable-languages=c,c++ \
  --with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
  --with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
  --with-local-prefix=/tmp/gcc7 --prefix=/tmp/gcc7
  ...
  $ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 gmake

The build failed with the following:
g++ -std=gnu++98-g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc
-Wl,-bmaxdata:0x4000 -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o
c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o
c/c-objc-common.o c/c-parser.o c/c-array-notation.o c/c-fold.o
c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o
c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o
c-family/c-attribs.o c-family/c-warn.o default-c.o rs6000-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -L/opt/TWWfsw/libisl016/lib -lisl
-L/opt/TWWfsw/libgmp61/lib -L/opt/TWWfsw/libmpfr31/lib
-L/opt/TWWfsw/libmpc10/lib -lmpc -lmpfr -lgmp   -L./../zlib -lz
ld: 0711-783 WARNING: TOC overflow. TOC size: 207328Maximum size: 65536
Extra instructions are being generated for each reference to a TOC
symbol if the symbol is in the TOC overflow area.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 953, object file attribs.o
Length of stabstring in .debug section is invalid.
The stabstring is being deleted.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 1587, object file c/c-decl.o
Length of stabstring in .debug section is invalid.
The stabstring is being deleted.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 1604, object file
c/c-typeck.o
Length of stabstring in .debug section is invalid.
The stabstring is being deleted.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 761, object file
c/c-convert.o
Length of stabstring in .debug section is invalid.
The stabstring is being deleted.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 1533, object file
c/c-parser.o
Length of stabstring in .debug section is invalid.
The stabstring is being deleted.
...
collect2: error: ld returned 12 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj'
gmake: *** [all] Error 2

Some info about this system:
  $ oslevel -s
  5300-11-08-1140
  $ lslpp -h bos.rte.bind_cmds
Fileset Level Action   Status   Date Time
   

  Path: /usr/lib/objrepos
bos.rte.bind_cmds
   5.3.0.50   COMMIT   COMPLETE 01/13/07 19:57:05
   5.3.0.51   COMMIT   COMPLETE 01/14/07 19:44:07
5.3.8.0   COMMIT   COMPLETE 09/05/08 08:06:25
5.3.8.2   COMMIT   COMPLETE 09/05/08 08:29:06
   5.3.11.4   COMMIT   COMPLETE 06/18/12 16:56:58
   5.3.11.7   APPLYCOMPLETE 06/18/12 17:28:20

[Bug c/86559] Build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559

--- Comment #1 from The Written Word  
---
Might be a duplicate of PR64081.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

[Bug bootstrap/86559] Build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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?
> 
> Hmm. Let me try upgrading. Thanks.

I upgraded the system to the following:
  $ oslevel -s
  7100-04-05-1720
  $ lslpp -h bos.rte.bind_cmds
  Fileset Level Action   Status   Date Time
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
  7.1.0.0   COMMIT   COMPLETE 11/13/10 21:01:20
 7.1.0.15   COMMIT   COMPLETE 06/18/12 19:54:09
 7.1.0.16   COMMIT   COMPLETE 10/12/16 21:23:45
 7.1.2.19   COMMIT   COMPLETE 10/17/16 20:41:47
 7.1.3.47   COMMIT   COMPLETE 07/10/18 21:18:33
 7.1.4.32   APPLYCOMPLETE 07/10/18 21:31:27

Path: /etc/objrepos
  bos.rte.bind_cmds
  7.1.0.0   COMMIT   COMPLETE 11/13/10 21:01:20
 7.1.0.15   COMMIT   COMPLETE 06/18/12 19:54:10
 7.1.0.16   COMMIT   COMPLETE 10/12/16 21:23:45
 7.1.2.19   COMMIT   COMPLETE 10/17/16 20:41:47
 7.1.3.47   COMMIT   COMPLETE 07/10/18 21:18:33
 7.1.4.32   APPLYCOMPLETE 07/10/18 21:31:29

I built gcc-4.9.4 and I still get the error:
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-peda
ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-D
HAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-4.9.4/gcc
-I/opt/build/china/gcc-4.
9.4/gcc/. -I/opt/build/china/gcc-4.9.4/gcc/../include -I./../intl
-I/opt/build/c
hina/gcc-4.9.4/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include
-I/opt/TWWfs
w/libmpfr31/include -I/opt/TWWfsw/libmpc10/include 
-I/opt/build/china/gcc-4.9.4
/gcc/../libdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libdecnumber/dpd
-I../l
ibdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/
opt/TWWfsw/libcloog018/include -I/opt/TWWfsw/libisl015/include  -o
insn-output.o
 -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo insn-output.c
/tmp//ccGCJgTB.s: Assembler messages:
/tmp//ccGCJgTB.s:1361: Error: value of 00012990 too large for field of
2
 bytes at 046e
/tmp//ccGCJgTB.s:1495: Error: value of 00012990 too large for field of
2
 bytes at 05ee
/tmp//ccGCJgTB.s:1628: Error: value of 00012990 too large for field of
2
 bytes at 0772
/tmp//ccGCJgTB.s:1761: Error: value of 00012990 too large for field of
2
 bytes at 08f6
/tmp//ccGCJgTB.s:1913: Error: value of 00012994 too large for field of
2
 bytes at 0aa6
/tmp//ccGCJgTB.s:2047: Error: value of 00012990 too large for field of
2
 bytes at 0c2a
/tmp//ccGCJgTB.s:2183: Error: value of 00012990 too large for field of
2
 bytes at 0db6
/tmp//ccGCJgTB.s:2289: Error: value of 00012998 too large for field of
2
 bytes at 0eca
...

I was able to build gcc-8.1.0 on this system. Trying gcc-5.5.0, 6.4.0, and
7.2.0 now.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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 platform has:
#ifdef _ISOC99_SOURCE
#ifdef __LONGDOUBLE128
...
#else
...
#define acosl(__x)  acos((double) (__x))
#define fabsl(__x)  fabs((double) (__x))
...
#endif

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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 #undef'd everything to get a clean
build of that file and restarted the build from scratch so we'll see.

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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.

> You never showed an example of the assembly line representing the error
> message to allow someone to observe the exact assembly instruction and
> operands in question.

I've attached insn-output.s. Looks like the problematic lines are of the form:
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   3466
lwz 0,LC..1(2)  <-- line 1361
.eb 3466
.line   3468
mr 3,0
addi 1,31,96
...
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   14
lwz 0,LC..2(2)  <-- line 1495
.eb 14
.line   16
mr 3,0
addi 1,31,96

...
bl ._Z17gen_rtx_CONST_INT12machine_modex
nop
mr 0,3
stw 0,0(28)
.line   14
lwz 0,LC..3(2)  <-- line 1628
.eb 14
.line   16
mr 3,0
addi 1,31,96

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.

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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.

gcc-6.4.0 just died somewhere else with the same error:
g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasync
hronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing
-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-ma
cros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/opt/build/c
hina/gcc-6.4.0/gcc -I/opt/build/china/gcc-6.4.0/gcc/.
-I/opt/build/china/gcc-6.4
.0/gcc/../include -I./../intl
-I/opt/build/china/gcc-6.4.0/gcc/../libcpp/include
 -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include
-I/opt/TWWfsw/li
bmpc10/include  -I/opt/build/china/gcc-6.4.0/gcc/../libdecnumber
-I/opt/build/ch
ina/gcc-6.4.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/opt/build/china/gcc-6
.4.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include  -o rs6000.o -MT
rs6000
.o -MMD -MP -MF ./.deps/rs6000.TPo
/opt/build/china/gcc-6.4.0/gcc/config/rs6000/
rs6000.c
/tmp//ccsn8s2Z.s: Assembler messages:
/tmp//ccsn8s2Z.s:177152: Error: value of 0001 too large for field
of
 2 bytes at 0007e722
/tmp//ccsn8s2Z.s:177680: Error: value of 00010004 too large for field
of
 2 bytes at 0007ed12
/tmp//ccsn8s2Z.s:178850: Error: value of 00010008 too large for field
of
 2 bytes at 0007fb5e
/tmp//ccsn8s2Z.s:179521: Error: value of 0001000c too large for field
of
 2 bytes at 00080246
...

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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
> generating code with too large displacements.
> 
> Also, some of the configure options are unusual.

Ok, will try something later than 4.4. Thanks.

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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 solved by any fix for PR 79700, which would have to
> add this to :
> 
> #undef fabsl
> 
> But I'm not sure when PR 79700 will get fixed.

Is it just a matter of someone finding the time to fix 79700 or is it just too
low a priority?

[Bug fortran/86599] New: Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA

[bugzilla-gcc at thewrittenword dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599

Bug ID: 86599
   Summary: Problems building libgfortran from 7.2.0 on HP-UX
11.31/PA
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  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 .obj
  $ PATH=/opt/TWWfsw/gcc49/bin:$PATH ../configure \
  SHELL=/opt/fsw/bash42/bin/bash --enable-nls --with-included-gettext \
  --enable-shared --enable-languages=c,c++,fortran \
  --with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
  --with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
  --with-gnu-as --with-as=/opt/TWWfsw/gcc7/hppa2.0-hp-hpux11.31/bin/as \
  --with-local-prefix=/tmp/gcc7 --prefix=/tmp/gcc7
  ...
  $ PATH=/opt/TWWfsw/gcc49/bin:$PATH \
  ac_cv_prog_OBJCOPY="/opt/TWWfsw/gcc7/bin/gobjcopy" \
  ac_cv_prog_OBJDUMP="/opt/TWWfsw/gcc7/bin/gobjdump" gmake

The build failed with the following:
libtool: compile:  /opt/build/china/gcc-7.2.0/.obj/./gcc/xgcc
-B/opt/build/china
/gcc-7.2.0/.obj/./gcc/ -B/tmp/gcc7/hppa2.0w-hp-hpux11.31/bin/
-B/tmp/gcc7/hppa2.
0w-hp-hpux11.31/lib/ -isystem /tmp/gcc7/hppa2.0w-hp-hpux11.31/include -isystem
/
tmp/gcc7/hppa2.0w-hp-hpux11.31/sys-include -DHAVE_CONFIG_H -I.
-I/opt/build/chin
a/gcc-7.2.0/libgfortran -iquote/opt/build/china/gcc-7.2.0/libgfortran/io
-I/opt/
build/china/gcc-7.2.0/libgfortran/../gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../gcc/config
-I/opt/build/china/gcc-7.2.0/libgfortran/../libquadmath -I../.././gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libgcc -I../libgcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -g -O2 -MT
read.lo -MD -MP -MF .deps/read.Tpo -c
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c  -fPIC -DPIC -o .libs/read.o
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c: In function 'convert_real':
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c:177:30: error: incompatible
types when assigning to type 'GFC_REAL_16 {aka long double}' from type
'long_double {aka struct }'
   *((GFC_REAL_16*) dest) = gfc_strtold (buffer, &endptr);
  ^
gmake[3]: *** [read.lo] Error 1
gmake[3]: Leaving directory
`/opt/build/china/gcc-7.2.0/.obj/hppa2.0w-hp-hpux11.31/libgfortran'

I was able to build on HP-UX 11.23/PA.

[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA

[bugzilla-gcc at thewrittenword dot com]

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.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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-hpux11.31/bin/
-B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
 -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-I. -I. -I../.././gcc -I/opt/build/china/gcc-4.9.4/libgcc
-I/opt/build/china/gcc-4.9.4/libgcc/.
-I/opt/build/china/gcc-4.9.4/libgcc/../gcc
-I/opt/build/china/gcc-4.9.4/libgcc/../include  -DHAVE_CC_TLS  -o emutls.o -MT
emutls.o -MD -MP -MF emutls.dep -fexceptions -c
/opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS
/opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function '__emutls_get_address':
/opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: in
simplify_subreg, at simplify-rtx.c:5917
 }
 ^

Should I build this with -O0 as well?