Re: A very "strange" bug in gcc 2.96

Re: A very "strange" bug in gcc 2.96

[Mike Stump]

> Date: 21 May 2000 13:42:42 -0700
> From: Ian Lance Taylor <ian@zembu.com>
> To: drepper@cygnus.com

> Note that the reason the new optimization fails is that the
> assembler translates the jmp into a short branch instruction.  If
> the assembler translated the jmp into a 32 bit branch with a reloc,
> then I believe everything would still work correctly.  At least on
> the i386.  However, doing this would disable part of the
> optimization.

Thanks for the description, I certainly didn't understand the reason
from the other posts.  Given this description, I think the default
should be off for targets that can only have fewer reloc bits than the
instruction it is replacing (if the number is sufficiently small).
I'd rather place the burden on people that want this to complete the
job, and arrange for potentially the same or more reloc bits, or place
the burden on people who want an optimization that can cause there
code to not link, to specifically ask for it.

Now, what is sufficiently small?  Clearly <16 bits is probably
sufficiently small.  >=30 probably isn't.

I've seen enough problems at 22 to make me want to shy away from it.

I generally don't like compilers that generate short code, then ask
you to recompile with other options when the code choice fails.  I
think this goes against the spirit of the FSF coding conventions.

Re: A very "strange" bug in gcc 2.96

[Richard Henderson]

On Mon, May 22, 2000 at 10:42:46AM -0700, Mike Stump wrote:
> Given this description, I think the default
> should be off for targets that can only have fewer reloc bits than the
> instruction it is replacing (if the number is sufficiently small).

Um, the *default* is off.  Period.  One has to add stuff to the
machine description before tail calls happen *at all*.  That stuff
includes the answer to the question "can I tail call to this function".


r~

Re: A very "strange" bug in gcc 2.96

[Eric W. Biederman]

Mike Stump <mrs@windriver.com> writes:

> > Date: 21 May 2000 13:42:42 -0700
> > From: Ian Lance Taylor <ian@zembu.com>
> > To: drepper@cygnus.com
> 
> > Note that the reason the new optimization fails is that the
> > assembler translates the jmp into a short branch instruction.  If
> > the assembler translated the jmp into a 32 bit branch with a reloc,
> > then I believe everything would still work correctly.  At least on
> > the i386.  However, doing this would disable part of the
> > optimization.
> 

The problem is that gas when it's deciding how long to make the jmp
instruction for x86 it was forgetting to take relocations into account.
So gcc is fine.  It's just that for gcc3.0 you need to require
an updated/fixed version of gas.

Which I believe is now at exists.

Eric

Re: A very "strange" bug in gcc 2.96

[Richard Henderson]

On Tue, May 23, 2000 at 09:04:58AM -0700, Ian Lance Taylor wrote:
>    Sparc, Alpha, and IA-64 at a minimum adjust the compiler's notion
>    of the appropriate name binding rules depending on -fpic.
> 
> In what way, other than the recently introduced optimization?  I'm
> genuinely curious.

Symbols that are known to be defined locally are referenced with
gp-relative addressing instead of indirectly through the got.
This is trivially all static variables, but also includes

	int i = 0;
	int j;		// if !TREE_COMMON (via -fno-common or c++)

On Alpha it also controls whether we fold

	ldq $27, foo($29)	!literal!0
	jsr $26, ($27), foo	!lituse_jsr!0
	ldah $29, 0($26)	!gpdisp!1
	lda $29, 0($29)		!gpdisp!1
to 
	bsr $26, $foo..ng

where "$foo..ng" is a special symbol emitted by the compiler
in foo after the gp is loaded.



r~

Re: A very "strange" bug in gcc 2.96

