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

           Summary: Segmentation fault in main()
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: tbanelwebmin@free.fr


--- Comment #0 from tbanelwebmin@free.fr 2013-02-04 03:51:35 PST ---
This small code crashs.

----------------------------------
import core.simd;

void main()
{
  ubyte16 table[1];
}
----------------------------------

It crashes in:
void[] *_memset128ii(void[] *p, void[] value, size_t count);

It seems that a wrong "count" is passed in by the _Dmain() function.

Details:
  DMD64 D Compiler v2.061
  Linux Ubuntu
  x86_64
  AMD Phenom II

-- 
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=9449


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx


--- Comment #1 from hsteoh@quickfur.ath.cx 2013-02-08 20:36:49 PST ---
Something is very screwy with the executable that DMD produces for this code. For example:

$ cat test.d
import core.simd;

void main() {
    ubyte16 table[1];
}
$ dmd -L--export-dynamic -g -m64 test.d
$ gdb test
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test...done.
(gdb) break Dmain
Segmentation fault
$


Commenting out the ubyte16 line makes the problem go away (it will correctly set the breakpoint). Looks like the codegen is screwed up somewhere?

-- 
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=9449


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|druntime                    |DMD


--- Comment #2 from hsteoh@quickfur.ath.cx 2013-02-08 21:39:27 PST ---
Actually, this looks like a compiler bug. The ubyte16 alias translates to __vector(ubyte[16]), which is a compiler built-in magic type.

Here's the disassembly of Dmain:

0000000000418620 <_Dmain>:
  418620:       55                      push   %rbp
  418621:       48 8b ec                mov    %rsp,%rbp
  418624:       48 83 ec 10             sub    $0x10,%rsp
  418628:       48 be 01 00 00 00 00    movabs $0x1,%rsi
  41862f:       00 00 00
  418632:       66 0f 6f 05 e6 77 01    movdqa 0x177e6(%rip),%xmm0        #
42fe20 <_IO_stdin_used+0x10>
  418639:       00
  41863a:       48 8d 7d f0             lea    -0x10(%rbp),%rdi
  41863e:       e8 a9 07 00 00          callq  418dec <_memset128ii>
  418643:       31 c0                   xor    %eax,%eax
  418645:       c9                      leaveq
  418646:       c3                      retq

Here's the disassembly of _memset128ii:

0000000000418dec <_memset128ii>:
  418dec:       55                      push   %rbp
  418ded:       48 8b ec                mov    %rsp,%rbp
  418df0:       48 83 ec 20             sub    $0x20,%rsp
  418df4:       48 89 75 e8             mov    %rsi,-0x18(%rbp)
  418df8:       48 89 55 f0             mov    %rdx,-0x10(%rbp)
  418dfc:       49 89 f8                mov    %rdi,%r8
  418dff:       49 89 fb                mov    %rdi,%r11
  418e02:       49 89 c9                mov    %rcx,%r9
  418e05:       49 c1 e1 04             shl    $0x4,%r9
  418e09:       4c 03 cf                add    %rdi,%r9
  418e0c:       4d 3b c1                cmp    %r9,%r8
  418e0f:       73 18                   jae    418e29 <_memset128ii+0x3d>
  418e11:       48 8b 55 f0             mov    -0x10(%rbp),%rdx
  418e15:       48 8b 45 e8             mov    -0x18(%rbp),%rax
  418e19:       49 89 00                mov    %rax,(%r8)
  418e1c:       49 89 50 08             mov    %rdx,0x8(%r8)
  418e20:       49 83 c0 10             add    $0x10,%r8
  418e24:       4d 39 c8                cmp    %r9,%r8
  418e27:       72 e8                   jb     418e11 <_memset128ii+0x25>
  418e29:       49 8b c3                mov    %r11,%rax
  418e2c:       48 8b e5                mov    %rbp,%rsp
  418e2f:       5d                      pop    %rbp
  418e30:       c3                      retq

Note that the expected parameters to memset128ii appear to not be passed by Dmain; I traced the execution into memset128ii and found that it was trying to memset an unreasonably large range of memory (2e+15 bytes), probably because the wrong arguments were passed to it.

Since the only druntime code involved is template wrapper around the compiler magic type __vector, the fault must lie with the compiler SIMD intrinsics.

-- 
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=9449


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #3 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-09 02:48:23 PST ---
_memset128ii expects:

%rcx => size_t count
%rdx => .ptr of value array
$rsi => .length of value array
%rdi => pointer to first argument array

what _Dmain passes:

%rcx => nothing (garbage)
%rdx => nothing (garbage)
%rsi => size_t count
%rdi => pointer to 16 byte object
%xmm0 => ubyte16[1] array

-- 
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=9449



