New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use travis-ci build matrix to test different compilers #901

Merged
merged 6 commits into from Dec 20, 2014

Conversation

Projects
None yet
6 participants
@MartinNowak
Contributor

MartinNowak commented Nov 21, 2014

  • fixes #734
  • dmd-2.065.0, dmd-2.066.1, ldc-0.14.0, gdc-4.9.0
use travis-ci build matrix to test different compilers
- fixes #734

- dmd-2.065.0, dmd-2.066.1, ldc-0.14.0, gdc-4.9.0
@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Nov 21, 2014

Contributor

DMD-2.066.1 is the only one passing right now.
I get ICEs for everything else (@klickverbot, @ibuclaw).

Contributor

MartinNowak commented Nov 21, 2014

DMD-2.066.1 is the only one passing right now.
I get ICEs for everything else (@klickverbot, @ibuclaw).

@ibuclaw

This comment has been minimized.

Show comment
Hide comment
@ibuclaw

ibuclaw Nov 21, 2014

I use gdc to build gdcproject.org, so either the download version is missing a bugfix I did for vibe.d (which means someone needs to build new binaries), or there is a new change to vibe.d master that causes an ICE - maybe a change that is 2.066.1 specific?

ibuclaw commented Nov 21, 2014

I use gdc to build gdcproject.org, so either the download version is missing a bugfix I did for vibe.d (which means someone needs to build new binaries), or there is a new change to vibe.d master that causes an ICE - maybe a change that is 2.066.1 specific?

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Nov 21, 2014

Contributor

Quick question out of context, how do you deal with druntime's Borland inline assembly in gdc? I'm looking forward to maintaining vibe.d compatibility eventually and fibers require some asm magic so I'm a bit puzzled at how you manage to get them working without Borland asm support

Contributor

etcimon commented Nov 21, 2014

Quick question out of context, how do you deal with druntime's Borland inline assembly in gdc? I'm looking forward to maintaining vibe.d compatibility eventually and fibers require some asm magic so I'm a bit puzzled at how you manage to get them working without Borland asm support

@klickverbot

This comment has been minimized.

Show comment
Hide comment
@klickverbot

klickverbot Nov 21, 2014

Contributor

LDC 0.14.0 definitely will not pass for frontend reasons if DMD 2.065 doesn't either. I've also fixed a few LDC codegen bugs that affected vibe.d a while back, and they aren't in the 0.14 releases yet. The 0.15.0 beta should build vibe.d master from a month ago or so; haven't checked the tests since.

Contributor

klickverbot commented Nov 21, 2014

LDC 0.14.0 definitely will not pass for frontend reasons if DMD 2.065 doesn't either. I've also fixed a few LDC codegen bugs that affected vibe.d a while back, and they aren't in the 0.14 releases yet. The 0.15.0 beta should build vibe.d master from a month ago or so; haven't checked the tests since.

@ibuclaw

This comment has been minimized.

Show comment
Hide comment
@ibuclaw

ibuclaw Nov 23, 2014

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

ibuclaw commented Nov 23, 2014

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Nov 23, 2014

Contributor

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

Do you mean GCC-inline assembly? Could you point me to the relevant source code from GDC?

Contributor

etcimon commented Nov 23, 2014

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

Do you mean GCC-inline assembly? Could you point me to the relevant source code from GDC?

@ibuclaw

This comment has been minimized.

Show comment
Hide comment
@ibuclaw

ibuclaw Nov 23, 2014

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

Do you mean GCC-inline assembly? Could you point me to the relevant source code from GDC?

This is what currently happens on Linux (and all other Posix thread compliant systems): https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/thread.d#L3355

This is where the replaced assembly will end up being located to: https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/threadasm.S#L415

ibuclaw commented Nov 23, 2014

@etcimon - by the time I get round to 2.066 update, it'll be written in assembly (as opposed to inlined in D code). Ucontext is the current workaround on Linux, but bloats the size of Thread.

Do you mean GCC-inline assembly? Could you point me to the relevant source code from GDC?

This is what currently happens on Linux (and all other Posix thread compliant systems): https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/thread.d#L3355

This is where the replaced assembly will end up being located to: https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/threadasm.S#L415

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Nov 23, 2014

Contributor

This is where the replaced assembly will end up being located to: https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/threadasm.S#L415

According to my research, the GDC inline assembly could also be used for LDC if it were inline GCC rather than a .S file.

I'm still unsure about why the druntime/phobos library for each compiler couldn't simply be merged in the official repository with version tags. If it were outlined as an objective, I suppose it would be less time consuming to maintain it, because every compiler would be supported directly in the druntime/phobos repo for each version increments.

I think my work on SIMD would be a proper example for what I mean: https://github.com/etcimon/botan/blob/master/source/botan/utils/simd/emmintrin.d

In this case, each compiler version is covered in the module, no need for a separate makefile. It should be this way for most parts of the official druntime, or am I missing something?

