[Bug fortran/89375] fortran/expr.c:4723:5: warning: logical ‘or’ of equal expressions [-Wlogical-op]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375 --- Comment #5 from Fritz Reese --- Thanks Dominiq. On Wed, Apr 3, 2019, 05:02 dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375 > > Dominique d'Humieres changed: > >What|Removed |Added > > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #4 from Dominique d'Humieres --- > Fixed. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/82511] [7/8 Regression] ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 --- Comment #5 from Fritz Reese --- Nice! That should probably not compile. There is some trickiness because it is valid to create a RECORD variable with the same name as a STRUCTURE. I’ll get on that as well. On Fri, Oct 13, 2017, 13:49 sgk at troutmask dot apl.washington.edu < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511 > > --- Comment #4 from Steve Kargl > --- > On Fri, Oct 13, 2017 at 01:39:26AM +, foreese at gcc dot gnu.org > wrote: > > > > Fritz Reese changed: > > > > Under other DEC compilers, it seems STRUCTUREs are to be treated > consistently > > with derived types in regards to I/O lists. That is to say, a structure > > variable is treated as if each of its named components was listed on the > I/O > > list. (Even with UNIONs/MAPs, each named component is to be treated as > having > > been listed in place of the DEC RECORD containing it, so that the last > > component written to within overlapping MAPs takes effect. Yikes.) > > > > I believe both the code in the attachment and the "intended code" > (writing to > > bucket.c16 instead of bucket) should be accepted, whereas they both ICE > > currently. > > > > I will look into it. > > I actually misread the code. I thought it was > > program bug > structure /bckt/ > union > map >character*16 c16 > end map > end union > end structure > record /bckt/ bucket > character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP' > 100 format(A16) > read(rec1, 100) bckt > end program bug > > where one is trying read into the definition of the structure. > Is the above suppose to compile? Because it does. A simple > program with a Fortran derived type fails. > > type bar > integer i > end type bar > character(len=10) :: str ='123' > read(str,*) bar > end > > # gfcx -c b.f > b.f:5:21: > >read(str,*) bar > 1 > Error: Derived type 'bar' cannot be used as a variable at (1) > > I was thinking the bckt should be handled in the same manner > as bar. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 Fritz Reese changed: What|Removed |Added CC||fritzoreese at gmail dot com --- Comment #6 from Fritz Reese --- (In reply to Dominique d'Humieres from comment #5) > > Yes, fixed in r240230, I can't change the bug status myself or I would've > > This is strange: if you have write access, you should be able to change the > status. Maybe it's because I created my bugzilla account before I got write access? Is there someone I can contact to sort that out?
[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 --- Comment #4 from Fritz Reese --- Yes, fixed in r240230, I can't change the bug status myself or I would've https://gcc.gnu.org/ml/fortran/2016-09/msg00105.html On Thu, Sep 29, 2016, 21:06 dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 > > Dominique d'Humieres changed: > >What|Removed |Added > > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2016-09-30 > Ever confirmed|0 |1 > > --- Comment #3 from Dominique d'Humieres --- > Isn't this PR fixed? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/77764] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77764 Fritz Reese changed: What|Removed |Added CC||fritzoreese at gmail dot com --- Comment #2 from Fritz Reese --- https://gcc.gnu.org/ml/fortran/2016-09/msg00190.html Patch submitted
[Bug fortran/77782] ICE in gfc_get_union_type, at fortran/trans-types.c:2387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77782 --- Comment #2 from Fritz Reese --- https://gcc.gnu.org/ml/fortran/2016-09/msg00189.html Patch submitted
[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584 --- Comment #1 from Fritz Reese --- Created attachment 39618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39618&action=edit Patch for PR 77584 The attached patch fixes the issue. 2016-09-14 Fritz Reese PR fortran/77584 * gcc/fortran/decl.c (match_record_decl, gfc_match_decl_type_spec): Fixes to handling of structure/record from declaration-type-spec. * gcc/testsuite/gfortran.dg/dec_structure_15.f90: New testcase.
[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327 --- Comment #7 from Fritz Reese --- (In reply to Vittorio Zecca from comment #5) > The test case you propose, dec_structure_13.f90, does not trigger the asan > memory checker. Sorry if it was unclear, the new testcase dec_structure_13.f90 tests a separate regression that is also fixed by the patch (see the comments in my post on the mailing list). (In reply to Vittorio Zecca from comment #5) > (In reply to Fritz Reese from comment #3) > > I would appreciate > > ideas for a testcase I can commit with the aforementioned patch to > > ensure this PR isn't regressed. > As I wrote before, the test case gfortran.dg/import4.f90 does trigger > the asan memory checker. Is that sufficient then to test the regression, or need I add another testcase to my patch? (In reply to Vittorio Zecca from comment #5) > In your test case I do not understand the final statement "call > sub2(u2)" because > sub2 is not defined. That is a typo - "sub3" from dec_structure_13.f90 line 40 should be named "sub2". That's what I get for forgetting "implicit none"... (In reply to Vittorio Zecca from comment #6) > Fritz, do you have a -fsanitize=address version of gfortran, in > particular of f951? I was not aware of the capability. I will build one.
[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327 --- Comment #3 from Fritz Reese --- > interface.c:403 is > if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION) > > and I believe d->attr.flavor is the item used after freed. This is correct, and the reason is clear when you look up a few lines and realize I did not check the type of cmp1 or cmp2 before jumping straight to checking properties about their derived type declarations (in cmp->ts.u.derived). Unless cmp->ts.type == BT_DERIVED or cmp->ts.type == BT_UNION, the cmp->ts.u.derived pointer is garbage. I have a patch which implements that part of code in a different way - also correctly and more reliably. It fixes this PR and I hope to commit it over the weekend: https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html However I am not sure how one would observe that no invalid memory references occur for your code via a DejaGNU testcase. I would appreciate ideas for a testcase I can commit with the aforementioned patch to ensure this PR isn't regressed.
[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77327 Fritz Reese changed: What|Removed |Added CC||fritzoreese at gmail dot com --- Comment #2 from Fritz Reese --- Yes - thanks for the bug report and the CC. I have identified the problem, but I am contemplating some changes to the section of code in question that may supersede the fix. Give me a day or few to flesh out some things and I'll have a patch one way or the other.
[Bug fortran/71523] Static variables given automatic initializers with -finit-* and -fmax-stack-var-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71523 Fritz Reese changed: What|Removed |Added CC||fritzoreese at gmail dot com --- Comment #1 from Fritz Reese --- Created attachment 38697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38697&action=edit Patch for pr71523 Patch submitted, see https://gcc.gnu.org/ml/fortran/2016-06/msg00032.html
[Bug fortran/71523] New: Static variables given automatic initializers with -finit-* and -fmax-stack-var-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71523 Bug ID: 71523 Summary: Static variables given automatic initializers with -finit-* and -fmax-stack-var-size Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fritzoreese at gmail dot com Target Milestone: --- This bug is similar to pr41860. When a variable becomes static due to being larger than -fmax-stack-var-size, the variable is still given an automatic initializer on entry to its namespace by the -finit-* flags (-finit-integer, -finit-local-zero, etc...) This is probably an oversight due to the fact that the initializers are generated at resolution time in resolve.c, but the size of the variable is not known until translation time (in trans-decl.c). S.A. the thread at https://gcc.gnu.org/ml/fortran/2016-06/msg00023.html
[Bug fortran/71047] [7 Regression] Allocatable component of INTENT(OUT) dummy not set correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71047 --- Comment #4 from Fritz Reese --- See https://gcc.gnu.org/ml/fortran/2016-05/msg00032.html for the fix.
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #29 from Fritz Reese --- (In reply to Andreas Schwab from comment #25) > FAIL: gfortran.dg/dec_union_4.f90 -O0 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O1 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O2 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions execution test > FAIL: gfortran.dg/dec_union_4.f90 -O3 -g execution test > FAIL: gfortran.dg/dec_union_4.f90 -Os execution test It was silly of me to disregard endian-ness in this test case. Fixed: https://gcc.gnu.org/ml/fortran/2016-05/msg00018.html
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #13 from Fritz Reese --- I actually have a fairly in-depth set of testcases as part of the patch (based on lots of legacy code). More are of course welcome, but check out what I've already added as a starting point.
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #9 from Fritz Reese --- I've finally submitted my patches for a -fdec-structure option which enables STRUCTURE/RECORD and UNION/MAP support: https://gcc.gnu.org/ml/fortran/2016-03/msg2.html I have (4) patches, and had to submit the patches separately to avoid being spam-blocked: https://gcc.gnu.org/ml/fortran/2016-03/msg3.html https://gcc.gnu.org/ml/fortran/2016-03/msg4.html https://gcc.gnu.org/ml/fortran/2016-03/msg5.html https://gcc.gnu.org/ml/fortran/2016-03/msg6.html
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #7 from Fritz Reese --- FWIW I have the patches ready against the gcc-5.0.0 dev trunk, I'm just waiting on my employer's lawyer, who has been on vacation for several weeks, to sort out the legal issues. The wheels of justice spin awfully slow.
[Bug fortran/62174] Component declarations overwrite types of Cray Pointee variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174 --- Comment #3 from Fritz Reese --- > Patches should go to the gcc-patches at gcc.gnu.org mailing list (and in > case of Fortran FE patches also CC fortran at gcc.gnu.org ml). That is > where patch review happens. Sorry - submitted to the mailing lists. https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00175.html https://gcc.gnu.org/ml/fortran/2014-09/msg7.html > For a one-liner change like this, I think you > don't need Copyright assignment, but if you plan to submit further patches, > please consider following https://gcc.gnu.org/contribute.html I am working with my employer now to decide how best to comply with GNU's legal requirements for future contributions.
[Bug fortran/62309] -fno-automatic with -finit-local prevents initialization of automatics in recursive functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62309
Fritz Reese changed:
What|Removed |Added
CC||fritzoreese at gmail dot com
--- Comment #1 from Fritz Reese ---
Created attachment 33418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33418&action=edit
Patch and testcase
I believe this is a simple fix; to actually follow the specification set forth
in the man page, don't treat symbols in a RECURSIVE namespace as if they are
saved in resolve.c (apply_default_init_local):
2014-08-29 Fritz Reese
* resolve.c (apply_default_init_local): Don't treat variables in
RECURSIVE units as saved.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 43eb240..a428633 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11104,6 +11104,7 @@ apply_default_init_local (gfc_symbol *sym)
result variable, which are also nonstatic. */
if (sym->attr.save || sym->ns->save_all
|| (gfc_option.flag_max_stack_var_size == 0 && !sym->attr.result
+ && !sym->ns->proc_name->attr.recursive
&& (!sym->attr.dimension || !is_non_constant_shape_array (sym
{
/* Don't clobber an existing initializer! */
diff --git a/gcc/testsuite/gfortran.dg/auto_save_2.f90
b/gcc/testsuite/gfortran.
new file mode 100644
index 000..0d39d48
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/auto_save_2.f90
@@ -0,0 +1,52 @@
+! { dg-do run }
+! { dg-options "-fno-automatic -finit-local-zero" }
+!
+! Make sure variables are saved with -fno-automatic except in
+! functions marked RECURSIVE, and that they are still initialized with
+! -finit-local-zero.
+!
+
+function f (x)
+implicit none
+ integer f, x
+ integer a ! should be SAVEd
+ a = a + x ! should increment by y every time
+ f = a
+ return
+endfunction
+
+recursive function g (x)
+implicit none
+ integer g, x
+ integer b ! should be automatic
+ b = b + x ! should be set to y every time
+ g = b
+ return
+endfunction
+
+implicit none
+integer f, g
+
+! Should return static value of a; accumulates y
+if ( f(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( f(4) .ne. 7 ) then
+ call abort ()
+endif
+if ( f(2) .ne. 9 ) then
+ call abort ()
+endif
+
+! Should return automatic value of a; equal to y each time
+if ( g(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( g(4) .ne. 4 ) then
+ call abort ()
+endif
+if ( g(2) .ne. 2 ) then
+ call abort ()
+endif
+
+end
[Bug fortran/62309] New: -fno-automatic with -finit-local prevents initialization of automatics in recursive functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62309 Bug ID: 62309 Summary: -fno-automatic with -finit-local prevents initialization of automatics in recursive functions Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fritzoreese at gmail dot com It seems with gcc-4.8.3 -fno-automatic prevents initializers from being applied to automatic variables. The following does not behave as I would expect it to with (linux-x86-64): function f (x) implicit none integer f, x integer a ! should be SAVEd from -fno-automatic a = a + x ! should increment by y every time f = a return endfunction recursive function g (x) implicit none integer g, x integer b ! should be automatic from recursive b = b + x ! should be set to y every time g = b return endfunction implicit none integer f, g ! Should return static value of a; accumulates x print *, f(3) ! -> 3, ok print *, f(4) ! -> 7, ok print *, f(2) ! -> 2, ok ! Should return automatic value of c; equal to y each time print *, g(3) ! -> garbage, expected 3 print *, g(4) ! -> garbage, expected 4 print *, g(2) ! -> garbage, expected 2 end $ gfortran -fno-automatic -finit-local-zero auto_test.f $ ./a.out 3 7 9 32770 32771 32769 $ According to gfortran's manual page, -fno-automatic should "Treat each program unit (except those marked as RECURSIVE) as if the "SAVE" statement were specified for every local variable [...]". As far as I can tell, -finit-local-zero should still initialize automatic variables in RECURSIVE functions.
[Bug fortran/62174] New: Component declarations overwrite types of Cray Pointee variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174
Bug ID: 62174
Summary: Component declarations overwrite types of Cray Pointee
variables
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: fritzoreese at gmail dot com
Created attachment 33353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33353&action=edit
Proposed patch for the described problem
The typespecs for Cray pointees are overwritten by the typespecs of components
with the same name which are declared later.
This problem was introduced with Cray pointer support in 4.1.0 and is present
as far as I can tell up through the current release.
Here is a proposed patch from 4.8.3. The added test case demonstrates the
problem:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4048ac9..7b3c59a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1904,8 +1904,9 @@ variable_decl (int elem)
}
/* If this symbol has already shown up in a Cray Pointer declaration,
+ and this is not a component declaration,
then we want to set the type & bail out. */
- if (gfc_option.flag_cray_pointer)
+ if (gfc_option.flag_cray_pointer && gfc_current_state () != COMP_DERIVED)
{
gfc_find_symbol (name, gfc_current_ns, 1, &sym);
if (sym != NULL && sym->attr.cray_pointee)
diff --git a/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
b/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
new file mode 100644
index 000..fcc0132
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-fcray-pointer" }
+!
+! Since the introduction of Cray pointers in 4.1.0 as late as 4.8.3,
+! component declarations within derived types would overwrite the typespec of
+! variables with the same name who were Cray pointees.
+implicit none
+
+type t1
+ integer i
+end type t1
+type(t1) x
+
+pointer (x_ptr, x)
+
+type t2
+ real x ! should not overwrite x's type
+end type t2
+
+x%i = 0 ! should see no error here
+
+end
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 53d2691..8d8f9d5 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,8 @@
+2014-08-18 Fritz Reese
+
+* decl.c (variable_decl): Don't overwrite typesepc of Cray pointees
+when matching a component declaration.
+
2014-08-17 Tobias Burnus
* resolve.c (gfc_resolve_finalizers): Ensure that parents are
