[Bug tree-optimization/109788] New: [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int

[Bug tree-optimization/109788] New: [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int

[marxin at gcc dot gnu.org]

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

            Bug ID: 109788
           Summary: [14 Regression] gcc/hwint.h:293:61: runtime error:
                    shift exponent 64 is too large for 64-bit type 'long
                    unsigned int
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

The following UBSAN happens with the following test-case:

$ cat cat associate_60.f90
cat: cat: No such file or directory
    character(3) :: a = 'abc'
    associate (y => spread(trim(a),1,2) // 'd')
    end associate
  end

$ /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/ associate_60.f90 -c -Os
/home/marxin/Programming/gcc/gcc/hwint.h:293:61: runtime error: shift exponent
64 is too large for 64-bit type 'long unsigned int'
    #0 0xb9c00c in sext_hwi(long, unsigned int)
(/dev/shm/objdir/gcc/f951+0xb9c00c) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #1 0xb9c737 in wi::hwi_with_prec::hwi_with_prec(long, unsigned int, signop)
(/dev/shm/objdir/gcc/f951+0xb9c737) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #2 0xb9c7c2 in wi::shwi(long, unsigned int)
(/dev/shm/objdir/gcc/f951+0xb9c7c2) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #3 0x128eaad in wi::minus_one(unsigned int)
(/dev/shm/objdir/gcc/f951+0x128eaad) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #4 0x12928b9 in irange::set_varying(tree_node*)
(/dev/shm/objdir/gcc/f951+0x12928b9) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #5 0x247afe1 in range_cast(vrange&, tree_node*)
(/dev/shm/objdir/gcc/f951+0x247afe1) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #6 0x1dd34ff in ipa_compute_jump_functions_for_edge(ipa_func_body_info*,
cgraph_edge*) (/dev/shm/objdir/gcc/f951+0x1dd34ff) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #7 0x1dd4b25 in ipa_compute_jump_functions_for_bb(ipa_func_body_info*,
basic_block_def*) (/dev/shm/objdir/gcc/f951+0x1dd4b25) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #8 0x1dd82c5 in analysis_dom_walker::before_dom_children(basic_block_def*)
(/dev/shm/objdir/gcc/f951+0x1dd82c5) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #9 0x60da965 in dom_walker::walk(basic_block_def*)
(/dev/shm/objdir/gcc/f951+0x60da965) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #10 0x1dd8c79 in ipa_analyze_node(cgraph_node*)
(/dev/shm/objdir/gcc/f951+0x1dd8c79) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #11 0x63788ee in ipcp_generate_summary()
(/dev/shm/objdir/gcc/f951+0x63788ee) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #12 0x23758b2 in execute_ipa_summary_passes(ipa_opt_pass_d*)
(/dev/shm/objdir/gcc/f951+0x23758b2) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #13 0x14834d3 in ipa_passes() (/dev/shm/objdir/gcc/f951+0x14834d3)
(BuildId: 3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #14 0x1483f12 in symbol_table::compile()
(/dev/shm/objdir/gcc/f951+0x1483f12) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #15 0x1484ee4 in symbol_table::finalize_compilation_unit()
(/dev/shm/objdir/gcc/f951+0x1484ee4) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #16 0x280638f in compile_file() (/dev/shm/objdir/gcc/f951+0x280638f)
(BuildId: 3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #17 0x280e46e in do_compile(bool) (/dev/shm/objdir/gcc/f951+0x280e46e)
(BuildId: 3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #18 0x280eccb in toplev::main(int, char**)
(/dev/shm/objdir/gcc/f951+0x280eccb) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #19 0x692ac5f in main (/dev/shm/objdir/gcc/f951+0x692ac5f) (BuildId:
3d3a45e367361bf0f2e66b9ab765947856982ca3)
    #20 0x7ffff722cbaf in __libc_start_call_main (/lib64/libc.so.6+0x27baf)
(BuildId: 9854a3cd243b5cfbf99999e26f7fbb65e62146c7)
    #21 0x7ffff722cc78 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x27c78)
(BuildId: 9854a3cd243b5cfbf99999e26f7fbb65e62146c7)
    #22 0xa604a4 in _start ../sysdeps/x86_64/start.S:115

[Bug tree-optimization/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression]             |[14 Regression]
                   |gcc/hwint.h:293:61: runtime |gcc/hwint.h:293:61: runtime
                   |error: shift exponent 64 is |error: shift exponent 64 is
                   |too large for 64-bit type   |too large for 64-bit type
                   |'long unsigned int          |'long unsigned int since
                   |                            |r14-377-gc92b8be9b52b7e
                 CC|                            |aldyh at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-05-09
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r14-377-gc92b8be9b52b7e.

[Bug tree-optimization/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is on
_gfortran_spread_char_scalar (&atmp.0, _1, &a, &C.4290, &C.4292, _1);
and ipa_compute_jump_functions_for_edge on the _1 arg, which is
 <ssa_name 0x7fffea134ab0
    type <integer_type 0x7fffea146738 integer(kind=8) public DI
        size <integer_cst 0x7fffea12cc48 constant 64>
        unit-size <integer_cst 0x7fffea12cc60 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set 6 canonical-type
0x7fffea146738 precision:64 min <integer_cst 0x7fffea12ced0
-9223372036854775808> max <integer_cst 0x7fffea12cee8 9223372036854775807>
        pointer_to_this <pointer_type 0x7fffea17c738> reference_to_this
<reference_type 0x7fffe9f02498>>
    visited
    def_stmt _1 = MAX_EXPR <_20, 0>;
    version:1
    ptr-info 0x7fffe9f186e0>
but somehow
       tree param_type = ipa_get_callee_param_type (cs, n);
returns VOID_TYPE.  So, either it is a bug that parm_type can be some
completely unrelated type to the argument's type, or if it has some special
meaning,
          if (TREE_CODE (arg) == SSA_NAME
              && param_type
              /* Limit the ranger query to integral types as the rest
                 of this file uses value_range's, which only hold
                 integers and pointers.  */
              && irange::supports_p (TREE_TYPE (arg))
              && get_range_query (cfun)->range_of_expr (vr, arg)
              && !vr.undefined_p ())
should also check that irange::supports_p (param_type) or something similar.
The exact ICE is trying to compute wide_int -1 with precision 0.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |fortran

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, perhaps it is a Fortran FE bug, but still IPA should try to be careful.
The _gfortran_spread_char_scalar fndecl the FE creates has types
array01_character(kind=1)&, integer(kind=8), real(kind=4)&, integer(kind=8)&,
integer(kind=4)& (just 5 arguments), but the call passes it 6 arguments, which
is why param_type for the last one is VOID_TYPE (aka the argument type list
terminator).
Strangely, the libgfortran function it is actually calling has
void
spread_char_scalar (gfc_array_char *ret,
                    GFC_INTEGER_4 ret_length __attribute__((unused)),
                    const char *source, const index_type *along,
                    const index_type *pncopies,
                    GFC_INTEGER_4 source_length __attribute__((unused)))
prototype.  So, not really sure how can this work at all.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the IPA side I'd go with at least
2023-05-09  Jakub Jelinek  <jakub@redhat.com>

        PR fortran/109788
        * ipa-prop.cc (ipa_get_callee_param_type): Don't return TREE_VALUE (t)
        if t is void_list_node.

--- gcc/ipa-prop.cc.jj  2023-05-01 09:59:46.485296735 +0200
+++ gcc/ipa-prop.cc     2023-05-09 15:07:44.975578250 +0200
@@ -2147,7 +2147,7 @@ ipa_get_callee_param_type (struct cgraph
         break;
       t = TREE_CHAIN (t);
     }
-  if (t)
+  if (t && t != void_list_node)
     return TREE_VALUE (t);
   if (!e->callee)
     return NULL;

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
            Version|13.0                        |14.0

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 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:395a75593ef87a68a04111bb08243b5d9a811f45

commit r14-656-g395a75593ef87a68a04111bb08243b5d9a811f45
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 10 13:20:39 2023 +0200

    ipa-prop: Fix ipa_get_callee_param_type for calls with argument type
mismatches

    The PR contains a testcase where the Fortran FE creates FUNCTION_TYPE
    which doesn't really match the passed in arguments (FUNCTION_TYPE has
    5 arguments, call has 6).  Now, I think that is a Fortran FE bug that
    should be fixed there, but I think with function pointers one can
    create something similar (of course invalid) in C/C++ too,so IMHO IPA
    should be also more careful.
    The ipa_get_callee_param_type function can return NULL if something goes
    wrong and it does e.g. if asked for 7th argument type on a function
    with just 5 arguments and similar.  But, if a function isn't varargs,
    when asked for 6th argument type on a function with just 5 arguments
    it actually returns void_type_node because the argument list is in that
    case terminated with void_list_node.

    The following patch makes sure we don't treat void_list_node as something
    holding another argument.

    2023-05-10  Jakub Jelinek  <jakub@redhat.com>

            PR fortran/109788
            * ipa-prop.cc (ipa_get_callee_param_type): Don't return TREE_VALUE
(t)
            if t is void_list_node.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What remains is some Fortran FE change.  The function seems to be called with 6
arguments that the runtime actually expects, so there is some chance that it
works, but
some of the arguments have incompatible types (integer(kind=8) vs.
GFC_INTEGER_4) and the FUNCTION_TYPE contains just 5 arguments rather than 6.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 55040
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55040&action=edit
libgfortran patch

It appears that the prototypes of the character variants of the SPREAD
intrinsic were not updated at the time when the character length type
was changed from int to size_t.

Does the attached patch fix your observation?

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That feels like ABI incompatible change.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Of course, if libgfortran plans to bump soname for GCC 14, that would be ok,
but not ok otherwise (you could e.g. keep the old symbol as is and add a
differently named entrypoint that used the new prototype).
But, as I wrote, the size_t vs. integer(kind=4) difference isn't the only
problem, the other is that the FUNCTION_TYPE created in the FE for the function
has just 5 arguments instead of 6 for some reason.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Can you tell whether you see other intrinsics with bad FUNCTION_TYPE?
E.g. if we have a similar issue with pack_char or pack_s_char?

In that case I have a vague idea why it happens, but do not yet know how
to solve this.

Regarding the prototype fix: would it be ok if we add an
__attribute__((unused))
to the affected-but-unused arguments, as that is already there for the
actual implementation?  And would that make a difference for the ABI?

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you e.g. put breakpoint on the spot I changed and stopon the testcase with
-Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in e->callee the
FUNCTION_TYPE with just 5 arguments.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> If you e.g. put breakpoint on the spot I changed and stopon the testcase
> with -Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in
> e->callee the FUNCTION_TYPE with just 5 arguments.

I am not too experienced to debug this kind of stuff, but I guess I've seen
what happens.  I was then wondering if one of the dump files would show the
function decl, like we can see it for normal procedures, but did not succeed.

The following (partial) patch seems to fix the decl:

diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 7880aba63bb..615d3ec98d4 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -2664,6 +2664,10 @@ gfc_resolve_spread (gfc_expr *f, gfc_expr *source,
gfc_expr *dim,
        f->value.function.name = PREFIX ("spread");
     }

+  /* Take formal argument type from SOURCE so that a function decl with the
+     right number of arguments is generated (hidden character length).  */
+  f->value.function.isym->formal->ts = source->ts;
+
   if (dim && gfc_is_constant_expr (dim)
       && ncopies && gfc_is_constant_expr (ncopies) && source->shape[0])
     {

It would be interesting to see if you see issues with the following code:

program p
  character(3) :: a = 'abc'
  real         :: b = 42.0
  complex      :: c = (2.0,0.0)
  type t
     integer :: i
  end type t
  type(t)      :: d = t(3)
  associate (y => spread(a,1,2) // "d")
  end associate
  associate (x => spread(b,1,2))
  end associate
  associate (z => spread(c,1,2))
  end associate
  associate (w => spread(d,1,2))
  end associate
end program p

The library function _gfortran_spread_char_scalar should now have 6 arguments,
while the uses of _gfortran_spread_scalar have 4 arguments, which are in part
pointers to either intrinsic or user-defined types.  I do hope that does not
lead to new problems.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor <jamborm at gcc dot gnu.org> ---
*** Bug 109759 has been marked as a duplicate of this bug. ***

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/109788] [14/15 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.