[Ian Lance Taylor]

   From: Ulrich Drepper <drepper@redhat.com>
   Date: 21 May 2000 13:33:13 -0700

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

   > It's not broken to build a shared library with an object compiled
   > without -fPIC.  It is often a convenience, when a single object is
   > used in multiple ways.

   This is still broken.  There is absolutely no reason why the build
   process could not be fixed.  You are only giving stupid and lazy
   programmers an excuse to not fix their code.

People don't always have sources for their objects, so fixing the code
is not always an option.

   There are platforms where it is really absolutely necessary to use
   -fPIC is you are building a DSO and requiring this on more platforms
   just increases portability.

What platforms are those?  (The MIPS requires PIC if you want to any
dynamic linking at all, but I'm not aware of any platform which
requires PIC for shared objects and only for shared objects.)

Ian

Re: A very "strange" bug in gcc 2.96

[Ian Lance Taylor]

   Date: Sun, 21 May 2000 21:00:41 -0700
   From: Geoff Keating <geoffk@cygnus.com>

   > Date: 21 May 2000 13:42:42 -0700
   > From: Ian Lance Taylor <ian@zembu.com>

   > It's not broken to build a shared library with an object compiled
   > without -fPIC.  It is often a convenience, when a single object is
   > used in multiple ways.

   Then the linker or assembler is broken, right?

   It's surely valid, if unusual, assembler to branch to other object
   files.

   I know this works on ppc.

   It may be that fully supporting this feature (non -fpic in shared
   libraries) means something as nasty as implementing linker relaxation,
   but...

Correct.

I tried to say something along these lines, but I was probably too
terse.  Or maybe I forgot.

Ian

Re: A very "strange" bug in gcc 2.96

[Alan Modra]

On Mon, 22 May 2000, Jeffrey A Law wrote:

> There was a lot of discussion on this over the weekend.  Anyone care to 
> post an exec summary?

It's an x86 specific gas bug, now fixed.

-- 
Linuxcare.  Support for the Revolution.

Re: A very "strange" bug in gcc 2.96

[Mike Stump]

> Date: Mon, 22 May 2000 11:57:09 -0700
> From: Richard Henderson <rth@cygnus.com>
> To: Mike Stump <mrs@windriver.com>
> Cc: drepper@cygnus.com, ian@zembu.com, binutils@sourceware.cygnus.com,
>         egcs@egcs.cygnus.com, hjl@lucon.org, mark@codesourcery.com
> References: < 200005221742.KAA19115@kankakee.wrs.com >
> In-Reply-To: < 200005221742.KAA19115@kankakee.wrs.com >; from Mike Stump on Mon, May 22, 2000 at 10:42:46AM -0700

> On Mon, May 22, 2000 at 10:42:46AM -0700, Mike Stump wrote:
> > Given this description, I think the default
> > should be off for targets that can only have fewer reloc bits than the
> > instruction it is replacing (if the number is sufficiently small).

> Um, the *default* is off.  Period.  One has to add stuff to the
> machine description before tail calls happen *at all*.  That stuff
> includes the answer to the question "can I tail call to this function".

I was under the impression that we got to this position because
someone had added it to x86 and that that default was to use it, for
it to be on, and that the number of reloc bits was smaller than
before.  Sorry if it isn't.  Is my understanding incomplete?

Re: A very "strange" bug in gcc 2.96

[Geoff Keating]

> Date: Mon, 22 May 2000 11:28:44 -0600
> From: Jeffrey A Law <law@cygnus.com>

> There was a lot of discussion on this over the weekend.  Anyone care to 
> post an exec summary?

Last I heard, HJ had posted a patch to the binutils mailing list for
this, to fix the assembler.  There is general agreement that it is an
assembler problem.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: A very "strange" bug in gcc 2.96

[Jeffrey A Law]

  In message < 20000521123156E.mitchell@codesourcery.com >you write:
  > >>>>> "H" == H J Lu <hjl@lucon.org> writes:
  > 
  >     H> There is the ia32 asm ouput from gcc 2.96 with -O2. Please
  >     H> notice that
  > 
  >     H> 	jmp foo
  > 
  >     H> is generated, instead of
  > 
  >     H>         call foo leave ret
  > 
  > This is presumably due to the new sibling call optimization.
  > 
  > Richard, Jeff: I would very much appreciate your comments on this
  > issue.
