https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326
--- Comment #9 from Nathan Weeks ---
(In reply to anlauf from comment #8)
> (In reply to Nathan Weeks from comment #7)
> > (In reply to anlauf from comment #6)
> > > (In reply to Nathan Weeks from comment #5)
> > > > (In reply to Brad Richardson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326
--- Comment #7 from Nathan Weeks ---
(In reply to anlauf from comment #6)
> (In reply to Nathan Weeks from comment #5)
> > (In reply to Brad Richardson from comment #3)
> > > Was there any more progress on this? I've just run into it.
> > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326
--- Comment #5 from Nathan Weeks ---
(In reply to Brad Richardson from comment #3)
> Was there any more progress on this? I've just run into it.
>
> FYI I'm trying implement a polymorphic send/receive:
> https://gitlab.com/everythingfunctional/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150
--- Comment #7 from Nathan Weeks ---
Great, thanks!
--
Nathan
On Sat, Jan 15, 2022 at 4:11 PM anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150
>
> anlauf at gcc dot gnu.org chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960
--- Comment #1 from Nathan Weeks ---
Note that GET_TEAM() itself is currently broken in gfortran (pr88154).
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
The Fortran 2018 standard (N2146 draft) defines the GET_TEAM() intrinsic
function as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87939
--- Comment #2 from Nathan Weeks ---
The following patch attempts to address this issue & pr87326:
https://gcc.gnu.org/ml/fortran/2019-01/msg00131.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326
--- Comment #2 from Nathan Weeks ---
I think that would be appropriate, especially since I submitted a patch that
attempts to address those two simultaneously:
https://gcc.gnu.org/ml/fortran/2019-01/msg00131.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87939
--- Comment #1 from Nathan Weeks ---
My bad: END CRITICAL does not accept STAT= or ERRMSG= arguments in Fortran
2018.
nent: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
The Fortran 2018 CHANGE TEAM and END TEAM statements should support a construct
name. Support is current lacking in gfortran 8.2.0; see the example below (and
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
gcc/fortran/match.c appears to implement support for that STAT= and ERRMSG=
specifiers in LOCK, UNLOCK, SYNC ALL, SYNC IMAGES, and
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
Created attachment 44810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44810&action=edit
reproducer
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
gfortran 8.2 does not accept the NEW_INDEX= specifier of the (Fortran 2018)
FORM TEAM statement. The following example is note 11.48 from
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
The following module code results in an internal compiler error with gfortran
7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633
--- Comment #4 from Nathan T. Weeks ---
Fortran 2008 appears to have tightened restrictions on explicit-shape arrays in
the main program and made this particular case illegal (per section 5.3.8.2
"Explicit-shape array"):
C531 (R516) An explicit-
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
The following (invalid) 3-line Fortran code triggers an internal compiler error
in gfortran 7.1.0. The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #9 from Nathan Weeks ---
Created attachment 41423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41423&action=edit
Code from 80822 comment #4 run as per comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #7 from Nathan Weeks ---
The Cray 8.5.4 compiler supports only OpenMP 4.0, and so lacks support for
omp_get_num_places(), omp_get_place_num_procs(), and omp_get_place_proc_ids().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #6 from Nathan Weeks ---
Created attachment 41417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41417&action=edit
output from comment #4 code compiled with Intel 17.0.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #5 from Nathan Weeks ---
Created attachment 41416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41416&action=edit
output from comment #4 code compiled with gcc 6.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #3 from Nathan Weeks ---
Setting OMP_DISPLAY_ENV=verbose results in the following output with Intel
17.0.2:
OPENMP DISPLAY ENVIRONMENT BEGIN
_OPENMP=
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 41385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41385&action=edit
xthi.c from Cr
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: weeks at iastate dot edu
Target Milestone: ---
gcc 5.2.0 cannot utilize bit fields within an OpenMP atomic update.
Consider the following code (atomic_bitwise_or.c):
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40374
Nathan Weeks changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
in GCC 4.4.0 manual
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weeks at iastate dot edu
http://gcc.gnu.org
--- Comment #4 from weeks at iastate dot edu 2009-06-07 22:15 ---
I was somehow looking at an older version of the gcc manual page; the 4.4.0
version does describe -Wextra. Mea culpa.
--
weeks at iastate dot edu changed:
What|Removed |Added
--- Comment #2 from weeks at iastate dot edu 2009-06-07 16:14 ---
The description in the gcc manual page states the behavior for C/C++; little of
it could apply to Fortran. It would be nice to know how how this option
affects Fortran code (e.g., does it turn on all the warnings not
l page
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weeks at iastate dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
28 matches
Mail list logo
