Bug 91056

Created attachment 91748 [details]
A small testcase

With "gcc -S -O2 x.c", I got

	.file	"x.c"
	.pred.safe_across_calls p1-p5,p16-p63
	.text
	.align 16
	.global bar#
	.proc bar#
bar:
	.prologue
	.body
	.bbb
	nop 0
	nop 0
	br.sptk.many foo#
	;;
	break.f 0
	;;
	.endp bar#
	.ident	"GCC: (GNU) 3.2.3 20030422 (Red Hat Linux 3.2.3-3)"

gp is not preserved.

And the problem is? The caller doesn't use gp at all, so it doesn't have to restore it.
Its caller is supposed to restore gp if it uses it.
Also, your example is a tail call, so there really must not be any gp restoring.

On page 5-2 in Itanium Software Conventions and Runtime Architecture
Guide, there are

...
a. On entry to a procedure, gp is guaranteed valide for that procedure.
b. At any direct procedure call, gp must be valid (for the caller). This
guarantees that an import stub (see Section 8.4.1) can access the linkage
table.
c. Any procedure call (indirect or direct) may modify gp - unless the call
is known to be local to the load module.
d. At procedure return, gp must be valid (for the returning prodecure).
This allows the compiler to optimize calls known to be local (i.e., the
exceptions to Rule 'c').

The effect of the rules is that gp must be treated as scratch register
at the point of call (i.e., it must be saved by the caller), and it must
be preserved from entry to exit.

Since bar () may modify gp, at the return of foo, gp must be valid for foo
even if foo doesn't use gp at all. Did I miss something here?

THIS IS ISSUE TRACKER 22133 opened as sev 2 on 5/18/03.

*** Bug 91140 has been marked as a duplicate of this bug. ***

FROM ISSUE TRACKER....
Event posted 06-28-2003 11:40am by hongjiu.lu with duration of 0.00        
This bug is very serious and affects all ia64 compilers, Intel compiler, HP
compiler and gcc. We need a way to tell if a .o file preserves GP or not.
Richard Henderson proposed to use a bit in e_flags in ELF header. Both Intel and
HP feel a note section is more appropriate.

I am uploading Intel's proposal. Intel will provide a patch for linker. If
necessry, Intel will provide a gcc patch to generate the note section.    

--------------------
Event posted 06-28-2003 11:41am by hongjiu.lu with duration of 0.00
note.txt
This is a proposal to add a property note section to .o file.

File uploaded: note.txt    

-----------------------
Event posted 06-28-2003 11:44am by hongjiu.lu with duration of 0.00
rfc.txt
This is a proposal to add a property note section to .o file. In another file,
we propose a NT_GNU_PROPETRTY_IA_64_PRESERVE_GP bit in the property note section
to indicate if a .o file preserves GP or not.

File uploaded: rfc.txt

Created attachment 92695 [details]
note.txt

Created attachment 92696 [details]
rfc.txt

I think Richard was quite clear why he prefers e_flags:
http://sources.redhat.com/ml/binutils/2003-06/msg00217.html

I askd Richard about the impact of e_flags change:

http://sources.redhat.com/ml/binutils/2003-06/msg00224.html

Neither Intel compiler group nor HP compiler group believe changing e_flags
is the right solution. A note section should be used in this case. Intel
made a proposal and can provide resources to work on this issue.

QUESTION FROM ISSUE TRACKER 22133 WHOSE ORIGINAL BUGZILLA (91140) WAS MARKED AS
A DUP OF THIS BUG.

Event posted 05-19-2003 10:45am by hongjiu.lu with duration of 0.00        
This bug has been there for a long time. It was discovered on
AS 2.1 last week and I don't think it it is changed in Red Hat
EL 3.0 Alpha 3.

-----------------
QUESTION ON THE TABLE IS WHETHER RH AGREES WITH INTEL/HP RECOMMENDATION THAT A
NOTE IS APPROPRIATE... per hjl's comment of 6/30/03. If not, then do we
plan to implement the recommended fix or propose an alternate action?

Intel is asking for a Red Hat position on this....
1) Note
2) Accept their patch
3) Propose alternative action (patch/doc/???)

FROM ISSUE TRACKER.........
Event posted 07-14-2003 03:30pm by hongjiu.lu with duration of 0.00
Intel has looked into the e_flags solution. We have several concerns:

1. How will gcc generate a .o file with the new e_flags?
2. Is a new assembler needed? Is a new assembler option needed?
3. What should the default e_flags for assembler and linker be?
4. What changes are required for glibc and kernel?
5. What changes are required for the third-party tools?

We were afraid the e_flags approach might be too intrusive. Also
the e_flags change is the ia64 psABI change, which requires
agreement from all tool vendors. Since it is a gcc specific bug,
it may not be easy to get OK from all other tool vendors. If we
do decide to go the e_flags route, we should be prepared to present
a strong case to the ia64 psABI committee as well as glibc and kernel
people if their changes are needed.

> 1. How will gcc generate a .o file with the new e_flags?
> 2. Is a new assembler needed? Is a new assembler option needed?

With an assembler directive, so yes, a new assembler would be needed.

> 3. What should the default e_flags for assembler and linker be?

Unset.

> 4. What changes are required for glibc and kernel?

None that I know of.

> 5. What changes are required for the third-party tools?

Depends on what they do with object files, or code generation.

> Since it is a gcc specific bug, it may not be easy to get OK from
> all other tool vendors.  If we do decide to go the e_flags route,
> we should be prepared to present a strong case to the ia64 psABI
> committee as well as glibc and kernel people if their changes are needed.

I understand this, but I still think that it's worth while.

In the short term I plan on changing gcc so that we do not generate
tail-calls.  I will not change gcc to take advantage of the knowledge
that local calls cannot modify the GP.  This means that gcc's output
will be compatible with both icc and older gcc output.  There will be
no flags or magic sections or anything associate with this change.

In the long term, I'd still like to see the psABI change to accomodate
languages that REQUIRE tail call optimizations, such as Scheme, ML,
Mercury, and other functional/logical languages.  Further, it is my
guess (unbacked by hard data) that tail call optimizations are more
useful to ia64 than avoiding gp reloads.

Patch applied for gcc 3.3.1; needs merging to appropriate RH branches.

FROM ISSUE TRACKER.....
Event posted 07-25-2003 11:13am by hongjiu.lu with duration of 0.00
Will beta2 have the new gcc? Another issue is unless all .a archives in beta2 are
recompiled by the new gcc, we still can't assume GP will be preserved in beta2.

ADDITIONAL COMMENTS FROM THE INTEL CALL TODAY...
Intel informs us that at least glibc will need to be recompiled when gcc is
updates. They recommend recompiling the entire platform to insure all components
pick up the gcc patch. Can we do this for Beta2?

Already Taroon beta1 has this gcc.
As for rebuilding everything, I'm afraid it is not going to happen.
Some libraries surely will (or already have been rebuilt), including glibc.