https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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 #20 from Andreas Schwab ---
aarch64 also fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #19 from Jakub Jelinek ---
Author: jakub
Date: Sat Sep 3 09:20:03 2016
New Revision: 239970
URL: https://gcc.gnu.org/viewcvs?rev=239970&root=gcc&view=rev
Log:
PR c/65467
* gcc.dg/gomp/_Atomic-4.c: Require vect_simd_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #18 from Jakub Jelinek ---
(In reply to Andreas Schwab from comment #17)
> FAIL -> UNSUPPORTED
That is expected on targets that don't provide compute_vecsize_and_simdlen
target hook. If it is a target with reasonable vector support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #17 from Andreas Schwab ---
FAIL -> UNSUPPORTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #16 from Jakub Jelinek ---
(In reply to Andreas Schwab from comment #15)
> FAIL: gcc.dg/gomp/_Atomic-4.c (test for warnings, line 7)
Does
--- gcc/testsuite/gcc.dg/gomp/_Atomic-4.c.jj2016-09-02 20:36:22.0
+0200
+++ gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #15 from Andreas Schwab ---
FAIL: gcc.dg/gomp/_Atomic-4.c (test for warnings, line 7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 2 18:38:07 2016
New Revision: 239964
URL: https://gcc.gnu.org/viewcvs?rev=239964&root=gcc&view=rev
Log:
PR c/65467
* gimplify.c (gimplify_adjust_omp_clauses_1):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
Jakub Jelinek changed:
What|Removed |Added
Attachment #39524|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #12 from Jakub Jelinek ---
Actually, firstprivate on _Atomic vars in target construct could be implemented
just by forcing it into a temporary with non-_Atomic qualified type on the host
side (i.e. atomically loading it), firstprivati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #11 from Jakub Jelinek ---
Created attachment 39524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39524&action=edit
gcc7-pr65467-wip.patch
Untested WIP patch. This attempts to handle _Atomic qualified vars/expressions
etc. wh
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 #9 from Andrew Pinski ---
(In reply to Jeff Hammond from comment #8)
> So GCC refuses to compile any code that potentially includes undefined
> behavior?
Semantics not being defined is different than undefined behavior.
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 #6 from Andrew Pinski ---
(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 an uncountable number of others?
This is differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #5 from Andrew Pinski ---
From the original discussions on why this is disabled:
_Atomic support is currently disabled for Objective-C and OpenMP. For
both (but mainly OpenMP), the relevant parser code needs checking to
determine whe
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
21 matches
Mail list logo