On Friday, 7 December 2018 at 13:58:12 UTC, Dennis wrote:
> My biggest gripe is this confusing matrix of compiler flags:
>
>       default  -m32     -m32mscoff  -m64
> dmd   OMF      OMF      COFF-32     COFF-64
> ldc   COFF-64  COFF-32  Error       COFF-64

Some corrections for LDC:
* The default depends on the host. If you're using a 64-bit LDC executable, it defaults to producing 64-bit code.
* `-m32mscoff` is supported by LDMD, which is the DMD-compatible wrapper (and simply translates it to `-m32` for the LDC executable).

On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
> On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
>> Hi,
>>
>> This is mostly interesting for windows developers. What is your opinion of switching to architecture x86_mscoff or x86_64 as default on windows?
>>
>> To be pretty clear, you still can compile to x86 OMF by setting the default architecture either in settings.json or as command line argument. The proposal is just to set another default.
>>
>> This is now possible as DMD and LDC comes with lld and the needed libraries.
>>
>> Kind regards
>> Andre
>
> I'd  wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.

This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.

On Friday, December 7, 2018 3:15:30 PM MST Rubn via Digitalmars-d wrote:
> On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
> > On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
> >> Hi,
> >>
> >> This is mostly interesting for windows developers. What is your opinion of switching to architecture x86_mscoff or x86_64 as default on windows?
> >>
> >> To be pretty clear, you still can compile to x86 OMF by setting the default architecture either in settings.json or as command line argument. The proposal is just to set another default.
> >>
> >> This is now possible as DMD and LDC comes with lld and the needed libraries.
> >>
> >> Kind regards
> >> Andre
> >
> > I'd  wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
>
> This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.

The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester:

https://auto-tester.puremagic.com/

Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not?

- Jonathan M Davis

On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis wrote:
> On Friday, December 7, 2018 3:15:30 PM MST Rubn via Digitalmars-d wrote:
>> On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
>> > On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
>> >> Hi,
>> >>
>> >> This is mostly interesting for windows developers. What is your opinion of switching to architecture x86_mscoff or x86_64 as default on windows?
>> >>
>> >> To be pretty clear, you still can compile to x86 OMF by setting the default architecture either in settings.json or as command line argument. The proposal is just to set another default.
>> >>
>> >> This is now possible as DMD and LDC comes with lld and the needed libraries.
>> >>
>> >> Kind regards
>> >> Andre
>> >
>> > I'd  wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
>>
>> This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
>
> The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester:
>
> https://auto-tester.puremagic.com/
>
> Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not?
>
> - Jonathan M Davis

https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8519/3/pipeline

I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else.

What you linked are just those basic tests, those tests don't do anything complicated like building DMD itself with the newly created DMD and running the tests for both to ensure a correct binary is produced.

On Friday, December 7, 2018 8:09:37 PM MST Rubn via Digitalmars-d wrote:
> On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis wrote:
> > On Friday, December 7, 2018 3:15:30 PM MST Rubn via
> >> This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
> >
> > The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester:
> >
> > https://auto-tester.puremagic.com/
> >
> > Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not?
> >
> > - Jonathan M Davis
>
> https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8 519/3/pipeline
>
> I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else.

I think that they moved those tests to buildkite, but I don't know what the exact situation with that is right now. While the main auto-tester has been the same for ages, they keep changing what they're doing with the other tests. But I believe that the tests for each project are run using travis and depend on how each project set that up, so which which platforms they test is going to vary from project to project. And I don't think that that includes Windows at all, because that would require something like appveyor. So, the testing of projects beyond dmd and the standard library is only on *nix systems AFAIK, but dmd itself and the standard library are definitely tested on all of the platforms that dmd supports.

> What you linked are just those basic tests, those tests don't do anything complicated like building DMD itself with the newly created DMD and running the tests for both to ensure a correct binary is produced.

The new compiler is built and used to run the druntime and Phobos test suites. Then it's used with the newly built druntime and Phobos to run the dmd test suite. So, the new dmd binary is definitely being tested, but no, the newly built dmd isn't then used to build dmd yet again as part of those tests.

- Jonathan M Davis

On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
>
> Visual studio is no longer needed as lld and x86mscoff/x86_64 libraries now included in dmd and LDC:)
>
> We just need to get it mature.
>
> Kind regards
> Andre

Is it any faster than OPTLINK?

On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat wrote:
> On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
>>
>> Visual studio is no longer needed as lld and x86mscoff/x86_64 libraries now included in dmd and LDC:)
>>
>> We just need to get it mature.
>>
>> Kind regards
>> Andre
>
> Is it any faster than OPTLINK?

LLD is advertised as a very fast linker. Whether that is true I can't say, I didn't measure it.
But there should be also other benefits:
-it is actively developed by llvm community
- you do not have to convert static libs from coff to omf (e.g. SQLite,...)

Current situation is, you can't create documentation in format ddox because of an Optlink bug. This bug is known for a very long time.

Kind regards
Andre

On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat wrote:
> On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
>>
>> Visual studio is no longer needed as lld and x86mscoff/x86_64 libraries now included in dmd and LDC:)
>>
>> We just need to get it mature.
>>
>> Kind regards
>> Andre
>
> Is it any faster than OPTLINK?

I had some tries. LLD link is very fast in my applications. It feels even noticeable faster than OPTLINK.

But also I facing some maturity issues.

- While trying to run dub test in combination with dependency d-unit and a module command.d containing an std.datetime import there is always an linker error:
Native PDB Error: The entry already exists.  The specified module already exists
I have a reduced test case (dustmite is great!) and will file an issue

- From time to time there is a spurious linker error:
Error: module `NOLOGO` is in file '\NOLOGO.d' which cannot be read
I don't know how to reproduce this error but it disappears on next try.

Kind regards
André

On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
> Hi,
>
> This is mostly interesting for windows developers. What is your opinion of switching to architecture x86_mscoff or x86_64 as default on windows?
>
> To be pretty clear, you still can compile to x86 OMF by setting the default architecture either in settings.json or as command line argument. The proposal is just to set another default.
>
> This is now possible as DMD and LDC comes with lld and the needed libraries.
>
> Kind regards
> Andre

To me, it's obvious that the default on Windows 64-bit (i.e. "Windows" for 99.9% of the population) should be x86_64.

On Wednesday, 19 December 2018 at 13:11:19 UTC, Atila Neves wrote:
> On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
>> Hi,
>>
>> This is mostly interesting for windows developers. What is your opinion of switching to architecture x86_mscoff or x86_64 as default on windows?
>>
>> To be pretty clear, you still can compile to x86 OMF by setting the default architecture either in settings.json or as command line argument. The proposal is just to set another default.
>>
>> This is now possible as DMD and LDC comes with lld and the needed libraries.
>>
>> Kind regards
>> Andre
>
> To me, it's obvious that the default on Windows 64-bit (i.e. "Windows" for 99.9% of the population) should be x86_64.

I propose a smooth transition in 3 steps:

- 64 bit version of DMD should default to x86_64 instead of x86 (Optlink). I will check whether I am able to create the pr.

- an additional Windows package should be created for each release containing the 64 bit dmd version. This package should be clearly marked as experimental while the current Windows package is marked as stable.

- in some years, if 64 bit dmd and lld is proofed to be stable, either both packages can be combined into 1 or we can leave both packages but remove the experimental tag.

Kind regards
Andre