[Bug middle-end/96192] New: tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[Bug middle-end/96192] New: tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[skpgkp2 at gmail dot com]

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

            Bug ID: 96192
           Summary: tree-inline.c(copy_decl_for_dup_finish) should
                    preserve decl alignment in copy
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: skpgkp2 at gmail dot com
                CC: hjl.tools at gmail dot com
  Target Milestone: ---
            Target: x86_64-*-* i?86-*-*

tree-inline.c function copy_decl_for_dup_finish should preserve local decl
alignment in copy.

This issue appears when local decl alignment get lowered by target hook, but
during the inline, copy may get different alignment than original decl.

This blocks PR95237.

Test case:

$ cat foo.c
int a;

long long 
b (void)
{
}

void
c (void)
{
  if (b())
    a = 1;
}

$gcc -m32 -mpreferred-stack-boundary=2 -Os -c foo.c
during GIMPLE pass: adjust_alignment
foo.c: In function ??c??:
foo.c:12:1: internal compiler error: in execute, at adjust-alignment.c:74
   12 | c (void)
      | ^
0x20bc351 execute
        /local/skpandey/gccwork/gccwork/pr95237_1/gcc/adjust-alignment.c:74
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-14
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, but there's no local variable to copy here?  Are you refering to the
result decl from b we materialize in c?  This would be the same case
as for example switch conversion adding a 'long long' variable, so the
issue would be more wide-spread as you think - for example IPA SRA might
choose to pass an aggregate by its components thus with an aggregate with
two long long members you should see similar issues.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elver at google dot com

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
*** Bug 95645 has been marked as a duplicate of this bug. ***

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[skpgkp2 at gmail dot com]

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

--- Comment #3 from Sunil Pandey <skpgkp2 at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> Hmm, but there's no local variable to copy here?  Are you refering to the
> result decl from b we materialize in c?  This would be the same case
> as for example switch conversion adding a 'long long' variable, so the
> issue would be more wide-spread as you think - for example IPA SRA might
> choose to pass an aggregate by its components thus with an aggregate with
> two long long members you should see similar issues.

Yes, long long result decl. It's incoming alignment is 4(lowered by target
hook). But copy get default alignment as 8.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[skpgkp2 at gmail dot com]

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

Sunil Pandey <skpgkp2 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skpgkp2 at gmail dot com

--- Comment #4 from Sunil Pandey <skpgkp2 at gmail dot com> ---
Created attachment 48913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48913&action=edit
This patch lower alignment of parm and result decl. It also preserve decl
alignment during inlining.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:07c70c29affe7c6d01ab37cc7bc725fd1351f668

commit r11-2315-g07c70c29affe7c6d01ab37cc7bc725fd1351f668
Author: Sunil K Pandey <skpgkp2@gmail.com>
Date:   Fri Jul 24 14:08:41 2020 -0700

    Add testcase to show kernel issue got fixed by pr95237 [PR96192]

    This test case, extracted from PR 95645, was failing because alignment
    of local long long variable got lowered from 8 bytes to 4 bytes in
    adjust alignment pass, which triggered assert failure.

    This test case passes now because PR 95237 fix only allows lowering of
    alignment of local variables in the front end.  As a result, alignment
    of local long long variable no longer gets lowered in adjust alignment
    pass.

    gcc/testsuite/ChangeLog:

            PR target/96192
            * c-c++-common/pr96192-1.c: New test.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |11.0

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed