https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
Jeff Hammond changed:
What|Removed |Added
CC||jeff.science at gmail dot com
: 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
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?
Is
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 best
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
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 --build=aarch64-apple-d
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&action=edit
source code that t
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.
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 (whic
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:
> https://gcc.
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 this
++
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.cppreferenc
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 goal is
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 no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350
Jeff Hammond changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81350
Jeff Hammond changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
: 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&action=edit
source code associated with bug
Code is correct with Intel
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
reference to `std::vector >::vector(std::v
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, wh
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
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 -fop
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
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&action=edit
tasks C++
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&action=edit
header for C++ codes
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&action=edit
doacross C++
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&action=edit
sequential C++
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&action=edit
tasks Fortran
This code runs faster than serial (assuming blocking is used), showing that
this pattern can be pa
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&action=edit
doacross Fortran
: 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&action=edit
sequential code
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,
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 er
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
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
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 defin
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 allowing
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
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.
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
a
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250
--- Comment #13 from Jeff Hammond ---
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 compiler, or any compiler for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250
--- Comment #9 from Jeff Hammond ---
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, true, but that doesn't stop gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250
--- Comment #7 from Jeff Hammond ---
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 the problem, why not make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250
Jeff Hammond changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250
--- Comment #3 from Jeff Hammond ---
Unfortunately, this does not change anything.
> gfortran-5 -traditional-cpp -I. -E source.F
# 1 "source.F"
# 1 ""
# 1 ""
# 1 "source.F"
C
C OLD SCHOOL COMMENTS
C
subroutine xyz(stuff)
implicit no
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 a
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=36195&action=edit
source file
I do not underst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
Jeff Hammond changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
Jeff Hammond changed:
What|Removed |Added
CC||jeff.science at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #5 from Jeff Hammond ---
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 steps forward towards C11 complia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #2 from Jeff Hammond ---
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 based upon their priorities.
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 clos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340
Jeff changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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
C
53 matches
Mail list logo
