[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220 Jeff Hammond changed: What|Removed |Added CC||jeff.science at gmail dot com

[Bug fortran/107375] New: CFI_cdesc_t incorrectly reports non-interoperable C structure as such

: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Interoperable C structs are not permitted to contain allocatable members, among other things. The compiler should report

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #11 from Jeff Hammond --- > program foo >use f >integer i >call test(i) > end program > > which specific subroutine is called based on TKR? I understand there is an ambiguity here, but what if I never make this call?

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #2 from Jeff Hammond --- Is this ever going to be fixed? I observe that a similar MCVE (below) is compiled without complaint by Intel, Cray and NAG Fortran, so it's almost certainly a lack of support for the standard in GCC. As

[Bug fortran/101602] New: local and local_init are not supported in DO CONCURRENT

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Fortran 2018 (https://j3-fortran.org/doc/year/18/18-007r1.pdf) has three locality specifiers: shared, local and local_init. GCC Fortran

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #7 from Jeff Hammond --- @Martin % gfortran -O3 -fprefetch-loop-arrays --verbose -c ctrsm.f && echo OKAY Using built-in specs. COLLECT_GCC=gfortran Target: aarch64-apple-darwin20 Configured with: ../configure

[Bug fortran/99092] New: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Created attachment 50179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50179=edit source code that triggers bug

[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 --- Comment #12 from Jeff Hammond --- I apologize for stupidly misinterpreting the automated message as something else. My email client did not show the true sender address.

[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 --- Comment #11 from Jeff Hammond --- Thanks for sharing. I’ve seen that bug or closely related ones before. This is definitely one of the motivating examples for this feature set. The only question is how many years before it gets adopted

[Bug libstdc++/85998] feature request: support C++17 parallel STL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85998 --- Comment #5 from Jeff Hammond --- > Finishing C++17 support in libstdc++ is already one of our top priorities for > GCC 9. There's no need to ask for it, and doing so won't affect priorities. > The missing pieces are documented: >

[Bug libstdc++/85998] feature request: support C++17 parallel STL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85998 --- Comment #3 from Jeff Hammond --- Other projects use the existence of feature requests in their bug tracker for prioritization of development. How does GCC manage this information? How do you track GCC roadmap development if not through

[Bug c++/85998] New: feature request: support C++17 parallel STL

++ Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- I'd like to see GCC evolve https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html into a proper implementation of the C++17 parallel STL (http://en.cppreference.com

[Bug c/84274] New: [feature request] mbind attribute

Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- https://sourceware.org/ml/binutils/2017-03/msg00261.html describes as-of-yet-unimplemented attributes to control the placement of data into new variants of bss, data, etc. > The g

[Bug driver/81358] libatomic not automatically linked with C11 code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #5 from Jeff Hammond --- Indeed, _Atomic is a language keyword and doesn't require any headers (the inclusion of stdatomic.h in this code is superfluous), so the "header->explicit library" argument doesn't apply. In any case, I do

[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Jeff Hammond changed: What|Removed |Added Resolution|FIXED |INVALID

[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350 Jeff Hammond changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug fortran/81350] New: gfortran OpenMP taskloop segfaults or incorrect

: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Created attachment 41697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41697=edit source code associated with bug Code is correct with Intel 18 but genera

[Bug c++/81314] New: In function `star1(int, std::vector<double, std::allocator >&) [clone ._omp_cpyfn.1]': $(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined reference to `std::vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81314 Bug ID: 81314 Summary: In function `star1(int, std::vector&) [clone ._omp_cpyfn.1]': $(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #10 from Jeff Hammond --- Thanks for the feedback. I agree that it is a huge amount of work to optimize this. For what it's worth, GCC and Clang perform about the same. Unfortunately, I do not have the means to evaluate IBM XLF,

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #8 from Jeff Hammond --- I tried with schedule(dynamic) and schedule(static,n) for n=1,8,100. None of this made a positive difference. Is that expected? I'm happy to make any code changes that don't break correctness and are still

[Bug libstdc++/81221] [7/8 Regression] stl_algo.h: error: ‘__sample’ is not a member of ‘std’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81221 --- Comment #2 from Jeff Hammond --- Thank you! Indeed, that fixes it, both when applied directly to the installed header and when integrated into a build of the latest version. $ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL

[Bug libstdc++/81221] New: stl_algo.h: error: ‘__sample’ is not a member of ‘std’

Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- The trivial parallel STL example from the documentation (https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode_using.html) does not compile with GCC

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #6 from Jeff Hammond --- Created attachment 41566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41566=edit tasks C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #5 from Jeff Hammond --- Created attachment 41565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41565=edit header for C++ codes

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #4 from Jeff Hammond --- Created attachment 41564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41564=edit doacross C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #3 from Jeff Hammond --- Created attachment 41563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41563=edit sequential C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #2 from Jeff Hammond --- Created attachment 41562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41562=edit tasks Fortran This code runs faster than serial (assuming blocking is used), showing that this pattern can be

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81108 --- Comment #1 from Jeff Hammond --- Created attachment 41561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41561=edit doacross Fortran

[Bug libgomp/81108] New: OpenMP doacross (omp do/for ordered) performance

: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 41560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41560=edit sequential code When I

[Bug middle-end/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80161 --- Comment #5 from Jeff Hammond --- Thanks for the comments. Indeed, I made all the changes to the containing project to compile in C++ and the problem went away. I will likely just switch to the preprocessor solution for now. For posterity,

[Bug target/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80161 --- Comment #2 from Jeff Hammond --- Fair point, but the error is "error: the last argument must be scale 1, 2, 4, 8" and "const int scale = 1" sure seems like it should be interpreted by the compiler as "1", given "scale" has local scope (the

[Bug c/80161] New: const argument hidden from AVX intrinsics due to OpenMP outlining

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- I get "error: the last argument must be scale 1, 2, 4, 8" when the argument is "const int scale = 1", only w

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #21 from Jeff Hammond --- Thanks. This is great. I built GCC master last night and can now compile both the trivial test program and a more interesting one that encapsulates what I actually need to work to make progress on OpenMP 5

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #10 from Jeff Hammond --- (In reply to Andrew Pinski from comment #9) > (In reply to Jeff Hammond from comment #8) > > So GCC refuses to compile any code that potentially includes undefined > > behavior? > > Semantics not being

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #8 from Jeff Hammond --- (In reply to Andrew Pinski from comment #6) > (In reply to Jeff Hammond from comment #3) > > Do you seriously pick this one time to prevent the user from even trying to > > write incorrect code, while

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #7 from Jeff Hammond --- The fact that the parser doesn't handle a particle case where something might go wrong is no reason to have the compiler refuse to compile code that includes stdatomic.h with -fopenmp. Look at my example and

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #4 from Jeff Hammond --- Apparently, the GCC team wants to make it impossible for anyone to build software where independent components that share CFLAGS in the build system cannot use both the C11 atomics header and the OpenMP flag.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #3 from Jeff Hammond --- This is awful. How do I disable this horrible thing? I am using OpenMP to create a thread pool, because C11 threads are still not implemented in glibc, and all of my access to C11 _Atomic variables use C11

[Bug c/69680] New: stdlib.h does not declare aligned_alloc

Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- When I use aligned_alloc, I am told to include stdlib.h to provide a declaration, but I have already done so. VERSION $ gcc-5 -v Using built-in specs. COLLECT_GCC=gcc-5

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #9 from Jeff Hammond jeff.science at gmail dot com --- First, you will not accept the fusion of cpp+gfortran behavior as a feature request? Is there a reason other than you do not want to do it because you are already busy? Second

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #13 from Jeff Hammond jeff.science at gmail dot com --- This is all fair. I try very hard to fix my own bugs and submit patches, but in this case I am wholly unqualified. I don't know the first thing about implementing a production

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 Jeff Hammond jeff.science at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #7 from Jeff Hammond jeff.science at gmail dot com --- And your obvious workaround is in fact not one because it changes the behavior of gfortran for Fortran source code and breaks the build in another way. And even if it did solve

[Bug fortran/67250] New: gfortran does not faithfully preprocess the way cpp does

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Created attachment 36195 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36195action=edit source file I do not understand why

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #3 from Jeff Hammond jeff.science at gmail dot com --- Unfortunately, this does not change anything. gfortran-5 -traditional-cpp -I. -E source.F # 1 source.F # 1 built-in # 1 command-line # 1 source.F C C OLD SCHOOL COMMENTS C

[Bug fortran/67251] New: gfortran does not faithfully preprocess the way cpp does

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- I do not understand why gfortran -I. -E source.F does not give the same result as cpp-5 -I. -E source.F. It appears that gfortran does

[Bug c/58016] stdatomic.h missing in 4.8.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #5 from Jeff Hammond jeff.science at gmail dot com --- Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ in GCC so I can submit a patch? I'd rather solve the problem and take 1-2

[Bug c/58016] stdatomic.h missing in 4.8.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 Jeff Hammond jeff.science at gmail dot com changed: What|Removed |Added CC||jeff.science

[Bug c/58016] stdatomic.h missing in 4.8.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 Jeff Hammond jeff.science at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c/58016] New: stdatomic.h missing in 4.8.1

Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com GCC 4.8.1 provides a -std=c11 option that defines __STDC_VERSION__ = 201112L and does not define __STDC_NO_ATOMICS__, hence is required to provide stdatomic.h. This requirement is not met. This ticket is closely

[Bug c/58016] stdatomic.h missing in 4.8.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #2 from Jeff Hammond jeff.science at gmail dot com --- If GCC doesn't support C11, it should not claim to support C11 via __STDC_VERSION__. The C11 standard definition isn't a recommendation from which implementers can pick and choose

[Bug fortran/46340] internal compiler error: Segmentation fault building LAPACK 3.1.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340 Jeff jeff.science at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED

[Bug fortran/46340] New: internal compiler error: Segmentation fault building LAPACK 3.1.1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340 Summary: internal compiler error: Segmentation fault building LAPACK 3.1.1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3