First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 16314
Product:  
Component:  
Status: NEW
Resolution:
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Wouter van Heyst <wouter@vidicode.org>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 16314 depends on: Show dependency tree
Show dependency graph
Bug 16314 blocks:

Additional Comments:





Mark bug as waiting for feedback
Mark bug as suspended




View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: 2004-07-01 13:57 Opened: 2004-07-01 13:19
Trying to compile some simple floating point math using the Maverick Crunch
coprocessor on the EP9312 breaks because the divide functions end up in the
assemby but aren't in libcc. As far as I understand it, the problem stems from
the Crunch core not supporting floating point divide, and then we get into ABI
differences (returning values in integer/float point registers). More (accurate)
information can be found in the thread on the gcc ml:

thread start: http://gcc.gnu.org/ml/gcc/2004-06/msg01867.html
continued into the next month: http://gcc.gnu.org/ml/gcc/2004-07/msg00028.html


simple test case to reproduce the problem:

double x, y;  float a, b;
int main () { a = a/b; x = x /y; return 0; }

compiler commandline and output:

# arm-ep93xx-linux-gnu-gcc bug.c -Wall -nostdlib                               
                                                                                   
/home/larstiq/crosstool/arm-ep93xx-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/../lib/gcc/arm-ep93xx-linux-gnu/3.4.0/../../../../arm-ep93xx-linux-gnu/bin/ld:
warning: cannot find entry symbol _start; defaulting to 0000807
/tmp/cc8FEzYi.o(.text+0x20): In function `main':                               
                                                                               
                                                     
: undefined reference to `__divsf3'                                            
                                                                               
                                                     
/tmp/cc8FEzYi.o(.text+0x40): In function `main':
: undefined reference to `__divdf3'                                            
                                                                               
        
collect2: ld returned 1 exit status

# arm-ep93xx-linux-gnu-gcc -v                                                  
                                                                                
Reading specs from
/home/larstiq/crosstool/arm-ep93xx-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/../lib/gcc/arm-ep93xx-linux-gnu/3.4.0/specs
                                                                               
Configured with: ../gcc-3.4.0/configure --target=arm-ep93xx-linux-gnu
--host=powerpc-linux
--prefix=/opt/crosstool/arm-ep93xx-linux-gnu/gcc-3.4.0-glibc-2.3.2
--with-local-prefix=/opt/crosstool/arm-ep93xx-linux-gnu
Thread model: single                                                           
                                                                               
                                                     
gcc version 3.4.0

------- Comment #1 From dank@kegel.com 2004-08-30 14:12 -------
This happens for me when building any arm toolchain with softfloat with
gcc-3.4.x.
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02436.html
seems to fix it for me.  
Note: the target tuple in this bug report was arm-elf, which is incorrect; 
it should be changed to arm-softfloat-linux-gnu or something like that.

------- Comment #2 From dank@kegel.com 2004-08-30 14:17 -------
This is kind of a fit-and-finish problem with gcc-3.4.2-pre.
Any chance the fix could be applied before release?

------- Comment #3 From Mark Mitchell 2004-08-30 14:46 -------
If Richard Earnshaw approves this patch, we can put it in for GCC 3.4.2.

------- Comment #4 From Richard Earnshaw 2004-08-31 09:14 -------
No, it won't work.  As things stand the ep9312 abi for linux expects the result
of the division to be returned in a Maverick register.  The soft-float routines
return a value in r0 or r0/r1.  So all it would do is punt the problem into a
hard-to-locate run-time one.

------- Comment #5 From dank@kegel.com 2004-08-31 13:14 -------
Then perhaps I should open a separate PR for the 
generic soft-float case...

------- Comment #6 From Richard Earnshaw 2004-08-31 13:16 -------
Subject: Re:  EP9312 gcc: undefined reference to __divdf3

On Tue, 2004-08-31 at 14:14, dank at kegel dot com wrote:
> ------- Additional Comments From dank at kegel dot com  2004-08-31 13:14 -------
> Then perhaps I should open a separate PR for the 
> generic soft-float case...

I think there already is one.  Daniel filed it.


------- Comment #7 From dank@kegel.com 2004-08-31 15:17 -------
I can't find it.  If you run into it, can you paste in the PR number?
Otherwise I'll add a new one in a few days, and we can mark it dup later.

