gcc cvs (010922) build error on ia64

gcc cvs (010922) build error on ia64

[Randolph Chung]

While trying to build a recent gcc 3.0.2 snapshot (2001-09-02 cvs) on linux-ia64,
I am seeing the following error:

/usr/src/gcc-3.0-3.0.2ds2/build/gcc/xgcc -B/usr/src/gcc-3.0-3.0.2ds2/build/gcc/ -nostdinc++ -L/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/src -L/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/src/.libs -B/usr/ia64-linux/bin/ -B/usr/ia64-linux/lib/ -isystem /usr/ia64-linux/include -I../../../../src/libstdc++-v3/../gcc -I../../../../src/libstdc++-v3/../include -I/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/include/ia64-linux -I/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/include -I../../../../src/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../src/libstdc++-v3/libsupc++/eh_exception.cc  -fPIC -DPIC -o eh_exception.o
/tmp/ccuZSgNa.s: Assembler messages:
/tmp/ccuZSgNa.s:352: Error: Unknown opcode `data16.ua @iplt(_ZNSt13bad_exceptionD1Ev#)'
/tmp/ccuZSgNa.s:353: Error: Unknown opcode `data16.ua @iplt(_ZNSt13bad_exceptionD0Ev#)'
/tmp/ccuZSgNa.s:354: Error: Unknown opcode `data16.ua @iplt(_ZNKSt9exception4whatEv#)'
/tmp/ccuZSgNa.s:364: Error: Unknown opcode `data16.ua @iplt(_ZNSt9exceptionD1Ev#)'
/tmp/ccuZSgNa.s:365: Error: Unknown opcode `data16.ua @iplt(_ZNSt9exceptionD0Ev#)'
/tmp/ccuZSgNa.s:366: Error: Unknown opcode `data16.ua @iplt(_ZNKSt9exception4whatEv#)'
make[6]: *** [eh_exception.lo] Error 1
make[6]: Leaving directory `/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/libsupc++'

This is built using binutils 2.11.90.0.29 (2001-08-27 cvs). 

Is a newer binutils needed? Or is this a bug?

thanks,
randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: gcc cvs (010922) build error on ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Randolph Chung <randolph@tausq.org> writes:

|> While trying to build a recent gcc 3.0.2 snapshot (2001-09-02 cvs) on linux-ia64,
|> I am seeing the following error:
[...]
|> /tmp/ccuZSgNa.s:366: Error: Unknown opcode `data16.ua @iplt(_ZNKSt9exception4whatEv#)'
|> make[6]: *** [eh_exception.lo] Error 1
|> make[6]: Leaving directory `/usr/src/gcc-3.0-3.0.2ds2/build/ia64-linux/libstdc++-v3/libsupc++'
|> 
|> This is built using binutils 2.11.90.0.29 (2001-08-27 cvs). 
|> 
|> Is a newer binutils needed?

Yes, support for data16.ua and @iplt has been added 2001-09-05.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: gcc cvs (010922) build error on ia64

[Gerald Pfeifer]

On 23 Sep 2001, Andreas Schwab wrote:
>|> Is a newer binutils needed?
> Yes, support for data16.ua and @iplt has been added 2001-09-05.

I just noticed that our platform-specific installation notes in
gcc/doc/install.texi ( http://gcc.gnu.org/install/specific.html )
do not seem to mention ia64 at all.

It would be greate could some of you with experience with this platform
add something (including the requirement stated above).

Thanks,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: gcc cvs (010922) build error on ia64

[Jim Wilson]

This is likely to get a little complicated because the IA-64 toolchcain is
still not completely finished yet.  Here is a rough draft of most of the
important points that I think need documenting.

ia64-*-linux
Gcc 3.0.2 is not ABI compatible with previous releases, including gcc 3.0.1,
the Trillian 000717 release, and the Red Hat "2.96" release.  This primarily
affects C++ programs, and programs that create shared libraries.  Because of
these ABI incompatibilities, gcc 3.0.2 is not recommended for user programs
on GNU/Linux systems built using earlier compiler releases.  Gcc 3.0.2 is
recommended for compiling linux, the kernel.  Gcc 3.0.2 is believed to be
fully ABI compliant, and hence no more major incompatible ABI changes are
expected.

Gcc 3.0.2 requires a binutils from 2001-09-05 or later.  Gcc 3.0.1 requires
binutils 2.11.1 or later.

Jim

Re: gcc cvs (010922) build error on ia64

[Janis Johnson]

On Mon, Sep 24, 2001 at 01:17:20PM -0700, Jim Wilson wrote:
> This is likely to get a little complicated because the IA-64 toolchcain is
> still not completely finished yet.  Here is a rough draft of most of the
> important points that I think need documenting.
> 
> ia64-*-linux
> Gcc 3.0.2 is not ABI compatible with previous releases, including gcc 3.0.1,
> the Trillian 000717 release, and the Red Hat "2.96" release.  This primarily
> affects C++ programs, and programs that create shared libraries.  Because of
> these ABI incompatibilities, gcc 3.0.2 is not recommended for user programs
> on GNU/Linux systems built using earlier compiler releases.  Gcc 3.0.2 is
> recommended for compiling linux, the kernel.  Gcc 3.0.2 is believed to be
> fully ABI compliant, and hence no more major incompatible ABI changes are
> expected.
> 
> Gcc 3.0.2 requires a binutils from 2001-09-05 or later.  Gcc 3.0.1 requires
> binutils 2.11.1 or later.

Thanks, Jim.  I turned your comments into a patch and added the glibc
requirement.  I also clarified (I hope) the ABI incompatibility issue,
since no IA-64 release so far is compatible with any other release.

Janis

2001-09-24  Jim Wilson  <wilson@redhat.com>

	* doc/install.texi (Specific, ia64-*-linux): Document.

Index: install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.67
diff -u -r1.67 install.texi
--- install.texi	2001/09/24 17:29:37	1.67
+++ install.texi	2001/09/24 21:07:10
@@ -1353,6 +1353,8 @@
 @item
 @uref{#i860-intel-osf*,,i860-intel-osf*}
 @item
+@uref{#ia64-*-linux,,ia64-*-linux}
+@item
 @uref{#*-lynx-lynxos,,*-lynx-lynxos}
 @item
 @uref{#*-ibm-aix*,,*-ibm-aix*}
@@ -2219,6 +2221,30 @@
 @end example
 
 These problems don't exist in operating system version 1.1.
+
+@html
+</p>
+<hr>
+@end html
+@heading @anchor{ia64-*-linux}ia64-*-linux
+IA-64 processor (also known as IPF, or Itanium Processor Family)
+running GNU/Linux.
+
+The toolchain is not completely finished, so requirements will continue
+to change.
+GCC 3.0.1 and later require glibc 2.2.4.
+GCC 3.0.2 requires binutils from 2001-09-05 or later.
+GCC 3.0.1 requires binutils 2.11.1 or later.
+
+None of the following versions of GCC has an ABI that is compatible
+with any of the other versions in this list:
+3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.
+This primarily affects C++ programs and programs that create shared libraries.
+Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for
+user programs on GNU/Linux systems built using earlier compiler releases.
+GCC 3.0.2 is recommended for compiling linux, the kernel.
+GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major
+ABI changes are expected.
 
 @html
 </p>

Re: gcc cvs (010922) build error on ia64

[Jim Wilson]

This looks reasonable to me.  The addition of glibc info is good; I didn't
have it handy.

Jim

Re: gcc cvs (010922) build error on ia64

[Jakub Jelinek]

On Mon, Sep 24, 2001 at 02:26:45PM -0700, Janis Johnson wrote:
> +None of the following versions of GCC has an ABI that is compatible
> +with any of the other versions in this list:
> +3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.

This is not entirely correct, I believe 2.96-RH is ABI compatible with
Trillian 000717 (2.96-RH/ia64 has the ia64 backend almost identical to
Trillian 000717, with a few bugfixes, plus the CVS snapshot the two
compilers are based on is very close (000717 and 000731), the patches which
were applied on top of 000731 do not change ABI).

Also, aren't 3.0/ia64 and 3.0.1/ia64 binary compatible too (no idea, just
wondering)?

	Jakub

Re: gcc cvs (010922) build error on ia64

[Gerald Pfeifer]

On Mon, 24 Sep 2001, Janis Johnson wrote:
> 2001-09-24  Jim Wilson  <wilson@redhat.com>
>
> 	* doc/install.texi (Specific, ia64-*-linux): Document.

Please add your name here and commit this to both branches (with the
minor change pointed out on the list).

Jim, thanks for the info.

Janis, you beat me to converting this to texinfo -- thanks a lot! ;-)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: gcc cvs (010922) build error on ia64

[Janis Johnson]

On Tue, Sep 25, 2001 at 03:49:42PM +0200, Gerald Pfeifer wrote:
> On Mon, 24 Sep 2001, Janis Johnson wrote:
> > 2001-09-24  Jim Wilson  <wilson@redhat.com>
> >
> > 	* doc/install.texi (Specific, ia64-*-linux): Document.
> 
> Please add your name here and commit this to both branches (with the
> minor change pointed out on the list).
> 
> Jim, thanks for the info.

OK, but I'll wait for word from Jim about the compatibility issues.
It sounds like the Trillian release and Red Hat 2.96 are compatible;
are there incompatibilities on ia64 between 3.0 and 3.0.1?

Janis

Re: gcc cvs (010922) build error on ia64

[Jim Wilson]

>This is not entirely correct, I believe 2.96-RH is ABI compatible with
>Trillian 000717

Yes, I would expect them to be ABI compatible, but I've never tried to
verify it.  If they aren't ABI compatible, no one is going to fix it.
So documenting them as incompatible seems reasonable.

>Also, aren't 3.0/ia64 and 3.0.1/ia64 binary compatible too (no idea, just
>wondering)?

3.0 has ia64_app_header, 3.0.1 does not.  Thus you can get undefined
references to ia64_app_header if you mix them.  I think the failure case
would be building a shared library with 3.0 that imports functions from
libgcc, and then linking it into a 3.0.1 compiled application.

Jim

Re: gcc cvs (010922) build error on ia64

[David Edelsohn]

	GCC 3.0.2 and the trunk now define TARGET_VTABLE_USES_DESCRIPTORS
on IA-64.  Is that an incompatible change?

	On a related note, should all targets with function descriptors
(e.g., AIX and 64-bit PowerPC Linux) use that macro as well?

Thanks, David

Re: gcc cvs (010922) build error on ia64

[Jakub Jelinek]

On Tue, Sep 25, 2001 at 02:42:27PM -0400, David Edelsohn wrote:
> 	GCC 3.0.2 and the trunk now define TARGET_VTABLE_USES_DESCRIPTORS
> on IA-64.  Is that an incompatible change?

Sure. Before that change gcc/IA-64 did not follow IA-64 ABI.

> 	On a related note, should all targets with function descriptors
> (e.g., AIX and 64-bit PowerPC Linux) use that macro as well?

Only if the respective ABIs require it.

	Jakub

Re: gcc cvs (010922) build error on ia64

[Jim Wilson]

>	GCC 3.0.2 and the trunk now define TARGET_VTABLE_USES_DESCRIPTORS
>on IA-64.  Is that an incompatible change?

Yes.  C++ vtables before and after the change are not compatible.  This
is why IA-64 gcc 3.0.2 is not compatible with IA-64 gcc 3.0.1.  This was
necessary for ABI compliance.

>	On a related note, should all targets with function descriptors
>(e.g., AIX and 64-bit PowerPC Linux) use that macro as well?

I think this would have to be investigated on an individual basis.  For
IA-64, putting the function descriptor in the vtable removes one branch
from the execution path, but it makes vtables bigger, and requires special
relocations and special assembler syntax for the vtables, and it also
apparently causes other problems.  Richard commented on this briefly in one
of his messages when asked about java.

Bryce McKinlay...
Do we need to handle storing function descriptors in the interface
tables for IA64?

Richard Henderson...
Nope.  In fact the only real reason to do it for vtables
is that someone decided that it was a good idea for c++.
Better would have been a scheme that didn't require any
dynamic relocations, or at least one that could use lazy
binding, but...

There is also the fact that this is an ABI change, which would be a problem
for established systems.  IA-64 is still new enough that we can get ABI
changes in, though we expect that this is the last one that we will need.

Jim