On Mon, 29 Apr 2019 at 06:11, Matthias Klose wrote:
>
> On 27.04.19 14:08, Iain Buclaw wrote:
> > On Sat, 27 Apr 2019 at 12:24, Jakub Jelinek wrote:
> >>
> >> On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote:
> >>> On 15.03.19 16:49, Robin Dapp wrote:
> during the last few
> Robin, have you been testing with --disable-multilib or something
> similar?
yes, I believe so... stupid mistake :(
Thanks for fixing it so quickly.
On 27.04.19 14:08, Iain Buclaw wrote:
> On Sat, 27 Apr 2019 at 12:24, Jakub Jelinek wrote:
>>
>> On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote:
>>> On 15.03.19 16:49, Robin Dapp wrote:
during the last few days I tried to get D running on s390x (apparently
the first Big
On Sat, Apr 27, 2019 at 02:08:06PM +0200, Iain Buclaw wrote:
> I built all compilers last night from config-list.mk, so I had a ready
> cross compiler available. With the following patch, all compiles
> successfully with -fsyntax-only for both s390x-linux and s390-linux,
> though checking on
On Sat, 27 Apr 2019 at 12:24, Jakub Jelinek wrote:
>
> On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote:
> > On 15.03.19 16:49, Robin Dapp wrote:
> > > during the last few days I tried to get D running on s390x (apparently
> > > the first Big Endian platform to try it?). I did not
On Sat, Apr 27, 2019 at 11:26:15AM +0200, Matthias Klose wrote:
> On 15.03.19 16:49, Robin Dapp wrote:
> > during the last few days I tried to get D running on s390x (apparently
> > the first Big Endian platform to try it?). I did not yet go through the
> > code systematically and add a
On 15.03.19 16:49, Robin Dapp wrote:
> Hi,
>
> during the last few days I tried to get D running on s390x (apparently
> the first Big Endian platform to try it?). I did not yet go through the
> code systematically and add a version(SystemZ) in every place where it
> might be needed but rather
On Wed, 24 Apr 2019 at 10:05, Robin Dapp wrote:
>
> Hi,
>
> the attached patch is against the current HEAD, fixing one additional
> test case.
>
Thanks, this has been committed.
> Parallel testing does not seem to work anymore. Adding the following
> define for ${PWD_COMMAND} makes it work
Hi,
the attached patch is against the current HEAD, fixing one additional
test case.
Parallel testing does not seem to work anymore. Adding the following
define for ${PWD_COMMAND} makes it work again.
diff --git a/libphobos/testsuite/Makefile.in
b/libphobos/testsuite/Makefile.in
index
On Thu, 18 Apr 2019 at 16:55, Robin Dapp wrote:
>
> Hi Rainer,
>
> > I noticed you missed one piece of Iain's typeinfo.cc patch, btw.:
> >
> > diff --git a/gcc/d/typeinfo.cc b/gcc/d/typeinfo.cc
> > --- a/gcc/d/typeinfo.cc
> > +++ b/gcc/d/typeinfo.cc
> > @@ -886,7 +886,7 @@ public:
> > if
Hi Rainer,
> I noticed you missed one piece of Iain's typeinfo.cc patch, btw.:
>
> diff --git a/gcc/d/typeinfo.cc b/gcc/d/typeinfo.cc
> --- a/gcc/d/typeinfo.cc
> +++ b/gcc/d/typeinfo.cc
> @@ -886,7 +886,7 @@ public:
> if (cd->isCOMinterface ())
> flags |= ClassFlags::isCOMclass;
>
Hi Robin,
>> This will occur on any 32-bit target. The following patch (using
>> ssize_t instead) allowed the code to compile:
>
> thanks, included your fix and attempted a more generic version of the
> 186 test.
>
> I also continued debugging some fails further:
>
> - Most of the MurmurHash
Hi Iain,
> @Rainer Orth any last requests before I commit the fix for PR
> d/89255? That will make testing individual library modules easier I
> guess.
no, the patch is perfectly fine as is. Sorry for not following up
earlier; I've now tested it successfully on Solaris 11.[345]/x86 and am
On Thu, 11 Apr 2019 at 17:43, Robin Dapp wrote:
>
> Hi Rainer,
>
> > This will occur on any 32-bit target. The following patch (using
> > ssize_t instead) allowed the code to compile:
>
> thanks, included your fix and attempted a more generic version of the
> 186 test.
>
> I also continued
Hi Rainer,
> This will occur on any 32-bit target. The following patch (using
> ssize_t instead) allowed the code to compile:
thanks, included your fix and attempted a more generic version of the
186 test.
I also continued debugging some fails further:
- Most of the MurmurHash fails are
Hi Robin,
>> Are the values inside the tables the problem? Or just some of the
>> helper functions/templates that interact with them to generate the
>> static data?
>>
>> If the latter, then a rebuild of the files may not be necessary.
>
> I managed to get this to work without rebuilding the
Hi,
> Are the values inside the tables the problem? Or just some of the
> helper functions/templates that interact with them to generate the
> static data?
>
> If the latter, then a rebuild of the files may not be necessary.
I managed to get this to work without rebuilding the files. After
Iain Buclaw writes:
> On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
>>
>> Hi,
>>
>> during the last few days I tried to get D running on s390x (apparently
>> the first Big Endian platform to try it?). I did not yet go through the
>> code systematically and add a version(SystemZ) in every
On Wed, 20 Mar 2019 at 12:27, Iain Buclaw wrote:
>
> On Wed, 20 Mar 2019 at 10:57, Robin Dapp wrote:
> >
> > Hi,
> >
> > the unicode tables in std.internal.unicode_tables are apparently auto
> > generated and loaded at (libphobos) compile time. They are also in
> > little endian format. Is the
On Wed, 20 Mar 2019 at 10:57, Robin Dapp wrote:
>
> Hi,
>
> the unicode tables in std.internal.unicode_tables are apparently auto
> generated and loaded at (libphobos) compile time. They are also in
> little endian format. Is the tool to generate them available somewhere?
> I wanted to start
Hi,
the unicode tables in std.internal.unicode_tables are apparently auto
generated and loaded at (libphobos) compile time. They are also in
little endian format. Is the tool to generate them available somewhere?
I wanted to start converting them to little endian before loading but
this will
> This would mean that StructFlags and ClassFlags will also both have a
> wrong value as well.
Yes, can confirm that m_flags = 0 (instead of 1) for a struct containing
a pointer.
> If there's a compiler/library discrepancy, the compiler should be
> adjusted to write out the value at the correct
On Tue, 19 Mar 2019 at 13:07, Robin Dapp wrote:
>
> Hi,
>
> > Alignment is written to TypeInfo, I don't think it should ever be
> > zero. That would mean that it isn't being generated by the compiler,
> > or read by the library correctly, so something else is amiss.
>
> it took me a while to see
On March 19, 2019 1:07:26 PM GMT+01:00, Robin Dapp wrote:
>Hi,
>
>> Alignment is written to TypeInfo, I don't think it should ever be
>> zero. That would mean that it isn't being generated by the compiler,
>> or read by the library correctly, so something else is amiss.
>
>it took me a while to
Hi,
> Alignment is written to TypeInfo, I don't think it should ever be
> zero. That would mean that it isn't being generated by the compiler,
> or read by the library correctly, so something else is amiss.
it took me a while to see that in libphobos/libdruntime/object.d
override @property
Hi!
On Mon, Mar 18, 2019 at 10:59:26AM +0100, Iain Buclaw wrote:
> On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
> > during the last few days I tried to get D running on s390x (apparently
> > the first Big Endian platform to try it?). I did not yet go through the
> > code systematically and
On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
>
> Hi,
>
> during the last few days I tried to get D running on s390x (apparently
> the first Big Endian platform to try it?). I did not yet go through the
> code systematically and add a version(SystemZ) in every place where it
> might be needed
Hi,
during the last few days I tried to get D running on s390x (apparently
the first Big Endian platform to try it?). I did not yet go through the
code systematically and add a version(SystemZ) in every place where it
might be needed but rather tried to fix test failures as they arose.
After
28 matches
Mail list logo
