The gfc_match_select_rank issue showed up in the testsuite
and was found by Martin's asan-bootstrapped GCC. First
analysis by Harald – thanks to both!
However, I think the other variables I fixed were also
prone to overflows; see below for its usage.
OK for mainline? Other branches?
Tobias
PS:
Hi all,
I have a doubt about lbound and bound in the test below
using gfortran with opencoarrays, gasnet, and openmpi.
With the AA coarray (each AA entry is a 2D array),
the values obtained with lbound and ubound are different
from the initial and final values arbitrarily defined for
each ar
Dear all,
in order to be able to run f951 under valgrind on OpenSuse Leap 15.2,
I've already reduced the dwarf version back to 4,
diff --git a/gcc/common.opt b/gcc/common.opt
index c75dd36843e..7dbfcb589ed 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3171,7 +3171,7 @@ Common Driver Joined
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
The gfc_match_se
Hi Harald,
On 21.03.21 20:50, Harald Anlauf via Fortran wrote:
in order to be able to run f951 under valgrind on OpenSuse Leap 15.2,
I've already reduced the dwarf version back to 4,
+++ b/gcc/common.opt
-Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
+Common Driver Jo
