On 10/31/21 1:50 PM, Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check
On Fri, 29 Oct 2021 22:09:07 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 29 Oct 2021 21:36:26 +0200
> Harald Anlauf via Gcc-patches wrote:
>
> > Dear Bernhard, all,
> >
> > Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> >
> > >> diff --git a/gcc/fortran/symbol.
Dear Fortranners,
the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays, or showed
up in valgrind as invalid reads, all of which seemed to be related
On Sun, 31 Oct 2021 20:46:07 +0100
Harald Anlauf wrote:
> Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
> >>> The only caller is translate_all_program_units.
> >>> Since we free only module gsyms, even -fdump-fortran-global is
> >>> unaffected by this, fwiw.
> >
> > AFAICS
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check the left operator if the right one was faulty.
c407b-2
Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
The only caller is translate_all_program_units.
Since we free only module gsyms, even -fdump-fortran-global is
unaffected by this, fwiw.
AFAICS we do not have a test for -fdump-fortran-global
Do we want to add one, would the att
On Sun, 31 Oct 2021 18:05:36 +0100
Thomas Koenig wrote:
> Hi Bernhard,
>
> > gcc/fortran/ChangeLog:
> >
> > * resolve.c (resolve_fl_procedure): Initialize
> > allocatable_or_pointer.
>
> Looking at the code, it is clear that this is a false
> positive, or a false maybe, but the seman
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/100972
* decl.c (gfc_match_implicit_none): Fix typo in warning.
* resolve.c (resolve_unknown_f): Reject external procedures
without explicit EXTERNAL attribute whe IMPLICIT none (external)
is
Hi Bernhard,
gcc/fortran/ChangeLog:
* resolve.c (resolve_fl_procedure): Initialize
allocatable_or_pointer.
Looking at the code, it is clear that this is a false
positive, or a false maybe, but the semantics of C/C++
may well indicate that sym->result could change, although
i
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* resolve.c (resolve_fl_procedure): Initialize
allocatable_or_pointer.
---
fortran/resolve.c: In function 'bool resolve_fl_procedure(gfc_symbol*, int)':
fortran/resolve.c:13391:7: warning: 'allocatable_or_pointer' may be used
Hi,
I have put together a summary of what users should see
as a change. I've made this a diff against the current
documentation. This is an RFC, please feel free to
suggest any changes.
I have put in a few remarks among the diff.
If there is general agreement that this is the best way forward
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/99884
* io.c (check_open_constraints): Remove double spaces.
---
gcc/fortran/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index fc97df79eca..9506f3500
12 matches
Mail list logo