Re: c/9475: Wrong ffs results

Re: c/9475: Wrong ffs results

[Falk Hueffner]

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

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: gcc-gnats@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: c/9475: Wrong ffs results
Date: 29 Jan 2003 01:01:54 +0100

 This was fixed yesterday, somebody please close it.
 
 -- 
 	Falk

Re: c/9475: Wrong ffs results

[bangerth]

Synopsis: Wrong ffs results

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Wed Jan 29 00:13:15 2003
State-Changed-Why:
    submitter sez was fixed yesterday

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9475

Re: c/9475: Wrong ffs results

[Falk Hueffner]

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

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c/9475: Wrong ffs results
Date: 28 Jan 2003 14:13:37 +0100

 Hi,
 
 gcc thinks ffs gets its parameters on the stack:
 
 int f(unsigned dummy, unsigned x) {
     return __builtin_ffs(x);
 }
 
 f:
         .frame $30,32,$26,0
         .mask 0x4000000,-16
         ldah $29,0($27)         !gpdisp!6
         lda $29,0($29)          !gpdisp!6
 $f..ng:
         lda $30,-32($30)
         ldq $27,ffs($29)                !literal!7
         stq $26,16($30)
         .prologue 1
 -->     stl $17,0($30)
         jsr $26,($27),ffs               !lituse_jsr!7
         ldah $29,0($26)         !gpdisp!8
         addl $31,$0,$0
         bis $31,$31,$31
         lda $29,0($29)          !gpdisp!8
         ldq $26,16($30)
         lda $30,32($30)
         ret $31,($26),1
 
 But ffs follows normal C calling conventions (first argument in $16).
 Any ideas which recent change might have caused this?
 
 -- 
 	Falk

c/9475: Wrong ffs results

[Falk Hueffner]

>Number:         9475
>Category:       c
>Synopsis:       Wrong ffs results
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 28 12:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Falk Hueffner
>Release:        3.4 20030128 (experimental)
>Organization:
>Environment:
System: Linux juist 2.5.59 #4 Sat Jan 18 12:46:41 CET 2003 alpha unknown unknown GNU/Linux
Architecture: alpha

	
host: alphaev68-unknown-linux-gnu
build: alphaev68-unknown-linux-gnu
target: alphaev68-unknown-linux-gnu
configured with: ../configure --enable-languages=c++ --disable-nls
>Description:
In certain contexts, the ffs builtin gives wrong results. It does not
happen when special purpose instructions are used instead of a libcall
(-mcpu=ev67). The problem is also not present in gcc 3.2, or in gcc
3.4 20030116 (so it looks like it has been introduced very recently).
>How-To-Repeat:
% cat ffs.c                                                
int printf(const char *format, ...);

int main(void) {
    int i;
    for (i = 0; i < 8; i++) {
        unsigned j = 1u << i;
        printf("%2d %10u %2d\n", i, j, __builtin_ffs(j));
    }
    return 0;
}
% gcc -O1 -W -Wall -mcpu=ev4 ffs.c  && ./a.out
 0          1  1
 1          2  0
 2          4  0
 3          8  0
 4         16  0
 5         32  0
 6         64  0
 7        128  0

The correct output would be:
 0          1  1
 1          2  2
 2          4  3
 3          8  4
 4         16  5
 5         32  6
 6         64  7
 7        128  8
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: