Re: [committed] libstdc++: Reformat Python code

2023-11-13 Thread Romain GEISSLER
> Le 13 nov. 2023 à 16:24, Jonathan Wakely  a écrit :
> 
> Yes, I'll do that backport (and most of the other Python improvements
> too, at least for gcc-13).
> 
> Thanks for raising it.
> 

Cool thanks ! ;)

In the meantime, in my own toolchains I have silenced (without fixing it) the 
warnings
with this simple patch (in case anyone else wants to quickly get rid of it, but 
it’s not
really a good long term workaround).

--- libstdc++-v3/python/libstdcxx/v6/__init__.py
+++ libstdc++-v3/python/libstdcxx/v6/__init__.py
@@ -1 +1,2 @@
-
+import warnings
+warnings.filterwarnings("ignore", category=SyntaxWarning)

Re: [committed] libstdc++: Reformat Python code

2023-11-13 Thread Romain GEISSLER
> Le 28 sept. 2023 à 22:21, Jonathan Wakely  a écrit :
> 
> Tested x86_64-linux (GDB 13.2, Python 3.11). Pushed to trunk.
> 
> -- >8 --
> 
> Some of these changes were suggested by autopep8's --aggressive
> option, others are for readability.
> 
> Break long lines by splitting strings across multiple lines, or
> introducing local variables to hold results.
> 
> Use raw strings for regular expressions, so that backslashes don't need
> to be escaped.

Hi Jonathan,

FYI, it seems that with python 3.12, the bits "Use raw strings for regular 
expressions"
seems to fix the following new Python warnings:

/opt/1A/toolchain/x86_64-v23.0.19/lib/../share/gcc-13.2.1/python/libstdcxx/v6/printers.py:1273:
 SyntaxWarning: invalid escape sequence '\d'
  self.typename = re.sub('^std::experimental::fundamentals_v\d::', 
'std::experimental::', self.typename, 1)
/opt/1A/toolchain/x86_64-v23.0.19/lib/../share/gcc-13.2.1/python/libstdcxx/v6/printers.py:1302:
 SyntaxWarning: invalid escape sequence '\w'
  x = re.sub("std::string(?!\w)", s, m.group(1))
 … (snapped, there are a bit more than that in total).

How ok would it be to backport to the branches still maintained the "raw 
string" fix,
in order to avoid deprecation warnings as soon as people use gdb with python >= 
3.12 ?

Thanks,
Romain

[gcc 11 backport] Support ld.mold linker.

2023-08-15 Thread Romain Geissler via Gcc-patches
Hi,

Is it ok to backport small unrisky features to the old gcc 11 branch ?
Here is a proposal to merge the ld.mold linker support which Martin has
pushed in gcc >= 12. It's a cherry-pick of commit
ad964f7eaef9c03ce68a01cfdd7fde9d56524868. Note that it doesn't backport
the gcc build machinery to be able to link gcc itself with mold.

Note: it also doesn't backport Martin's change in the LTO machinery to
support LTO plugin with mold.

Cheers,
Romain


gcc/ChangeLog:

* collect2.c (main): Add ld.mold.
* common.opt: Add -fuse-ld=mold.
* doc/invoke.texi: Document it.
* gcc.c (driver_handle_option): Handle -fuse-ld=mold.
* opts.c (common_handle_option): Likewise.
---
 gcc/collect2.c  | 10 +++---
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi |  4 
 gcc/gcc.c   |  4 
 gcc/opts.c  |  1 +
 5 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index 3e212fc75f3..558016af486 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -785,6 +785,7 @@ main (int argc, char **argv)
   USE_GOLD_LD,
   USE_BFD_LD,
   USE_LLD_LD,
+  USE_MOLD_LD,
   USE_LD_MAX
 } selected_linker = USE_DEFAULT_LD;
   static const char *const ld_suffixes[USE_LD_MAX] =
@@ -793,7 +794,8 @@ main (int argc, char **argv)
   PLUGIN_LD_SUFFIX,
   "ld.gold",
   "ld.bfd",
-  "ld.lld"
+  "ld.lld",
+  "ld.mold"
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -970,6 +972,8 @@ main (int argc, char **argv)
  selected_linker = USE_GOLD_LD;
else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
  selected_linker = USE_LLD_LD;
+   else if (strcmp (argv[i], "-fuse-ld=mold") == 0)
+ selected_linker = USE_MOLD_LD;
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1082,7 +1086,7 @@ main (int argc, char **argv)
   ld_file_name = 0;
 #ifdef DEFAULT_LINKER
   if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  selected_linker == USE_LLD_LD || selected_linker == USE_MOLD_LD)
 {
   char *linker_name;
 # ifdef HOST_EXECUTABLE_SUFFIX
@@ -1317,7 +1321,7 @@ main (int argc, char **argv)
  else if (!use_collect_ld
   && strncmp (arg, "-fuse-ld=", 9) == 0)
{
- /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
+ /* Do not pass -fuse-ld={bfd|gold|lld|mold} to the linker. */
  ld1--;
  ld2--;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index 4a3f09d9e1f..b7f0a52348c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2967,6 +2967,10 @@ fuse-ld=lld
 Common Driver Negative(fuse-ld=lld)
 Use the lld LLVM linker instead of the default linker.
 
+fuse-ld=mold
+Common Driver Negative(fuse-ld=mold)
+Use the Modern linker (MOLD) linker instead of the default linker.
+
 fuse-linker-plugin
 Common Undocumented Var(flag_use_linker_plugin)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fffa899585e..3ecdb85 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15606,6 +15606,10 @@ Use the @command{gold} linker instead of the default 
linker.
 @opindex fuse-ld=lld
 Use the LLVM @command{lld} linker instead of the default linker.
 
+@item -fuse-ld=mold
+@opindex fuse-ld=mold
+Use the Modern Linker (@command{mold}) instead of the default linker.
+
 @cindex Libraries
 @item -l@var{library}
 @itemx -l @var{library}
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 20a649ea08e..ecda8cbba02 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4196,6 +4196,10 @@ driver_handle_option (struct gcc_options *opts,
use_ld = ".gold";
break;
 
+case OPT_fuse_ld_mold:
+   use_ld = ".mold";
+   break;
+
 case OPT_fcompare_debug_second:
   compare_debug_second = 1;
   break;
diff --git a/gcc/opts.c b/gcc/opts.c
index 24bb64198c8..9192ca75743 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2875,6 +2875,7 @@ common_handle_option (struct gcc_options *opts,
 case OPT_fuse_ld_bfd:
 case OPT_fuse_ld_gold:
 case OPT_fuse_ld_lld:
+case OPT_fuse_ld_mold:
 case OPT_fuse_linker_plugin:
   /* No-op. Used by the driver and passed to us because it starts with f.*/
   break;
-- 
2.39.3



Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

2019-11-01 Thread Romain Geissler
Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
>
> Please make sure to get features intended for GCC 10 finished
> and reviewed before the end of stage 1.
>

Hi,

I understand my question comes very (most likely too) late, but are
there any plans to switch the default C++ dialect to -std=gnu++17 when
invoking g++ ? C++17 support in gcc is now quite complete, has been
out tested by some users since gcc 8, so shall it be switched on by
default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
some tests in the testsuite, I hope not too many.

Cheers,
Romain


Re: [PATCH] Use __is_same_as for std::is_same and std::is_same_v

2019-10-12 Thread Romain Geissler
Le sam. 12 oct. 2019 à 17:44, Romain Geissler
 a écrit :
>
> It looks like this creates the following error when I try to bootstrap
> clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that
> with g++, there is no problem, however it looks like clang++ has some
> problem with the new header. I don't know if this is an issue on
> libstdc++ side or clang++ side.

__is_same_as is not implemented as a compiler builtin in clang++
unlike g++, thus the error on clang 9.0.0 side. It looks like current
clang trunk doesn't define __is_same_as either. Until clang implements
this support (if it ever will), usage of __is_same_as in libstdc++
shall be conditional, only when __has_builtin(__is_same_as) is true
(however that would require that gcc implements __has_builtin, as
implemented here:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html )

Cheers,
Romain


Re: [PATCH] Use __is_same_as for std::is_same and std::is_same_v

2019-10-12 Thread Romain Geissler
Le ven. 11 oct. 2019 à 17:50, Jonathan Wakely  a écrit :
>
> By using the built-in we don't need to match a partial specialization
> for std::is_same and don't need to instantiate std::is_same at all for
> uses of std::is_same_v.
>
> * include/std/type_traits (is_same): Replace partial specialization
> by using __is_same_as built-in in primary template.
> (is_same_v): Use __is_same_as built-in instead of instantiating the
> is_same trait.
>
> Tested x86_64-linux, committed to trunk.
>

Hi Jonathan,

It looks like this creates the following error when I try to bootstrap
clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that
with g++, there is no problem, however it looks like clang++ has some
problem with the new header. I don't know if this is an issue on
libstdc++ side or clang++ side.

Cheers,
Romain

FAILED: compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o
/workdir/build/final-system/llvm-build/./bin/clang++
--target=x86_64-1a-linux-gnu  -DXRAY_HAS_EXCEPTIONS=1
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/..
-I/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/../../include -O2 -msse
-msse2 -msse3 
-I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include
-I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include/ncursesw
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color
-ffunction-sections -fdata-sections -Wall -std=c++11
-Wno-unused-parameter -O3 -DNDEBUG-m64 -fPIC -fno-builtin
-fno-exceptions -fomit-frame-pointer -funwind-tables
-fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden
-fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros
-Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -MD -MT
compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o
-MF compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o.d
-o compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o
-c /workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_buffer_queue.cc
In file included from
/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_buffer_queue.cc:21:
In file included from
/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_allocator.h:29:
In file included from
/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_utils.h:20:
In file included from
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/utility:70:
In file included from
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/stl_pair.h:59:
In file included from
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:55:
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1393:51:
error: '_Tp' does not refer to a value
: public integral_constant
  ^
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1391:21:
note: declared here
  template
^
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1393:56:
error: '_Up' does not refer to a value
: public integral_constant
   ^
/opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1391:35:
note: declared here
  template
  ^
2 errors generated.


Re: C++ PATCH to merge concepts-cxx2a branch

2019-10-09 Thread Romain Geissler
Le mer. 9 oct. 2019 à 19:20, Jason Merrill  a écrit :
>
> Andrew has done a lot of work to update the GCC implementation of C++
> concepts to conform to the upcoming C++20 standard, which clarifies,
> removes, and changes various aspects of the earlier concepts TS.  It can
> still use some polishing, but other stage 1 projects are waiting for it
> to land on trunk and it's already a big improvement from what's
> currently there, so I'm going to go ahead and merge it now.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

Hi Jason,

This is a very good news to see preliminary concept support being
merged in the trunk :)

However for me, this caused the following bootstrap failure:

In file included from /workdir/src/gcc-10.0.0/gcc/cp/cp-lang.c:24:
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h: In function 'tree_node*
template_info_decl_check(const_tree, const char*, int, const char*)':
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: error:
'tree_check_failed' was not declared in this scope
   tree_check_failed (t, f, l, fn,
   ^
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: note: suggested
alternative: 'vec_check_alloc'
   tree_check_failed (t, f, l, fn,
   ^
   vec_check_alloc
make[2]: *** [Makefile:1118: cp/cp-lang.o] Error 1

Cheers,
Romain


Re: [EXT] Re: [Driver] Add support for -fuse-ld=lld

2019-02-04 Thread Romain Geissler
On Fri, 25 Jan 2019, Jonathan Wakely wrote:

> This patch was committed to trunk (r265940), but HJ's review comments
> were never addressed (and look correct to me):
> https://clicktime.symantec.com/3QJw9yc7Scra74WXzR3yBDR6H2?u=https%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-patches%2F2016-07%2Fmsg00146.html
>
> The multi-line condition should be split before the || operator not
> after it, and the negation of -fuse-ld=lld is not -fuse-ld-lld.

Hi,

This small cosmetic patch should address it. I don't know how much spaces
should be used to indent the second and third lines in the if condition,
this of course can be changed if it doesn't follow the gcc guidelines.

Cheers,
Romain

2019-02-04  Romain Geissler  

* collect2.c (main): Use one condition per line when checking for
selected_linker.
* common.opt (-fuse-ld=gold, -fuse-ld=lld): Adjust negative driver 
option.


>From ff9489bad0eda7b1a551ba454300022def0c8c77 Mon Sep 17 00:00:00 2001
From: Romain Geissler 
Date: Mon, 4 Feb 2019 11:49:41 +
Subject: [PATCH] Cosmetic changes for -fuse-ld=lld patch.

---
 gcc/collect2.c | 5 +++--
 gcc/common.opt | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index da956bfd984..96e449962e9 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1127,8 +1127,9 @@ main (int argc, char **argv)
   /* Maybe we know the right file to use (if not cross).  */
   ld_file_name = 0;
 #ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (selected_linker == USE_BFD_LD
+  || selected_linker == USE_GOLD_LD
+  || selected_linker == USE_LLD_LD)
 {
   char *linker_name;
 # ifdef HOST_EXECUTABLE_SUFFIX
diff --git a/gcc/common.opt b/gcc/common.opt
index 295cb1f55e1..03d8bc36260 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2792,11 +2792,11 @@ Common Driver Negative(fuse-ld=gold)
 Use the bfd linker instead of the default linker.

 fuse-ld=gold
-Common Driver Negative(fuse-ld=bfd)
+Common Driver Negative(fuse-ld=lld)
 Use the gold linker instead of the default linker.

 fuse-ld=lld
-Common Driver Negative(fuse-ld=lld)
+Common Driver Negative(fuse-ld=bfd)
 Use the lld LLVM linker instead of the default linker.

 fuse-linker-plugin
-- 
2.17.1



Re: [EXT] Re: [Driver] Add support for -fuse-ld=lld

2019-01-29 Thread Romain GEISSLER
> Le 29 janv. 2019 à 20:03, Marek Polacek  a écrit :
> 
> On Fri, Jan 25, 2019 at 03:06:41PM +, Jonathan Wakely wrote:
> 
> Indeed.  Romain, are you going to submit a followup patch to address this?
> 
> Marek

Hi,

I submitted the original patch because it was not written by me but by Davide, 
and I thought that modifying myself would require me to sign a FSF copyright 
assignment (which is Ok for me, but my employer needs to sign too and right now 
it is not done).

So if the followup patch can be committed without assignment, I can do it right 
now. If not, I will need to get my company legal team to figure out the 
assignment and it can take weeks. Do you think it would be obvious enough not 
to require an assignment ?

Cheers,
Romain

Re: [EXT] Re: [Driver] Add support for -fuse-ld=lld

2018-11-08 Thread Romain Geissler

On Thu, 8 Nov 2018, Richard Biener wrote:



The patch is OK.

Thanks,
Richard.



Thanks. Can you please apply it as I don't have any commit rights ?
The patch can be found in
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01240.html

Here is a valid gcc/ChangeLog correctly formated where I am referrencing
the original author of the patch (not me).

Cheers,
Romain

2018-11-08  Davide Italiano  

* collect2.c (main): Support -fuse-ld=lld.
* common.opt: Add fuse-ld=lld
* doc/invoke.texi:  Document -fuse-ld=lld
* opts.c: Ignore -fuse-ld=lld


Re: [EXT] Re: [Driver] Add support for -fuse-ld=lld

2018-11-08 Thread Romain Geissler
On Tue, 6 Nov 2018, H.J. Lu wrote:

> On Sat, Oct 20, 2018 at 3:19 AM Romain Geissler
>  wrote:
> >
> > I would like to raise again the question of supporting -fuse-ld=lld.
> >
>
> LGTM.  But I can't approve it.
>
> --
> H.J.

Hi,

Is there any gcc reviewer that could comment whether or not this small
feature is welcome in gcc ?

Cheers,
Romain


Re: [Driver] Add support for -fuse-ld=lld

2018-11-06 Thread Romain GEISSLER
Ping^2

> Le 27 oct. 2018 à 11:33, Romain GEISSLER  a 
> écrit :
> 
> Ping
> 
>> Le 20 oct. 2018 à 12:18, Romain Geissler  a 
>> écrit :
>> 
>> Hi,
>> 
>> I would like to raise again the question of supporting -fuse-ld=ldd. A
>> patch implementing it was already submitted in
>> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01722.html by Davide
>> Italiano. This patch still applies correctly to current trunk. I am CC-ing
>> the original author and re-posting it here unchanged for reference.
>> 
>> I think we can consider this patch as relevant despite the goals and
>> licence difference of LLVM vs GNU, based on what was written by Mike Stump
>> in https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00157.html
>> 
>> Back then, the technical problem raised by lld was reported as
>> https://bugs.llvm.org/show_bug.cgi?id=28414 now closed. In this bug, every
>> reported problems have been fixed except the last one. H.J. Lu mentions
>> this last problem (lld does not produces symbol versions predecessor
>> relationship while ld.bfd and ld.gold do, which seems to be a decision
>> taken on purpose and advertised as a harmless change) as being one reason
>> against supporting in -fuse-ld=ldd in gcc. Is it still the case today, and
>> if yes, why ?
>> 
>> Is there any other reason why -fuse-ld=ldd shall not be supported by gcc ?
>> 
>> Cheers,
>> Romain
>> 
>> From 323c23d79c91d7dcee2f29b9ced8c1c00703d346 Mon Sep 17 00:00:00 2001
>> From: Davide Italiano 
>> Date: Thu, 23 Jun 2016 20:51:53 -0700
>> Subject: [PATCH] Driver: Add support for -fuse-ld=lld.
>> 
>> * collect2.c  (main): Support -fuse-ld=lld.
>> 
>> * common.opt: Add fuse-ld=lld
>> 
>> * doc/invoke.texi:  Document -fuse-ld=lld
>> 
>> * opts.c: Ignore -fuse-ld=lld
>> ---
>> gcc/collect2.c  | 11 ---
>> gcc/common.opt  |  4 
>> gcc/doc/invoke.texi |  4 
>> gcc/opts.c  |  1 +
>> 4 files changed, 17 insertions(+), 3 deletions(-)
>> 
>> diff --git a/gcc/collect2.c b/gcc/collect2.c
>> index bffac80..6a8387c 100644
>> --- a/gcc/collect2.c
>> +++ b/gcc/collect2.c
>> @@ -831,6 +831,7 @@ main (int argc, char **argv)
>>  USE_PLUGIN_LD,
>>  USE_GOLD_LD,
>>  USE_BFD_LD,
>> +  USE_LLD_LD,
>>  USE_LD_MAX
>>} selected_linker = USE_DEFAULT_LD;
>>  static const char *const ld_suffixes[USE_LD_MAX] =
>> @@ -838,7 +839,8 @@ main (int argc, char **argv)
>>  "ld",
>>  PLUGIN_LD_SUFFIX,
>>  "ld.gold",
>> -  "ld.bfd"
>> +  "ld.bfd",
>> +  "ld.lld"
>>};
>>  static const char *const real_ld_suffix = "real-ld";
>>  static const char *const collect_ld_suffix = "collect-ld";
>> @@ -1004,6 +1006,8 @@ main (int argc, char **argv)
>>selected_linker = USE_BFD_LD;
>>  else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
>>selected_linker = USE_GOLD_LD;
>> +  else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
>> +selected_linker = USE_LLD_LD;
>> 
>> #ifdef COLLECT_EXPORT_LIST
>>  /* These flags are position independent, although their order
>> @@ -1093,7 +1097,8 @@ main (int argc, char **argv)
>>  /* Maybe we know the right file to use (if not cross).  */
>>  ld_file_name = 0;
>> #ifdef DEFAULT_LINKER
>> -  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD)
>> +  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
>> +  selected_linker == USE_LLD_LD)
>>{
>>  char *linker_name;
>> # ifdef HOST_EXECUTABLE_SUFFIX
>> @@ -1307,7 +1312,7 @@ main (int argc, char **argv)
>>else if (!use_collect_ld
>> && strncmp (arg, "-fuse-ld=", 9) == 0)
>>  {
>> -  /* Do not pass -fuse-ld={bfd|gold} to the linker. */
>> +  /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
>>ld1--;
>>ld2--;
>>  }
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 5d90385..2a95a1f 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -2536,6 +2536,10 @@ fuse-ld=gold
>> Common Driver Negative(fuse-ld=bfd)
>> Use the gold linker instead of the default linker.
>> 
>> +fuse-ld=lld
>> +Common Driver Negative(fuse-ld=lld)
>> +Use the lld LLVM linker instead of the default linker.
>> +
>>

Re: [Driver] Add support for -fuse-ld=lld

2018-10-27 Thread Romain GEISSLER
Ping

> Le 20 oct. 2018 à 12:18, Romain Geissler  a 
> écrit :
> 
> Hi,
> 
> I would like to raise again the question of supporting -fuse-ld=ldd. A
> patch implementing it was already submitted in
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01722.html by Davide
> Italiano. This patch still applies correctly to current trunk. I am CC-ing
> the original author and re-posting it here unchanged for reference.
> 
> I think we can consider this patch as relevant despite the goals and
> licence difference of LLVM vs GNU, based on what was written by Mike Stump
> in https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00157.html
> 
> Back then, the technical problem raised by lld was reported as
> https://bugs.llvm.org/show_bug.cgi?id=28414 now closed. In this bug, every
> reported problems have been fixed except the last one. H.J. Lu mentions
> this last problem (lld does not produces symbol versions predecessor
> relationship while ld.bfd and ld.gold do, which seems to be a decision
> taken on purpose and advertised as a harmless change) as being one reason
> against supporting in -fuse-ld=ldd in gcc. Is it still the case today, and
> if yes, why ?
> 
> Is there any other reason why -fuse-ld=ldd shall not be supported by gcc ?
> 
> Cheers,
> Romain
> 
> From 323c23d79c91d7dcee2f29b9ced8c1c00703d346 Mon Sep 17 00:00:00 2001
> From: Davide Italiano 
> Date: Thu, 23 Jun 2016 20:51:53 -0700
> Subject: [PATCH] Driver: Add support for -fuse-ld=lld.
> 
> * collect2.c  (main): Support -fuse-ld=lld.
> 
> * common.opt: Add fuse-ld=lld
> 
> * doc/invoke.texi:  Document -fuse-ld=lld
> 
> * opts.c: Ignore -fuse-ld=lld
> ---
> gcc/collect2.c  | 11 ---
> gcc/common.opt  |  4 
> gcc/doc/invoke.texi |  4 
> gcc/opts.c  |  1 +
> 4 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/collect2.c b/gcc/collect2.c
> index bffac80..6a8387c 100644
> --- a/gcc/collect2.c
> +++ b/gcc/collect2.c
> @@ -831,6 +831,7 @@ main (int argc, char **argv)
>   USE_PLUGIN_LD,
>   USE_GOLD_LD,
>   USE_BFD_LD,
> +  USE_LLD_LD,
>   USE_LD_MAX
> } selected_linker = USE_DEFAULT_LD;
>   static const char *const ld_suffixes[USE_LD_MAX] =
> @@ -838,7 +839,8 @@ main (int argc, char **argv)
>   "ld",
>   PLUGIN_LD_SUFFIX,
>   "ld.gold",
> -  "ld.bfd"
> +  "ld.bfd",
> +  "ld.lld"
> };
>   static const char *const real_ld_suffix = "real-ld";
>   static const char *const collect_ld_suffix = "collect-ld";
> @@ -1004,6 +1006,8 @@ main (int argc, char **argv)
> selected_linker = USE_BFD_LD;
>   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
> selected_linker = USE_GOLD_LD;
> +  else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
> +selected_linker = USE_LLD_LD;
> 
> #ifdef COLLECT_EXPORT_LIST
>   /* These flags are position independent, although their order
> @@ -1093,7 +1097,8 @@ main (int argc, char **argv)
>   /* Maybe we know the right file to use (if not cross).  */
>   ld_file_name = 0;
> #ifdef DEFAULT_LINKER
> -  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD)
> +  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
> +  selected_linker == USE_LLD_LD)
> {
>   char *linker_name;
> # ifdef HOST_EXECUTABLE_SUFFIX
> @@ -1307,7 +1312,7 @@ main (int argc, char **argv)
> else if (!use_collect_ld
>  && strncmp (arg, "-fuse-ld=", 9) == 0)
>   {
> -   /* Do not pass -fuse-ld={bfd|gold} to the linker. */
> +   /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
> ld1--;
> ld2--;
>   }
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 5d90385..2a95a1f 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2536,6 +2536,10 @@ fuse-ld=gold
> Common Driver Negative(fuse-ld=bfd)
> Use the gold linker instead of the default linker.
> 
> +fuse-ld=lld
> +Common Driver Negative(fuse-ld=lld)
> +Use the lld LLVM linker instead of the default linker.
> +
> fuse-linker-plugin
> Common Undocumented Var(flag_use_linker_plugin)
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 2c87c53..4b8acff 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -10651,6 +10651,10 @@ Use the @command{bfd} linker instead of the default 
> linker.
> @opindex fuse-ld=gold
> Use the @command{gold} linker instead of the default linker.
> 
> +@item -fuse-ld=lld
> +@opindex fuse-ld=lld
> +Use the LLVM @

[Driver] Add support for -fuse-ld=lld

2018-10-20 Thread Romain Geissler
Hi,

I would like to raise again the question of supporting -fuse-ld=ldd. A
patch implementing it was already submitted in
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01722.html by Davide
Italiano. This patch still applies correctly to current trunk. I am CC-ing
the original author and re-posting it here unchanged for reference.

I think we can consider this patch as relevant despite the goals and
licence difference of LLVM vs GNU, based on what was written by Mike Stump
in https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00157.html

Back then, the technical problem raised by lld was reported as
https://bugs.llvm.org/show_bug.cgi?id=28414 now closed. In this bug, every
reported problems have been fixed except the last one. H.J. Lu mentions
this last problem (lld does not produces symbol versions predecessor
relationship while ld.bfd and ld.gold do, which seems to be a decision
taken on purpose and advertised as a harmless change) as being one reason
against supporting in -fuse-ld=ldd in gcc. Is it still the case today, and
if yes, why ?

Is there any other reason why -fuse-ld=ldd shall not be supported by gcc ?

Cheers,
Romain

>From 323c23d79c91d7dcee2f29b9ced8c1c00703d346 Mon Sep 17 00:00:00 2001
From: Davide Italiano 
Date: Thu, 23 Jun 2016 20:51:53 -0700
Subject: [PATCH] Driver: Add support for -fuse-ld=lld.

* collect2.c  (main): Support -fuse-ld=lld.

* common.opt: Add fuse-ld=lld

* doc/invoke.texi:  Document -fuse-ld=lld

* opts.c: Ignore -fuse-ld=lld
---
 gcc/collect2.c  | 11 ---
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi |  4 
 gcc/opts.c  |  1 +
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/gcc/collect2.c b/gcc/collect2.c
index bffac80..6a8387c 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -831,6 +831,7 @@ main (int argc, char **argv)
   USE_PLUGIN_LD,
   USE_GOLD_LD,
   USE_BFD_LD,
+  USE_LLD_LD,
   USE_LD_MAX
 } selected_linker = USE_DEFAULT_LD;
   static const char *const ld_suffixes[USE_LD_MAX] =
