* [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
2023-05-09 12:17 [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
@ 2023-05-09 12:31 ` marxin at gcc dot gnu.org
2023-05-09 12:44 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-05-09 12:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
2023-05-09 12:31 ` [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
@ 2023-05-09 12:44 ` jakub at gcc dot gnu.org
2023-05-09 12:58 ` [Bug fortran/109788] " jakub at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-09 12:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
2023-05-09 12:31 ` [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
2023-05-09 12:44 ` jakub at gcc dot gnu.org
@ 2023-05-09 12:58 ` jakub at gcc dot gnu.org
2023-05-09 13:10 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-09 12:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (2 preceding siblings ...)
2023-05-09 12:58 ` [Bug fortran/109788] " jakub at gcc dot gnu.org
@ 2023-05-09 13:10 ` jakub at gcc dot gnu.org
2023-05-10 7:05 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-09 13:10 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (3 preceding siblings ...)
2023-05-09 13:10 ` jakub at gcc dot gnu.org
@ 2023-05-10 7:05 ` rguenth at gcc dot gnu.org
2023-05-10 11:21 ` cvs-commit at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-10 7:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (4 preceding siblings ...)
2023-05-10 7:05 ` rguenth at gcc dot gnu.org
@ 2023-05-10 11:21 ` cvs-commit at gcc dot gnu.org
2023-05-10 11:23 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-10 11:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (5 preceding siblings ...)
2023-05-10 11:21 ` cvs-commit at gcc dot gnu.org
@ 2023-05-10 11:23 ` jakub at gcc dot gnu.org
2023-05-10 18:47 ` anlauf at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-10 11:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (6 preceding siblings ...)
2023-05-10 11:23 ` jakub at gcc dot gnu.org
@ 2023-05-10 18:47 ` anlauf at gcc dot gnu.org
2023-05-10 18:53 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-10 18:47 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (7 preceding siblings ...)
2023-05-10 18:47 ` anlauf at gcc dot gnu.org
@ 2023-05-10 18:53 ` jakub at gcc dot gnu.org
2023-05-10 18:55 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-10 18:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (8 preceding siblings ...)
2023-05-10 18:53 ` jakub at gcc dot gnu.org
@ 2023-05-10 18:55 ` jakub at gcc dot gnu.org
2023-05-10 21:40 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-10 18:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (9 preceding siblings ...)
2023-05-10 18:55 ` jakub at gcc dot gnu.org
@ 2023-05-10 21:40 ` anlauf at gcc dot gnu.org
2023-05-10 21:46 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-10 21:40 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (10 preceding siblings ...)
2023-05-10 21:40 ` anlauf at gcc dot gnu.org
@ 2023-05-10 21:46 ` jakub at gcc dot gnu.org
2023-05-12 19:41 ` anlauf at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-10 21:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (11 preceding siblings ...)
2023-05-10 21:46 ` jakub at gcc dot gnu.org
@ 2023-05-12 19:41 ` anlauf at gcc dot gnu.org
2023-05-17 8:44 ` jamborm at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-05-12 19:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (12 preceding siblings ...)
2023-05-12 19:41 ` anlauf at gcc dot gnu.org
@ 2023-05-17 8:44 ` jamborm at gcc dot gnu.org
2023-10-17 10:34 ` rguenth at gcc dot gnu.org
2024-05-07 7:40 ` [Bug fortran/109788] [14/15 " rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: jamborm at gcc dot gnu.org @ 2023-05-17 8:44 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (13 preceding siblings ...)
2023-05-17 8:44 ` jamborm at gcc dot gnu.org
@ 2023-10-17 10:34 ` rguenth at gcc dot gnu.org
2024-05-07 7:40 ` [Bug fortran/109788] [14/15 " rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-17 10:34 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
2023-05-09 12:17 [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
` (14 preceding siblings ...)
2023-10-17 10:34 ` rguenth at gcc dot gnu.org
@ 2024-05-07 7:40 ` rguenth at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread