www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10995] New: [REG]CTFE failures for structs with void initialized members

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

           Summary: [REG]CTFE failures for structs with void initialized
                    members
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: monarchdodra gmail.com


--- Comment #0 from monarchdodra gmail.com 2013-09-08 02:56:35 PDT ---
Regression 2.063.2 => 2.064-devel

Possibly related (or even the root cause) of 10994:
http://d.puremagic.com/issues/show_bug.cgi?id=10994

Let T be a struct with a void initialized member:

REG 1:
//----
struct T
{
    short a = void;
}
enum i = T.init.a;
//----
main.d(5): Error: cannot read uninitialized variable T().a in ctfe
main.d(3): Error: variable main.T.a was uninitialized and used before set

REG2:
This one is more problematic, as there would seem to be some type system
corruption:

//----
struct T
{
    short a = void;
}

T foo()
{
    auto t = T.init;
    return t;
}

enum i = foo().a;
//----
main.d(12): Error: couldn't find field a in short
//----

Apparently, doing the call ".a" "transforms" the type of "foo()" to "a's" type,
giving the cryptic error message. Or something.

############################
Both these cases passed in 2.063.2.
Both these cases pass if a is not declared void-initialized.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 08 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, ice
            Summary|[REG]CTFE failures for      |CTFE failures for structs
                   |structs with void           |with void initialized
                   |initialized members         |members
           Severity|regression                  |normal


--- Comment #1 from Don <clugdbug yahoo.com.au> 2013-09-12 00:08:07 PDT ---
This is not a regression. The change in behaviour is an accepts-invalid bug
that was fixed. In both cases, an uninitialized variable is indeed being read.
To get the intended behaviour, use 

-enum i = T.init.a; 
+enum i = T.a.init;

