[Bug c/113727] New: csmith: differences from nothing to -O1

[Bug c/113727] New: csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

            Bug ID: 113727
           Summary: csmith: differences from nothing to -O1
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57298&action=edit
C source code

The attached C code seems to produce different answers
between no optimisation flags and -O1:

foundBugs $ ../results/bin/gcc -w bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 0
foundBugs $ ../results/bin/gcc -w -O1 bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 1
foundBugs $ diff 0 1 
469,478c469,478
< ...checksum after hashing g_994.f3 : 5F99C263
< ...checksum after hashing g_994.f4 : 6E61EEE1
< ...checksum after hashing g_994.f5 : 8A4973F3
< ...checksum after hashing g_994.f6 : 1A47F5E1
< ...checksum after hashing g_994.f7 : CD2C240E
< ...checksum after hashing g_994.f8 : 7E61A9F
< ...checksum after hashing g_1368 : 74B15A31
< ...checksum after hashing g_1659 : 322B1FCB
< ...checksum after hashing g_1720 : 65F2763C
< checksum = 65F2763C
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
> ...checksum after hashing g_994.f4 : 23E1696C
> ...checksum after hashing g_994.f5 : B115BFA4
> ...checksum after hashing g_994.f6 : E3A4BBDA
> ...checksum after hashing g_994.f7 : D44B3E01
> ...checksum after hashing g_994.f8 : 656901A2
> ...checksum after hashing g_1368 : 3B45689
> ...checksum after hashing g_1659 : EBA715C1
> ...checksum after hashing g_1720 : BDD5FC31
> checksum = BDD5FC31

I have a reduction running. 

The bug first seems to occur sometime between dates 20231001 and 20231119. 
Git hashes are g:5f3da480e7541a9c and eaeaad3fcac4d7a3.

[Bug c/113727] csmith: differences from nothing to -O1

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
With UBSAN, I get:
```
$ gcc-13 -ggdb3 -fsanitize=address,undefined /tmp/PR113727.c -o /tmp/PR113727
$ /tmp/PR113727
runData/keep/in.9954.c:416:134: runtime error: store to misaligned address
0x55a497188a23 for type 'uint32_t', which requires 4 byte alignment
0x55a497188a23: note: pointer points here
 00  a5 07 00 83 88 64 91 23  2a 00 28 bc 14 00 50 fe  ff 15 00 00 00 00 00 00 
00 00 00 00 00 00 00
              ^
    #0 0x55a49716fda5 in func_46 runData/keep/in.9954.c:416
    #1 0x55a49716c2fb in func_19 runData/keep/in.9954.c:352
    #2 0x55a49716661e in func_1 runData/keep/in.9954.c:153
    #3 0x55a49717dc21 in main runData/keep/in.9954.c:838
    #4 0x7f9632452e69  (/usr/lib64/libc.so.6+0x25e69)
    #5 0x7f9632452f1c in __libc_start_main (/usr/lib64/libc.so.6+0x25f1c)
    #6 0x55a4971632e0 in _start (/tmp/PR113727+0x172e0)
```

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
I have a bisection running too. I am trying out g:0f2e2080685e7509

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #2)
> I have a bisection running too. I am trying out g:0f2e2080685e7509

That seems bad. Trying g:328745607c5d403a.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > I have a bisection running too. I am trying out g:0f2e2080685e7509
> 
> That seems bad. Trying g:328745607c5d403a.

Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
some 155 commits.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #4)
> Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
> some 155 commits.

Current range seems to be g:0f40e59f193f96f1 to g:6decda1a35be5764.

Of those 5 commits, 3 are for RISC-V and look unrelated and these two:

g:6decda1a35be5764101987c210b5693a0d914e58
g:35b5bb475375dba4ea9101d6db13a6012c4e84ca

look likely candidates, both by Richard. Adding Richard for their opinion.

My first attempt at a reduction didn't work. 
I will have another go sometime over the weekend.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
As expected:

trunk.20210101 $ git bisect good 35b5bb475375dba4
6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit
commit 6decda1a35be5764101987c210b5693a0d914e58
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Oct 12 11:34:57 2023 +0200

    tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA

[Bug c/113727] csmith: differences from nothing to -O1

[sjames at gcc dot gnu.org]

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

--- Comment #7 from Sam James <sjames at gcc dot gnu.org> ---
Can you try produce a testcase without UB please?

[Bug c/113727] csmith: differences from nothing to -O1

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=109982

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
#pragma pack(push)
#pragma pack(1)
struct S0 { 
   signed f0 : 22;
   uint32_t f1;
   unsigned f2 : 5; 
   unsigned f3 : 21;
   unsigned f4 : 8; 
   signed f5 : 22;
   signed f6 : 1; 
   signed f7 : 23;
   signed f8 : 10;
};
#pragma pack(pop)

Removing these #pragma silence the UBSan.  But I bet the code is just invalid
with those #pragma and with #pragma removed the issue will just gone, like
PR109982.

[Bug c/113727] csmith: differences from nothing to -O1

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |
                   |a/show_bug.cgi?id=109982    |

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Nope.  Even with #pragma removed the result is still wrong.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Sam James from comment #7)
> Can you try produce a testcase without UB please?

I have some partly reduced code that seems to have no UB.

cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined bug1002.c
cvise $ ./a.out 1 > 0
cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined -O1 bug1002.c
cvise $ ./a.out 1 > 1
cvise $ diff 0 1
469c469
< ...checksum after hashing g_994.f3 : 5F99C263
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
cvise $

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 57310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57310&action=edit
C source code

[Bug c/113727] csmith: differences from nothing to -O1

[xry111 at gcc dot gnu.org]

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

--- Comment #12 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to David Binderman from comment #11)
> Created attachment 57310 [details]
> C source code

static uint32_t (safe_mul_func_uint32_t_u_u)(uint32_t ui1, uint32_t ui2 ) { 
}

This thing is UB if you use its return value (in C; in C++ it will be an UB
even if the return value is not used).

Better adding -Werror=return-type to cvise.

[Bug c/113727] [14 Regression] csmith: differences from nothing to -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Keywords|                            |needs-reduction, wrong-code
            Summary|csmith: differences from    |[14 Regression] csmith:
                   |nothing to -O1              |differences from nothing to
                   |                            |-O1

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P1

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[sjames at gcc dot gnu.org]

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

--- Comment #13 from Sam James <sjames at gcc dot gnu.org> ---
I'll spend some CPU hours with cvise on this.

-ftrivial-auto-var-init=zero seems to make -O1 work.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[sjames at gcc dot gnu.org]

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

--- Comment #14 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57731&action=edit
reduced.i

Maybe. I think it could go further even with cvise but I was playing with the
sysctls for that ASAN ASLR issue and I think it meant it stopped going further.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[sjames at gcc dot gnu.org]

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

--- Comment #15 from Sam James <sjames at gcc dot gnu.org> ---
(I am going to let it run more with fixed sysctls.)

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[pinskia at gcc dot gnu.org]

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57732&action=edit
A little more reduced

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #57732|0                           |1
        is obsolete|                            |

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57733&action=edit
A lot more

Just a checkpoint. There does not seem to be any undefined code in this one.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #57733|0                           |1
        is obsolete|                            |

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57734&action=edit
Reduced all the way down I could

Note the struct copies are important to reproduce the bug.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-reduction             |
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-03-19

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

