Re: libffi maintenance within GCC?

[Andrew Haley]

On 28/10/16 04:03, Ian Lance Taylor wrote:
> On Thu, Oct 27, 2016 at 6:08 AM, Anthony Green  wrote:
>> Is it still important that libffi be included in the GCC tree?
> 
> [ Replying again as last message was bounced as HTML--sorry for the
> duplication.]
> 
> libffi is used by libgo, for much the same reason as it was used by
> libjava, so it needs to come from somewhere.

It has been very convenient for GCC port maintainers to be able to
commit their patches to the GCC tree.

Andrew.

Questions about pedantic_non_lvalue_loc and related code

[Bin.Cheng]

Hi,
I am trying to move simplifications in fold_cond_expr_with_comparison
to match.pd and had below questions about pedantic_non_lvalue_loc.

Last change for the function is:

commit 565353e8cf24046c034ecaf04dcb69ea8319a57c
Author: rguenth 
Date:   Tue Nov 11 15:21:12 2014 +

2014-11-11  Richard Biener  

* tree-core.h (pedantic_lvalues): Remove.
* fold-const.c (pedantic_lvalues): Likewise.
(pedantic_non_lvalue_loc): Remove conditional non_lvalue_loc call.

c/
* c-decl.c (c_init_decl_processing): Do not set pedantic_lvalues
to true.

It removes call to non_lvalue_loc in pedantic_non_lvalue_loc.  IIUC,
pedantic_lvalues was introduced because of Generic Lvalue extension
originally, and it is set to true after that feature was removed long
ago.  So before the aforementioned commit, pedantic_non_lvalue_loc is
like:
 static tree
 pedantic_non_lvalue_loc (location_t loc, tree x)
 {
   if (pedantic_lvalues)
 return non_lvalue_loc (loc, x);

   return protected_set_expr_location_unshare (x, loc);
 }

The net effect of this function is actually always returning what
non_lvalue_loc returns, it should be changed into below?
 static tree
 pedantic_non_lvalue_loc (location_t loc, tree x)
 {
   return non_lvalue_loc (loc, x);
 }
Given the change is made in 2014 and not causing any issue after it, I
can only assuming two possible reasons:
A) expressions passed to pedantic_non_lvalue_loc will never be lvalue,
thus no need to wrap it with NON_LVALUE by calling non_lvalue_loc.
B) expressions passed to pedantic_non_lvalue_loc could be lvalue, and
the lvalue is kept by not calling non_lvalue_loc as it is now.

Question 1) is, which one of above is correct?  After going through
all calls to pedantic_non_lvalue_loc, I tend to agree A) is correct.
Most calls in fold_cond_expr_with_comparison are lvalue-safe, and the
only exception is now also guarded by fix from PR19199.

Well, there are two calls outside of fold_cond_expr_with_comparison
which I am not sure: The one in fold_binary_loc for COMPOUND_EXPR, the
other one in fold_tenary_loc for COND_EXPR, the two calls are both
(somehow) guarded by !TREE_SIDE_EFFECTS, for example:
case COMPOUND_EXPR:
  /* When pedantic, a compound expression can be neither an lvalue
 nor an integer constant expression.  */
  if (TREE_SIDE_EFFECTS (arg0) || TREE_CONSTANT (arg1))
return NULL_TREE;
  /* Don't let (0, 0) be null pointer constant.  */
  tem = integer_zerop (arg1) ? build1 (NOP_EXPR, type, arg1)
 : fold_convert_loc (loc, type, arg1);
  return pedantic_non_lvalue_loc (loc, tem);

The comment leads me to
Question 2) Does this mean a lvalue expression must have side_effects_flag set?
If answer is yes, then question 1.A) will hold.

Get back to current implementation of pedantic_non_lvalue_loc:
static tree
pedantic_non_lvalue_loc (location_t loc, tree x)
{
  return protected_set_expr_location_unshare (x, loc);
}

Function protected_set_expr_location_unshare was introduced by
PR45700.  It I read it correctly, the change is to, when necessarily,
set different loc information only after copying the original
expression.  Again if Question 2) is a yes, pedantic_non_lvalue_loc
can be cleaned up, based on the code before 2014's change.  Even
Question 2) is not always yes, calls to pedantic_non_lvalue_loc in
fold_cond_expr_with_comparison are all dead because it's for sure the
expression can't be lvalue.

So any explanation?  Thanks very much in advance.

Thanks,
bin

[PATCH][0/2] GIMPLE Frontend

[Richard Biener]

I've posted two patches implementing a GIMPLE Frontend to the extent
required for simple unit testing of GIMPLE passes.  The work was
mostly done by Prasad Ghangal during this years GSoC project.  I've
picked it up to ensure it would be ready for the end of stage1
even though the frontend itself can IMHO be developed throughout
stage3 where required.

https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02336.html
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02335.html

The current status is that simple C testcases can be compiled
and dumped at some random pass with -gimple and that dump
output can be fed back into the GIMPLE frontend (by adding -fgimple
to the C compiler invocation).

Most syntax and semantic checking is only done by the GIMPLE
verification code we have in the middle-end as the parser is
modeled after the C one which usually accepts more complex input
as allowed by GIMPLE.

I expect there is syntax we still do not parse (MEM_REF comes to
my mind) plus on-the-side info that we either do not have a good
source representation for or that the parser does not yet parse
(generally EH info or things like range info or points-to info).

Currently what the parser emits is a mixed bag of low and high
gimple (it's technically high gimple as it still has the outer
gimple BIND).  It parses SSA form with PHIs being represented
as a function call to __PHI with pairs of label (comes-from)
and value.

A feature of the frontend is that it allows (or rather requires
for all declarations) mixing C with GIMPLE.  This means you
can write a single function in GIMPLE and surround it with
a (unit-)test harness written in C.

I hope we can get this into GCC 7, kind of as a preview as I expect
it will evolve once we get the first unit tests (I didn't try to
re-write existing tests).

Thanks,
Richard.