[Bug c/104427] New: [12 Regression] ICE in gimplify_expr, at gimplify.cc:15759

[Bug c/104427] New: [12 Regression] ICE in gimplify_expr, at gimplify.cc:15759

[gscfq@t-online.de]

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

            Bug ID: 104427
           Summary: [12 Regression] ICE in gimplify_expr, at
                    gimplify.cc:15759
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started between 20211114 and 20211121 :


$ cat z1.c
_Float16 x, y;
int foo()
{
  return __builtin_assoc_barrier(x + y) - y;
}


$ gcc-12-20220206 -c z1.c
z1.c:4:36: internal compiler error: in gimplify_expr, at gimplify.cc:15759
    4 |   return __builtin_assoc_barrier(x + y) - y;
      |                                  ~~^~~
0xac934a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15759
0xac70cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15720
0xac43ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15066
0xac3f9d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15729
0xac9c78 gimplify_stmt(tree_node**, gimple**)
        ../../gcc/gimplify.cc:7035
0xac57ee gimplify_and_add(tree_node*, gimple**)
        ../../gcc/gimplify.cc:495
0xac57ee gimplify_return_expr
        ../../gcc/gimplify.cc:1677
0xac57ee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15225
0xac9c78 gimplify_stmt(tree_node**, gimple**)
        ../../gcc/gimplify.cc:7035
0xaca603 gimplify_bind_expr
        ../../gcc/gimplify.cc:1427
0xac5f8a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
        ../../gcc/gimplify.cc:15164
0xac9c78 gimplify_stmt(tree_node**, gimple**)
        ../../gcc/gimplify.cc:7035
0xacb85e gimplify_body(tree_node*, bool)
        ../../gcc/gimplify.cc:16209
0xacbe47 gimplify_function_tree(tree_node*)
        ../../gcc/gimplify.cc:16363
0x8dd527 cgraph_node::analyze()
        ../../gcc/cgraphunit.cc:675
0x8e07d6 analyze_functions
        ../../gcc/cgraphunit.cc:1240
0x8e19ad symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.cc:2500

[Bug c/104427] ICE with __builtin_assoc_barrier and float16 types

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Started between 20211114 and 20211121 :

Started when __builtin_assoc_barrier support was added
(r12-5368-gefb7c51024ccad9df2) so this is not a regression.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE with                    |ICE with
                   |__builtin_assoc_barrier and |__builtin_assoc_barrier and
                   |float16 types               |float types which introduce
                   |                            |excess precision
             Target|                            |aarch64*-* x86_64-*-*

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is an interaction between excess_precision_expr and the barrier.

Here is another testcase which shows the same issue but on i?86 (-m32 -mno-sse
-std=c99):
float x, y;
int foo()
{
  return __builtin_assoc_barrier(x + y) - y;
}

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-07

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Matthias?

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[mkretz at gcc dot gnu.org]

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

--- Comment #4 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
I can certainly take a look, but so far my GCC internals experience ends with
the C++ front-end. This ICEs in the pass where front-end trees are transformed
into GIMPLE, right? So it would be a pass that is not shared with the FORTRAN
front-end, which surely doesn't have this problem? But in principle, the two
front-ends would have to produce equivalent GIMPLE for
  C++: __builtin_assoc_barrier(x + y) - y
  FORTRAN: (x + y) - y
right?

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Kretz (Vir) from comment #4)
> I can certainly take a look, but so far my GCC internals experience ends
> with the C++ front-end. This ICEs in the pass where front-end trees are
> transformed into GIMPLE, right? So it would be a pass that is not shared
> with the FORTRAN front-end, which surely doesn't have this problem? But in
> principle, the two front-ends would have to produce equivalent GIMPLE for
>   C++: __builtin_assoc_barrier(x + y) - y
>   FORTRAN: (x + y) - y
> right?

The issue is somewhere in the C frontend which uses EXCESS_PRECISION_EXPR
which it fails to properly lower (in C frontend or c-family code) when
the __builtin_assoc_barrier is processed.  I don't know the details there,
Joseph might.  There might be similar issues with C_MAYBE_CONST_EXPR.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[jakub at gcc dot gnu.org]

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

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

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

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

This works for me.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:499f8d4c2bc585b985882b4716f35b4c1553ce32

commit r12-7148-g499f8d4c2bc585b985882b4716f35b4c1553ce32
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 9 20:45:31 2022 +0100

    c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]

    The following testcase ICEs, because when creating PAREN_EXPR for
    __builtin_assoc_barrier the FE doesn't do the usual tweaks for
    EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR.  I believe that the
    declared effect of the builtin is just association barrier, so
    e.g. excess precision should be still handled like if it wasn't
    there.

    The following patch uses build_unary_op to handle those.

    2022-02-09  Jakub Jelinek  <jakub@redhat.com>

            PR c/104427
            * c-parser.cc (c_parser_postfix_expression)
            <case RID_BUILTIN_ASSOC_BARRIER>: Use parser_build_unary_op
            instead of build1_loc to build PAREN_EXPR.
            * c-typeck.cc (build_unary_op): Handle PAREN_EXPR.
            * c-fold.cc (c_fully_fold_internal): Likewise.

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

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.