Received: by 10.180.106.3 with SMTP id gq3mr3712671wib.1.1342043221600;
        Wed, 11 Jul 2012 14:47:01 -0700 (PDT)
X-BeenThere: ldc-dev@googlegroups.com
Received: by 10.180.103.170 with SMTP id fx10ls7217783wib.0.canary; Wed, 11
 Jul 2012 14:47:00 -0700 (PDT)
Received: by 10.180.24.202 with SMTP id w10mr3138518wif.0.1342043220127;
        Wed, 11 Jul 2012 14:47:00 -0700 (PDT)
Received: by 10.180.24.202 with SMTP id w10mr3138517wif.0.1342043220117;
        Wed, 11 Jul 2012 14:47:00 -0700 (PDT)
Return-Path: <da...@klickverbot.at>
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174])
        by gmr-mx.google.com with ESMTPS id a5si4833484wiy.0.2012.07.11.14.46.59
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 11 Jul 2012 14:46:59 -0700 (PDT)
Received-SPF: pass (google.com: domain of da...@klickverbot.at designates 209.85.212.174 as permitted sender) client-ip=209.85.212.174;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of da...@klickverbot.at designates 209.85.212.174 as permitted sender) smtp.mail=da...@klickverbot.at; dkim=pass header...@klickverbot.at
Received: by mail-wi0-f174.google.com with SMTP id hr14so4901826wib.3
        for <ldc-dev@googlegroups.com>; Wed, 11 Jul 2012 14:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=klickverbot.at; s=gapps;
        h=sender:from:to:subject:date:message-id:in-reply-to:references
         :mime-version:content-type:content-transfer-encoding:x-mailer;
        bh=YdvJn8uEwrRMVs226ELcnI1lZiCdBTR5Ha8amwhdadY=;
        b=Aha4moack2FiwA61KVfLrH8mHXl7cnPogcPR2+pkQQLonUXUtPjCCBlIWLHJpLXiNM
         iJQ1pKi4s6q9MqCGiJCPaiuS4/LZ0v636/5v0dey+6Ba8RaClEGDmEXlFZikEdaclxxp
         0DS1fPDxCc8+ia9s0Kxrj7eOMEBuAuy6yS+Uc=
Received: by 10.217.1.79 with SMTP id m57mr1327777wes.121.1342043219570;
        Wed, 11 Jul 2012 14:46:59 -0700 (PDT)
Return-Path: <da...@klickverbot.at>
Received: from [192.168.1.46] (132-218.203-62.cust.bluewin.ch. [62.203.218.132])
        by mx.google.com with ESMTPS id fb20sm8055611wid.1.2012.07.11.14.46.58
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 11 Jul 2012 14:46:59 -0700 (PDT)
Sender: David Nadlinger <m...@klickverbot.at>
From: "David Nadlinger" <da...@klickverbot.at>
To: ldc-dev@googlegroups.com
Subject: Re: [ldc-dev] Some initial ARM patches
Date: Wed, 11 Jul 2012 23:46:58 +0200
Message-ID: <219163EA-D4FC-4424-BB27-FD1257D3D...@klickverbot.at>
In-Reply-To: <CAEnAdhYi_EgDsrBGQg4LR5zYVMZjv4Gjptq8sEMV=uRCbXB...@mail.gmail.com>
References: <CAEnAdha25SKNE7pO=wQR9T1hkHWbcmf9F1ukTYBjLbuSpAh...@mail.gmail.com> <CAEnAdhYi_EgDsrBGQg4LR5zYVMZjv4Gjptq8sEMV=uRCbXB...@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate Trial (1.4.2r2818)

On 8 Jul 2012, at 3:29, Alex R=C3=B8nne Petersen wrote:
> OK, first of all, this pull request should be merged:
> https://github.com/ldc-developers/ldc/pull/137

Done.

> Now, GitHub is really dodgy about this and doesn't let me send a pull
> request to ldc-developers/druntime|phobos because my repos are forked
> off the DPL ones. Even when I explicitly tell it to base on the
> ldc-developers repos, it won't let me update the commit range.

Did you change the branch on the left side to "ldc" (we have no master =

branch in the ldc-developers fork to prevent confusion)? The user =

experience for that page indeed leaves a lot to be desired =E2=80=93 we s=
hould =

bug the GitHub guys about this.

> So, please just pull these branches:
>
> * https://github.com/alexrp/druntime/tree/ldc-master
> * https://github.com/alexrp/phobos/tree/ldc-master

Merged most of the patches verbatim, removing the added .diff files from =

the register popping patch [1].

I didn't merge the _d_newarrayOpT commit [2] though, because the code =

would be broken on non-x86 afterwards anyway (ap2 is never set). After a =

quick look at the code, I think right fix is to just take the X86 branch =

for LCD all the time, although I'm not quite sure why ap2 is reset every =

time in the loop on X86_64. Unfortunately, I can't look into verifying =

that this is indeed the correct solution right now (i.e. that it works =

on X86_64), but I didn't want to merge a patch which silently leaves =

other platforms in a broken state.

Thanks again for your work,
David


[1] =

https://github.com/alexrp/druntime/commit/6e61b4645ff3ad3f9b47988caa786be=
0892af9c9
[2] =

https://github.com/alexrp/druntime/commit/717613ef2b42774fb2b40c360c80ad8=
09d63c007=