(In reply to David Binderman from comment #6)
> As expected:
> 
> trunk.20210101 $ git bisect good 35b5bb475375dba4
> 6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit
> commit 6decda1a35be5764101987c210b5693a0d914e58
> Author: Richard Biener <rguenther@suse.de>
> Date:   Thu Oct 12 11:34:57 2023 +0200
> 
>     tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA

yes this seems very much the change which caused the reduced testcase even.
Since if we change the bitfields to non bitfields, things start to work and
```
if (as.au)
```
is changed to:
```
      if ((BIT_FIELD_REF <as, 8, 0> & 31) != 0)
```

by fold.

If we add:
```
int t = as.au;
```

Right before that if statemtent things start to work too.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.  Thanks for the reduced testcase.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, so the mistake happens in 135.sra which does

   <bb 2> [local count: 178992760]:
-  as.f3 = 5;
+  as$f3_6 = 5;

   <bb 3> [local count: 894749064]:
   # y_24 = PHI <y_14(5), 0(2)>
   # as_27 = PHI <as_12(5), 169(2)>
+  # as$f3_8 = PHI <as$f3_4(5), as$f3_6(2)>
   _1 = as_27 & 31;
   if (_1 != 0)
     goto <bb 5>; [50.00%]
@@ -26,12 +39,12 @@
     goto <bb 4>; [50.00%]

   <bb 4> [local count: 447374532]:
-  cstore_19 = MEM <struct f> [(void *)&as].f3;
+  cstore_19 = as$f3_8;

   <bb 5> [local count: 894749064]:
   # as_12 = PHI <as_27(4), 66(3)>
   # cstore_20 = PHI <cstore_19(4), 154(3)>
-  MEM <struct f> [(void *)&as].f3 = cstore_20;
+  as$f3_4 = cstore_20;
   y_14 = y_24 + 1;
   if (y_14 <= 4)
     goto <bb 3>; [80.00%]
@@ -41,8 +54,12 @@
   <bb 6> [local count: 178992760]:
   # as_28 = PHI <as_12(5)>
   BIT_FIELD_REF <as, 8, 0> = as_28;
+  as$f3_22 = as.f3;
+  as.f3 = as$f3_22;
   aq1 = as;


note how we elide as.f3 but in BB6 fail to process the BIT_FIELD_REF
but then re-materialize as.f3 as if 'as' were fully stored to by
the BIT_FIELD_REF.

The BIT_FIELD_REF should have triggered re-materialization before it.

Upon handling BIT_FIELD_REF <as, 8, 0> = as_28; we create the re-load
of as.f3, but as said we fail to re-materialize 'as' before it from the
replacement.

For the following aggregate copy we run into

      if (access_has_children_p (lacc)
          && access_has_children_p (racc)
          /* When an access represents an unscalarizable region, it usually
             represents accesses with variable offset and thus must not be used
             to generate new memory accesses.  */
          && !lacc->grp_unscalarizable_region
          && !racc->grp_unscalarizable_region)
        {
          struct subreplacement_assignment_data sad;

          sad.left_offset = lacc->offset;
          sad.assignment_lhs = lhs;
          sad.assignment_rhs = rhs; 
          sad.top_racc = racc;
          sad.old_gsi = *gsi;
          sad.new_gsi = gsi;
          sad.loc = gimple_location (stmt);
          sad.refreshed = SRA_UDH_NONE;

          if (lacc->grp_read && !lacc->grp_covered)
            handle_unscalarized_data_in_subtree (&sad);

which I think is a similar situation in that the BIT_FIELD_REF on the LHS
overlaps with replacements and is a RMW operation.  I think SRA simply
assumes that any non-aggregate copy will hever partially invalidate
replacements?

I'm not sure how BIT_FIELD_REF was handled (and worked) before my change,
we record the whole variable as access for the BIT_FIELD_REF write
(but with ->grp_partial_lhs set).  But we do not look at grp_partial_lhs
when analyzing for overlaps.

The following fixes this, but a "better" change would be to record the
proper extent, including the BIT_FIELD_REF, even for LHS?  Before my RHS
handling change we likely always produced a replacement for the BIT_FIELD_REF
base and kept the BIT_FIELD_REFs around, correct?

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..848bb8b89e0 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2269,6 +2269,11 @@ sort_and_splice_var_accesses (tree var)
           && TREE_CODE (access->expr) == COMPONENT_REF
           && DECL_BIT_FIELD (TREE_OPERAND (access->expr, 1)));

+      /* When there is a partial LHS involved we have no way to see what it
+        accesses, so if it's not the only access we have to fail.  */
+      if (access->grp_partial_lhs && access_count != 1)
+       return NULL;
+
       if (first || access->offset >= high)
        {
          first = false;

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Handling LHS sra_handled_bf_read_p the same as RHS also fixes the issue,
we then detect the partial overlap of the accesses without looking at
grp_partial_lhs.

I wonder if we run into the same issue for REAL/IMAGPART_EXPR on the LHS
when we have both _Complex and component accesses mixed.

So alternative patch:

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..8e9c2e3d343 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1161,7 +1161,7 @@ build_access_from_expr_1 (tree expr, gimple *stmt, bool
write)
   bool partial_ref;

   if ((TREE_CODE (expr) == BIT_FIELD_REF
-       && (write || !sra_handled_bf_read_p (expr)))
+       && !sra_handled_bf_read_p (expr))
       || TREE_CODE (expr) == IMAGPART_EXPR
       || TREE_CODE (expr) == REALPART_EXPR)
     {
@@ -3973,7 +3980,7 @@ sra_modify_expr (tree *expr, bool write,
gimple_stmt_iterator *stmt_gsi,
   bool partial_cplx_access = false;

   if (TREE_CODE (*expr) == BIT_FIELD_REF
-      && (write || !sra_handled_bf_read_p (*expr)))
+      && !sra_handled_bf_read_p (*expr))
     {
       bfr = *expr;
       expr = &TREE_OPERAND (*expr, 0);
@@ -4517,7 +4524,7 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator
*gsi)
   if (TREE_CODE (rhs) == REALPART_EXPR || TREE_CODE (lhs) == REALPART_EXPR
       || TREE_CODE (rhs) == IMAGPART_EXPR || TREE_CODE (lhs) == IMAGPART_EXPR
       || (TREE_CODE (rhs) == BIT_FIELD_REF && !sra_handled_bf_read_p (rhs))
-      || TREE_CODE (lhs) == BIT_FIELD_REF)
+      || (TREE_CODE (lhs) == BIT_FIELD_REF && !sra_handled_bf_read_p (lhs)))
     {
       modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (stmt),
                                          false, gsi, gsi);

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note with the 2nd patch it's still broken when the BIT_FIELD_REFs in the IL are
not byte aligned.

Both patches passed bootstrap & regtest, there is unknown effect on
optimization of __imag / __real.

Looking at such an example we see

  _1 = x.f;
  s$f = _1;
  REALPART_EXPR <s$f> = 1.0e+0;
  _7 = s$f;
  s.f = _7;
  bar (s);

so while we don't "handle" REALPART_EXPR we assume its base is fully
replaced.  For the BIT_FIELD_REF case we cannot know any such thing.

Ah, and the fix is a bit wrong I guess.  It should be

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..f8176de817f 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2358,6 +2358,12 @@ sort_and_splice_var_accesses (tree var)
          j++;
        }

