On 06/23/2016 08:45 AM, Alexander Monakov wrote:
Hi,
I've discovered that this assert in my patch was too restrictive:
+ if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+ {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+
On 07/14/2016 12:33 PM, Alexander Monakov wrote:
On Thu, 14 Jul 2016, Jeff Law wrote:
Is the point here to be able to deduce what symbols are external & undefined
and emit some kind of directive to the assembler in that case?
Yes, PTX assembly requires that properly typed declarations are emit
On Thu, 14 Jul 2016, Jeff Law wrote:
> Is the point here to be able to deduce what symbols are external & undefined
> and emit some kind of directive to the assembler in that case?
Yes, PTX assembly requires that properly typed declarations are emitted for
external references. Today, the NVPTX ba
On 06/23/2016 08:45 AM, Alexander Monakov wrote:
Hi,
I've discovered that this assert in my patch was too restrictive:
+ if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+ {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+
On Fri, 1 Jul 2016, Alexander Monakov wrote:
> On Thu, 23 Jun 2016, Alexander Monakov wrote:
> > Hi,
> >
> > I've discovered that this assert in my patch was too restrictive:
> >
> > + if (DECL_HAS_VALUE_EXPR_P (pv->decl))
> > + {
> > + gcc_checking_assert (lookup_attribute ("omp decla
On Thu, 23 Jun 2016, Alexander Monakov wrote:
> Hi,
>
> I've discovered that this assert in my patch was too restrictive:
>
> + if (DECL_HAS_VALUE_EXPR_P (pv->decl))
> + {
> + gcc_checking_assert (lookup_attribute ("omp declare target link",
> +
Hi,
I've discovered that this assert in my patch was too restrictive:
+ if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+ {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+DECL_ATTRIBUTES (pv->decl)));
Testing for the
> On Thu, 16 Jun 2016, Jan Hubicka wrote:
> > I see, order is created at a time variable is added to symbol table (not at
> > time when definition is given). So we should have order everywhere.
> > Patch is OK
>
> Thanks! If you don't mind a quick followup question: now that both
> FOR_EACH_VARI
On Thu, 16 Jun 2016, Jan Hubicka wrote:
> I see, order is created at a time variable is added to symbol table (not at
> time when definition is given). So we should have order everywhere.
> Patch is OK
Thanks! If you don't mind a quick followup question: now that both
FOR_EACH_VARIABLE loops in
> On Thu, 16 Jun 2016, Jan Hubicka wrote:
> > > On Thu, 9 Jun 2016, Alexander Monakov wrote:
> > + FOR_EACH_VARIABLE (pv)
> [snip]
> > + i = pv->order;
> > + gcc_assert (nodes[i].kind == ORDER_UNDEFINED);
> > + nodes[i].kind = pv->definition ? ORDER_VAR : ORDER_VAR_UNDEF;
> > +
On Thu, 16 Jun 2016, Jan Hubicka wrote:
> > On Thu, 9 Jun 2016, Alexander Monakov wrote:
> + FOR_EACH_VARIABLE (pv)
[snip]
> + i = pv->order;
> + gcc_assert (nodes[i].kind == ORDER_UNDEFINED);
> + nodes[i].kind = pv->definition ? ORDER_VAR : ORDER_VAR_UNDEF;
> + nodes[i].u.v =
> On Thu, 9 Jun 2016, Alexander Monakov wrote:
>
> > Hi,
> >
> > This patch teaches cgraphunit.c:output_in_order to output undefined external
> > variables via assemble_undefined_decl. At the moment that is only done for
> > -ftoplevel-reorder in varpool.c:symbol_table::output_variables. This p
On Thu, 9 Jun 2016, Alexander Monakov wrote:
> Hi,
>
> This patch teaches cgraphunit.c:output_in_order to output undefined external
> variables via assemble_undefined_decl. At the moment that is only done for
> -ftoplevel-reorder in varpool.c:symbol_table::output_variables. This patch
> makes b
13 matches
Mail list logo
