Re: Hurd port for GCC Go (was: [PATCH] gccgo patch 0-2 (9))

[Svante Signell]

Hi Thomas,

On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell  
> wrote:
> > Attached are patches to enable gccgo to build properly on Debian
> > GNU/Hurd on gcc-4.7 (4.7.3-4).
> 
> Thanks!  I've begun integrating them into my GCC tree (based on upstream
> GCC trunk, so some changes to be done to your patches), and get it in a
> state for Fotis to base his GSoC work on.

Where to find your GCC tree? Also I had problems to tracing this commit:
.
I did not find anything related to context_functions at
http://git.savannah.gnu.org/cgit/hurd/glibc.git/

Furthermore, for testing purposes, is it straight-forward to add the new
functions getcontext/setcontext/makecontext*/movecontext to the debian
sources, e.g. 2.13-39+hurd.3 or 2.17-6 (when that is released?). Where
should these be placed in the tree: hurd/, sysdeps/mach/hurd/,
elsewhere? And how to avoid the stubs at stdlib/ being compiled in?

MELT 0.9.9 rc3 plugin release candidate for GCC 4.6, 4.7, 4.8

[Basile Starynkevitch]

Dear All

It is my pleasure to annnounce the MELT plugin 0.9.9 rc3 release candidate 3 
(for GCC 4.6, 4.7, 4.8).

This is a significant release of the MELT plugin (and the last able to work as 
plugin to GCC 4.6)

References http://gcc.gnu.org/ml/gcc/2013-06/msg00018.html & 
http://gcc.gnu.org/ml/gcc/2013-06/msg1.html

You can download the gnuzipped source tarball from
  http://gcc-melt.org/melt-0.9.9-rc3-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
a gzipped source tarball of 5717948 bytes of md5sum 
51ec9c5fcf4da993b72d66999041dd41 
extracted from MELT branch svn rev. 200015 on june 12th 2012. 

Many bug fixes (and internal improvements) from 0.9.9 rc2.

0.9.9 rc3 is probably the last release candidate and very close to 0.9.9 
release.

So please test it and report bugs quickly


NEWS for 0.9.9 MELT plugin for GCC 4.6 & 4.7 & 4.8
[[june, XX, 2013]]

This is a significant release. A lot of new features are
appearing. Much more ability to mix arbitrary C/C++ & MELT code in any
way and both directions!

This is the last MELT release supporting GCC 4.6 and GCC compilers in
C only. Future MELT releases with will be C++ only (i.e. emit C++
code), for GCC 4.7 & 4.8

   Language improvements
   =

   ***
   * Code chunks can contain void side-effecting expressions of :VOID
 ctype, translated to some C/C++ block. Hence code chunks can even
 be indirectly nested. Within the macro-string, write $(...) for
 the expression. You may want to make it a PROGN ending with
 (VOID) to force it to be void.  Sub-expressions -of :VOID ctype-
 inside code chunks are evaluated at the place of appearance, and
 are expanded to C/C++ blocks at their occurrence.


   ***
   * Expression chunks are expanded into C/C++ expressions. Syntax is