+      /* When there is a partial LHS involved we have no way to see what it
+        accesses, so if it's not the only access to the subregion
+        we have to fail.  */
+      if (grp_partial_lhs && j != i + 1)
+       return NULL;
+
       i = j;

       access->group_representative = access;

and that indeed does disable SRA for

struct S { _Complex float f; } x;

void bar (struct S);

float foo ()
{
  struct S s;
  s.f = x.f;
  __real s.f = 1.f;
  bar (s);
  float x = __real s.f;
  return x;
}

so maybe grp_partial_lhs isn't supposed to handle the BIT_FIELD_REF case
in question but only handles the case where there's a sub-access in its
base?

I suppose it simply wasn't designed to handle mixed accesses.

Maybe the problem is that SRA fails to see that for a ->grp_partial_lhs
access we _have_ to do a replacement.  For the testcase in this PR the
access is 'as' itself and we create a replacement for as.au and as.f3
but then we have overlapping replacements (with the covering 'as').

The following fixes that, but maybe not in the correct place:

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..dbfae5e7fdd 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2735,7 +2735,8 @@ analyze_access_subtree (struct access *root, struct
access *parent,
     {
       hole |= covered_to < child->offset;
       sth_created |= analyze_access_subtree (child, root,
-                                            allow_replacements && !scalar,
+                                            allow_replacements && !scalar
+                                            && !root->grp_partial_lhs,
                                             totally);

       root->grp_unscalarized_data |= child->grp_unscalarized_data;

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:9d6ff6f1ea2ae7fc32ec9fbd0554fb06238ed045

commit r14-9589-g9d6ff6f1ea2ae7fc32ec9fbd0554fb06238ed045
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Mar 19 14:50:06 2024 +0100

    tree-optimization/113727 - bogus SRA with BIT_FIELD_REF

    When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
    aligned reads differently from byte aligned reads.  Instead of
    trying to create replacements for the loaded portion the former
    cases try to replace the base object while keeping the wrapping
    BIT_FIELD_REFs.  This breaks when we have both kinds operating
    on the same base object if there's no appearant overlap conflict
    as the conflict that then nevertheless exists isn't handled with.
    The fix is to enforce what I think is part of the design handling
    the former case - that only the full base object gets replaced
    and no further sub-objects are created within as otherwise
    keeping the wrapping BIT_FIELD_REF cannot work.  The patch
    enforces this within analyze_access_subtree.

            PR tree-optimization/113727
            * tree-sra.cc (analyze_access_subtree): Do not allow
            replacements in subtrees when grp_partial_lhs.

            * gcc.dg/torture/pr113727.c: New testcase.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.