From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=nuMU=7M=suse.de=rguenther@sourceware.org>
Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c])
	by sourceware.org (Postfix) with ESMTPS id 292293858C74
	for <gcc-patches@gcc.gnu.org>; Mon, 20 Mar 2023 10:59:59 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 292293858C74
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
	by smtp-out1.suse.de (Postfix) with ESMTP id 1E2D021B70;
	Mon, 20 Mar 2023 10:59:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1679309998; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=MpCYJUszwO0UbhlAJG1IPspzIbKgzGpPCHUEQPaEteA=;
	b=LU+aZrXecANglWskluMg4Pfra1dLgT827D1567AM7aSq945PjRbRuXcQsPRksiW537kAjp
	7UfXC3SzjQNZIr8/4HN0NGrektkTUo21SDVM4ods7HhFG9Lx0n2ie8h7OPDTAqxlpcW0f0
	GgndZy1GCACWg5ws6/XNVbWbtqOiWR4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1679309998;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=MpCYJUszwO0UbhlAJG1IPspzIbKgzGpPCHUEQPaEteA=;
	b=6xVeZ1gUrhmK97GL29cGeB/FF5wVJWsHrGcNizHg3gI8vNSi1f+mTP5e9mnulPiEkLZXO5
	chBFpavMegImLVDw==
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by relay2.suse.de (Postfix) with ESMTPS id 126B82C141;
	Mon, 20 Mar 2023 10:59:57 +0000 (UTC)
Date: Mon, 20 Mar 2023 10:59:57 +0000 (UTC)
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] New testcase
In-Reply-To: <ZBgyRKFDWHiF2HA+@tucnak>
Message-ID: <nycvar.YFH.7.77.849.2303201059460.18795@jbgna.fhfr.qr>
References: <20230314072924.C1A34385840C@sourceware.org> <ZBgyRKFDWHiF2HA+@tucnak>
User-Agent: Alpine 2.22 (LSU 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

On Mon, 20 Mar 2023, Jakub Jelinek wrote:

> On Tue, Mar 14, 2023 at 07:29:19AM +0000, Richard Biener via Gcc-patches wrote:
> > This is a reduced testcase for an issue I ran into when trying to
> > improve PTA compile-time further, there wasn't any C family runfail
> > in the testsuite for this.
> > 
> > Pushed.
> > 
> > 	* g++.dg/torture/20230313.C: New testcase.
> 
> I've noticed this testcase FAILs on i686-linux with
> -fstack-protector-strong.
> 
> sizeof (auto_vec<int, 8>) == 16, which in this case contains
> 4-byte m_vec (which points to to m_auto), then 8-byte m_auto
> which contains just 8-byte m_vecpfx and finally 1 byte m_data,
> rest is padding.  We then try to push 2 ints to it, so 8 bytes,
> starting at the end of m_vecpfx aka address of m_data, but there
> is just 1 byte + 3 bytes of padding.
> In the lp64 case, I think sizeof (auto_vec<int, 8>) == 24,
> because there is 8-byte m_vec, 8-byte m_vecpfx and 1-byte m_char
> all with 8-byte alignment.
> 
> Can we just change
> --- gcc/testsuite/g++.dg/torture/20230313.C.jj	2023-03-14 12:24:55.930723588 +0100
> +++ gcc/testsuite/g++.dg/torture/20230313.C	2023-03-20 11:11:55.009044518 +0100
> @@ -60,7 +60,7 @@ struct auto_vec : vec<T, va_heap>
>      this->release ();
>    }
>    vec<T, va_heap, int> m_auto;
> -  char m_data;
> +  char m_data[2 * sizeof (int)];
>  };
>  template<typename T>
>  struct vec<T, va_heap>
> 
> or does it go against what the testcase wants to verify?

That should be fine.

Thanks,
Richard.