There was a lot of discussion on this over the weekend.  Anyone care to 
post an exec summary?

My gut feeling is the assembler should be leaving this as a 32bit jump so
that it can be twiddled as necessary at link time.

jeff

Re: A very "strange" bug in gcc 2.96

[Mark Mitchell]

>>>>> "Andi" == Andi Kleen <ak@suse.de> writes:

    Andi> Mark Mitchell <mark@codesourcery.com> writes:
    >>
    H> without -fPIC. With "jmp foo", it doesn't work anymore. If it
    H> is intentional, we should declare PIC is required for building
    H> shared libraries.
    >>  I think that using -fPIC should be required for building
    >> shared libraries.

    Andi> Some x86 people prefer not to use -fPIC for all shared
    Andi> library functions: it costs you a few duplicated code pages,
    Andi> but gives you a valuable register which can make a big
    Andi> difference in a important inner loop. Making gcc more clever
    Andi> about pic register handling could have the same effect, but
    Andi> currently using -fPIC means that you lost the register in a
    Andi> function if at least one global symbol is accessed.

That's a good point.  But, it's really a good argument for improving
the copmiler -- not for not requiring -fPIC for shared objects.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: A very "strange" bug in gcc 2.96

[Alan Modra]

The folowing patch should fix this x86 gas bug for x86.  x86 looks to
be the only architecture affected.

I committed it to the trunk, and it should probably go to the 2.10 branch
too.  I'll give you a chance to fire off any unfavourable comments before
doing so.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

gas/ChangeLog
	* config/tc-i386.c (tc_i386_fix_adjustable): Prevent adjustment
	for OBJ_MAYBE_ELF too.  Use S_IS_EXTERNAL instead of S_IS_EXTERN.
	(md_estimate_size_before_relax): Ensure jumps to weak and
	externally visible symbols are relocatable.

