http://d.puremagic.com/issues/show_bug.cgi?id=7932

           Summary: protected method
           Product: D
           Version: D1 & D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: leandro.lucarella@sociomantic.com


--- Comment #0 from Leandro Lucarella <leandro.lucarella@sociomantic.com> 2012-04-17 06:31:25 PDT ---
This is a weird one:

---
extern (C) int printf(char* fmt, ...);

size_t N;

class C
{
    protected void f(size_t n)
    out
    {
        printf("out: this=%p &n=%p n=%zu\n",
                cast(void*) this, &n, n);
        assert (N == n);
    }
    body
    {
        int dummy;
        //printf("\n");
        N = n;
        printf("body: this=%p &dummy=%p &N=%p N=%zu\n",
                cast(void*) this, &dummy, &N, N);
    }
}

void main()
{
    auto x = new C;
    x.f(1);
}
---

Compiling with dmd -m64 -O, the assertion fails, and the output is: body: this=0x7f457090dcf0 &dummy=0x7fffc16ece98 &N=0x6fe2d0 N=1 out: this=0x7f457090dcf0 &n=0x7fffc16ecea8 n=4401614

All other flags seems to be irrelevant except for -release, of course, as the out contract is not generated.

Uncommenting the commented out printf() fixes the problem. Removing the protected attribute, or changing it to either public, private or package fixes the problem too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2012-04-17 22:37:23 PDT ---
Adding assert(this); at the start of the body of f() makes the bug disappear.
I think this is why 'protected' is required; if it is public, the assert(this)
is automatically added.

Comparing the generated code for the three cases
(a) -O, fails
(b)  without -O, passes
(c)  -O + assert(this), passes
I can't see any obvious explanation. case (a) has the f() body of case (b), and
the main() body of case (c).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1                          |D1 & D2
            Summary|Corrupted argument inside   |Corrupted argument inside
                   |out contract for protected  |out contract in x86_64
                   |methods when compiling with |
                   |-O in x86_64                |


--- Comment #2 from Don <clugdbug@yahoo.com.au> 2012-04-18 01:44:46 PDT ---
Also applies to D2, and does not require -O. Interestingly on D2, adding 'assert(this)' or making it public does not make the bug go away.

This test case applies to D1 if you remove __gshared and add 'protected'.

__gshared size_t second;
class C
{
    /*protected*/ void f(size_t n)
    out
    {
        second = n;
    }
    body
    {
    }
}

void main()
{
    C x = new C;
    x.f(6);
    assert(second == 6);
}
---------------------------
This is a parameter passing bug. The code generated for the 'out' contract
assumes that the register parameters were spilled to the stack, but that isn't
necessarily true. Space is allocated on the stack for them, but they aren't
necessarily copied there. On D1, calling the class invariant causes the
parameter (in this case RSI) to be copied to the stack.
Otherwise, 'n' is uninitialized garbage while in the out contract.
The solution is to force all parameters to be copied to the stack when an out
contract is present.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932



--- Comment #3 from github-bugzilla@puremagic.com 2012-04-28 16:14:22 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/b538ba7b10e4af45f5b3f160b475ebeea03e0c1d fix Issue 7932 - Corrupted argument inside out contract in x86_64

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932



--- Comment #4 from github-bugzilla@puremagic.com 2012-04-28 16:14:44 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/e3a8e6449e8c210524e32520237fcb6ea1191a10 fix Issue 7932 - Corrupted argument inside out contract in x86_64

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7932


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------