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 days
> 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 E
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 nativ
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 y
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 version(Sy
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 tri
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 agai
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 26ed875d
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 (cd
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 fail
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
also
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 debugg
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 simply
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 file
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
chec
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 plac
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 co
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 pr
> 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 s
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 s
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 siz
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 ad
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 b
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 en
28 matches
Mail list logo
