public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: Nick Clifton <nickc@redhat.com>, Ben Elliston <bje@au1.ibm.com>,
	binutils@sources.redhat.com
Subject: Re: build failure for ia64 (due to -Werror)
Date: Fri, 18 Mar 2005 22:15:00 -0000	[thread overview]
Message-ID: <1111177693.9897.18.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <20050318122113.GY21148@bubble.modra.org>

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


  reply	other threads:[~2005-03-18 20:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18  3:58 Ben Elliston
2005-03-18 13:14 ` Nick Clifton
2005-03-18 14:13   ` Alan Modra
2005-03-18 22:15     ` James E Wilson [this message]
2005-03-18 22:49       ` Ian Lance Taylor
2005-03-18 23:31         ` Ian Lance Taylor
2005-03-18 23:52           ` James E Wilson
2005-03-18 23:37       ` Andreas Schwab
2005-03-19  0:42         ` Alan Modra
2005-03-19  1:56           ` Andreas Schwab
2005-03-19  4:04             ` James E Wilson
2005-03-19  4:30               ` Andreas Schwab
2005-03-19  9:44                 ` James E Wilson
2005-03-19 12:13                 ` James E Wilson
2005-03-19 17:57                 ` James E Wilson
2005-03-19 18:37                   ` Alan Modra
2005-03-19 18:33                 ` James E Wilson
2005-03-19 19:00                   ` Andreas Schwab
2005-03-23  9:45           ` James E Wilson
2005-03-23 19:24             ` Nick Clifton
2005-03-24  9:27               ` James E Wilson
2005-03-24 14:58                 ` Nick Clifton
2005-03-19  0:56       ` Alan Modra
2005-03-22  2:19   ` Ben Elliston
2005-03-20  9:26 Paul Schlie
2005-03-20 19:42 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111177693.9897.18.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=bje@au1.ibm.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).