(EXPR_CHUNK...)

   For instance, to get the pid of the cc1 running your MELT extension, use
  (expr_chunk getpid_chk :long #{/*$GETPID_CHK*/ (long)getpid()}#)

   Important notice: any sub-expression appearing in some EXPR_CHUNK
   is evaluated before, like for primitives, so will always be
   evaluated.


   ***
   * Ability to emit some C code in the implementation part. Syntax
 (CIMPLEMENT )

   This is a companion to the existing CHEADER. Useful to declare some
   specific non-inlined C++ function or static variable with CHEADER
   and to define it with CIMPLEMENT.



   ***
   * New ability to add module "static" value variables in MELT
   
(DEFVAR )
   
   The so defined variable  is (in the generated C/C++ code)
   a pointer [to some MELT value] inside a static array. Garbage
   collection support is generated.  The variable  cannot be
   exported with EXPORT_VALUES, you need to export functions accessing
   or changing it.  Once defined, you can use SETQ to assign to such a
   module variable (and also DEFHOOK with :VAR)


   ***
   * New ability to define hooks, that is C/C++ functions coded in
 MELT. Syntax is 

(DEFHOOK 
 [:var ] )
 
The optional  given with a :var annotation should be 
a module variable previously defined with DEFVAR. 
For example, with the following code

(defvar varlist)
(setq varlist (list))
(defvar varhook)
(defhook appendnumhk (:long n) (:long outlen) :void 
 :var varhook
(list_append varlist (constant_box n))
(setq outlen (list_length varlist)))

you get two generated extern "C" functions in the emitted C/C++ code
void melthook_APPENDNUMHK (melt_ptr_t hook, long n, long* outlen);
and
void melthookproc_APPENDNUMHK (long n, long* outlen);

which you could use e.g. in some other code_chunk-s. The first
function melthook_APPENDNUMHK needs the hook value `appendnumhk' as
its first argument; the second function melthookproc_APPENDNUMHK
is generated because a :var annotation has been given, and uses
the hook value automagically stored in that `varhook' module
variable.

Many functions previously coded in C/C++ inside the melt-runtime.c
have been migrated to predefined hooks coded in MELT inside
melt/warmelt-hooks.melt etc...

Hooks are a very important addition: with them you can mix C/C++ & MELT 
code 
at will.


   ***
   * New ability to call hooks,

   Expresssions can also call known hooks given by their operator. But
   the hook cannot be unknown: only applications can be done with
   statically unknown operators.


   ***
   * EVAL function

   An EVAL function has been added, it wraps the existing
   TRANSLATE_RUN_MELT_EXPRESSIONS utility function so works by
   generating C/C++ code then loading and running it.


   Runtime improvements
   

   *** 
   * To register your MELT pass, use the INSTALL_MELT_PASS_IN_GCC
   function instead of the obsolete INSTALL_MELT_GCC_PASS
   primitive. Notice that INSTALL_MELT_P

Can our C++ vectors hold derived classes?

[Martin Jambor]

Hi everyone, but especially Diego :-)

it seems to me that our new C++ vectors have some problems holding
derived classes.  For example, when try to compile the following

  struct zzzA
  {
int kind;
  };
  
  struct zzzB : public zzzA
  {
int some, data, here;
  };
  
  struct container
  {
vec  my_vec;
  };
  static struct container my_cnt;
  
  /* and then somewhere later do */
  my_cnt.my_vec.create (8);

I get the following warnings:

In file included from /home/mjambor/gcc/small/src/gcc/tree.h:27:0,
 from /home/mjambor/gcc/small/src/gcc/ipa-cp.c:106:
/home/mjambor/gcc/small/src/gcc/vec.h: In instantiation of ‘static size_t 
vec::embedded_size(unsigned int) [with T = zzzB; A = va_heap; 
size_t = long unsigned int]’:
/home/mjambor/gcc/small/src/gcc/vec.h:298:64:   required from ‘static void 
va_heap::reserve(vec*&, unsigned int, bool) [with T = 
zzzB]’
/home/mjambor/gcc/small/src/gcc/vec.h:1468:5:   required from ‘bool vec::reserve(unsigned int, bool) [with T = zzzB; A = va_heap]’
/home/mjambor/gcc/small/src/gcc/vec.h:1482:45:   required from ‘bool vec::reserve_exact(unsigned int) [with T = zzzB; A = va_heap]’
/home/mjambor/gcc/small/src/gcc/vec.h:1497:5:   required from ‘void vec::create(unsigned int) [with T = zzzB; A = va_heap]’
/home/mjambor/gcc/small/src/gcc/ipa-cp.c:3608:26:   required from here
/home/mjambor/gcc/small/src/gcc/vec.h:1091:63: warning: invalid access to 
non-static data member ‘vec::vecdata_’  of NULL object 
[-Winvalid-offsetof]
/home/mjambor/gcc/small/src/gcc/vec.h:1091:63: warning: (perhaps the ‘offsetof’ 
macro was used incorrectly) [-Winvalid-offsetof]
rm -rf libbackend.a

Note that in the warning messages, the template parameters of vec
change from (IMHO correct) vec to (IMHO wrong)
vec.  

When I remove the ": public zzzA" part the earnings disappear.  Thus,
it seems there is an error somewhere... or am I doing something wrong?

Thanks,

Martin

Re: [lambda] First stage remake of old lambda patches

[Adam Butcher]

Hi Jason,

I did find some code in the end but it wasn't much use due to the
changes in gcc/cp since the old lambda branch from which the original
patch was based.

I've since been finding 10 minutes here and there to have a hack about
and have finally got the first stage of generic lambda support
functional against GCC's trunk.

It currently only supports the explicit template-style syntax of the
second (non approved) paper (and my original patch) but I believe this
is good place to start even if it is considered a GNU extension for
now.  I will try to reapply the 'auto' syntax patch at some point but
that is syntactic rather than a behavioral.

I want to fix up the stateless lambda ptr-to-fn conversion-op stuff
next which, I think, is currently the biggest wheel off mechanically.

