Bug 12769 - -mlongcall doesn't convert all calls to long calls for builtin functions
Summary: -mlongcall doesn't convert all calls to long calls for builtin functions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: 3.4.4
Assignee: Alan Modra
URL:
Keywords: patch, wrong-code
Depends on:
Blocks:
 
Reported: 2003-10-24 21:40 UTC by John Fardo
Modified: 2004-11-27 01:53 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: powerpc-unknown-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 3.3.6 3.4.4 4.0.0
Known to fail: 3.4.3
Last reconfirmed: 2003-11-23 07:14:14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Fardo 2003-10-24 21:40:52 UTC
If you compile and link an extremely large c++ powerpc application 
with -mlongcall, the program will fail to link with errors such as:

"relocation truncated to fit: R_PPC_REL24 _Unwind_Resume"

The -mlongcall flag seems to do the right thing with regard
to functions explicitly called in our application. However,
function calls that are generated by the compiler (such as
the call to _Unwind_Resume() to handle exception unwinding)
do not become long calls.

If you compile the example program below and run 'objdump -r'
you will see that the compiler only generates a R_PPC_REL24
relocation record for _Unwind_Resume. All other function calls
have 2 relocation records R_PPC_ADDR16_LO and R_PPC_ADDR16_HA.

// 
// powerpc-unknown-linux-gnu-c++ -mlongcall -c test.c++
//
class Foo
{
  public:
    Foo() {};
    ~Foo() {};
};

int main()
{
    Foo bar1;
    try {
        Foo bar2;
        throw 2;
    } catch (...) {
        throw;
    }

    return 0;
}

> powerpc-unknown-linux-gnu-objdump -r test.o

test.o:     file format elf32-powerpc

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
0000001e R_PPC_ADDR16_HA   _ZN3FooC1Ev
00000022 R_PPC_ADDR16_LO   _ZN3FooC1Ev
00000036 R_PPC_ADDR16_HA   _ZN3FooC1Ev
0000003a R_PPC_ADDR16_LO   _ZN3FooC1Ev
0000004a R_PPC_ADDR16_HA   __cxa_allocate_exception
0000004e R_PPC_ADDR16_LO   __cxa_allocate_exception
0000006a R_PPC_ADDR16_HA   _ZTIi
0000006e R_PPC_ADDR16_LO   _ZTIi
00000076 R_PPC_ADDR16_HA   __cxa_throw
0000007a R_PPC_ADDR16_LO   __cxa_throw
00000096 R_PPC_ADDR16_HA   _ZN3FooD1Ev
0000009a R_PPC_ADDR16_LO   _ZN3FooD1Ev
000000ae R_PPC_ADDR16_HA   __cxa_begin_catch
000000b2 R_PPC_ADDR16_LO   __cxa_begin_catch
000000be R_PPC_ADDR16_HA   __cxa_rethrow
000000c2 R_PPC_ADDR16_LO   __cxa_rethrow
000000d6 R_PPC_ADDR16_HA   __cxa_end_catch
000000da R_PPC_ADDR16_LO   __cxa_end_catch
000000f2 R_PPC_ADDR16_HA   _ZN3FooD1Ev
000000f6 R_PPC_ADDR16_LO   _ZN3FooD1Ev
00000108 R_PPC_REL24       _Unwind_Resume   
	 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the source of the problem.


RELOCATION RECORDS FOR [.eh_frame]:
OFFSET   TYPE              VALUE 
00000012 R_PPC_ADDR32      __gxx_personality_v0
00000024 R_PPC_ADDR32      .text
0000002d R_PPC_ADDR32      .rodata
Comment 1 Andrew Pinski 2003-10-24 21:47:26 UTC
I want to say that rs6000_set_default_type_attributes (aka 
TARGET_SET_DEFAULT_TYPE_ATTRIBUTES) is not being called for _Unwind_Resume.
Comment 2 John Fardo 2003-10-24 21:54:34 UTC
Subject: RE:  -mlongcall doesn't convert all calls to long calls in c++ programs

I should probably add, that I've seen this happen to other
library functions also:

