[Issue 23641] core.simd.int4 multiplication
https://issues.dlang.org/show_bug.cgi?id=23641 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to ponce from comment #0) > LDC, GDC and DMD implement int4 differently when it comes to multiplication. > With DMD, you need to explicitly pass -mcpu=avx when compiling. It uses a strict gate at compile-time to determine whether or not the expression would map to a single opcode in the dmd backend for the given type mode. GDC and LDC ignores this gate - even if the information is there and can be queried against GCC or LLVM respectively - and just permissively allows the operation, which does mean that when passing down to the backend, it may split up the vector op into narrower modes when the target being compiled for doesn't have an available opcode. This behaviour is justified because strictly, we don't know whether the optimizer might rewrite the expression in such a way that there *is* an a supported opcode. For example: `a / b` has no vector op, but `a >> b` does. https://d.godbolt.org/z/vrn77GG9f (FYI, in gdc-13, `-Wvector-operation-performance` will be turned on by default so you'll at least get a non-blocking warning about expressions that have been expanded at narrower modes). --
[Issue 23643] New: [betterC] Better Error Message For CTFE GC Usage
https://issues.dlang.org/show_bug.cgi?id=23643
Issue ID: 23643
Summary: [betterC] Better Error Message For CTFE GC Usage
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: j...@jackstouffer.com
Consider the following real code example,
char[] unsignedToTempString(uint radix = 10)(ulong value, return scope
char[] buf) @safe
if (radix >= 2 && radix <= 16)
{
size_t i = buf.length;
do
{
uint x = void;
if (value < radix)
{
x = cast(uint)value;
value = 0;
}
else
{
x = cast(uint)(value % radix);
value /= radix;
}
buf[--i] = cast(char)((radix <= 10 || x < 10) ? x + '0' : x - 10 +
'a');
} while (value);
return buf[i .. $];
}
char[] myToString(ulong n)
{
char[20] buf;
auto s = unsignedToTempString(n, buf);
return s ~ (n > uint.max ? "UL" : "U");
}
enum a = myToString(5);
This gives the following error
Error: array concatenation of expression `cast(const(char)[])s ~ (n >
4294967295LU ? "UL" : "U")` requires the GC which is not available with
-betterC
The problem here is that DMD is trying to include the function myToString into
the object file even though it's only being used during CTFE. The fix for this
code is to make myToString a template. But the chance that a user is going to
know that is very low.
The compiler knows that it encountered this function during the CTFE run. So it
should give a helpful error message, something like.
Error: array concatenation of expression `cast(const(char)[])s ~ (n >
4294967295LU ? "UL" : "U")` requires the GC which is not available with
-betterC
This GC allocation was encountered during CTFE. If this function is
supposed to be a CTFE only function then this error can be fixed by making the
function a template.
Simple, easy to understand, and very helpful.
--
[Issue 23642] New: DMD installer should set up PATH in the same order as it was before reinstall
https://issues.dlang.org/show_bug.cgi?id=23642 Issue ID: 23642 Summary: DMD installer should set up PATH in the same order as it was before reinstall Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com It seems that reinstalling DMD on Windows will cause it to first uninstall and remove DMD from PATH, and then install it and add DMD to PATH as the *last* entry. This can cause unexpected problems, for example: - If there is no user-provided dub settings file (https://dub.pm/settings) - And if another D compiler is installed and is in PATH, e.g. LDC - And if the DMD was in PATH before LDC Then after installing a new version of DMD via the installer the LDC compiler will be picked up by default by DUB. Of course one can set up the default with https://dub.pm/settings, but the user may not be aware of that. --
[Issue 23641] core.simd.int4 multiplication
https://issues.dlang.org/show_bug.cgi?id=23641 ponce changed: What|Removed |Added Keywords||backend, SIMD, spec --
[Issue 15259] D_InlineAsm_X86_Any as builtin
https://issues.dlang.org/show_bug.cgi?id=15259 --- Comment #1 from ponce --- This can be closed, as assembly is on the way out anyway, and not faster in many cases. --
[Issue 23641] core.simd.int4 multiplication
https://issues.dlang.org/show_bug.cgi?id=23641 --- Comment #1 from ponce --- > requires Neon or SSE4.1 with the requires Neon or SSE4.1 with the pmulld instruction --
[Issue 23641] New: core.simd.int4 multiplication
https://issues.dlang.org/show_bug.cgi?id=23641
Issue ID: 23641
Summary: core.simd.int4 multiplication
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alil...@gmail.com
LDC, GDC and DMD implement int4 differently when it comes to multiplication.
-- test-case.d -
import core.simd;
int4 mul_4_ints (int4 a, int4 b)
{
return a * b; // ok with LDC and GDC, but not DMD
}
An efficient int4 * int4 requires Neon or SSE4.1 with the
- DMD doesn't implement int4 * int4
- GDC and LDC implement it with a replacement sequence and two multiply
instructions. GDC gained that function at one point.
In intel-intrinsics, I now tell people to use a _mm_mullo_epi32 to stay
portable, it will do the workarounds. Since having this operation is a bit of a
portability trap.
Two solutions I could see here:
- A. remove support from LDC and GDC, since no particular hardware support is
here below SSE4.1. User is forced to think about portability.
- B. add support for int4*int4 in DMD, to match the capabilities. Use can use
core.simd without unknowingly breaking compat.
Personally have no idea what is best.
--
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=10616, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=20913, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=22981 --
[Issue 20913] Array "forward reference" error
https://issues.dlang.org/show_bug.cgi?id=20913 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23598 --
[Issue 22981] Another forward reference bug involving a string mixin
https://issues.dlang.org/show_bug.cgi?id=22981 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23598 --
[Issue 10616] forward reference error with `class C: C.D{static class D{}}`
https://issues.dlang.org/show_bug.cgi?id=10616 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23598 --
[Issue 23631] [REG master] ./src/importc.h:80:8: warning: undefining "__has_builtin"
https://issues.dlang.org/show_bug.cgi?id=23631 --- Comment #3 from Iain Buclaw --- (In reply to Walter Bright from comment #2) > ImportC does not has builtin, and those macros are predefined by cpp. > Therefore, cpp is run with -Wno-builtin-macro-redefined. > > Perhaps you are building with an earlier dmd? That -W switch was added to > dmd's call to cpp very recently. No, you are not seeing this because you're building with an outdated toolcahin. I'm building master, everything is broken since https://github.com/dlang/dmd/pull/14801 CI is also broken when updating to latest toolchain, so I've had to revert it here: https://github.com/dlang/dmd/pull/14824 --
[Issue 23634] Possible data race with runnable example tester
https://issues.dlang.org/show_bug.cgi?id=23634 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3492 "Fix possible data race with runnable example tester" was merged into master: - f10de525521ed4b74a1d460ec6e456aa984e7d82 by Nick Treleaven: Fix Issue 23634 - Possible data race with runnable example tester https://github.com/dlang/dlang.org/pull/3492 --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #8 from Walter Bright --- Looking at expandMembers, perhaps this could be done in two passes - once for the top level conditional compilation, then check oneMember, then again for the rest. --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #7 from Walter Bright --- Perhaps I can make this work by noticing if the `static if` member is the only member of the template, so it can be eagerly evaluated? --
[Issue 23598] Another nasty forward reference bug
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #6 from Walter Bright --- What seems to be happening is the first time it goes through `template sort`, it cannot set `aliasdecl` because the two `alias sort` assignments are hidden behind conditional compilation. Hence `aliasdecl` is null. So, in semantic for `struct String` it encounters `SortedItems.length`. The `aliasdecl` is null, so `SortedItems` becomes `sort!(...)` which becomes `void` and there is no `length` for `void`. --
[Issue 23640] Nullable range iteration doesn't work with immutable values
https://issues.dlang.org/show_bug.cgi?id=23640 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @FeepingCreature updated dlang/phobos pull request #8668 "Fix issue 23460: Use `Nullable[]` to allow iterating `Nullable` of immutable type." fixing this issue: - Fix issue 23640: Use `Nullable[]` to allow iterating `Nullable` of immutable type. https://github.com/dlang/phobos/pull/8668 --
[Issue 23460] ICE in some cases when trying to infer an exception throwing function
https://issues.dlang.org/show_bug.cgi?id=23460 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @FeepingCreature created dlang/phobos pull request #8668 "Fix issue 23460: Use `Nullable[]` to allow iterating `Nullable` of immutable type." fixing this issue: - Fix issue 23460: Use `Nullable[]` to allow iterating `Nullable` of immutable type. https://github.com/dlang/phobos/pull/8668 --
