[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-10-21 18:59 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01311.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-21 18:57 --- Subject: Bug 24455 CVSROOT:/cvs/gcc Module name:gcc Branch: gomp-20050608-branch Changes by: [EMAIL PROTECTED]2005-10-21 18:57:39 Modified files: gcc: ChangeLog.gomp c-decl.c c-parser.c c-tree.h gcc/cp : ChangeLog.gomp cp-tree.h decl.c semantics.c libgomp: ChangeLog Added files: libgomp/testsuite/libgomp.c++: pr24455-1.C pr24455.C libgomp/testsuite/libgomp.dg: pr24455-1.c pr24455.c Log message: gcc/ PR 24455 * c-tree.h (C_DECL_THREADPRIVATE_P): Define. * c-parser.c (c_parser_omp_threadprivate): Set. Do not error out if C_DECL_THREADPRIVATE_P is set already. * c-decl.c (diagnose_mismatched_decls): Do not check for mismatched thread-local attributes when OLDDECL is marked threadprivate and NEWDECL has no thread-local attributes. (merge_decls): Merge C_DECL_THREADPRIVATE_P. gcc/cp/ PR 24455 * cp/cp-tree.h (struct lang_decl_flags): Add field threadprivate_p. (CP_DECL_IS_THREADPRIVATE): Define. * cp/semantics.c (finish_omp_threadprivate): Set. Do not error out if CP_DECL_IS_THREADPRIVATE is set already. * cp/decl.c (duplicate_decls): Merge CP_DECL_THREADPRIVATE_P. libgomp/ PR 24455 * testsuite/libgomp.c++/pr24455-1.C: New test. * testsuite/libgomp.c++/pr24455.C: New test. * testsuite/libgomp.dg/pr24455-1.c: New test. * testsuite/libgomp.dg/pr24455.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.gomp.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.6.97&r2=1.1.6.98 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.662.4.13&r2=1.662.4.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parser.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=2.17.4.37&r2=2.17.4.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.203.4.10&r2=1.203.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.gomp.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.8.14&r2=1.1.8.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1144.4.13&r2=1.1144.4.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1403.4.9&r2=1.1403.4.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.475.4.12&r2=1.475.4.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgomp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.6.49&r2=1.1.6.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgomp/testsuite/libgomp.c++/pr24455-1.C.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgomp/testsuite/libgomp.c++/pr24455.C.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgomp/testsuite/libgomp.dg/pr24455-1.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgomp/testsuite/libgomp.dg/pr24455.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #5 from dnovillo at gcc dot gnu dot org 2005-10-20 17:52 --- The problem here is that when we are parsing the second declaration, we call start_decl before having parsed the threadprivate clause. This causes us to miss the attribute. One solution I'm considering is to look-ahead in c_parser_declaration_or_fndef and build a regular tls_model attribute instead of lazily setting DECL_TLS_MODEL when we get to the threadprivate #pragma. That seems a more natural way of setting threadprivate attributes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #4 from dnovillo at redhat dot com 2005-10-20 17:07 --- Subject: Re: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de > Doesn't translation unit cover the include file? > > But anyway. How should I mark it threadprivate in file2.c? > Adding "#pragma omp threadprivate (i)" before or after "int i;" > doesn't work. > Indeed, sorry about that. I misread your code. I'll take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
Re: [Bug c/24455] [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de > Doesn't translation unit cover the include file? > > But anyway. How should I mark it threadprivate in file2.c? > Adding "#pragma omp threadprivate (i)" before or after "int i;" > doesn't work. > Indeed, sorry about that. I misread your code. I'll take a look.
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #3 from reichelt at igpm dot rwth-aachen dot de 2005-10-20 16:50 --- Subject: Re: [gomp] Trouble with threadprivate and extern On 20 Oct, dnovillo at redhat dot com wrote: > > > --- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 --- > Subject: Re: New: [gomp] Trouble with threadprivate and extern > > On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: > >> I'd expect that i is threadprivate in file1.c and file2.c. >> > But you have to mark it so in both places. > >> Am I misreading the OpenMP spec or is this a bug in the frontends? >> > I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: > > "If a variable is specified in a threadprivate directive in one translation > unit, it must be specified in a threadprivate directive in every > translation unit in which it is declared." Doesn't translation unit cover the include file? But anyway. How should I mark it threadprivate in file2.c? Adding "#pragma omp threadprivate (i)" before or after "int i;" doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 16:49 --- (In reply to comment #1) > Subject: Re: New: [gomp] Trouble with threadprivate and extern > > On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: > > > I'd expect that i is threadprivate in file1.c and file2.c. > > > But you have to mark it so in both places. Huh, to me it is marked in both TUs. --- file1.c is equivalant to: extern int i; #pragma omp threadprivate (i) int main() { return i; } --- While file2.c is equivalant to: extern int i; #pragma omp threadprivate (i) int i; --- I don't see anything wrong here at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 --- Subject: Re: New: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: > I'd expect that i is threadprivate in file1.c and file2.c. > But you have to mark it so in both places. > Am I misreading the OpenMP spec or is this a bug in the frontends? > I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: "If a variable is specified in a threadprivate directive in one translation unit, it must be specified in a threadprivate directive in every translation unit in which it is declared." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455