From MAILER-DAEMON Fri Jul 04 08:26:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19YPcl-0002rG-9m for mharc-gomp-discuss@gnu.org; Fri, 04 Jul 2003 08:25:11 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19YPcO-0002Ck-Me for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 08:24:48 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19YPbn-0000Oj-82 for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 08:24:14 -0400 Received: from gw.comsys.ideon.se ([62.95.120.145] helo=kanga.comsys.se) by monty-python.gnu.org with esmtp (Exim 4.20) id 19YPbN-0007cl-MK for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 08:23:45 -0400 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated bits=0)h64CNfel005045 for ; Fri, 4 Jul 2003 14:23:42 +0200 Message-ID: <3F0571CD.6020700@comsys.se> Date: Fri, 04 Jul 2003 14:23:41 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: sv, sv-fi, en, ar, ar-dz, ar-bh, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye, bs, be, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja, ru, sr MIME-Version: 1.0 To: gomp-discuss@nongnu.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Gomp-discuss] Since tree-ssa is on it's way ... X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Jul 2003 12:25:09 -0000 Perhaps it's time for some activities ? / Lars Segerlund. From MAILER-DAEMON Fri Jul 04 09:17:41 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19YQOT-0001ms-Ao for mharc-gomp-discuss@gnu.org; Fri, 04 Jul 2003 09:14:29 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19YQNg-0001J0-5j for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 09:13:40 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19YQLq-0000H9-U3 for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 09:11:47 -0400 Received: from lvs00-fl.valueweb.net ([216.219.253.199] helo=ams006.ftl.affinity.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19YQG3-0006p6-SR for gomp-discuss@nongnu.org; Fri, 04 Jul 2003 09:05:47 -0400 Received: from coyotegulch.com ([68.200.44.160]) by ams.ftl.affinity.com with ESMTP id <216457-18810>; Fri, 4 Jul 2003 09:05:20 -0400 Message-ID: <3F057B8D.1070602@coyotegulch.com> Date: Fri, 04 Jul 2003 09:05:17 -0400 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: en MIME-Version: 1.0 To: gomp-discuss@nongnu.org Subject: Re: [Gomp-discuss] Since tree-ssa is on it's way ... References: <3F0571CD.6020700@comsys.se> In-Reply-To: <3F0571CD.6020700@comsys.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Jul 2003 13:14:27 -0000 Lars Segerlund wrote: > Perhaps it's time for some activities ? I've just been swamped with work and research; by mid-July, things should slow down a bit. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) From MAILER-DAEMON Tue Jul 08 15:37:28 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19ZyHH-0007Ep-Ms for mharc-gomp-discuss@gnu.org; Tue, 08 Jul 2003 15:37:27 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19ZyHF-0007Ck-Ad for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 15:37:25 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19ZyHC-0007AP-Rq for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 15:37:23 -0400 Received: from 3eea1ab7.cable.wanadoo.nl ([62.234.26.183] helo=steven.lr-s.tudelft.nl) by monty-python.gnu.org with esmtp (Exim 4.20) id 19ZyFn-0006k2-Hp for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 15:35:55 -0400 Received: from steven.lr-s.tudelft.nl (localhost.localdomain [127.0.0.1]) h68JbsSj014781; Tue, 8 Jul 2003 21:37:55 +0200 Received: (from steven@localhost) by steven.lr-s.tudelft.nl (8.12.8/8.12.8/Submit) id h68JbpZC014779; Tue, 8 Jul 2003 21:37:51 +0200 X-Authentication-Warning: steven.lr-s.tudelft.nl: steven set sender to s.bosscher@student.tudelft.nl using -f From: Steven Bosscher To: zack@codesourcery.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057693070.3657.151.camel@steven.lr-s.tudelft.nl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 08 Jul 2003 21:37:51 +0200 cc: GNU OpenMP Subject: [Gomp-discuss] Lexing and parsing OMP directives, again X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Jul 2003 19:37:26 -0000 Zack Weinberg wrote in http://gcc.gnu.org/ml/gcc/2003-02/msg00653.html: > Steven Bosscher writes: > > > > Pragmas are registered in cpplib with a handler that is called from > > cpplib. So the lexer and parser never see the pragmas. This makes it a > > bit difficult to have elaborate interaction between the parser and the > > pragma handlers. There are additional callbacks for most pragmas from > > c-decl (the maybe_apply_{weak,renaming_pragma} functions) because the > > compiler may encounted symbols that are affected by those pragmas long > > after the pragma itself was handled. > > > > In OpenMP, the pragmas are more like grammar productions. Certain > > pragmas can only be followed or by a compound statement, some other > > pragmas can only appear inside a compound. Some constructs need > > information about scope and/or about how deep they're nested. > > > > In fact, the OpenMP specifications present the OpenMP pragmas as grammar > > extensions for C/C++! > > Pragmas are callbacks only for historical reasons: It was easier to > implement them that way at the time. With the C/C++ front ends moving > to recursive descent parsers, it would make perfect sense to put them > back in the token stream. Perhaps we would transform > > #pragma foo bar baz > > into > > __builtin_pragma foo bar baz; > > and feed that to phase 7. > > zw Hi, With the GOMP project we still haven't found out how to lex/parse OMP directives. That bothers me a bit so I've been giving this a lot of thought lately, but I still don't see how it can be done without major changes. We need to figure this out before we can hack the front ends. I was hoping maybe you can give me some help here because you probably have the best idea of what exactly you mean with "phase 7" and you know cpplib best :-) So what problems are we facing when lexing/parsing OpenMP pragmas? Most of these have to do with how GCC handles pragmas. The more I looked at it, the more I have to agree with the responses we received from the GCC mailing list last time the GOMP project was discussed there: Pragma's really suck big time. AFAICU, cpplib allows the front end to register a "pragma handler" which can lex tokens with cpplib (with no macro expansion). The handler receives CPP_EOF when the preprocessor finds an end-of-line. _The_ single most important problem we're facing is that GCC can only handle really simple pragmas that can appear anywhere, ie. have no syntactic context. On the other hand, OMP pragmas can only appear in certain contexts, they can be nested, and they sometimes restrict the syntax of the expressions following the pragma (eg. "parallel for"). This means that we have to figure out a way to make the parser aware of OpenMP. A related problem is that it is almost impossible to implement the "if", "num_threads" and "reduction" clauses. These clauses can have full scalar C/C++ expressions as their arguments. Calling (expression) parser from a GCC pragma handler is difficult to do because such handlers are unaware of the state of the parser. And obviously it's even impossible if you're using a YACC-derived parser... Writing an expression parser just for OpenMP is _not_ an option, so again, we need to hook up OMP pragmas with the parser somehow. Sebastian Pop has been playing with rewriting those "#pragma OMP"s as builtin _functions_. He wrote in a message to the GOMP list: --------------------------- Following the discussion from gcc@ we should transform the entire line into something that looks like a function call: #pragma omp flush (x) to __builtin_omp_flush (x); But then what happens when we're given something like that: #pragma omp parallel shared (j, sum) private (i) schedule (runtime) Would it be transformed into __builtin_omp_parallel (shared (j, sum), private (i), schedule (runtime)); ? --------------------------- I believe it is obvious that this approach is not going to work. It is unclear to me how we can handle the syntactic restrictions on expressions following the OMP pragmas, or nested pragmas, etc. when we have to handle them as builtin functions. After re-reading that mail from you to gcc@, I think you had something else in mind: Not builtin _functions_, but rather some kind of token __builtin_pragma, and a regular stream of tokens following that. If I understand your idea correctly, this means that the parser would be (more) responsible for handling pragmas. This would be ideal to us. However, I and probably most others in the GOMP project, are not exactly C/C++ language lawyers. At least I don't have a clue what "phase 7" means, and how it is related to recursive descent parsing. Could you please explain your idea a bit further, and maybe point us to some "Further reading" material? Gr. Steven From MAILER-DAEMON Tue Jul 08 16:35:55 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19ZzBb-0008Ax-Mj for mharc-gomp-discuss@gnu.org; Tue, 08 Jul 2003 16:35:39 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19ZzBL-00082X-BL for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 16:35:23 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Zz8e-0006r4-Vb for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 16:32:37 -0400 Received: from voldemort.codesourcery.com ([65.73.237.138] helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Zz3V-0005Ac-P9 for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 16:27:17 -0400 Received: (qmail 11891 invoked from network); 8 Jul 2003 20:26:05 -0000 Received: from egil.codesourcery.com (HELO taltos.codesourcery.com) (zack@66.92.14.122) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 8 Jul 2003 20:26:05 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 8 Jul 2003 13:27:15 -0700 From: "Zack Weinberg" To: Steven Bosscher References: <1057693070.3657.151.camel@steven.lr-s.tudelft.nl> Date: Tue, 08 Jul 2003 13:27:14 -0700 In-Reply-To: <1057693070.3657.151.camel@steven.lr-s.tudelft.nl> (Steven Bosscher's message of "08 Jul 2003 21:37:51 +0200") Message-ID: <871xx03gt9.fsf@egil.codesourcery.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: GNU OpenMP Subject: [Gomp-discuss] Re: Lexing and parsing OMP directives, again X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Jul 2003 20:35:37 -0000 Steven Bosscher writes: >> Perhaps we would transform >> #pragma foo bar baz >> into >> __builtin_pragma foo bar baz; >> and feed that to phase 7. > > With the GOMP project we still haven't found out how to lex/parse OMP > directives. That bothers me a bit so I've been giving this a lot of > thought lately, but I still don't see how it can be done without major > changes. We need to figure this out before we can hack the front ends. > I was hoping maybe you can give me some help here because you probably > have the best idea of what exactly you mean with "phase 7" and you know > cpplib best :-) ... > > After re-reading that mail from you to gcc@, I think you had something > else in mind: Not builtin _functions_, but rather some kind of token > __builtin_pragma, and a regular stream of tokens following that. If I > understand your idea correctly, this means that the parser would be > (more) responsible for handling pragmas. This would be ideal to us. > > However, I and probably most others in the GOMP project, are not exactly > C/C++ language lawyers. At least I don't have a clue what "phase 7" > means, and how it is related to recursive descent parsing. "Phase 7" is a term from the C standard. The short version is that it refers to the parsing phase of translation (and everything after that). You've correctly understood my suggestion. I had in mind that cpplib would, upon encountering a #pragma, first check whether it was a #pragma that affects preprocessor behavior. If not, it would inject the token __builtin_pragma into its output stream, then pass all the tokens following the #pragma on unchanged, and finally inject a ; token at the end of the directive line. The C parser would then interpret __builtin_pragma as a _keyword_, and expect a stream of tokens following - with whatever syntax and semantics are necessary - until it reached the trailing semicolon, at which point it would go back to the normal grammar. C99's _Pragma() would get the same treatment, except that its argument would be unstringified first. The only thing this has to do with recursive descent parsing is that this suggestion would be a major major PITA to implement with the current yacc-based C parser. So I would suggest that the GOMP project help out with the existing plans to reimplement the C parser in recursive descent style. Neil is, or was, working on this; you should talk to him. zw From MAILER-DAEMON Tue Jul 08 22:19:29 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19a3tn-000137-T8 for mharc-gomp-discuss@gnu.org; Tue, 08 Jul 2003 21:37:35 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19a3fy-0006Hr-Vg for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 21:23:18 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19a3Hl-0001hZ-5l for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 20:58:48 -0400 Received: from gnuftp.gnu.org ([199.232.41.6]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19a3DJ-0000bF-6H for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 20:53:41 -0400 Received: from mail.physics.ox.ac.uk ([163.1.244.140] helo=janus.physics.ox.ac.uk) by gnuftp.gnu.org with esmtp (Exim 4.20) id 19ZzfZ-0000a2-8k for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 17:06:37 -0400 Received: from amavis by janus.physics.ox.ac.uk with scanned-ok (Exim 4.10) id 19ZzfV-0005H8-00 for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 22:06:33 +0100 Received: from eros.physics.ox.ac.uk ([163.1.247.107] helo=netra2.physics.ox.ac.uk) by janus.physics.ox.ac.uk with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 19ZzfS-0005FY-00 for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 22:06:30 +0100 Received: from aphrodite ([163.1.247.104] helo=aphrodite.physics.ox.ac.uk) by netra2.physics.ox.ac.uk with esmtp (Exim 3.32 #1) id 19ZzfR-0002KN-00 for gomp-discuss@nongnu.org; Tue, 08 Jul 2003 22:06:29 +0100 Received: from localhost (lucini@localhost) by aphrodite.physics.ox.ac.uk with SMTP id WAA08647 for ; Tue, 8 Jul 2003 22:06:29 +0100 (BST) X-Authentication-Warning: aphrodite.physics.ox.ac.uk: lucini owned process doing -bs Date: Tue, 8 Jul 2003 22:06:29 +0100 (BST) From: Biagio Lucini X-X-Sender: lucini@aphrodite To: gomp-discuss@nongnu.org In-Reply-To: <3F057B8D.1070602@coyotegulch.com> Message-ID: References: <3F0571CD.6020700@comsys.se> <3F057B8D.1070602@coyotegulch.com> MIME-Version: 1.0 Subject: Re: [Gomp-discuss] Since tree-ssa is on it's way ... Content-Type: TEXT/PLAIN; charset=US-ASCII X-AVtransport: scanmails_remote X-AVwrapper: AMaViS (http://www.amavis.org/) X-AVscanner: Sophos sweep (http://www.sophos.com/) X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1.2 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 01:37:33 -0000 On Fri, 4 Jul 2003, Scott Robert Ladd wrote: > Lars Segerlund wrote: > > Perhaps it's time for some activities ? > > I've just been swamped with work and research; by mid-July, things > should slow down a bit. > No better luck here: I am traveling around the world for conferences, things should settle down only this autumn. Apologies. Biagio From MAILER-DAEMON Wed Jul 09 04:41:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19aAWD-0003tj-K7 for mharc-gomp-discuss@gnu.org; Wed, 09 Jul 2003 04:41:41 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19aAW1-0003m4-17 for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 04:41:29 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19aAV3-0003E9-E7 for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 04:41:00 -0400 Received: from gw.comsys.ideon.se ([62.95.120.145] helo=kanga.comsys.se) by monty-python.gnu.org with esmtp (Exim 4.20) id 19aAUY-000358-Se for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 04:39:59 -0400 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated bits=0) by kanga.comsys.se (8.12.3/8.12.3/Debian-6.3) with ESMTP id h698ds7h009046 for ; Wed, 9 Jul 2003 10:39:55 +0200 Message-ID: <3F0BD4DA.3050108@comsys.se> Date: Wed, 09 Jul 2003 10:39:54 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 X-Accept-Language: sv, sv-fi, en, ar, ar-dz, ar-bh, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye, bs, be, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja, ru, sr MIME-Version: 1.0 To: gomp-discuss@nongnu.org Subject: Re: [Gomp-discuss] Re: Lexing and parsing OMP directives, again References: <1057693070.3657.151.camel@steven.lr-s.tudelft.nl> <871xx03gt9.fsf@egil.codesourcery.com> In-Reply-To: <871xx03gt9.fsf@egil.codesourcery.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1.2 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 08:41:39 -0000 This seems like the most reasonable suggestion I've seen so far, it should be fairly straightforward when we get to the parser instead of the preprocessor. / Lars Segerlund. Zack Weinberg wrote: > Steven Bosscher writes: > > >>> Perhaps we would transform >>>#pragma foo bar baz >>>into >>>__builtin_pragma foo bar baz; >>>and feed that to phase 7. >> >>With the GOMP project we still haven't found out how to lex/parse OMP >>directives. That bothers me a bit so I've been giving this a lot of >>thought lately, but I still don't see how it can be done without major >>changes. We need to figure this out before we can hack the front ends. >>I was hoping maybe you can give me some help here because you probably >>have the best idea of what exactly you mean with "phase 7" and you know >>cpplib best :-) > > ... > >>After re-reading that mail from you to gcc@, I think you had something >>else in mind: Not builtin _functions_, but rather some kind of token >>__builtin_pragma, and a regular stream of tokens following that. If I >>understand your idea correctly, this means that the parser would be >>(more) responsible for handling pragmas. This would be ideal to us. >> >>However, I and probably most others in the GOMP project, are not exactly >>C/C++ language lawyers. At least I don't have a clue what "phase 7" >>means, and how it is related to recursive descent parsing. > > > "Phase 7" is a term from the C standard. The short version is that it > refers to the parsing phase of translation (and everything after that). > > You've correctly understood my suggestion. I had in mind that cpplib > would, upon encountering a #pragma, first check whether it was a > #pragma that affects preprocessor behavior. If not, it would inject > the token __builtin_pragma into its output stream, then pass all the > tokens following the #pragma on unchanged, and finally inject a ; > token at the end of the directive line. > > The C parser would then interpret __builtin_pragma as a _keyword_, and > expect a stream of tokens following - with whatever syntax and > semantics are necessary - until it reached the trailing semicolon, at > which point it would go back to the normal grammar. > > C99's _Pragma() would get the same treatment, except that its argument > would be unstringified first. > > The only thing this has to do with recursive descent parsing is that > this suggestion would be a major major PITA to implement with the > current yacc-based C parser. So I would suggest that the GOMP project > help out with the existing plans to reimplement the C parser in > recursive descent style. Neil is, or was, working on this; you should > talk to him. > > zw > > > _______________________________________________ > Gomp-discuss mailing list > Gomp-discuss@nongnu.org > http://mail.nongnu.org/mailman/listinfo/gomp-discuss > From MAILER-DAEMON Wed Jul 09 11:14:50 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19aGMS-0008Vw-1f for mharc-gomp-discuss@gnu.org; Wed, 09 Jul 2003 10:56:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19aGIj-0007np-AX for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 10:52:09 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19aGFi-000761-7V for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 10:49:33 -0400 Received: from gnuftp.gnu.org ([199.232.41.6]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19aFcN-0000iy-8f for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 10:08:23 -0400 Received: from lvs00-fl.valueweb.net ([216.219.253.199] helo=ams003.ftl.affinity.com) by gnuftp.gnu.org with esmtp (Exim 4.20) id 19aFOL-0002xO-4r for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 09:53:53 -0400 Received: from coyotegulch.com ([68.200.44.160]) by ams.ftl.affinity.com with ESMTP id <216892-20734>; Wed, 9 Jul 2003 09:52:47 -0400 Message-ID: <3F0C1E2C.4090000@coyotegulch.com> Date: Wed, 09 Jul 2003 09:52:44 -0400 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: en MIME-Version: 1.0 To: gomp-discuss@nongnu.org Subject: Re: [Gomp-discuss] Re: Lexing and parsing OMP directives, again References: <1057693070.3657.151.camel@steven.lr-s.tudelft.nl> <871xx03gt9.fsf@egil.codesourcery.com> In-Reply-To: <871xx03gt9.fsf@egil.codesourcery.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1.2 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 14:55:58 -0000 Zack Weinberg wrote: > You've correctly understood my suggestion. I had in mind that cpplib > would, upon encountering a #pragma, first check whether it was a > #pragma that affects preprocessor behavior. If not, it would inject > the token __builtin_pragma into its output stream, then pass all the > tokens following the #pragma on unchanged, and finally inject a ; > token at the end of the directive line. > > The C parser would then interpret __builtin_pragma as a _keyword_, and > expect a stream of tokens following - with whatever syntax and > semantics are necessary - until it reached the trailing semicolon, at > which point it would go back to the normal grammar. As I understand it, what you're suggesting is that cpplib would translate OpenMP pragmas into internally-defined language extensions handled by later stages of the compile. > C99's _Pragma() would get the same treatment, except that its argument > would be unstringified first. So it sounds like any work required to implement OpenMP will also be applicable implementing C99. Nice and synergistic. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) From MAILER-DAEMON Wed Jul 09 16:17:58 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19aLO1-0005hy-MP for mharc-gomp-discuss@gnu.org; Wed, 09 Jul 2003 16:17:57 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19aLNz-0005gk-6q for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 16:17:55 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19aLNw-0005fe-Nc for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 16:17:53 -0400 Received: from mailhost1.tudelft.nl ([130.161.180.15]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19aLNw-0005f9-5D for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 16:17:52 -0400 Received: from CONVERSION-DAEMON.mailhost1.tudelft.nl by mailhost1.tudelft.nl (PMDF V6.1-1 #40924) id <0HHR00L01XPPLL@mailhost1.tudelft.nl> for gomp-discuss@nongnu.org; Wed, 09 Jul 2003 22:17:50 +0200 (MEST) Received: from lr0nt3.lr.tudelft.nl (lr0nt3.lr.tudelft.nl [130.161.166.23]) by mailhost1.tudelft.nl (PMDF V6.1-1 #40924) with ESMTP id <0HHR00CNBXPP7M@mailhost1.tudelft.nl>; Wed, 09 Jul 2003 22:17:49 +0200 (MEST) Received: by lr0nt3.lr.tudelft.nl with Internet Mail Service (5.5.2656.59) id ; Wed, 09 Jul 2003 22:16:44 +0200 Content-return: allowed Date: Wed, 09 Jul 2003 22:16:43 +0200 From: "S. Bosscher" Subject: RE: [Gomp-discuss] Re: Lexing and parsing OMP directives, again To: "'zack@codesourcery.com'" , 'Scott Robert Ladd ' , "'gomp-discuss@nongnu.org '" Message-id: <4195D82C2DB1D211B9910008C7C9B06F01F3736B@lr0nt3.lr.tudelft.nl> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-type: text/plain; charset=iso-8859-1 Cc: X-BeenThere: gomp-discuss@nongnu.org X-Mailman-Version: 2.1.2 Precedence: list Reply-To: gomp-discuss@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 20:17:56 -0000 [ CC: Zack next time, he is not on this list I think... ] Zack Weinberg wrote: > > You've correctly understood my suggestion. I had in mind that cpplib > > would, upon encountering a #pragma, first check whether it was a > > #pragma that affects preprocessor behavior. If not, it would inject > > the token __builtin_pragma into its output stream, then pass all the > > tokens following the #pragma on unchanged, and finally inject a ; > > token at the end of the directive line. > > > > The C parser would then interpret __builtin_pragma as a _keyword_, > and > > expect a stream of tokens following - with whatever syntax and > > semantics are necessary - until it reached the trailing semicolon, at > > which point it would go back to the normal grammar. > > As I understand it, what you're suggesting is that cpplib would > translate OpenMP pragmas into internally-defined language extensions > handled by later stages of the compile. All pragma, actually. > > C99's _Pragma() would get the same treatment, except that its argument > > would be unstringified first. > > So it sounds like any work required to implement OpenMP will also be > applicable implementing C99. Nice and synergistic. Actually, _Pragma() has to be unstringified now too, so no changes here, right? Anyway, I mailed Neil about his C recursive-descent parser, and it is more or less on hold while he's doing options handling and cpplib work. That is a real shame :-( Zack, is there any way to still pass pragmas as a stream of tokens, but intercept them in c_lex for the YACC parsers so they doesn't have to deal with them? I think that the existing supported pragmas are simple enough that a pragma handler could be called from c_lex. That way, we could feed pragmas as tokens to the C++ parser (is that called phase 7 for C++ too?) while hiding them for the C/ObjC parsers. (Or does java use cpplib too???) Gr. Steven