www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 884] New: Segfault in recursive template

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884

           Summary: Segfault in recursive template
           Product: D
           Version: 1.001
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: fvbommel wxs.nl


The following code segfaults DMD v1.001 (Linux, don't know about Windows)
-----
template Inner(Ts...) {

    const Inner = .Inner!((Ts));
}



auto x = Inner!();
-----

Just so you people don't think I'm crazy for trying to compile that ;), let me
just state for the record that above code is *way* cut down from much more
complicated code. I removed everything I could while retaining the segfault.

Above code is probably invalid. The original code may or may not have been
valid, I'm not sure.

The original code also segfaulted on v1.00, and perhaps earlier (not sure when
I started working on it).

Some notes I made while cutting it down:
* The Ts in the initializer was originally sliced with [1..$], with the same
result (if filled with some value parameters). Only in 'static if (Ts.length >
0)', of course.
* The initializer expression in general used to be a bit more complicated :p.
* Braces around Ts were initially added to avoid "tuple Ts is used as a type",
later avoided "tuple is not a valid template value argument" and currently need
to be retained to eliminate "circular reference to 'Inner'", which is pretty
obvious in the current code :). Since the code that produced those errors
didn't segfault DMD, they stayed in.
* The Inner member originally had type T[] (T being the template parameter of
an enclosing template), but the compiler segfaulted with void[] as well.


-- 
Jan 24 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884


thomas-dloop kuehne.cn changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Linux                       |All





Added to DStress as
http://dstress.kuehne.cn/nocompile/t/templatde_58_A.d
http://dstress.kuehne.cn/nocompile/t/templatde_58_B.d
http://dstress.kuehne.cn/nocompile/t/templatde_58_C.d
http://dstress.kuehne.cn/nocompile/t/templatde_58_D.d


-- 
Apr 05 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884


matti.niemenmaa+dbugzilla iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matti.niemenmaa+dbugzilla ik
                   |                            |i.fi
           Keywords|                            |ice-on-valid-code
           Platform|PC                          |All





-------
Another testcase, somewhat different (just ran into this in 1.034 on Windows):

template Ins() { const Ins = Ins!(Ins); }
alias Ins!() x;

This was reduced from the following, which should be valid but loops infinitely
(added ice-on-valid-code, since the code is valid, just divergent):

template Ins(alias x) { const Ins = Ins!(Ins); }
alias Ins!(Ins) x;

Doing the following instead makes DMD correctly report a circular reference
error:

template Ins() { const Ins = Ins!(); }
alias Ins!() x;


-- 
Aug 17 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884






The first of Matti's cases is OK on DMD2.027.
The second is segfaulting in optimize.c,
Expression *expandVar(int result, VarDeclaration *v),
in the line:

        Type *tb = v->type->toBasetype();

type may be null. This can trivially be changed into an ICE, rather than a
segfault, not that's much of an improvement.


-- 
Apr 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884






Seems like dmd uses too much field access for order-independent language.


-- 
Apr 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884






Created an attachment (id=336)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=336&action=view)
Patch against DMD2.029

This patch stops Matti's case from segfaulting, and gives an error message on
the offending line. The DStress cases are no longer segfaulting, they ICE
instead.


-- 
Apr 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch





Note that this patch doesn't close the original bug, it just fixes the
(different) bug from Matti. With this patch applied, the bug title can become
"ICE(template.c) in recursive template".


-- 
Apr 24 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=884


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |
             Status|NEW                         |RESOLVED
                 CC|                            |clugdbug yahoo.com.au
         Resolution|                            |FIXED
            Summary|Segfault in recursive       |ICE(template.c) in
                   |template                    |recursive template





All segfaults are fixed in D2.030 and 1.045. The original test case still ICEs,
though, but I'm moving that to issue 2884 (which seems to be the same bug).

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