From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 70FDD385841D; Sun, 10 Dec 2023 17:58:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70FDD385841D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1702231108;
	bh=GFNA2DrQaHtIzMU+mgeYF4ZNBvQex9FygkPD5LDqvaU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Nqt/1TQj0hSa/hnaZI1SnKg7Ja6z+oPQtI/8Lib5GcbuqkYaUu5O2WaXYsrRlmP7n
	 eOJxVKHrRMqVdMZBiss9GolliylU2uZMAfcpd66xMwgwErD1wuxo1SeR1gU1hVn/p1
	 CXwCnGtz0t2K3lEvKf15tsPCdwpRtGcBjAO9aBnY=
From: "hanno@schwalm-bremen.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with
 -mavx512f generates AVX instructions without stack alignment
Date: Sun, 10 Dec 2023 17:58:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: ABI, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hanno@schwalm-bremen.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-110273-4-zsb0R9kRuM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110273-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110273-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110273

Jens-Hanno Schwalm <hanno@schwalm-bremen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hanno@schwalm-bremen.de

--- Comment #10 from Jens-Hanno Schwalm <hanno@schwalm-bremen.de> ---
Hi, i think we found a very-similar issue in darktable code, you might look=
 at

https://github.com/darktable-org/darktable/pull/15742

In short
- reported with gcc 13.2.1, -march=3Dznver4 or using -fvect-cost-model=3Ddy=
namic

The code in question was
```
typedef struct dt_draw_curve_t
{
  CurveData c;
  CurveSample csample;
} dt_draw_curve_t;

static inline void dt_draw_curve_set_point(dt_draw_curve_t *c,
                                           const int num,
                                           const float x,
                                           const float y)
{
  c->c.m_anchors[num].x =3D x;
  c->c.m_anchors[num].y =3D y;
}


static void _generate_curve_lut( ...)
{
  ...
  dt_iop_rgbcurve_node_t curve_nodes[3][20];
  ...
     for(int k =3D 0; k < d->params.curve_num_nodes[ch]; k++)
      dt_draw_curve_set_point(d->curve[ch], k,
            curve_nodes[ch][k].x,
            curve_nodes[ch][k].y);
 ...
}
```

The relevant point here was:
even if the curve_nodes are not aligned64 the compiled code looked like

lea (%rcx, %rbx,1), %rdi
vmoaps -0x220(%rbp, %rdi,8), %ymm2
vmoups %ymm2, 0x18(%r15,%rcx,8)

forcing an alignment64 on curve_nodes fixed the problem

reporting this as one of darktable devs - no compiler expert at all - and n=
ever
reported here before. Yet this seems a bug and possibly the same are origin=
ally
reported here.=