Index: config/tc-i386.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-i386.c,v
retrieving revision 1.49
diff -u -p -r1.49 tc-i386.c
--- tc-i386.c	2000/05/13 12:49:55	1.49
+++ tc-i386.c	2000/05/22 11:29:46
@@ -1023,13 +1023,12 @@ int
 tc_i386_fix_adjustable (fixP)
      fixS *fixP;
 {
-#if defined (OBJ_ELF) || defined (TE_PE)
+#if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF) || defined (TE_PE)
   /* Prevent all adjustments to global symbols, or else dynamic
      linking will not work correctly.  */
-  if (S_IS_EXTERN (fixP->fx_addsy))
+  if (S_IS_EXTERNAL (fixP->fx_addsy)
+      || S_IS_WEAK (fixP->fx_addsy))
     return 0;
-  if (S_IS_WEAK (fixP->fx_addsy))
-    return 0;
 #endif
   /* adjust_reloc_syms doesn't know about the GOT */
   if (fixP->fx_r_type == BFD_RELOC_386_GOTOFF
@@ -3765,12 +3764,19 @@ md_estimate_size_before_relax (fragP, se
   old_fr_fix = fragP->fr_fix;
   opcode = (unsigned char *) fragP->fr_opcode;
   /* We've already got fragP->fr_subtype right;  all we have to do is
-     check for un-relaxable symbols.  */
-  if (S_GET_SEGMENT (fragP->fr_symbol) != segment)
-    {
-      /* symbol is undefined in this segment */
-      int code16 = fragP->fr_subtype & CODE16;
-      int size = code16 ? 2 : 4;
+     check for un-relaxable symbols.  On an ELF system, we can't relax
+     an externally visible symbol, because it may be overridden by a
+     shared library.  */
+  if (S_GET_SEGMENT (fragP->fr_symbol) != segment
+#if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF) || defined (TE_PE)
+      || S_IS_EXTERNAL (fragP->fr_symbol)
+      || S_IS_WEAK (fragP->fr_symbol)
+#endif
+      )
+    {
+      /* Symbol is undefined in this segment, or we need to keep a
+	 reloc so that weak symbols can be overridden.  */
+      int size = (fragP->fr_subtype & CODE16) ? 2 : 4;
 #ifdef BFD_ASSEMBLER
       enum bfd_reloc_code_real reloc_type;
 #else
@@ -3785,7 +3791,7 @@ md_estimate_size_before_relax (fragP, se
 			most of the time. ERY  */
 	  && S_GET_SEGMENT(fragP->fr_symbol) == undefined_section)
 	reloc_type = BFD_RELOC_386_PLT32;
-      else if (code16)
+      else if (size == 2)
 	reloc_type = BFD_RELOC_16_PCREL;
       else
 	reloc_type = BFD_RELOC_32_PCREL;

Re: A very "strange" bug in gcc 2.96

[Andreas Schwab]

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

"H . J . Lu" <hjl@lucon.org> writes:

|> On Mon, May 22, 2000 at 12:00:15PM +1000, Alan Modra wrote:
|> > On 21 May 2000, Eric W. Biederman wrote:
|> > 
|> > > "H . J . Lu" <hjl@lucon.org> writes:
|> > > 
|> > > > There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that
|> > > > 
|> > > > 	jmp	foo
|> > > > 
|> > > > is generated, instead of
|> > > > 
|> > > >         call foo
|> > > >         leave
|> > > >         ret
|> > > > 
|> > > > It is ok if foo () is a static function. But for extern, they are
|> > > > not the same. The GNU linker supports shared libraries even without
|> > > > -fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
|> > > > we should declare PIC is required for building shared libraries.
|> > > > Personally, I don't like compiler does this behind my back. It took
|> > > > me several days to figure out why things stopped working.
|> > > > 
|> > > > Thanks.
|> > > 
|> > > What would need to change with gnu as and gnu ld to cause this to work?
|> > > Is it simply that as needs to emit a location record when jumping
|> > > to labels declared .globl?
|> > 
|> > For x86, gas/config/tc-i386.c:md_estimate_size_before_relax needs to be
|> > taught how to handle this case properly.  (I think that's all that's
|> > needed...)
|> > 
|> 
|> That is only ia32. What about others?

AFAIK the m68k assembler does this correctly (ie, not relaxing references
to global symbols, see gas/config/tc-m68k.c:relaxable_symbol).  The ia32
assembler should do the same, IMHO.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: A very "strange" bug in gcc 2.96

[Andi Kleen]

Mark Mitchell <mark@codesourcery.com> writes:
> 
>     H> without -fPIC. With "jmp foo", it doesn't work anymore. If it
>     H> is intentional, we should declare PIC is required for building
>     H> shared libraries.
> 
> I think that using -fPIC should be required for building shared
> libraries.

Some x86 people prefer not to use -fPIC for all shared library functions:
it costs you a few duplicated code pages, but gives you a valuable register
which can make a big difference in a important inner loop. Making gcc more
clever about pic register handling could have the same effect, but currently
using -fPIC means that you lost the register in a function if at least
one global symbol is accessed.


-Andi

Re: A very "strange" bug in gcc 2.96

[H . J . Lu]

On Mon, May 22, 2000 at 02:35:02PM +1000, Alan Modra wrote:
> On Sun, 21 May 2000, H . J . Lu wrote:
> 
> > > For x86, gas/config/tc-i386.c:md_estimate_size_before_relax needs to be
> > > taught how to handle this case properly.  (I think that's all that's
> > > needed...)
> > 
> > That is only ia32. What about others?
> 
> If what I understand about this problem is correct, then it's caused by a
> feature in the x86 assembler, namely that jumps are emitted using the
> smallest possible opcode that the assembler "knows" it can use.  If jumps
> aren't treated specially on other gas architectures then there shouldn't
> be a problem.
> 
> x86 gas currently assumes that if a jump target is within the same
> segment, then it is OK to consider using a small jump, and that a reloc
> isn't needed.  That assumption breaks badly now that gcc might be emitting
> jumps to weak symbols.
> 

Assume it is correct, do you have a patch I can try?


H.J.

Re: A very "strange" bug in gcc 2.96

[Alan Modra]

On Sun, 21 May 2000, H . J . Lu wrote:

> > For x86, gas/config/tc-i386.c:md_estimate_size_before_relax needs to be
> > taught how to handle this case properly.  (I think that's all that's
> > needed...)
> 
> That is only ia32. What about others?

If what I understand about this problem is correct, then it's caused by a
feature in the x86 assembler, namely that jumps are emitted using the
smallest possible opcode that the assembler "knows" it can use.  If jumps
aren't treated specially on other gas architectures then there shouldn't
be a problem.

x86 gas currently assumes that if a jump target is within the same
segment, then it is OK to consider using a small jump, and that a reloc
isn't needed.  That assumption breaks badly now that gcc might be emitting
jumps to weak symbols.

-- 
Linuxcare.  Support for the Revolution.

Re: A very "strange" bug in gcc 2.96

[Geoff Keating]

> Date: 21 May 2000 13:42:42 -0700
> From: Ian Lance Taylor <ian@zembu.com>

> It's not broken to build a shared library with an object compiled
> without -fPIC.  It is often a convenience, when a single object is
> used in multiple ways.

Then the linker or assembler is broken, right?

It's surely valid, if unusual, assembler to branch to other object
files.

I know this works on ppc.

It may be that fully supporting this feature (non -fpic in shared
libraries) means something as nasty as implementing linker relaxation,
but...
-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: A very "strange" bug in gcc 2.96

[Richard Henderson]

On Sun, May 21, 2000 at 01:42:42PM -0700, Ian Lance Taylor wrote:
> It's not broken to build a shared library with an object compiled
> without -fPIC.  It is often a convenience, when a single object is
> used in multiple ways.

There are quite a few places in GCC that we make assumptions about
symbol binding based on the lack of -fpic.  This is merely the first
to be quite so visible on ia32.

> This change will silently break existing code which works today and is
> wholly correct.  If this change is to be turned on by default, it must
> be carefully documented.

It's true that the documentation needs clarifying on this point...



r~

Re: A very "strange" bug in gcc 2.96

[H . J . Lu]

On Mon, May 22, 2000 at 12:00:15PM +1000, Alan Modra wrote:
> On 21 May 2000, Eric W. Biederman wrote:
> 
> > "H . J . Lu" <hjl@lucon.org> writes:
> > 
> > > There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that
> > > 
> > > 	jmp	foo
> > > 
> > > is generated, instead of
> > > 
> > >         call foo
> > >         leave
> > >         ret
> > > 
> > > It is ok if foo () is a static function. But for extern, they are
> > > not the same. The GNU linker supports shared libraries even without
> > > -fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
> > > we should declare PIC is required for building shared libraries.
> > > Personally, I don't like compiler does this behind my back. It took
> > > me several days to figure out why things stopped working.
> > > 
> > > Thanks.
> > 
> > What would need to change with gnu as and gnu ld to cause this to work?
> > Is it simply that as needs to emit a location record when jumping
> > to labels declared .globl?
> 
> For x86, gas/config/tc-i386.c:md_estimate_size_before_relax needs to be
> taught how to handle this case properly.  (I think that's all that's
> needed...)
> 

That is only ia32. What about others?


H.J.

Re: A very "strange" bug in gcc 2.96

[Alan Modra]

On 21 May 2000, Eric W. Biederman wrote:

> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that
> > 
> > 	jmp	foo
> > 
> > is generated, instead of
> > 
> >         call foo
> >         leave
> >         ret
> > 
> > It is ok if foo () is a static function. But for extern, they are
> > not the same. The GNU linker supports shared libraries even without
> > -fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
> > we should declare PIC is required for building shared libraries.
> > Personally, I don't like compiler does this behind my back. It took
> > me several days to figure out why things stopped working.
> > 
> > Thanks.
> 
> What would need to change with gnu as and gnu ld to cause this to work?
> Is it simply that as needs to emit a location record when jumping
> to labels declared .globl?

For x86, gas/config/tc-i386.c:md_estimate_size_before_relax needs to be
taught how to handle this case properly.  (I think that's all that's
needed...)

-- 
Linuxcare.  Support for the Revolution.

Re: A very "strange" bug in gcc 2.96

[Eric W. Biederman]

"H . J . Lu" <hjl@lucon.org> writes:

> There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that
> 
> 	jmp	foo
> 
> is generated, instead of
> 
>         call foo
>         leave
>         ret
> 
> It is ok if foo () is a static function. But for extern, they are
> not the same. The GNU linker supports shared libraries even without
> -fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
> we should declare PIC is required for building shared libraries.
> Personally, I don't like compiler does this behind my back. It took
> me several days to figure out why things stopped working.
> 
> Thanks.

What would need to change with gnu as and gnu ld to cause this to work?
Is it simply that as needs to emit a location record when jumping
to labels declared .globl?

Or do we need to emit a special variant of the jmp instruction to cause
gnu as to do the right thing? (yuck...)

In scheme this optimization is required, so it would be worth figuring
out how to do safely.

Eric

Re: A very "strange" bug in gcc 2.96

[Ulrich Drepper]

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

> It's not broken to build a shared library with an object compiled
> without -fPIC.  It is often a convenience, when a single object is
> used in multiple ways.

This is still broken.  There is absolutely no reason why the build
process could not be fixed.  You are only giving stupid and lazy
programmers an excuse to not fix their code.

There are platforms where it is really absolutely necessary to use
-fPIC is you are building a DSO and requiring this on more platforms
just increases portability.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: A very "strange" bug in gcc 2.96

[Ian Lance Taylor]

   From: Ulrich Drepper <drepper@redhat.com>
   Date: 21 May 2000 13:04:53 -0700

   "H . J . Lu" <hjl@lucon.org> writes:

   > If we take it out, it may disappoint some people. I'd prefer to turn
   > it on with a flag.

   I don't care if it disappoints anybody.  If smoething is broken it
   does not deserve to be preserved.  Especially since it hurts 99.9% of
   the applications which are not broken.  Just document it and let
   people disable the sibling call optimization.

It's not broken to build a shared library with an object compiled
without -fPIC.  It is often a convenience, when a single object is
used in multiple ways.

This change will silently break existing code which works today and is
wholly correct.  If this change is to be turned on by default, it must
be carefully documented.

Note that the reason the new optimization fails is that the assembler
translates the jmp into a short branch instruction.  If the assembler
translated the jmp into a 32 bit branch with a reloc, then I believe
everything would still work correctly.  At least on the i386.
However, doing this would disable part of the optimization.

Ian

Re: A very "strange" bug in gcc 2.96

[Ulrich Drepper]

"H . J . Lu" <hjl@lucon.org> writes:

> If we take it out, it may disappoint some people. I'd prefer to turn
> it on with a flag.

I don't care if it disappoints anybody.  If smoething is broken it
does not deserve to be preserved.  Especially since it hurts 99.9% of
the applications which are not broken.  Just document it and let
people disable the sibling call optimization.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: A very "strange" bug in gcc 2.96

[H . J . Lu]

On Sun, May 21, 2000 at 12:31:56PM -0700, Mark Mitchell wrote:
> 
> But, you are right that there is an issue here in that this does
> change behavior relative to older versions of the compiler.  Perhaps
> someone could clarify this piece of documentation from the gcc info
> pages:
> 
>   `-shared'
>        Produce a shared object which can then be linked with other
>        objects to form an executable.  Not all systems support this
>        option.  You must also specify `-fpic' or `-fPIC' on some systems
>        when you specify this option.
> 
> as well as the descriptions of -fpic and -fPIC.

We have been telling people it is a feature for the GNU ld and the GNU
C library. There are testcases in binutils for this fearture. If we
take it out, it may disappoint some people. I'd prefer to turn it on
with a flag. The problem with it is the code used to work now fails.
Sometimes, it is very hard to track it down. As the result, developers
may blame Linux.

H.J.

Re: A very "strange" bug in gcc 2.96

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> There is the ia32 asm ouput from gcc 2.96 with -O2. Please
    H> notice that

    H> 	jmp foo

    H> is generated, instead of

    H>         call foo leave ret

This is presumably due to the new sibling call optimization.

Richard, Jeff: I would very much appreciate your comments on this
issue.

    H> without -fPIC. With "jmp foo", it doesn't work anymore. If it
    H> is intentional, we should declare PIC is required for building
    H> shared libraries.

I think that using -fPIC should be required for building shared
libraries.

But, you are right that there is an issue here in that this does
change behavior relative to older versions of the compiler.  Perhaps
someone could clarify this piece of documentation from the gcc info
pages:

  `-shared'
       Produce a shared object which can then be linked with other
       objects to form an executable.  Not all systems support this
       option.  You must also specify `-fpic' or `-fPIC' on some systems
       when you specify this option.

as well as the descriptions of -fpic and -fPIC.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: A very "strange" bug in gcc 2.96

[Jakub Jelinek]

On Sun, May 21, 2000 at 11:59:08AM -0700, H . J . Lu wrote:
> There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that
> 
> 	jmp	foo
> 
> is generated, instead of
> 
>         call foo
>         leave
>         ret
> 
> It is ok if foo () is a static function. But for extern, they are
> not the same. The GNU linker supports shared libraries even without
> -fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
> we should declare PIC is required for building shared libraries.
> Personally, I don't like compiler does this behind my back. It took
> me several days to figure out why things stopped working.

IMHO we should just declare that -foptimize-sibling-calls is incompatible
with non-fPIC shared libraries.
I don't think we should kill useful optimizations by default just because
people are lazy to compile with -fPIC.
It is not only ia32 where this breaks, although on SPARC this might change
(because linker can optimize the tailcall using call instruction but cannot
do it with sethi/jmpl).

	Jakub

A very "strange" bug in gcc 2.96

[H . J . Lu]

There is the ia32 asm ouput from gcc 2.96 with -O2. Please notice that

	jmp	foo

is generated, instead of

        call foo
        leave
        ret

It is ok if foo () is a static function. But for extern, they are
not the same. The GNU linker supports shared libraries even without
-fPIC. With "jmp foo", it doesn't work anymore. If it is intentional,
we should declare PIC is required for building shared libraries.
Personally, I don't like compiler does this behind my back. It took
me several days to figure out why things stopped working.

Thanks.

H.J.
---x.c--
int foo ()
{
  return 8;
}

int bar ()
{
  return foo ();
}
---x.s--
	.file	"x.c"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 16
.globl foo
	.type	 foo,@function
foo:
	pushl	%ebp
	movl	$8, %eax
	movl	%esp, %ebp
	popl	%ebp
	ret
.Lfe1:
	.size	 foo,.Lfe1-foo
	.align 16
.globl bar
	.type	 bar,@function
bar:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	movl	%ebp, %esp
	popl	%ebp
	jmp	foo
.Lfe2:
	.size	 bar,.Lfe2-bar
	.ident	"GCC: (GNU) 2.96 20000517 (experimental)"