On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
That's why shouldn't compose it like that.
It's been a constant source of bugs in C/C++ code:
On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu
wrote:
Kate Gregory makes a good argument on something I've often
commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682
Sean Parent covered early exits years ago in an excellent talk I
just can't find anymore (maybe
On Wednesday, 5 September 2018 at 19:35:46 UTC, Meta wrote:
I think the only sane way to use asserts as an optimization
guide is when the program will abort if the condition does not
hold.
Which is the usual behavior of assert.
I'm all for using them to optimize but it's not clear how to do
On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote:
On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc
wrote:
https://issues.dlang.org/show_bug.cgi?id=19179
https://issues.dlang.org/show_bug.cgi?id=5570
https://issues.dlang.org/show_bug.cgi?id=13957
According to
On Friday, 7 September 2018 at 08:26:11 UTC, Kagamin wrote:
You can sort of have custom literals like in C++
String s(object.string t){ return String(t); }
foo("this".s);
Awesome :D
On Sunday, 2 September 2018 at 21:12:39 UTC, Nick Sabalausky
(Abscissa) wrote:
This does make me think of one thing: Shouldn't assert
expressions be required to be pure? (even if only weakly pure)
Not sure how much practical problems that would create, but at
least in theory it certainly
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright
wrote:
Note the "may or may not be evaluated." We've debated this here
before. I'm rather pleased that John agrees with me on this.
It shouldn't allow side-effects then though.
https://run.dlang.io/is/P6VnYd
Also a common source of
On Friday, 24 August 2018 at 09:52:20 UTC, Walter Bright wrote:
On 8/24/2018 1:45 AM, Trass3r wrote:
Are you referring to http://wg21.link/P0709 ?
Yes. (please don't use link shorteners, they tend to go poof)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf
I expect
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
Back to throwing constructors.
1) They are expensive, adding considerable hidden bloat in the
form of finally blocks, one for each constructing field. These
unwinding frames defeat optimization. The concept of "zero-cost
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
Possible Solution: Make all globals hidden by default unless
'export'.
Same mess as in C++. But there you have -fvisibility=hidden at
least to fix it.
Side effects: Everyone will be spending weeks to months fixing
their
On Tuesday, 20 October 2015 at 07:57:29 UTC, Marco Leise wrote:
For a while now GDC and LDC have supported a variety of their
backend's attributes, like inlining or compiling a specific
function with SSE4 in an otherwise generic x64 build.
I think we should unify those into a common
http://wg21.link/P0709
Interesting read. Looks like they want to bake something like
llvm::Expected into the language. I wonder if D shares all
these dynamic exceptions issues.
In any case it should become relevant if they really change the C
ABI as well.
Here's the original discussion with Eric's elaborate answer:
http://ericniebler.com/2014/02/21/introducing-iterables/#comment-403
Because I want to leverage the vast amount of iterator-based
code already written, and because in my experience, I don’t
find that ranges as primitives solve all
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:
Yes, this is an explanation. Thanks. So the argument being C++
customs. Now that you mention it, this seems to be the argument
in Eric's D4128 paper, too.
I was hoping for a somewhat deeper reasoning. Out of curiously,
I am
Just save yourself lots of headaches and abandon the optlink/omf
crap with -m64 resp. -m32mscoff.
Plenty of not covered lines are actually assert(0)'s.
On Thursday, 13 November 2014 at 09:36:26 UTC, Manu via
Digitalmars-d wrote:
On 13 November 2014 10:57, Walter Bright wrote:
This is good news for D! It lowers the bar for writing 64 bit
D code on
Windows, and it also enables us to abandon support for
versions of VS prior
to 2013.
Many,
Let the bikeshedding begin.
They treat the style guide like the holy bible.
https://github.com/D-Programming-Language/dmd/pull/4092
my work has stalled as I try to find a way to make the
experience more polished, and less like patchwork.
It's a shame this went nowhere:
https://issues.dlang.org/show_bug.cgi?id=12270
Does this msvc based build output gdb-compatible
debugging symbols?
No DWARFs in there.
On Thursday, 28 February 2013 at 01:03:08 UTC, Maxime Chevalier
wrote:
I did some further testing:
void foo(int a, int b)
{
writefln(a: %s, a);
writefln(b: %s, b);
}
unittest
{
foo(1, 2);
asm
{
mov RDI, 1;
mov RSI, 2;
call foo;
}
}
Produces:
On Thursday, 28 February 2013 at 02:02:09 UTC, Walter Bright
wrote:
On 2/27/2013 5:03 PM, Maxime Chevalier wrote:
Unless I'm mistaken, DMD does not respect the C calling
convention on Linux/AMD64.
To use the C calling convention, specify extern (C) for the
function.
This is about
Looking at the code extern(D) is in the _revfunc list in optabgen.
Which seems to cause params to be reversed independent of the
architecture in FuncDeclaration::toObjFile // Reverse params[]
entries.
Meaning Linux x32 would also be affected.
This totally smells like a remnant as the code
Yes it's clearly stated on the ABI page (and sane).
Nobody ever noticed cause it's hard to spot this in assembly.
But it was very salient and disturbing in llvm IR.
LDC is 2.065
Already 2.066 in the repo.
I don't think it would be too difficult. You are analyzing an
expression that evaluates to false, and it wouldn't take much
to dig down to find out which subexpressions cause the false to
occur.
I think it's not that straightforward in dmd as it simply
delegates the constraint to the
What should I do? Am I stuck with not using -O and -inline for
now, hoping that things will improve in the future?
Step 1) DustMite the heck out of it and create a bug report.
Step 2) Start using ldc/gdc for release builds if possible.
http://youtu.be/qwXq5MqY2ZA?t=33m57s
I wish we had diagnostics like that in D.
the long-term solution is to include the [win32] headers in
druntime
™
On Wednesday, 8 October 2014 at 18:56:31 UTC, Etienne wrote:
I can't seem to find this function anywhere: __simd(void16*,
void16)
MOVDQU = void _mm_storeu_si128 ( __m128i *p, __m128i a)
MOVDQU = __m128i _mm_loadu_si128 ( __m128i *p)
Is there a module by now that allows to directly write
On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
Also, inferring everything is quite
expensive and we want D to compile fast.
Doesn't the compiler have to do that anyway?
I'd expect a proper compiler to check if my code is actually what
I claim it is. It's quite easy to mark
https://auto-tester.puremagic.com/?projectid=10
Just windows left now.
Looks like a dash is missing?
ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d
magicport\scanner.d magicport\tokens.d magicport\parser.d
magicport\dprinter.d magicport\typenames.d magicport\visitor.d
Btw was there any specific commit / release that reduced
memory concumption or it was a gradual improvement?
No idea.
One could use Digger to generate a graph of SDC build times over
time like in the DConf talk.
And how do ldc and gdc do? =)
Since Git 1.8.2 you can bound a submodule to a branch.
Ah cool didn't know that.
You could also use submodules (or subtrees, haven't tried them
yet).
with 3 pull request queues
Good argument for the separation :)
SEH was patented, so llvm doesn't support it.
That has changed.
On Saturday, 6 September 2014 at 21:54:00 UTC, David Nadlinger
wrote:
On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote:
SEH was patented, so llvm doesn't support it.
That has changed.
Has it? SEH on Win64 is something entirely different from the
original (x86) SEH design
Thanks for the help with the Win64 version and for providing
the binary!
:) fwiw
A bunch of tests still crash.
I also have an experimental Win64 MSVC version.
https://github.com/Trass3r/ldc/releases
I don't think dmd comes with a COFF64 linker now, users are
just told to install Visual Studio or the Windows SDK for a
linker. No reason you can't do the same with COFF32. Optlink
can stick around with OMF for a couple releases. I suspect
nobody would use it when given the choice of COFF32
Is there a PR now?
What makes it craziest is that there's a COFF32 branch lying
around that nobody merges:
http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
Same procedure as every year.
? Or should we
be using core.runtime.Runtime.loadLibrary()?
I think so, though the page is still 32-bit/Optlink centric.
http://wiki.dlang.org/Win32_DLLs_in_D
Just created a Win64 dll the other day:
https://github.com/Trass3r/hooksample
But haven't investigated GC/runtime sharing.
Yeah that's the price we pay for the simplicity.
Also most constraints directly or indirectly consist of a complex
boolean expressions and you don't get any hint which part failed
and why.
On linux more work should be done to get line infos, I'm
investigating how to get then.
Cheers !
That's the spirit!
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it
also allow this?
The implementation doesn't seem to be correct.
Could anybody versed in this look into it?
version(Windows)
{
private extern __gshared fenv_t _FE_DFL_ENV;
fenv_t* FE_DFL_ENV = _FE_DFL_ENV;
}
There's no such symbol in the libcmt and it fails to link.
druntime:
make -f win64.mak DMD=../windows/bin/dmd.exe
CC=\c:\l\vc10\bin64\cl.exe\ target
phobos:
make -f win64.mak DMD=../windows/bin/dmd.exe
CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make
AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib
That works?
So it probably doesn't need
Nope doesn't.
Setting VCDIR and SDKDIR via the make command works.
Setting VCDIR and SDKDIR via the make command works.
Works for me. Maybe you need a newer version of make (there was
a silent update in 2012, my version is 5.06).
Well if you don't set VCDIR you won't get proper include paths.
So no clue why it works for you.
The pdb debug format is not supported, AFAIK. But that format
is not documented and I don't think you could add D extensions
anyway.
So does LLVM really support PDB?
As long as they rely on the MS linker they only need to emit
proper debug info into the object files. But that's still TODO:
Any other good blog posts / social media comments / pointers I
can digest and use?
http://planet.dsource.org
Digger is awesome. Have never heard of it before this talk.
Unfortunately it's a huge PITA to get a Win64 build with it cause
of those stupid hardcoded \Program Files (x86)\Microsoft Visual
Studio 10.0\VC paths. The modified makefiles etc are always
reverted by Digger before building.
You can add the compiler to the make command line with some
magic quoting.
My build script calls
druntime:
make -f win64.mak DMD=../windows/bin/dmd.exe
CC=\c:\l\vc10\bin64\cl.exe\ target
phobos:
make -f win64.mak DMD=../windows/bin/dmd.exe
CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make
Can you reproduce this?
Any news on this?
Somebody (I think bearophile) mentioned a while back that they
had a folder with all the D solutions from Rosettacode.
Yeah that would indeed be nice to have.
http://youtu.be/Es8st0E5428
Thx alot!
Enables me to watch it easily on my tv :)
http://youtu.be/n9RNxUQ0Cyk
If you have
immutable int[] arr = [0,1,0,3];
Couldn't the type of the literal be inferred as immutable?
Then you could put the data into read-only memory, and maybe even
elide the copy to the heap?
The immutable arr type is even passed to
ArrayLiteralExp::inferType but doesn't influence the
By the way, LDC already does this today (even without
optimizations turned on).
My ldc doesn't.
I had to cast(immutable) to actually get it to put the data as a
constant.
And even then it's still copied to the GC heap.
auto foo() {
immutable int[] arr = [0, 1, 0, 3];
return arr;
}
---
produces (with optimizations on, but just for brevity)
---
define { i64, i32* } @_D4test3fooFZyAi() #0 {
ret { i64, i32* } { i64 4, i32* getelementptr inbounds ([4 x
i32]* @.immutablearray, i32 0, i32 0) }
}
---
And
private immutable int[] aaa = [0,1,2,3,4,5,6,7];
int foo() pure nothrow
{
int sum;
foreach (int i; aaa)
sum += i;
return sum;
}
@_D5immut3aaayAi = constant { i64, i32* } { i64 8, i32*
getelementptr inbounds ([8 x i32]* @.constarray, i32 0, i32 0) }
http://forum.dlang.org/thread/pxotrowaqcenrpnnw...@forum.dlang.org
Is there a way to disable exceptions with MSVC like
-fno-exceptions for GCC to help get rid of the associated false
positives?
Sure, no /EHsc and /D_HAS_EXCEPTIONS=0 for its STL.
The only question I have is what happens when you use
SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher)
and the program runs on something older?
WinXP is dead :)
On Monday, 16 June 2014 at 01:23:28 UTC, Daniel Murphy wrote:
Trass3r wrote
Is there any good reason to catch that?
I really want the debugger to fire up.
I know, I hate this. You can disable it by changing
rt_trapExceptions in dmain2.d in druntime to false and
rebuilding druntime, which
I think it should be possible to run DustMite on some big project
like phobos to actually search for such internal errors.
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
Win7 x64
It is default windows runtime behavior
Yeah but couldn't/shouldn't it let breakpoints through?
On Thursday, 26 January 2012 at 01:06:46 UTC, Trass3r wrote:
When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?
Does
Is there any generic D image processing library similar to
Adobe's boost::GIL?
On Saturday, 1 February 2014 at 19:28:54 UTC, Andrej Mitrovic
wrote:
On 2/1/14, Paulo Pinto pj...@progtools.org wrote:
Shouldn't those makefiles use Windows only tools?
Those makefiles should be just one makefile that works across
platforms by using GNU Make, but some people love the idea of
On Sunday, 18 August 2013 at 18:35:45 UTC, Russel Winder wrote:
https://github.com/Trass3r/cl4d
I had missed that as well. Bad Google and GitHub skills on my
part clearly.
I think the path is now obvious, ask if the owner will turn this
repository over to a group so that it can become
Has anyone ever created a CMakeLists.txt for the dmd source?
Do you need help?
..and thus already has a working splitter?
compiled with:
dmd hello.d
rdmd hello.d
dmd: glue.c:542: virtual void FuncDeclaration::toObjFile(int): Assertion
`semanticRun == PASSsemantic3done' failed.
Aborted
wouter@carillon:~/code/d/DustMite$
... and I'm not yet that fluent in D to understand what's going on. Any
ideas?
pass dustmite.d before dsplit.d
known problem, but the
... the order of files matters? Yuck.
Yep it's a bug.
1) Currently the patches that Walter applies written by other people
come mostly from the most recent ones. I think this is not good.
Yep, github's default sort method sucks.
They should really implement some sort of voting scheme or something like
a ready to merge button for prolific
A notice for some unused imports would be great too...
You could create a brute-force tool.
Rip off an import statement at a time and see if it still compiles.
One could probably modify DustMite to do that.
Object generation is an unholy disaster of IFDEF's and my brain has
melted
every time I try to venture into it
Funnily enough, cppcheck shares your opinion on the backend: Interrupted
checking because of too many #ifdef configurations
http://trass3r.github.com/dmd-cppcheck/
Seems like the tool isn't dead after all so I tried it out with the dmd
sources.
Some false positives but also some valid points.
E.g. http://trass3r.github.com/dmd-cppcheck/15.html#line-960 looks
particularly interesting.
There are surprisingly few notices of memory leaks considering DMD uses
a GC.
This is news to me. Has the GC been re-enabled?
http://trass3r.github.com/dmd-clang/
I think in general fixing cppcheck's complaints makes the code more
understandable and maintainable, even if it doesn't actually fix
anything.
+1
This is news to me. Has the GC been re-enabled?
No, it's just that cppcheck doesn't (and cannot) detect global memory
leaks - only very localized ones.
btw, what is the stance on adding some manual memory freeing, at least for
obvious local leaks?
1) D Inline Asm and naked function support is raising far too many alarm
bells. So would just be easier to remove it and avoid all the other
comments on why we need middle-end and backend headers in gdc.
And the C++ frontend doesn't need these headers for its inline assembler
Plus, gcc asm syntax is horrible, and DMD's is really nice.
yep, ATT vs. Intel syntax :)
Please be informed that GCC inline asm supports Intel syntax...
With -masm=intel.
Does this somewhat vague statement meant that we are getting COFF
support in the near term?
Yes, because that is necessary for MSVC linker compatibility.
Hooray!
If you want to convert a range to an array, use std.array.array
This is a constant source of confusion and it also is a crappy design to
use a function in a totally different module for this purpose imho.
Can't these Result types get an eval() method and/or be made implicitly
convertible to
test code please
import std.stdio, core.simd;
void main()
{ int4 v;
}
Internal error: ..\ztc\cgcod.c 1447
Building Debug\dtest1.exe failed!
Works fine on Linux.
Maybe the 32Bit check doesn't work for Windoze?
-m32 on Linux yields Error: SIMD vector types not supported on this
platform
I think it has been fixed for the next version of DMD already. Any idea
why align isn't letting me use movdqa?
Cause align doesn't work the way you think it does.
In fact I still don't understand how it works at all.
1 - 100 of 1242 matches
Mail list logo