I've no idea how well this will deal with parameter packs or more
exotic use cases than the simple test program below but I'd welcome
any feedback at this stage.

I do feel like I've gone backward with this but I think it's worth
getting the mechanical side working right with the latest GCC before
integrating the 'auto' parameter patch.

Cheers,
Adam

## begin test program ##

// to check generated asm
//
volatile int E = 1;
volatile int F = 2;
volatile int G = 3;
volatile int H = 4;

// instantiation generates a -Wwrite-strings warning showing the type
// bindings for T and U (currently not displayed in generic lambda
// diagnostics) as part of the synthesized constructor.
//
template 
struct diagnostic { char* x = ""; };

int main()
{
  int i = 1;

  // e: monomorphic stateless lambda
  // f: monomorphic closure
  // g: polymorphic stateless lambda
  // (Note: explicit return type specified to avoid current
  //conversion-op bug)
  // h: polymorphic closure
  //
  auto e = []  (char a, char b) { return E + a + b; };
  auto f = [i] (char a, char b) { return F + i + a + b; };
  auto g = []   (T a, U b) -> double { 
diagnostic(); return G + a + b; };
  auto h = [i]  (T a, U b) { diagnostic(); return 
H + i + a + b; };

  // SEGV currently: conversion-op not implemented correctly yet:
  //   int (*p) (char, float) = g;
  //   int (*q) (int, double) = g;
  
  return g (1.0, 2) + h (2.f, '\003');
}

## end test program ##

[PATCH] Remake initial changes from old lambda branch to support explicit lambda template support and fixup against mainline gcc/cp changes.

[Adam Butcher]

This only supports the explicit template parameter syntax and does not
correctly support conversion to static ptr-to-function for generic
stateless lambdas.
---
 gcc/cp/mangle.c|  2 ++
 gcc/cp/parser.c| 43 +--
 gcc/cp/semantics.c | 24 
 3 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 8da62b5..4d4c0fd 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -1438,6 +1438,8 @@ write_closure_type_name (const tree type)
   MANGLE_TRACE_TREE ("closure-type-name", type);
 
   write_string ("Ul");
+  if (TREE_CODE (fn) == TEMPLATE_DECL) // XXX: should we bother mangling 
generic lambdas?
+fn = DECL_TEMPLATE_RESULT (fn);
   write_method_parms (parms, /*method_p=*/1, fn);
   write_char ('E');
   write_compact_number (LAMBDA_EXPR_DISCRIMINATOR (lambda));
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 319da21..407dca3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8668,6 +8668,7 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
 /* Parse the (optional) middle of a lambda expression.
 
lambda-declarator:
+ < template-parameter-list [opt] >
  ( parameter-declaration-clause [opt] )
attribute-specifier [opt]
mutable [opt]
@@ -8687,10 +8688,26 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, 
tree lambda_expr)
   tree param_list = void_list_node;
   tree attributes = NULL_TREE;
   tree exception_spec = NULL_TREE;
+  tree template_param_list = NULL_TREE;
   tree t;
 
-  /* The lambda-declarator is optional, but must begin with an opening
- parenthesis if present.  */
+  /* The template-parameter-list is optional, but must begin with
+ an opening angle if present.  */
+  if (cp_lexer_next_token_is (parser->lexer, CPP_LESS))
+{
+  cp_lexer_consume_token (parser->lexer);
+
+  template_param_list = cp_parser_template_parameter_list (parser);
+
+  cp_parser_skip_to_end_of_template_parameter_list (parser);
+
+  /* We just processed one more parameter list.  */
+  ++parser->num_template_parameter_lists;
+}
+
+  /* The parameter-declaration-clause is optional (unless
+ template-parameter-list was given), but must begin with an
+ opening parenthesis if present.  */
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_PAREN))
 {
   cp_lexer_consume_token (parser->lexer);
@@ -8736,6 +8753,8 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, tree 
lambda_expr)
 
   leave_scope ();
 }
+  else if (template_param_list != NULL_TREE) // generate diagnostic
+cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN);
 
   /* Create the function call operator.
 
@@ -8779,6 +8798,23 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, tree 
lambda_expr)
DECL_ARTIFICIAL (fco) = 1;
/* Give the object parameter a different name.  */
DECL_NAME (DECL_ARGUMENTS (fco)) = get_identifier ("__closure");
+   if (template_param_list != NULL_TREE)
+ {
+   tree saved_current_function_decl = current_function_decl;
+
+   /* Clear current function decl to allow check_member_template
+  to pass.  Currently it rejects templates inside functions.
+  Couldn't figure out a clean way to test for lambda inside
+  check_member_template.  */
+   current_function_decl = NULL_TREE;
+   fco = finish_member_template_decl (fco);
+   current_function_decl = saved_current_function_decl;
+
+   --parser->num_template_parameter_lists;
+
+   finish_template_decl (template_param_list);
+
+ }
   }
 
 finish_member_declaration (fco);