--- Comment #4 from hsteoh@quickfur.ath.cx 2013-02-09 22:26:56 PST ---
Seems to be related to bug 8518.

-- 
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=9449



--- Comment #5 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-09 22:40:37 PST ---
(In reply to comment #4)
> Seems to be related to bug 8518.

Thanks for founding. The root of the problem (at least this one) is when dmd frontend parses and generates list of expressions, it does not create "hidden" expression which calls _memset128ii. Instead it does this when it executes AssignExpression::toElem() and later calls setArray() which issues call to _memset128ii. However it does not convert ubyte16[1] from static array to dynamic array and passes it as a static array. Since _memset128ii expects dynamic array, the program goes off the rails.

-- 
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=9449



--- Comment #6 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-15 23:41:19 PST ---
It may be a regression. 8 month ago Walter introduced two commits to e2ir.c
(https://github.com/D-Programming-Language/dmd/commit/6c2a2878200e0df1c73db976a747abf61b6a5e1a)
and src/memset.d
(https://github.com/D-Programming-Language/druntime/commit/a405a02394e2c26c6a66c3fc5ef3777bb86cd973)
to fix reg pair. However there is no crosstalk between how e2ir.c pass
arguments and how _memset128ii takes it. I do not know whether original code
was supported before these changes, but if it was, this is a regression.

-- 
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=9449


John Colvin <john.loughran.colvin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.loughran.colvin@gmail.
                   |                            |com


--- Comment #7 from John Colvin <john.loughran.colvin@gmail.com> 2013-04-21 17:25:52 BST ---
(In reply to comment #5)
> (In reply to comment #4)
> > Seems to be related to bug 8518.
> 
> Thanks for founding. The root of the problem (at least this one) is when dmd frontend parses and generates list of expressions, it does not create "hidden" expression which calls _memset128ii. Instead it does this when it executes AssignExpression::toElem() and later calls setArray() which issues call to _memset128ii. However it does not convert ubyte16[1] from static array to dynamic array and passes it as a static array. Since _memset128ii expects dynamic array, the program goes off the rails.

I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array.

_memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.

(In reply to comment #3)
> _memset128ii expects:
> 
> %rcx => size_t count
> %rdx => .ptr of value array
> $rsi => .length of value array
> %rdi => pointer to first argument array

This is incorrect. _memset128 expects:

RCX: size_t count
RDX: higher 64 bits of value
RSI: lower 64 bits of value
RDI: pointer to the 1st element of the destination array.

-- 
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=9449



--- Comment #8 from John Colvin <john.loughran.colvin@gmail.com> 2013-04-21 17:27:06 BST ---
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Seems to be related to bug 8518.
> > 
> > Thanks for founding. The root of the problem (at least this one) is when dmd frontend parses and generates list of expressions, it does not create "hidden" expression which calls _memset128ii. Instead it does this when it executes AssignExpression::toElem() and later calls setArray() which issues call to _memset128ii. However it does not convert ubyte16[1] from static array to dynamic array and passes it as a static array. Since _memset128ii expects dynamic array, the program goes off the rails.
> 
> I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array.
> 
> _memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.
> 
> (In reply to comment #3)
> > _memset128ii expects:
> > 
> > %rcx => size_t count
> > %rdx => .ptr of value array
> > $rsi => .length of value array
> > %rdi => pointer to first argument array
> 
> This is incorrect. _memset128 expects:
> 
> RCX: size_t count
> RDX: higher 64 bits of value
> RSI: lower 64 bits of value
> RDI: pointer to the 1st element of the destination array.

/s/_memset128/_memset128ii

-- 
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=9449


Maxim Fomin <maxim@maxim-fomin.ru> changed:

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


--- Comment #9 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-04-21 10:52:44 PDT ---
(In reply to comment #7)
> I'm pretty sure the use of void[] in _memset128ii is simply so as to have a 128bit data type. It's never used as, or expected to be, an array.
> 
> _memset128ii doesn't care whether it's being passed a static or dynamic array, it just blindly increments a pointer and writes to it "count" times.

I think it does matter whether dynamic array was passed or a static one due to how arguments are passed.

> (In reply to comment #3)
> > _memset128ii expects:
> > 
> > %rcx => size_t count
> > %rdx => .ptr of value array
> > $rsi => .length of value array
> > %rdi => pointer to first argument array
> 
> This is incorrect. _memset128 expects:
> 
> RCX: size_t count
> RDX: higher 64 bits of value
> RSI: lower 64 bits of value
> RDI: pointer to the 1st element of the destination array.

I see no difference between length dynamic array property and your "lower 64 bits of value" (also between ptr and "higher 64 bits of value"). And passing a pointer to dynamic array is not the same thing as passing pointer to the first element: http://dpaste.dzfl.pl/8f91aed8

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