Re: build failure for ia64 (due to -Werror)

Re: build failure for ia64 (due to -Werror)

[Paul Schlie]

> Andreas Schwab writes:
>> James E Wilson <wilson@specifixinc.com> writes:
>>> On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
>>> IMHO the only change we need is to check for BFD_HOST_64_BIT and error
>>> out if that is not defined.
>>
>> Doesn't that break --enable-targets=all on a 32-bit host without long
>> long?
>
> Yes, that is true. Although they are becoming rarer nowadays, and whether
> it is worth to support this combination is another question.

- Just to double check; 32-bit limited hosts would still be able to
  build/support correspondingly limited targets, yes?

Re: build failure for ia64 (due to -Werror)

[Andreas Schwab]

Paul Schlie <schlie@comcast.net> writes:

>> Andreas Schwab writes:
>>> James E Wilson <wilson@specifixinc.com> writes:
>>>> On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
>>>> IMHO the only change we need is to check for BFD_HOST_64_BIT and error
>>>> out if that is not defined.
>>>
>>> Doesn't that break --enable-targets=all on a 32-bit host without long
>>> long?
>>
>> Yes, that is true. Although they are becoming rarer nowadays, and whether
>> it is worth to support this combination is another question.
>
> - Just to double check; 32-bit limited hosts would still be able to
>   build/support correspondingly limited targets, yes?

Yes, sure.  I'm not aware of anonther 32-bit backend that needs 64-bit
integers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build failure for ia64 (due to -Werror)

[Nick Clifton]

Hi Jim,

>>I am happy to do that, but presumably the elf32-ia64.lo entry should be 
>>moved from BFD32_BACKENDS to BFD64_BACKENDS ?

> That is what the proposed patch attached to my last message does.

Sorry - I missed that.  I have now checked your patch in.

Cheers
   Nick

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Wed, 2005-03-23 at 02:17, Nick Clifton wrote:
> I am happy to do that, but presumably the elf32-ia64.lo entry should be 
> moved from BFD32_BACKENDS to BFD64_BACKENDS ?

That is what the proposed patch attached to my last message does.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[Nick Clifton]

Hi Jim,

> Anyways, I think the right solution is what Ian suggested, which is to
> remove elf32-ia64.lo from BDF32_BACKENDS.

I am happy to do that, but presumably the elf32-ia64.lo entry should be 
moved from BFD32_BACKENDS to BFD64_BACKENDS ?

Cheers
   Nick

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

On Fri, 2005-03-18 at 15:49, Alan Modra wrote:
> This only hides other more serious bugs in this function if bfd_vma is
> 32-bit.  For instance,

I don't see any benefit from fixing elfxx-ia64.c to work with a 32-bit
bfd_vma.  IA-64 is a true 64-bit architecture, like alpha.  There is no
32-bit subset architecture.  All IA-64 operating systems are 64-bit
operating systems that require a 64-bit bfd_vma.  This is enforced in
config.bfd.

One system, HPUX, supports an ILP32 ABI, but since this is implemented
with 64-bit operations, and uses 64-bit addresses, gdb at least needs to
be 64-bit aware, and I would argue that bfd does to.

Also, I'd like to point out that the build failures being discussed here
can not be reproduced with any IA-64 target, nor on an IA-64 host.  They
can only be reproduced on a (non-IA-64) 32-bit host using
--enable-targets=all.

If we did have a 32-bit IA-64 target, then yes, we should make a 32-bit
bfd_vma work.  But meanwhile, I think this is unwise.  It just creates
maintenance problems for the IA-64 maintainer (me), because no one will
remember that we must support a 32-bit bfd_vma.  Also, this potentially
hurts the performance of the IA-64 bfd support if we can't assume use of
64-bit operations even though this is a 64-bit target.

My attempts to look at this are hampered by the fact that I can't
actually reproduce it on any of the machines I normally use for
development. Either they are 64-bit machines, or they don't have the
right gcc versions needed to trigger the error Ben saw.

