[{"id":3678161,"web_url":"http://patchwork.ozlabs.org/comment/3678161/","msgid":"<406sqor8-n9p6-5447-77q6-958299no3r98@fhfr.qr>","list_archive_url":null,"date":"2026-04-16T13:10:26","subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Thu, 16 Apr 2026, Martin Jambor wrote:\n\n> Hi,\n> \n> when SRA propagates bit-field propagations across assignments, it\n> first attempts to use build_user_friendly_ref_for_offset to represent\n> the expression of the new accesses and a possible scalar replacement\n> so that if there are any warnings generated for it, they are as nice\n> as we can make them.\n> \n> However, this can lead to situations where, despite that the new\n> access has exactly the same type as the new old one, the new access\n> can be a bit field even though the old one spanned entire bytes, like\n> in the testcase in this patch. This trips the verifier and I guess\n> may lead to data loss in the \"padding.\"\n> \n> Since r16-7406-g538da7baf6aee0 we do not initiate propagating for\n> bit-fields and so we can just as well avoid creating any, so this\n> patch skips them when searching for a user-friendly expression. In\n> practical terms, this means that the propagated accesses have types\n> such as unsigned char and are accessed via a MEM_REF.\n> \n> Bootstrapped and tested on x86_64-linux. OK for master and all the\n> active release branches?\n\nOK.\n\nThanks,\nRichard.\n\n> Thanks,\n> \n> Martin\n> \n> \n> gcc/ChangeLog:\n> \n> 2026-04-15 Martin Jambor \n> \n> \tPR tree-optimization/124151\n> \t* tree-sra.cc (build_user_friendly_ref_for_offset): Skip\n> \tbit-fields.\n> \n> gcc/testsuite/ChangeLog:\n> \n> 2026-04-15 Martin Jambor \n> \n> \tPR tree-optimization/124151\n> \t* gcc.dg/tree-ssa/pr124151.c: New test.\n> ---\n> gcc/testsuite/gcc.dg/tree-ssa/pr124151.c | 31 ++++++++++++++++++++++++\n> gcc/tree-sra.cc | 3 ++-\n> 2 files changed, 33 insertions(+), 1 deletion(-)\n> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> \n> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> new file mode 100644\n> index 00000000000..4424e2d2768\n> --- /dev/null\n> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> @@ -0,0 +1,31 @@\n> +/* { dg-do compile } */\n> +/* { dg-options \"-O1\" } */\n> +\n> +typedef struct {\n> + bool : 1;\n> +} Http2Identifier;\n> +typedef struct {\n> + bool is_end;\n> + Http2Identifier identifier;\n> +} Http2DataFrame;\n> +typedef struct {\n> + Http2Identifier identifier;\n> + bool end_headers;\n> +} Http2ContinuationFrame;\n> +typedef struct {\n> + union {\n> + Http2DataFrame data;\n> + Http2ContinuationFrame continuation;\n> + };\n> +} Http2Frame;\n> +typedef struct {\n> + Http2Identifier stream_identifier;\n> +} Http2RawHeader;\n> +Http2RawHeader parse_http2_continuation_frame_http2_raw_header;\n> +Http2Frame gh2f;\n> +void http2_send_and_receive_preface() {\n> + Http2ContinuationFrame continuation_frame = {\n> + parse_http2_continuation_frame_http2_raw_header.stream_identifier, 0};\n> + Http2Frame frame = {.continuation = continuation_frame};\n> + gh2f = frame;\n> +}\n> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\n> index f4b672300aa..5352ea10838 100644\n> --- a/gcc/tree-sra.cc\n> +++ b/gcc/tree-sra.cc\n> @@ -2139,7 +2139,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n> \t\t if (pos != offset)\n> \t\t continue;\n> \t\t}\n> -\t else if (pos > offset || (pos + size) <= offset)\n> +\t else if (pos > offset || (pos + size) <= offset\n> +\t\t || (size % BITS_PER_UNIT) != 0)\n> \t\tcontinue;\n> \n> \t expr = build3 (COMPONENT_REF, TREE_TYPE (fld), *res, fld,\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=Xknm6YIB;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=uRoIpno+;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=Xknm6YIB;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=uRoIpno+;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=Xknm6YIB;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=uRoIpno+;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=Xknm6YIB;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=uRoIpno+","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxJKr6fddz1yG9\n\tfor ; Thu, 16 Apr 2026 23:10:56 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 0060B4BA9020\n\tfor ; Thu, 16 Apr 2026 13:10:55 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id 998F24BA902B\n for ; Thu, 16 Apr 2026 13:10:27 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id 907D66A7EC;\n Thu, 16 Apr 2026 13:10:26 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 0060B4BA9020","OpenDKIM Filter v2.11.0 sourceware.org 998F24BA902B"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 998F24BA902B","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 998F24BA902B","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776345027; cv=none;\n b=KDML4vFC/aHNjjzm6y5w3wJfClmcwhjwKwVqhQ5cm9hHOgoXwJqC0rkCoJH7NDFcm0Lx9pPq8UzwSaGir+Ybf1A/DQTHb3vUpfdkQ3EChM0jRWJSHnfaYtN/LafJE/RHSpFt5WJUQZQTYAza38dlXNraxuIfsXh0p4PEpU6BcoE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776345027; c=relaxed/simple;\n bh=EYkhX0z7PHILbWs7Q6SGigGQqehFjRovS8CDdAp/ipc=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=Kjy/V+GspDzNi1LFFud9ueV9WIuaBtY07KJH/NtAVmXR1GWVu0NBvE6LMK2QuvhNy+eAdcfKChmy5bd2uPP2XpLDftxIJegUSXoK1+4xh1eTaQJdAMlwWmn0ANl7WyevbO2OJWNgucv8CZOzqZ/WnIuZBfPI50Gfex84b3tfBLM=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776345026;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=vFDLtq16msc6NNdqrSHmyVEdQ8aqomn11htQz0YDHn4=;\n b=Xknm6YIBOjwNmU8VVi73Rh3+qnNqwqF6Yt+mTrDsZhNT/RKhPJQFouB3XLS4fPrjUw54Ge\n bKoPiKvwXMw2eJbb/idvNLHJi2dHG381wYfRHd9C0vcLR6EJy9Ll7ItQKEQeTMpdz4hQ89\n RIlJbbRb2SDyAeWJLkUhcfs2HgqUfRE=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776345026;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=vFDLtq16msc6NNdqrSHmyVEdQ8aqomn11htQz0YDHn4=;\n b=uRoIpno+ACjuxykimQGDe6bM5jxp/5fr7q5UjnhjSBp0DrPYynM7I+XmwDhOn3IRq3hR75\n Rh7iu2T+TqX0JIBg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776345026;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=vFDLtq16msc6NNdqrSHmyVEdQ8aqomn11htQz0YDHn4=;\n b=Xknm6YIBOjwNmU8VVi73Rh3+qnNqwqF6Yt+mTrDsZhNT/RKhPJQFouB3XLS4fPrjUw54Ge\n bKoPiKvwXMw2eJbb/idvNLHJi2dHG381wYfRHd9C0vcLR6EJy9Ll7ItQKEQeTMpdz4hQ89\n RIlJbbRb2SDyAeWJLkUhcfs2HgqUfRE=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776345026;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=vFDLtq16msc6NNdqrSHmyVEdQ8aqomn11htQz0YDHn4=;\n b=uRoIpno+ACjuxykimQGDe6bM5jxp/5fr7q5UjnhjSBp0DrPYynM7I+XmwDhOn3IRq3hR75\n Rh7iu2T+TqX0JIBg=="],"Date":"Thu, 16 Apr 2026 15:10:26 +0200 (CEST)","From":"Richard Biener ","To":"Martin Jambor ","cc":"GCC Patches ","Subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","In-Reply-To":"","Message-ID":"<406sqor8-n9p6-5447-77q6-958299no3r98@fhfr.qr>","References":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","X-Spamd-Result":"default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n RCPT_COUNT_TWO(0.00)[2]; FUZZY_RATELIMITED(0.00)[rspamd.com];\n ARC_NA(0.00)[];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+];\n FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n RCVD_COUNT_ZERO(0.00)[0]; MISSING_XM_UA(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[tree-sra.cc:url,suse.cz:email]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3678162,"web_url":"http://patchwork.ozlabs.org/comment/3678162/","msgid":"<86qq131s-8851-o8q2-54rq-1074ns134o12@fhfr.qr>","list_archive_url":null,"date":"2026-04-16T13:12:28","subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"On Thu, 16 Apr 2026, Richard Biener wrote:\n\n> On Thu, 16 Apr 2026, Martin Jambor wrote:\n> \n> > Hi,\n> > \n> > when SRA propagates bit-field propagations across assignments, it\n> > first attempts to use build_user_friendly_ref_for_offset to represent\n> > the expression of the new accesses and a possible scalar replacement\n> > so that if there are any warnings generated for it, they are as nice\n> > as we can make them.\n> > \n> > However, this can lead to situations where, despite that the new\n> > access has exactly the same type as the new old one, the new access\n> > can be a bit field even though the old one spanned entire bytes, like\n> > in the testcase in this patch. This trips the verifier and I guess\n> > may lead to data loss in the \"padding.\"\n> > \n> > Since r16-7406-g538da7baf6aee0 we do not initiate propagating for\n> > bit-fields and so we can just as well avoid creating any, so this\n> > patch skips them when searching for a user-friendly expression. In\n> > practical terms, this means that the propagated accesses have types\n> > such as unsigned char and are accessed via a MEM_REF.\n> > \n> > Bootstrapped and tested on x86_64-linux. OK for master and all the\n> > active release branches?\n> \n> OK.\n\nOr rather...\n\n> Thanks,\n> Richard.\n> \n> > Thanks,\n> > \n> > Martin\n> > \n> > \n> > gcc/ChangeLog:\n> > \n> > 2026-04-15 Martin Jambor \n> > \n> > \tPR tree-optimization/124151\n> > \t* tree-sra.cc (build_user_friendly_ref_for_offset): Skip\n> > \tbit-fields.\n> > \n> > gcc/testsuite/ChangeLog:\n> > \n> > 2026-04-15 Martin Jambor \n> > \n> > \tPR tree-optimization/124151\n> > \t* gcc.dg/tree-ssa/pr124151.c: New test.\n> > ---\n> > gcc/testsuite/gcc.dg/tree-ssa/pr124151.c | 31 ++++++++++++++++++++++++\n> > gcc/tree-sra.cc | 3 ++-\n> > 2 files changed, 33 insertions(+), 1 deletion(-)\n> > create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> > \n> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> > new file mode 100644\n> > index 00000000000..4424e2d2768\n> > --- /dev/null\n> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n> > @@ -0,0 +1,31 @@\n> > +/* { dg-do compile } */\n> > +/* { dg-options \"-O1\" } */\n> > +\n> > +typedef struct {\n> > + bool : 1;\n> > +} Http2Identifier;\n> > +typedef struct {\n> > + bool is_end;\n> > + Http2Identifier identifier;\n> > +} Http2DataFrame;\n> > +typedef struct {\n> > + Http2Identifier identifier;\n> > + bool end_headers;\n> > +} Http2ContinuationFrame;\n> > +typedef struct {\n> > + union {\n> > + Http2DataFrame data;\n> > + Http2ContinuationFrame continuation;\n> > + };\n> > +} Http2Frame;\n> > +typedef struct {\n> > + Http2Identifier stream_identifier;\n> > +} Http2RawHeader;\n> > +Http2RawHeader parse_http2_continuation_frame_http2_raw_header;\n> > +Http2Frame gh2f;\n> > +void http2_send_and_receive_preface() {\n> > + Http2ContinuationFrame continuation_frame = {\n> > + parse_http2_continuation_frame_http2_raw_header.stream_identifier, 0};\n> > + Http2Frame frame = {.continuation = continuation_frame};\n> > + gh2f = frame;\n> > +}\n> > diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\n> > index f4b672300aa..5352ea10838 100644\n> > --- a/gcc/tree-sra.cc\n> > +++ b/gcc/tree-sra.cc\n> > @@ -2139,7 +2139,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n> > \t\t if (pos != offset)\n> > \t\t continue;\n> > \t\t}\n> > -\t else if (pos > offset || (pos + size) <= offset)\n> > +\t else if (pos > offset || (pos + size) <= offset\n> > +\t\t || (size % BITS_PER_UNIT) != 0)\n\n... don't we want to fail, aka return false? We have an in-range\nfield, skipping to the next one looks odd.\n\n> > \t\tcontinue;\n> > \n> > \t expr = build3 (COMPONENT_REF, TREE_TYPE (fld), *res, fld,\n> > \n> \n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=hwPvT8lB;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=tzVout1Y;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=CkuNEhEZ;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=3su0/uCM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=hwPvT8lB;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=tzVout1Y;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=CkuNEhEZ;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=3su0/uCM","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.131","smtp-out2.suse.de;\n\tnone"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxJND5VDQz1yG9\n\tfor ; Thu, 16 Apr 2026 23:13:00 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id CF5D44BA9021\n\tfor ; Thu, 16 Apr 2026 13:12:58 +0000 (GMT)","from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])\n by sourceware.org (Postfix) with ESMTPS id 103B64BA23F2\n for ; Thu, 16 Apr 2026 13:12:30 +0000 (GMT)","from murzim.nue2.suse.org (unknown [10.168.4.243])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out2.suse.de (Postfix) with ESMTPS id EF3525BD11;\n Thu, 16 Apr 2026 13:12:28 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org CF5D44BA9021","OpenDKIM Filter v2.11.0 sourceware.org 103B64BA23F2"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 103B64BA23F2","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 103B64BA23F2","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776345150; cv=none;\n b=iAjm1OI4/8Xd7uoiSfPQv3SS5EGq13QFbSComGiTmFTk+o9WuM+I8qAcDaJhX6a4pGqY+/kSIK3Gwu4nt2NduQocCprxumHnNCgzIgDX3jyAQ/ZEtOt850KlIQnrxraufGttUt7O0kC6njg9C1s907DtqA95ZyKZNKww8sM2tOQ=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776345150; c=relaxed/simple;\n bh=JkF9L9Z2gIEWcsZYpo2X9qxDE2lPrJ4yCtJ96AkzbG0=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date:\n From:To:Subject:Message-ID:MIME-Version;\n b=wLQAqJhypxapfexkYOXOC6kk0QFK4EMVjem82T2CY0m+5awLCsZ27wPyiYjVTKRwcEAxSBaw9lPRlGdSBQwot/pSwQ+YMKSacDWw2r271l7Q7FWFP7TzCWBGvyxYyZmo8lv004VkczonuY8nuq39PeOfFy9Tsuor9p5Qn7h/xA0=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776345149;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=iwltgLtbIiR8BoucGWp7xe/Ooag814j3llWwvs2VEEA=;\n b=hwPvT8lBPxAgf5WldWLLfxtkOeIQEWr1o5XEwPCIADZzrEU2Wib7m69U4J3R5bimnQ9qdU\n 34K1mEe/SZdYcvG6YT0zvRJgNbiUfmJ0qq9r5dWUUiUAdydfBReYsrdvuuCtSQ6LT5wtTM\n pM8lYUvUI2NH2excnmkqJsMkNVYB//0=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776345149;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=iwltgLtbIiR8BoucGWp7xe/Ooag814j3llWwvs2VEEA=;\n b=tzVout1YqEuJmyDEgzrrxR1bfoFxSn8ftD82pqXELONRljbyCi0x5lGjWhoq6ugAzZ/Hit\n D/onlP5r6HsM3mBg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776345148;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=iwltgLtbIiR8BoucGWp7xe/Ooag814j3llWwvs2VEEA=;\n b=CkuNEhEZLXSzeXG5UXxWlpQjys2sM3uXPuu0ph4OFFjKM+b6C3HOoH7kl9RyFGNqqz8KCz\n E27EWrctX5zSaHP1VuxDBt9r8LPukbKMIg3Cm9DhMDfikCGb6KjX33TGM/AD9SlFymZQl9\n rKEd3OxiDVjLGeZhGQnwSc/sQF5oJPg=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776345148;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=iwltgLtbIiR8BoucGWp7xe/Ooag814j3llWwvs2VEEA=;\n b=3su0/uCMZHfDhT2EQ8TbewFeyQ+y+uKmljeN1df/at2uylWJulWvehoK4l8Cth47SysflQ\n S9V2tcr9OTGa+6Bg=="],"Date":"Thu, 16 Apr 2026 15:12:28 +0200 (CEST)","From":"Richard Biener ","To":"Martin Jambor ","cc":"GCC Patches ","Subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","In-Reply-To":"<406sqor8-n9p6-5447-77q6-958299no3r98@fhfr.qr>","Message-ID":"<86qq131s-8851-o8q2-54rq-1074ns134o12@fhfr.qr>","References":"\n <406sqor8-n9p6-5447-77q6-958299no3r98@fhfr.qr>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","X-Spamd-Result":"default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n RCPT_COUNT_TWO(0.00)[2]; FUZZY_RATELIMITED(0.00)[rspamd.com];\n ARC_NA(0.00)[];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+];\n FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n RCVD_COUNT_ZERO(0.00)[0]; MISSING_XM_UA(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[tree-sra.cc:url, fhfr.qr:mid,\n murzim.nue2.suse.org:helo, suse.de:email, suse.cz:email]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3678220,"web_url":"http://patchwork.ozlabs.org/comment/3678220/","msgid":"","list_archive_url":null,"date":"2026-04-16T14:49:32","subject":"Re: [PATCH] sra: Do not create bit-field type accesses during\n access propagation (PR124151)","submitter":{"id":4351,"url":"http://patchwork.ozlabs.org/api/people/4351/","name":"Martin Jambor","email":"mjambor@suse.cz"},"content":"Hi,\n\nOn Thu, Apr 16 2026, Richard Biener wrote:\n> On Thu, 16 Apr 2026, Richard Biener wrote:\n>\n>> On Thu, 16 Apr 2026, Martin Jambor wrote:\n>> \n>> > Hi,\n>> > \n>> > when SRA propagates bit-field propagations across assignments, it\n>> > first attempts to use build_user_friendly_ref_for_offset to represent\n>> > the expression of the new accesses and a possible scalar replacement\n>> > so that if there are any warnings generated for it, they are as nice\n>> > as we can make them.\n>> > \n>> > However, this can lead to situations where, despite that the new\n>> > access has exactly the same type as the new old one, the new access\n>> > can be a bit field even though the old one spanned entire bytes, like\n>> > in the testcase in this patch. This trips the verifier and I guess\n>> > may lead to data loss in the \"padding.\"\n>> > \n>> > Since r16-7406-g538da7baf6aee0 we do not initiate propagating for\n>> > bit-fields and so we can just as well avoid creating any, so this\n>> > patch skips them when searching for a user-friendly expression. In\n>> > practical terms, this means that the propagated accesses have types\n>> > such as unsigned char and are accessed via a MEM_REF.\n>> > \n>> > Bootstrapped and tested on x86_64-linux. OK for master and all the\n>> > active release branches?\n>> \n>> OK.\n>\n> Or rather...\n>\n\n[...]\n\n>> > diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\n>> > index f4b672300aa..5352ea10838 100644\n>> > --- a/gcc/tree-sra.cc\n>> > +++ b/gcc/tree-sra.cc\n>> > @@ -2139,7 +2139,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n>> > \t\t if (pos != offset)\n>> > \t\t continue;\n>> > \t\t}\n>> > -\t else if (pos > offset || (pos + size) <= offset)\n>> > +\t else if (pos > offset || (pos + size) <= offset\n>> > +\t\t || (size % BITS_PER_UNIT) != 0)\n>\n> ... don't we want to fail, aka return false? We have an in-range\n> field, skipping to the next one looks odd.\n\nThe code also deals with unions. I admit I actually don't know what\nleads to the fact that sometimes bool fields have size 1 bit and\nsometimes 1 byte, so I don't know if it is possible that some other\nunion field would succeed (maybe if it itself is a single field record?)\nbut the code is structured to try.\n\nBut I can make it return false too, indeed the case is quite unlikely in\npractice.\n\nThanks,\n\nMartin\n\n>\n>> > \t\tcontinue;\n>> > \n>> > \t expr = build3 (COMPONENT_REF, TREE_TYPE (fld), *res, fld,\n>> >","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=e8zhUT+c;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=hcfXMnlS;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=ETv/2nes;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=q4++aKUe;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=e8zhUT+c;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=hcfXMnlS;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=ETv/2nes;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=q4++aKUe","sourceware.org;\n dmarc=none (p=none dis=none) header.from=suse.cz","sourceware.org; spf=pass smtp.mailfrom=suse.cz","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.131","smtp-out2.suse.de;\n\tnone"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxLXT6Y38z1yCv\n\tfor ; Fri, 17 Apr 2026 00:50:17 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 748044BB58AE\n\tfor ; Thu, 16 Apr 2026 14:50:02 +0000 (GMT)","from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])\n by sourceware.org (Postfix) with ESMTPS id 21BEB4BA23F2\n for ; Thu, 16 Apr 2026 14:49:35 +0000 (GMT)","from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out2.suse.de (Postfix) with ESMTPS id D48965BCFA;\n Thu, 16 Apr 2026 14:49:32 +0000 (UTC)","from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CDD4A593A3;\n Thu, 16 Apr 2026 14:49:32 +0000 (UTC)","from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])\n by imap1.dmz-prg2.suse.org with ESMTPSA id qXc6Mvz24GlBKQAAD6G6ig\n (envelope-from ); Thu, 16 Apr 2026 14:49:32 +0000"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 748044BB58AE","OpenDKIM Filter v2.11.0 sourceware.org 21BEB4BA23F2"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 21BEB4BA23F2","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 21BEB4BA23F2","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776350975; cv=none;\n b=Xd9d+u5OlCvk0vISwNoZlM0XJhLezvU9+P2agpZtixHG1/x5AQjMD5mnOAIyguVS/4qBLgHK6M0xdsJu0eMH4WGb/Huce3/tyY/656tqpGQn74VaTirPG0ZhgDNJkY9Zgp2hgK5QjOCthKEtab8WQ+kgPz1FT19kNl7uDLA9cTM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776350975; c=relaxed/simple;\n bh=QhURvOPOxyMsTLgzPNQWqibwz7ElYeXm2vl/XfFxwN8=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From:\n To:Subject:Date:Message-ID:MIME-Version;\n b=d/srXi3gG8RTtLkAea+MzAix7MctQE3b4vvwaerPF7Q4PB8RfnpGpKsq/fz0vTn5tyD78/NJPhT34MeGVr4xi0xKbX9B5Lz4qgT4+qtgnA6ZzX0sMbMcWb7H5Xv7mBE5f2yvHd2ijfwfKKn1ZchkJwzKGbtpfAcfipZ3Xgq1QNU=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1776350974;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=f4f3dsZNiFPT8lbv3eCkgLn8ZfFuLGkIrcQfBfus0cg=;\n b=e8zhUT+cbHtgtyxnYuSbycnyswZqBo7wUv2Cv9RxBiM4LDnT/e1zw4HXjk4zKoVa7c2A0X\n MweLK8HzdNjibWAWPzt8xtvULboUFsWEsRWT8Bqk9nhzBEQcaCXFr9XEvqst/hOwCGyyuu\n huNePbtCzQ0AdC2OOeQ9pB50m7Lh75Q=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1776350974;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=f4f3dsZNiFPT8lbv3eCkgLn8ZfFuLGkIrcQfBfus0cg=;\n b=hcfXMnlStsj/FMPO2WJEh8G1cjcqPUlEJGzkn2LeqDcXC01Y56CJg+ICkTM+wSFieg2Y2x\n 7cLIQ1obtV0e8xDg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1776350972;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=f4f3dsZNiFPT8lbv3eCkgLn8ZfFuLGkIrcQfBfus0cg=;\n b=ETv/2nesn3oTY9uc4imZl8sX4JEJ7RblAxPrBojaYv1JvkoRW5NkJ5XBfHFFjsC3M9gwPn\n WRNdIiIBl75gLJ6tuJXEWGRb6/xwypHvpL6S0B0X7SbBA/bbfRpR/fqbsO9q4knlxY35Yi\n ckioNyXTFpnjKKkDUCq5OJC0GEp7vII=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1776350972;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=f4f3dsZNiFPT8lbv3eCkgLn8ZfFuLGkIrcQfBfus0cg=;\n b=q4++aKUeCfUaaGfCOI3eBMMHUExAual8XVojb2+4/oN1ShLmFJRlHNB9YXp3sEddMSQdCj\n 8E505U+o6H1/nBBA=="],"From":"Martin Jambor ","To":"Richard Biener ","Cc":"GCC Patches ","Subject":"Re: [PATCH] sra: Do not create bit-field type accesses during\n access propagation (PR124151)","In-Reply-To":"<86qq131s-8851-o8q2-54rq-1074ns134o12@fhfr.qr>","References":"\n <406sqor8-n9p6-5447-77q6-958299no3r98@fhfr.qr>\n <86qq131s-8851-o8q2-54rq-1074ns134o12@fhfr.qr>","User-Agent":"Notmuch/0.38.3 (https://notmuchmail.org) Emacs/30.2\n (x86_64-suse-linux-gnu)","Date":"Thu, 16 Apr 2026 16:49:32 +0200","Message-ID":"","MIME-Version":"1.0","Content-Type":"text/plain","X-Spamd-Result":"default: False [-8.30 / 50.00]; REPLY(-4.00)[];\n BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n MID_RHS_MATCH_FROMTLD(0.00)[];\n URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:helo];\n FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[];\n ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[];\n RCPT_COUNT_TWO(0.00)[2];\n DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];\n TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+];\n FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2];\n TO_MATCH_ENVRCPT_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,\n virgil.suse.cz:mid]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3678235,"web_url":"http://patchwork.ozlabs.org/comment/3678235/","msgid":"","list_archive_url":null,"date":"2026-04-16T15:05:44","subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","submitter":{"id":4338,"url":"http://patchwork.ozlabs.org/api/people/4338/","name":"Richard Biener","email":"rguenther@suse.de"},"content":"> Am 16.04.2026 um 16:50 schrieb Martin Jambor :\n> \n> Hi,\n> \n>> On Thu, Apr 16 2026, Richard Biener wrote:\n>>> On Thu, 16 Apr 2026, Richard Biener wrote:\n>>> \n>>>> On Thu, 16 Apr 2026, Martin Jambor wrote:\n>>> \n>>>> Hi,\n>>>> \n>>>> when SRA propagates bit-field propagations across assignments, it\n>>>> first attempts to use build_user_friendly_ref_for_offset to represent\n>>>> the expression of the new accesses and a possible scalar replacement\n>>>> so that if there are any warnings generated for it, they are as nice\n>>>> as we can make them.\n>>>> \n>>>> However, this can lead to situations where, despite that the new\n>>>> access has exactly the same type as the new old one, the new access\n>>>> can be a bit field even though the old one spanned entire bytes, like\n>>>> in the testcase in this patch. This trips the verifier and I guess\n>>>> may lead to data loss in the \"padding.\"\n>>>> \n>>>> Since r16-7406-g538da7baf6aee0 we do not initiate propagating for\n>>>> bit-fields and so we can just as well avoid creating any, so this\n>>>> patch skips them when searching for a user-friendly expression. In\n>>>> practical terms, this means that the propagated accesses have types\n>>>> such as unsigned char and are accessed via a MEM_REF.\n>>>> \n>>>> Bootstrapped and tested on x86_64-linux. OK for master and all the\n>>>> active release branches?\n>>> \n>>> OK.\n>> \n>> Or rather...\n>> \n> \n> [...]\n> \n>>>> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\n>>>> index f4b672300aa..5352ea10838 100644\n>>>> --- a/gcc/tree-sra.cc\n>>>> +++ b/gcc/tree-sra.cc\n>>>> @@ -2139,7 +2139,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n>>>> if (pos != offset)\n>>>> continue;\n>>>> }\n>>>> - else if (pos > offset || (pos + size) <= offset)\n>>>> + else if (pos > offset || (pos + size) <= offset\n>>>> + || (size % BITS_PER_UNIT) != 0)\n>> \n>> ... don't we want to fail, aka return false? We have an in-range\n>> field, skipping to the next one looks odd.\n> \n> The code also deals with unions. I admit I actually don't know what\n> leads to the fact that sometimes bool fields have size 1 bit and\n> sometimes 1 byte, so I don't know if it is possible that some other\n> union field would succeed (maybe if it itself is a single field record?)\n> but the code is structured to try.\n> \n> But I can make it return false too, indeed the case is quite unlikely in\n> practice.\n\nThe check at least needs a comment then. Even bit-size can match. If we never want a reconstructed ref for those as we only have them from BIT_FIELD_REFs then we should check for this before searching fields and require a match on an outermost BFR only?\n\nRichard.\n\n> Thanks,\n> \n> Martin\n> \n>> \n>>>> continue;\n>>>> \n>>>> expr = build3 (COMPONENT_REF, TREE_TYPE (fld), *res, fld,\n>>>>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=DCCIqdQH;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=2By/phBF;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=DCCIqdQH;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=2By/phBF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256\n header.s=susede2_rsa header.b=DCCIqdQH;\n\tdkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=2By/phBF;\n\tdkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de\n header.a=rsa-sha256 header.s=susede2_rsa header.b=DCCIqdQH;\n\tdkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=2By/phBF","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=suse.de","sourceware.org; spf=pass smtp.mailfrom=suse.de","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n\tnone"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxLvN3gCjz1yCv\n\tfor ; Fri, 17 Apr 2026 01:06:40 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 7FEFF4C318BB\n\tfor ; Thu, 16 Apr 2026 15:06:38 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id C772D4BA23FB\n for ; Thu, 16 Apr 2026 15:06:00 +0000 (GMT)","from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id 6FD556A7FA;\n Thu, 16 Apr 2026 15:05:59 +0000 (UTC)","from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 62174593A3;\n Thu, 16 Apr 2026 15:05:59 +0000 (UTC)","from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])\n by imap1.dmz-prg2.suse.org with ESMTPSA id 7JvxF9f64GlGOgAAD6G6ig\n (envelope-from ); Thu, 16 Apr 2026 15:05:59 +0000"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 7FEFF4C318BB","OpenDKIM Filter v2.11.0 sourceware.org C772D4BA23FB"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org C772D4BA23FB","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org C772D4BA23FB","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776351961; cv=none;\n b=j4Z0q7OZcG8JYFdrI90hn4pUGz8bp/LkZPSotpYn8k5dgJWlykD8Uxzfo6nvLDMdyycLtaxI6q5Uo1vDOGPkFd2wBZ96ydcJAMYTmL6IgvYYCFuGZrAh0k3pBJgyIn/xOVMR2K/bK0j6pWsgweu4U75IMKQiyeXxCKT4hmHKg40=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776351961; c=relaxed/simple;\n bh=leIgJ6okoxQQ0tXzH7c1wB228MFcSXnf3tocEFxsWgY=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From:\n Mime-Version:Subject:Date:Message-Id:To;\n b=W4OXqv3J6uQTdMPxLfvRgksIGD0EmVKT3SIiYFfdhMZI5oJXC8GrqWr85TTXvtaz+HAbKyN2ol9O9kz99/E5UIdlgsH5GUMxX9F9t+P/nxa3xBATiHCqPnqpyHHtf276nRie4hX2Kveg9LbEDzJTA+EZ+URGKzoPvYl6BGPUa9Q=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776351959;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=4VMvfXexPvGO2aFRh94or5jOMFHy+/r3RM0MkZ/dcHE=;\n b=DCCIqdQHT05b+LRFzhHxSg2CKn6Itlt2/nn5ivsM03408qZG8Pa524Prut4WCOPHKbvmZg\n Q4XOHIe428eyFgtzjmzgtgBV2qMdFl1tEAqD5KL8t+O0LusShUb5cf7AsDW0s9TQGqIxs8\n GZB8nchJNcgn60b5DmyboetO06WoNac=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776351959;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=4VMvfXexPvGO2aFRh94or5jOMFHy+/r3RM0MkZ/dcHE=;\n b=2By/phBFsdWW6cC8YESzdEYrZlN3YJB4p1DhewJsyw1cHFyXnWvCCjE+e22UmEJpoR+2cS\n 5+ShFep9ZUDXN2Aw==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_rsa;\n t=1776351959;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=4VMvfXexPvGO2aFRh94or5jOMFHy+/r3RM0MkZ/dcHE=;\n b=DCCIqdQHT05b+LRFzhHxSg2CKn6Itlt2/nn5ivsM03408qZG8Pa524Prut4WCOPHKbvmZg\n Q4XOHIe428eyFgtzjmzgtgBV2qMdFl1tEAqD5KL8t+O0LusShUb5cf7AsDW0s9TQGqIxs8\n GZB8nchJNcgn60b5DmyboetO06WoNac=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;\n s=susede2_ed25519; t=1776351959;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=4VMvfXexPvGO2aFRh94or5jOMFHy+/r3RM0MkZ/dcHE=;\n b=2By/phBFsdWW6cC8YESzdEYrZlN3YJB4p1DhewJsyw1cHFyXnWvCCjE+e22UmEJpoR+2cS\n 5+ShFep9ZUDXN2Aw=="],"Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","From":"Richard Biener ","Mime-Version":"1.0 (1.0)","Subject":"Re: [PATCH] sra: Do not create bit-field type accesses during access\n propagation (PR124151)","Date":"Thu, 16 Apr 2026 17:05:44 +0200","Message-Id":"","References":"","Cc":"Patches GCC ","In-Reply-To":"","To":"Martin Jambor ","X-Mailer":"iPhone Mail (23E254)","X-Spamd-Result":"default: False [-8.30 / 50.00]; REPLY(-4.00)[];\n BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n MID_RHS_MATCH_FROM(0.00)[];\n URIBL_BLOCKED(0.00)[suse.cz:email,suse.de:mid,imap1.dmz-prg2.suse.org:helo];\n APPLE_IOS_MAILER_COMMON(0.00)[];\n FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[];\n RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[];\n RCPT_COUNT_TWO(0.00)[2];\n DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];\n FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[];\n MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[];\n TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2];\n DBL_BLOCKED_OPENRESOLVER(0.00)[suse.cz:email, imap1.dmz-prg2.suse.org:helo,\n suse.de:mid]","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684691,"web_url":"http://patchwork.ozlabs.org/comment/3684691/","msgid":"","list_archive_url":null,"date":"2026-04-30T13:09:28","subject":"Re: [PATCH] sra: Do not create bit-field type accesses during\n access propagation (PR124151)","submitter":{"id":4351,"url":"http://patchwork.ozlabs.org/api/people/4351/","name":"Martin Jambor","email":"mjambor@suse.cz"},"content":"Hello,\n\nOn Thu, Apr 16 2026, Richard Biener wrote:\n>> Am 16.04.2026 um 16:50 schrieb Martin Jambor :\n>> \n>> Hi,\n>> \n>>> On Thu, Apr 16 2026, Richard Biener wrote:\n>>>> On Thu, 16 Apr 2026, Richard Biener wrote:\n>>>> \n>>>>> On Thu, 16 Apr 2026, Martin Jambor wrote:\n>>>> \n>>>>> Hi,\n>>>>> \n>>>>> when SRA propagates bit-field propagations across assignments, it\n>>>>> first attempts to use build_user_friendly_ref_for_offset to represent\n>>>>> the expression of the new accesses and a possible scalar replacement\n>>>>> so that if there are any warnings generated for it, they are as nice\n>>>>> as we can make them.\n>>>>> \n>>>>> However, this can lead to situations where, despite that the new\n>>>>> access has exactly the same type as the new old one, the new access\n>>>>> can be a bit field even though the old one spanned entire bytes, like\n>>>>> in the testcase in this patch. This trips the verifier and I guess\n>>>>> may lead to data loss in the \"padding.\"\n>>>>> \n>>>>> Since r16-7406-g538da7baf6aee0 we do not initiate propagating for\n>>>>> bit-fields and so we can just as well avoid creating any, so this\n>>>>> patch skips them when searching for a user-friendly expression. In\n>>>>> practical terms, this means that the propagated accesses have types\n>>>>> such as unsigned char and are accessed via a MEM_REF.\n>>>>> \n>>>>> Bootstrapped and tested on x86_64-linux. OK for master and all the\n>>>>> active release branches?\n>>>> \n>>>> OK.\n>>> \n>>> Or rather...\n>>> \n>> \n>> [...]\n>> \n>>>>> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\n>>>>> index f4b672300aa..5352ea10838 100644\n>>>>> --- a/gcc/tree-sra.cc\n>>>>> +++ b/gcc/tree-sra.cc\n>>>>> @@ -2139,7 +2139,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n>>>>> if (pos != offset)\n>>>>> continue;\n>>>>> }\n>>>>> - else if (pos > offset || (pos + size) <= offset)\n>>>>> + else if (pos > offset || (pos + size) <= offset\n>>>>> + || (size % BITS_PER_UNIT) != 0)\n>>> \n>>> ... don't we want to fail, aka return false? We have an in-range\n>>> field, skipping to the next one looks odd.\n>> \n>> The code also deals with unions. I admit I actually don't know what\n>> leads to the fact that sometimes bool fields have size 1 bit and\n>> sometimes 1 byte, so I don't know if it is possible that some other\n>> union field would succeed (maybe if it itself is a single field record?)\n>> but the code is structured to try.\n>> \n>> But I can make it return false too, indeed the case is quite unlikely in\n>> practice.\n>\n> The check at least needs a comment then. Even bit-size can match. If\n> we never want a reconstructed ref for those as we only have them from\n> BIT_FIELD_REFs\n\nPlease note that this is about COMPONENT_REFs which have size that is\nnot a multiple of bytes, not about BIT_FIELD_REFs.\n\n> then we should check for this before searching fields and require a\n> match on an outermost BFR only?\n\nBased on this thread and on our conversation last week, I went back and\nmade a patch which makes the function identify bit-fields and only\nreturn them when desirable and also reverts the bail-out fix for\nPR117217.\n\nThe patch has passed bootstrap and testing on x86_64-linux and I'd like\nto push it to master. It is however applicable to the release branches\nas well - and it should not be a big risk either. I can however also\nprepare a variant of the previous patch with the requested comment.\n\nIs this OK for master? What is your preference for the release\nbranches?\n\nThanks,\n\nMartin\n\n\n\n[PATCH] sra: Fix build_user_friendly_ref_for_offset for bit-fields (PR124151)\n\nWhen SRA propagates bit-field propagations across assignments, it\nfirst attempts to use build_user_friendly_ref_for_offset to represent\nthe expression of the new accesses and a possible scalar replacement\nso that if there are any warnings generated for it, they are as nice\nas we can make them.\n\nHowever, this can lead to situations where, despite that the new\naccess has exactly the same type as the new old one, it accesses a\n(record or union): field which is just big enough for its precision,\nwhereas the one we want to match has size rounded up to bytes. This\ncauses discrepancy between the recorded size of the new access and the\nsize get_ref_base_and_extent reports for its expr, which trips the\nverifier.\n\nUnlike the previous approach which avoided propagation in the case of\nbit fields, this patch fixes build_user_friendly_ref_for_offset by\nmaking it also track the size it is looking at and the size it is\nlooking for so that it can declare success only if these two also\nmatch. Additionally, it reverts the simple bail-out fix for PR 117217\nbecause it is no longer necessary. (I have verified the bug is still\nfixed though by applying the new fix on top of the last problematic\ncommit.)\n\ngcc/ChangeLog:\n\n2026-04-29 Martin Jambor \n\n\tPR tree-optimizations/124151\n\t* tree-sra.cc (build_user_friendly_ref_for_offset): Added parameters\n\tCUR_SIZE and EXP_SIZE. Added code passing the correct CUR_SIZE and\n\tchecking it against EXP_SIZE. Removed unused code for the case when\n\tEXP_TYPE was NULL_TREE.\n\t(create_artificial_child_access): Adjusted the call to\n\tbuild_user_friendly_ref_for_offset.\n\t(propagate_subaccesses_from_rhs): Likewise.\n\t(propagate_subaccesses_from_rhs): Removed a check that the size of\n\tlchild is a multiple of BITS_PER_UNIT.\n\t(propagate_subaccesses_from_lhs): Likewise.\n\ngcc/testsuite/ChangeLog:\n\n2026-04-29 Martin Jambor \n\n\tPR tree-optimizations/124151\n\t* gcc.dg/tree-ssa/pr124151.c: New test.\n---\n gcc/testsuite/gcc.dg/tree-ssa/pr124151.c | 31 ++++++++++++++++++\n gcc/tree-sra.cc | 41 +++++++++++++-----------\n 2 files changed, 53 insertions(+), 19 deletions(-)\n create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n\ndiff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\nnew file mode 100644\nindex 00000000000..37d3edc3812\n--- /dev/null\n+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c\n@@ -0,0 +1,31 @@\n+/* { dg-do compile } */\n+/* { dg-options \"-O1\" } */\n+\n+typedef struct {\n+ _Bool : 1;\n+} Http2Identifier;\n+typedef struct {\n+ _Bool is_end;\n+ Http2Identifier identifier;\n+} Http2DataFrame;\n+typedef struct {\n+ Http2Identifier identifier;\n+ _Bool end_headers;\n+} Http2ContinuationFrame;\n+typedef struct {\n+ union {\n+ Http2DataFrame data;\n+ Http2ContinuationFrame continuation;\n+ };\n+} Http2Frame;\n+typedef struct {\n+ Http2Identifier stream_identifier;\n+} Http2RawHeader;\n+Http2RawHeader parse_http2_continuation_frame_http2_raw_header;\n+Http2Frame gh2f;\n+void http2_send_and_receive_preface() {\n+ Http2ContinuationFrame continuation_frame = {\n+ parse_http2_continuation_frame_http2_raw_header.stream_identifier, 0};\n+ Http2Frame frame = {.continuation = continuation_frame};\n+ gh2f = frame;\n+}\ndiff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc\nindex 293386b6c29..1b4ee39d7b9 100644\n--- a/gcc/tree-sra.cc\n+++ b/gcc/tree-sra.cc\n@@ -2091,16 +2091,20 @@ build_debug_ref_for_model (location_t loc, tree base, HOST_WIDE_INT offset,\n }\n \n /* Construct a memory reference consisting of component_refs and array_refs to\n- a part of an aggregate *RES (which is of type TYPE). The requested part\n- should have type EXP_TYPE at be the given OFFSET. This function might not\n- succeed, it returns true when it does and only then *RES points to something\n- meaningful. This function should be used only to build expressions that we\n- might need to present to user (e.g. in warnings). In all other situations,\n+ a part of an aggregate *RES which is of type TYPE. The requested part\n+ should have type EXP_TYPE at be the given OFFSET. CUR_SIZE should be the\n+ size of *RES unless it is known that *RES alone cannot be the result. This\n+ function might not succeed, it returns true when it does and only then *RES\n+ points to something meaningful.\n+\n+ This function should be used only to build expressions that we might need to\n+ present to user (e.g. in warnings). In all other situations,\n build_ref_for_model or build_ref_for_offset should be used instead. */\n \n static bool\n build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n-\t\t\t\t tree exp_type)\n+\t\t\t\t HOST_WIDE_INT cur_size, tree exp_type,\n+\t\t\t\t HOST_WIDE_INT exp_size)\n {\n while (1)\n {\n@@ -2108,7 +2112,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n tree tr_size, index, minidx;\n HOST_WIDE_INT el_size;\n \n- if (offset == 0 && exp_type\n+ if (offset == 0\n+\t && cur_size == exp_size\n \t && types_compatible_p (exp_type, type))\n \treturn true;\n \n@@ -2146,7 +2151,8 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n \t\t\t NULL_TREE);\n \t expr_ptr = &expr;\n \t if (build_user_friendly_ref_for_offset (expr_ptr, TREE_TYPE (fld),\n-\t\t\t\t\t\t offset - pos, exp_type))\n+\t\t\t\t\t\t offset - pos, size,\n+\t\t\t\t\t\t exp_type, exp_size))\n \t\t{\n \t\t *res = expr;\n \t\t return true;\n@@ -2169,17 +2175,12 @@ build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,\n \t *res = build4 (ARRAY_REF, TREE_TYPE (type), *res, index,\n \t\t\t NULL_TREE, NULL_TREE);\n \t offset = offset % el_size;\n+\t cur_size = el_size;\n \t type = TREE_TYPE (type);\n \t break;\n \n \tdefault:\n-\t if (offset != 0)\n-\t return false;\n-\n-\t if (exp_type)\n-\t return false;\n-\t else\n-\t return true;\n+\t return false;\n \t}\n }\n }\n@@ -3070,7 +3071,8 @@ create_artificial_child_access (struct access *parent, struct access *model,\n struct access *access = access_pool.allocate ();\n memset (access, 0, sizeof (struct access));\n if (!build_user_friendly_ref_for_offset (&expr, TREE_TYPE (expr), new_offset,\n-\t\t\t\t\t model->type))\n+\t\t\t\t\t parent->size, model->type,\n+\t\t\t\t\t model->size))\n {\n access->grp_no_warning = true;\n expr = build_ref_for_model (EXPR_LOCATION (parent->base), parent->base,\n@@ -3211,8 +3213,11 @@ propagate_subaccesses_from_rhs (struct access *lacc, struct access *racc)\n \t tree t = lacc->base;\n \n \t lacc->type = racc->type;\n+\t /* We know racc and lacc are different type so can pass -1 as\n+\t cur_size. */\n \t if (build_user_friendly_ref_for_offset (&t, TREE_TYPE (t),\n-\t\t\t\t\t\t lacc->offset, racc->type))\n+\t\t\t\t\t\t lacc->offset, -1,\n+\t\t\t\t\t\t racc->type, racc->size))\n \t {\n \t lacc->expr = t;\n \t lacc->grp_same_access_path = true;\n@@ -3270,7 +3275,6 @@ propagate_subaccesses_from_rhs (struct access *lacc, struct access *racc)\n \t}\n \n if (rchild->grp_unscalarizable_region\n-\t || (rchild->size % BITS_PER_UNIT) != 0\n \t || !budget_for_propagation_access (lacc->base))\n \t{\n \t if (!lacc->grp_write && access_or_its_child_written (rchild))\n@@ -3330,7 +3334,6 @@ propagate_subaccesses_from_lhs (struct access *lacc, struct access *racc)\n HOST_WIDE_INT norm_offset = lchild->offset + norm_delta;\n \n if (lchild->grp_unscalarizable_region\n-\t || (lchild->size % BITS_PER_UNIT) != 0\n \t || child_would_conflict_in_acc (racc, norm_offset, lchild->size,\n \t\t\t\t\t &matching_acc)\n \t || !budget_for_propagation_access (racc->base))","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=Uy6M2YrC;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=OAuztqy6;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=Uy6M2YrC;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=OAuztqy6;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=suse.cz header.i=@suse.cz header.a=rsa-sha256\n header.s=susede2_rsa header.b=Uy6M2YrC;\n\tdkim=pass header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=OAuztqy6;\n\tdkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz\n header.a=rsa-sha256 header.s=susede2_rsa header.b=Uy6M2YrC;\n\tdkim=neutral header.d=suse.cz header.i=@suse.cz header.a=ed25519-sha256\n header.s=susede2_ed25519 header.b=OAuztqy6","sourceware.org;\n dmarc=none (p=none dis=none) header.from=suse.cz","sourceware.org; spf=pass smtp.mailfrom=suse.cz","server2.sourceware.org;\n arc=none smtp.remote-ip=195.135.223.130","smtp-out1.suse.de;\n dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Uy6M2YrC;\n dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=OAuztqy6"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5vfc5LDFz1xqf\n\tfor ; Thu, 30 Apr 2026 23:10:12 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id F2350436F3DE\n\tfor ; Thu, 30 Apr 2026 13:10:08 +0000 (GMT)","from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])\n by sourceware.org (Postfix) with ESMTPS id 2D71A43B5528\n for ; Thu, 30 Apr 2026 13:09:37 +0000 (GMT)","from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org\n [IPv6:2a07:de40:b281:104:10:150:64:97])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-out1.suse.de (Postfix) with ESMTPS id 19C576A822;\n Thu, 30 Apr 2026 13:09:36 +0000 (UTC)","from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested)\n by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 823C0593B0;\n Thu, 30 Apr 2026 13:09:33 +0000 (UTC)","from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])\n by imap1.dmz-prg2.suse.org with ESMTPSA id QsvEH41U82m/IwAAD6G6ig\n (envelope-from ); Thu, 30 Apr 2026 13:09:33 +0000"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org F2350436F3DE","OpenDKIM Filter v2.11.0 sourceware.org 2D71A43B5528"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 2D71A43B5528","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 2D71A43B5528","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777554577; cv=none;\n b=giEl71vR9u/762gpWBgGb++uKthumNBdoGoVqiz16EIqQ1FNMwDzdeJ24Rjuo6UkeUqknty1Bne7JdIg/KiwTcKYbQlTw9aohbPFfhioDu16h44uUdbOHI4Ak2lgADDIJEZUHh43XPcdde//EjTNMoP+A0GKov+i0XKobQqud94=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777554577; c=relaxed/simple;\n bh=QU4ySAblA4dzQNGL0sHeWNyH5Nteqk1PM7N5PwZlzAQ=;\n h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From:\n To:Subject:Date:Message-ID:MIME-Version;\n b=VAugUdrNk+E+ygwvOv5b+KksMa9/zFbiieA+6E+83wfZUvMMoZvt5O2JmX7oPwnbr7+efpfATedxu7BKAjGVhqjQSrsQbIuFShHqlr6H7DGTLaV72ICr3xjHGHo1IAOTOSow3da5pVW36cwP+Q4rBc5qxCnaNFelCqyBGByHy5k=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1777554576;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=JSBU0OAtR6E85oqSoNsyLHxsyZkmCWE2ZZxrMOAkPmQ=;\n b=Uy6M2YrCTDADZv4YiOe0h91LgLX8xsmNa+doHDkdks1tjRiqnV3ibAIMKsPPtZB1iFNEMv\n Zj8v1KrQOLB62IleTuQjurXVp1I9MMEG7jj+LWdE1q6bBuUH84t04CNeXCHNJM8jrDP+Os\n oRodGsZ5RYRIC/u4TefkZynLzJCRpF0=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1777554576;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=JSBU0OAtR6E85oqSoNsyLHxsyZkmCWE2ZZxrMOAkPmQ=;\n b=OAuztqy64YCXmN8rpye2jeYxgy1ups79+FM1UvFepSO0KsWQuaUHPzlWpkch9N67y0DJyd\n 1myh65jgnf03BzBQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_rsa;\n t=1777554576;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=JSBU0OAtR6E85oqSoNsyLHxsyZkmCWE2ZZxrMOAkPmQ=;\n b=Uy6M2YrCTDADZv4YiOe0h91LgLX8xsmNa+doHDkdks1tjRiqnV3ibAIMKsPPtZB1iFNEMv\n Zj8v1KrQOLB62IleTuQjurXVp1I9MMEG7jj+LWdE1q6bBuUH84t04CNeXCHNJM8jrDP+Os\n oRodGsZ5RYRIC/u4TefkZynLzJCRpF0=","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;\n s=susede2_ed25519; t=1777554576;\n h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:\n mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=JSBU0OAtR6E85oqSoNsyLHxsyZkmCWE2ZZxrMOAkPmQ=;\n b=OAuztqy64YCXmN8rpye2jeYxgy1ups79+FM1UvFepSO0KsWQuaUHPzlWpkch9N67y0DJyd\n 1myh65jgnf03BzBQ=="],"From":"Martin Jambor ","To":"Richard Biener ","Cc":"Patches GCC ","Subject":"Re: [PATCH] sra: Do not create bit-field type accesses during\n access propagation (PR124151)","In-Reply-To":"","References":"\n ","User-Agent":"Notmuch/0.38.3 (https://notmuchmail.org) Emacs/30.2\n (x86_64-suse-linux-gnu)","Date":"Thu, 30 Apr 2026 15:09:28 +0200","Message-ID":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","X-Rspamd-Action":"no action","X-Rspamd-Server":"rspamd2.dmz-prg2.suse.org","X-Spamd-Result":"default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%];\n NEURAL_HAM_LONG(-1.00)[-1.000];\n R_DKIM_ALLOW(-0.20)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];\n NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain];\n MX_GOOD(-0.01)[];\n DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received];\n FUZZY_RATELIMITED(0.00)[rspamd.com];\n RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+];\n ARC_NA(0.00)[];\n SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];\n RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2];\n DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];\n FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[];\n MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2];\n TO_MATCH_ENVRCPT_ALL(0.00)[];\n DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.cz:dkim,suse.cz:email];\n TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.cz:+]","X-Rspamd-Queue-Id":"19C576A822","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]