------- Comment #8 From Richard Earnshaw 2004-09-01 10:44 -------
Subject: Re:  EP9312 gcc: undefined reference to __divdf3

On Tue, 2004-08-31 at 16:17, dank at kegel dot com wrote:
> ------- Additional Comments From dank at kegel dot com  2004-08-31 15:17 -------
> I can't find it.  If you run into it, can you paste in the PR number?

PR 14352.

R.

------- Comment #9 From zhangyijin 2004-11-23 06:04 -------
(In reply to comment #8)
> Subject: Re:  EP9312 gcc: undefined reference to __divdf3
> On Tue, 2004-08-31 at 16:17, dank at kegel dot com wrote:
> > ------- Additional Comments From dank at kegel dot com  2004-08-31 15:17 ---
----
> > I can't find it.  If you run into it, can you paste in the PR number?
> PR 14352.
> R.

I use this function and I test it can run ok. But I don`t know can it run ok 
always?
//double __divdf3(double a,double b ){ return a/b; }
	.file	"__divdf3.s"
	.global	__divdf3
	.text
	.align	2
	.global	__divdf3
	.type	__divdf3, %function
__divdf3:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	mov	ip, sp
	stmfd	sp!, {r4, fp, ip, lr, pc}
	sub	fp, ip, #4
	sub	sp, sp, #16
	str	r0, [fp, #-24]
	str	r1, [fp, #-20]
	str	r2, [fp, #-32]
	str	r3, [fp, #-28]
	ldfd	f1, [fp, #-24]
	ldfd	f0, [fp, #-32]
	dvfd	f0, f1, f0
	ldmfd	sp!, {r3, r4}
         cfmvdlr	mvd0, r3
	cfmvdhr	mvd0, r4
	sub	sp, fp, #16
	ldmfd	sp, {r4, fp, sp, pc}
        .end



------- Comment #10 From zhangyijin 2004-11-23 06:06 -------
(In reply to comment #8)
> Subject: Re:  EP9312 gcc: undefined reference to __divdf3
> On Tue, 2004-08-31 at 16:17, dank at kegel dot com wrote:
> > ------- Additional Comments From dank at kegel dot com  2004-08-31 15:17 ---
----
> > I can't find it.  If you run into it, can you paste in the PR number?
> PR 14352.
> R.

I use this function and I test it can run ok. But I don`t know can it run ok 
always?
//double __divdf3(double a,double b ){ return a/b; }
	.file	"__divdf3.s"
	.global	__divdf3
	.text
	.align	2
	.global	__divdf3
	.type	__divdf3, %function
__divdf3:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	mov	ip, sp
	stmfd	sp!, {r4, fp, ip, lr, pc}
	sub	fp, ip, #4
	sub	sp, sp, #16
	str	r0, [fp, #-24]
	str	r1, [fp, #-20]
	str	r2, [fp, #-32]
	str	r3, [fp, #-28]
	ldfd	f1, [fp, #-24]
	ldfd	f0, [fp, #-32]
	dvfd	f0, f1, f0
	ldmfd	sp!, {r3, r4}
         cfmvdlr	mvd0, r3
	cfmvdhr	mvd0, r4
	sub	sp, fp, #16
	ldmfd	sp, {r4, fp, sp, pc}
        .end



------- Comment #11 From Richard Earnshaw 2004-11-23 11:03 -------
Subject: Re:  EP9312 gcc: undefined reference to __divdf3

On Tue, 2004-11-23 at 06:04, zhangyijin_2008 at 163 dot com wrote:
> I use this function and I test it can run ok. But I don`t know can it run ok 
> always?
> 	ldfd	f1, [fp, #-24]
> 	ldfd	f0, [fp, #-32]
> 	dvfd	f0, f1, f0

These are FPA instructions, the ep9312 does not have an FPA co-processor
and your linux kernel is emulating their behaviour in software.  That
won't work on an embedded system.

R.


------- Comment #12 From Richard Earnshaw 2005-11-26 22:44 -------
*** Bug 25044 has been marked as a duplicate of this bug. ***

------- Comment #13 From Dario Massarin 2005-11-28 18:14 -------
Hi Richard

Could you explain us in details what would be in your opinion the best solution
to this problem?

Should we create a new maverick crunch target with specific division code or
what else?

First Last Prev Next    No search results available      Search page      Enter new bug