[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement
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 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/communicator > > > > > > > > The FSF copyright assignment ended up being an unexpectedly-difficult > > > > hurdle > > > > at the time. I could try again if there is interest, though it would > > > > also > > > > require some effort to rework the original patch for GCC 14. If another > > > > contributor were willing to submit a clean-room implementation, that > > > > may be > > > > more expedient. > > > > > > Besides the copyright assignment there is also the possibility to use the > > > Developer's Certificate of Origin sign-off: > > > > > > https://gcc.gnu.org/dco.html > > > > Is that an option in this case? I was originally advised to pursue a > > copyright assignment > > > > https://gcc.gnu.org/pipermail/fortran/2019-January/051674.html > > That requirement was changed in 2021: > > https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html > > See also: > > https://gcc.gnu.org/contribute.html That's great news! I'll carve out some time to try to adapt the patch for GCC 14.
[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement
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. > > > > > > FYI I'm trying implement a polymorphic send/receive: > > > https://gitlab.com/everythingfunctional/communicator > > > > The FSF copyright assignment ended up being an unexpectedly-difficult hurdle > > at the time. I could try again if there is interest, though it would also > > require some effort to rework the original patch for GCC 14. If another > > contributor were willing to submit a clean-room implementation, that may be > > more expedient. > > Besides the copyright assignment there is also the possibility to use the > Developer's Certificate of Origin sign-off: > > https://gcc.gnu.org/dco.html Is that an option in this case? I was originally advised to pursue a copyright assignment: https://gcc.gnu.org/pipermail/fortran/2019-January/051674.html
[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement
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/communicator The FSF copyright assignment ended up being an unexpectedly-difficult hurdle at the time. I could try again if there is interest, though it would also require some effort to rework the original patch for GCC 14. If another contributor were willing to submit a clean-room implementation, that may be more expedient.
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
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 changed: > >What|Removed |Added > > > Status|NEW |RESOLVED > Resolution|--- |DUPLICATE > > --- Comment #6 from anlauf at gcc dot gnu.org --- > This is indeed fixed by commit r12-6387. Closing. > > Thanks for the report! > > *** This bug has been marked as a duplicate of bug 101762 *** > > -- > You are receiving this mail because: > You reported the bug.
[Bug fortran/88960] [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM
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).
[Bug fortran/88960] New: [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960 Bug ID: 88960 Summary: [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal 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: == 16.9.85 GET_TEAM ([LEVEL]) ... 3 Argument. LEVEL (optional) shall be a scalar integer whose value is equal to one of the named constants INITIAL_TEAM, PARENT_TEAM, or CURRENT_TEAM from the intrinsic module ISO_FORTRAN_ENV. == gfortran 8.2.0 does not provide these constants in ISO_FORTRAN_ENV: == $ cat test_level.f90 use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM end $ gfortran test_level.f90 test_level.f90:1:41: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'initial_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV test_level.f90:1:55: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'parent_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV test_level.f90:1:68: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'current_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV ==
[Bug fortran/87939] [F18] Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements
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
[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement
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
[Bug fortran/87939] [F18] Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements
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.
[Bug fortran/88254] New: Support construct name for CHANGE TEAM & END TEAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88254 Bug ID: 88254 Summary: Support construct name for CHANGE TEAM & END TEAM Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 also example C.6.8 from the N2146 draft of the Fortran 2018 standard). === $ cat team_construct_name.f90 program test_team_construct_name use, intrinsic :: iso_fortran_env, only: team_type implicit none type(team_type) :: team form team (1, team) team_construct_name: change team(team) if (.true.) exit team_construct_name error stop 'fail' end team team_construct_name write(*,*) 'pass' end program $ gfortran-mp-8 team_construct_name.f90 team_construct_name.f90:9:3: team_construct_name: change team(team) 1 Error: Unclassifiable statement at (1) team_construct_name.f90:10:42: if (.true.) exit team_construct_name 1 Error: Name 'team_construct_name' in EXIT statement at (1) is unknown team_construct_name.f90:12:12: end team team_construct_name 1 Error: Unclassifiable statement at (1) $ gfortran-mp-8 -v Using built-in specs. COLLECT_GCC=gfortran-mp-8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17/8.2.0/lto-wrapper Target: x86_64-apple-darwin17 Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc8/gcc8/work/gcc-8.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin17 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc8 --includedir=/opt/local/include/gcc8 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-8 --with-gxx-include-dir=/opt/local/include/gcc8/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc8 8.2.0_3' Thread model: posix gcc version 8.2.0 (MacPorts gcc8 8.2.0_3) ===
[Bug fortran/87939] New: Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87939 Bug ID: 87939 Summary: Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal 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 SYNC MEMORY statements (as standardized by Fortran 2008), in addition to EVENT POST and EVENT WAIT from the forthcoming Fortran 2018 standard. gfortran currently lacks support for STAT= and ERRMSG= specifiers in several statements where they will be allowed in Fortran 2018: FORM TEAM, CHANGE TEAM, SYNC TEAM, END TEAM, CRITICAL, and END CRITICAL. It would be beneficial to add these to gfortran to allow more comprehensive support for failed images in OpenCoarrays.
[Bug fortran/87556] New: FORM TEAM statement team-number argument interpreted incorrectly when function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87556 Bug ID: 87556 Summary: FORM TEAM statement team-number argument interpreted incorrectly when function Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: 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=edit reproducer In the attached reproducer, the gfortran 8.2.0 FORM TEAM statement appears to misinterpret a team-number actual argument when it is a scalar-int-expr involving a function, but not when the result of this expression is first assigned to an integer variable that is then used as the team-number argument. The following output, using the OpenCoarrays compiler driver, contains 4 columns: current team, this_image() in initial team, this_image() in current team, and num_images() in current team. It looks correct for my_team1 (integer variable actual argument), and incorrect for my_team2 (scalar-int-expr involving a function). $ caf -std=f2018 -Wall -Wextra test_form_team.f90 $ cafrun -np 6 ./a.out | sort my_team1 1 1 3 my_team1 2 2 3 my_team1 3 3 3 my_team1 4 1 3 my_team1 5 2 3 my_team1 6 3 3 my_team2 1 1 6 my_team2 2 2 6 my_team2 3 3 6 my_team2 4 4 6 my_team2 5 5 6 my_team2 6 6 6 This seems like the issue gfortran front-end, rather than the OpenCoarrays library. Software versions: $ caf --version OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.2.0-13-gb47afbc) Copyright (C) 2015-2018 Sourcery Institute Copyright (C) 2015-2018 Sourcery, Inc. OpenCoarrays comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of OpenCoarrays under the terms of the BSD 3-Clause License. For more information about these matters, see the file named LICENSE that is distributed with OpenCoarrays. $ caf -w caf wraps /opt/local/bin/gfortran-mp-8 $ /opt/local/bin/gfortran-mp-8 -dumpversion 8.2.0 $ mpiexec --version | head -n 2 HYDRA build details: Version: 3.3b3
[Bug fortran/87326] New: Support the NEW_INDEX= specifier in the FORM TEAM statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87326 Bug ID: 87326 Summary: Support the NEW_INDEX= specifier in the FORM TEAM statement Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal 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 N2146, modified to define & initialize P & have an END PROGRAM statement: $ cat note-11.48.f90 USE, INTRINSIC :: ISO_FORTRAN_ENV integer, parameter :: P = 8 TYPE(TEAM_TYPE) :: ROW REAL :: A [P, *] INTEGER :: ME (2) ME (:) = THIS_IMAGE (A) FORM TEAM (ME(1), ROW, NEW_INDEX=ME(2)) end program $ gfortran-mp-8 -fcoarray=single note-11.48.f90 note-11.48.f90:7:21: FORM TEAM (ME(1), ROW, NEW_INDEX=ME(2)) 1 Error: Syntax error in FORM TEAM statement at (1)
[Bug fortran/85150] New: internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 Bug ID: 85150 Summary: internal compiler error for module with illegal non-constant pointer initialization designator Product: gcc Version: 7.3.0 Status: UNCONFIRMED 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: == $ cat mod_test.f90 module mod_test implicit none integer, target :: buf(2) integer :: buf_i = 1 integer, pointer :: buf_ptr => buf(buf_i) ! invalid end module mod_test $ gfortran-mp-7 mod_test.f90 f951: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1058 f951: internal compiler error: Abort trap: 6 gfortran-mp-7: internal compiler error: Abort trap: 6 (program f951) Please submit a full bug report, with preprocessed source if appropriate. See <https://trac.macports.org/newticket> for instructions. $ gfortran-mp-7 --version GNU Fortran (MacPorts gcc7 7.3.0_0) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == This code is apparently invalid, but a helpful error message would be preferable to an internal compiler error. Compile-time errors from the Intel Fortran 18.0.1 and Cray Fortran 8.6.2 seem to indicate that the preceding code violates the following paragraph in the Fortran 2008 standard: C461 (R443) The designator shall designate a nonallocatable variable that has the TARGET and SAVE attri- butes and does not have a vector subscript. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be a constant expression.
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
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-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, BLOCK construct, or interface body.
[Bug fortran/83633] New: gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 Bug ID: 83633 Summary: gfortran internal compiler error for explicit-shape array with non-constant bounds Product: gcc Version: 7.1.0 Status: UNCONFIRMED 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 output is from the Cray-provided version on the NERSC Cori supercomputer, though I've reproduced it on macOS with MacPorts GCC 7.2.0. $ cat internal_compiler_error.f90 integer :: A(command_argument_count()) = 1 write (*,*) A end $ gfortran internal_compiler_error.f90 internal_compiler_error.f90:1:0: integer :: A(command_argument_count()) = 1 internal compiler error: Segmentation fault 0xad23bf crash_signal ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/toplev.c:337 0x6d3748 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-array.c:5701 0x6fd6d0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-expr.c:6793 0x6e2dc1 gfc_get_symbol_decl(gfc_symbol*) ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-decl.c:1800 0x6e57d7 generate_local_decl ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-decl.c:5403 0x6abef2 do_traverse_symtree ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/symbol.c:4009 0x6e644a generate_local_vars ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-decl.c:5603 0x6e644a gfc_generate_function_code(gfc_namespace*) ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/trans-decl.c:6267 0x67add6 translate_all_program_units ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/parse.c:6074 0x67add6 gfc_parse_file() ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/parse.c:6274 0x6bde2f gfc_be_parse_file ../../cray-gcc-7.1.0-201705230545.65f29659747b4/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/7.1.0/bin/../snos/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/snos/libexec/gcc/x86_64-suse-linux/7.1.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../cray-gcc-7.1.0-201705230545.65f29659747b4/configure --prefix=/opt/gcc/7.1.0/snos --disable-nls --libdir=/opt/gcc/7.1.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/7.1.0/snos/include/g++ --with-slibdir=/opt/gcc/7.1.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog --disable-multilib Thread model: posix gcc version 7.1.0 20170502 (Cray Inc.) (GCC)
[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads
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=edit Code from 80822 comment #4 run as per comment #8
[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads
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().
[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads
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=edit output from comment #4 code compiled with Intel 17.0.2
[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads
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=edit output from comment #4 code compiled with gcc 6.3.0
[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads
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='201511' [host] KMP_ABORT_DELAY='0' [host] KMP_ADAPTIVE_LOCK_PROPS='1,1024' [host] KMP_ALIGN_ALLOC='64' [host] KMP_ALL_THREADPRIVATE='256' [host] KMP_ALL_THREADS='2147483647' [host] KMP_ATOMIC_MODE='2' [host] KMP_BLOCKTIME='200' [host] KMP_CPUINFO_FILE: value is not defined [host] KMP_DETERMINISTIC_REDUCTION='FALSE' [host] KMP_DISP_NUM_BUFFERS='7' [host] KMP_DUPLICATE_LIB_OK='FALSE' [host] KMP_FORCE_REDUCTION: value is not defined [host] KMP_FOREIGN_THREADS_THREADPRIVATE='TRUE' [host] KMP_FORKJOIN_BARRIER='2,2' [host] KMP_FORKJOIN_BARRIER_PATTERN='hyper,hyper' [host] KMP_FORKJOIN_FRAMES='TRUE' [host] KMP_FORKJOIN_FRAMES_MODE='3' [host] KMP_GTID_MODE='3' [host] KMP_HANDLE_SIGNALS='FALSE' [host] KMP_HOT_TEAMS_MAX_LEVEL='1' [host] KMP_HOT_TEAMS_MODE='0' [host] KMP_INIT_AT_FORK='TRUE' [host] KMP_INIT_WAIT='2048' [host] KMP_ITT_PREPARE_DELAY='0' [host] KMP_LIBRARY='throughput' [host] KMP_LOCK_KIND='queuing' [host] KMP_MALLOC_POOL_INCR='1M' [host] KMP_NEXT_WAIT='1024' [host] KMP_NUM_LOCKS_IN_BLOCK='1' [host] KMP_PLAIN_BARRIER='2,2' [host] KMP_PLAIN_BARRIER_PATTERN='hyper,hyper' [host] KMP_REDUCTION_BARRIER='1,1' [host] KMP_REDUCTION_BARRIER_PATTERN='hyper,hyper' [host] KMP_SCHEDULE='static,balanced;guided,iterative' [host] KMP_SETTINGS='FALSE' [host] KMP_SPIN_BACKOFF_PARAMS='4096,100' [host] KMP_STACKOFFSET='64' [host] KMP_STACKPAD='0' [host] KMP_STACKSIZE='4M' [host] KMP_STORAGE_MAP='FALSE' [host] KMP_TASKING='2' [host] KMP_TASK_STEALING_CONSTRAINT='1' [host] KMP_USER_LEVEL_MWAIT='FALSE' [host] KMP_VERSION='FALSE' [host] KMP_WARNINGS='TRUE' [host] OMP_CANCELLATION='FALSE' [host] OMP_DEFAULT_DEVICE='0' [host] OMP_DISPLAY_ENV='VERBOSE' [host] OMP_DYNAMIC='FALSE' [host] OMP_MAX_ACTIVE_LEVELS='2147483647' [host] OMP_MAX_TASK_PRIORITY='0' [host] OMP_NESTED='FALSE' [host] OMP_NUM_THREADS='32' [host] OMP_PLACES='threads' [host] OMP_PROC_BIND='spread' [host] OMP_SCHEDULE='static' [host] OMP_STACKSIZE='4M' [host] OMP_THREAD_LIMIT='2147483647' [host] OMP_WAIT_POLICY='PASSIVE' [host] KMP_AFFINITY='noverbose,warnings,respect,granularity=thread,noduplicates,compact,0,0' OPENMP DISPLAY ENVIRONMENT END For comparison, the Cray 8.5.4 OpenMP runtime (which produces the same thread affinity as the Intel 17.0.2 OpenMP runtime in the aforementioned example) outputs the following when OMP_DISPLAY_ENV=verbose: OPENMP DISPLAY ENVIRONMENT BEGIN _OPENMP='201307' OMP_SCHEDULE='static,0' OMP_NUM_THREADS='32' OMP_DYNAMIC='TRUE' OMP_NESTED='FALSE' OMP_STACKSIZE='128MB' OMP_WAIT_POLICY='ACTIVE' OMP_MAX_ACTIVE_LEVELS='1023' OMP_THREAD_LIMIT='256' CRAY_OMP_CHECK_AFFINITY='FALSE' OMP_PROC_BIND='spread' OMP_PLACES='threads' OMP_CANCELLATION='FALSE' OMP_DISPLAY_ENV='VERBOSE' OMP_DEFAULT_DEVICE='0' CRAY_OMP_GUARD_SIZE='0B' CRAY_OMP_TASK_Q_LIMIT='256' CRAY_OMP_CONTENTION_POLICY='Automatic' OPENMP DISPLAY ENVIRONMENT END Also, in this environment, with OMP_NUM_THREADS=2 OMP_PLACES=threads OMP_PROC_BIND=close, the libgomp affinity results in both threads being pinned to different sockets: $ OMP_NUM_THREADS=2 OMP_PLACES=threads OMP_PROC_BIND=close ./xthi-omp.gnu | sort -k 4n,4n Hello from thread 0, on nid00015. (core affinity = 0) Hello from thread 1, on nid00015. (core affinity = 1) Both the Intel and Cray OpenMP runtimes pin the threads to the same physical core: $ OMP_NUM_THREADS=2 OMP_PLACES=threads OMP_PROC_BIND=close ./xthi-omp.intel | sort -k 4n,4n Hello from thread 0, on nid00015. (core affinity = 0) Hello from thread 1, on nid00015. (core affinity = 32) It does seem that the OpenMP 4.5 specification can be interpreted to support the libgomp behavior (e.g., p. 52 lines 33-38), though it at least seems counterintuitive.
[Bug libgomp/80822] New: libgomp incorrect affinity when OMP_PLACES=threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822 Bug ID: 80822 Summary: libgomp incorrect affinity when OMP_PLACES=threads Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 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=edit xthi.c from Cray, Inc. modified to remove MPI code On the NERSC Cori system, the Haswell nodes have two Intel Xeon E5-2698 v3 processors, each with 16 CPU cores with HyperThreading enabled. Using OMP_PLACES=threads, libgomp from gcc 6.3.0 appears to mistakenly assume that CPU (hardware thread) 0 and 1 share the same core, while in reality 0 and 32 are on the same core, etc. To illustrate, attached (xthi-omp.c) is a version of xthi.c from the "Cray XC Series User Application Placement Guide (CLE 6.0.UP01) S-2496" (https://pubs.cray.com/content/00330629-DC/FA00256413) that has been modified to remove the MPI code. The output of en MPI 1.10.2 "lstopo --of console" command (lstopo.out) that shows the processor topology is at the bottom of this text. In the first example (OMP_NUM_THREADS=32 OMP_PLACES=threads OMP_PROC_BIND=spread), CPU cores 0, 2, 4, ..., 30 each have two OpenMP threads, while CPU cores 1,3,...,31 have none: == $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list 0,32 $ gcc --version gcc (GCC) 6.3.0 20161221 (Cray Inc.) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -fopenmp -o xthi-omp.x xthi-omp.c $ OMP_NUM_THREADS=32 OMP_PLACES=threads OMP_PROC_BIND=spread ./xthi-omp.x | sort -k 4n,4n Hello from thread 0, on nid9. (core affinity = 0) Hello from thread 1, on nid9. (core affinity = 2) Hello from thread 2, on nid9. (core affinity = 4) Hello from thread 3, on nid9. (core affinity = 6) Hello from thread 4, on nid9. (core affinity = 8) Hello from thread 5, on nid9. (core affinity = 10) Hello from thread 6, on nid9. (core affinity = 12) Hello from thread 7, on nid9. (core affinity = 14) Hello from thread 8, on nid9. (core affinity = 16) Hello from thread 9, on nid9. (core affinity = 18) Hello from thread 10, on nid9. (core affinity = 20) Hello from thread 11, on nid9. (core affinity = 22) Hello from thread 12, on nid9. (core affinity = 24) Hello from thread 13, on nid9. (core affinity = 26) Hello from thread 14, on nid9. (core affinity = 28) Hello from thread 15, on nid9. (core affinity = 30) Hello from thread 16, on nid9. (core affinity = 32) Hello from thread 17, on nid9. (core affinity = 34) Hello from thread 18, on nid9. (core affinity = 36) Hello from thread 19, on nid9. (core affinity = 38) Hello from thread 20, on nid9. (core affinity = 40) Hello from thread 21, on nid9. (core affinity = 42) Hello from thread 22, on nid9. (core affinity = 44) Hello from thread 23, on nid9. (core affinity = 46) Hello from thread 24, on nid9. (core affinity = 48) Hello from thread 25, on nid9. (core affinity = 50) Hello from thread 26, on nid9. (core affinity = 52) Hello from thread 27, on nid9. (core affinity = 54) Hello from thread 28, on nid9. (core affinity = 56) Hello from thread 29, on nid9. (core affinity = 58) Hello from thread 30, on nid9. (core affinity = 60) Hello from thread 31, on nid9. (core affinity = 62) == In the second example, OMP_PROC_BIND=close results in 1 OpenMP thread per core, opposite of the intended effect: == $ OMP_NUM_THREADS=32 OMP_PLACES=threads OMP_PROC_BIND=close ./xthi-omp.x | sort -k 4n,4n Hello from thread 0, on nid9. (core affinity = 0) Hello from thread 1, on nid9. (core affinity = 1) Hello from thread 2, on nid9. (core affinity = 2) Hello from thread 3, on nid9. (core affinity = 3) Hello from thread 4, on nid9. (core affinity = 4) Hello from thread 5, on nid9. (core affinity = 5) Hello from thread 6, on nid9. (core affinity = 6) Hello from thread 7, on nid9. (core affinity = 7) Hello from thread 8, on nid9. (core affinity = 8) Hello from thread 9, on nid9. (core affinity = 9) Hello from thread 10, on nid9. (core affinity = 10) Hello from thread 11, on nid9. (core affinity = 11) Hello from thread 12, on nid9. (core affinity = 12) Hello from thread 13, on nid9. (core affinity = 13) Hello from thread 14, on nid000
[Bug c/69389] New: bit field incompatible with OpenMP atomic update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69389
Bug ID: 69389
Summary: bit field incompatible with OpenMP atomic update
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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
struct BGZF {
unsigned errcode:16, is_write:2, is_be:2;
};
int main(void) {
struct BGZF A = {0};
#pragma omp parallel
#pragma omp master
#pragma omp atomic update
A.errcode |= 1;
if (A.errcode != 1) {
printf("failed\n");
return 1;
} else {
printf("success\n");
return 0;
}
}
When compiled without OpenMP, it produces the expected result:
$ gcc atomic_bitwise_or.c
$ ./a.out
success
However, it fails to compile when OpenMP is enabled:
$ gcc -fopenmp atomic_bitwise_or.c
atomic_bitwise_or.c: In function 'main':
atomic_bitwise_or.c:13:4: error: cannot take address of bit-field 'errcode'
A.errcode |= 1;
^
gcc version info:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/5.2.0/bin/../snos/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc/5.2.0/snos/libexec/gcc/x86_64-suse-linux/5.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../cray-gcc-5.2.0/configure --prefix=/opt/gcc/5.2.0/snos
--disable-nls --libdir=/opt/gcc/5.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/5.2.0/snos/include/g++
--with-slibdir=/opt/gcc/5.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog
Thread model: posix
gcc version 5.2.0 20150716 (Cray Inc.) (GCC)
[Bug libgomp/40374] OpenMP version needs updating in GCC 4.4.0 manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40374 Nathan Weeks changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Nathan Weeks --- The man page was apparently updated long ago...
[Bug fortran/40367] New: -Wextra description missing from gfortran manual page
The gfortran manual page is missing a description of -Wextra. The description of -Wunused-parameter mentions the use of -Wall -Wextra, but nowhere in the manual page is -Wextra described. -- Summary: -Wextra description missing from gfortran manual 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
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- 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 enabled by -Wall?). -- weeks at iastate dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug web/40374] New: OpenMP version needs updating in GCC 4.4.0 manual
The gcc 4.4.0 manual states: When -fopenmp is specified, the compiler generates parallel code according to the OpenMP Application Program Interface v2.5 Per (http://gcc.gnu.org/gcc-4.4/changes.html), GCC 4.4.0 supports OpenMP 3.0. -- Summary: OpenMP version needs updating 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/bugzilla/show_bug.cgi?id=40374
