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=QbJVomh4blxTfWBR3pRLus46ZuGS95BJqwfv7FEHM98=; b=Tby176GtpOMRSpORgKr6V1KnCnbMR9cfmuY+PAOl9kq3nhdH/LiLlKwylP9NvM+1ty aNH81XZUHjQxOcBS0U9cVKd03cDoJuwNAVbRWUY1Oa06ofKtos9Pb/yumHUm7g9v/FXI Z75CgVCHWaWhZTq+Y2wjTsimGT+MUrBKLGYmO+nu4zumG5TQ57V0EF5LR6hU2Z/XZtOe kaxwHqyUMMPwRsFR8p04dQorhza/bw2//wVqCOltWRLXL0GAQdm7ZEuzMP6SZhrKXgF1 UWj+Wk/Ha9mLfz/LGuDDwkHQ7SEVNgQwf4UqoMCmscDkf41DREh+VP590no88mmRZ2GD uIjQ== 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=QbJVomh4blxTfWBR3pRLus46ZuGS95BJqwfv7FEHM98=; b=GV2fUpfcyNGGn9d6fBMJC0eXmVYb4A2w2tFbucRJCWVGL28U8/RIVrdVZ/KY6PW0XL wN2GPooJbZJdn58FBMdYiNR3RL2KbsSDZW5Zw0pyrgEZlB/XsvM9elmQYBlnOJVhxdjP fPvfteGuZUGqEbPXkySpvoc9jovA1TBt9k4XrpDcmSt1y+x110rLDpfkF2yNjNaCiI58 LmihnPPu2xsxiGJvftouS6fYJ79pb5P2XLJBTz3BY+Ju2fsPeFgsInZrQsA8PsVtCwth Ehnou/CZCFnB/9Y9iOizoSNH+U0fZFiC0WgP+TLQWcLwp7jcDtVPA6DfHKB3JfD2PZAS apoQ== X-Gm-Message-State: AFeK/H0wivx+/cBpFClsDniFK9HTSXqe/HvDpDLzfK6cclewaxiSa3ACn1hZqFbivA52SYOfYQ2b+mhJGXa7Nw== X-Received: by 10.36.91.142 with SMTP id g136mr6009572itb.52.1489295740276; Sat, 11 Mar 2017 21:15:40 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References:

From: "Louis Santillan (lpsantil AT gmail DOT com) [via djgpp AT delorie DOT com]" Date: Sat, 11 Mar 2017 21:15:39 -0800 Message-ID: Subject: Re: BUG: djgpp should allow 16-byte alignment To: "djgpp AT delorie DOT com" Content-Type: multipart/alternative; boundary=001a11410e909098fb054a81af06 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 --001a11410e909098fb054a81af06 Content-Type: text/plain; charset=UTF-8 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] 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] 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. > > --001a11410e909098fb054a81af06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Have you tried using `-mstackrealign`?=C2=A0 That might corre= ct the errors you are seeing.=C2=A0 Without seeing any code, it's hard = to say what's going on.=C2=A0 Looking at BZ, I see the code there but n= o 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@= gmail.com) [via djgpp AT delorie DOT com<= /a>]=C2=A0 wrote:
> Are you unable to use `--mstackrealign`, `-mpreferred-stack-boundary= =3Dnum`, `-mincoming-stack-boundary=3Dnum` [0]?=C2=A0 Looks like = you'll also need to force those options if you compile with `-Os` as we= ll.
>
>
>
>
> [0] https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-6= 4-Options.html#i386-and-x86-64-Options=C2=A0=C2=A0
>
>
> 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. Sinc= e djgpp-compiled programs can potentially use SSE instructions (either expl= icitly or implicitly, when compiled with -march=3Dpentium3), I do think thi= s should be supported.
>
>
>
> previous discussion:
>
> > https://gcc.gnu.org/bugzilla/show= _bug.cgi?id=3D79935

I was already using -mpreferred-stack-boundary=3D4 (which implies -m= incoming-stack-boundary=3D4) 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 =3D= =3D 0x0c). That doesn't make any sense at all! It's guaranteed to c= ause a GP fault and gcc should know this.

--001a11410e909098fb054a81af06--