: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Using gfortran 11.2.0 installed by Homebrew on macOS 12.0.1 to compile the code
below and link against
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
In TS 18508, the second summy argument to co_reduce had the keyword name
"operator." In the Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897
--- Comment #8 from Damian Rouson ---
Thanks, Paul and Tobias!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897
--- Comment #3 from Damian Rouson ---
Thanks for the quick fix, Paul! Any chance of this being back-ported to the
10 branch?
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The behavior demonstrated below also occurs if the procedure definition is
moved to a submodule. Workarounds include (1) declaring "output_data" as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
Damian Rouson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #7 from Damian Rouson ---
I agree that it would have been better for image_distinct to be optional. I
co-hosted the 2018 WG5 meeting at which there were lengthy discussions around
random number generation. I don't recall whether mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #5 from Damian Rouson ---
Steve, thanks for all the time you put into implementing random_init and
responding to this PR. My confusion stemmed from the first sentence that I
quoted from the standard. It states that the provided rando
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
16.9.155 Case (i) in the Fortran 2018 standard states
CALL RANDOM_INIT (REPEATABLE=true, IMAGE_DISTINCT=true) is equivalent to
invoking RANDOM_SEED with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
--- Comment #4 from Damian Rouson ---
The above reduced version produces an ICE with gfortran 11.0.0 2020815 built
from source so this is not specific to Homebrew but is specific to macOS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below effectively has an abstract parent type ("object"), abstract
child type ("oracle")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #24 from Damian Rouson ---
This appears to be another example of an issue with a module procedure defined
in the same module as its interface body. In this case, the compiler doesn't
recognize a reference to the procedure:
± cat subr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #23 from Damian Rouson ---
A related issue arises if the procedure in question is a pure function as
demonstrated below. The code compiles cleanly if either
1. The result-spec is absent and the procedure is renamed new_foo in both th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #21 from Damian Rouson ---
Now that the patch fixing this PR has been committed to the trunk, should it be
marked as "Resolved" instead of "Assigned?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #12 from Damian Rouson ---
Thanks to each of you for looking at and working on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #9 from Damian Rouson ---
(In reply to Dominique d'Humieres from comment #3)
>
> Do you mean this is F2008 extension?
Usually I think of "extension" as describing something non-standard. This is a
standard feature. I meant simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #7 from Damian Rouson ---
For context, I nearly always put the procedure definition in a submodule. In
this case, I'm attempting to use a tool that needs to parse the code and the
tool doesn't support submodules so I moved the proced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #2 from Damian Rouson ---
Hi Dominique,
> What do you want to do with your test?
I don't understand the question. The submitted code is designed to be a minimal
demonstration of the problem so I don't want to do anything with it oth
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles cleanly with the NAG Fortran compiler. I believe the
error message is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #6 from Damian Rouson ---
Thanks, Tobias!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #2 from Damian Rouson ---
Thanks for the quick reply, Steve. My apologies for not providing any text. I
dashed this off during a call with the person who reported the problem to me.
I think the code is legal, but I'm very open to th
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat foo.f90
module foo_module
implicit none
interface
module function foo() result(bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #29 from Damian Rouson ---
Hi Paul,
The test case works with your patch applied. Thanks!
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671
--- Comment #1 from Damian Rouson ---
The submitted code also compiles and executes cleanly with the NAG Fortran
compiler version 7.0.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below generates an internal compiler error (ICE) in gfortran 8.3.0,
9.2.0, and in 10.0.0
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The ICE demonstrated below disappears if any one of the following is true:
1. The module and submodule are in the same file, or
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #27 from Damian Rouson ---
Thanks, Paul! We'll test the patch.
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513
--- Comment #5 from Damian Rouson ---
Thanks, Steve!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #6 from Damian Rouson ---
Steve, I'm so incredibly glad you posted the details of your workaround.
Thank you! I had seen the FCFLAG environment variable, but I hadn't noticed the
FFLAG variable listed just a few lines lower in the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #5 from Damian Rouson ---
MPICH must find ISO_Fortran_binding.h in order to build the modern Fortran
bindings that the MPI standard provides through the "mpi_f08" Fortran module.
Gfortran only started providing ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #3 from Damian Rouson ---
So do I need to report this to the MPICH developers or is a gfortran bug? I
tried "-w -fallow-argument-mismatch" and got the same error message.
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Below is the trailing output of configuring MPICH 3.2, 3.2.1, or 3.3.1 with the
current GCC trunk:
configure: error: The Fortran compiler /opt/gnu/10.0.0/bin/gfortran will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717
--- Comment #1 from Damian Rouson ---
FYI, this reproducer was developed by Paul Thomas based on my report that the
gfortran trunk is unable to build the json-fortran repository
(https://jacobwilliams.github.io/json-fortran/).
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$cat concat-deferred-len.f90
type core
character (len=:), allocatable :: msg
end type
type(core) :: my_core
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Based on a quick search, I don't think the Fortran standard uses the term
"impur
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 9.1.0 gives an error message when compiling the following code, which
I believe is valid and which gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90305
--- Comment #1 from Damian Rouson ---
The code gives the expected output "f" with GCC 9.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
An ASSOCIATE construct with a substring of a deferred-length character selector
yields garbage with
: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles cleanly with -fcoarray=single but generates a linker
error when I use -fcoarray=lib and link to MPICH and OpenCoarrays. The linking
problem goes away if the &quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89840
Damian Rouson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89840
--- Comment #2 from Damian Rouson ---
The PR was cited in the original description: Bug 64777. It was closed for
lack of a test cased and the person who closed it suggested opening a new PR if
a test case was provided so I attempted to do so. U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64777
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
This report is simply to provide a test case for Bug 64777, which was closed
for lack of a test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #6 from Damian Rouson ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output. In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #6 from Damian Rouson ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output. In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #4 from Damian Rouson ---
I don't agree that the code submitted in this bug report is non-sensical. The
submitted example is very useful for code debugging purposes. I just spent a
couple of hours trying to isolate this same bug. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
--- Comment #10 from Damian Rouson ---
I see no ICE in testing the code from Comment 3 using fortran 7.3.0, 8.2.0, and
9.0.1. I believe this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200
--- Comment #4 from Damian Rouson ---
Thanks, Paul!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200
--- Comment #1 from Damian Rouson ---
gfortran 8.2.0 code gives the correct output:
$gfortran corrupted-component.f90
$./a.out
12
$gfortran --version
GNU Fortran (GCC) 8.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
--- Comment #3 from Damian Rouson ---
I just created PR89200, on which this meta-bug should depend, but I don't know
how to edit the "Depends on" list.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$cat corrupted-component.f90
type foo
character(len=:), allocatable :: string
end type
type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #8 from Damian Rouson ---
(In reply to Nicolas Koenig from comment #7)
> I actually opted to use multiprocessing with shared memory (shm_open() & co)
> instead of multithreading, since it will be much easier and faster with
> static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 84894, which changed state.
Bug 84894 Summary: [F2018] provide ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #6 from Damian Rouson ---
Correction to the end of the first sentence of the final paragraph in Comment
5: "... not join them _until_ the end."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #5 from Damian Rouson ---
This is an exciting idea. When I gave some thought to writing a shared-memory
alternative coarray ABI, it seemed to me that pthreads would be a better choice
than OpenMP. Part of the problem is that I was c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
--- Comment #13 from Damian Rouson ---
Thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077
--- Comment #11 from Damian Rouson ---
Thanks, Paul!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659
--- Comment #1 from Damian Rouson ---
In initial comment, I meant to write "... bug disappears if the pointer intent
is switched to intent(inout)..."
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The following bug disappears if the pointer intent is switched to intent(out)
or if the
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 6.4, 7.3, and 8.2 all produce the error message below when attempting
to use a renamed type while in the same scope as the variable that motivated
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Gfortran 8.2.0 fails to recognize the public type-bound procedure below. The
error message goes away when "module procedur
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The consensus opinion on the J3 mailing list is that the code below is
standard-conforming. The Intel compiler accepts the code. gfortran 5.5, 6.4,
7.3, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
--- Comment #6 from Damian Rouson ---
Sounds good. I agree that it would be great for gfortran to provide
ISO_Fortran_binding.h independently. Hopefully the OpenCoarrays version will be
a useful starting point. My understanding is that it's alway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606
--- Comment #12 from Damian Rouson ---
Thank you, Andre!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 84894, which changed state.
Bug 84894 Summary: [F2018] provide ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
--- Comment #3 from Damian Rouson ---
Oxford University graduate student Daniel Celis Garza has been working on this
for the bulk of his 11-week visit with me, which ends next week. For reasons
motivated largely by the difficulty of coaxing the G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82275
--- Comment #9 from Damian Rouson ---
Thanks, Paul!
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510
--- Comment #1 from Damian Rouson ---
As similar error message results if the associate construct is replaced with a
block construct of the form
block
integer n
n=1
print*,i[1]
end block
The error disappears if the 'bl
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles without error with -fcoarray=single; whereas compiling
with -fcoarray=lib generates the
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Fortran 2018 requires that compilers provide an iso_fortran_binding.h C header
file for further interoperability with C. Such a file was on the fortran-dev
branch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
--- Comment #3 from Damian Rouson ---
With Fortran 2018 now in Committee Draft (CD) and likely to be published this
year, it probably makes sense to close this bug report. Any features from TS
29113 that will be in Fortran 2018 have already been
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 7 and 8 accept the following invalid code when the dummy argument is
declared with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
--- Comment #4 from Damian Rouson ---
(In reply to Dominique d'Humieres from comment #3)
> AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib
> -lcaf_single.
Yes, I meant to write "-fcoarray=lib -lcaf_mpi". If the errors are
compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
--- Comment #2 from Damian Rouson ---
Thanks for this! For anyone looking at this, I'll be glad to assist with
parallel execution testing via -fcoarray=lib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
--- Comment #6 from Damian Rouson ---
Using 7.2, I still see an ICE with the reduced example from Comment 3:
$ gfortran -fcoarray=lib -c bug-78983.f90
bug-78983.f90:24:0:
end module
internal compiler error: in gfc_conv_descriptor_data_get, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606
--- Comment #1 from Damian Rouson ---
Is this a duplicate of Bug #81773?
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The commands below use MPICH 3.2 installed by GCC 8 trunk dated 20171227.
Alternatively, the code can be
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Presumably the internal compiler error (ICE) demonstrated below is somehow
related to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82275
--- Comment #3 from Damian Rouson ---
Thanks for looking at this. Once there's a fix, it would be great if it could
be back-ported to GCC 7 as well.
RMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat reproducer.f90
!! Associating a name with a reduced-dimension section of a
!! multidimensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #37 from Damian Rouson ---
Bravo!
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat poly-array-section-arg.f90
!! Gfortran 7.1.0 and 8.0.0 20170731 report an ICE when a
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 6, 7, and 8 generate compiler error messages when a variable in the
iso_fortran_env intrinsic model is accessed via use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
--- Comment #3 from Damian Rouson ---
The same code causes an ICE with the 7.1.0 release. Is there a fix on the 8
branch or any related updates?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640
--- Comment #2 from Damian Rouson ---
I think this bug just bit gfortran user and Fortran enthusiast Stefano Zhagi.
Is anyone interested in fixing it?
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below causes an internal compiler error with gfortran 7.0.1, but
compiles and executes cleanly with gfortran 6.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79447
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79447
--- Comment #4 from Damian Rouson ---
Hi Paul,
Thanks for the updates. My son loves to host garage sales so let us know if
you're getting rid of the "stuff" and we'll drop by. :) Safe travels.
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79447
--- Comment #1 from Damian Rouson ---
I just tested with a more recent build (7.0.1 dated 20170205) and see the same
behavior.
rity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
A recent build of gfortran 7 doesn’t allow an internal subprogram to be
contained inside a module subprogram
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
This a gfortran issue appears in the interface body below, but doesn't
disappears if the procedu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913
--- Comment #6 from Damian Rouson ---
I don't have any specific knowledge of it being fixed, but there have been two
releases since 6.1.0: the latest is 6.3.0 and 7.1.0 is expected to be released
soon so the current trunk is a nearly releasable s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935
--- Comment #6 from Damian Rouson ---
Workaround (4) was supposed to be "when both allocations are moved into the
main program."
1 - 100 of 177 matches
Mail list logo
