Re: [patch, fortran] First part of Fortran's unsigned implementation
Hi Thomas,
may I ask you to run contrib/check_GNU_style.py on your patch? At least on my
system more than lines 50 are reported. I am drawn to this style issues and find
it hard to digest the beef of the patch. That's my personal OCD unfortunately.
Furthermore (Sorry, I inserted your w/o cite and noted that after it was too
late. I have prefixed my remarks/questions with AV: to make them easier to
find. I hope this helps):
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 2f50d84b876..1020ba5342f 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -7637,3 +7960,12 @@ gfc_check_storage_size (gfc_expr *a, gfc_expr *kind)
return true;
}
+
+/* Check two operands that either both or none of them can
+ be UNSIGNED. */
+
+bool
+gfc_invalid_unsigned_ops (gfc_expr * op1, gfc_expr * op2)
+{
+ return (op1->ts.type == BT_UNSIGNED) + (op2->ts.type == BT_UNSIGNED) == 1;
AV: That's an interesting way to model an xor. Why not `op1.. ^ op2..`? Yes,
it's bitwise, but on bools.
+}
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 7e8783a3690..9043fa321dc 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2701,7 +2702,90 @@ descriptor occurred, use @code{INQUIRE} to get the file
position, count the characters up to the next @code{NEW_LINE} and then start
reading from the position marked previously.
+@node Experimental features for Fortran 202Y
+@section Experimental features for Fortran 202Y
+@cindex Fortran 202Y
+GNU Fortran supports some experimental features which have been
+proposed and accepted by the J3 standards committee. These
+exist to give users a chance to try them out, and to provide
+a reference implementation.
+
+As these features have not been finalized, there is a chance that the
+version in the upcoming standard will differ from what GNU Fortran
+currently implements. Stability of these implementations is therefore
+not guaranteed.
+
+@menu
+* Unsigned integers::
+@end menu
+
+@node Unsigned integers
+@subsection Unsigned integers
+@cindex Unsigned integers
+GNU Fortran supports unsigned integers according to
+@uref{https://j3-fortran.org/doc/year/24/24-116.txt, J3/24-116}. The
+data type is called @code{UNSIGNED}. For an unsigned type with $n$ bits,
+it implements integer arithmetic modulo @code{2**n}, comparable to the
+@code{unsigned} data type in C.
+
+The data type has @code{KIND} numbers comparable to other Fortran data
+types, which can be selected via the @code{SELECTED_UNSIGNED_KIND}
+function.
+
+Mixed arithmetic, comparisoins and assignment between @code{UNSIGNED}
AV: ... comparisons ...
+and other types are only possible via explicit conversion. Conversion
+from @code{UNSIGNED} to other types is done via type conversion
+functions like @code{INT} or @code{REAL}. Conversion from other types
+to @code{UNSIGNED} is done via @code{UINT}. Unsigned variables cannot be
+used as index variables in @code{DO} loops or as array indices.
+
+Unsigned numbers have a trailing @code{u} as suffix, optionally followed
+by a @code{KIND} number separated by an underscore.
+
+Input and output can be done using the @code{I}, @code{B}, @code{O}
+and @code{Z} descriptors, plus unformatted I/O.
+
+Here is a small, somewhat contrived example of their use:
+@smallexample
+program main
+ unsigned(kind=8) :: v
+ v = huge(v) - 32u_8
+ print *,v
+end program main
+@end smallexample
+which will output the number 18446744073709551583.
+
+Arithmetic operations work on unsigned integers, except for exponentiation,
+which is prohibited. Unary minus is not permitted when @code{-predantic}
AV: ... @code{-pedantic}
+is in force; this prohibition is part of J3/24-116.txt.
+
+Generally, unsigned integers are only permitted as data in intrinsics.
+
+Unsigned numbers can be read and written using list-directed,
+formatted and unformatted I/O. For formatted I/O, the @code{B},
+@code{I}, @code{O} and @code{Z} descriptors are valid. Negative
+values and values which would overflow are rejected with
+@code{-pedantic}.
+
+As of now, the following intrinsics take unsigned arguments:
+@itemize @bullet
+@item @code{BLT}, @code{BLE}, @code{BGE} and @code{BGT}. These intrinsics
+ are actually redundant because comparison operators could be used
+ directly.
+@item @code{IAND}, @code{IOR}, @code{IEOR} and @code{NOT}
+@item @code{BIT_SIZE}, @code{DIGITS} and @code{HUGE}
+@item @code{DSHIFTL} and @code{DSHIFTR}
+@item @code{IBCLR}, @code{IBITS} and @code{IBITS}
AV: IBITS and IBITS ???
+@item @code{MIN} and @code{MAX}
+@item @code{ISHFT}, @code{ISHFTC}, @code{SHIFTL}, @code{SHIFTR} and
@code{SHIFTA}. +@item @code{MERGE_BITS}
+@item @code{MOD} and @code{MODULO}
+@item @code{MVBITS}
+@item @code{RANGE}
+@item @code{TRANSFER}
+@end itemize
+This list will grow in the near future.
@c -
@c -
@c Mixed-Languag
[Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc
Hi all,
attached patch fixes a regression introduced by my previous patch on handling
_vptr's more consistently. The patch gets the _vptr only of a derived or
class type now and not of every type.
Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
PS. This patch was made with all of my other pending patches on the same
branch. So it may not apply clean to master.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4b19d871a3f5a4cdaf0fef6200ddaf51d6c8a8c4 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 9 Aug 2024 16:19:23 +0200
Subject: [PATCH] [Fortran] Fix ICE in build_function_decl [PR116292]
Fix ICE by getting the vtype only when a derived or class type is
prevent. Also take care about the _len component for unlimited
polymorphics.
gcc/fortran/ChangeLog:
PR fortran/116292
* trans-intrinsic.cc (conv_intrinsic_move_alloc): Get the vtab
only for derived types and classes and adjust _len for class
types.
gcc/testsuite/ChangeLog:
* gfortran.dg/move_alloc_19.f90: New test.
---
gcc/fortran/trans-intrinsic.cc | 20 ++--
gcc/testsuite/gfortran.dg/move_alloc_19.f90 | 34 +
2 files changed, 51 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/move_alloc_19.f90
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 34115c2679b..0ecb0439778 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -12774,9 +12774,12 @@ conv_intrinsic_move_alloc (gfc_code *code)
gfc_symbol *vtab;
from_tree = from_se.expr;
- vtab = gfc_find_vtab (&from_expr->ts);
- gcc_assert (vtab);
- from_se.expr = gfc_get_symbol_decl (vtab);
+ if (to_expr->ts.type == BT_CLASS)
+ {
+ vtab = gfc_find_vtab (&from_expr->ts);
+ gcc_assert (vtab);
+ from_se.expr = gfc_get_symbol_decl (vtab);
+ }
}
gfc_add_block_to_block (&block, &from_se.pre);
@@ -12821,6 +12824,15 @@ conv_intrinsic_move_alloc (gfc_code *code)
gfc_class_set_vptr (&block, to_se.expr, from_se.expr);
if (from_is_class)
gfc_reset_vptr (&block, from_expr);
+ if (UNLIMITED_POLY (to_expr))
+ {
+ tree to_len = gfc_class_len_get (to_se.class_container);
+ tmp = from_expr->ts.type == BT_CHARACTER && from_se.string_length
+ ? from_se.string_length
+ : size_zero_node;
+ gfc_add_modify_loc (input_location, &block, to_len,
+ fold_convert (TREE_TYPE (to_len), tmp));
+ }
}
if (from_is_scalar)
@@ -12835,6 +12847,8 @@ conv_intrinsic_move_alloc (gfc_code *code)
input_location, &block, from_se.string_length,
build_int_cst (TREE_TYPE (from_se.string_length), 0));
}
+ if (UNLIMITED_POLY (from_expr))
+ gfc_reset_len (&block, from_expr);
return gfc_finish_block (&block);
}
diff --git a/gcc/testsuite/gfortran.dg/move_alloc_19.f90 b/gcc/testsuite/gfortran.dg/move_alloc_19.f90
new file mode 100644
index 000..d23d9809ba1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/move_alloc_19.f90
@@ -0,0 +1,34 @@
+!{ dg-do run }
+
+! Check PR 116292 is fixed.
+
+! Contributed by Harald Anlauf
+!Sam James
+
+program move_alloc_19
+ character, allocatable :: buffer, dummy, dummy2
+ class(*), allocatable :: poly
+
+ dummy = 'C'
+ dummy2 = 'A'
+ call s()
+ if (allocated (dummy)) stop 1
+ if (allocated (dummy2)) stop 2
+ if (.not. allocated (buffer)) stop 3
+ if (.not. allocated (poly)) stop 4
+ if (buffer /= 'C') stop 5
+ select type (poly)
+type is (character(*))
+ if (poly /= 'A') stop 6
+ if (len (poly) /= 1) stop 7
+class default
+ stop 8
+ end select
+ deallocate (poly, buffer)
+contains
+ subroutine s
+call move_alloc (dummy, buffer)
+call move_alloc (dummy2, poly)
+ end
+end
+
--
2.46.0
Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc
Hi Andre, attached patch fixes a regression introduced by my previous patch on handling _vptr's more consistently. The patch gets the _vptr only of a derived or class type now and not of every type. Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? OK (and looks obvious, too). Best regards Thomas
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
On Mon, Aug 5, 2024 at 6:25 PM Sergey Fedorov wrote: > > On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > >> Can you post an updated version of the patch, following the first round >> of review? >> >> FX > > If you got some time, please review this. I will likely be away from my PowerPC hardware from next week for some time. If we could wrap this up by then, it would be great. (What is the release schedule for gcc15? My concern is not to miss the deadline, so that we have it in gcc15.) Sergey
[Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case
Hi all,
attached patch is the last one the meta-bug 87477 ASSOCIATE depends on. The
resolution was already given in the PR, so I just beautified it and made patch
for it. I tried to come up with a testcase as well as Harald has, but had no
luck with it. I see less harm in reseting the flag in the error case than not
to do it.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 02e96672b2c9891ade40497298e2c69652e3d321 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 13 Aug 2024 15:06:56 +0200
Subject: [PATCH] [Fortran] Prevent future proc_ptr parsing issues in associate
[PR102973]
A global variable is set when proc_ptr parsing in an associate is
expected. In the case of an error, that flag was not reset, which is
fixed now.
gcc/fortran/ChangeLog:
PR fortran/102973
* match.cc (gfc_match_associate): Reset proc_ptr parsing flag on
error.
---
gcc/fortran/match.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 4acdb146439..d30a98f48fa 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -1932,6 +1932,7 @@ gfc_match_associate (void)
gfc_matching_procptr_assignment = 1;
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
+ gfc_matching_procptr_assignment = 0;
gfc_error ("Invalid association target at %C");
goto assocListError;
}
--
2.46.0
Re: [Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case
Hi Andre, Am 13.08.24 um 15:15 schrieb Andre Vehreschild: Hi all, attached patch is the last one the meta-bug 87477 ASSOCIATE depends on. The resolution was already given in the PR, so I just beautified it and made patch for it. I tried to come up with a testcase as well as Harald has, but had no luck with it. I see less harm in reseting the flag in the error case than not to do it. this is much simpler than Berhhard's patch while functionally equivalent and good for mainline. Thanks for taking care of the issue! Harald Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Hi, > I dropped a change to the test file, since you have fixed it appropriately, > and switched to Apple libm convention for flags, as you have suggested. > Please let me know if I should do anything further to improve it and make it > acceptable for a merge. The patch itself is OK. Please add a ChangeLog entry fitting the GCC format (see prior commits in libgfortran/ for examples). FX
[PATCH] Fortran: reject array constructor value of abstract type [PR114308]
Dear all,
the attached patch checks whether the declared type of an array constructor
value is abstract, which is forbidden by the standard.
Steve found the relevant constraint in F2023, but it exists already in F2018.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 9988d7e004796ab531df7bcda45788a7aa9276d7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 13 Aug 2024 19:17:36 +0200
Subject: [PATCH] Fortran: reject array constructor value of abstract type
[PR114308]
gcc/fortran/ChangeLog:
PR fortran/114308
* array.cc (resolve_array_list): Reject array constructor value if
its declared type is abstract (F2018:C7114).
gcc/testsuite/ChangeLog:
PR fortran/114308
* gfortran.dg/abstract_type_10.f90: New test.
Co-Authored-By: Steven G. Kargl
---
gcc/fortran/array.cc | 13
.../gfortran.dg/abstract_type_10.f90 | 30 +++
2 files changed, 43 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/abstract_type_10.f90
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 79c774d59a0..a5e94f1fa77 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -2127,6 +2127,19 @@ resolve_array_list (gfc_constructor_base base)
"polymorphic [F2008: C4106]", &c->expr->where);
t = false;
}
+
+ /* F2018:C7114 The declared type of an ac-value shall not be abstract. */
+ if (c->expr->ts.type == BT_CLASS
+ && c->expr->ts.u.derived
+ && c->expr->ts.u.derived->attr.abstract
+ && CLASS_DATA (c->expr))
+ {
+ gfc_error ("Array constructor value %qs at %L is of the ABSTRACT "
+ "type %qs", c->expr->symtree->name, &c->expr->where,
+ CLASS_DATA (c->expr)->ts.u.derived->name);
+ t = false;
+ }
+
}
return t;
diff --git a/gcc/testsuite/gfortran.dg/abstract_type_10.f90 b/gcc/testsuite/gfortran.dg/abstract_type_10.f90
new file mode 100644
index 000..a4bf65d4e12
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/abstract_type_10.f90
@@ -0,0 +1,30 @@
+! { dg-do compile }
+!
+! PR fortran/114308 - reject array constructor value of abstract type
+
+module my_module
+ implicit none
+ private
+
+ type, abstract, public :: a
+ end type
+
+ type, extends(a), public :: b
+ end type
+end
+
+program main
+ use my_module
+ implicit none
+ type(b) :: b_instance
+ class(a), allocatable :: a_array(:)
+ class(b), allocatable :: b_array(:)
+
+ a_array = [b_instance]
+ b_array = [b_instance]
+ a_array = [a_array] ! { dg-error "is of the ABSTRACT type" }
+ a_array = [a_array(1)] ! { dg-error "is of the ABSTRACT type" }
+ a_array = [a_array, b_instance] ! { dg-error "is of the ABSTRACT type" }
+ a_array = [b_instance, a_array] ! { dg-error "is of the ABSTRACT type" }
+ b_array = [b_array, a_array]! { dg-error "is of the ABSTRACT type" }
+end program
--
2.35.3
Re: [PATCH] Fortran: reject array constructor value of abstract type [PR114308]
Pushed after an OK by Steve in the PR as r15-2902-g9988d7e004796ab531df7bcda45788a7aa9276d7 Am 13.08.24 um 19:25 schrieb Harald Anlauf: Dear all, the attached patch checks whether the declared type of an array constructor value is abstract, which is forbidden by the standard. Steve found the relevant constraint in F2023, but it exists already in F2018. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Cheers, Harald
[PATCH] Fortran: fix minor frontend GMP leaks
Dear all,
while running f951 under valgrind on testcase gfortran.dg/sizeof_6.f90
I found two minor memleaks with GMP variables that were not cleared.
Regtested on x86_64-pc-linux-gnu.
I intend to commit to mainline soon unless there are comments.
(And no, this does not address the recent intermittent runtime failures
reported in pr116261).
Thanks,
Harald
From 0cef868a87050c9854ac17c5a604c1aa72ea1862 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 13 Aug 2024 21:17:45 +0200
Subject: [PATCH] Fortran: fix minor frontend GMP leaks
gcc/fortran/ChangeLog:
* simplify.cc (gfc_simplify_sizeof): Clear used gmp variable.
* target-memory.cc (gfc_target_expr_size): Likewise.
---
gcc/fortran/simplify.cc | 10 +++---
gcc/fortran/target-memory.cc | 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 8ddd491de11..953d59efd70 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -7778,9 +7778,13 @@ gfc_simplify_sizeof (gfc_expr *x)
|| x->ts.u.cl->length->expr_type != EXPR_CONSTANT))
return NULL;
- if (x->rank && x->expr_type != EXPR_ARRAY
- && !gfc_array_size (x, &array_size))
-return NULL;
+ if (x->rank && x->expr_type != EXPR_ARRAY)
+{
+ if (!gfc_array_size (x, &array_size))
+ return NULL;
+
+ mpz_clear (array_size);
+}
result = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind,
&x->where);
diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
index a02db7a06e4..0a289f32d37 100644
--- a/gcc/fortran/target-memory.cc
+++ b/gcc/fortran/target-memory.cc
@@ -158,6 +158,8 @@ gfc_target_expr_size (gfc_expr *e, size_t *size)
asz = mpz_get_ui (tmp);
else
return false;
+
+ mpz_clear (tmp);
}
else
asz = 1;
--
2.35.3
Re: [PATCH] Fortran: fix minor frontend GMP leaks
Hi Harald, I had a hard time to figure why this is correct, when gfc_array_size() returned false, but now I get it. Ok to commit. - Andre On Tue, 13 Aug 2024 21:25:31 +0200 Harald Anlauf wrote: > Dear all, > > while running f951 under valgrind on testcase gfortran.dg/sizeof_6.f90 > I found two minor memleaks with GMP variables that were not cleared. > > Regtested on x86_64-pc-linux-gnu. > > I intend to commit to mainline soon unless there are comments. > > (And no, this does not address the recent intermittent runtime failures > reported in pr116261). > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de
