[Issue 20126] New: bad codegen for return statement in function with asm code
https://issues.dlang.org/show_bug.cgi?id=20126
Issue ID: 20126
Summary: bad codegen for return statement in function with asm
code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
On my local 2.087, this code works, but in master, it generates bad code:
asmtest.d
-
extern(C) float floop(float* r, float x)
{
asm
{
mov EAX, x;
mov RCX, r;
xchg [RCX], EAX;
mov x, EAX;
}
return x;
}
> dmd asmtest.d -c -m64
Dumping this emits:
:
0: 55 push %rbp
1: 48 8b ecmov%rsp,%rbp
4: 48 83 ec 10 sub$0x10,%rsp
8: 48 89 7d f0 mov%rdi,-0x10(%rbp)
c: f3 0f 11 45 f8 movss %xmm0,-0x8(%rbp)
11: 8b 45 f8mov-0x8(%rbp),%eax
14: 48 8b 4d f0 mov-0x10(%rbp),%rcx
18: 87 01 xchg %eax,(%rcx)
1a: 89 45 f8mov%eax,-0x8(%rbp)
1d: c9 leaveq
1e: c3 retq
It's missing this before the return:
movss 0x8(%rbp),%xmm0
You can see where it loads from the argument in xmm0 to -0x8(%rbp) to transfer
to RAX in the asm code, then the asm code as written.
It writes the modified value back to the stack, but the `return x;` statement
should load `x` back into xmm0 to return the value, but it just skips that.
I presume that it assumes xmm0 was not clobbered by the asm block and elides
the return code, but the variable was written...
This fails on x64 in master on both windows and linux, but it works correctly
for -m32 (does emit an fld before return).
It also used to work on x64 in 2.087.0 (which i'm running locally)
--
[Issue 20124] macOS 10.15 requires notarized apps
https://issues.dlang.org/show_bug.cgi?id=20124 Nicholas Wilson changed: What|Removed |Added CC||iamthewilsona...@hotmail.co ||m --- Comment #2 from Nicholas Wilson --- I guess this will affect LDC & GDC too. --
[Issue 20124] macOS 10.15 requires notarized apps
https://issues.dlang.org/show_bug.cgi?id=20124 ponce changed: What|Removed |Added CC||alil...@gmail.com --- Comment #1 from ponce --- Created attachment 1759 --> https://issues.dlang.org/attachment.cgi?id=1759&action=edit Notarization script Here is a script app developers share in my domain. I've not used it yet. >From what I heard, notarization apparently must be applied to a complete redistributable (such as a ZIP file). It will notarize in a "deep" manner what it founds. One of the (few?) advantages is that notarization will warn about errors with code signing. Code-signing for macOS is just $99/year and relatively easy. --
[Issue 4923] immutable module variables are modifiable in non-shared module constructors
https://issues.dlang.org/show_bug.cgi?id=4923 Les De Ridder changed: What|Removed |Added CC||dl...@lesderid.net --
[Issue 1324] __FILE__ in mixin template expand to the definition, not the instantiation
https://issues.dlang.org/show_bug.cgi?id=1324
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from RazvanN ---
(In reply to Mathias LANG from comment #1)
> Edited the issue title to make the current problem more obvious.
> The original code uses ranges access to trigger an exception, which are
> errors (not exception in D2).
>
> The actual bug, can be illustrated by those 2 files:
>
> / t1.d /
> module t1;
> import t2;
> import std.stdio;
> void main()
> {
> mixin mixinT2!();
> testT2();
> }
>
> / t2.d /
> module t2;
> template mixinT2()
> {
> void testT2()
> {
> try
> throw new Exception("FromT2");
> catch(Exception e)
> writefln("T2: caught exception in %s: '%s'", __FILE__, e.toString);
> }
> }
>
> ///
> Running this code:
>
> dmd t2.d -run t1.d
> T2: caught exception in t2.d: 'object.Exception@t2.d(8): FromT2
>
> ??:? void t1.main().__mixin1.testT2(int) [0x102b84f17]
> ??:? _Dmain [0x102b84afb]'
>
>
> As the message shows, `__FILE__` expands to `t2.d`, both in the `writeln`
> call and the default parameter for `Exception` ctor.
> However, the specs currently mentions:
> > __FILE__ and __LINE__ expand to the source file name and line number at the
> > point of instantiation. The path of the source file is left up to the
> > compiler.
>
> It is not 100% clear to me if "point of instantiation" implies templates as
> well, and thus not 100% clear if this is a bug and/or can be solved.
"Point of instantiation" refers to the call site of a function that uses
__FILE__ as a default parameter. Even though the mixin introduces the code in
there, I like it that __FILE__/__LINE__ point to the actual declaration because
it's real code, that generated.
IMHO this bug report is invalid.
--
[Issue 2788] return val not passable via ref const in other method
https://issues.dlang.org/show_bug.cgi?id=2788
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #2 from RazvanN ---
`getVar()` is an rvalue, therefore it cannot be passed to a ref parameter.
Therefore the bug report is invalid.
>struct A {}
>void foo(ref A a) {}
>void main()
>{
>foo(A());
>}
This doesn't compiler and neither does this:
>static A bar()
>{
>return A();
>}
>
>foo(bar());
Closing as invalid.
--
[Issue 1448] UTF-8 output to console is seriously broken
https://issues.dlang.org/show_bug.cgi?id=1448 --- Comment #18 from kinke --- This isn't solved, but would now be solvable with recent Windows versions. There are 2 things about this: * DMD outputs a mix of UTF-8 and strings in the current codepage, AFAIK without setting any console codepage, so DMD output on Windows can be garbage. LDC v1.17 fixes this for LDC. * User programs writing UTF-8 strings to the console suffer from the same issue. This *could* be worked around by setting the console codepage in druntime's _d_run_main and resetting it to the original one before termination. --
[Issue 17263] Issue diagnostic if mandatory template parameter is missing
https://issues.dlang.org/show_bug.cgi?id=17263 Les De Ridder changed: What|Removed |Added CC||dl...@lesderid.net --
[Issue 20125] New: Different .stringof format for CT Sequences depending on content
https://issues.dlang.org/show_bug.cgi?id=20125 Issue ID: 20125 Summary: Different .stringof format for CT Sequences depending on content Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: simen.kja...@gmail.com import std.meta; static assert(AliasSeq!().stringof == "()"); static assert(AliasSeq!(1).stringof== "tuple(1)"); static assert(AliasSeq!(1,2).stringof == "tuple(1, 2)"); static assert(AliasSeq!(int).stringof == "(int)"); static assert(AliasSeq!(int, int).stringof == "(int, int)"); static assert(AliasSeq!(int, 2).stringof == "tuple((int), 2)"); static assert(AliasSeq!(int, 2, int, int).stringof == "tuple((int), 2, (int), (int))"); As we can see above, CT sequences containing at least one value has a "tuple" prefix, while others don't. Not only that, but mixed sequences wrap every type in (brackets). --
[Issue 1448] UTF-8 output to console is seriously broken
https://issues.dlang.org/show_bug.cgi?id=1448 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #17 from RazvanN --- (In reply to kinke from comment #16) > Update: it's working with Win10 v1903 (with the exact same binary that > didn't work with v1803). According to Rainer Schütze, it's working since > v1809. See > https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and- > utf-8-output-text-buffer/. So is this issue fixed? I don't have a windows machine to test it. Should we close this? --
[Issue 1182] Mixins scope
https://issues.dlang.org/show_bug.cgi?id=1182 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED URL||d CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #7 from RazvanN --- (In reply to Marcin Kuszczak from comment #4) > First: How does it work? There are two policy symbols in template > (overloaded functions). Why 'getter property' is choosen? How to choose > setter? > Because the overload that does not take any parameters is called. If you would call the other it would be an ambiguity error (as it should). > Second: That's solution far from good. Imagine you have e.g. 10 symbols > inserted by mixin (I work with such a case.). You can use metaprogramming to generate the aliases. >What's more mixins are > inserted into many inherited classes. You need to alias all symbols > inside mixin template in every inherited class. > You would most likely get errors regarding overriding. > Third: Would be also great to implement anchored types (#1120). It would > depreciate this use-case for mixins. > > I request to leave that enhancement open. Simply enhancing rule of > inserting anonymous mixin into scope for function names *AND* their > arguments would solve problem cleanly. That will probably never happen. That would break code and it would make the mixin model inconsistent with the import one and we don't want that. This design has served us well and there is no reason to change it, since there are workarounds for all the situations stated in the enhancement request. Closing as WONTFIX. --
[Issue 20124] New: macOS 10.15 requires notarized apps
https://issues.dlang.org/show_bug.cgi?id=20124 Issue ID: 20124 Summary: macOS 10.15 requires notarized apps Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: d...@me.com On the latest version of macOS, Catalina (10.15), currently in beta, it's required that all applications are notarized. This includes command line applications and installers. If an application is not notarized the application will not run and a dialog opens. It's possible to start the application anyway by going into System Preferences and launch the application. But it's a pretty poor user experience. This applies not to just DMD but all executables that are shipped with in the archive and the installer itself. To notarized an application it needs to be signed with a Developer ID certificate and the application needs to adopt the Hardened runtime [1]. A Developer ID costs 99 USD per year. Nonprofit organizations may get the fee waived [2]. [1] https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution [2] https://developer.apple.com/support/membership-fee-waiver/ --
[Issue 20104] core.atomic has no exchange function
https://issues.dlang.org/show_bug.cgi?id=20104 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/druntime pull request #2729 "Added atomicExchange to core.atomic" was merged into master: - 16048f1d764c279c8d860e02fae90f3b960fc28e by Manu Evans: Added atomicExchange to core.atomic Fix Issue 20104 - core.atomic has no exchange function https://github.com/dlang/druntime/pull/2729 --
[Issue 1670] tupleof an aggregate cannot be used as a template tuple argument
https://issues.dlang.org/show_bug.cgi?id=1670 RazvanN changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from RazvanN --- This issue has been fixed in D2. Closing as WORKSFORME. --
[Issue 1399] Wrapping a case statement in a version statement gives a shadowing declaration error.
https://issues.dlang.org/show_bug.cgi?id=1399 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #7 from RazvanN --- This the correct behavior. The compiler identifies the end of a case statement if it has encountered another case/default statement or the ending `}` of the switch statement. Once a version identifier or even a static if is encountered, the parser sees it as part of the case statement that it is analyzing at that time. A workaround would be to add the version block in the default statement and lose the `case 2` statement. Closing as invalid. --
[Issue 20120] libcurl.dll hangs when running std.net.curl unittests
https://issues.dlang.org/show_bug.cgi?id=20120 --- Comment #7 from Rainer Schuetze --- (In reply to Seb from comment #6) > Maybe sth is wrong with the test server that is spawned to handle these test > requests? It's a simple while loop after all. The problem is reproducible locally. > BTW how does this pass on the Auto-Tester? Isn't 2.079 used there? I suspect the DLLs have never been updated on the build machines. They sit in a folder outside the build directories, see for example https://github.com/braddr/at-client/blob/8a2a2743716fcfde13d5ab0856bd4b5a0e403851/configs/WIN-F30QP0PU8L1#L23 --
