[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #9 from timon.g...@gmx.ch ---
(In reply to timon.gehr from comment #8)
> (In reply to RazvanN from comment #1)
> > Issuing an error is the correct behavior. As you can see in the grammar 
> > [1], 
> > *(x)++ is parsed the following way: *UnaryExpression. If a parenthesis is
> > encountered, then the parser expects a type :
> > (type).identifier/templateInstance.
> 
> That is the bug. The grammar allows the derivation
> 
> UnaryExpression
>   \
> PowExpression
> \
>   PostfixExpression
>   \
> PostfixExpression ++
> \
>  ( PrimaryExpression )
>   \
>   ...
> \
>  Identifier
> 

Should have been:

UnaryExpression
  \
PowExpression
\
  PostfixExpression
  \
PostfixExpression ++
\
  PrimaryExpression
  \
   ( Expression )
\
...
  \
   Identifier

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #8 from timon.g...@gmx.ch ---
(In reply to RazvanN from comment #1)
> Issuing an error is the correct behavior. As you can see in the grammar [1], 
> *(x)++ is parsed the following way: *UnaryExpression. If a parenthesis is
> encountered, then the parser expects a type :
> (type).identifier/templateInstance.

That is the bug. The grammar allows the derivation

UnaryExpression
  \
PowExpression
\
  PostfixExpression
  \
PostfixExpression ++
\
 ( PrimaryExpression )
  \
  ...
\
 Identifier

Aside: It is a bad idea to try and distinguish types from non-types in the
parser, because it just can't. I guess this grew out of the way the parser and
semantic analysis were developed. It's not a very good design.

> Since none of the above is actually encountered, the parser presumes you
> tried to do a C style cast. Note that dropping the useless parens

The parens were not useless, they just became useless because I created a
reduced test case.

> or doing
> *((x))++ works since the parser then knows that the outermost () hold a
> primary expression.
> ...

That's a workaround.

> The behavior is according to the spec,

Certainly not. The spec is also bad though. Types should be part of the
expression grammar.

> so I will close this as invalid. 

It's not invalid.

> 
> [1] https://dlang.org/spec/grammar.html#UnaryExpression

--

[Issue 17935] [scope] auto-generated destructor not scope aware

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17935

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7283

--

[Issue 17965] Unexplained usage of the FPU while function result already in right XMM registers

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17965

--- Comment #3 from ponce  ---
@Basile: I also find that unsettling.

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17961

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #6 from Jonathan M Davis  ---
(In reply to hsteoh from comment #5)
> Yeah, I know Phobos is not -dip1000 ready yet.  That's probably how this PR
> got pulled in spite of the breakage. :-P
> 
> It would be nice to fix these breakages, though.  Less trouble for when we
> do want to start building Phobos with -dip1000.

I think that Walter has done a few PRs to fix DIP 1000 issues in Phobos, but as
long as -dip1000 isn't being used, we're going to continue to introduce code
that doesn't work with it and have to create new PRs to fix that breakage when
we catch it. I don't think that -dip1000 is really ready to be enabled though,
even if all of druntime and Phobos worked with it. So, we could be at this for
a while, depending on how long it takes for -dip1000 to be ready.

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17961

--- Comment #5 from hst...@quickfur.ath.cx ---
Yeah, I know Phobos is not -dip1000 ready yet.  That's probably how this PR got
pulled in spite of the breakage. :-P

It would be nice to fix these breakages, though.  Less trouble for when we do
want to start building Phobos with -dip1000.

--

[Issue 17965] Unexplained usage of the FPU while function result already in right XMM registers

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17965

b2.t...@gmx.com changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from b2.t...@gmx.com ---
(In reply to ponce from comment #1)
> You can avoid such FPU <=> XMM round trips by using the LDC compiler. The
> DMD backend tend to generate those.

I know p0nce, but this is really a "pathological case" to me. The "trip", as
you say, that happens at the end is a bug, not just something that could be
better.

--

[Issue 17965] Unexplained usage of the FPU while function result already in right XMM registers

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17965

ponce  changed:

   What|Removed |Added

 CC||alil...@gmail.com

--- Comment #1 from ponce  ---
You can avoid such FPU <=> XMM round trips by using the LDC compiler. The DMD
backend tend to generate those.

--

[Issue 17823] Declaration of a __vector leads to a segfault on OSX 32bits

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17823

b2.t...@gmx.com changed:

   What|Removed |Added

   Severity|blocker |normal

--

[Issue 17792] [ICE] Internal error: ddmd/backend/el.c 3033 with simd.double4

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17792

--- Comment #1 from b2.t...@gmx.com ---
w/ double2 as well (now that double4 usage is restricted by an option)

--

[Issue 17419] add __traits(getLinkage, s) to the the linkage of symbol s

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17419

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #10 from b2.t...@gmx.com ---
*** Issue 17150 has been marked as a duplicate of this issue. ***

--

[Issue 17150] Add a trait to detect the linkage attribute of classes and interfaces

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17150

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from b2.t...@gmx.com ---


*** This issue has been marked as a duplicate of issue 17419 ***

--

[Issue 17893] [REG 2.076.1] contract in templatized final class require nothrow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17893

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from b2.t...@gmx.com ---
the bot didn't detect the pull as auto closable but this is well fixed now:

https://github.com/dlang/dmd/pull/7208

--

[Issue 17965] New: Unexplained usage of the FPU while function result already in right XMM registers

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17965

  Issue ID: 17965
   Summary: Unexplained usage of the FPU while function result
already in right XMM registers
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Keywords: performance
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

For the following trivial function:

---
struct Point{double x,y;}

Point foo()
{
Point result;
return result;
}
---

dmd64 with -O generates:

;--- SUB 0044E1C0h ---
0044E1C0h  push rbp
0044E1C1h  mov rbp, rsp
0044E1C4h  sub rsp, 20h
0044E1C8h  lea rax, qword ptr [004C92F0h]
0044E1CFh  movsd xmm0, qword ptr [rax] // result.x = 0; // default
init OK
0044E1D3h  movsd qword ptr [rbp-10h], xmm0 // load result.x in a temp
because ?
0044E1D9h  movsd xmm1, qword ptr [rax+08h] // result.y = 0; // default
init OK
0044E1DEh  movsd qword ptr [rbp-08h], xmm1 // load result.y in a temp
because ?
0044E1E4h  fld qword ptr [rbp-10h] // pass the whole result to
the FPU because ?
0044E1E7h  fld qword ptr [rbp-08h] // ...
0044E1EAh  fstp qword ptr [rbp-20h]// ...
0044E1EDh  movsd xmm1, qword ptr [rbp-20h] // reload back result to
XMM0 and 1 because?
0044E1F2h  fstp qword ptr [rbp-20h]//
0044E1F5h  movsd xmm0, qword ptr [rbp-20h] // .
0044E1FAh  mov rsp, rbp
0044E1FDh  pop rbp
0044E1FEh  ret 
;-

Point.x is returned in low XMM0 half and Point.y in low XMM1 half.
from 0044E1E4h to 0044E1F5h, the result is loaded in the FPU
and then loaded back in XMM0 and XMM1 for no reasons. In addition, 32 bytes are
allocated for this useless transfert, leading to the prelude and prologue to be
emitted.


Expected backend production is something like

---
lea rax, qword ptr []
movsd xmm0, qword ptr [rax]
movsd xmm1, qword ptr [rax+08h]
ret
---

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #7 from Simen Kjaeraas  ---
Unsurprisingly, the function call variant is somewhat unfixable. (T)(a+b) is a
very common cast in C, and looks a lot like a function call where T is a
function. Even (T)(1,2,3) is valid C.

It would probably be possible to make this an error at a later point - when we
know that the content of the parentheses does evaluate to a type.

Anyways, PR: https://github.com/dlang/dmd/pull/7281

--

[Issue 17964] New: [CTFE] If array is large enough it hits __simd at CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17964

  Issue ID: 17964
   Summary: [CTFE] If array is large enough it hits __simd at CTFE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dmitry.o...@gmail.com

Array ops used to work at CTFE, now:

uint bug(){
uint[] a = [1, 2, 3, 5, 6, 7];
uint[] b = [1, 2, 3, 5, 6, 7];
a[] |= ~b[];
return a[1];
}

enum x = bug();

Produces on a recent master (1fa67d062b8d755b11722ea112af63cb34cc06b7):

/home/olshanskiy/dmd2/linux/bin64/../../src/druntime/import/core/internal/arrayop.d(102):
Error: __simd cannot be interpreted at compile time, because it has no
available source code
/home/olshanskiy/dmd2/linux/bin64/../../src/druntime/import/core/internal/arrayop.d-mixin-50(50):
   called from here: load([pos])
/home/olshanskiy/dmd2/linux/bin64/../../src/druntime/import/core/internal/arrayop.d-mixin-50(50):
   called from here: binop(load([pos]), unaop(load(&_param_1[pos])))
/home/olshanskiy/dmd2/linux/bin64/../../src/druntime/import/core/internal/arrayop.d-mixin-50(50):
   called from here: store([pos], binop(load([pos]),
unaop(load(&_param_1[pos]
bug.d(5):called from here: arrayOp(a[], b[])
bug.d(9):called from here: bug()

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #6 from Simen Kjaeraas  ---
You're at least partly right, though (a[b]).c does work. The smallest example
of this bug is probably this:

unittest {
(a)++;
}

That should of course fail to compile as well, but for other reasons. This
should compile:

unittest {
int a;
(a)++;
}

Are there any cases where this is valid with 'a' being a type? No. The compiler
even complains about exactly that: "C style cast illegal, use cast(a)++0".
++(T), where T has overloaded static opUnary, should and does work, but the
postfix version does not, because the lowering doesn't make sense.

Another example of where this bug shows up is with call expressions:

void foo(int n) {}
unittest {
(foo)(3);
}

(parameter added because the compiler gives up and spews other errors when
getting empty parentheses)

For comparison, (a)++ compiles and runs with expected semantics in C#, C++ and
Javascript.

It seems to me that this is in fact not a spec error, but that the parser is
misbehaving when reporting this error. It gives up when it sees that the next
character after (a) is not a period[0], while the grammar seems to support a
test for PowExpression, to find that (a) is a PrimaryExpression on the form
(Expression), and continue down that route. The error message is printed long
before the parser knows that the stuff inside the parentheses is a type.

[0]:
https://github.com/dlang/dmd/blob/1fa67d062b8d755b11722ea112af63cb34cc06b7/src/ddmd/parse.d#L7959

--

[Issue 17963] New: Spec is incorrect about what is considered a COM interface

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17963

  Issue ID: 17963
   Summary: Spec is incorrect about what is considered a COM
interface
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

The spec says:
"A COM interface is defined as one that derives from the interface
core.stdc.win­dows.com.IUnknown."
https://dlang.org/spec/interface.html#com-interfaces

However an interface derived from another interface named "IUnknown", whatever
its content and fully qualified name, will also be considered COM, with the
semantics restrictions.
This is very desirable since it allow to use COM interfaces with sayn @nogc
signatures, or COM without Windows.

So the spec is wrong about this, core.stdc.win­dows.com.IUnknown is not needed,
but the name "IUnknown" is.

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #5 from anonymous4  ---
Ah, so the problem is that in expression (a[b]).c it's undecidable if the
braced expression should be parsed as type or value.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #17 from anonymous4  ---
(In reply to Vladimir Panteleev from comment #4)
> dmd/src/root/file.d is now located at dmd/src/ddmd/root/file.d:
> 
> https://github.com/dlang/dmd/blob/master/src/ddmd/root/file.d#L97
File size can be determined by seeking to the end. That would be a simpler fix.

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

--- Comment #4 from RazvanN  ---
(In reply to Simen Kjaeraas from comment #3)
> (In reply to RazvanN from comment #1)
> > The behavior is according to the spec, so I will close this as invalid. 
> 
> It's perfectly possible for the spec to be in error (there's even the spec
> keyword in Bugzilla). In this case, the code looks perfectly sensible for
> someone who doesn't know the spec in detail, and getting a compiler error
> like this is not expected.
> 
> Could the spec in this case be amended to allow the example code to compile,
> without breaking code elsewhere? I don't know. If you know it's impossible,
> please explain why, and close this bug again.

It's not that it is impossible, rather that it requires much effort to allow a
redundant use of ().

--

[Issue 17915] [REG 2.073] core.exception.AssertError@ddmd/optimize.d(614): Assertion failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17915

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/dd2fcfa3278dda8d5d1109365ef53f7c92dd1276
fix Issue 17915 - [REG 2.073] core.exception.AssertError@ddmd/optimize.d(614):
Assertion failure

https://github.com/dlang/dmd/commit/1fa67d062b8d755b11722ea112af63cb34cc06b7
Merge pull request #7278 from WalterBright/fix17915

fix Issue 17915 - [REG 2.073] core.exception.AssertError@ddmd/optimiz…
merged-on-behalf-of: Iain Buclaw 

--

[Issue 17955] compiler segfault in DsymbolSemanticVisitor::visit(UnittestDeclaration*)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17955

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/a32b62f9415c65df9186037fbfe2f9acc1f5be56
fix Issue 17955 - compiler segfault in
DsymbolSemanticVisitor::visit(UnittestDeclaration*)

https://github.com/dlang/dmd/commit/56e48617fa91c80555abdcb5251861d3ed4099a7
Merge pull request #7277 from WalterBright/fix17955

fix Issue 17955 - compiler segfault in DsymbolSemanticVisitor::visit(…
merged-on-behalf-of: Iain Buclaw 

--

[Issue 17915] [REG 2.073] core.exception.AssertError@ddmd/optimize.d(614): Assertion failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17915

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17955] compiler segfault in DsymbolSemanticVisitor::visit(UnittestDeclaration*)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17955

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 7184] parse error on *(x)++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7184

Simen Kjaeraas  changed:

   What|Removed |Added

   Keywords||spec
 Status|RESOLVED|REOPENED
 CC||simen.kja...@gmail.com
 Resolution|INVALID |---

--- Comment #3 from Simen Kjaeraas  ---
(In reply to RazvanN from comment #1)
> The behavior is according to the spec, so I will close this as invalid. 

It's perfectly possible for the spec to be in error (there's even the spec
keyword in Bugzilla). In this case, the code looks perfectly sensible for
someone who doesn't know the spec in detail, and getting a compiler error like
this is not expected.

Could the spec in this case be amended to allow the example code to compile,
without breaking code elsewhere? I don't know. If you know it's impossible,
please explain why, and close this bug again.

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17961

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #4 from Dmitry Olshansky  ---
(In reply to hsteoh from comment #0)
> Code:
> ---
> /* test.d */
> import std.uni;
> ---
> 
> Compile command:
> ---
> dmd -dip1000 -unittest -c test.d
> ---
> 
> Compiler output:
> ---
> /usr/src/d/phobos/std/uni.d(2554): Error: reference to local variable
> __tmpfordtor853 assigned to non-scope parameter this calling
> std.uni.InversionList!(GcPolicy).InversionList.byInterval
> /usr/src/d/phobos/std/uni.d(1976): Error: template instance
> std.uni.InversionList!(GcPolicy) error instantiating
> ---
> 
> This used to work fine until recently. Will post an update once I finish git
> bisecting.

Most curious. But AFAIK Phobos is not compiled with -dip1000 yet.

--