[Patch] Fortran: Fix 'name' bound size [PR99688]
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: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
Fortran: Fix 'name' bound size [PR99688]
gcc/fortran/ChangeLog:
PR fortran/99688
* match.c (select_type_set_tmp, gfc_match_select_type,
(gfc_match_select_rank): Fix 'name' buffersize to avoid out of bounds.
* resolve.c (resolve_select_type): Likewise.
/lhome/tburnus/repos/gcc/gcc/fortran
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..29462013038 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6330,7 +6332,7 @@ select_intrinsic_set_tmp (gfc_typespec *ts)
static void
select_type_set_tmp (gfc_typespec *ts)
{
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 12 + 1];
gfc_symtree *tmp = NULL;
gfc_symbol *selector = select_type_stack->selector;
gfc_symbol *sym;
@@ -6409,7 +6411,7 @@ gfc_match_select_type (void)
{
gfc_expr *expr1, *expr2 = NULL;
match m;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 1];
bool class_array;
gfc_symbol *sym;
gfc_namespace *ns = gfc_current_ns;
@@ -6634,7 +6636,7 @@ gfc_match_select_rank (void)
{
gfc_expr *expr1, *expr2 = NULL;
match m;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym, *sym2;
gfc_namespace *ns = gfc_current_ns;
gfc_array_spec *as = NULL;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 32015c21efc..715fecd4b3a 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9246,7 +9246,7 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
gfc_code *class_is = NULL, *default_case = NULL;
gfc_case *c;
gfc_symtree *st;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 12 + 1];
gfc_namespace *ns;
int error = 0;
int rank = 0;
A doubt about lbound and ubound of an array inside a coarray
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 array entry.
Is this ok and did I miss something here?
Thanks in advance for some clarification.
Regards.
Jorge.
$ which gfortran
/usr/beta/gcc-trunk/bin/gfortran
$ gfortran --version
GNU Fortran (GCC) 11.0.1 20210315 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
$ which ompi_info
/usr/beta/openmpi/bin/ompi_info
$ ompi_info
...
/usr/beta/gcc-trunk/bin/gfortran
$ mpifort -Wall -Wextra -g -fcoarray=lib doubt1.f90 -o doubt1-openmpi.exe
-L/usr/beta/opencoarrays-openmpi/lib64 -lcaf_mpi -lopencoarrays_mod -lmpi
$ mpirun --mca pml ucx --mca osc ucx -np 4 --mca btl vader,self,tcp
--machinefile ${HOME}/machi-openmpi.dat --map-by node --map-by slot --map-by
core --bind-to l2cache --mca orte_base_help_aggregate 0 --report-bindings
--display-allocation --display-devel-map doubt1-openmpi.exe
== ALLOCATED NODES ==
flags=0x11 slots=16 max_slots=16 slots_inuse=0 state=UP
=
Data for JOB [53806,1] offset 0 Total slots allocated 16
Mapper requested: NULL Last mapper: round_robin Mapping policy:
BYCORE:NOOVERSUBSCRIBE Ranking policy: CORE
Binding policy: L2CACHE Cpu set: NULL PPR: NULL Cpus-per-rank: 0
Num new daemons: 0New daemon starting vpid INVALID
Num nodes: 1
Data for node: State: 3Flags: 11
Daemon: [[53806,0],0]Daemon launched: True
Num slots: 16Slots in use: 4Oversubscribed: FALSE
Num slots allocated: 16Max slots: 16
Num procs: 4Next node_rank: 4
Data for proc: [[53806,1],0]
Pid: 0Local rank: 0Node rank: 0App
rank: 0
State: INITIALIZEDApp_context: 0
Locale: [BB/../../..]
Binding: [BB/../../..]
Data for proc: [[53806,1],1]
Pid: 0Local rank: 1Node rank: 1App
rank: 1
State: INITIALIZEDApp_context: 0
Locale: [../BB/../..]
Binding: [../BB/../..]
Data for proc: [[53806,1],2]
Pid: 0Local rank: 2Node rank: 2App
rank: 2
State: INITIALIZEDApp_context: 0
Locale: [../../BB/..]
Binding: [../../BB/..]
Data for proc: [[53806,1],3]
Pid: 0Local rank: 3Node rank: 3App
rank: 3
State: INITIALIZEDApp_context: 0
Locale: [../../../BB]
Binding: [../../../BB]
[55028] MCW rank 0 bound to socket 0[core 0[hwt 0-1]]: [BB/../../..]
[55028] MCW rank 1 bound to socket 0[core 1[hwt 0-1]]: [../BB/../..]
[55028] MCW rank 2 bound to socket 0[core 2[hwt 0-1]]: [../../BB/..]
[55028] MCW rank 3 bound to socket 0[core 3[hwt 0-1]]: [../../../BB]
ti h lbound(aa%oo,1) ubound(aa%oo,1) lbound(aa%oo,2) ubound(aa%oo,2)
1 1 1 2 1 2
3 1 1 2 1 2
4 1 1 2 1 2
2 1 1 2 1 2
2 2 1 3 1 3
1 2 1 3 1 3
4 2 1 3 1 3
3 2 1 3 1 3
3 3 1 4 1 4
2 3 1 4 1 4
1 3 1 4 1 4
4 3 1 4 1 4
4 4 1 5 1 5
3 4 1 5 1 5
2 4 1 5 1 5
1 4 1 5 1 5
ti h aa[h]%i1 aa[h]%i2 aa[h]%j1 aa[h]%j1 aa[h]%j2
1 1 2 3 4 5
2 1 2 3 4 5
2 2 8 10 12 14
1 2 8 10 12 14
2 3 14 17 20 23
2 4 20 24 28 32
3
valgrind & f951
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 JoinedOrMissing Negative(gdwarf-)
Generate debug information in default version of DWARF format.
gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
Generate debug information in DWARF v2 (or later) format.
gdwarf32
However, I am still seeing issues probably in the backend even for the
simplest code, such as
i = 1
end
which is annoying:
==29099== Memcheck, a memory error detector
==29099== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29099== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==29099== Command: /opt/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.0.1/f951 foo.f90
==29099==
MAIN__ main
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 4096k} {heap 4096k}
{heap 4096k} {heap 4096k} {heap 4096k}
{heap 4096k} {heap 4096k}Streaming LTO
{heap 4096k} {heap 4096k} {heap 4096k}
{heap 4096k} {heap 4096k} {heap 4096k}
{heap 4096k}Assembling functions:
{heap 4096k} MAIN__ main==29099== Conditional jump or move depends
on uninitialised value(s)
==29099==at 0xBCB62E: sparseset_bit_p (sparseset.h:146)
==29099==by 0xBCB62E: mark_pseudo_regno_live(int) (ira-lives.c:326)
==29099==by 0xBCD270: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1433)
==29099==by 0xBAE40D: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
==29099==by 0xBCDD8F: ira_create_allocno_live_ranges() (ira-lives.c:1733)
==29099==by 0xBB0149: ira_build() (ira-build.c:3428)
==29099==by 0xBA615C: ira (ira.c:5654)
==29099==by 0xBA615C: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5977)
==29099==by 0xCC4353: execute_one_pass(opt_pass*) (passes.c:2567)
==29099==by 0xCC4C70: execute_pass_list_1(opt_pass*) (passes.c:2656)
==29099==by 0xCC4C82: execute_pass_list_1(opt_pass*) (passes.c:2657)
==29099==by 0xCC4CC4: execute_pass_list(function*, opt_pass*)
(passes.c:2667)
==29099==by 0x8E8C95: cgraph_node::expand() (cgraphunit.c:1830)
==29099==by 0x8EA3C7: output_in_order (cgraphunit.c:2141)
==29099==by 0x8EA3C7: symbol_table::compile() [clone .part.62]
(cgraphunit.c:2359)
...
==29099== Use of uninitialised value of size 8
==29099==at 0xBCB633: sparseset_bit_p (sparseset.h:146)
==29099==by 0xBCB633: mark_pseudo_regno_live(int) (ira-lives.c:326)
==29099==by 0xBCD270: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1433)
==29099==by 0xBAE40D: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
==29099==by 0xBCDD8F: ira_create_allocno_live_ranges() (ira-lives.c:1733)
==29099==by 0xBB0149: ira_build() (ira-build.c:3428)
==29099==by 0xBA615C: ira (ira.c:5654)
==29099==by 0xBA615C: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5977)
==29099==by 0xCC4353: execute_one_pass(opt_pass*) (passes.c:2567)
==29099==by 0xCC4C70: execute_pass_list_1(opt_pass*) (passes.c:2656)
==29099==by 0xCC4C82: execute_pass_list_1(opt_pass*) (passes.c:2657)
==29099==by 0xCC4CC4: execute_pass_list(function*, opt_pass*)
(passes.c:2667)
==29099==by 0x8E8C95: cgraph_node::expand() (cgraphunit.c:1830)
==29099==by 0x8EA3C7: output_in_order (cgraphunit.c:2141)
==29099==by 0x8EA3C7: symbol_table::compile() [clone .part.62]
(cgraphunit.c:2359)
...
and I get tons of the above.
This is not a bootstrap-build compiler; it was configured with
--disable-bootstrap.
Could this be the reason for the above? I would really prefer to no do a full
bootstrap since I am interested only in the development of the Fortran-related
parts of the compiler?
Any insights appreciated.
Thanks,
Harald
Re: [Patch] Fortran: Fix 'name' bound size [PR99688]
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_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: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, &expr2);
Re: valgrind & f951
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 Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
you could also just use "-g -gdwarf-4" on the command line.
{heap 4096k} MAIN__ main==29099== Conditional jump or move
depends on uninitialised value(s)
==29099==at 0xBCB62E: sparseset_bit_p (sparseset.h:146)
This is a false positive; you need to configure GCC with
|--enable-valgrind-annotations, see
https://gcc.gnu.org/install/configure.html|I would really prefer to no
do a full
bootstrap since I am interested only in the development of the Fortran-related
parts of the compiler?
If you don't bootstrap, be careful about compiler warnings as the
bootstrap compiler runs with -Werror in stage2 & 3.
Tobias