@@ -8822,6 +8858,9 @@ cp_parser_lambda_body (cp_parser* parser, tree 
lambda_expr)
 tree compound_stmt;
 tree cap;
 
+if (TREE_CODE (fco) == TEMPLATE_DECL)
+  fco = DECL_TEMPLATE_RESULT (fco);
+
 /* Let the front end know that we are going to be defining this
function.  */
 start_preparsed_function (fco,
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index b5c3b0a..db5ba7b 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9135,7 +9135,7 @@ lambda_function (tree lambda)
  /*protect=*/0, /*want_type=*/false,
  tf_warning_or_error);
   if (lambda)
-lambda = BASELINK_FUNCTIONS (lambda);
+lambda = OVL_CURRENT (BASELINK_FUNCTIONS (lambda));
   return lambda;
 }
 
@@ -9381,6 +9381,8 @@ build_capture_proxy (tree member)
 
   closure = DECL_CONTEXT (member);
   fn = lambda_function (closure);
+  if (TREE_CODE (fn) == TEMPLATE_DECL)
+fn = DECL_TEMPLATE_RESULT (fn);
   lam = CLASSTYPE_LAMBDA_EXPR (closure);
 
   /* The proxy variable forwards to the capture field.  */
@@ -9795,7 +9797,8 @@ maybe_add_lambda_conv_op (tree type)
   if (processing_template_decl)
 return;
 
-  if (DECL_INITIAL (callop) == NULL_TREE)
+  if (TREE_CODE (callop) != TEMPLATE

Re: Can our C++ vectors hold derived classes?

[Andrew Pinski]

On Wed, Jun 12, 2013 at 10:23 AM, Martin Jambor  wrote:
> Hi everyone, but especially Diego :-)
>
> it seems to me that our new C++ vectors have some problems holding
> derived classes.  For example, when try to compile the following

I think the answer is simple.  vec supports POD only, once you have
inherents, it becomes non-POD in C++98.

Thanks,
Andrew Pinski

>
>   struct zzzA
>   {
> int kind;
>   };
>
>   struct zzzB : public zzzA
>   {
> int some, data, here;
>   };
>
>   struct container
>   {
> vec  my_vec;
>   };
>   static struct container my_cnt;
>
>   /* and then somewhere later do */
>   my_cnt.my_vec.create (8);
>
> I get the following warnings:
>
> In file included from /home/mjambor/gcc/small/src/gcc/tree.h:27:0,
>  from /home/mjambor/gcc/small/src/gcc/ipa-cp.c:106:
> /home/mjambor/gcc/small/src/gcc/vec.h: In instantiation of ‘static size_t 
> vec::embedded_size(unsigned int) [with T = zzzB; A = va_heap; 
> size_t = long unsigned int]’:
> /home/mjambor/gcc/small/src/gcc/vec.h:298:64:   required from ‘static void 
> va_heap::reserve(vec*&, unsigned int, bool) [with T = 
> zzzB]’
> /home/mjambor/gcc/small/src/gcc/vec.h:1468:5:   required from ‘bool vec vl_ptr>::reserve(unsigned int, bool) [with T = zzzB; A = va_heap]’
> /home/mjambor/gcc/small/src/gcc/vec.h:1482:45:   required from ‘bool vec A, vl_ptr>::reserve_exact(unsigned int) [with T = zzzB; A = va_heap]’
> /home/mjambor/gcc/small/src/gcc/vec.h:1497:5:   required from ‘void vec vl_ptr>::create(unsigned int) [with T = zzzB; A = va_heap]’
> /home/mjambor/gcc/small/src/gcc/ipa-cp.c:3608:26:   required from here
> /home/mjambor/gcc/small/src/gcc/vec.h:1091:63: warning: invalid access to 
> non-static data member ‘vec::vecdata_’  of NULL 
> object [-Winvalid-offsetof]
> /home/mjambor/gcc/small/src/gcc/vec.h:1091:63: warning: (perhaps the 
> ‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
> rm -rf libbackend.a
>
> Note that in the warning messages, the template parameters of vec
> change from (IMHO correct) vec to (IMHO wrong)
> vec.
>
> When I remove the ": public zzzA" part the earnings disappear.  Thus,
> it seems there is an error somewhere... or am I doing something wrong?
>
> Thanks,
>
> Martin