[Bug c/30936] New: const attribute in nanf prototype causes gcc not producing correct code.

[Bug c/30936] New: const attribute in nanf prototype causes gcc not producing correct code.

[filippo dot arcidiacono at gmail dot com]

Being nanf declared using const attribute, sh4-linux-gcc (4.1.1) doesn't
produce 
the code to call the nanf function.
Removing the 'const' attribute the generated code works fine.
Using gcc (3.4.3) Red Hat EL4 the test runs fine.


-- 
           Summary: const attribute in nanf prototype causes gcc not
                    producing correct code.
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: filippo dot arcidiacono at gmail dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.

[filippo dot arcidiacono at gmail dot com]

------- Comment #1 from filippo dot arcidiacono at gmail dot com  2007-02-23 15:43 -------
Created an attachment (id=13100)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13100&action=view)
simple test case exploiting gcc bug

compiled with the following command:
> sh4-linux-gcc nanf-test.c -D_GNU_SOURCE -o nanf-test -lm


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-02-23 17:39 -------
> Being nanf declared using const attribute

Can you attach the preprocessed source which you can get by adding -save-temps
to the command line?  The file will be called something.i.

Also can you compile with -W -Wall as I think really nanf is not being
prototyped which means this is not a GCC issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.

[filippo dot arcidiacono at gmail dot com]

------- Comment #3 from filippo dot arcidiacono at gmail dot com  2007-02-26 08:08 -------
Created an attachment (id=13111)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13111&action=view)
prerprocessed file of nanf-test.c

In  attach you can find the preprocessed file nanf-test.i of nanf-test.c.
It contains the nanf prototype, declared by bits/mathcalls.h included by math.h
header file.
Using -Wall option I doesn't obtain any warning.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug target/30936] const attribute in nanf prototype causes gcc not producing correct code.

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-02-26 08:21 -------
No, the const attribute does not cause to produce wrong code.
On powerpc-darwin with your testcase, I get:
        mflr r0
        lis r3,ha16(LC0)
        la r3,lo16(LC0)(r3)
        stw r0,8(r1)
        stwu r1,-64(r1)
        bl _nanf
        li r3,0
        fcmpu cr7,f1,f1
        bne- cr7,L5


You can see the floating point compare happens but only one call to nanf.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug target/30936] const attribute in nanf prototype causes gcc not producing correct code.

[filippo dot arcidiacono at gmail dot com]

------- Comment #5 from filippo dot arcidiacono at gmail dot com  2007-02-26 09:29 -------
Created an attachment (id=13112)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13112&action=view)
assembler code of nanf-test.c

Following a piece of the objdump of the nanf-test:
:
:
int
main (void)
{
   0:   e6 2f           mov.l   r14,@-r15
   2:   22 4f           sts.l   pr,@-r15
   4:   f8 7f           add     #-8,r15
   6:   f3 6e           mov     r15,r14
  int op;

  op = (nanf ("") != nanf ("") );
   8:   e3 62           mov     r14,r2
   a:   c8 72           add     #-56,r2
   c:   00 e1           mov     #0,r1
   e:   1f 12           mov.l   r1,@(60,r2)
  if (!op) {
  10:   e3 61           mov     r14,r1
  12:   c8 71           add     #-56,r1
  14:   1f 51           mov.l   @(60,r1),r1
  16:   18 21           tst     r1,r1
  18:   08 8b           bf      2c <main+0x2c>
    printf ("Test NAN Failed!\n");
  1a:   09 d1           mov.l   40 <main+0x40>,r1       ! 0x0 <main>
  1c:   13 64           mov     r1,r4
  1e:   09 d1           mov.l   44 <main+0x44>,r1       ! 0x0 <main>
  20:   0b 41           jsr     @r1
  22:   09 00           nop     
    return (1);
  24:   01 e1           mov     #1,r1
  26:   12 2e           mov.l   r1,@r14
  28:   02 a0           bra     30 <main+0x30>
  2a:   09 00           nop     
  }
:
:
Note that I using sh4 architecture.
In attach you can find the nanf-test.s that doesn't contains any reference 
to nanf symbol.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug target/30936] __builtin_nanf("") != __builtin_nanf("") is false for sh4-linux-gnu

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-02-26 09:52 -------
>In attach you can find the nanf-test.s that doesn't contains any reference 
> to nanf symbol.

That is ok, because nanf("") is foldded into a constant and the function is not
called.
I don't read sh asm that well but it looks like:
        mov     #0,r1

is wrong, it should be instead:
mov #1, r1


If I changed nanf(") to __builtin_nanf("") on powerpc-darwin, I get:
        li r0,1
        stw r0,56(r30)
        lwz r0,56(r30)
        cmpwi cr7,r0,0

So it is doing the correct thing there.

So this still has nothing to do with the nanf prototype really.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|const attribute in nanf     |__builtin_nanf("") !=
                   |prototype causes gcc not    |__builtin_nanf("") is false
                   |producing correct code.     |for sh4-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug target/30936] __builtin_nanf("") != __builtin_nanf("") is false for sh4-linux-gnu

[filippo dot arcidiacono at gmail dot com]

------- Comment #7 from filippo dot arcidiacono at gmail dot com  2007-02-26 13:01 -------
> is wrong, it should be instead:
> mov #1, r1

OK!
This is what I get if I use __builtin_nanf() instead of nanf.
But using nanf there isn't any undefined nanf symbol in the obiect
generated, as expected, as well as happens also with gcc (3.4.3).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936

[Bug target/30936] __builtin_nanf("") != __builtin_nanf("") is false for sh4-linux-gnu

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-02-26 18:02 -------
Actually it turns out this is not a bug but rather you did not read the full
documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/SH-Options.html

-mieee
Increase IEEE-compliance of floating-point code. At the moment, this is
equivalent to -fno-finite-math-only. When generating 16 bit SH opcodes, getting
IEEE-conforming results for comparisons of NANs / infinities incurs extra
overhead in every floating point comparison, therefore the default is set to
-ffinite-math-only. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936