X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
        bh=4DFCgrEmR5a2vqEkwjfySZ3cOdTY15U8LI37U7WoDoM=;
        b=KmVpHCpHakAwdfIi0QybA9BjWH4eSO5qURqE3URCtAoMzSCrZjI54xCCXE/gTI5Acf
         Wq7gFf+u/bWJ/IxL9262fTsEqQmk7iDEKCrQOUksk7NUMn2TShTojvl4nrwMOpgxO8IK
         CuQ51Wyndpg9USgK7qMtM8j7qL1kl1yoq6IiwiTYm6tGBhKNqtw2B4T/sNe+KLL2RzmT
         Eag8R2xi0zbBcEsC71bmnkPPQavOFAGVPo40b+9KYaAC1nHm/0kfhy3oNG5Co0my+SKe
         zFZk+qTGmVW8Hf1I2qyf+0S1s8KSNfUBK+cnZ9+0KZbYcSLiE8Z4lLnWPGN+wn2lK/D+
         qi6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to;
        bh=4DFCgrEmR5a2vqEkwjfySZ3cOdTY15U8LI37U7WoDoM=;
        b=VZpAS1Nu7kR7SqtnHX6HnKRK9eUNjE4PfbXlSppVRRErCszAc2SNNd+Yf3uOh4HKOo
         8CLePcmtzuylaG855k6+++VXcNHAW/g36bwFDGk10uEALb7wfuDr9sNksi7kP2YzlVjS
         FkzcTb98ILHw1YbTW44rx3SlscLHHIxKAZypaIVstRvRxNZ1TFCb1z5NlsvttTVZXZg0
         LWPV04hfEGb/bvhIBAShguUFclDTKjifNYMr5vQRRsKiSel4+pw5lYb27/qbPwlWSXb+
         Bai/JVF3/yqCDARlHbn2gfGK5XgbuHn/0nA41MNdN7kwkdvDAoBiVWng23KxjJYg37k7
         79Rw==
X-Gm-Message-State: AFeK/H0AHH8QR6I8oM/AS0BrkPylT8m94WUNv5DYJM6SAYCNsb8iK19Dgg8d+31RhyBwgUVn5y4yX0gsjtEoUw==
X-Received: by 10.25.233.201 with SMTP id j70mr58036lfk.20.1489335293346; Sun,
 12 Mar 2017 09:14:53 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CAB9Rao9rmU8wSxVGYEbkWut8qdc_CtvYX620tA1nEWRbpepe9w@mail.gmail.com>
References: <a3cedf91-bd02-46a1-9f41-58a9747747b7 AT googlegroups DOT com>
 <CAB9Rao8M=6bk+2BJGsCCQVs0q_aUHwf3+6zP+aG+k4oywE3LOQ AT mail DOT gmail DOT com>
 <eaa5f75a-3128-4309-8d28-ab3a9ca1566b AT googlegroups DOT com> <CAB9Rao9rmU8wSxVGYEbkWut8qdc_CtvYX620tA1nEWRbpepe9w AT mail DOT gmail DOT com>
From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Date: Sun, 12 Mar 2017 17:14:52 +0100
Message-ID: <CAPLG5jY-E2KpB_Xsu9HRiZqLGtcOVbPOu6bR+WG+gGpV_+dsnw@mail.gmail.com>
Subject: Re: BUG: djgpp should allow 16-byte alignment
To: djgpp AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Okay thanks, I tried -mstackrealign and it seems to help in the last
case I mentioned. I don't really see how, though. It shouldn't be
necessary in the first place, since once the stack is aligned
correctly, it should stay aligned in every subsequent function call.

The GP fault I mentioned earlier occurs in the following instruction:
       60987: 0f 29 45 a8    movaps XMMWORD PTR [ebp-0x58],xmm0

Here is the entry to this function, when compiled with -mstackrealign:
    00060a74 <jw::thread::detail::scheduler::check_exception()>:
       60a74: 8d 4c 24 04   lea    ecx,[esp+0x4]
       60a78: 83 e4 f0      and    esp,0xfffffff0
       60a7b: ff 71 fc      push   DWORD PTR [ecx-0x4]
       60a7e: 55            push   ebp
       60a7f: 89 e5         mov    ebp,esp

And here is the same function, without it:
    00060918 <jw::thread::detail::scheduler::check_exception()>:
       60918: 55            push   ebp
       60919: 89 e5         mov    ebp,esp

In the first case, ebp ends up being 0x...8, while in the second, ebp
is 0x...c. In both cases however, esp at the point of the call is
correctly aligned to 0x10 bytes.

Either with or without -mstackrealign, the stack is always aligned to
16 bytes in main():
    0005ee6c <main>:
       5ee6c: 55            push   ebp
       5ee6d: 89 e5         mov    ebp,esp
       5ee6f: 57            push   edi
       5ee70: 56            push   esi
       5ee71: 53            push   ebx
       5ee72: 83 e4 f0      and    esp,0xfffffff0
       5ee75: 83 c4 80      add    esp,0xffffff80

Here's the code I'm working with, if you want to try for yourself:
https://github.com/jwt27/jwdpmi_test

On 12 March 2017 at 06:15, Louis Santillan (lpsantil AT gmail DOT com) [via
djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
> Have you tried using `-mstackrealign`?  That might correct the errors you
> are seeing.  Without seeing any code, it's hard to say what's going on.
> Looking at BZ, I see the code there but no compiler flags.
>
> On Fri, Mar 10, 2017 at 12:08 AM, jwjagersma AT gmail DOT com [via
> djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
>>
>> On Friday, 10 March 2017 00:13:25 UTC+1, Louis Santillan
>> (lpsantil AT gmail DOT com) [via djgpp AT delorie DOT com]  wrote:
>> > Are you unable to use `--mstackrealign`,
>> > `-mpreferred-stack-boundary=num`, `-mincoming-stack-boundary=num` [0]?
>> > Looks like you'll also need to force those options if you compile with `-Os`
>> > as well.
>> >
>> >
>> >
>> >
>> > [0]
>> > https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
>> >
>> >
>> > On Thu, Mar 9, 2017 at 8:14 AM, jwjag DOT  DOT  DOT  AT gmail DOT com [via
>> > dj DOT  DOT  DOT  AT delorie DOT com] <dj DOT  DOT  DOT  AT delorie DOT com> wrote:
>> > Currently it seems that djgpp does not support 16-byte alignment. Since
>> > djgpp-compiled programs can potentially use SSE instructions (either
>> > explicitly or implicitly, when compiled with -march=pentium3), I do think
>> > this should be supported.
>> >
>> >
>> >
>> > previous discussion:
>> >
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935
>>
>> I was already using -mpreferred-stack-boundary=4 (which implies
>> -mincoming-stack-boundary=4) but that didn't seem to have the intended
>> effect. Most notably in static constructors, the stack alignment is always 8
>> bytes off. From the disassembly I can tell gcc does its best to keep the
>> stack aligned, so that part works correctly, at least.
>>
>> Now yesterday I had a problem in a non-static function, where gcc inserted
>> an SSE instruction with a memory operand [ebp-0x58], with (ebp % 0x10 ==
>> 0x0c). That doesn't make any sense at all! It's guaranteed to cause a GP
>> fault and gcc should know this.
>>
>