public inbox for
help / color / mirror / Atom feed
From: "Christian Ehrhardt" <>
Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86
Date: Wed, 21 May 2003 12:46:00 -0000	[thread overview]
Message-ID: <> (raw)

The following reply was made to PR optimization/10877; it has been noted by GNATS.

From: "Christian Ehrhardt" <>
To: Wolfgang Bangerth <>,
Cc: Andrew Pinski <>,,,
Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86
Date: Wed, 21 May 2003 14:39:38 +0200

 [ Added Eric to cc because his patch might have triggered this gas bug. ]
 On Tue, May 20, 2003 at 12:05:35PM -0500, Wolfgang Bangerth wrote:
 > > Feeding this assembler file into gcc 3.2 on an Intel box works for me
 > > and the program doesn't crash! This might mean that we have an
 > > assembler/binutils problem here.
 > Whereas if I do the same, it crashes. So you seem to have a point :-)
 This is definitely a gas Bug! The problem is the following instruction:
 	addl    $_GLOBAL_OFFSET_TABLE_, %eax
 This tells the assembler that we want the difference between the adress
 of this addl instruction and the start of the global offset table to be
 added to %eax. When translating this request into relocation records an
 R_386_GOTPC relocation is used.
 However, this relocation calculates the difference between the place where
 the relocation takes place and the start of the global offset table.
 Hence the assembler must add an addend to fix up the difference between
 the address of the addl instruction and the address of its immediate
 operand (the latter is the place of the relocation).
 Now in the %eax case gas emmits the 0x05 opcode for addl imm32,%eax
 with a length of 1 byte. If the register isn't %eax the assembler
 has to use the longer 0x81 0xc3 opcode. Both opcodes are followed by
 the immediate 32bit Operand.
 I.e. if %eax is used the addend for the R_386_GOTPC relocation must be 1
 but for all other registers it must be 2 due to the different length of
 the opcode. This is what some gas versions seem to get wrong.
 So what should we do with this report? Do we want to work around
 this bug in gcc or should we close it and tell people to upgrade
 binutils. The bug is fixed at least since 20020717 (SuSE).
    regards   Christian

             reply	other threads:[~2003-05-21 12:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-21 12:46 Christian Ehrhardt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-21 11:28 Christian Ehrhardt
2003-05-21  8:46 Christian Ehrhardt
2003-05-20 22:46 Janis Johnson
2003-05-20 19:36 Andrew Pinski
2003-05-20 19:27 Andrew Pinski
2003-05-20 19:16 Wolfgang Bangerth
2003-05-20 17:16 Andrew Pinski
2003-05-20 17:06 Wolfgang Bangerth
2003-05-20 17:06 Christian Ehrhardt
2003-05-20 16:16 Wolfgang Bangerth
2003-05-20 13:56 Wolfgang Bangerth
2003-05-20  2:06 Andrew Pinski
2003-05-20  1:16 bangerth

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:

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

  git send-email \ \ \ \ \

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