@@ -838,7 +839,8 @@ main (int argc, char **argv)
   "ld",
   PLUGIN_LD_SUFFIX,
   "ld.gold",
-  "ld.bfd"
+  "ld.bfd",
+  "ld.lld"
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -1004,6 +1006,8 @@ main (int argc, char **argv)
  selected_linker = USE_BFD_LD;
else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
  selected_linker = USE_GOLD_LD;
+  else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
+selected_linker = USE_LLD_LD;

 #ifdef COLLECT_EXPORT_LIST
/* These flags are position independent, although their order
@@ -1093,7 +1097,8 @@ main (int argc, char **argv)
   /* Maybe we know the right file to use (if not cross).  */
   ld_file_name = 0;
 #ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD)
+  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
+  selected_linker == USE_LLD_LD)
 {
   char *linker_name;
 # ifdef HOST_EXECUTABLE_SUFFIX
@@ -1307,7 +1312,7 @@ main (int argc, char **argv)
  else if (!use_collect_ld
   && strncmp (arg, "-fuse-ld=", 9) == 0)
{
- /* Do not pass -fuse-ld={bfd|gold} to the linker. */
+ /* Do not pass -fuse-ld={bfd|gold|lld} to the linker. */
  ld1--;
  ld2--;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index 5d90385..2a95a1f 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2536,6 +2536,10 @@ fuse-ld=gold
 Common Driver Negative(fuse-ld=bfd)
 Use the gold linker instead of the default linker.

+fuse-ld=lld
+Common Driver Negative(fuse-ld=lld)
+Use the lld LLVM linker instead of the default linker.
+
 fuse-linker-plugin
 Common Undocumented Var(flag_use_linker_plugin)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2c87c53..4b8acff 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10651,6 +10651,10 @@ Use the @command{bfd} linker instead of the default 
linker.
 @opindex fuse-ld=gold
 Use the @command{gold} linker instead of the default linker.

+@item -fuse-ld=lld
+@opindex fuse-ld=lld
+Use the LLVM @command{lld} linker instead of the default linker.
+
 @cindex Libraries
 @item -l@var{library}
 @itemx -l @var{library}
diff --git a/gcc/opts.c b/gcc/opts.c
index 7406210..f2c86f7 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2178,6 +2178,7 @@ common_handle_option (struct gcc_options *opts,

 case OPT_fuse_ld_bfd:
 case OPT_fuse_ld_gold:
+case OPT_fuse_ld_lld:
 case OPT_fuse_linker_plugin:
   /* No-op. Used by the driver and passed to us because it starts with f.*/
   break;


Re: [stdc++] Mark global new/delete operators as weak symbols

2013-09-04 Thread Romain Geissler
Ping

2013/8/20 Romain Geissler romain.geiss...@gmail.com:
 Hi,

 According to the C++ standard §17.4.3.4(2,3) the global new and delete
 operator implementation can be replaced by the program. For example,
 tcmalloc does redefine them. On ELF targets, it is currently OK if you
 link libstc++ dynamically. However, if you try to link both tcmalloc
 and stdc++ statically, then the linker will complain about multiple
 symbol definition.

 This patch fixes this by marking the global new/delete operator as
 weaks for linux. I may be extended to all ELF targets. Bootstrapped
 and tested on SLES 11 SP1 x86_64.

 Cheers,
 Romain

 /libstc++-v3/

 2013-08-20  Romain Geissler  romain.geiss...@gmail.com

 * config/os/gnu-linux/os_defines.h: (_GLIBCXX_WEAK_DEFINITION): Define.


[stdc++] Mark global new/delete operators as weak symbols

2013-08-20 Thread Romain Geissler
Hi,

According to the C++ standard §17.4.3.4(2,3) the global new and delete
operator implementation can be replaced by the program. For example,
tcmalloc does redefine them. On ELF targets, it is currently OK if you
link libstc++ dynamically. However, if you try to link both tcmalloc
and stdc++ statically, then the linker will complain about multiple
symbol definition.

This patch fixes this by marking the global new/delete operator as
weaks for linux. I may be extended to all ELF targets. Bootstrapped
and tested on SLES 11 SP1 x86_64.

Cheers,
Romain

/libstc++-v3/

2013-08-20  Romain Geissler  romain.geiss...@gmail.com

* config/os/gnu-linux/os_defines.h: (_GLIBCXX_WEAK_DEFINITION): Define.


0001-Define-global-new-delete-operators-as-weak-symbols.patch
Description: Binary data


Re: Add __stpncpy_chk builtin support

2011-12-15 Thread Romain Geissler
Le 8 déc. 2011 à 19:09, Jakub Jelinek a écrit :

 On Mon, Nov 28, 2011 at 12:16:52PM +0100, Romain Geissler wrote:
 2011-11-28  Romain Geissler  romain.geiss...@gmail.com
 
  * builtins.def (BUILT_IN_STPNCPY_CHK): New definition.
  * builtins.c (expand_builtin, fold_builtin_4, maybe_emit_chk_warning):
  Add BUILT_IN_STPNCPY_CHK case.
  * gimple-fold.c (gimple_fold_builtin): Likewise.
  * tree-object-size.c (pass_through_call): Likewise.
  * tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
  call_may_clobber_ref_p_1): Likewise.
  * tree-ssa-structalias.c (find_func_aliases_for_builtin_call,
  find_func_clobbers): Likewise.
  * tree.h (fold_builtin_strncpy_chk): Rename to fold_builtin_stxncpy_chk
  * builtins.c (fold_builtin_strncpy_chk): Likewise.
  Rewrite stpncpy_chk calls to strncpy_chk calls if returned value is
  ignored.
 
 gcc/testsuite/
 
 2011-11-28  Romain Geissler  romain.geiss...@gmail.com
 
  * gcc.c-torture/execute/builtins/chk.h (stpncpy, stpncpy_disallowed):
  New definitions.
  * gcc.c-torture/execute/builtins/lib/chk.c (stpncpy_disallowed):
  Likewise.
  (stpncpy, __stpncpy_chk): New functions.
  * gcc.c-torture/execute/builtins/stpncpy-chk-lib.c: New file.
  * gcc.c-torture/execute/builtins/stpncpy-chk.c: Likewise.
 
 
 This is ok for trunk, if you fix formatting nits mentioned below:
 
 @@ -10910,7 +10911,8 @@ fold_builtin_4 (location_t loc, tree fndecl,
 DECL_FUNCTION_CODE (fndecl));
 
 case BUILT_IN_STRNCPY_CHK:
 -  return fold_builtin_strncpy_chk (loc, arg0, arg1, arg2, arg3, 
 NULL_TREE);
 +case BUILT_IN_STPNCPY_CHK:
 +  return fold_builtin_stxncpy_chk (loc, arg0, arg1, arg2, arg3, 
 NULL_TREE, ignore, fcode);
 
 Please watch formatting, this line is too long.
 
 case BUILT_IN_STRNCAT_CHK:
   return fold_builtin_strncat_chk (loc, fndecl, arg0, arg1, arg2, arg3);
 @@ -12863,8 +12877,9 @@ fold_builtin_strncpy_chk (location_t loc, tree dest, 
 tree src,
   return NULL_TREE;
 }
 
 -  /* If __builtin_strncpy_chk is used, assume strncpy is available.  */
 -  fn = builtin_decl_explicit (BUILT_IN_STRNCPY);
 +  /* If __builtin_st{r,p}ncpy_chk is used, assume st{r,p}ncpy is available.  
 */
 +  fn = builtin_decl_explicit (fcode == BUILT_IN_STPNCPY_CHK
 + ? BUILT_IN_STPNCPY : BUILT_IN_STRNCPY);
 
 ? BUILT_IN_STPNCPY needs to be below fcode ==  on the previous line.
 
 + result = fold_builtin_stxncpy_chk (loc, gimple_call_arg (stmt, 0),
gimple_call_arg (stmt, 1),
gimple_call_arg (stmt, 2),
gimple_call_arg (stmt, 3),
 -val[2]);
 +val[2],
 +ignore,
 +   DECL_FUNCTION_CODE (callee));
 
 Please put ignore, on the same line as val[2], and align DECL_FUNCTION_CODE
 properly below val[2].
 
 --- gcc/tree.h
 +++ gcc/tree.h
 @@ -5444,7 +5444,8 @@ extern tree fold_builtin_memory_chk (location_t, tree, 
 tree, tree, tree, tree, t
enum built_in_function);
 extern tree fold_builtin_stxcpy_chk (location_t, tree, tree, tree, tree, 
 tree, bool,
enum built_in_function);
 -extern tree fold_builtin_strncpy_chk (location_t, tree, tree, tree, tree, 
 tree);
 +extern tree fold_builtin_stxncpy_chk (location_t, tree, tree, tree, tree, 
 tree, bool,
 +  enum built_in_function);
 
 enum  should be aligned below location_t,.
 
   Jakub

Hi

Here is the patch with fixed coding style.
Can you please apply it, i don't have write access to the repository.

Romain Geissler



lion_build.patch
Description: Binary data



Re: Add __stpncpy_chk builtin support

2011-12-08 Thread Romain Geissler
Le 28 nov. 2011 à 12:16, Romain Geissler a écrit :

 Hi,
 
 The current trunk have no support for the __stpncpy_chk function. As the 
 latest
 OS X (10.7 aka Lion) now defines stpncpy as a call to builtin__stpncpy_chk for
 GNUC compliant compiler, the following code won't link:
 
 #include string.h
 
 int main(){
   char string[10];
   stpncpy(string,abcd,8);
 
   return 0;
 }
 
 Undefined symbols for architecture x86_64:
  ___builtin___stpncpy_chk, referenced from:
  _main in ccGFZoZV.o
 ld: symbol(s) not found for architecture x86_64
 collect2: error: ld returned 1 exit status
 
 
 This patch add support for this builtin.
 Bootstrapped and tested without regression on darwin x86_64.
 
 Romain Geissler
 
 gcc/
 
 2011-11-28  Romain Geissler  romain.geiss...@gmail.com
 
   * builtins.def (BUILT_IN_STPNCPY_CHK): New definition.
   * builtins.c (expand_builtin, fold_builtin_4, maybe_emit_chk_warning):
   Add BUILT_IN_STPNCPY_CHK case.
   * gimple-fold.c (gimple_fold_builtin): Likewise.
   * tree-object-size.c (pass_through_call): Likewise.
   * tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
   call_may_clobber_ref_p_1): Likewise.
   * tree-ssa-structalias.c (find_func_aliases_for_builtin_call,
   find_func_clobbers): Likewise.
   * tree.h (fold_builtin_strncpy_chk): Rename to fold_builtin_stxncpy_chk
   * builtins.c (fold_builtin_strncpy_chk): Likewise.
   Rewrite stpncpy_chk calls to strncpy_chk calls if returned value is
   ignored.
 
 gcc/testsuite/
 
 2011-11-28  Romain Geissler  romain.geiss...@gmail.com
 
   * gcc.c-torture/execute/builtins/chk.h (stpncpy, stpncpy_disallowed):
   New definitions.
   * gcc.c-torture/execute/builtins/lib/chk.c (stpncpy_disallowed):
   Likewise.
   (stpncpy, __stpncpy_chk): New functions.
   * gcc.c-torture/execute/builtins/stpncpy-chk-lib.c: New file.
   * gcc.c-torture/execute/builtins/stpncpy-chk.c: Likewise.
 
 lion_build.patch

