This patch reworks pragma parsing in c-pragma.cc, with the
following improvements:
- it replaces the GCC_BAD* macros (that contained "return") in favor
of helper classes and functions for emitting diagnostics, making control
flow more explicit
- the -Wpragmas diagnostics are reworde
On Wed, 10 Feb 2021, Jakub Jelinek wrote:
> On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> > The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> > but doesn't free the array. The following fixes that.
> >
> > Bootstrapped and tested on x86_64-unknown-
On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> but doesn't free the array. The following fixes that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2021-02-1
The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
but doesn't free the array. The following fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-02-10 Richard Biener
gcc/c-family/
* c-common.c (parse_optimize_options):
nd-root.php?message_id=%3C20141218142942.GM1667%40tucnak.redhat.com%3E>,
> but I'm not sure about this: aren't these code paths only exercised for
> pragma parsing, and aren't there really only ever one handful (or, a few)
> of pragmas per source code file, so this could ha
On Tue, Apr 28, 2015 at 06:59:12PM +0200, Thomas Schwinge wrote:
> We're getting ready to submit patches extending the C/C++ front ends for
> the remaining OpenACC clauses, and given the current layout of
> gcc/c-family/c-pragma.h:pragma_omp_clause, we're then at 69 unique
> clauses, which is more
l (see below), or something else?
Regarding std::bitset, you've been worried about performance,
<http://news.gmane.org/find-root.php?message_id=%3C20141218142942.GM1667%40tucnak.redhat.com%3E>,
but I'm not sure about this: aren't these code paths only exercised for
pragma pa
On Fri, Dec 19, 2014 at 01:20:52PM +0100, Thomas Schwinge wrote:
> Hi Jakub!
>
> On Fri, 19 Dec 2014 11:36:39 +0100, Jakub Jelinek wrote:
> > On Thu, Dec 18, 2014 at 07:00:09PM +0100, Thomas Schwinge wrote:
> > > > The point is that we now have lots of clauses, and making it clear what
> > > > f
Hi Jakub!
On Fri, 19 Dec 2014 11:36:39 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 07:00:09PM +0100, Thomas Schwinge wrote:
> > > The point is that we now have lots of clauses, and making it clear what
> > > from
> > > those clauses are Cilk+, what are OpenACC, what are OpenMP will hel
On Thu, Dec 18, 2014 at 07:00:09PM +0100, Thomas Schwinge wrote:
> > The point is that we now have lots of clauses, and making it clear what from
> > those clauses are Cilk+, what are OpenACC, what are OpenMP will help with
> > code readability.
So here is what I'd like to see with PRAGMA_O*_CLAUS
On Thu, Dec 18, 2014 at 07:00:09PM +0100, Thomas Schwinge wrote:
> OK, so there is this limit. But, I fail to understand how merely moving
> the OpenACC-only PRAGMA_*_CLAUSE_* to the end of enum pragma_omp_clause
> will help overcome that? Or have I now completely confused myself, and
> I'm not e
Hi Jakub!
On Thu, 18 Dec 2014 15:29:42 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 02:48:32PM +0100, Thomas Schwinge wrote:
> > > Like for CILK, I'd strongly prefer if for the clauses that are
> > > specific to OpenACC only you'd use PRAGMA_OACC_CLAUSE_* instead,
> > > and put them afte
On Thu, Dec 18, 2014 at 02:48:32PM +0100, Thomas Schwinge wrote:
> > Like for CILK, I'd strongly prefer if for the clauses that are
> > specific to OpenACC only you'd use PRAGMA_OACC_CLAUSE_* instead,
> > and put them after the PRAGMA_CILK_* enum values.
> > If you want to have PRAGMA_OACC_CLAUSE_
Hi!
On Thu, 13 Nov 2014 14:02:37 +0100, Jakub Jelinek wrote:
> > void
> > init_pragma (void)
> > {
> > + if (flag_openacc)
> > +{
> > + const int n_oacc_pragmas
> > + = sizeof (oacc_pragmas) / sizeof (*oacc_pragmas);
> > + int i;
> > +
> > + for (i = 0; i < n_oacc_pragmas
14 matches
Mail list logo