When libgfortran is compiled, there are some -Woverflow warnings like
../../../libgfortran/generated/maxloc0_4_m1.c:99:14: warning: unsigned conversion from ‘int’ to ‘GFC_UINTEGER_1’ {aka ‘unsigned char’} changes value from ‘-255’ to ‘1’ [-Woverflow]
99 | maxval = -GFC_UINTEGER_1_HUGE;
| ^
and those actually point a bug in the maxloc*/maxval* implementation
for UNSIGNED.
The intent of
#if defined ('atype_inf`)
result = -atype_inf;
#else
result = atype_min;
#endif
(or similar for maxval) is to initialize the variable with
minimum value of the type, if the type has infinities, then
negative infinity, otherwise the minimum (normalized) value.
atype_min expands for signed integers to say (-GFC_INTEGER_4_HUGE-1)
or for floating point to say -GFC_REAL_8_HUGE.
For UNSIGNED it expands to e.g. -GFC_UINTEGER_4_HUGE, but that is
-0xffffffffU which is 1U, while the minimum value of the type is
0.
Haven't tried to construct testcases for that, but I believe e.g.
maskval could return incorrectly 1 on an array (or masked array)
full of 0s, or maxloc could identify incorrectly the maximum location.
The following patch makes sure atype_min expands to 0 for atype_name
GFC_UINTEGER*.
2025-05-07 Jakub Jelinek <jakub@redhat.com>
PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
* generated/maxloc0_16_m1.c: Regenerate.
* generated/maxloc0_16_m2.c: Regenerate.
* generated/maxloc0_16_m4.c: Regenerate.
* generated/maxloc0_16_m8.c: Regenerate.
* generated/maxloc0_16_m16.c: Regenerate.
* generated/maxloc0_4_m1.c: Regenerate.
* generated/maxloc0_4_m2.c: Regenerate.
* generated/maxloc0_4_m4.c: Regenerate.
* generated/maxloc0_4_m8.c: Regenerate.
* generated/maxloc0_4_m16.c: Regenerate.
* generated/maxloc0_8_m1.c: Regenerate.
* generated/maxloc0_8_m2.c: Regenerate.
* generated/maxloc0_8_m4.c: Regenerate.
* generated/maxloc0_8_m8.c: Regenerate.
* generated/maxloc0_8_m16.c: Regenerate.
* generated/maxloc1_16_m1.c: Regenerate.
* generated/maxloc1_16_m2.c: Regenerate.
* generated/maxloc1_16_m4.c: Regenerate.
* generated/maxloc1_16_m8.c: Regenerate.
* generated/maxloc1_16_m16.c: Regenerate.
* generated/maxloc1_4_m1.c: Regenerate.
* generated/maxloc1_4_m2.c: Regenerate.
* generated/maxloc1_4_m4.c: Regenerate.
* generated/maxloc1_4_m8.c: Regenerate.
* generated/maxloc1_4_m16.c: Regenerate.
* generated/maxloc1_8_m1.c: Regenerate.
* generated/maxloc1_8_m2.c: Regenerate.
* generated/maxloc1_8_m4.c: Regenerate.
* generated/maxloc1_8_m8.c: Regenerate.
* generated/maxloc1_8_m16.c: Regenerate.
* generated/maxval_m1.c: Regenerate.
* generated/maxval_m2.c: Regenerate.
* generated/maxval_m4.c: Regenerate.
* generated/maxval_m8.c: Regenerate.
* generated/maxval_m16.c: Regenerate.
While looking at PR120152, I have noticed that libgfortran.so doesn't
export 5 *m16* symbols I would have expected that should be exported.
This is caused by 2 issues, one filename was forgotten to be added in r15-4124
to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept in the
position after generated/maxloc1_8_m16.c and the i -> m difference wasn't
spotted), and one some garbage prefix on HAVE_GFC_UINTEGER_16 macro.
The first two hunks of this patch fix that.
Though, as GCC 15.1 has been released already, we can't add these symbols
to GFORTRAN_15 symbol version as they've never been there, so the patch
adds them to a new GFORTRAN_15.2 symbol version instead.
2025-05-07 Jakub Jelinek <jakub@redhat.com>
PR libfortran/120153
* Makefile.am (i_maxloc1_c): Add generated/maxloc1_16_m16.c.
* intrinsics/random.c (arandom_m16): Use #ifdef HAVE_GFC_UINTEGER_16
guard rather than #ifdef GFC_HAVE_GFC_UINTEGER_16.
* gfortran.map (GFORTRAN_15): Remove _gfortran_arandom_m16,
_gfortran_maxloc1_16_m16, _gfortran_mmaxloc1_16_m16 and
_gfortran_smaxloc1_16_m16.
(GFORTRAN_15.2): New symbol version, add those 4 symbols to it.
* generated/maxloc1_16_m16.c: New file.
* Makefile.in: Regenerate.