Here's a couple more:

 relocation truncated to fit: R_PPC_REL24 __cmpdi2
 relocation truncated to fit: R_PPC_REL24 __fixunsdfdi
 relocation truncated to fit: R_PPC_REL24 __floatdidf
 relocation truncated to fit: R_PPC_REL24 __floatdisf
 relocation truncated to fit: R_PPC_REL24 __udivdi3

- John

> -----Original Message-----
> From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org]
> Sent: Friday, October 24, 2003 5:47 PM
> To: John Fardo
> Subject: [Bug target/12769] -mlongcall doesn't convert all 
> calls to long
> calls in c++ programs
> 
> 
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* 
> gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769
> 
> 
> 
> ------- Additional Comments From pinskia at gcc dot gnu dot 
> org  2003-10-24 21:47 -------
> I want to say that rs6000_set_default_type_attributes (aka 
> TARGET_SET_DEFAULT_TYPE_ATTRIBUTES) is not being called for 
> _Unwind_Resume.
> 
> 
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> 
Comment 3 Andrew Pinski 2003-10-24 21:58:43 UTC
Looks like all builtin functions do get inited with a call to TARGET_SET_DEFAULT_TYPE_ATTRIBUTES.
Comment 4 Andrew Pinski 2003-11-23 07:14:14 UTC
Confirmed.
Comment 5 Peter Grehan 2004-08-12 05:19:49 UTC
I've run across this bug when doing loadable module support for FreeBSD/PPC.
Loadable modules run above 3Gb but have to call back to the kernel which is
loaded at 0.
Using GNU C version 3.4.2 [FreeBSD] 20040728 (powerpc-undermydesk-freebsd)
and compiling the program with "cc -c -v -S -mlongcall test.c"

extern int extfunc(void);

long long
testfunc(long long a, long long b)
{
  extfunc();

  return (a / b);
}

 The assembler output shows that the extfunc() call uses the correct longcall
sequence, but the builtin __divdi3 for the 64-bit division still uses the
"bl" shortcall sequence.

 The bug appears to be in rs6000.c:init_cumulative_args(). A libcall routine
has a NULL fntype parameter, so the test for the longcall/shortcall attribute
fails. The fix I'm using is:

--- rs6000.c    Wed Aug 11 22:20:04 2004
+++ rs6000.c.longcall   Thu Jul 29 19:18:38 2004
@@ -3946,6 +3946,9 @@
       && lookup_attribute ("longcall", TYPE_ATTRIBUTES (fntype))
       && !lookup_attribute ("shortcall", TYPE_ATTRIBUTES (fntype)))
     cum->call_cookie = CALL_LONG;
+  else if (!fntype)
+    if (rs6000_default_long_calls)
+      cum->call_cookie = CALL_LONG;
 
 ... which should certainly be done in a cleaner fashion.

later,

Peter.
Comment 7 GCC Commits 2004-11-27 01:07:15 UTC
Subject: Bug 12769

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	amodra@gcc.gnu.org	2004-11-27 01:06:59

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: rs6000.c 

Log message:
	PR target/12769
	* config/rs6000/rs6000.c (init_cumulative_args): Set call_cookie
	from rs6000_default_long_calls for libcalls.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6579&r2=2.6580
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.753&r2=1.754

Comment 8 GCC Commits 2004-11-27 01:08:16 UTC
Subject: Bug 12769

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	amodra@gcc.gnu.org	2004-11-27 01:08:03

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: rs6000.c 

Log message:
	PR target/12769
	* config/rs6000/rs6000.c (init_cumulative_args): Set call_cookie
	from rs6000_default_long_calls for libcalls.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.706&r2=2.2326.2.707
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.576.2.34&r2=1.576.2.35

Comment 9 GCC Commits 2004-11-27 01:18:38 UTC
Subject: Bug 12769

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	amodra@gcc.gnu.org	2004-11-27 01:18:31

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: rs6000.c 

Log message:
	PR target/12769
	* config/rs6000/rs6000.c (init_cumulative_args): Set call_cookie
	from rs6000_default_long_calls for libcalls.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1026&r2=1.16114.2.1027
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.403.2.14&r2=1.403.2.15

Comment 10 Alan Modra 2004-11-27 01:19:34 UTC
Fixed.