Bug 33661 - template methods forget explicit local register asm vars
Summary: template methods forget explicit local register asm vars
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 36080 64951 66393 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-10-04 19:33 UTC by Vincent Riviere
Modified: 2019-05-18 22:28 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 3.3.3, 4.1.0, 4.2.3, 4.3.0
Last reconfirmed: 2007-12-10 01:55:24


Attachments
Experimental fix (1.16 KB, patch)
2015-06-09 09:06 UTC, Andreas Krebbel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Riviere 2007-10-04 19:33:19 UTC
Hello.

http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Local-Reg-Vars.html#Local-Reg-Vars
"However, using the variable as an asm operand guarantees that the specified register is used for the operand."

This does not always work if the code is inside a template method which gets inlined.

For this testcase, imagine a system call invoked by trap #0. It returns a pointer into d0, and clobbers d1/a0/a1.

$ cat a.cpp
template<class T>
class Tpl
{
public:
        static long* MySysCall()
        {
                register long retval __asm__("d0");

                asm
                (
                        "trap   #0\n\t"
                        "move.l %0,%0\n\t"
                : "=r"(retval)
                :
                : "d1", "a0", "a1"
                );

                return (long*)retval;
        }
};

void f()
{
        long* p = Tpl<char>::MySysCall();
        *p = 1;
}

Note that I added an extra "move.l %0,%0" to see which register is affected to %0.

$ g++ -S a.cpp -O1 -o -
#NO_APP
        .file   "a.cpp"
        .text
        .align  2
        .globl  _Z1fv
        .type   _Z1fv, @function
_Z1fv:
.LFB3:
        link.w %fp,#0
.LCFI0:
        move.l %a2,-(%sp)
.LCFI1:
#APP
        trap    #0
        move.l  %a2,%a2

#NO_APP
        moveq #1,%d0
        move.l %d0,(%a2)
        move.l (%sp)+,%a2
        unlk %fp
        rts
.LFE3:
        .size   _Z1fv, .-_Z1fv
        .globl  __gxx_personality_v0
        .ident  "GCC: (GNU) 4.2.1"
        .section        .note.GNU-stack,"",@progbits

We can see that even though we requested "retval" to be mapped to d0, it has been mapped to a2.

The problem does not appear if the code is in a method of a standard class (not a method of a template).
Another way to get it work is to add "volatile" to the register variable declaration.
Comment 1 Andrew Pinski 2007-12-10 01:55:22 UTC
Confirmed,
It also fails with 3.3 so this is not a regression.
A testcase for PPC:
template<class T>
class Tpl
{
public:
        static long* MySysCall()
        {
                register long retval __asm__("r3");

                asm
                (
                        "trap   #0\n\t"
                        "move.l %0,%0\n\t"
                : "=r"(retval)
                :
                : "r4"
                );

                return (long*)retval;
        }
};

void f()
{
        long* p = Tpl<char>::MySysCall();
        *p = 1;
}

Note I did not change the inline-asm's string though so it will not assemble.

 
Comment 2 Vincent Riviere 2008-02-02 20:48:22 UTC
Still fails in GCC release 4.2.3
Comment 3 Richard Biener 2008-02-05 10:28:20 UTC
This works for me on x86_64 with 4.3.0.
Comment 4 Vincent Riviere 2008-02-05 19:56:37 UTC
Same problem with GCC 4.3-20080201 on target i686-pc-linux-gnu
Comment 5 Andrew Pinski 2008-04-29 17:09:17 UTC
*** Bug 36080 has been marked as a duplicate of this bug. ***
Comment 6 Adam Lackorzynski 2008-04-30 13:34:46 UTC
Even if this is not a regression it would be very helpful if g++ would emit a warning that the register allocation will be ignored. Those bugs are subtle.
Comment 7 Vincent Riviere 2008-04-30 15:32:52 UTC
This is not a regression, however it is a bug, it has to be fixed. Inline assembly coupled with templates is very powerful, however because of this bug it is unusable :-(
If I remember well, a workaround is to put the assembly in an inline global function, then call it from the template method.
Comment 8 Adam Lackorzynski 2008-04-30 20:22:11 UTC
(In reply to comment #7)
> This is not a regression, however it is a bug, it has to be fixed. Inline
> assembly coupled with templates is very powerful, however because of this bug
> it is unusable :-(

I fully agree. I don't know how hard this one is to fix so at least a warning/error would be good to have. Silently ignoring the allocation just causes bugs nobody wants to have.

Comment 9 Stefan Schuh 2011-08-24 10:00:48 UTC
I can confirm this bug in gcc version 4.5.2 on i686-linux-gnu 
and in gcc version 4.6.0 on s390x-ibm-linux-gnu
Comment 10 Aleksandrs Saveljevs 2012-05-31 08:16:41 UTC
Confirming that the bug still exists on ARM, x86 and x86_64 as of GCC 4.6.3.
Comment 11 Adam Lackorzynski 2014-10-26 13:37:27 UTC
Confirming issue still exists for 4.7.4, 4.8.4, 4.9.2 and 5.0 (tested on x86_64).
Comment 12 Andrew Pinski 2015-06-03 10:05:33 UTC
*** Bug 66393 has been marked as a duplicate of this bug. ***
Comment 13 Andreas Krebbel 2015-06-09 09:06:05 UTC
Created attachment 35723 [details]
Experimental fix

The attached patch fixes the problem for me.

There appear to be two problems:

1. When parsing a template function cp_finish_decl returns before the asmspec is set in a var decl.
2. When expanding the template function the assembler_name is zeroed out.
Comment 14 Andrew Pinski 2017-03-30 14:47:27 UTC
*** Bug 64951 has been marked as a duplicate of this bug. ***
Comment 15 Alexey Dobriyan 2019-04-14 11:45:32 UTC
I can only reconfirm this bug still exists with 8.2.0 after rediscovering it independently.

Linux system calls taking 4+ arguments can't be templatized as they require

    register T3 _a3 asm("r10") = a3;


But using

    "r10" (a3)

in assembly input constraints doesn't work either.
Comment 16 Guillaume Delugré 2019-05-18 22:28:34 UTC
Tested on g++ 9.1.0, the bug is still present. Is there any chance of having the Andreas' fix pushed upstream?