In the first test case, the second error message is a bit useless and should be
removed.
And the second case, the error message is so bad it's practically a internal
compiler error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #2 from monarchdodra gmail.com 2013-09-12 00:35:13 PDT ---
(In reply to comment #1)
 This is not a regression. The change in behaviour is an accepts-invalid bug
 that was fixed. In both cases, an uninitialized variable is indeed being read.
I somehow expected that answer, but I'm not sure I entirely agree. Marking a field to void means the compiler is allowed to optimize out giving the field a deterministic value on initializing the field, for run-time performance reasons. But that don't mean it's not actually initialized. I think that for CTFE, it should *just work* Not being able to count on "T t = T.init" meaning "t is in an initialized state", goes against what ".init" represents. No-one said it had a deterministic value though. In any case, I think it is not that problematic. "10994" is a real blocker for me though... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #3 from Don <clugdbug yahoo.com.au> 2013-09-13 00:30:32 PDT ---
 Marking a field to void means the compiler is allowed to optimize out giving
the field a deterministic value on initializing the field, for run-time performance reasons. But that don't mean it's not actually initialized. No, it's illegal. You're telling the compiler that you will initialize it. The compiler attempts to detect cases where you failed to do so, but it isn't always successful. For DMD, you need to compile with -O. struct S { int x; } void main() { S s = void; s.x++; } $ dmd -O bug bug.d(7): Error: variable s used before set The reason it seemed to be legal in structs, is that the compiler historically ignored the = void, and initialized it anyway! Now marking a field as void actually has an effect... (at least in some cases).
 "10994" is a real blocker for me though...
Yup. I've marked that with ctfe so that it appears on my list. The fix for the diagnostics in this one is here: https://github.com/D-Programming-Language/dmd/pull/2551 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995


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

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


--- Comment #4 from Maxim Fomin <maxim maxim-fomin.ru> 2013-09-13 00:55:37 PDT
---
(In reply to comment #2)
 (In reply to comment #1)
 This is not a regression. The change in behaviour is an accepts-invalid bug
 that was fixed. In both cases, an uninitialized variable is indeed being read.
I somehow expected that answer, but I'm not sure I entirely agree. Marking a field to void means the compiler is allowed to optimize out giving the field a deterministic value on initializing the field, for run-time performance reasons. But that don't mean it's not actually initialized. I think that for CTFE, it should *just work*
Marking a field of aggregate to void does different thing comparing to void initialization of variable - it makes dmd to blit memory with zeroes regardless of type (for many types default value is zero, but for some types - likes doubles and chars dmd still produces zeroes). I think CTFE should follow runtime in this regard, so in your example value of 'a' should be zero. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #5 from Maxim Fomin <maxim maxim-fomin.ru> 2013-09-13 01:12:19 PDT
---
(In reply to comment #3)
 No, it's illegal. You're telling the compiler that you will initialize it. The
 compiler attempts to detect cases where you failed to do so, but it isn't
 always successful. For DMD, you need to compile with -O.
 
 struct S {
    int x;
 }
 
 void main() {
    S s = void;
    s.x++;
 }
This is irrelevant to the issue because it is a different case.
 $ dmd -O bug
 bug.d(7): Error: variable s used before set
 
 The reason it seemed to be legal in structs, is that the compiler historically
 ignored the = void, and initialized it anyway! Now marking a field as void
 actually has an effect... (at least in some cases).
 
I think this point (issuing not initialized error) is wrong. Regardless of what dmd does produce in runtime (technically speaking dmd didn't ignored void initializer for fields - its presence actually affected behavior), there should be statically known default value of any type - that's why during CTFE dmd should produce some default value even for structs having void initialized fields. So, if dmd accepts this feature, it should produce some value. Not initialized type does not make much sense. It looks like initializaing some filed with void is a wired idea which doesn't fit into design, so it should be probably removed from language. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #6 from Don <clugdbug yahoo.com.au> 2013-09-13 03:15:04 PDT ---
(In reply to comment #5)
 (In reply to comment #3)
 No, it's illegal. You're telling the compiler that you will initialize it. The
 compiler attempts to detect cases where you failed to do so, but it isn't
 always successful. For DMD, you need to compile with -O.
 
 struct S {
    int x;
 }
 
 void main() {
    S s = void;
    s.x++;
 }
This is irrelevant to the issue because it is a different case.
It illustrates that it is illegal to read a value initialized to void. It is the same case, unless .init is magical. (And maybe it should be magical, see below).
 $ dmd -O bug
 bug.d(7): Error: variable s used before set
 
 The reason it seemed to be legal in structs, is that the compiler historically
 ignored the = void, and initialized it anyway! Now marking a field as void
 actually has an effect... (at least in some cases).
 
I think this point (issuing not initialized error) is wrong. Regardless of what dmd does produce in runtime (technically speaking dmd didn't ignored void initializer for fields - its presence actually affected behavior),
That's only because it's been generating extremely bad code. Intuitively, initializing a struct should be the same as initializing each member individually. struct S { int a = 2; int b = void; } S s; should mean: S s = void; S.a = S.a.init; S.b = S.b.init; and only the S.a case should generate any code. In fact, if it doesn't behave in that way, it's a completely pointless feature. (It's not an optimization).
 there should
 be statically known default value of any type - that's why during CTFE dmd
 should produce some default value even for structs having void initialized
 fields. So, if dmd accepts this feature, it should produce some value. Not
 initialized type does not make much sense.
 
 It looks like initializing some field with void is a weird idea which doesn't
 fit into design, so it should be probably removed from language.
Quite possibly. It's a fight: .init gives what it was initialized with. 'void' says it's not initialized! They can't both be true! Certainly the current runtime behaviour (blitting zeros onto the struct) is useless. Another possible resolution would be to define .init to mean "the value the object would be initialized to, with = void treated as the default initializer. This would however mean that: S s; and S s = S.init; would not be the same, in the case where a void initializer is present. Of course they are different anyway, if a constructor is present. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #7 from monarchdodra gmail.com 2013-09-13 03:44:12 PDT ---
(In reply to comment #6)
 (In reply to comment #5)
 I think this point (issuing not initialized error) is wrong. Regardless of what
 dmd does produce in runtime (technically speaking dmd didn't ignored void
 initializer for fields - its presence actually affected behavior),
That's only because it's been generating extremely bad code. Intuitively, initializing a struct should be the same as initializing each member individually. struct S { int a = 2; int b = void; } S s; should mean: S s = void; S.a = S.a.init; S.b = S.b.init; and only the S.a case should generate any code.
Just for the record, you should never initialize a struct instance like this. If you do this, then the padding bytes will not be initialized. This is important, as if S has no elaborate opEquals, comparison becomes a straight up memcompare, which will unconditonally scan the totality of S, padding and all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #8 from Maxim Fomin <maxim maxim-fomin.ru> 2013-09-13 06:06:19 PDT
---
(In reply to comment #6)
 (In reply to comment #5)
 This is irrelevant to the issue because it is a different case.
It illustrates that it is illegal to read a value initialized to void. It is the same case, unless .init is magical. (And maybe it should be magical, see below).
In case of particular variable void initialization there is no questions regarding default value of type per se, its semantic is clear and there is consensus regarding it. However in case of field initialization, usecase affects not some variable but type of variable (which is essential point here) and as consequence, all instances of that type. And there is no consensus on what does this feature mean. That's why I ask to concentrate on field void initialization.
 That's only because it's been generating extremely bad code.
 Intuitively, initializing a struct should be the same as initializing each
 member individually.
 
 struct S { 
    int a = 2;
    int b = void;
 }
 
 S s;
 
 should mean:
 S s = void;
 S.a = S.a.init;
 S.b = S.b.init;
 and only the S.a case should generate any code.
 
 In fact, if it doesn't behave in that way, it's a completely pointless feature.
 (It's not an optimization).
Yes, this behavior makes sense. There is one question left - what is default value of type S in CT, in particular what static assert(S.init.a == ??) should be.
 It looks like initializing some field with void is a weird idea which doesn't
 fit into design, so it should be probably removed from language.
Quite possibly. It's a fight: .init gives what it was initialized with. 'void' says it's not initialized! They can't both be true!
Yes.
 Certainly the current runtime behaviour (blitting zeros onto the struct) is
 useless.
Yes.
 Another possible resolution would be to define .init to mean "the value the
 object would be initialized to, with = void treated as the default initializer.
 This would however mean that:
 S s;
 and
 S s = S.init;
 would not be the same, in the case where a void initializer is present.
 Of course they are different anyway, if a constructor is present.
I think this is better option than current situation. Init value of aggregate with void field should give default value of respective type. If it does provide in CT zeroes irrespective of type, it is useless, if it doesn't yield anything at all, than it badly integrates into language design and should not be supported at all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #9 from github-bugzilla puremagic.com 2013-09-13 10:53:25 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a65d3247bf1e2443f2ed4c1632cf5b032edf78d3
Fix bug 10995 CTFE failure for void initialized members

Fix the duplicate error message, and don't scrub twice -- only scrub
when CTFE is actually finished.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10995


Walter Bright <bugzilla digitalmars.com> changed:

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


--- Comment #10 from Walter Bright <bugzilla digitalmars.com> 2013-09-13
10:54:14 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2551

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