Anyways, I think the right solution is what Ian suggested, which is to
remove elf32-ia64.lo from BDF32_BACKENDS.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


[-- Attachment #2: patch.32-bit.ia-64 --]
[-- Type: text/plain, Size: 2352 bytes --]

2005-03-22  James E Wilson  <wilson@specifixinc.com>

	* Makefile.am (BFD32_BACKENDS): Delete elf32-ia64.lo.
	(BFD64_BACKENDS): Add elf32-ia64.lo.
	* Makefile.in: Regenerate.

Index: Makefile.am
===================================================================
RCS file: /cvs/src/src/bfd/Makefile.am,v
retrieving revision 1.149
diff -p -p -r1.149 Makefile.am
*** Makefile.am	2 Mar 2005 09:03:48 -0000	1.149
--- Makefile.am	23 Mar 2005 04:30:13 -0000
*************** BFD32_BACKENDS = \
*** 237,243 ****
  	elf32-i386.lo \
  	elf32-i860.lo \
  	elf32-i960.lo \
- 	elf32-ia64.lo \
  	elf32-ip2k.lo \
  	elf32-iq2000.lo \
  	elf32-m32r.lo \
--- 237,242 ----
*************** BFD32_BACKENDS_CFILES = \
*** 509,514 ****
--- 508,515 ----
  # The .o files needed by all of the 64 bit vectors that are configured into
  # target_vector in targets.c if configured with --enable-targets=all
  # and --enable-64-bit-bfd.
+ # elf32-ia64.c requires a 64-bit bfd_vma, and hence can not be put in
+ # BFD32_BACKENDS.
  BFD64_BACKENDS = \
  	aix5ppc-core.lo \
  	aout64.lo \
*************** BFD64_BACKENDS = \
*** 519,524 ****
--- 520,526 ----
  	elf64-x86-64.lo \
  	elf64-alpha.lo \
  	elf64-hppa.lo \
+ 	elf32-ia64.lo \
  	elf64-ia64.lo \
  	elf64-gen.lo \
  	elfn32-mips.lo \
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/bfd/Makefile.in,v
retrieving revision 1.163
diff -p -p -r1.163 Makefile.in
*** Makefile.in	2 Mar 2005 09:03:50 -0000	1.163
--- Makefile.in	23 Mar 2005 04:30:13 -0000
*************** BFD32_BACKENDS = \
*** 476,482 ****
  	elf32-i386.lo \
  	elf32-i860.lo \
  	elf32-i960.lo \
- 	elf32-ia64.lo \
  	elf32-ip2k.lo \
  	elf32-iq2000.lo \
  	elf32-m32r.lo \
--- 476,481 ----
*************** BFD32_BACKENDS_CFILES = \
*** 749,754 ****
--- 748,755 ----
  # The .o files needed by all of the 64 bit vectors that are configured into
  # target_vector in targets.c if configured with --enable-targets=all
  # and --enable-64-bit-bfd.
+ # elf32-ia64.c requires a 64-bit bfd_vma, and hence can not be put in
+ # BFD32_BACKENDS.
  BFD64_BACKENDS = \
  	aix5ppc-core.lo \
  	aout64.lo \
*************** BFD64_BACKENDS = \
*** 759,764 ****
--- 760,766 ----
  	elf64-x86-64.lo \
  	elf64-alpha.lo \
  	elf64-hppa.lo \
+ 	elf32-ia64.lo \
  	elf64-ia64.lo \
  	elf64-gen.lo \
  	elfn32-mips.lo \

Re: build failure for ia64 (due to -Werror)

[Ben Elliston]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

Hi Nick

> I am unable to reproduce this problem :-(
>
> Can you tell me how you configured the toolchain that produces this
> problem and which version of gcc you are using ?

GCC 3.3.5, configured with just --enable-targets=all (which is the important point!)

Cheers, Ben

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: build failure for ia64 (due to -Werror)

[Andreas Schwab]

James E Wilson <wilson@specifixinc.com> writes:

> On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
>> IMHO the only change we need is to check for BFD_HOST_64_BIT and error out
>> if that is not defined.
>
> Doesn't that break --enable-targets=all on a 32-bit host without long
> long?

Yes, that is true.  Although they are becoming rarer nowadays, and whether
it is worth to support this combination is another question.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build failure for ia64 (due to -Werror)

[Alan Modra]

On Fri, Mar 18, 2005 at 06:04:18PM -0800, James E Wilson wrote:
> On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
> > This is wrong.  bfd_uint64_t does not require a 64-bit BFD, only a native
> > 64-bit type (be it long long or long).
> 
> Another thing I find confusing here, if what you say is right, then why
> did Alan go to all of the trouble of removing all 64-bit types from the
> elfNN_ia64_relax_brl function last month?  I am assuming there is a
> reason why he made such a large change, when a much simpler one could
> have been made if you are right.  Perhaps my assumption is wrong.

I did more than strictly necessary, that's all.  Andreas is correct that
elfxx-ia64.c only needs a 64-bit host type and minor changes.  Larger
changes are needed, along the lines of my relax_brl patch, if the 32-bit
version of elfxx-ia64.c is to compile without a 64-bit host type.
Sorry to add to the confusion..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
> IMHO the only change we need is to check for BFD_HOST_64_BIT and error out
> if that is not defined.

Doesn't that break --enable-targets=all on a 32-bit host without long
long?  We will try to compile elf32-ia64.c and error out, because
elf32-ia64.c requires 64-bit integer types.  This presumably would work
if the elf32-ia64.c file was not included in the build.  Ergo, the
assumption that elf32-ia64.c should not be included in BFD32_BACKENDS.

As a safety measure, we could add ifdefs as you suggest to verify that
bfd_vma is the 64-bit type that we require and error out then.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
> This is wrong.  bfd_uint64_t does not require a 64-bit BFD, only a native
> 64-bit type (be it long long or long).

Another thing I find confusing here, if what you say is right, then why
did Alan go to all of the trouble of removing all 64-bit types from the
elfNN_ia64_relax_brl function last month?  I am assuming there is a
reason why he made such a large change, when a much simpler one could
have been made if you are right.  Perhaps my assumption is wrong.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
> James E Wilson <wilson@specifixinc.com> writes
> > You missed the point.  First of all, there is no bfd_uint64_t type when
> > there is no 64-bit BFD.
> This is wrong.  bfd_uint64_t does not require a 64-bit BFD, only a native
> 64-bit type (be it long long or long).

I can't argue this, as I've already said I don't understand fully how
this stuff works.  I can only point to Alan's comments which insist that
there are other problems here.

I am trying to figure out how this stuff works, but you need to give me
some time, and meanwhile, please don't make any rash changes to the
IA-64 port.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 17:23, Andreas Schwab wrote:
> The cast was clearly bogus, because it violated the strict aliasing
> rules.

I agree the change did something useful.   However, I disagree that the
change was required to make the file work.

It only violated strict aliasing rules because it was compiled with a
32-bit bfd_vma which is wrong.  If it was compiled with a proper 64-bit
bfd_vma, as required by the port, then there is no aliasing violation,
and hence no serious bug.  There was only a minor issue of the code not
being as clean as possible.

So the problem isn't that the code had a bogus cast.  The problem is
that it was compiled with the wrong bfd_vma type.  That is the problem
that I think should be fixed.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[Andreas Schwab]

James E Wilson <wilson@specifixinc.com> writes:

> You missed the point.  First of all, there is no bfd_uint64_t type when
> there is no 64-bit BFD.

This is wrong.  bfd_uint64_t does not require a 64-bit BFD, only a native
64-bit type (be it long long or long).

> Secondly, all bfd_get_64 calls will fail when there is no 64-bit BFD.

No.  They work perfectly well when a 64-bit type is available.

> There are no changes needed in elfxx-ia64.c, not even the obvious one
> that you already checked in,

The cast was clearly bogus, because it violated the strict aliasing
rules.

> The only change we need here is a Makefile.am change.

IMHO the only change we need is to check for BFD_HOST_64_BIT and error out
if that is not defined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 16:17, Andreas Schwab wrote:
> Ok, this is broken too.  I've reviewed all uses of bfd_vma and came up
> with this patch.  I think that should cover all those problems.  Maybe we
> should even dump ia64_insn and use bfd_uint64_t throughout instead?

You missed the point.  First of all, there is no bfd_uint64_t type when
there is no 64-bit BFD.  Secondly, all bfd_get_64 calls will fail when
there is no 64-bit BFD.  They call BFD_FAIL() in this case.  So all
bfd_get_64 calls need to be replaced with bfd_get_32 calls, and likewise
for other related functions, bfd_put_64, bfd_getl64, bfd_putl64, etc. 
Also, all long long constants (search for LL) will need to be removed. 
We can not have any uses of any 64-bit integer type at all.  There is
quite a bit of rewriting to make this all work, and we will need to
remember not to accidentally reintroduce any 64-bit code in the future. 
See for instance the elfNN_ia64_relax_brl change that Alan made last
month.

I think this is all pointless.  The elf32_ia64 vectors in config.bfd are
already protected by BFD64.  I think the problem is just what Ian
pointed out, which is that elf32-ia64.c is misclassified as a 32-bit
target in BFD32_BACKENDS etc.  It really is a 64-bit target that
generates 32-bit code, and requires a 64-bit BFD.  Hence the proper
solution is to stop compiling it on 32-bit hosts without long long. 
(Note: bfd assumes no long long is needed when --enable-targets=all is
used, unless you use --enable-64-bit-bfd.)

There are no changes needed in elfxx-ia64.c, not even the obvious one
that you already checked in, nor the one that Alan made last month, nor
the one you just proposed.

The only change we need here is a Makefile.am change.

But first I need to figure out how this stuff works.  All 3 machines on
my desk are 64-bit machines (even the embedded one), so I need to try
doing a build elsewhere.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> This only hides other more serious bugs in this function if bfd_vma is
> 32-bit.  For instance,
>
>     case IA64_OPND_IMMU64:
>       hit_addr -= (long) hit_addr & 0x3;
>       t0 = bfd_getl64 (hit_addr);
>       t1 = bfd_getl64 (hit_addr + 8);

Ok, this is broken too.  I've reviewed all uses of bfd_vma and came up
with this patch.  I think that should cover all those problems.  Maybe we
should even dump ia64_insn and use bfd_uint64_t throughout instead?

Andreas.

2005-03-19  Andreas Schwab  <schwab@suse.de>

	* elfxx-ia64.c (elfNN_ia64_relax_ldxmov): Change type of insn to
	ia64_insn and type of dword to bfd_uint64_t.
	(elfNN_ia64_install_value): Change type of t0, t1 and dword to
	bfd_uint64_t.
	(elfNN_ia64_unwind_entry_compare): Change type of av and bv to
	bfd_uint64_t.

Index: bfd/elfxx-ia64.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
retrieving revision 1.150
diff -u -a -p -a -u -p -r1.150 bfd/elfxx-ia64.c
--- bfd/elfxx-ia64.c 18 Mar 2005 21:31:31 -0000	1.150
+++ bfd/elfxx-ia64.c 19 Mar 2005 00:14:10 -0000
@@ -1213,7 +1213,8 @@ elfNN_ia64_relax_ldxmov (contents, off)
      bfd_vma off;
 {
   int shift, r1, r3;
-  bfd_vma dword, insn;
+  ia64_insn insn;
+  bfd_uint64_t dword;
 
   switch ((int)off & 0x3)
     {
@@ -3119,7 +3120,7 @@ elfNN_ia64_install_value (hit_addr, v, r
 {
   const struct ia64_operand *op;
   int bigendian = 0, shift = 0;
-  bfd_vma t0, t1, dword;
+  bfd_uint64_t t0, t1, dword;
   ia64_insn insn;
   enum ia64_opnd opnd;
   const char *err;
@@ -3652,7 +3653,7 @@ elfNN_ia64_unwind_entry_compare (a, b)
      const PTR a;
      const PTR b;
 {
-  bfd_vma av, bv;
+  bfd_uint64_t av, bv;
 
   av = bfd_get_64 (elfNN_ia64_unwind_entry_compare_bfd, a);
   bv = bfd_get_64 (elfNN_ia64_unwind_entry_compare_bfd, b);

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build failure for ia64 (due to -Werror)

[Alan Modra]

On Fri, Mar 18, 2005 at 12:28:13PM -0800, James E Wilson wrote:
> to suggest that other elf64-* files have the same problem.  elf64-ppc.c
> is using bfd_get_64 for instance, as are some others.

That's fine in elf64-ppc.c.  We always have a 64-bit BFD there.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: build failure for ia64 (due to -Werror)

[Alan Modra]

On Fri, Mar 18, 2005 at 10:33:26PM +0100, Andreas Schwab wrote:
> James E Wilson <wilson@specifixinc.com> writes:
> 
> > On Fri, 2005-03-18 at 04:21, Alan Modra wrote:
> >> I would guess 32-bit host, no --enable-64-bit-bfd.  Then "bfd_vma insn"
> >> is 32-bit and ia64_insn is long long.  There's worse things in that code
> >> than type-punned pointers..
> >
> > I believe this can only happen if --enable-targets=all is used.
> >
> > I see this is a documented feature in configure.in.  This seems like a
> > flaw to me.  The elfxx-ia64.c file won't work without a 64-bit integer
> > type, and it seems unreasonable to try to fix this.
> 
> The use of 32-bit vs 64-bit bfd_vma has nothing to do with the general
> availability of a 64-bit type.  This bug is trivial to fix.  I've checked
> in this patch as obvious.
> 
> Andreas.
> 
> 2005-03-18  Andreas Schwab  <schwab@suse.de>
> 
> 	* elfxx-ia64.c (elfNN_ia64_install_value): Change type of insn
> 	from bfd_vma to ia64_insn, remove broken cast.

This only hides other more serious bugs in this function if bfd_vma is
32-bit.  For instance,

    case IA64_OPND_IMMU64:
      hit_addr -= (long) hit_addr & 0x3;
      t0 = bfd_getl64 (hit_addr);
      t1 = bfd_getl64 (hit_addr + 8);

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 13:12, Ian Lance Taylor wrote:
> Or perhaps we just need to move elf32-ia64.c from BFD32_BACKENDS to
> BFD64_BACKENDS in bfd/Makefile.am.

OK, thanks, I see the problem now.  With 40-bit instructions, a few
80-bit instructions, 128-bit bundles, and 64-bit unwind info, it is
easier and more convenient if we can assume a 64-bit type exists, even
if this is a 32-bit target.  Things could be fixed if we had to though,
Alan fixed elfNN_ia64_relax_brl last month to work with a 32-bit
bfd_vma.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[Andreas Schwab]

James E Wilson <wilson@specifixinc.com> writes:

> On Fri, 2005-03-18 at 04:21, Alan Modra wrote:
>> I would guess 32-bit host, no --enable-64-bit-bfd.  Then "bfd_vma insn"
>> is 32-bit and ia64_insn is long long.  There's worse things in that code
>> than type-punned pointers..
>
> I believe this can only happen if --enable-targets=all is used.
>
> I see this is a documented feature in configure.in.  This seems like a
> flaw to me.  The elfxx-ia64.c file won't work without a 64-bit integer
> type, and it seems unreasonable to try to fix this.

The use of 32-bit vs 64-bit bfd_vma has nothing to do with the general
availability of a 64-bit type.  This bug is trivial to fix.  I've checked
in this patch as obvious.

Andreas.

2005-03-18  Andreas Schwab  <schwab@suse.de>

	* elfxx-ia64.c (elfNN_ia64_install_value): Change type of insn
	from bfd_vma to ia64_insn, remove broken cast.

Index: bfd/elfxx-ia64.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
retrieving revision 1.149
retrieving revision 1.150
diff -u -a -p -u -p -a -r1.149 -r1.150
--- bfd/elfxx-ia64.c	14 Mar 2005 18:55:44 -0000	1.149
+++ bfd/elfxx-ia64.c	18 Mar 2005 21:31:31 -0000	1.150
@@ -3119,7 +3119,8 @@ elfNN_ia64_install_value (hit_addr, v, r
 {
   const struct ia64_operand *op;
   int bigendian = 0, shift = 0;
-  bfd_vma t0, t1, insn, dword;
+  bfd_vma t0, t1, dword;
+  ia64_insn insn;
   enum ia64_opnd opnd;
   const char *err;
   size_t size = 8;
@@ -3308,7 +3309,7 @@ elfNN_ia64_install_value (hit_addr, v, r
       insn = (dword >> shift) & 0x1ffffffffffLL;
 
       op = elf64_ia64_operands + opnd;
-      err = (*op->insert) (op, val, (ia64_insn *)& insn);
+      err = (*op->insert) (op, val, &insn);
       if (err)
 	return bfd_reloc_overflow;
 

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build failure for ia64 (due to -Werror)

[Ian Lance Taylor]

Ian Lance Taylor <ian@airs.com> writes:

> If you don't have a 64-bit host, nor a 64-bit target, nor do you
> configure with --enable-64-bit-bfd, then --enable-targets=all should
> only permit the use of 32-bit targets.  This is implemented through
> the rather odd mechanism of using #ifdef BFD64 in bfd/config.bfd, from
> which targmatch.h is constructed.
> 
> Perhaps this has broken somehow.

Or perhaps we just need to move elf32-ia64.c from BFD32_BACKENDS to
BFD64_BACKENDS in bfd/Makefile.am.

Ian

Re: build failure for ia64 (due to -Werror)

[Ian Lance Taylor]

James E Wilson <wilson@specifixinc.com> writes:

> On Fri, 2005-03-18 at 04:21, Alan Modra wrote:
> > I would guess 32-bit host, no --enable-64-bit-bfd.  Then "bfd_vma insn"
> > is 32-bit and ia64_insn is long long.  There's worse things in that code
> > than type-punned pointers..
> 
> I believe this can only happen if --enable-targets=all is used.
> 
> I see this is a documented feature in configure.in.  This seems like a
> flaw to me.  The elfxx-ia64.c file won't work without a 64-bit integer
> type, and it seems unreasonable to try to fix this.  A quick look seems
> to suggest that other elf64-* files have the same problem.  elf64-ppc.c
> is using bfd_get_64 for instance, as are some others.
> 
> I suppose I could add something like
> #ifndef BFD64
> #error This target requires a 64 bit integer type.
> #endif
> to the elfxx-ia64.c file to make the problem more obvious if people
> think something needs to be done.
> 
> It might be better to fix the --enable-targets=all support.  We have
> enough 64-bit targets by now that perhaps --enable-targets=all should
> force use of BFD64.

If you don't have a 64-bit host, nor a 64-bit target, nor do you
configure with --enable-64-bit-bfd, then --enable-targets=all should
only permit the use of 32-bit targets.  This is implemented through
the rather odd mechanism of using #ifdef BFD64 in bfd/config.bfd, from
which targmatch.h is constructed.

Perhaps this has broken somehow.

Ian

Re: build failure for ia64 (due to -Werror)

[James E Wilson]

On Fri, 2005-03-18 at 04:21, Alan Modra wrote:
> I would guess 32-bit host, no --enable-64-bit-bfd.  Then "bfd_vma insn"
> is 32-bit and ia64_insn is long long.  There's worse things in that code
> than type-punned pointers..

I believe this can only happen if --enable-targets=all is used.

I see this is a documented feature in configure.in.  This seems like a
flaw to me.  The elfxx-ia64.c file won't work without a 64-bit integer
type, and it seems unreasonable to try to fix this.  A quick look seems
to suggest that other elf64-* files have the same problem.  elf64-ppc.c
is using bfd_get_64 for instance, as are some others.

I suppose I could add something like
#ifndef BFD64
#error This target requires a 64 bit integer type.
#endif
to the elfxx-ia64.c file to make the problem more obvious if people
think something needs to be done.

It might be better to fix the --enable-targets=all support.  We have
enough 64-bit targets by now that perhaps --enable-targets=all should
force use of BFD64.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: build failure for ia64 (due to -Werror)

[Alan Modra]

On Fri, Mar 18, 2005 at 11:24:26AM +0000, Nick Clifton wrote:
> Hi Ben,
> 
> >gcc -DHAVE_CONFIG_H -I. -I/home/bje/source/src/bfd -I. -D_GNU_SOURCE 
> >-DTRAD_CORE -I.
> >-I/home/bje/source/src/bfd -I/home/bje/source/src/bfd/../include
> >-I/home/bje/source/src/bfd/../intl -I../intl -W -Wall -Wstrict-prototypes
> >-Wmissing-prototypes -Werror -g -O2 -c elf32-ia64.c -o elf32-ia64.o
> >elf32-ia64.c: In function `elf32_ia64_install_value':
> >elf32-ia64.c:3311: warning: dereferencing type-punned pointer will break
> >strict-aliasing rules
> 
> I am unable to reproduce this problem :-(
> 
> Can you tell me how you configured the toolchain that produces this 
> problem and which version of gcc you are using ?

I would guess 32-bit host, no --enable-64-bit-bfd.  Then "bfd_vma insn"
is 32-bit and ia64_insn is long long.  There's worse things in that code
than type-punned pointers..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: build failure for ia64 (due to -Werror)

[Nick Clifton]

Hi Ben,

> gcc -DHAVE_CONFIG_H -I. -I/home/bje/source/src/bfd -I. -D_GNU_SOURCE 
> -DTRAD_CORE -I.
> -I/home/bje/source/src/bfd -I/home/bje/source/src/bfd/../include
> -I/home/bje/source/src/bfd/../intl -I../intl -W -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Werror -g -O2 -c elf32-ia64.c -o elf32-ia64.o
> elf32-ia64.c: In function `elf32_ia64_install_value':
> elf32-ia64.c:3311: warning: dereferencing type-punned pointer will break
> strict-aliasing rules

I am unable to reproduce this problem :-(

Can you tell me how you configured the toolchain that produces this 
problem and which version of gcc you are using ?

Cheers
   Nick

build failure for ia64 (due to -Werror)

[Ben Elliston]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

I don't have time to fix it today, but someone else might like to?

Ben


gcc -DHAVE_CONFIG_H -I. -I/home/bje/source/src/bfd -I. -D_GNU_SOURCE -DTRAD_CORE -I.
-I/home/bje/source/src/bfd -I/home/bje/source/src/bfd/../include
-I/home/bje/source/src/bfd/../intl -I../intl -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -c elf32-ia64.c -o elf32-ia64.o
elf32-ia64.c: In function `elf32_ia64_install_value':
elf32-ia64.c:3311: warning: dereferencing type-punned pointer will break
strict-aliasing rules

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]