Contributor

etcimon commented Nov 23, 2014

This is where the replaced assembly will end up being located to: https://github.com/D-Programming-GDC/GDC/blob/99c2f902471889528f96aa89d3f5b28598843078/libphobos/libdruntime/core/threadasm.S#L415

According to my research, the GDC inline assembly could also be used for LDC if it were inline GCC rather than a .S file.

I'm still unsure about why the druntime/phobos library for each compiler couldn't simply be merged in the official repository with version tags. If it were outlined as an objective, I suppose it would be less time consuming to maintain it, because every compiler would be supported directly in the druntime/phobos repo for each version increments.

I think my work on SIMD would be a proper example for what I mean: https://github.com/etcimon/botan/blob/master/source/botan/utils/simd/emmintrin.d

In this case, each compiler version is covered in the module, no need for a separate makefile. It should be this way for most parts of the official druntime, or am I missing something?

MartinNowak added some commits Nov 30, 2014

workaround Issue 13194 in 2.065 compiler
- ICE when initializing static class members to void

- the static variable would probably end up in the binary
  even though it was only used to check for a property

https://issues.dlang.org/show_bug.cgi?id=13194
workaround ICE in ldc-0.14.0
- ldc segfaults while building a nested context for ClientTask.execute
  function (not sure why it does build a context)

- apparently fixed in ldc-0.15.0-beta1
workaround GDC issue with undefined lambda
- the lambda is emitted to libvibe-d.a but only
  as local symbol (small t in nm)

- fixed by templatizing the auto function
  (lambda is generated on first call)
@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Dec 1, 2014

Contributor

I added workarounds for the different compilers, ready to merge now.
Might be worth to do a point release @s-ludwig.

Contributor

MartinNowak commented Dec 1, 2014

I added workarounds for the different compilers, ready to merge now.
Might be worth to do a point release @s-ludwig.

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Dec 2, 2014

Contributor

Wonderful !
Do you think we should build on DMD master as well, or is it too unstable ?

Contributor

Geod24 commented Dec 2, 2014

Wonderful !
Do you think we should build on DMD master as well, or is it too unstable ?

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Dec 2, 2014

Contributor

Do you think we should build on DMD master as well, or is it too unstable ?

There are no binary releases and it's fairly unstable both from dmd's and vibe.d's site (e.g. the new std.concurrency.Scheduler isn't really finished).

Contributor

MartinNowak commented Dec 2, 2014

Do you think we should build on DMD master as well, or is it too unstable ?

There are no binary releases and it's fairly unstable both from dmd's and vibe.d's site (e.g. the new std.concurrency.Scheduler isn't really finished).

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Dec 3, 2014

Contributor

@ibuclaw :

I use gdc to build gdcproject.org, so either the download version is missing a bugfix I did for vibe.d (which means someone needs to build new binaries), or there is a new change to vibe.d master that causes an ICE - maybe a change that is 2.066.1 specific?

I guess you used dub build. It works fine. What triggers a SEGV is dub test --compiler=gdc (tested with 4.9.0 and 4.9.2).

Contributor

Geod24 commented Dec 3, 2014

@ibuclaw :

I use gdc to build gdcproject.org, so either the download version is missing a bugfix I did for vibe.d (which means someone needs to build new binaries), or there is a new change to vibe.d master that causes an ICE - maybe a change that is 2.066.1 specific?

I guess you used dub build. It works fine. What triggers a SEGV is dub test --compiler=gdc (tested with 4.9.0 and 4.9.2).

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Dec 15, 2014

Contributor

Updated to use travis-ci's D support.
Would be @s-ludwig to get this merged and out in a new point release as 0.7.21 is only usable on dmd-2.066.1.

Contributor

MartinNowak commented Dec 15, 2014

Updated to use travis-ci's D support.
Would be @s-ludwig to get this merged and out in a new point release as 0.7.21 is only usable on dmd-2.066.1.

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Dec 16, 2014

Contributor

LDC 0.15.1 is out with 2.066.1 support. Could it be added to the build matrix ?

Contributor

Geod24 commented Dec 16, 2014

LDC 0.15.1 is out with 2.066.1 support. Could it be added to the build matrix ?

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak Dec 20, 2014

Contributor

Could it be added to the build matrix ?

Done

Contributor

MartinNowak commented Dec 20, 2014

Could it be added to the build matrix ?

Done

s-ludwig added a commit that referenced this pull request Dec 20, 2014

Merge pull request #901 from MartinNowak/travis-ci
Use travis-ci build matrix to test different compilers

@s-ludwig s-ludwig merged commit f419478 into vibe-d:master Dec 20, 2014

1 check failed

continuous-integration/travis-ci The Travis CI build failed
Details

@MartinNowak MartinNowak deleted the MartinNowak:travis-ci branch Dec 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment