José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi José, hi all, especially since my patch which moved the descriptor conversion from libgfortran to gfortran is in, I wonder whether there are still patches to be applied and useful testcases; I assume there are more issues in Bugzilla, especially as I filled myself some (often related to polymorphism or assumed rank). While I (and also Sandra) try to resolve some bugs and look at testcases: it would be helpful if others – in particular José – could check whether: (a) PRs can be now closed, (b) testcases exist which still should be added, (c) patches exist which still are applicable (even if they need to be revised). (Partial/full list below.) I hope that we can really cleanup this backlog – and possibly fix also some of the remaining bugs before GCC 12 is released! And kudos to José for the bug reports, testcases and patches – and sorry for slow reviews. I hope we resolve the pending issues and be quicker in future. Tobias PS: Old and probably current but incomplete pending patch list: On 21.06.21 17:21, José Rui Faustino de Sousa wrote: On 21/06/21 12:37, Tobias Burnus wrote: Thus: Do you have a list of patches pending review? https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html I am not 100% sure this is all of them but it should be most. - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi Tobias, My disappearance is partly responsible for the backlog. I told José that I would start working on it some months since but just have not had the time. I can do some of the reviews but still do not have much time to spare. Perhaps you could divide them up between us. Andrew Benson has been working on some standards issues associated with a patch of mine that sorts out finalization for intrinsic assignment - PR64290. The main issue was that of finalization of finalizable types/classes that themselves have finalizable array components. I believe that the patch has it right, following a comparison between the (differing!) behaviour of other brands. We have also found a case where gfortran, with the patch applied, that still does not finalize when it should. I will work up a fix for this and will coordinate with Andrew to produce testcases as necessary, well before 15th November. Best regards Paul On Fri, 22 Oct 2021 at 08:42, Tobias Burnus wrote: > Hi José, hi all, > > especially since my patch which moved the descriptor conversion from > libgfortran to gfortran is in, I wonder whether there are still patches > to be applied and useful testcases; I assume there are more issues in > Bugzilla, especially as I filled myself some (often related to > polymorphism or assumed rank). While I (and also Sandra) try to resolve > some bugs and look at testcases: > > it would be helpful if others – in particular José – could check > whether: (a) PRs can be now closed, (b) testcases exist which still > should be added, (c) patches exist which still are applicable (even if > they need to be revised). (Partial/full list below.) > > I hope that we can really cleanup this backlog – and possibly fix also > some of the remaining bugs before GCC 12 is released! > > And kudos to José for the bug reports, testcases and patches – and sorry > for slow reviews. I hope we resolve the pending issues and be quicker in > future. > > Tobias > > PS: Old and probably current but incomplete pending patch list: > > On 21.06.21 17:21, José Rui Faustino de Sousa wrote: > > On 21/06/21 12:37, Tobias Burnus wrote: > >> Thus: Do you have a list of patches pending review? > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html > > > > I am not 100% sure this is all of them but it should be most. > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi José, hi Fortraners,
triage of all listed patches:
On 21.06.21 17:21, José Rui Faustino de Sousa wrote:
https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
PR100040 - Wrong code with intent out assumed-rank allocatable
PR100029 - ICE on subroutine call with allocatable polymorphic
→ Both: Still occurs, ICE in gfc_deallocate_scalar_with_status
TODO: Review patch.
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
PR100097 - Unlimited polymorphic pointers and allocatables have incorrect rank
PR100098 - Polymorphic pointers and allocatables have incorrect rank
→ Both: PASS
TODO: Check whether it makes sense to apply the testcase
TODO: Close PRs
→ See also patch below (2021-June/056169.html)
https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html
PR96870 - Class name on error message
→ Fixed with sufficient test coverage; thus, I closed the PR.
Nothing to be done.
https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html
PR96724 - Bogus warnings with the repeat intrinsic and the flag
-Wconversion-extra| repeat ('x', NCOPIES=i08) ! i08 is 20_1 shows: Warning:
Conversion
from INTEGER(1) to INTEGER(8) at (1) [-Wconversion-extra] TODO: Review
patch. |
https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
Bug 93308 - bind(c) subroutine changes lower bound of array argument in caller
Bug 93963 - Select rank mishandling allocatable and pointer arguments with
bind(c)
Bug 94327 - Bind(c) argument attributes are incorrectly set
Bug 94331 - Bind(C) corrupts array descriptors
Bug 97046 - Bad interaction between lbound/ubound, allocatable arrays and
bind(C) subroutine with dimension(..) parameter
→ All already closed as FIXED
TODO: Nothing, unless we want to pick one of the testcases.
https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html
PR94104 - Request for diagnostic improvement
10 | print *, sumf(a)
|1
Error: Actual argument for ‘a’ must be a pointer at (1)
NOTE: as the dummy is intent(in), since F2008 alternatively a TARGET attr would
be also okay.
TODO: Review patch - in principle, I am fine with the but I am not sure the
'valid target' in the error message is clear enough. Might require some message
tweaking
for clarity.
https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html
Gerald's PR100948 - [12 Regression] ICE in gfc_conv_expr_val, at
fortran/trans-expr.c:9069
Still has an ICE.
TODO: Review patch.
https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html
Bug 100906 - Bind(c): failure handling character with len/=1
→ Testcase now passes.
Bug 100907 - Bind(c): failure handling wide character
→ I think now okay – but the testcase assumes elem_len/sizeof(char) == #chars
but for the C descriptor, elem_len / sizeof(char-type) = #chars
Thus, sz is not 1 or 7 bytes but 4 or 28 bytes (or 1/7 characters)
Bug 100911 - Bind(c): failure handling C_PTR
→ Closed as FIXED.
Bug 100914 - Bind(c): errors handling complex
→ Closed as FIXED
Bug 100915 - Bind(c): failure handling C_FUNPTR
→ Closed as FIXED
Bug 100916 - Bind(c): CFI_type_other unimplemented
→ Bogus testcase (for 't(ype)' argument) otherwise it expects
CFI_type_other instead of CFI_type_struct (TODO: Is that sensible?)
TODO: Check whether a testcase is needed
TODO: Close the three still open PRs
https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html
Bug 101047 - Pointer explicit initialization fails
Bug 101048 - Class pointer explicit initialization refuses valid
..., pointer, save :: ptr => tgt
fails to associate ptr with tgt
(wrong-code + rejects valid)
TODO: Review patch.
https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html
PR92621 - Problems with memory handling with allocatable intent(out) arrays
with bind(c)
I think mostly fixed by my big bind(C) patch, but there still one ICE
with '-fcheck=all -fsanitize=undefined'
TODO: Fix that bug (unlikely to be fixed by José's patch)
TODO: Check whether testcase should be added
and then close the PR
https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html
PR100245 - ICE on automatic reallocation.
Still ICEs
TODO: Review patch.
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
PR100136 - ICE, regression, using flag -fcheck=pointer
First testcase has an ICE with -fcheck=pointer
Second testcase has always an ICE + possibly missing func.
TODO: Review patch – and probably: follow-up patch for remaining issue
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
PR100132 - Optimization breaks pointer association.
'fn spec' is wrong :-(
TODO: Review patch!
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
PR100103 - Automatic reallocation fails inside select rank
Still segfaults at runtime for 'that = a' where the RHS is a parameter
and the LHS an allocatable assumed-rank array (inside select rank).
TODO: Review patch
https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html
PR100097 - Unlimited polymorphic pointers a
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
Hi all, On 22.10.21 15:05, Hafiz Abid Qadeer wrote: This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not yet support the allocator-modifier as specified in OpenMP 5.1. The allocate clause is already supported in C/C++. I think the following shouldn't block the acceptance of the patch, but I think we eventually need to handle the following as well: type t integer, allocatable :: xx(:) end type type(t) :: tt class(t), allocatable :: cc allocate(t :: cc) tt%xx = [1,2,3,4,5,6] cc%xx = [1,2,3,4,5,6] ! ... !$omp task firstprivate(tt, cc) allocate(h) ... In my spec reading, both tt/cc itself and tt%ii and cc%ii should use the specified allocator. And unless I missed something (I only glanced at the patch so far), it is not handled. But for derived types (except for recursive allocatables, valid since 5.1), I think it can be handled in gfc_omp_clause_copy_ctor / gfc_omp_clause_dtor, but I have not checked whether those support it properly. For CLASS + recursive allocatables, it requires some more changes (which might be provided by my derived-type deep copy patch, of which only 1/3 has been written). Tobias PS: Just a side note, OpenMP has the following for Fortran: "If any operation of the base language causes a reallocation of a variable that is allocated with a memory allocator then that memory allocator will be used to deallocate the current memory and to allocate the new memory. For allocated allocatable components of such variables, the allocator that will be used for the deallocation and allocation is unspecified." - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [PATCH][WIP] Add install-dvi Makefile targets
On 10/18/2021 7:30 PM, Eric Gallager wrote: On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager wrote: On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager wrote: Currently the build machinery handles install-pdf and install-html targets, but no install-dvi target. This patch is a step towards fixing that. Note that I have only tested with --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will probably also have to be added for the languages I skipped. Also, please note that this patch applies on top of: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html ChangeLog: 2016-10-06 Eric Gallager * Makefile.def: Handle install-dvi target. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. gcc/ChangeLog: 2016-10-06 Eric Gallager * Makefile.in: Handle dvidir and install-dvi target. * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi target hooks. * configure.ac: Handle install-dvi target. * configure: Regenerate. libiberty/ChangeLog: 2016-10-06 Eric Gallager * Makefile.in: Handle dvidir and install-dvi target. * functions.texi: Regenerate. Ping. The prerequisite patch that I linked to previously has gone in now. I'm not sure if this specific patch still applies, though. Also note that I've opened a bug to track this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 Hi, I have updated this patch and tested it with more languages now; I can now confirm that it works with ada, d, and fortran now. The only languages that remain untested now are go (since I'm building on darwin and go doesn't build on darwin anyways, as per bug 46986) and jit (which I ran into a bug about that I brought up on IRC, and will probably need to file on bugzilla). OK to install? Yea, I think this is OK. We might need to adjust go/jit and perhaps other toplevel modules, but if those do show up as problems I think we can fault in those fixes. jeff
[Fortran, committed] Add testcase for PR 94289
I've committed this slightly cleaned-up version of the testcase
originally submitted with the now-fixed issue PR 94289.
-Sandra
commit c31d2d14f798dc7ca9cc078200d37113749ec3bd
Author: Sandra Loosemore
Date: Fri Oct 22 11:08:19 2021 -0700
Add testcase for PR fortran/94289
2021-10-22 José Rui Faustino de Sousa
Sandra Loosemore
gcc/testsuite/
PR fortran/94289
* gfortran.dg/PR94289.f90: New.
diff --git a/gcc/testsuite/gfortran.dg/PR94289.f90 b/gcc/testsuite/gfortran.dg/PR94289.f90
new file mode 100644
index 000..4f17d97
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR94289.f90
@@ -0,0 +1,168 @@
+! { dg-do run }
+!
+! Testcase for PR 94289
+!
+! - if the dummy argument is a pointer/allocatable, it has the same
+! bounds as the dummy argument
+! - if is is nonallocatable nonpointer, the lower bounds are [1, 1, 1].
+
+module bounds_m
+
+ implicit none
+
+ private
+ public :: &
+lb, ub
+
+ public :: &
+bnds_p, &
+bnds_a, &
+bnds_e
+
+ integer, parameter :: lb1 = 3
+ integer, parameter :: lb2 = 5
+ integer, parameter :: lb3 = 9
+ integer, parameter :: ub1 = 4
+ integer, parameter :: ub2 = 50
+ integer, parameter :: ub3 = 11
+ integer, parameter :: ex1 = ub1 - lb1 + 1
+ integer, parameter :: ex2 = ub2 - lb2 + 1
+ integer, parameter :: ex3 = ub3 - lb3 + 1
+
+ integer, parameter :: lf(*) = [1,1,1]
+ integer, parameter :: lb(*) = [lb1,lb2,lb3]
+ integer, parameter :: ub(*) = [ub1,ub2,ub3]
+ integer, parameter :: ex(*) = [ex1,ex2,ex3]
+
+contains
+
+ subroutine bounds(a, lb, ub)
+integer, pointer, intent(in) :: a(..)
+integer, intent(in) :: lb(3)
+integer, intent(in) :: ub(3)
+
+integer :: ex(3)
+
+ex = max(ub-lb+1, 0)
+if(any(lbound(a)/=lb)) stop 101
+if(any(ubound(a)/=ub)) stop 102
+if(any( shape(a)/=ex)) stop 103
+return
+ end subroutine bounds
+
+ subroutine bnds_p(this)
+integer, pointer, intent(in) :: this(..)
+
+if(any(lbound(this)/=lb)) stop 1
+if(any(ubound(this)/=ub)) stop 2
+if(any( shape(this)/=ex)) stop 3
+call bounds(this, lb, ub)
+return
+ end subroutine bnds_p
+
+ subroutine bnds_a(this)
+integer, allocatable, target, intent(in) :: this(..)
+
+if(any(lbound(this)/=lb)) stop 4
+if(any(ubound(this)/=ub)) stop 5
+if(any( shape(this)/=ex)) stop 6
+call bounds(this, lb, ub)
+return
+ end subroutine bnds_a
+
+ subroutine bnds_e(this)
+integer, target, intent(in) :: this(..)
+
+if(any(lbound(this)/=lf)) stop 7
+if(any(ubound(this)/=ex)) stop 8
+if(any( shape(this)/=ex)) stop 9
+call bounds(this, lf, ex)
+return
+ end subroutine bnds_e
+
+end module bounds_m
+
+program bounds_p
+
+ use, intrinsic :: iso_c_binding, only: c_int
+
+ use bounds_m
+
+ implicit none
+
+ integer, parameter :: fpn = 1
+ integer, parameter :: fan = 2
+ integer, parameter :: fon = 3
+
+ integer :: i
+
+ do i = fpn, fon
+call test_p(i)
+ end do
+ do i = fpn, fon
+call test_a(i)
+ end do
+ do i = fpn, fon
+call test_e(i)
+ end do
+ stop
+
+contains
+
+ subroutine test_p(t)
+integer, intent(in) :: t
+
+integer, pointer :: a(:,:,:)
+
+allocate(a(lb(1):ub(1),lb(2):ub(2),lb(3):ub(3)))
+select case(t)
+case(fpn)
+ call bnds_p(a)
+case(fan)
+case(fon)
+ call bnds_e(a)
+case default
+ stop
+end select
+deallocate(a)
+return
+ end subroutine test_p
+
+ subroutine test_a(t)
+integer, intent(in) :: t
+
+integer, allocatable, target :: a(:,:,:)
+
+allocate(a(lb(1):ub(1),lb(2):ub(2),lb(3):ub(3)))
+select case(t)
+case(fpn)
+ call bnds_p(a)
+case(fan)
+ call bnds_a(a)
+case(fon)
+ call bnds_e(a)
+case default
+ stop
+end select
+deallocate(a)
+return
+ end subroutine test_a
+
+ subroutine test_e(t)
+integer, intent(in) :: t
+
+integer, target :: a(lb(1):ub(1),lb(2):ub(2),lb(3):ub(3))
+
+select case(t)
+case(fpn)
+ call bnds_p(a)
+case(fan)
+case(fon)
+ call bnds_e(a)
+case default
+ stop
+end select
+return
+ end subroutine test_e
+
+end program bounds_p
PDT type parameters are not restricted to default integer
Here's an obvious quick fix. Please apply.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 6043e100fbb..e889bb44142 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5619,14 +5619,6 @@ match_attr_spec (void)
m = MATCH_ERROR;
goto cleanup;
}
- if (current_ts.kind != gfc_default_integer_kind)
- {
- gfc_error ("Component with LEN attribute at %C must be "
-"default integer kind (%d)",
- gfc_default_integer_kind);
- m = MATCH_ERROR;
- goto cleanup;
- }
}
else
{
--
Steve
[PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
Dear Fortranners,
the recently introduced shape validation for array components
in DT constructors did not properly deal with invalid code
created by ingenious testers.
Obvious solution: replace the gcc_assert by a suitable error message.
Regarding the error message: before the shape validation, gfortran
would emit the same error message twice referring to the same line,
namely the bad declaration of the component. With the attached patch
we get one error message for the bad declaration of the component,
and one for the structure constructor referring to that DT component.
One could easily change that and make the second message refer to the
same as the declaration, giving two errors for the same line.
Comments / opinions?
Regtested on x86_64-pc-linux-gnu. OK?
Thanks,
Harald
Fortran: error recovery on initializing invalid derived type array component
gcc/fortran/ChangeLog:
PR fortran/102816
* resolve.c (resolve_structure_cons): Reject invalid array spec of
a DT component referred in a structure constructor.
gcc/testsuite/ChangeLog:
PR fortran/102816
* gfortran.dg/pr102816.f90: New test.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 5ccd9072c24..dc4ca5ef818 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1463,8 +1463,15 @@ resolve_structure_cons (gfc_expr *expr, int init)
mpz_init (len);
for (int n = 0; n < rank; n++)
{
- gcc_assert (comp->as->upper[n]->expr_type == EXPR_CONSTANT
- && comp->as->lower[n]->expr_type == EXPR_CONSTANT);
+ if (comp->as->upper[n]->expr_type != EXPR_CONSTANT
+ || comp->as->lower[n]->expr_type != EXPR_CONSTANT)
+ {
+ gfc_error ("Bad array spec of component %qs referred in "
+ "structure constructor at %L",
+ comp->name, &cons->expr->where);
+ t = false;
+ break;
+ };
mpz_set_ui (len, 1);
mpz_add (len, len, comp->as->upper[n]->value.integer);
mpz_sub (len, len, comp->as->lower[n]->value.integer);
diff --git a/gcc/testsuite/gfortran.dg/pr102816.f90 b/gcc/testsuite/gfortran.dg/pr102816.f90
new file mode 100644
index 000..46831743b2b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102816.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/102816
+
+program p
+ type t
+ integer :: a([2]) ! { dg-error "must be scalar" }
+ end type
+ type(t) :: x = t([3, 4]) ! { dg-error "Bad array spec of component" }
+end
gfortran.dg/c-interop/cf-descriptor-5.f90 fails on freebsd
gfortran.dg/c-interop/cf-descriptor-5.f90 is associated with 5 FAILS on x86_64-*-freebsd. Please fix. -- Steve
libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD
libgomp.fortran/async_io_[1,2,3,4,8,9].f90 account for a number of FAILS on x86_64-*-freebsd. Please fix. -- Steve
Re: PDT type parameters are not restricted to default integer
Hi Steve,
Am 22.10.21 um 21:35 schrieb Steve Kargl via Fortran:
Here's an obvious quick fix. Please apply.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 6043e100fbb..e889bb44142 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5619,14 +5619,6 @@ match_attr_spec (void)
m = MATCH_ERROR;
goto cleanup;
}
- if (current_ts.kind != gfc_default_integer_kind)
- {
- gfc_error ("Component with LEN attribute at %C must be "
-"default integer kind (%d)",
- gfc_default_integer_kind);
- m = MATCH_ERROR;
- goto cleanup;
- }
}
else
{
I think you are right. We should always have allowed any integer kind.
However, have you checked whether this change introduces regressions?
If you don't, somebody else will. Please open a PR, then.
Harald
Re: PDT type parameters are not restricted to default integer
On Fri, Oct 22, 2021 at 10:16:05PM +0200, Harald Anlauf wrote:
> Hi Steve,
>
> Am 22.10.21 um 21:35 schrieb Steve Kargl via Fortran:
> > Here's an obvious quick fix. Please apply.
> >
> >
> > diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> > index 6043e100fbb..e889bb44142 100644
> > --- a/gcc/fortran/decl.c
> > +++ b/gcc/fortran/decl.c
> > @@ -5619,14 +5619,6 @@ match_attr_spec (void)
> > m = MATCH_ERROR;
> > goto cleanup;
> > }
> > - if (current_ts.kind != gfc_default_integer_kind)
> > - {
> > - gfc_error ("Component with LEN attribute at %C must be "
> > -"default integer kind (%d)",
> > - gfc_default_integer_kind);
> > - m = MATCH_ERROR;
> > - goto cleanup;
> > - }
> > }
> > else
> > {
>
> I think you are right. We should always have allowed any integer kind.
>
> However, have you checked whether this change introduces regressions?
> If you don't, somebody else will. Please open a PR, then.
>
It seems that pdt_4.f03 will fail with the above patch because
it explicitly tests for this error message. That's the only
failure in the testsuite. For the record, F2003, page 48,
R435 type-param-def-stmt is INTEGER [ kind-selector ] , ...
Each type parameter is itself of type integer. If its kind selector
is omitted, the kind type parameter is default integer.
Now that I think about and look, there is a nearby similar gcc_error()
for KIND. This should be removed too.
--
Steve
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi Tobias, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html PR100103 - Automatic reallocation fails inside select rank Still segfaults at runtime for 'that = a' where the RHS is a parameter and the LHS an allocatable assumed-rank array (inside select rank). TODO: Review patch this one LGTM. Thanks for the patch! Harald
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html PR100136 - ICE, regression, using flag -fcheck=pointer First testcase has an ICE with -fcheck=pointer Second testcase has always an ICE + possibly missing func. TODO: Review patch – and probably: follow-up patch for remaining issue I think this LGTM. Thanks for the patch! Harald
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html PR100245 - ICE on automatic reallocation. Still ICEs TODO: Review patch. this one works and LGTM. Thanks for the patch! Harald
[committed] Fortran: Avoid running into assert with -fcheck= + UBSAN [PR92621]
The testcase of the PR or as attached gave an ICE, but only when
compiled with -fcheck=all -fsanitize=undefined. Solution: Strip
the nop to avoid the assert failure.
Committed as r12-4632-g24e99e6ec1cc57f3660c00ff677c7feb16aa94d2
Tobias
* * *
PS: Similar issues when using additional flags:
ICE also with -fcheck=all -fsanitize=undefined:
https://gcc.gnu.org/PR102901 ICE (segfault) when compiling pdt_13.f03 with
-fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps
https://gcc.gnu.org/PR102900 ICE via gfc_class_data_get with
alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
+ runtime same flags but running the code:
https://gcc.gnu.org/PR102903 New: Invalid gfortran.dg testcases or wrong-code
with -fcheck=all -fsanitize=undefined
Here, false positives might/do surely exist as do testcase bugs. (And the list
is incomplete.)
+ -flto fail (not really fitting into this series):
https://gcc.gnu.org/PR102885 - [12 Regression] ICE when compiling
gfortran.dg/bind_c_char_10.f90 with -flto since r12-4467-g64f9623765da3306
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 24e99e6ec1cc57f3660c00ff677c7feb16aa94d2
Author: Tobias Burnus
Date: Fri Oct 22 23:23:06 2021 +0200
Fortran: Avoid running into assert with -fcheck= + UBSAN
PR fortran/92621
gcc/fortran/
* trans-expr.c (gfc_trans_assignment_1): Add STRIP_NOPS.
gcc/testsuite/
* gfortran.dg/bind-c-intent-out-2.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 29697e69e75..2d7f9e0fb91 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -11727,6 +11727,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
tmp = INDIRECT_REF_P (lse.expr)
? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+ STRIP_NOPS (tmp);
/* We should only get array references here. */
gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
diff --git a/gcc/testsuite/gfortran.dg/bind-c-intent-out-2.f90 b/gcc/testsuite/gfortran.dg/bind-c-intent-out-2.f90
new file mode 100644
index 000..fe8f6060f1f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bind-c-intent-out-2.f90
@@ -0,0 +1,39 @@
+! { dg-do run }
+! { dg-additional-options "-fsanitize=undefined -fcheck=all" }
+
+! PR fortran/92621
+
+subroutine hello(val) bind(c)
+ use, intrinsic :: iso_c_binding, only: c_int
+
+ implicit none
+
+ integer(kind=c_int), allocatable, intent(out) :: val(:)
+
+ allocate(val(1))
+ val = 2
+ return
+end subroutine hello
+
+program alloc_p
+
+ use, intrinsic :: iso_c_binding, only: c_int
+
+ implicit none
+
+ interface
+subroutine hello(val) bind(c)
+ import :: c_int
+ implicit none
+ integer(kind=c_int), allocatable, intent(out) :: val(:)
+end subroutine hello
+ end interface
+
+ integer(kind=c_int), allocatable :: a(:)
+
+ allocate(a(1))
+ a = 1
+ call hello(a)
+ stop
+
+end program alloc_p
[committed]
Committed as r12-4633-g030875c197e339542ddfcbad90cfc01263151bec
To reduce the XFAIL clutter in the *.sum files, this patch removes some
pointless XFAIL in favour of pruning the output which should be ignored
and using explicit checks for the currently output warnings/errors.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 030875c197e339542ddfcbad90cfc01263151bec
Author: Tobias Burnus
Date: Sat Oct 23 00:04:43 2021 +0200
Fortran: Change XFAIL to PASS
Replace dg-excess-errors by dg-error/warning and dg-prune-output for
more fine-grained output handling and to avoid XPASS.
gcc/testsuite/ChangeLog:
* gfortran.dg/associate_3.f03: Replace dg-excess-errors by
other dg-* to change XFAIL to PASS.
* gfortran.dg/binding_label_tests_4.f03: Likewise.
* gfortran.dg/block_4.f08: Likewise.
* gfortran.dg/charlen_04.f90: Likewise.
* gfortran.dg/charlen_05.f90: Likewise.
* gfortran.dg/charlen_06.f90: Likewise.
* gfortran.dg/charlen_13.f90: Likewise.
* gfortran.dg/coarray_9.f90: Likewise.
* gfortran.dg/coarray_collectives_3.f90: Likewise.
* gfortran.dg/data_invalid.f90: Likewise.
* gfortran.dg/do_4.f: Likewise.
* gfortran.dg/dollar_sym_1.f90: Likewise.
* gfortran.dg/dollar_sym_3.f: Likewise.
* gfortran.dg/fmt_tab_1.f90: Likewise.
* gfortran.dg/fmt_tab_2.f90: Likewise.
* gfortran.dg/forall_16.f90: Likewise.
* gfortran.dg/g77/970125-0.f: Likewise.
* gfortran.dg/gomp/unexpected-end.f90: Likewise.
* gfortran.dg/interface_operator_1.f90: Likewise.
* gfortran.dg/interface_operator_2.f90: Likewise.
* gfortran.dg/line_length_4.f90: Likewise.
* gfortran.dg/line_length_5.f90: Likewise.
* gfortran.dg/line_length_6.f90: Likewise.
* gfortran.dg/line_length_8.f90: Likewise.
* gfortran.dg/line_length_9.f90: Likewise.
* gfortran.dg/pr65045.f90: Likewise.
* gfortran.dg/pr69497.f90: Likewise.
* gfortran.dg/submodule_21.f08: Likewise.
* gfortran.dg/tab_continuation.f: Likewise.
* gfortran.dg/typebound_proc_2.f90: Likewise.
* gfortran.dg/warnings_are_errors_1.f90: Likewise.
diff --git a/gcc/testsuite/gfortran.dg/associate_3.f03 b/gcc/testsuite/gfortran.dg/associate_3.f03
index da7bec951d1..dfd5a99500e 100644
--- a/gcc/testsuite/gfortran.dg/associate_3.f03
+++ b/gcc/testsuite/gfortran.dg/associate_3.f03
@@ -34,4 +34,4 @@ PROGRAM main
INTEGER :: b ! { dg-error "Unexpected data declaration statement" }
END ASSOCIATE
END PROGRAM main ! { dg-error "Expecting END ASSOCIATE" }
-! { dg-excess-errors "Unexpected end of file" }
+! { dg-error "Unexpected end of file" "" { target "*-*-*" } 0 }
diff --git a/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03 b/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03
index f8c0f046063..af9a588cfec 100644
--- a/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03
+++ b/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03
@@ -20,4 +20,4 @@ module C
use A
use B ! { dg-error "Cannot open module file" }
end module C
-! { dg-excess-errors "compilation terminated" }
+! { dg-prune-output "compilation terminated" }
diff --git a/gcc/testsuite/gfortran.dg/block_4.f08 b/gcc/testsuite/gfortran.dg/block_4.f08
index 4c63194c85d..3ff52b0a098 100644
--- a/gcc/testsuite/gfortran.dg/block_4.f08
+++ b/gcc/testsuite/gfortran.dg/block_4.f08
@@ -15,4 +15,4 @@ PROGRAM main
myname2: BLOCK
END BLOCK ! { dg-error "Expected block name of 'myname2'" }
END PROGRAM main ! { dg-error "Expecting END BLOCK" }
-! { dg-excess-errors "Unexpected end of file" }
+! { dg-error "Unexpected end of file" "" { target "*-*-*" } 0 }
diff --git a/gcc/testsuite/gfortran.dg/charlen_04.f90 b/gcc/testsuite/gfortran.dg/charlen_04.f90
index f93465f2ae6..97aa0ec583c 100644
--- a/gcc/testsuite/gfortran.dg/charlen_04.f90
+++ b/gcc/testsuite/gfortran.dg/charlen_04.f90
@@ -3,6 +3,5 @@
program p
type t
character(*), allocatable :: x(*) ! { dg-error "must have a deferred shape" }
- end type
+ end type ! { dg-error "needs to be a constant specification" "" { target "*-*-*" } .-1 }
end
-! { dg-excess-errors "needs to be a constant specification" }
diff --git a/gcc/testsuite/gfortran.dg/charlen_05.f90 b/gcc/testsuite/gfortran.dg/charlen_05.f90
index 0eb0015bf38..e58f9263330 100644
--- a/gcc/testsuite/gfortran.dg/charlen_05.f90
+++ b/gcc/testsuite/gfortran.dg/charlen_05.f90
@@ -3,6 +3,5 @@
program p
type t
character(*) :: x y ! { dg-error "error in data declar
Re: [PATCH][WIP] Add install-dvi Makefile targets
On Fri, Oct 22, 2021 at 8:23 AM Jeff Law wrote: > > > > On 10/18/2021 7:30 PM, Eric Gallager wrote: > > On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager wrote: > >> On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager wrote: > >>> Currently the build machinery handles install-pdf and install-html > >>> targets, but no install-dvi target. This patch is a step towards > >>> fixing that. Note that I have only tested with > >>> --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will > >>> probably also have to be added for the languages I skipped. > >>> Also, please note that this patch applies on top of: > >>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html > >>> > >>> ChangeLog: > >>> > >>> 2016-10-06 Eric Gallager > >>> > >>> * Makefile.def: Handle install-dvi target. > >>> * Makefile.tpl: Likewise. > >>> * Makefile.in: Regenerate. > >>> > >>> gcc/ChangeLog: > >>> > >>> 2016-10-06 Eric Gallager > >>> > >>> * Makefile.in: Handle dvidir and install-dvi target. > >>> * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi > >>> target hooks. > >>> * configure.ac: Handle install-dvi target. > >>> * configure: Regenerate. > >>> > >>> libiberty/ChangeLog: > >>> > >>> 2016-10-06 Eric Gallager > >>> > >>> * Makefile.in: Handle dvidir and install-dvi target. > >>> * functions.texi: Regenerate. > >> Ping. The prerequisite patch that I linked to previously has gone in now. > >> I'm not sure if this specific patch still applies, though. > >> Also note that I've opened a bug to track this issue: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 > > Hi, I have updated this patch and tested it with more languages now; I > > can now confirm that it works with ada, d, and fortran now. The only > > languages that remain untested now are go (since I'm building on > > darwin and go doesn't build on darwin anyways, as per bug 46986) and > > jit (which I ran into a bug about that I brought up on IRC, and will > > probably need to file on bugzilla). OK to install? > Yea, I think this is OK. We might need to adjust go/jit and perhaps > other toplevel modules, but if those do show up as problems I think we > can fault in those fixes. > > jeff OK thanks, installed as r12-4636: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c3e80a16af287e804b87b8015307085399755cd4
[Fortran, committed] Add testcase for PR95196
I've committed another testcase from a bugzilla issue that now appears
to be fixed.
-Sandra
commit 9a0e34eb45e36d4f90cedb61191fd31da0bab256
Author: Sandra Loosemore
Date: Fri Oct 22 17:22:00 2021 -0700
Add testcase for PR fortran/95196
2021-10-22 José Rui Faustino de Sousa
Sandra Loosemore
gcc/testsuite/
PR fortran/95196
* gfortran.dg/PR95196.f90: New.
diff --git a/gcc/testsuite/gfortran.dg/PR95196.f90 b/gcc/testsuite/gfortran.dg/PR95196.f90
new file mode 100644
index 000..14333e4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR95196.f90
@@ -0,0 +1,83 @@
+! { dg-do run }
+
+program rnk_p
+
+ implicit none
+
+ integer, parameter :: n = 10
+ integer, parameter :: m = 5
+ integer, parameter :: s = 4
+ integer, parameter :: l = 4
+ integer, parameter :: u = s+l-1
+
+ integer :: a(n)
+ integer :: b(n,n)
+ integer :: c(n,n,n)
+ integer :: r(s*s*s)
+ integer :: i
+
+ a = reshape([(i, i=1,n)], [n])
+ b = reshape([(i, i=1,n*n)], [n,n])
+ c = reshape([(i, i=1,n*n*n)], [n,n,n])
+ r(1:s) = a(l:u)
+ call rnk_s(a(l:u), r(1:s))
+ r(1:s*s) = reshape(b(l:u,l:u), [s*s])
+ call rnk_s(b(l:u,l:u), r(1:s*s))
+ r = reshape(c(l:u,l:u,l:u), [s*s*s])
+ call rnk_s(c(l:u,l:7,l:u), r)
+ stop
+
+contains
+
+ subroutine rnk_s(a, b)
+integer, intent(in) :: a(..)
+integer, intent(in) :: b(:)
+
+!integer :: l(rank(a)), u(rank(a)) does not work due to Bug 94048
+integer, allocatable :: lb(:), ub(:)
+integer :: i, j, k, l
+
+lb = lbound(a)
+ub = ubound(a)
+select rank(a)
+rank(1)
+ if(any(lb/=lbound(a))) stop 11
+ if(any(ub/=ubound(a))) stop 12
+ if(size(a)/=size(b)) stop 13
+ do i = 1, size(a)
+if(a(i)/=b(i)) stop 14
+ end do
+rank(2)
+ if(any(lb/=lbound(a))) stop 21
+ if(any(ub/=ubound(a))) stop 22
+ if(size(a)/=size(b)) stop 23
+ k = 0
+ do j = 1, size(a, dim=2)
+do i = 1, size(a, dim=1)
+ k = k + 1
+ if(a(i,j)/=b(k)) stop 24
+end do
+ end do
+rank(3)
+ if(any(lb/=lbound(a))) stop 31
+ if(any(ub/=ubound(a))) stop 32
+ if(size(a)/=size(b)) stop 33
+ l = 0
+ do k = 1, size(a, dim=3)
+do j = 1, size(a, dim=2)
+ do i = 1, size(a, dim=1)
+l = l + 1
+! print *, a(i,j,k), b(l)
+if(a(i,j,k)/=b(l)) stop 34
+ end do
+end do
+ end do
+rank default
+ stop 171
+end select
+deallocate(lb, ub)
+return
+ end subroutine rnk_s
+
+end program rnk_p
+
Replacing keyword in RISC-V Fortran
Hello All, I am working on a custom float in RISC-V 32, one can replace keyword "float" with custom keyword like "fp_custom" at line # 482 riscv-gcc/gcc/c-family/c-common.c. But in the case of Fortran, can you please tell which files to modify to replace the "float" keyword? And also, in case of c/c++ one can do custom encoding and decoding of custom floats in gcc/real.c how about in fortran for custom real data type, which file(s) one has to modify? Many Thanks, -Amit
