From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 5CD35385803E for ; Thu, 30 Nov 2023 12:16:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CD35385803E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5CD35385803E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::132 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701346605; cv=none; b=OCLP6PmOZkpQTecBPtocxddNes1Ct8HH15R9Fd1HUicX7K0AFsyfzpcI3aRM0msmTUtStC+i3EVk8UaR2VuiD55olxQXyCFkMFZuTMX+vYMzwwOqTvqqcmSWxpuXan3BhFJZsCxzzU8tY6DvhoUAEk+6Jer9HW4WWOOnDdNfobo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701346605; c=relaxed/simple; bh=7tJDFfSPBhPIheoHFWwVYmZlkCBXG8MiUFJLo3Ke8/o=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=EnTeUv14DI2bV6hv3pDQQVZhLqrQdhzLu+USlcSfnAyidEqxNjfYfjpuOIVnwJd/BwMVMAz2QDz1ODTTS7VmhOL9Kp4954P8DU3OKKLuYQS7zjbHI2LJn7AOpDo5XyhnWgthjIEbfBOw4kADx/cKxViH0swEKWvBse9sKAvcBiE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-50bba1dd05fso1277511e87.0 for ; Thu, 30 Nov 2023 04:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701346602; x=1701951402; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9yoOWMnzFKnJf7r1Kak0y7iPoYIM6djtNSdqJNpMrdw=; b=VDO4VvfIQ+L8sbRMl9qrsbTNg3qKv+HkNuDO69ZlVweKcqQoxhE2Y7AJUu6r8QEdyV x+3+6jI1j/lWUENXeGIJd1UrrANAJavznnWzGoWVQ/4mZwL0PnXWgyC6EEECVqxaxpeV uVSGl5FPm7dNvWaSv9CkT0NSKht5Z0reWfcdardl3souMnuxlIOLZ2QaFurCMR/mNvnk 5Iuu5x1tHl6gGFLlESK5ZtaCSxI3nh69h3+fIOut80fWldr9ByxrTjHI79Yq4o3puMNh vE1NLkmWsD/k4HCsaYRaQHV4ot82gU+957eGFPubdcamlcQLMDeivIp5rd4AOchNJcYQ Ic5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701346602; x=1701951402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9yoOWMnzFKnJf7r1Kak0y7iPoYIM6djtNSdqJNpMrdw=; b=OAUg1S4AKNAqOTRSKVpS19oLgiOp5Hi69Cqn7EiAbRveC0HdqNZLQj0oQMK1a5U1Pj oum7Zfg5C4GImpz8+RUANYnpXHOijJ3/AmB1fHM3FyD7s+JuVE4aE5uKEUszlSEkcC08 U2catAlWaniwk/GAcynIayCGHVewbPZZI4X0v9pHixxn9fJ1LqkE5FmxfEVzP5ft5+em xXJMiQLDg5I/iYgof59uOAFF3mxVIjpDfDBy6Da1y9EiRWLGnU9TA3MXu7W0zKinyGXx BXO8bPiiUVB0G2ZrHE0SuFGoygN8XlouOHJmlxyaxKZd0YV4MXvMbNkM2RVz72tfnYjH vkEA== X-Gm-Message-State: AOJu0YzpyvHqTlclf38Ipkt7ovVi/osPTCQ/okjg7przSNo2IxwGI8fj SOqvvQwIDcABCKm/tU7HRrDI2QoFonotMhY97gKED5Ls X-Google-Smtp-Source: AGHT+IFV6xX7/H76icZOpIfUs8itjW5rxEhZe7OVQIJ7k1e15Yt11JHz1hN3swrA/lt04I0i3UlbDhnMS8z3q8FiuNw= X-Received: by 2002:a05:6512:398a:b0:50b:c80f:88ec with SMTP id j10-20020a056512398a00b0050bc80f88ecmr3442478lfu.18.1701346601630; Thu, 30 Nov 2023 04:16:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 30 Nov 2023 13:12:51 +0100 Message-ID: Subject: Re: Unjustified optimization due to restricted struct members? To: Ties Klappe Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Thu, Nov 30, 2023 at 12:07=E2=80=AFPM Ties Klappe via Gcc wrote: > > When reading section 6.7.3.1 of the C standard (quoted below) about > the *restrict > *type qualifier, the first section talks about *ordinary identifiers*. > These are defined in section 6.2.3, and exclude members of structures. > > Let D be a declaration of an ordinary identifier that provides a means of > > designating an object P as a restrict-qualified pointer to type T. > > > I would assume that this means that in the code excerpt below the functio= n > *h* cannot be optimized by substituting the load of *b.p *for *10*, as th= e > standard does not specify what it means for a struct member to be restric= t > qualified. However, the code is still optimized by gcc (but not Clang), a= s > can be seen here: https://godbolt.org/z/hEnKKoaae > > struct bar { > int* restrict p; > int* restrict q; > }; > > int h(struct bar b) { > *b.p =3D 10; > *b.q =3D 11; > return *b.p; > } > > Was this a deliberate choice, or does it simply follow from how restrict = is > supported in gcc (and could this be considered a bug w.r.t. the standard)= ? Hmm, this was a deliberate choice (it also works for global 'b'), I didn't = think the standard would exclude that. Note GCCs C++ standard library makes use of restrict qualified pointers as structure members for example. Richard.