Ping


Add __stpncpy_chk builtin support

2011-11-28 Thread Romain Geissler
Hi,

The current trunk have no support for the __stpncpy_chk function. As the latest
OS X (10.7 aka Lion) now defines stpncpy as a call to builtin__stpncpy_chk for
GNUC compliant compiler, the following code won't link:

#include string.h

int main(){
char string[10];
stpncpy(string,abcd,8);

return 0;
}

Undefined symbols for architecture x86_64:
  ___builtin___stpncpy_chk, referenced from:
  _main in ccGFZoZV.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


This patch add support for this builtin.
Bootstrapped and tested without regression on darwin x86_64.

Romain Geissler

gcc/

2011-11-28  Romain Geissler  romain.geiss...@gmail.com

* builtins.def (BUILT_IN_STPNCPY_CHK): New definition.
* builtins.c (expand_builtin, fold_builtin_4, maybe_emit_chk_warning):
Add BUILT_IN_STPNCPY_CHK case.
* gimple-fold.c (gimple_fold_builtin): Likewise.
* tree-object-size.c (pass_through_call): Likewise.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
call_may_clobber_ref_p_1): Likewise.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call,
find_func_clobbers): Likewise.
* tree.h (fold_builtin_strncpy_chk): Rename to fold_builtin_stxncpy_chk
* builtins.c (fold_builtin_strncpy_chk): Likewise.
Rewrite stpncpy_chk calls to strncpy_chk calls if returned value is
ignored.

gcc/testsuite/

2011-11-28  Romain Geissler  romain.geiss...@gmail.com

* gcc.c-torture/execute/builtins/chk.h (stpncpy, stpncpy_disallowed):
New definitions.
* gcc.c-torture/execute/builtins/lib/chk.c (stpncpy_disallowed):
Likewise.
(stpncpy, __stpncpy_chk): New functions.
* gcc.c-torture/execute/builtins/stpncpy-chk-lib.c: New file.
* gcc.c-torture/execute/builtins/stpncpy-chk.c: Likewise.



lion_build.patch
Description: Binary data


Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

2011-09-22 Thread Romain Geissler
Hello,

Le 22 sept. 2011 à 15:22, Dodji Seketeli a écrit :
 
 So i may need a PLUGIN_FINISH_TYPE_DECLARATION triggered when the type
 is declared but before it is finally defined.
 
 Hmmh.  For this specific case, maybe just setting the TREE_DEPRECATED
 flag on the tree node of type could do what you want


The deprecated attribute was just an example. I may need to apply any type 
attribute
when a new type is parsed, which is currently not possible with the current C++
front-end.

Romain


Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

2011-09-22 Thread Romain Geissler

Le 22 sept. 2011 à 16:18, Diego Novillo a écrit :

 On 11-09-22 09:40 , Dodji Seketeli wrote:
 Romain Geisslerromain.geiss...@gmail.com  a écrit:
 
 I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
 
 The followings does not currently trigger the PLUGIN_FINISH_DECL
 (or not in all cases), but should them ?
  - function parameters (in the function prototype)
  - definition (with a function body) of a top-level function (while the 
 exact
same function definition enclosed in a class definition will trigger
PLUGIN_FINISH_DECL)
  - label declaration
  - constants defined by enums
  - namespace
 
 Indeed.  finish_decl is not called in those cases.  As to if the
 PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at
 least if I believe what the description in plugin.def says:
 
 /* After finishing parsing a declaration. */
 DEFEVENT (PLUGIN_FINISH_DECL)
 
 But I'd rather ask what the maintainers think about it.
 
 Jason, Diego?
 
 Yes, those events should trigger a PLUGIN_FINISH_DECL call.

Ok, i've already implemented it in the C front-end. I'll post the whole patch 
soon.

Romain



Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

2011-09-13 Thread Romain Geissler

Hi

2011/9/12 Dodji Seketeli do...@seketeli.org:
 Romain Geissler romain.geiss...@gmail.com a écrit:
 When i recontributed the PLUGIN_FINISH_DECL patch from the original
 Brian Hackett, i didn't exactly checked  what may or may not trigger
 this new event. I know for example that declaring a function triggers
 this event, but defining it does not.

 I don't really know when those event should be triggered, we should
 clarify the meaning of those.

 According to me:
 PLUGIN_FINISH_DECL should be triggered anytime the parser parse a
 declaration (which includes declaration + definition of function,
 typedef definition, namespaces, ..., all DECL_P trees built by the
 parser).

 The general idea sounds sensible, IMHO.  However, we must keep in mind
 that there are cases like, e.g, 'struct C;' where G++ creates a typedef
 'typedef struct C C;' so that you can name that type 'C' instead of
 having to type struct C' all the time.  For these cases, I don't think
 the PLUGIN_FINISH_DECL event should be emitted.

I agree.


 For, PLUGIN_FINISH_TYPE i don't really know it means a new type
 declaration (or declaration + definition) or if it means usage of a
 type (in a function prototype, the type of a local variable.

 I'd say it's a definition of a new type, IMHO.

Ok, so it only involves struct, unions, enum and class declaration / 
definitions.


 I would rather vote for new type definition (including typedefs)

 My understanding is that a typedef declaration doesn't define a new
 type.  Rather, it declares an alias for an existing type.  As such, I
 would think that notifying typedef declarations via PLUGIN_FINISH_DECL
 would be the way to go.

Ok


 but for special cases of struct, you can declare and use them at the
 same time:

 Just to be sure I understand, do you need to be notified about *uses* of
 types and decls as well?  If so, maybe a new kind of event should
 probably be defined, because PLUGIN_FINISH_DECL and PLUGIN_FINISH_TYPE
 seem to have more to do with declaring/defining decls and types than
 using them.


Personally i don't need to catch all struct uses, but i need to catch struct 
declarations.
I want to apply some __attributes__ to a given struct type, for example let's say i need 
to mark *struct my_struct* as deprecated thanks to a plugin. I know how to apply some 
attributes to a type or a decl. See the plugin (test_plugin.c) and the test files attached.


With test_pass.c, my_struct is declared first, then defined after, applying the deprecated 
attribute works.
With test_fail.c, my_struct is declared and defined at the same time, applying the 
deprecated attribute doesn't work with the current trunk (and also with my patch).

I got:
test_fail.c:4:1: warning: type attributes ignored after type is already defined 
[-Wattributes]

So i may need a PLUGIN_FINISH_TYPE_DECLARATION triggered when the type is declared but 
before it is finally defined.


Does two different events PLUGIN_FINISH_TYPE_DECLARATION and PLUGIN_FINISH_TYPE_DEFINITION 
make sens to you ?


 --
Dodji


Romain Geissler
struct my_struct {
int field_1;
int field_2;
};

struct my_struct *my_function();

struct my_struct x = {1, 2};

struct my_struct *my_function(){
return x;
}
struct my_struct *my_function();

struct my_struct {
int field_1;
int field_2;
};

struct my_struct x = {1, 2};

struct my_struct *my_function(){
return x;
}
#include gcc-plugin.h
#include plugin-version.h
#include tree.h
#include cp/cp-tree.h

#pragma weak cplus_decl_attributes

bool my_struct_found = false;
void finish_type_callback (void *gcc_data, void *data ATTRIBUTE_UNUSED) {
tree type = (tree)gcc_data;
const char *type_name;

if (my_struct_found || type == error_mark_node || DECL_P (type)) {
//current PLUGIN_FINISH_TYPE is buggy in C++
//and my current patch may return TYPE_DECL for typedefs

return;
}

if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE) {
type_name = IDENTIFIER_POINTER (TYPE_NAME (type));
} else {
type_name = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)));
}

if (strcmp (type_name, my_struct)) {
//only affect my_struct type
return;
}

my_struct_found = true;
tree deprecated_attribute = tree_cons (get_identifier (deprecated), 
NULL_TREE, NULL_TREE);
inform(input_location,  my_struct found);


//apply the deprecated attribute to the my_struct type.
if (cplus_decl_attributes) {
cplus_decl_attributes (type, deprecated_attribute, 
ATTR_FLAG_TYPE_IN_PLACE);
} else {
decl_attributes (type, deprecated_attribute, 
ATTR_FLAG_TYPE_IN_PLACE);
}
}

int plugin_is_GPL_compatible;

int plugin_init (struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version ATTRIBUTE_UNUSED

[PLUGIN] Fix PLUGIN_FINISH_TYPE

2011-09-12 Thread Romain Geissler

Hi,

This patch solves some lacks with the PLUGIN_FINISH_TYPE event
triggering. For now, both C and C++ parser won't trigger it for enums or
for typedef. In C++, when a struct, class or union declaration is parsed
(without definition), the given event data is an error mark instead of
the parsed type node.

Bootstrapped and tested on x86_64.

Romain Geissler

gcc/
2011-09-12  Romain Geissler  romain.geiss...@gmail.com

* c-decl.c (grokdeclarator): Trigger PLUGIN_FINISH_TYPE for typedefs.
* c-parser.c (cp_parser_type_specifier: Trigger PLUGIN_FINISH_TYPE for
enums.


gcc/cp/
2011-09-12  Romain Geissler  romain.geiss...@gmail.com

* decl.c (grokdeclarator): Trigger PLUGIN_FINISH_TYPE for typedefs.
* parser.c (cp_parser_type_specifier: Trigger PLUGIN_FINISH_TYPE for
enums.
Correctly trigger PLUGIN_FINISH_TYPE for unions, structs or classes.


gcc/testsuite/
2011-09-12  Romain Geissler  romain.geiss...@gmail.com

* gcc.dg/plugin/dumb-plugin-test-1.c: New File.
* gcc.dg/plugin/dumb_plugin.c: Likewise.
* gcc.dg/plugin/plugin.exp: Add above testcase.
* g++.dg/plugin/dumb-plugin-test-1.C: New tests.
* g++.dg/plugin/dumb_plugin.c (handle_type): Renamed from handle_struct.
Add warnings for all kind of types.
Index: gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c
===
--- gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c(revision 0)
@@ -0,0 +1,56 @@
+// Test case for the dumb plugin.
+// { dg-do compile }
+// { dg-options -O -fplugin-arg-dumb_plugin-ref-pass-name=ccp 
-fplugin-arg-dumb_plugin-ref-pass-instance-num=1 }
+
+struct my_struct {
+  int a_;
+  char b_;
+}; // { dg-warning Process struct my_struct }
+
+struct Bar; // { dg-warning Process struct Bar }
+struct Bar; // { dg-warning Process struct Bar }
+struct Bar {
+  int c_;
+  int d_;
+  struct my_struct e_; // { dg-warning Process struct my_struct }
+}; // { dg-warning Process struct Bar }
+
+union my_union; // { dg-warning Process union my_union }
+union my_union; // { dg-warning Process union my_union }
+union my_union {
+  int g_;
+  char h_;
+}; // { dg-warning Process union my_union }
+
+enum my_enum; // { dg-warning Process enum my_enum }
+enum my_enum; // { dg-warning Process enum my_enum }
+enum my_enum {
+  i_,
+  j_
+}; // { dg-warning Process enum my_enum }
+
+typedef int* my_typedef; // { dg-warning Process typedef my_typedef }
+
+int g = 2;
+
+int func()
+{
+  struct Bar *bar1, bar2; // { dg-warning Process struct Bar }
+  int x = x;
+  static int y = 6;
+  float *f;
+  struct Bar bar_array[5];  // { dg-warning Process struct Bar }
+  char n;
+  int overflow;
+
+  *f = *f;
+  bar1-c_ = bar1-c_;
+  bar2.d_ = bar2.d_;
+  bar_array[3].e_ = bar_array[3].e_;
+  bar_array[x+g].d_ = bar_array[x+g].d_;
+  y = x;
+  x = y;
+} // { dg-warning Before genericizing function }
+
+// { dg-warning Analyze function  { target *-*-* } 53 }
+// {  dg-warning End of compilation unit  { target *-*-* } 53 }
Index: gcc/testsuite/gcc.dg/plugin/dumb_plugin.c
===
--- gcc/testsuite/gcc.dg/plugin/dumb_plugin.c   (revision 0)
+++ gcc/testsuite/gcc.dg/plugin/dumb_plugin.c   (revision 0)
@@ -0,0 +1,160 @@
+/* A trivial (dumb) plugin example that shows how to use the GCC plugin
+   mechanism.  */
+
+#include gcc-plugin.h
+#include stdlib.h
+#include config.h
+#include system.h
+#include coretypes.h
+#include tree.h
+#include tree-pass.h
+#include intl.h
+#include toplev.h
+#include diagnostic.h
+
+int plugin_is_GPL_compatible;
+
+/* Callback function to invoke after GCC finishes parsing a type.  */
+
+void
+handle_type (void *event_data, void *data)
+{
+  tree type = (tree) event_data;
+
+  switch (TREE_CODE (type)) {
+case RECORD_TYPE:
+  warning (0, G_(Process struct %s),
+ IDENTIFIER_POINTER (TYPE_NAME (type)));
+  break;
+case UNION_TYPE:
+  warning (0, G_(Process union %s),
+ IDENTIFIER_POINTER (TYPE_NAME (type)));
+  break;
+case ENUMERAL_TYPE:
+  warning (0, G_(Process enum %s),
+ IDENTIFIER_POINTER (TYPE_NAME (type)));
+  break;
+case TYPE_DECL:
+  warning (0, G_(Process typedef %s),
+ IDENTIFIER_POINTER (DECL_NAME (type)));
+  break;
+default:
+  error (G_(Unexpected tree node in PLUGIN_FINISH_TYPE %s\n), 
tree_code_name [TREE_CODE (type)]);
+  }
+}
+
+/* Callback function to invoke before the function body is genericized.  */ 
+
+void
+handle_pre_generic (void *event_data, void *data)
+{
+  tree fndecl = (tree) event_data;
+  warning (0, G_(Before genericizing function %s),
+   IDENTIFIER_POINTER (DECL_NAME (fndecl)));
+}
+
+/* Callback function to invoke after GCC finishes the compilation unit.  */
+
+void
+handle_end_of_compilation_unit (void *event_data

Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

2011-09-12 Thread Romain Geissler
Hi,

2011/9/12 Dodji Seketeli do...@seketeli.org:
 Hello Romain,

 Romain Geissler romain.geiss...@st.com a écrit:

 This patch solves some lacks with the PLUGIN_FINISH_TYPE event
 triggering. For now, both C and C++ parser won't trigger it for enums or
 for typedef.

 AFAICT, typedef declarations are reported by the PLUGIN_FINISH_DECL
 event.  The predicate is_typedef_decl then returns TRUE when passed the
 decl carried by the event.  Maybe the plugin's documentation could use
 an addendum for this.

I just checked again, and PLUGIN_FINISH_DECL is triggered for a
typedef in C mode, but not in C++ mode. I'll patch that.
When i recontributed the PLUGIN_FINISH_DECL patch from the original
Brian Hackett, i didn't exactly checked  what may or may not trigger
this new event. I know for example that declaring a function triggers
this event, but defining it does not.

I don't really know when those event should be triggered, we should
clarify the meaning of those.

According to me:
PLUGIN_FINISH_DECL should be triggered anytime the parser parse a
declaration (which includes declaration + definition of function,
typedef definition, namespaces, ..., all DECL_P trees built by the
parser).
For, PLUGIN_FINISH_TYPE i don't really know it means a new type
declaration (or declaration + definition) or if it means usage of a
type (in a function prototype, the type of a local variable. I would
rather vote for new type definition (including typedefs) but for
special cases of struct, you can declare and use them at the same
time:

#include stdlib.h

struct my_struct x;
struct my_struct *my_function ();

struct my_struct {
  int field_1;
  int field_2;
};

struct my_struct *my_function () {
---return NULL;
}

which GCC accepts even with -pedantic.

That's why in this patch i launch a PLUGIN_FINISH_TYPE event every
time the parser meet the struct keyword.


So, what the real meaning of all those events ?


 [...]

 gcc/cp/
 2011-09-12  Romain Geissler  romain.geiss...@gmail.com

       * decl.c (grokdeclarator): Trigger PLUGIN_FINISH_TYPE for typedefs.

 [...]

 Index: gcc/cp/decl.c
 ===
 --- gcc/cp/decl.c     (revision 178252)
 +++ gcc/cp/decl.c     (working copy)
 @@ -9682,6 +9682,9 @@ grokdeclarator (const cp_declarator *dec
                     memfn_quals != TYPE_UNQUALIFIED,
                     inlinep, friendp, raises != NULL_TREE);

 +      if (TREE_TYPE (decl) != error_mark_node  !DECL_ARTIFICIAL (decl))
 +        invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, decl);
 +
        return decl;
      }


 So I think this change is not necessary.

 [...]


 Index: gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c
 ===
 --- gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c  (revision 0)
 +++ gcc/testsuite/gcc.dg/plugin/dumb-plugin-test-1.c  (revision 0)
 @@ -0,0 +1,56 @@
 +// Test case for the dumb plugin.
 +// { dg-do compile }
 +// { dg-options -O -fplugin-arg-dumb_plugin-ref-pass-name=ccp 
 -fplugin-arg-dumb_plugin-ref-pass-instance-num=1 }
 +

 Here, it would be nice to add a comment saying which plugin acts on this
 plugin's test and what the plugin does (what the output is supposed to
 be).  That redundant information eases the review, at very least.

Ok


 Thanks.

 --
                Dodji



Re: [PATCH] Fix configure --with-cloog

2011-08-23 Thread Romain Geissler
Ping


Re: [Patch] Properly find getopt system declaration

2011-08-23 Thread Romain Geissler
2011/8/10 Romain GEISSLER romain.geiss...@st.com:
 Hi

 Thanks to the recent changes made to stage 2 and 3 (now built with g++), i
 noticed a little error in the configure script that tries the
 system getopt declaration. Indeed, if your system defines it in a system
 header file named getopt.h (for example /usr/include/getopt.h on a Red Hat
 4 configuration), the configure script will incorrectly load
 /path/to/gcc/src/include/getopt.h instead, and thus find no getopt
 declaration.

 This can be solved by changing the appropriate -I${srcdir}/../include by
 -iquote ${srcdir}/../include. I added a configure check to verify that the
 compiler accepts the -iquote switch (and fallback to -I otherwise).
 Note that this only solve the getopt case, but -I is certainly often misused
 (instead of -iquote that would prevent error with system header having the
 same name than gcc header).

 The attached patch has been tested for regression with a native x86_64
 bootstrap.

 config/

 2011-08-10  Romain Geissler  romain.geiss...@gmail.com

        * acx.m4 (ACX_CHECK_CC_ACCEPTS_IQUOTE) : Define.


 gcc/

 2011-08-10  Romain Geissler  romain.geiss...@gmail.com

        * configure.ac (acx_cv_cc_accepts_iquote): Define through a call
        to ACX_CHECK_CC_ACCEPTS_IQUOTE.
        (CFLAGS for gcc_AC_CHECK_DECLS): Use $acx_cv_cc_accepts_iquote
        instead of -I.
        * configure: Regenerate.


 Romain Geissler


Ping


Re: plugin event for C/C++ declarations

2011-08-11 Thread Romain Geissler

On 08/10/2011 05:20 PM, Diego Novillo wrote:

On Mon, Aug 8, 2011 at 07:39, Romain Geisslerromain.geiss...@gmail.com  wrote:

2011/7/20 Diego Novillodnovi...@google.com:

On Mon, Jul 18, 2011 at 03:06, Romain Geissler
I will commit this patch shortly.


Diego.



Ping !


Romain, please send me a current patch against today's trunk.


Thanks.  Diego.


Hi

Find attached the updated patch. Retested for regression on x86_64.

