[Bug tree-optimization/104558] New: [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[Bug tree-optimization/104558] New: [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[zsojka at seznam dot cz]

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

            Bug ID: 104558
           Summary: [9/10/11/12 Regression] ICE: in expand_call, at
                    calls.cc:3601 with -fabi-version=9 on pr83487.c
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Compiler output:
$ cat gcc/testsuite/gcc.c-torture/compile/pr83487.c
/* PR middle-end/83487 */
/* { dg-skip-if "too many arguments in function call" { bpf-*-* } } */

struct __attribute__ ((aligned)) A {};
struct A a;
void bar (int, int, int, int, int, int, int, struct A);

void
foo (void)
{
  bar (0, 1, 2, 3, 4, 5, 6, a);
}
x86_64-pc-linux-gnu-gcc -fabi-version=9
gcc/testsuite/gcc.c-torture/compile/pr83487.c
during RTL pass: expand
gcc/testsuite/gcc.c-torture/compile/pr83487.c: In function 'foo':
gcc/testsuite/gcc.c-torture/compile/pr83487.c:11:3: internal compiler error: in
expand_call, at calls.cc:3601
   11 |   bar (0, 1, 2, 3, 4, 5, 6, a);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
0xe5a44d expand_call(tree_node*, rtx_def*, int)
        /repo/gcc-trunk/gcc/calls.cc:3601
0xfad901 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /repo/gcc-trunk/gcc/expr.cc:11539
0xe726de expand_expr
        /repo/gcc-trunk/gcc/expr.h:301
0xe726de expand_call_stmt
        /repo/gcc-trunk/gcc/cfgexpand.cc:2831
0xe726de expand_gimple_stmt_1
        /repo/gcc-trunk/gcc/cfgexpand.cc:3864
0xe726de expand_gimple_stmt
        /repo/gcc-trunk/gcc/cfgexpand.cc:4028
0xe78228 expand_gimple_basic_block
        /repo/gcc-trunk/gcc/cfgexpand.cc:6069
0xe7a3b7 execute
        /repo/gcc-trunk/gcc/cfgexpand.cc:6795
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7249-20220215180935-g8e84b2b37a5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7249-20220215180935-g8e84b2b37a5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220215 (experimental) (GCC)

[Bug tree-optimization/104558] [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Last reconfirmed|                            |2022-02-16
             Status|UNCONFIRMED                 |NEW
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |9.5
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r8-4853-g974aedcce8d3eb6d46493c1e597b75743cb4c3db
GCC 7 didn't ICE, with -fabi-version=9 we should be following the GCC 7 ABI for
this function.

[Bug tree-optimization/104558] [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is the
-      emit_push_insn (arg->value, arg->mode, TREE_TYPE (pval), size_rtx,
-                     parm_align, partial, reg, excess, argblock,
-                     ARGS_SIZE_RTX (arg->locate.offset), reg_parm_stack_space,
-                     ARGS_SIZE_RTX (arg->locate.alignment_pad), false);
+      if (!CONST_INT_P (size_rtx) || INTVAL (size_rtx) != 0)
+       emit_push_insn (arg->value, arg->mode, TREE_TYPE (pval), size_rtx,
+                       parm_align, partial, reg, excess, argblock,
+                       ARGS_SIZE_RTX (arg->locate.offset),
+                       reg_parm_stack_space,
+                       ARGS_SIZE_RTX (arg->locate.alignment_pad), false);
change that breaks this.  While we don't really need to push anything when
size_rtx is const0_rtx, emit_push_insn at the end does:
  if (alignment_pad && args_addr == 0)
    anti_adjust_stack (alignment_pad);
so I wonder if we don't need:
      else if (maybe_ne (arg->locate.alignment_pad, 0)
               && argblock == NULL_RTX)
        anti_adjust_stack (ARGS_SIZE_RTX (arg->locate.alignment_pad));
or so (also in the other spot).

[Bug middle-end/104558] [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52452&action=edit
gcc12-pr104558.patch

Untested fix.

[Bug middle-end/104558] [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:e6e6e0a97340068c90fe091482efbaacd6474754

commit r12-7458-ge6e6e0a97340068c90fe091482efbaacd6474754
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 3 09:11:09 2022 +0100

    calls: When bypassing emit_push_insn for 0 sized arg, emit at least
anti_adjust_stack for alignment pad if needed [PR104558]

    The following testcase ICEs on x86_64 when asked to use the pre-GCC 8
    ABI where zero sized arguments weren't ignored.
    In GCC 7 the emit_push_insn calls in store_one_arg were unconditional,
    it is true that they didn't actually push anything because it had zero
    size, but because arg->locate.alignment_pad is 8 in this case,
    emit_push_insn at the end performs
              if (alignment_pad && args_addr == 0)
                anti_adjust_stack (alignment_pad);
    and an assert larger on is upset if we don't do it.
    The following patch keeps the emit_push_insn conditional but calls
    the anti_adjust_stack when needed by hand for the zero sized arguments.
    For the new x86_64 ABI where zero sized arguments are ignored
    arg->locate.alignment_pad is 0 in this case, so nothing changes
    - we in that case really do ignore it.

    There is another emit_push_insn call earlier in store_one_arg, also made
    conditional on non-zero size by Marek in GCC 8, but that one is for
    arguments with non-BLKmode and the only way those can be zero size is
    if they are TYPE_EMPTY_P aka when they are completely ignored.  But
    I believe arg->locate.alignment_pad should be 0 in that case, so IMHO
    there is no need to do anything in the second spot.

    2022-03-03  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104558
            * calls.cc (store_one_arg): When not calling emit_push_insn
            because size_rtx is const0_rtx, call at least anti_adjust_stack
            on arg->locate.alignment_pad if !argblock and the alignment might
            be non-zero.

            * gcc.dg/pr104558.c: New test.

[Bug middle-end/104558] [9/10/11 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression]     |[9/10/11 Regression] ICE:
                   |ICE: in expand_call, at     |in expand_call, at
                   |calls.cc:3601 with          |calls.cc:3601 with
                   |-fabi-version=9 on          |-fabi-version=9 on
                   |pr83487.c                   |pr83487.c

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk.  I think for backports we'd need a proof that we always ICE
or at least that if it doesn't ICE the callers are ABI incompatible with
callees.

[Bug middle-end/104558] [10/11 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug middle-end/104558] [10/11 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug middle-end/104558] [11 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.