Romain Geissler.
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 177557)
+++ gcc/doc/plugins.texi(working copy)
@@ -151,6 +151,7 @@ enum plugin_event
 @{
   PLUGIN_PASS_MANAGER_SETUP,/* To hook into pass manager.  */
   PLUGIN_FINISH_TYPE,   /* After finishing parsing a type.  */
+  PLUGIN_FINISH_DECL,   /* After finishing parsing a declaration. */
   PLUGIN_FINISH_UNIT,   /* Useful for summary processing.  */
   PLUGIN_PRE_GENERICIZE,/* Allows to see low level AST in C and C++ 
frontends.  */
   PLUGIN_FINISH,/* Called before GCC exits.  */
Index: gcc/plugin.def
===
--- gcc/plugin.def  (revision 177557)
+++ gcc/plugin.def  (working copy)
@@ -24,6 +24,9 @@ DEFEVENT (PLUGIN_PASS_MANAGER_SETUP)
 /* After finishing parsing a type.  */
 DEFEVENT (PLUGIN_FINISH_TYPE)
 
+/* After finishing parsing a declaration. */
+DEFEVENT (PLUGIN_FINISH_DECL)
+
 /* Useful for summary processing.  */
 DEFEVENT (PLUGIN_FINISH_UNIT)
 
Index: gcc/testsuite/g++.dg/plugin/plugin.exp
===
--- gcc/testsuite/g++.dg/plugin/plugin.exp  (revision 177557)
+++ gcc/testsuite/g++.dg/plugin/plugin.exp  (working copy)
@@ -51,7 +51,8 @@ set plugin_test_list [list \
 { pragma_plugin.c pragma_plugin-test-1.C } \
 { selfassign.c self-assign-test-1.C self-assign-test-2.C 
self-assign-test-3.C } \
 { dumb_plugin.c dumb-plugin-test-1.C } \
-{ header_plugin.c header-plugin-test.C } ]
+{ header_plugin.c header-plugin-test.C } \
+{ decl_plugin.c decl-plugin-test.C } ]
 
 foreach plugin_test $plugin_test_list {
 # Replace each source file with its full-path name
Index: gcc/testsuite/g++.dg/plugin/decl-plugin-test.C
===
--- gcc/testsuite/g++.dg/plugin/decl-plugin-test.C  (revision 0)
+++ gcc/testsuite/g++.dg/plugin/decl-plugin-test.C  (revision 0)
@@ -0,0 +1,30 @@
+extern int global; // { dg-warning Decl Global global }
+int global_array[] = { 1, 2, 3 }; // { dg-warning Decl Global global_array }
+
+int takes_args(int arg1, int arg2)
+{
+  int local = arg1 + arg2 + global; // { dg-warning Decl Local local }
+  return local + 1;
+}
+
+int global = 12; // { dg-warning Decl Global global }
+
+struct test_str {
+  int field; // { dg-warning Decl Field field }
+};
+
+class test_class {
+  int class_field1; // { dg-warning Decl Field class_field1 }
+  int class_field2; // { dg-warning Decl Field class_field2 }
+
+  test_class() // { dg-warning Decl Function test_class }
+: class_field1(0), class_field2(0)
+  {}
+
+  void swap_fields(int bias) // { dg-warning Decl Function swap_fields }
+  {
+int temp = class_field1 + bias; // { dg-warning Decl Local temp }
+class_field1 = class_field2 - bias;
+class_field2 = temp;
+  }
+};
Index: gcc/testsuite/g++.dg/plugin/decl_plugin.c
===
--- gcc/testsuite/g++.dg/plugin/decl_plugin.c   (revision 0)
+++ gcc/testsuite/g++.dg/plugin/decl_plugin.c   (revision 0)
@@ -0,0 +1,51 @@
+/* A plugin example that shows which declarations are caught by FINISH_DECL */
+
+#include gcc-plugin.h
+#include stdlib.h
+#include config.h
+#include system.h
+#include coretypes.h
+#include tree.h
+#include tree-pass.h
+#include intl.h
+
+int plugin_is_GPL_compatible;
+
+/* Callback function to invoke after GCC finishes a declaration. */
+
+void plugin_finish_decl (void *event_data, void *data)
+{
+  tree decl = (tree) event_data;
+
+  const char *kind = NULL;
+  switch (TREE_CODE(decl)) {
+  case FUNCTION_DECL:
+kind = Function; break;
+  case PARM_DECL:
+kind = Parameter; break;
+  case VAR_DECL:
+if (DECL_FILE_SCOPE_P(decl))
+  kind = Global;
+else
+  kind = Local;
+break;
+  case FIELD_DECL:
+kind = Field; break;
+  default:
+kind = Unknown;
+  }
+
+  warning (0, G_(Decl %s %s),
+   kind, IDENTIFIER_POINTER (DECL_NAME (decl)));
+}
+
+int
+plugin_init (struct plugin_name_args *plugin_info,
+ struct plugin_gcc_version *version)
+{
+  const char *plugin_name = plugin_info-base_name;
+
+  register_callback (plugin_name, PLUGIN_FINISH_DECL,
+ plugin_finish_decl, NULL);
+  return 0;
+}
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c

Re: [PLUGIN] Install c-tree.h header

2011-08-10 Thread Romain Geissler
2011/8/2 Romain Geissler romain.geiss...@gmail.com:
 Hi,

 For now, plugins can't compare types. This patch allows
 c-tree.h to be installed as a plugin header, allowing
 plugins to see comptypes (among other things).

 Romain Geissler


 2011-08-02  Romain Geissler  romain.geiss...@gmail.com

        * Makefile.in (PLUGIN_HEADERS): Add C_TREE_H.


 Index: gcc/Makefile.in
 ===
 --- gcc/Makefile.in     (revision 176741)
 +++ gcc/Makefile.in     (working copy)
 @@ -4584,7 +4584,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
   $(GGC_H) $(TREE_DUMP_H) $(PRETTY_PRINT_H) $(OPTS_H) $(PARAMS_H) plugin.def \
   $(tm_file_list) $(tm_include_list) $(tm_p_file_list) $(tm_p_include_list) \
   $(host_xm_file_list) $(host_xm_include_list) $(xm_include_list) \
 -  intl.h $(PLUGIN_VERSION_H) $(DIAGNOSTIC_H) \
 +  intl.h $(PLUGIN_VERSION_H) $(DIAGNOSTIC_H) ${C_TREE_H} \
   $(C_COMMON_H) c-family/c-objc.h $(C_PRETTY_PRINT_H) \
   tree-iterator.h $(PLUGIN_H) $(TREE_FLOW_H) langhooks.h incpath.h debug.h \
   $(EXCEPT_H) tree-ssa-sccvn.h real.h output.h $(IPA_UTILS_H) \


Ping.


Re: plugin event for C/C++ declarations

2011-08-08 Thread Romain Geissler
2011/7/20 Diego Novillo dnovi...@google.com:
 On Mon, Jul 18, 2011 at 03:06, Romain Geissler
 I will commit this patch shortly.


 Diego.


Ping !


Re: PATCH RFA: Build stages 2 and 3 with C++

2011-08-08 Thread Romain Geissler

Le 8 août 2011 à 20:49, Ian Lance Taylor a écrit :
 
 However, since we currently permit plugins to call anything in gcc, I
 think the answer is going to have to be that plugins which do that
 should be compiled with C++.

Ok, i'll move to C++ then, until a dedicated C plugin API comes out.

 I don't think that adding extern C to
 all gcc header files is the right approach.  Adding extern C to a few
 selected header files seems fine.

Adding extern C to a small set of files doesn't make sense to me. When
working with real-world plugin, you will certainly end up calling many
different gcc primitives coming from a wide bunch of header files (which
for most of them don't use extern C for now). This hack should be applied
to all of the plugin visible files, or none, but not to just a few when someone
needs it.


Re: [PLUGIN] compile and install gengtype, install gtype.state

2011-08-04 Thread Romain GEISSLER

On 08/04/2011 12:21 PM, Romain Geissler wrote:

On Mon, Aug 01, 2011 at 02:27:49PM +0200, Romain Geissler wrote:

ping


I went ahead and bootstrapped/regtested/and make install tested your patch
(note your mailer wrapped it up so that it didn't apply cleanly), but now
that I think about it, it is wrong to put the gengtype binary into
$(libsubdir)/plugin/bin/
IMNSHO it should go into
$(libexecsubdir)/plugin/
directory instead, libexec is where binaries go...  So please change
plugin_bindir.

Jakub



Hi,

Find attached the final patch. I can't apply it by myself.

Romain Geissler.
2011-07-18  Romain Geissler  romain.geiss...@gmail.com

* gengtype-state.c: Include bconfig.h if
GENERATOR_FILE is defined, config.h otherwise.
* gengtype.c: Likewise.
* gengtype-lex.l: Likewise.
* gengtype-parse.c: Likewise.
* Makefile.in (gengtype-lex.o-warn): New variable.
(plugin_resourcesdir): Likewise.
(plugin_bindir): Likewise.
(plugin_includedir): Use $(plugin_resourcesdir) as prefix base.
(MOSTLYCLEANFILES): Add gengtype$(exeext).
(native): Depend on gengtype$(exeext) is $enable_plugin
is set to yes.
(gtype.state): Depend on s-gtype. Use temporary file.
(gengtype-lex.o): New rule.
(gengtype-parse.o): Likewise.
(gengtype-state.o): Likewise.
(gengtype$(exeext)): Likewise.
(install-gengtype): Likewise.
(gengtype.o): Likewise.
(build/gengtype.o): Depend on version.h.
(build/gengtype-state): Depend on double-int.h, version.h,
$(HASHTAB_H), $(OBSTACK_H), $(XREGEX_H) and build/errors.o.
(install-plugin): Depend on install-gengtype.
Index: gcc/gengtype-state.c
===
--- gcc/gengtype-state.c(revision 176740)
+++ gcc/gengtype-state.c(working copy)
@@ -23,7 +23,11 @@
and Basile Starynkevitch bas...@starynkevitch.net
 */
 
+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include errors.h/* For fatal.  */
 #include double-int.h
Index: gcc/gengtype.c
===
--- gcc/gengtype.c  (revision 176740)
+++ gcc/gengtype.c  (working copy)
@@ -18,7 +18,11 @@
along with GCC; see the file COPYING3.  If not see
http://www.gnu.org/licenses/.  */
 
+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include errors.h/* for fatal */
 #include getopt.h
Index: gcc/gengtype-lex.l
===
--- gcc/gengtype-lex.l  (revision 176740)
+++ gcc/gengtype-lex.l  (working copy)
@@ -22,7 +22,11 @@ along with GCC; see the file COPYING3.
 %option noinput
 
 %{
+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 
 #define malloc xmalloc
Index: gcc/gengtype-parse.c
===
--- gcc/gengtype-parse.c(revision 176740)
+++ gcc/gengtype-parse.c(working copy)
@@ -17,7 +17,11 @@
along with GCC; see the file COPYING3.  If not see
http://www.gnu.org/licenses/.  */
 
+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include gengtype.h
 
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 176741)
+++ gcc/Makefile.in (working copy)
@@ -192,6 +192,7 @@ GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $($(@D
 # be subject to -Werror:
 # flex output may yield harmless no previous prototype warnings
 build/gengtype-lex.o-warn = -Wno-error
+gengtype-lex.o-warn = -Wno-error
 # mips-tfile.c contains -Wcast-qual warnings.
 mips-tfile.o-warn = -Wno-error
 expmed.o-warn = -Wno-error
@@ -566,8 +567,12 @@ libexecdir = @libexecdir@
 libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
 # Directory in which the compiler finds executables
 libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
-# Directory in which plugin headers are installed
-plugin_includedir = $(libsubdir)/plugin/include
+# Directory in which all plugin resources are installed
+plugin_resourcesdir = $(libsubdir)/plugin
+ # Directory in which plugin headers are installed
+plugin_includedir = $(plugin_resourcesdir)/include
+# Directory in which plugin specific executables are installed
+plugin_bindir = $(libexecsubdir)/plugin
 # Used to produce a relative $(gcc_tooldir) in gcc.o
 unlibsubdir = ../../..
 # $(prefix), expressed as a path relative to $(libsubdir).
@@ -1531,8 +1536,8 @@ MOSTLYCLEANFILES = insn-flags.h insn-con
  $(EXTRA_PARTS) $(EXTRA_PROGRAMS) gcc-cross$(exeext) \
  $(SPECS) collect2$(exeext) lto-wrapper$(exeext) \
  gcov-iov$(build_exeext) gcov$(exeext) gcov-dump$(exeext) \
- *.[0-9][0-9].* *.[si] *-checksum.c libbackend.a libcommon-target.a

Re: [GCC-MELT-152] [MELT] Add a few tree primitives

2011-08-03 Thread Romain Geissler
Hi

2011/8/2 Basile Starynkevitch bas...@starynkevitch.net:
 On Tue, 2 Aug 2011 19:13:04 +0200
 Romain Geissler romain.geiss...@gmail.com wrote:
  You should build MELT in an empty build tree. Please give us the log file 
  of your make
  (don't use make -j, only a sequential make).

 Ok, i'll send you that tomorrow. Tell me if you want that i explore this 
 issue on my configuration.

 Yes please. I don't understand why on my system the builds go till 
 melt-stage3 while on
 Pierre's machine it fails before melt-stage2, and we looked together (by IRC) 
 several
 hours.

 Cheers

 PS Being on vacation, I probably won't MELT much tomorrow :-)


 --
 Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
 email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
 8, rue de la Faiencerie, 92340 Bourg La Reine, France
 *** opinions {are only mine, sont seulement les miennes} ***

 --
 Message from the http://groups.google.com/group/gcc-melt group.
 About GCC MELT http://gcc-melt.org/ a high level domain specific language to 
 code extensions to the Gnu Compiler Collection


I've made a few changes so that Melt bootstraps. But it still fails at
the final check-melt-runtime for a simple reason: Melt won't load
modules as we don't give it the melt-workdir where all *.so reside.
I realized that all those recent changes had made the melt-modules
directory completely useless as you always look for
my-module.MD5.FLAVOR.so that are in melt-workdir, and bypass the
melt-modules symlinks. I don't really know what exact behavior you are
expecting from the melt-modules, melt-workdir and melt-tempdir
directories so i don't really know how to correct the issue.

Find attached the log for check-melt-runtime, but it might not be
useful, i already gave you the reason of the error.

Romain


Melt-0.9-build.diff
Description: Binary data


Melt-0.9-build.Changelog
Description: Binary data


melt-check-runtime.log
Description: Binary data


Re: [MELT] split_string_* functions now take a value

2011-08-02 Thread Romain Geissler
Ping for Pierre !

2011/7/28 Romain Geissler romain.geiss...@gmail.com:
 Hi,

 I changed the argument type for the cs argument in split_string functions.
 Indeed, there is no way to access the boxed string from a value, and sometimes
 we can't avoid working with boxed strings. As we can box a :cstring in a 
 value,
 split_string_* functions are usable in all cases.

 Find attach the patch. Please note that it is a git patch, thus it should be
 applied with git-apply or git-am.

 Romain.



Re: [GCC-MELT-136] Re: [MELT] split_string_* functions now take a value

2011-08-02 Thread Romain Geissler
2011/8/2 Basile Starynkevitch bas...@starynkevitch.net:
 Please use capitals for macrovariables in
 macrostrings

Ok.

Can i have more details about that: is it just a Melt convention or is
it an implementation requirement (in other word, does melt awaits
macrovariables to be upper case ?)

Romain


Re: [GCC-MELT-137] Re: [MELT] split_string_* functions now take a value

2011-08-02 Thread Romain Geissler
Here is the fix git patch.


2011/8/2 Basile Starynkevitch bas...@starynkevitch.net:
 On Tue, 2 Aug 2011 10:46:38 +0200
 Romain Geissler romain.geiss...@gmail.com wrote:

 2011/8/2 Basile Starynkevitch bas...@starynkevitch.net:
  Please use capitals for macrovariables in
  macrostrings

 Ok.

 Can i have more details about that: is it just a Melt convention or is
 it an implementation requirement (in other word, does melt awaits
 macrovariables to be upper case ?)


 Just a coding (social) convention. Macrovariables are very important, and my 
 editor
 (emacs) and mode (lisp-mode) don't highlight them.

 Since macrovariables are really MELT symbols, their case don't matter (the 
 MELT reader
 force them to upper cases). But they are more human-readable in upper cases.

 Cheers.

 --
 Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
 email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
 8, rue de la Faiencerie, 92340 Bourg La Reine, France
 *** opinions {are only mine, sont seulement les miennes} ***

From 3e9b3fbbc25634a1f2e0b2b2e1a13c0e3927be31 Mon Sep 17 00:00:00 2001
From: Romain Geissler romain.geiss...@st.com
Date: Thu, 28 Jul 2011 12:43:59 +0200
Subject: [PATCH] split_string_* functions now require a value string instead
 of a :cstring.

---
 gcc/melt/warmelt-base.melt   |   24 
 gcc/melt/warmelt-outobj.melt |4 ++--
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/gcc/melt/warmelt-base.melt b/gcc/melt/warmelt-base.melt
index 8a6ff9d..3b068db 100644
--- a/gcc/melt/warmelt-base.melt
+++ b/gcc/melt/warmelt-base.melt
@@ -570,25 +570,25 @@ an integer $I if $I is lower than $N.}#
   #{(meltgc_string_hex_md5sum_file_sequence ((melt_ptr_t) $PATHSEQ))}#)
 
 
-(defprimitive split_string_space (dis :cstring cs) :value
-  :doc #{Split a cstring $CS into a list of space separated strings of
+(defprimitive split_string_space (dis s) :value
+  :doc #{Split a string value $S into a list of space separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ' ', (melt_ptr_t) $dis)}#)
+#{meltgc_new_split_string (melt_string_str ($S), ' ', (melt_ptr_t) $DIS)}#)
 
-(defprimitive split_string_comma (dis :cstring cs) :value
-  :doc #{Split a cstring $CS into a list of comma separated strings of
+(defprimitive split_string_comma (dis s) :value
+  :doc #{Split a string value $S into a list of comma separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ',', (melt_ptr_t) $dis)}#)
+#{meltgc_new_split_string (melt_string_str ($S), ',', (melt_ptr_t) $DIS)}#)
 
-(defprimitive split_string_colon (dis :cstring cs) :value
-  :doc #{Split a cstring $CS into a list of colon separated strings of
+(defprimitive split_string_colon (dis s) :value
+  :doc #{Split a string value $S into a list of colon separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ':', (melt_ptr_t)$dis)}#)
+#{meltgc_new_split_string (melt_string_str ($S), ':', (melt_ptr_t) $DIS)}#)
 
-(defprimitive split_string_equal (dis :cstring cs) :value
-  :doc #{Split a cstring $CS into a list of equal separated strings of
+(defprimitive split_string_equal (dis s) :value
+  :doc #{Split a string value $S into a list of equal separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, '=', (melt_ptr_t)$dis)}#)
+#{meltgc_new_split_string (melt_string_str ($S), '=', (melt_ptr_t) $DIS)}#)
 
 ;;; convert a strbuf into a string
 (defprimitive strbuf2string (dis sbuf) :value
diff --git a/gcc/melt/warmelt-outobj.melt b/gcc/melt/warmelt-outobj.melt
index dd1cdde..df4cf06 100644
--- a/gcc/melt/warmelt-outobj.melt
+++ b/gcc/melt/warmelt-outobj.melt
@@ -4671,7 +4671,7 @@ has basic debug support thru debug_msg, assert_msg...
 	 (inarg (cond ( progarg 
 			(make_stringconst discr_string progarg))
 		  ( progarglist
-			 (split_string_comma discr_string progarglist)
+			 (split_string_comma discr_string (make_stringconst discr_string progarglist))
 			)
 		  (:else
 		   (errormsg_plain invalid arg or arglist to translateinit mode)
@@ -5800,7 +5800,7 @@ has basic debug support thru debug_msg, assert_msg...
   (let ( 
 	(parmodenv (parent_module_environment))
 	(curenv (if moduldata moduldata initial_environment))
-	(arglist (split_string_comma discr_string (melt_argument arglist)))
+	(arglist (split_string_comma discr_string (make_stringconst discr_string (melt_argument arglist
 	(outarg (make_stringconst discr_string (melt_argument output)))
 	(rlist (make_list discr_list))
 	(mdinfo 
-- 
1.7.6



[PLUGIN] Install c-tree.h header

2011-08-02 Thread Romain Geissler
Hi,

For now, plugins can't compare types. This patch allows
c-tree.h to be installed as a plugin header, allowing
plugins to see comptypes (among other things).

Romain Geissler


2011-08-02  Romain Geissler  romain.geiss...@gmail.com

* Makefile.in (PLUGIN_HEADERS): Add C_TREE_H.


Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 176741)
+++ gcc/Makefile.in (working copy)
@@ -4584,7 +4584,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
   $(GGC_H) $(TREE_DUMP_H) $(PRETTY_PRINT_H) $(OPTS_H) $(PARAMS_H) plugin.def \
   $(tm_file_list) $(tm_include_list) $(tm_p_file_list) $(tm_p_include_list) \
   $(host_xm_file_list) $(host_xm_include_list) $(xm_include_list) \
-  intl.h $(PLUGIN_VERSION_H) $(DIAGNOSTIC_H) \
+  intl.h $(PLUGIN_VERSION_H) $(DIAGNOSTIC_H) ${C_TREE_H} \
   $(C_COMMON_H) c-family/c-objc.h $(C_PRETTY_PRINT_H) \
   tree-iterator.h $(PLUGIN_H) $(TREE_FLOW_H) langhooks.h incpath.h debug.h \
   $(EXCEPT_H) tree-ssa-sccvn.h real.h output.h $(IPA_UTILS_H) \


[MELT] Add a few tree primitives

2011-08-02 Thread Romain Geissler
Hi,

I added a few primitives about trees, plus a string_to_long
conversion primitive and a foreach_pair_between iterator
that allows to iterate between two pairs of the same list (and
thus iterate on sublist).

Note: again, it's a git patch for Pierre until Basil returns.

Romain


0001-Add-a-few-functions.Changelog
Description: Binary data
From a4d3037f8b0c032f2ba56b89a35f41fe7939d75a Mon Sep 17 00:00:00 2001
From: Romain Geissler romain.geiss...@st.com
Date: Tue, 2 Aug 2011 16:55:02 +0200
Subject: [PATCH] Add a few functions.

---
 gcc/melt/warmelt-first.melt |   28 +
 gcc/melt/xtramelt-ana-base.melt |   51 +++
 2 files changed, 79 insertions(+), 0 deletions(-)

diff --git a/gcc/melt/warmelt-first.melt b/gcc/melt/warmelt-first.melt
index ef8affd..33383dc 100644
--- a/gcc/melt/warmelt-first.melt
+++ b/gcc/melt/warmelt-first.melt
@@ -1162,6 +1162,12 @@ an integer $I if $I is greater than $N.}#
   :doc #{Test that value string $S1 is greater than $S2.}#
   #{melt_string_less((melt_ptr_t)($s2), (melt_ptr_t)($s1))}#)
 
+(defprimitive string_to_long (string) :long
+	:doc #{Read a string value and returns the corresponding
+	long stuff. 0 is returned if an error occurs while reading.}#
+	#{
+		atol(melt_string_str($string))
+	}#)
 
 
 
@@ -3225,6 +3231,26 @@ nil.}#
 
 
 
+;;; citerator on pairs
+(defciterator foreach_pair_between
+  (start_pair end_pair) ;start formals 
+  eachpair ;state
+  (curpair curcomp) ;local formals
+  :doc #{The $FOREACH_PAIR_BETWEEN iterator goes between two (linked) pairs,
+  given by the start formal $START_PAIR and $END_PAIR. Local formals are $CURPAIR,
+  bound to the current pair, and $CURCOMP, bound to the current component within
+  the pair.}#
+   #{/* start $eachpair */
+   for ($curpair = $start_pair;
+	melt_magic_discr($curpair) == MELTOBMAG_PAIR;
+$curpair = melt_pair_tail($curpair)) {
+	$curcomp = melt_pair_head($curpair); }#
+   #{
+  if ($curpair == $end_pair) {
+ break;
+  }
+   } /* end $eachpair */}#
+)
 
 ;;; citerator on lists
 (defciterator foreach_in_list 
@@ -4085,6 +4111,7 @@ also $CLASS_ANY_BINDING and $CLASS_ENVIRONMENT.}#
  shortbacktrace_dbg
  string
  string
+ string_to_long
  stringconst2val
  the_meltcallcount
  the_callcount
@@ -4207,6 +4234,7 @@ also $CLASS_ANY_BINDING and $CLASS_ENVIRONMENT.}#
 
 ;; export the citerators  cmatchers defined above
 (export_values
+ foreach_pair_between
  foreach_in_list
  foreach_in_mapobject
  foreach_in_mapstring
diff --git a/gcc/melt/xtramelt-ana-base.melt b/gcc/melt/xtramelt-ana-base.melt
index 34afcf2..af29fde 100644
--- a/gcc/melt/xtramelt-ana-base.melt
+++ b/gcc/melt/xtramelt-ana-base.melt
@@ -1494,6 +1494,51 @@
 (defprimitive tree_uid (:tree tr) :long
   #{(($tr) ? (long) DECL_UID($tr) : NULL)}#)
 
+(defprimitive tree_chain_prepend (:tree purpose value chain) :tree
+	:doc #{Create a new TREE_LIST node with $PURPOSE and $VALUE trees
+	and chain it at the begining of $CHAIN. Returns the newly created
+	chain.}#
+	#{
+		tree_cons ($PURPOSE, $VALUE, $CHAIN)
+	}#)
+
+(defprimitive tree_chain_append (:tree purpose value chain) :tree
+	:doc #{Create a new TREE_LIST node with $PURPOSE and $VALUE trees
+	and chain it at the end of $CHAIN. Returns the newly created
+	chain (different from $CHAIN if $CHAIN is NULL_TREE).}#
+	#{
+		chainon ($CHAIN, tree_cons ($PURPOSE, $VALUE, NULL_TREE))
+	}#)
+
+(defprimitive tree_chain_join (:tree chain1 chain2) :tree
+	:doc #{Append $CHAIN2 to $CHAIN1 and returns the newly created
+	chain (different from $CHAIN1 if $CHAIN1 is NULL_TREE).}#
+	#{
+		chainon ($CHAIN1, $CHAIN2)
+	}#)
+
+(defprimitive build_identifier_tree (name) :tree
+	:doc #{Create and returns a new IDENTIFIER_NODE tree whose
+	name is $NAME.}#
+	#{
+		get_identifier (melt_string_str ($NAME))
+	}#)
+
+(defprimitive build_string_tree (string_value) :tree
+	:doc #{Create and returns a new STRING_CST tree whose
+	value is $STRING_VALUE.}#
+	#{
+		build_string (strlen (melt_string_str ($STRING_VALUE)), melt_string_str ($STRING_VALUE))
+	}#)
+
+(defprimitive build_int_tree (int_value) :tree
+	:doc #{Create and returns a new INTEGER_CST tree whose
+	value is $INT_VALUE and type is the default language
+	integer type.}#
+	#{
+		build_int_cst (integer_type_node, (int)melt_get_int ($INT_VALUE))
+	}#)
+
 
 
 
@@ -3409,6 +3454,9 @@ and discriminant $DIS, usually $DISCR_MIXED_LOCATION.}#
  basicblock_nb_succ
  basicblock_phinodes
  basicblock_single_succ 
+ build_identifier_tree
+ build_int_tree
+ build_string_tree
  cfun_decl
  cfun_gimple_body
  cfun_has_cfg
@@ -3656,6 +3704,9 @@ and discriminant $DIS, usually $DISCR_MIXED_LOCATION.}#
  tree_array_ref_full
  tree_array_type
  tree_block
+ tree_chain_append
+ tree_chain_join
+ tree_chain_prepend
  tree_component_ref
  tree_component_ref_full
  tree_component_ref_typed
-- 
1.7.6



Re: [GCC-MELT-150] [MELT] Add a few tree primitives

2011-08-02 Thread Romain Geissler

Le 2 août 2011 à 18:38, Basile Starynkevitch a écrit :

 On Tue, 2 Aug 2011 17:02:05 +0200
 Romain Geissler romain.geiss...@gmail.com wrote:
 
 Hi,
 
 I added a few primitives about trees, plus a string_to_long
 conversion primitive and a foreach_pair_between iterator
 that allows to iterate between two pairs of the same list (and
 thus iterate on sublist).
 
 Note: again, it's a git patch for Pierre until Basil returns.
 
 I'm still near Paris for a few days.
 
 I applied it to the MELT branch.
 Transmitting file data ...
 Committed revision 177195.
 
 Romain, could you try to compile the latest MELT branch, please. I'm able to 
 build it till
 MELT stage3, but Pierre is not able to do that ( we spent several hours 
 understanding
 why without success). It does not build yet past xtramelt*.melt files (and it 
 cannot be
 installed). 

I tried to built two different revision this afternoon, each time with an empty 
build directory, and none worked (same error as Pierre got, it stops at Melt 
stage 1). IIRC the last one was at revision **162 or something near this one. I 
do fully bootstrap GCC unlike you, but the error occurs at GCC stage 1, so GCC 
bootstrapping might not be the cause.

 
 You should build MELT in an empty build tree. Please give us the log file of 
 your make
 (don't use make -j, only a sequential make).

Ok, i'll send you that tomorrow. Tell me if you want that i explore this issue 
on my configuration.


 Cheers.
 
 
 -- 
 Basile STARYNKEVITCH http://starynkevitch.net/Basile/
 email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
 8, rue de la Faiencerie, 92340 Bourg La Reine, France
 *** opinions {are only mine, sont seulement les miennes} ***
 
 -- 
 Message from the http://groups.google.com/group/gcc-melt group.
 About GCC MELT http://gcc-melt.org/ a high level domain specific language to 
 code extensions to the Gnu Compiler Collection



Re: [PLUGIN] compile and install gengtype, install gtype.state

2011-08-01 Thread Romain Geissler
ping

2011/7/26 Romain Geissler romain.geiss...@gmail.com:
 2011/7/25 Jakub Jelinek ja...@redhat.com:
 On Mon, Jul 25, 2011 at 09:10:55PM +0200, Romain Geissler wrote:
  2011-07-18  Romain Geissler  romain.geiss...@gmail.com
 
      * gengtype-state.c (#include bconfig.h): Include bconfig.h
      if GENERATOR_FILE is defined, config.h otherwise.

 Still not right, this should have been
        * gengtype-state.c: Include bconfig.h if GENERATOR_FILE is
        define, config.h otherwise.

      * gengtype.c: Likewise.
      * gengtype-lex.l: Likewise.
      * gengtype-parse.c: Likewise.

      * Makefile.in (gengtype): Compile and install for host when
      $enable_plugins is set to yes.
      (gtype.state): Install when $enable_plugins is set to yes.

 And this should list all the Makefile.in goals you've changed, added etc.

 Ok with those changes.

        Jakub


 Is it OK with this changelog ? If yes, can someone apply the patch,
 as i don't have write access.

 Romain Geissler.

 2011-07-18  Romain Geissler  romain.geiss...@gmail.com

        * gengtype-state.c: Include bconfig.h if
        GENERATOR_FILE is defined, config.h otherwise.
        * gengtype.c: Likewise.
        * gengtype-lex.l: Likewise.
        * gengtype-parse.c: Likewise.
        * Makefile.in (gengtype-lex.o-warn): New variable.
        (plugindir): Likewise.
        (plugin_bindir): Likewise.
        (plugin_includedir): Use $(plugindir) as prefix base.
        (MOSTLYCLEANFILES): Add gengtype$(exeext).
        (native): Depend on gengtype$(exeext) is $enable_plugin
        is set to yes.
        (gtype.state): Depend on s-gtype. Use temporary file.
        (gengtype-lex.o): New rule.
        (gengtype-parse.o): Likewise.
        (gengtype-state.o): Likewise.
        (gengtype$(exeext)): Likewise.
        (install-gengtype): Likewise.
        (gengtype.o): Likewise.
        (build/gengtype.o): Depend on version.h.
        (build/gengtype-state): Depend on double-int.h, version.h,
        $(HASHTAB_H), $(OBSTACK_H), $(XREGEX_H) and build/errors.o.
        (install-plugin): Depend on install-gengtype.


 Index: gcc/gengtype-state.c
 ===
 --- gcc/gengtype-state.c        (revision 175907)
 +++ gcc/gengtype-state.c        (working copy)
 @@ -23,7 +23,11 @@
    and Basile Starynkevitch bas...@starynkevitch.net
  */

 +#ifdef GENERATOR_FILE
  #include bconfig.h
 +#else
 +#include config.h
 +#endif
  #include system.h
  #include errors.h    /* For fatal.  */
  #include double-int.h
 Index: gcc/gengtype.c
 ===
 --- gcc/gengtype.c      (revision 175907)
 +++ gcc/gengtype.c      (working copy)
 @@ -18,7 +18,11 @@
    along with GCC; see the file COPYING3.  If not see
    http://www.gnu.org/licenses/.  */

 +#ifdef GENERATOR_FILE
  #include bconfig.h
 +#else
 +#include config.h
 +#endif
  #include system.h
  #include errors.h            /* for fatal */
  #include getopt.h
 Index: gcc/gengtype-lex.l
 ===
 --- gcc/gengtype-lex.l  (revision 175907)
 +++ gcc/gengtype-lex.l  (working copy)
 @@ -22,7 +22,11 @@ along with GCC; see the file COPYING3.
  %option noinput

  %{
 +#ifdef GENERATOR_FILE
  #include bconfig.h
 +#else
 +#include config.h
 +#endif
  #include system.h

  #define malloc xmalloc
 Index: gcc/gengtype-parse.c
 ===
 --- gcc/gengtype-parse.c        (revision 175907)
 +++ gcc/gengtype-parse.c        (working copy)
 @@ -17,7 +17,11 @@
    along with GCC; see the file COPYING3.  If not see
    http://www.gnu.org/licenses/.  */

 +#ifdef GENERATOR_FILE
  #include bconfig.h
 +#else
 +#include config.h
 +#endif
  #include system.h
  #include gengtype.h

 Index: gcc/Makefile.in
 ===
 --- gcc/Makefile.in     (revision 175907)
 +++ gcc/Makefile.in     (working copy)
 @@ -192,6 +192,7 @@ GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $($(@D
  # be subject to -Werror:
  # flex output may yield harmless no previous prototype warnings
  build/gengtype-lex.o-warn = -Wno-error
 +gengtype-lex.o-warn = -Wno-error
  # mips-tfile.c contains -Wcast-qual warnings.
  mips-tfile.o-warn = -Wno-error
  expmed.o-warn = -Wno-error
 @@ -566,8 +567,12 @@ libexecdir = @libexecdir@
  libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
  # Directory in which the compiler finds executables
  libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
 -# Directory in which plugin headers are installed
 -plugin_includedir = $(libsubdir)/plugin/include
 +# Directory in which all plugin resources are installed
 +plugindir = $(libsubdir)/plugin
 + # Directory in which plugin headers are installed
 +plugin_includedir = $(plugindir)/include
 +# Directory in which plugin specific executables are installed
 +plugin_bindir = $(plugindir)/bin
  # Used

[MELT] split_string_* functions now take a value

2011-07-28 Thread Romain Geissler
Hi,

I changed the argument type for the cs argument in split_string functions.
Indeed, there is no way to access the boxed string from a value, and sometimes
we can't avoid working with boxed strings. As we can box a :cstring in a value,
split_string_* functions are usable in all cases.

Find attach the patch. Please note that it is a git patch, thus it should be
applied with git-apply or git-am.

Romain.


0001-split_string_-functions-now-require-a-value-string-i.Changelog
Description: Binary data
From 41290f00ee0cb6bdeaf2254b0d6a25ebddf23a65 Mon Sep 17 00:00:00 2001
From: Romain Geissler romain.geiss...@st.com
Date: Thu, 28 Jul 2011 12:43:59 +0200
Subject: [PATCH] split_string_* functions now require a value string instead
 of a :cstring.

---
 gcc/melt/warmelt-base.melt   |   16 
 gcc/melt/warmelt-outobj.melt |4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/gcc/melt/warmelt-base.melt b/gcc/melt/warmelt-base.melt
index 8a6ff9d..c7eca3e 100644
--- a/gcc/melt/warmelt-base.melt
+++ b/gcc/melt/warmelt-base.melt
@@ -570,25 +570,25 @@ an integer $I if $I is lower than $N.}#
   #{(meltgc_string_hex_md5sum_file_sequence ((melt_ptr_t) $PATHSEQ))}#)
 
 
-(defprimitive split_string_space (dis :cstring cs) :value
+(defprimitive split_string_space (dis cs) :value
   :doc #{Split a cstring $CS into a list of space separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ' ', (melt_ptr_t) $dis)}#)
+#{meltgc_new_split_string(melt_string_str($cs), ' ', (melt_ptr_t) $dis)}#)
 
-(defprimitive split_string_comma (dis :cstring cs) :value
+(defprimitive split_string_comma (dis cs) :value
   :doc #{Split a cstring $CS into a list of comma separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ',', (melt_ptr_t) $dis)}#)
+#{meltgc_new_split_string(melt_string_str($cs), ',', (melt_ptr_t) $dis)}#)
 
-(defprimitive split_string_colon (dis :cstring cs) :value
+(defprimitive split_string_colon (dis cs) :value
   :doc #{Split a cstring $CS into a list of colon separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, ':', (melt_ptr_t)$dis)}#)
+#{meltgc_new_split_string(melt_string_str($cs), ':', (melt_ptr_t)$dis)}#)
 
-(defprimitive split_string_equal (dis :cstring cs) :value
+(defprimitive split_string_equal (dis cs) :value
   :doc #{Split a cstring $CS into a list of equal separated strings of
 discriminant $DIS.}#
-#{meltgc_new_split_string($cs, '=', (melt_ptr_t)$dis)}#)
+#{meltgc_new_split_string(melt_string_str($cs), '=', (melt_ptr_t)$dis)}#)
 
 ;;; convert a strbuf into a string
 (defprimitive strbuf2string (dis sbuf) :value
diff --git a/gcc/melt/warmelt-outobj.melt b/gcc/melt/warmelt-outobj.melt
index dd1cdde..df4cf06 100644
--- a/gcc/melt/warmelt-outobj.melt
+++ b/gcc/melt/warmelt-outobj.melt
@@ -4671,7 +4671,7 @@ has basic debug support thru debug_msg, assert_msg...
 	 (inarg (cond ( progarg 
 			(make_stringconst discr_string progarg))
 		  ( progarglist
-			 (split_string_comma discr_string progarglist)
+			 (split_string_comma discr_string (make_stringconst discr_string progarglist))
 			)
 		  (:else
 		   (errormsg_plain invalid arg or arglist to translateinit mode)
@@ -5800,7 +5800,7 @@ has basic debug support thru debug_msg, assert_msg...
   (let ( 
 	(parmodenv (parent_module_environment))
 	(curenv (if moduldata moduldata initial_environment))
-	(arglist (split_string_comma discr_string (melt_argument arglist)))
+	(arglist (split_string_comma discr_string (make_stringconst discr_string (melt_argument arglist
 	(outarg (make_stringconst discr_string (melt_argument output)))
 	(rlist (make_list discr_list))
 	(mdinfo 
-- 
1.7.6



[Melt] Fix foreach_edge_bb_precs

2011-07-25 Thread Romain Geissler
Hello,

This iteratoc won't work because of a little typo error (the previous
edge field is preDs and not preCs).
To avoid future errors, i apply the global /precs/preds/ change (and
thus the iterator is renamed).

Romain Geissler


Changelog
Description: Binary data


foreach_edge_bb_preds.diff
Description: Binary data


Re: [PATCH] Fix configure --with-cloog

2011-07-25 Thread Romain Geissler
Le 6 juil. 2011 à 11:04, Romain Geissler a écrit :

 Hello
 
 This patch fix an issue while building with cloog and gmp installed in
 a custom separate directories.
 
 How to reproduce :
 - Make sure you've installed cloog and gmp in separate directories
 (ie ${WITH-CLOOG-PATH}/lib doesn't contain libgmp)
 - Make sure neither gmp nor cloog is not installed in a directory
 searched by default by your linker when looking for libs.
 - Launch configure script with both --with-gmp and --with-cloog
 switch properly set
 
 This result in an unexpected error while configuring: error: Unable to
 find a usable CLooG.
 
 
 2011-07-06  Romain Geissler  romain.geiss...@gmail.com
 
   * configure: Add $gmplibs to cloog $LDFLAGS
 
 Index: configure
 ===
 --- configure   (revision 175709)
 +++ configure   (working copy)
 @@ -5713,7 +5713,7 @@ if test x$with_cloog != xno; then
 
 CFLAGS=${CFLAGS} ${clooginc} ${gmpinc}
   CPPFLAGS=${CPPFLAGS} ${_cloogorginc}
 -  LDFLAGS=${LDFLAGS} ${clooglibs}
 +  LDFLAGS=${LDFLAGS} ${clooglibs} ${gmplibs}
 
   case $cloog_backend in
 ppl-legacy)

Ping !


Re: [PLUGIN] compile and install gengtype, install gtype.state

2011-07-25 Thread Romain Geissler
Le 19 juil. 2011 à 14:41, Romain Geissler a écrit :

 2011/7/19 Jakub Jelinek ja...@redhat.com:
 On Tue, Jul 19, 2011 at 02:26:32PM +0200, Romain Geissler wrote:
 2011-07-18  Romain Geissler  romain.geiss...@gmail.com
 
   * gengtype-state.c (#include bconfig.h): include bconfig.h
   if GENERATOR_FILE is defined, config.h otherwise.
   * gengtype.c: Likewise.
   * gengtype-lex.l: Likewise.
   * gengtype-parse.c: Likewise.
   * Makefile.in (gengtype): compile and install for host when
   $enable_plugins is set to yes.
   (gtype.state): install when $enable_plugins is set to yes.
 
 s/: include/: Include/;s/: compile/: Compile/;s/: install/: Install/
 
Jakub
 
 
 Fixed
 
 Romain Geissler
 
 2011-07-18  Romain Geissler  romain.geiss...@gmail.com
 
   * gengtype-state.c (#include bconfig.h): Include bconfig.h
   if GENERATOR_FILE is defined, config.h otherwise.
   * gengtype.c: Likewise.
   * gengtype-lex.l: Likewise.
   * gengtype-parse.c: Likewise.
   * Makefile.in (gengtype): Compile and install for host when
   $enable_plugins is set to yes.
   (gtype.state): Install when $enable_plugins is set to yes.


Ping !


[Melt] Add some includes to melt-run.proto.h

2011-07-21 Thread Romain Geissler
Hi,

I added a few includes i need to define some new primitives.

Basile, i included two c-family/*.h files, but be aware that currently
GCC does not install this headers in the c-family directory but in the
directly in the plugin/include root directory with all other headers. I posted
a patch some times ago to solve that (because it breaks includes of
C++ plugin headers) for the trunk. Unfortunately, the patch hasn't been
reviewed yet. See
http://old.nabble.com/-PLUGIN--c-family-files-installation-td32038394.html
Once again, Debian maintainers applied a similar patch for a long time
and thus theses files are in the c-family directory (but only for Debian
users).

So i don't know if you should apply the patch as is or remove
the c-family/ prefix in the includes.

Romain Geissler

gcc/

2011-07-21  Romain Geissler  romain.geiss...@gmail.com

* melt-run.proto.h: Include c-family/c-pragma.h,
c-family/c-pretty-print.h, cpplib.h and langhooks.h.



Index: gcc/melt-run.proto.h
===
--- gcc/melt-run.proto.h(revision 176395)
+++ gcc/melt-run.proto.h(working copy)
@@ -52,6 +52,8 @@ along with GCC; see the file COPYING3.
 #include timevar.h
 #include ggc.h
 #include cgraph.h
+#include c-family/c-pragma.h
+#include c-family/c-pretty-print.h
 #include diagnostic.h
 #include flags.h
 #include toplev.h
@@ -61,6 +63,8 @@ along with GCC; see the file COPYING3.
 #include prefix.h
 #include md5.h
 #include cppdefault.h
+#include cpplib.h
+#include langhooks.h


 /* MELT specific includes */


Re: [Melt] Add some includes to melt-run.proto.h

2011-07-21 Thread Romain Geissler
I have just updated to the latest svn revision, and it seems you
forgot to #include cpplib.h and langhooks.h.

Note about the c-family issue, you will be allowed to apply it (in the
trunk, and then in the melt branch) in 24 hours unless the plugin
maintainer block this one. I can't do it by myself as i don't have
write access to the svn repo.
See Joseph S. Myers post at
http://old.nabble.com/-PLUGIN--c-family-files-installation-td32038394.html

Romain Geissler


[Melt] Fix translatequickly mode installation

2011-07-19 Thread Romain Geissler
Hi,

I corrected a minor error (translatedebug_mode get installed instead
of translatequickly_mode).

Romain Geissler


Changelog
Description: Binary data


translatequickly_mode.diff
Description: Binary data


Re: [PLUGIN] compile and install gengtype, install gtype.state

2011-07-19 Thread Romain Geissler
2011/7/19 Jakub Jelinek ja...@redhat.com:
 On Tue, Jul 19, 2011 at 02:26:32PM +0200, Romain Geissler wrote:
 2011-07-18  Romain Geissler  romain.geiss...@gmail.com

       * gengtype-state.c (#include bconfig.h): include bconfig.h
       if GENERATOR_FILE is defined, config.h otherwise.
       * gengtype.c: Likewise.
       * gengtype-lex.l: Likewise.
       * gengtype-parse.c: Likewise.
       * Makefile.in (gengtype): compile and install for host when
       $enable_plugins is set to yes.
       (gtype.state): install when $enable_plugins is set to yes.

 s/: include/: Include/;s/: compile/: Compile/;s/: install/: Install/

        Jakub


Fixed

Romain Geissler

2011-07-18  Romain Geissler  romain.geiss...@gmail.com

* gengtype-state.c (#include bconfig.h): Include bconfig.h
if GENERATOR_FILE is defined, config.h otherwise.
* gengtype.c: Likewise.
* gengtype-lex.l: Likewise.
* gengtype-parse.c: Likewise.
* Makefile.in (gengtype): Compile and install for host when
$enable_plugins is set to yes.
(gtype.state): Install when $enable_plugins is set to yes.


[Melt] Add coutput argument to translateto* modes

2011-07-19 Thread Romain Geissler
Hi,

Melt is creating annoying *.c files next to the .so module file, and i
just can no
longer handle temporary files polluting my final binary directory.
Here is a simple patch
that allow the user to give an explicit coutput file path in all
translateto* modes.

By the way, trying to reach the C sources files and checking their
checksum with the loaded
.so module just don't make sens to me. This task should be done by a
proper Makefile by
the plugin developer, not by Melt. Gcc won't tell you that your file.o
is outdated because
file.c has changed, there is no reason for melt to act otherwise. At
least, disable this behavior
by default and allow it through a custom parameter.

Romain Geissler


Changelog
Description: Binary data


couput.diff
Description: Binary data


Re: [PATCH] Fix configure --with-cloog

2011-07-18 Thread Romain Geissler
2011/7/11 Romain Geissler romain.geiss...@gmail.com:
 2011/7/6 Romain Geissler romain.geiss...@gmail.com:

 I forgot configure was a generated script. Here is the patch that fix
 it at the m4 macro level :


 2011-07-06  Romain Geissler  romain.geiss...@gmail.com

      * config/cloog.m4: Add $gmplibs to cloog $LDFLAGS
      * configure: Regenerate


 Index: config/cloog.m4
 ===
 --- config/cloog.m4     (revision 175907)
 +++ config/cloog.m4     (working copy)
 @@ -142,7 +142,7 @@ AC_DEFUN([CLOOG_FIND_FLAGS],
   dnl clooglibs  clooginc may have been initialized by CLOOG_INIT_FLAGS.
   CFLAGS=${CFLAGS} ${clooginc} ${gmpinc}
   CPPFLAGS=${CPPFLAGS} ${_cloogorginc}
 -  LDFLAGS=${LDFLAGS} ${clooglibs}
 +  LDFLAGS=${LDFLAGS} ${clooglibs} ${gmplibs}

   case $cloog_backend in
     ppl-legacy)


 Ping: It seems that little patch has been forgotten.
 Is ok for the trunk ?

 NB: I don't have write access to the trunk

 Romain Geissler


Ping !


Re: [PLUGIN] c-family files installation

2011-07-18 Thread Romain Geissler
2011/7/11 Matthias Klose d...@debian.org:
 On 07/11/2011 05:18 PM, Romain Geissler wrote:
 This patch add a new exception to the plugin header flattering strategy.
 c-family files can't be installed in the plugin include root directory as 
 some
 other files like cp/cp-tree.h will look for them in the c-family directory.

 Furthermore, i had to correct an include in c-pretty-print.h so that it
 looks for c-common.h in the c-family directory. That way, headers will
 work out of the box when compiling a plugin, there is no need for
 additional include directory.

 Builds and installs fine

 Ok for the trunk (i have no write access) ?

 looks ok (but I cannot approve it). Almost the same patch submitted at
 http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01461.html, but this chunk 
 unreviewed.

  Matthias


Hi

Is there something wrong with this patch ? Is it ok for the trunk ?

Romain Geissler


Re: plugin event for C/C++ declarations

2011-07-18 Thread Romain Geissler
2011/7/11 Romain Geissler romain.geiss...@gmail.com:
 2011/7/7 Diego Novillo dnovi...@google.com:
 OK.  This one fell through the cracks in my inbox.  Apologies.


 Diego.

 Hi,

 I don't have write access, can you please add the patch to the trunk ?

 Romain Geissler

Ping !


[PLUGIN] compile and install gengtype, install gtype.state

2011-07-18 Thread Romain Geissler
Hi,

This patch allows a third party plugin to define new GTY-ed types
by compiling and installing gengtype for host and installing gtype.state
in plugin_includedir.

Builds and installs fine on a x86_64 red hat.

Ok for the trunk ?

Romain Geissler

gcc/

2011-07-18  Romain Geissler  romain.geiss...@gmail.com

* gengtype-state.c (#include bconfig.h): #include config.h
with host CC
* gengtype.c: Likewise
* gengtype-lex.l: Likewise
* gengtype-parse.c: Likewise

* Makefile.in (gengtype): compile and install for host when
enable_plugins
(gtype.state): install when enable_plugins



Index: gcc/gengtype-state.c
===
--- gcc/gengtype-state.c(revision 175907)
+++ gcc/gengtype-state.c(working copy)
@@ -23,7 +23,11 @@
and Basile Starynkevitch bas...@starynkevitch.net
 */

+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include errors.h/* For fatal.  */
 #include double-int.h
Index: gcc/gengtype.c
===
--- gcc/gengtype.c  (revision 175907)
+++ gcc/gengtype.c  (working copy)
@@ -18,7 +18,11 @@
along with GCC; see the file COPYING3.  If not see
http://www.gnu.org/licenses/.  */

+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include errors.h/* for fatal */
 #include getopt.h
Index: gcc/gengtype-lex.l
===
--- gcc/gengtype-lex.l  (revision 175907)
+++ gcc/gengtype-lex.l  (working copy)
@@ -22,7 +22,11 @@ along with GCC; see the file COPYING3.
 %option noinput

 %{
+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h

 #define malloc xmalloc
Index: gcc/gengtype-parse.c
===
--- gcc/gengtype-parse.c(revision 175907)
+++ gcc/gengtype-parse.c(working copy)
@@ -17,7 +17,11 @@
along with GCC; see the file COPYING3.  If not see
http://www.gnu.org/licenses/.  */

+#ifdef GENERATOR_FILE
 #include bconfig.h
+#else
+#include config.h
+#endif
 #include system.h
 #include gengtype.h

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 175907)
+++ gcc/Makefile.in (working copy)
@@ -192,6 +192,7 @@ GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $($(@D
 # be subject to -Werror:
 # flex output may yield harmless no previous prototype warnings
 build/gengtype-lex.o-warn = -Wno-error
+gengtype-lex.o-warn = -Wno-error
 # mips-tfile.c contains -Wcast-qual warnings.
 mips-tfile.o-warn = -Wno-error
 expmed.o-warn = -Wno-error
@@ -566,8 +567,12 @@ libexecdir = @libexecdir@
 libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
 # Directory in which the compiler finds executables
 libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
-# Directory in which plugin headers are installed
-plugin_includedir = $(libsubdir)/plugin/include
+# Directory in which all plugin resources are installed
+plugindir = $(libsubdir)/plugin
+ # Directory in which plugin headers are installed
+plugin_includedir = $(plugindir)/include
+# Directory in which plugin specific executables are installed
+plugin_bindir = $(plugindir)/bin
 # Used to produce a relative $(gcc_tooldir) in gcc.o
 unlibsubdir = ../../..
 # $(prefix), expressed as a path relative to $(libsubdir).
@@ -1532,8 +1537,8 @@ MOSTLYCLEANFILES = insn-flags.h insn-con
  $(EXTRA_PARTS) $(EXTRA_PROGRAMS) gcc-cross$(exeext) \
  $(SPECS) collect2$(exeext) lto-wrapper$(exeext) \
  gcov-iov$(build_exeext) gcov$(exeext) gcov-dump$(exeext) \
- *.[0-9][0-9].* *.[si] *-checksum.c libbackend.a libcommon-target.a \
- libcommon.a libgcc.mk
+ gengtype$(exeext) *.[0-9][0-9].* *.[si] *-checksum.c libbackend.a \
+ libcommon-target.a libcommon.a libgcc.mk

 # Defined in libgcc2.c, included only in the static library.
 LIB2FUNCS_ST = _eprintf __gcc_bcmp
@@ -1825,6 +1830,10 @@ rest.encap: lang.rest.encap
 native: config.status auto-host.h build-@POSUB@ $(LANGUAGES) \
$(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(COLLECT2) lto-wrapper$(exeext)

+ifeq ($(enable_plugin),yes)
+native: gengtype$(exeext)
+endif
+
 # Define the names for selecting languages in LANGUAGES.
 c: cc1$(exeext)

@@ -3879,7 +3888,7 @@ ALL_GTFILES_H := $(sort $(GTFILES_H) $(G
 # write it out to a file (taking care not to do that in a way that
 # overflows a command line!) and then have gengtype read the file in.

-$(ALL_GTFILES_H) gtype-desc.c gtype-desc.h : s-gtype ; @true
+$(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gtype.state: s-gtype ; @true

 ### Common flags to gengtype [e.g. -v or -B backupdir]
 GENGTYPE_FLAGS=
@@ -3894,9 +3903,10 @@ s-gtype: build/gengtype$(build_exeext) $
 gtyp-input.list
 # First, parse all files and save a state

Re: [PATCH, MELT] Add PRE_GENERICIZE callback support in MELT

2011-07-15 Thread Romain Geissler
Le 15 juil. 2011 à 18:17, Pierre Vittet a écrit :

 Hello,
 
 The following patch add support for PLUGIN_PRE_GENERICIZE callback.
 
 The add_sysdata_pre_genericize patch add a field (sysdata_pre_genericize) in 
 initial system data, allowing to register a closure to be called on 
 PLUGIN_PRE_GENERICIZE event. This patch must be first applied and a make 
 warmelt-upgrade must be run in order to regenerate generated melt files.
 
 The add_pre_genericize_hook patch add a function (in melt-runtime.c) to be 
 called on PLUGIN_PRE_GENERICIZE, which call the closure 
 sysdata_pre_genericize defined by the users.
 
 Thanks
 
 Pierre Vittet
 add_sysdata_pre_genericize-176032.ChangeLogadd_sysdata_pre_genericize-176032.diffadd_pre_genericize_hook-176032.ChangeLogadd_pre_genericize_hook-176032.ChangeLog~

Great !

You forgot to attach the patch for melt-runtime.c (there is only the changelog)

I know your performing some simple static analysis, mostly based on matching 
some c source code patterns (check that there is a if (fopen_result) just after 
a fopen.

Is there a particular reason to do that as a pass (so at the gimple level) 
rather that doing it just after the function has been parsed (eg upon 
PLUGIN_PRE_GENERICIZE) ?


[MELT] Several build fix

2011-07-15 Thread Romain Geissler
Hello,

Here is a little patch that fix build on my red hat system. It should work for 
both the plugin and the branch version (although i could not generate the new 
plugin because upgrade-warmelt require unifdef that i don't have on my system, 
so the plugin version has not been tested directly from the branch source 
tarball).

Please check if it still work for you, i may have broken things !

(this includes

@Basile Do not read this until you're back from your vacation.
I've corrected the bug dealing with unfound c sources files to build existing 
module so files
I have also added a -Wno-error switch in the check-melt-runtime so that it 
doesn't break the whole build (as it uses -Werror by default on my system). But 
this should be only a temporary workaround, as you noticed some days 
warmelt-ana-simple detects bugs in the runtime, and this should be corrected. 
There is mostly meltgc_* functions that do no declare a MELT_ENTERFRAME. I 
don't really understand why and when there is a need for such, so i let you 
correct that. When it's done, do not forget to remove the -Wno-error switch.

The plugin version should now be a little bit more configurable thanks to  
variable ?= value assignements. In particular, we can use a custom gcc and not 
the one in PATH, and add some library includes thanks to LIBS_INCLUDEFLAGS 
(useful when ppl is not in the default include directory for example).

I will now try to patch the trunk to build twice and install gengtype when 
plugins are available.


build.diff
Description: Binary data


build.Changelog
Description: Binary data


Re: [MELT] Several build fix

2011-07-15 Thread Romain Geissler
Le 15 juil. 2011 à 19:25, Romain Geissler a écrit :

 Please check if it still work for you, i may have broken things !

Please try with clean installs (ie install gcc in a whole new directory for the 
branch or remove any previous melt related files for a plugin install).

 (this includes

This patch includes the previous one dealing with build issues from Pierre 
Vittet.



Re: [PATCH] Fix configure --with-cloog

2011-07-11 Thread Romain Geissler
2011/7/6 Romain Geissler romain.geiss...@gmail.com:

 I forgot configure was a generated script. Here is the patch that fix
 it at the m4 macro level :


 2011-07-06  Romain Geissler  romain.geiss...@gmail.com

      * config/cloog.m4: Add $gmplibs to cloog $LDFLAGS
      * configure: Regenerate


 Index: config/cloog.m4
 ===
 --- config/cloog.m4     (revision 175907)
 +++ config/cloog.m4     (working copy)
 @@ -142,7 +142,7 @@ AC_DEFUN([CLOOG_FIND_FLAGS],
   dnl clooglibs  clooginc may have been initialized by CLOOG_INIT_FLAGS.
   CFLAGS=${CFLAGS} ${clooginc} ${gmpinc}
   CPPFLAGS=${CPPFLAGS} ${_cloogorginc}
 -  LDFLAGS=${LDFLAGS} ${clooglibs}
 +  LDFLAGS=${LDFLAGS} ${clooglibs} ${gmplibs}

   case $cloog_backend in
     ppl-legacy)


Ping: It seems that little patch has been forgotten.
Is ok for the trunk ?

NB: I don't have write access to the trunk

Romain Geissler


Re: plugin event for C/C++ declarations

2011-07-11 Thread Romain Geissler
2011/7/7 Diego Novillo dnovi...@google.com:
 OK.  This one fell through the cracks in my inbox.  Apologies.


 Diego.

Hi,

I don't have write access, can you please add the patch to the trunk ?

Romain Geissler


Re: [PATCH] Remove call_expr_arg and call_expr_argp

2011-07-11 Thread Romain Geissler
2011/7/8 Richard Guenther richard.guent...@gmail.com:
 Ok.

 Thanks,
 Richard.


Hi,

I don't have write access, can you please add the patch to the trunk ?

Romain Geissler


[PLUGIN] c-family files installation

2011-07-11 Thread Romain Geissler
This patch add a new exception to the plugin header flattering strategy.
c-family files can't be installed in the plugin include root directory as some
other files like cp/cp-tree.h will look for them in the c-family directory.

Furthermore, i had to correct an include in c-pretty-print.h so that it
looks for c-common.h in the c-family directory. That way, headers will
work out of the box when compiling a plugin, there is no need for
additional include directory.

Builds and installs fine

Ok for the trunk (i have no write access) ?

Romain Geissler

gcc/c-family/
2011-07-11  Romain Geissler  romain.geiss...@gmail.com

 * c-pretty-print.h: Search c-common.h in c-family

gcc/
2011-07-11  Romain Geissler  romain.geiss...@gmail.com

 PR plugins/45348
 PR plugins/48425
 PR plugins/46577
 * Makefile.in: Do not flatten c-family directory
 when installing plugin headers


Index: gcc/c-family/c-pretty-print.h
===
--- gcc/c-family/c-pretty-print.h   (revision 175907)
+++ gcc/c-family/c-pretty-print.h   (working copy)
@@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.
 #define GCC_C_PRETTY_PRINTER

 #include tree.h
-#include c-common.h
+#include c-family/c-common.h
 #include pretty-print.h


Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 175907)
+++ gcc/Makefile.in (working copy)
@@ -4643,7 +4643,7 @@ s-header-vars: Makefile

 # Install the headers needed to build a plugin.
 install-plugin: installdirs lang.install-plugin s-header-vars
-# We keep the directory structure for files in config and .def files. All
+# We keep the directory structure for files in config or c-family and
.def files. All
 # other files are flattened to a single directory.
$(mkinstalldirs) $(DESTDIR)$(plugin_includedir)
headers=`echo $(PLUGIN_HEADERS) | tr ' ' '\012' | sort -u`; \
@@ -4656,7 +4656,7 @@ install-plugin: installdirs lang.install
  else continue; \
  fi; \
  case $$path in \
- $(srcdir)/config/* | $(srcdir)/*.def ) \
+ $(srcdir)/config/* | $(srcdir)/c-family/* | $(srcdir)/*.def ) \
base=`echo $$path | sed -e s|$$srcdirstrip/||`;; \
  *) base=`basename $$path` ;; \
  esac; \


[PATCH] Remove call_expr_arg and call_expr_argp

2011-07-08 Thread Romain Geissler
Hello,

This patch simply removes legacy call_expr_arg and call_expr_argp
declarations since these functions no longer have a defined body. Use
CALL_EXPR_ARG and CALL_EXPR_ARGP macros instead.

Build fine and no regression on x86_64.

2011-07-08  Romain Geissler  romain.geiss...@gmail.com

   * tree.h: Remove call_expr_arg and call_expr_argp



Index: gcc/tree.h
===
--- gcc/tree.h  (revision 175907)
+++ gcc/tree.h  (working copy)
@@ -5130,8 +5130,6 @@ extern bool commutative_ternary_tree_cod
 extern tree upper_bound_in_type (tree, tree);
 extern tree lower_bound_in_type (tree, tree);
 extern int operand_equal_for_phi_arg_p (const_tree, const_tree);
-extern tree call_expr_arg (tree, int);
-extern tree *call_expr_argp (tree, int);
 extern tree create_artificial_label (location_t);
 extern const char *get_name (tree);
 extern bool stdarg_p (const_tree);


Re: plugin event for C/C++ declarations

2011-07-07 Thread Romain Geissler
 On Tue, Dec 22, 2009 at 11:45 AM, Diego Novillo dnovi...@google.com wrote:
 On Tue, Dec 22, 2009 at 13:00, Brian Hackett bhackett1...@gmail.com wrote:
 Hi, this patch adds a new plugin event FINISH_DECL, which is invoked
 at every finish_decl in the C and C++ frontends. ?Previously there did
 not seem to be a way for a plugin to see the definition for a global
 that is never used in the input file, or the initializer for a global
 which is declared before a function but defined after. ?This event
 isn't restricted to just globals though, but also locals, fields, and
 parameters (C frontend only).

 Thanks for your patch. ?This will be great to fix
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 but we need to wait
 for your copyright assignment to go through before we can accept it.

 Hi, this is a patch from a few months ago which I was not able to get
 an assignment for.  The FSF has a personal copyright assignment for
 me, but I could not get one from my employer at the time, Stanford
 (according to Stanford's policies they would not claim copyright on
 this patch).  I now work for Mozilla, which (I understand) has a
 company wide copyright assignment.  Are there issues if I from scratch
 rewrite and resubmit a new patch?

 Original patch (9 new lines of code, doc change and new regression):

 http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01032.html

 Brian

Hi,

Once again, this is a ping for the long time proposed patch by Brian Hackett.
See last thread about this one here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00315.html

Find below the fixed patch for recent revision (changed
gcc/testsuite/g++.dg/plugin/decl_plugin.c global and local var
decl detection)

Romain Geissler

2011-07-07  Romain Geissler  romain.geiss...@gmail.com
2010-04-14  Brian Hackett  bhackett1...@gmail.com

gcc/ChangeLog:

   * plugin.def: Add event for finish_decl.
   * plugin.c (register_callback, invoke_plugin_callbacks): Same.
   * c-decl.c (finish_decl): Invoke callbacks on above event.
   * doc/plugins.texi: Document above event.

gcc/cp/ChangeLog:

   * decl.c (cp_finish_decl): Invoke callbacks on finish_decl event.

gcc/testsuite/ChangeLog:

   * g++.dg/plugin/decl_plugin.c: New test plugin.
   * g++.dg/plugin/decl-plugin-test.C: Testcase for above plugin.
   * g++.dg/plugin/plugin.exp: Add above testcase.


Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 175907)
+++ gcc/doc/plugins.texi(working copy)
@@ -151,6 +151,7 @@ enum plugin_event
 @{
   PLUGIN_PASS_MANAGER_SETUP,/* To hook into pass manager.  */
   PLUGIN_FINISH_TYPE,   /* After finishing parsing a type.  */
+  PLUGIN_FINISH_DECL,   /* After finishing parsing a declaration. */
   PLUGIN_FINISH_UNIT,   /* Useful for summary processing.  */
   PLUGIN_PRE_GENERICIZE,/* Allows to see low level AST in C
and C++ frontends.  */
   PLUGIN_FINISH,/* Called before GCC exits.  */
Index: gcc/plugin.def
===
--- gcc/plugin.def  (revision 175907)
+++ gcc/plugin.def  (working copy)
@@ -24,6 +24,9 @@ DEFEVENT (PLUGIN_PASS_MANAGER_SETUP)
 /* After finishing parsing a type.  */
 DEFEVENT (PLUGIN_FINISH_TYPE)

+/* After finishing parsing a declaration. */
+DEFEVENT (PLUGIN_FINISH_DECL)
+
 /* Useful for summary processing.  */
 DEFEVENT (PLUGIN_FINISH_UNIT)

Index: gcc/testsuite/g++.dg/plugin/plugin.exp
===
--- gcc/testsuite/g++.dg/plugin/plugin.exp  (revision 175907)
+++ gcc/testsuite/g++.dg/plugin/plugin.exp  (working copy)
@@ -51,7 +51,8 @@ set plugin_test_list [list \
 { pragma_plugin.c pragma_plugin-test-1.C } \
 { selfassign.c self-assign-test-1.C self-assign-test-2.C
self-assign-test-3.C } \
 { dumb_plugin.c dumb-plugin-test-1.C } \
-{ header_plugin.c header-plugin-test.C } ]
+{ header_plugin.c header-plugin-test.C } \
+{ decl_plugin.c decl-plugin-test.C } ]

 foreach plugin_test $plugin_test_list {
 # Replace each source file with its full-path name
Index: gcc/testsuite/g++.dg/plugin/decl-plugin-test.C
===
--- gcc/testsuite/g++.dg/plugin/decl-plugin-test.C  (revision 0)
+++ gcc/testsuite/g++.dg/plugin/decl-plugin-test.C  (revision 0)
@@ -0,0 +1,32 @@
+
+
+extern int global; // { dg-warning Decl Global global }
+int global_array[] = { 1, 2, 3 }; // { dg-warning Decl Global global_array }
+
+int takes_args(int arg1, int arg2)
+{
+  int local = arg1 + arg2 + global; // { dg-warning Decl Local local }
+  return local + 1;
+}
+
+int global = 12; // { dg-warning Decl Global global }
+
+struct test_str {
+  int field; // { dg-warning Decl Field field }
+};
+
+class test_class {
+  int class_field1; // { dg-warning Decl Field class_field1 }
+  int

Re: [PATCH] Fix configure --with-cloog

2011-07-06 Thread Romain Geissler
 Hello

 This patch fix an issue while building with cloog and gmp installed in
 a custom separate directories.

 How to reproduce :
  - Make sure you've installed cloog and gmp in separate directories
 (ie ${WITH-CLOOG-PATH}/lib doesn't contain libgmp)
  - Make sure neither gmp nor cloog is not installed in a directory
 searched by default by your linker when looking for libs.
  - Launch configure script with both --with-gmp and --with-cloog
 switch properly set

 This result in an unexpected error while configuring: error: Unable to
 find a usable CLooG.


 2011-07-06  Romain Geissler  romain.geiss...@gmail.com

       * configure: Add $gmplibs to cloog $LDFLAGS

 Index: configure
 ===
 --- configure   (revision 175709)
 +++ configure   (working copy)
 @@ -5713,7 +5713,7 @@ if test x$with_cloog != xno; then

     CFLAGS=${CFLAGS} ${clooginc} ${gmpinc}
   CPPFLAGS=${CPPFLAGS} ${_cloogorginc}
 -  LDFLAGS=${LDFLAGS} ${clooglibs}
 +  LDFLAGS=${LDFLAGS} ${clooglibs} ${gmplibs}

   case $cloog_backend in
     ppl-legacy)


I forgot configure was a generated script. Here is the patch that fix
it at the m4 macro level :


2011-07-06  Romain Geissler  romain.geiss...@gmail.com

  * config/cloog.m4: Add $gmplibs to cloog $LDFLAGS
  * configure: Regenerate


Index: config/cloog.m4
===
--- config/cloog.m4 (revision 175907)
+++ config/cloog.m4 (working copy)
@@ -142,7 +142,7 @@ AC_DEFUN([CLOOG_FIND_FLAGS],
   dnl clooglibs  clooginc may have been initialized by CLOOG_INIT_FLAGS.
   CFLAGS=${CFLAGS} ${clooginc} ${gmpinc}
   CPPFLAGS=${CPPFLAGS} ${_cloogorginc}
-  LDFLAGS=${LDFLAGS} ${clooglibs}
+  LDFLAGS=${LDFLAGS} ${clooglibs} ${gmplibs}

   case $cloog_backend in
 ppl-legacy)


Re: C++ mangling, function name to mangled name (or tree)

2011-07-06 Thread Romain Geissler
Le 6 juil. 2011 à 18:40, Pierre Vittet a écrit :

 On 06/07/2011 18:25, Kevin André wrote:
 On Wed, Jul 6, 2011 at 18:00, Pierre Vittetpier...@pvittet.com  wrote:
 
   
 I would like user of the plugin to give in arguments the name of the
 functions on which he would like a test to be run. That means that I must
 convert the string containing a function name (like myclass::init) and get
 either the mangled name or the tree corresponding to the function. I know
 that there might be several results (functions with the same name and
 different arguments), a good policy for me would be to recover every
 concerned functions (at least for the moment).
 
 I guess what I want to do is possible, because there are already some tools
 doing it (like gdb).
 
 Are you absolutely sure about gdb? It could be doing it the other way
 around, i.e. start from the mangled names in the object file and
 demangle all of them. Then it would search for a function name in its
 list of demangled names.
 Just guessing, though :)
 
 
 Regards,
 
 Kevin André
 
   
 Hello,
 
 no I am not sure, but I guess it would really have an important cost to do it 
 like you said. Would it no be easier to have a field containing the 
 'demangled' names? At least in debug since it has an important space 
 complexity.
 
 Thanks!
 
 Pierre Vittet

Hello,

Have you considered the reverse way to do that. I mean, why don't you hook on 
the PLUGIN_PRE_GENERICIZE event to catch all function bodies, and then compare 
the argument the user gave you to current_function_name() (that will returns 
you the full protoype of the current function, ie: malloc   full name is void* 
malloc(size_t)). Then, you can store the FUNCTION_DECL tree if there's a match 
and use it for later processing. That's how i proceed for my plugins.

Romain Geissler