libbacktrace PATCH: improve comment for backtrace_create_state
Hello All, I just discovered that backtrace_create_state should be called once, that it is returning some heap-allocated data (which cannot be free-d, because there is no backtrace_destroy_state routine). I suggest the attached patch (against GCC trunk r246678) which just improves the comment describing that function. libgcc/ChangeLog entry: 2017-04-04 Basile Starynkevitch * backtrace.h (backtrace_create_state): Improve comment, since should be called once. Comments are welcome. Otherwise, ok for trunk? -- Basile Starynkevitch (France) http://starynkevitch.net/Basile/Index: libbacktrace/backtrace.h === --- libbacktrace/backtrace.h (revision 246678) +++ libbacktrace/backtrace.h (working copy) @@ -83,16 +83,17 @@ int errnum); /* Create state information for the backtrace routines. This must be - called before any of the other routines, and its return value must - be passed to all of the other routines. FILENAME is the path name - of the executable file; if it is NULL the library will try - system-specific path names. If not NULL, FILENAME must point to a - permanent buffer. If THREADED is non-zero the state may be - accessed by multiple threads simultaneously, and the library will - use appropriate atomic operations. If THREADED is zero the state - may only be accessed by one thread at a time. This returns a state - pointer on success, NULL on error. If an error occurs, this will - call the ERROR_CALLBACK routine. */ + called once before any of the other routines (probably at startup, + e.g. early in main), and its return value must be passed to all of + the other routines. FILENAME is the path name of the executable + file; if it is NULL the library will try system-specific path + names. If not NULL, FILENAME must point to a permanent buffer. If + THREADED is non-zero the state may be accessed by multiple threads + simultaneously, and the library will use appropriate atomic + operations. If THREADED is zero the state may only be accessed by + one thread at a time. This returns a state pointer on success, + NULL on error. If an error occurs, this will call the + ERROR_CALLBACK routine. */ extern struct backtrace_state *backtrace_create_state ( const char *filename, int threaded,
Re: libbacktrace PATCH: improve comment for backtrace_create_state
On 2017-04-04 15:38, Ian Lance Taylor wrote: On Tue, Apr 4, 2017 at 5:05 AM, wrote: I just discovered that backtrace_create_state should be called once, that it is returning some heap-allocated data (which cannot be free-d, because there is no backtrace_destroy_state routine). I suggest the attached patch (against GCC trunk r246678) which just improves the comment describing that function. You are adding that backtrace_create_state should be called "(probably at startup, e.g. early in main)"? But that is not accurate. It's perfectly reasonable to do what GCC itself does, which is call backtrace_create_state only when it encounters an internal compiler error (in diagnostic_action_after_output in gcc/diagnostic.c). How about we just add backtrace_destroy_state? I don't know how to code that. In my https://github.com/bstarynk/melt-monitor I observed that calling free on such a struct backtrace_state pointer is breaking things. I also find the code of backtrace_create_state a bit complex (maybe for historical reasons). Why does it call backtrace_alloc instead of just calling malloc? And why would it call the error_callback on failure? (I would just return NULL in that case, leaving the caller of backtrace_create_state to handle that out-of-memory error itself). Actually, I tend to believe that backtrace_create_state should have its signature changed to just: struct backtrace_state *backtrace_create_state (const char *filename, int threaded); Or maybe the above should be called backtrace_create_simple_state? BTW, I guess that changing the API is not possible in current stage (that it why I suggested just a comment change). Cheers -- Basile Starynkevitch (France)http://starynkevitch.net/Basile/
Re: libbacktrace PATCH: improve comment for backtrace_create_state
On 2017-04-04 16:04, Ian Lance Taylor wrote: On Tue, Apr 4, 2017 at 6:50 AM, wrote: On 2017-04-04 15:38, Ian Lance Taylor wrote: How about we just add backtrace_destroy_state? I don't know how to code that. In my https://github.com/bstarynk/melt-monitor I observed that calling free on such a struct backtrace_state pointer is breaking things. Well, yes, it would have to call backtrace_free. But more than that it would have to munmap the free list. So you're right that it's not trivial. I also find the code of backtrace_create_state a bit complex (maybe for historical reasons). Why does it call backtrace_alloc instead of just calling malloc? Because backtrace_create_state, like all the backtrace functions, can be called from a signal handler. The backtrace code can never call malloc. (It does call malloc on systems that do not support anonymous mmap, because there is no other choice, which means that the backtrace library does not really work entirely correctly on such systems. Fortunately such systems are rare these days. See BACKTRACE_USES_MALLOC.) This is great news! I would be tempted to suggest another comment change in backtrace.h saying that the functions are (on most recent systems like Linux and those with anonymous mmap) async-signal-safe (when the user callbacks are also that). I was unaware of that delicious property of your libbacktrace. Ian, you are impressing me even more than usual! (I'm not a native English speaker or a POSIX guru, but to me the three words async-signal-safe means something important; I am borrowing them from http://man7.org/linux/man-pages/man7/signal.7.html which might be my favorite man page, with time(7)). Cheers. -- Basile Starynkevitch (France)http://starynkevitch/net/Basile/
Re: [wwwdocs] extensions.html - remove "rogue" MELT page
On 07/14/2018 10:17 PM, Gerald Pfeifer wrote: I noticed that http://gcc-melt.org now redirects to http://www.gcc-melt.org which looks like a default, and empty, Wordpress installation. I went ahead and applied the patch below. Basile, should we generally remove this reference to GCC MELT? Gerald Index: extensions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v retrieving revision 1.59 diff -u -r1.59 extensions.html --- extensions.html 2 Jun 2018 21:16:09 - 1.59 +++ extensions.html 14 Jul 2018 20:14:45 - @@ -21,7 +21,7 @@ analysis, debugging, and performance tuning in concurrent code. -http://gcc-melt.org";>GCC MELT +GCC MELT MELT is a high-level domain specific language to ease the development of GCC extensions. It is available as a GCC experimental Yes. I am no more working on MELT, but I did begin to work on its successor: https://github.com/bstarynk/bismon Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: [wwwdocs] extensions.html - remove "rogue" MELT page
On 07/15/2018 07:12 AM, Basile Starynkevitch wrote: On 07/14/2018 10:17 PM, Gerald Pfeifer wrote: I noticed that http://gcc-melt.org now redirects to http://www.gcc-melt.org which looks like a default, and empty, Wordpress installation. I went ahead and applied the patch below. Basile, should we generally remove this reference to GCC MELT? Gerald Index: extensions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v retrieving revision 1.59 diff -u -r1.59 extensions.html --- extensions.html 2 Jun 2018 21:16:09 - 1.59 +++ extensions.html 14 Jul 2018 20:14:45 - @@ -21,7 +21,7 @@ analysis, debugging, and performance tuning in concurrent code. -http://gcc-melt.org";>GCC MELT +GCC MELT MELT is a high-level domain specific language to ease the development of GCC extensions. It is available as a GCC experimental Yes. I am no more working on MELT, but I did begin to work on its successor: https://github.com/bstarynk/bismon I forgot to tell that the old GCC MELT pages are still online, but the gcc-melt.org domain has vanished. The old GCC MELT pages are available on http://starynkevitch.net/Basile/gcc-melt/ Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy
On Sat, 2013-08-31 at 11:57 +0200, Richard Biener wrote:
> Diego Novillo wrote:
> >
> >Yes. Lawrence and I thought about moving gengtype inside g++. That
> >seemed like a promising approach.
>
>
> What do you do during stage1? Have a collector that never collects?
We could imagine that the successor of gengtype would be some GCC plugin
(which would generate C++ code for marking and GC and PCH purposes,
perhaps using ad-hoc attributes and pragmas)
Then for bootstrapping purposes, we could put the generated C++ code in
the source repository (like we already do for configure, or
fixincludes/fixincl.x etc...). Hence stage1 would be buildable with the
generated C++ code in the repository.
A more difficult issue is that the set of GTY-ed types is target
specific and depends upon the .../configure argument at build time.
Perhaps we could consider processing all of it (i.e. every GTY-ed class
declaration), and have our gengtype successor plugin emit appropriate
#if in the generated C++ code.
Of course having gengtype replaced by a plugin requires such a plugin to
be developed and GCC maintainers to have access to some gcc...
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
patch to enable *.cc files in gengtype
Hello All,
The attached patch (for trunk svn rev 202160)
to gcc/gengtype.c permits files named *.cc (by adding another rule)
to be passed to gengtype and gives a slightly meaningful fatal
error message whan an unrecogized file name (e.g. *.cpp or something
even more wild) is passed to gengtype.
FWIW, this patch is imported from melt-branch svn rev 202160.
gcc/ChangeLog entry
2013-09-02 Basile Starynkevitch
* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give fatal message when no
rules found.
###
Ok for trunk?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/gengtype.c
===
--- gcc/gengtype.c (revision 202160)
+++ gcc/gengtype.c (working copy)
@@ -2004,14 +2004,21 @@
REG_EXTENDED, NULL_REGEX,
"gt-objc-objc-map.h", "objc/objc-map.c", NULL_FRULACT },
- /* General cases. For header *.h and source *.c files, we need
- * special actions to handle the language. */
+ /* General cases. For header *.h and source *.c or *.cc files, we
+ * need special actions to handle the language. */
/* Source *.c files are using get_file_gtfilename to compute their
output_name and get_file_basename to compute their for_name
through the source_dot_c_frul action. */
{ DIR_PREFIX_REGEX "([[:alnum:]_-]*)\\.c$",
REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.c", source_dot_c_frul},
+
+ /* Source *.cc files are using get_file_gtfilename to compute their
+ output_name and get_file_basename to compute their for_name
+ through the source_dot_c_frul action. */
+ { DIR_PREFIX_REGEX "([[:alnum:]_-]*)\\.cc$",
+REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.cc", source_dot_c_frul},
+
/* Common header files get "gtype-desc.c" as their output_name,
* while language specific header files are handled specially. So
* we need the header_dot_h_frul action. */
@@ -2269,9 +2276,9 @@
}
if (!output_name || !for_name)
{
- /* This is impossible, and could only happen if the files_rules is
- incomplete or buggy. */
- gcc_unreachable ();
+ /* This should not be possible, and could only happen if the
+ files_rules is incomplete or buggy. */
+ fatal ("failed to compute output name for %s", inpfname);
}
/* Look through to see if we've ever seen this output filename
Ping: small patch to accept = inside plugin arguments
Hello
I'm pinging my last month's patch
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
of August 07th 2013 to accept the = inside plugin arguments
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: operator new returns nonzero
On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
> Hello,
>
> this patch teaches the compiler that operator new, when it can throw,
> isn't allowed to return a null pointer. Note that it doesn't work for
> placement new (that one may have to be handled in the front-end or the
> inliner), and it will not work on user-defined operator new if they are
> inlined. I guess it would be possible to teach the inliner to insert an
> assert_expr or something when inlining such a function, but that's not for
> now. The code I removed from vrp_visit_stmt was duplicated in
> stmt_interesting_for_vrp and thus useless.
Interesting patch. However, I feel that we should give advanced users
the ability to say that their new operator is never returning null...
In particular, if I define my own new operator which never returns nil,
I find strange that it would be less optimized than the system's
operator new.
Perhaps we need an attribute `nonnullresult' which whould means that.
(we already the nonnull attribute for function arguments)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Ping patch to enable *.cc files in gengtype
Hello all,
I'm pinging the patch (of september 2nd) on
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch
* gengtype.c (file_rules): Added rule for *.cc files.
(get_output_file_with_visibility): Give fatal message when no
rules found.
###
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Ping^2: small patch to accept = inside GCC plugin arguments
Hello All,
I'm pinging again my small patch to accept = inside plugin arguments
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00037.html
# gcc/ChangeLog entry
2013-09-16 Basile Starynkevitch
* plugin.c (parse_plugin_arg_opt): Accept equal sign inside
plugin argument.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Ping patch to enable *.cc files in gengtype
On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote:
> On 2013-09-16 04:19 , Basile Starynkevitch wrote:
> >Hello all,
> >
> >I'm pinging the patch (of september 2nd) on
> >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
> >
> >
> > gcc/ChangeLog entry
> >
> >2013-09-16 Basile Starynkevitch
> >
> > * gengtype.c (file_rules): Added rule for *.cc files.
> > (get_output_file_with_visibility): Give fatal message when no
> > rules found.
>
> OK.
Thanks for the review and the approval. I just commited revision 202782.
BTW, I believe this patch should be back ported, at least to next GCC 4.8.2
(and perhaps even to 4.7). What do you think?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Ping^2: small patch to accept = inside GCC plugin arguments
On Fri, Sep 20, 2013 at 09:49:34AM -0400, Diego Novillo wrote:
> On Mon, Sep 16, 2013 at 4:23 AM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I'm pinging again my small patch to accept = inside plugin arguments
> > http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
>
> OK.
Thanks for the review and the approval. I also think that the above patch
should be backported to 4.7 & 4.8
Committed revision 202783.
What do you think?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Ping patch to enable *.cc files in gengtype
On Fri, Sep 20, 2013 at 05:56:22PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 20, 2013 at 05:52:38PM +0200, Basile Starynkevitch wrote:
> > On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote:
> > > On 2013-09-16 04:19 , Basile Starynkevitch wrote:
> > > >Hello all,
> > > >
> > > >I'm pinging the patch (of september 2nd) on
> > > >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
> > > >
> > > >
> > > > gcc/ChangeLog entry
> > > >
> > > >2013-09-16 Basile Starynkevitch
> > > >
> > > > * gengtype.c (file_rules): Added rule for *.cc files.
> > > > (get_output_file_with_visibility): Give fatal message when no
> > > > rules found.
> > >
> > > OK.
> >
> > Thanks for the review and the approval. I just commited revision 202782.
> >
> > BTW, I believe this patch should be back ported, at least to next GCC 4.8.2
> > (and perhaps even to 4.7). What do you think?
>
> Why? There are no *.cc files in 4.8.x and I don't see why this patch would
> be desirable for the release branches.
Because 4.8 (and even 4.7) plugins may have .cc files and they are running
(when they have GTY-ed data) gengtype to be built.
In general, I still do find that naming .c a C++ file is very confusing
(especially for newbies). BTW, some other compilers don't like that
(in particular Clang issues a warning when compiling a C++ file named .c,
so Clang issues a lot of warnings when compiling GCC)
Of course, one might say that no recent C++ formal standard states that
C++ source files should have a .cc or .cxx or .cpp or .C extension
(but I am not sure of this) but this is a common practice since several
decades (probably since the origin of C++).
INSHO plugins for GCC don't have any reasons to follow the GCC
(obscure and undocumented) bad & crazy habit of naming .c a C++ file
(that a plain C compiler won't even compile!).
So I believe that the plugin infrastructure should accept -and even mandates,
or at least strongly advise- that plugin files should be named *.cc (or *.cpp).
And since GCC 4.8 (and even 4.7) requires a C++ compiler, their plugins
should generally be coded in C++ not in C. And such a plugin C++ source
file has absolutely no reason to be named *.c (the reason why GCC still
have *.c file is some obscure version controlling reason; one might be
tempted to think that if the version control wants *.c files for C++ source,
that version control is broken and should be replaced by some more
fancy thing...)
Not accepting plugin source files named .cc for C++ source code is IMHO a bug.
And some plugins (those with GTY-ed data) do use gengtype during their build.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Patch correcting possible bug in toplevel.c regarding plugin & diagnostics finalizartion
Hello All
I'm re-reading toplev_main from gcc/toplev.c and I find strange that
invoke_plugin_callbacks for PLUGIN_FINISH was called before
diagnostic_finish (which I guess is finalizing all the diagnostic
infrastructure).
My guess would be that some GCC plugins might occasionally emit a
diagnostic at PLUGIN_FINISH stage. Imagine a plugin which fills some
database (e.g. with software metrics). It would probably close the
database at PLUGIN_FINISH, and in the rare event that database closing
fails, emit a diagnostic (using e.g. error)
proposed patch against trunk svn rev 203073
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 203073)
+++ gcc/toplev.c(working copy)
@@ -1970,11 +1970,13 @@ toplev_main (int argc, char **argv)
if (warningcount || errorcount || werrorcount)
print_ignored_options ();
- diagnostic_finish (global_dc);
- /* Invoke registered plugin callbacks if any. */
+ /* Invoke registered plugin callbacks if any. Some plugins could
+ emit some diagnostics here. */
invoke_plugin_callbacks (PLUGIN_FINISH, NULL);
+ diagnostic_finish (global_dc);
+
finalize_plugins ();
location_adhoc_data_fini (line_table);
if (seen_error () || werrorcount)
proposed gcc/ChangeLog entry
2013-10-01 Basile Starynkevitch
* toplev.c (toplev_main): Move PLUGIN_FINISH invocation before
diagnostic_finish.
#
I am not entirely sure about this patch (because I don't fully
understand what diagnostic_finish is supposed to do, just partly
guessing it). Comments are welcome.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH trunk: gengtype honoring mark_hook-s inside struct inide union-s
Hello All,
As I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html and in
http://gcc.gnu.org/ml/gcc/2012-10/msg3.html the mark_hook GTY annotation is
sometimes incorrectly ingored by gengtype.
The example in http://gcc.gnu.org/ml/gcc/2012-10/msg3.html demonstrates
that incorrect behavior of gengtype (both with gengtype from GCC 4.7,
and with the current trunk's gengtype). For simplicity, here is it again:
/* file tmarkh.h */
#define MYUTAG 1
union GTY ((desc("%0.u_int"))) myutest_un {
int GTY((skip)) u_int;
struct mytest_st GTY ((tag("MYUTAG"))) u_mytest;
};
static GTY(()) union myutest_un *myutestptr;
static inline void mymarker(struct mytest_st*s)
{
s->myflag = 1;
}
/* eof tmarkh.h */
when running gengtype (the one from the trunk, or the gcc-4.7 one) with
gengtype -D -v -r gtype.state -P _g-tmarkh.h tmarkh.h
you can observe that the generated _g-tmarkh.h don't contain any call to
mymarker. If the static variable (here myutestptr) is declared with the
struct mytest_st* type, the marker is emitted.
The reason of that bug is that for GTY-ed union members which are themselves
GTY-ed struct, the marking of the nested struct is generated inline (for the
union)
and in that case the mark_hook annotation was not used.
The attached patch to trunk svn rev 191972 solves this issue
(with it, the generated _g-tmarkh.h is correctly calling mymarker).
The gcc/ChangeLog entry is:
2012-10-02 Basile Starynkevitch
* gengtype.c (walk_type): Emit mark_hook when inside a
struct of a union member.
####
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc-trunk-bstarynk/gcc/gengtype.c
===
--- gcc-trunk-bstarynk/gcc/gengtype.c (revision 191972)
+++ gcc-trunk-bstarynk/gcc/gengtype.c (working copy)
@@ -2810,6 +2810,7 @@ walk_type (type_p t, struct walk_type_data *d)
const char *oldval = d->val;
const char *oldprevval1 = d->prev_val[1];
const char *oldprevval2 = d->prev_val[2];
+ const char *structmarkhook = NULL;
const int union_p = t->kind == TYPE_UNION;
int seen_default_p = 0;
options_p o;
@@ -2833,7 +2834,14 @@ walk_type (type_p t, struct walk_type_data *d)
if (!desc && strcmp (o->name, "desc") == 0
&& o->kind == OPTION_STRING)
desc = o->info.string;
+ else if (!structmarkhook && strcmp(o->name, "mark_hook") == 0
+ && o->kind == OPTION_STRING)
+ structmarkhook = o->info.string;
+ if (structmarkhook)
+ oprintf (d->of, "%*s/*structmarkhook %s */ %s (&%s));\n",
+ d->indent, "", t->u.s.tag, structmarkhook, oldval);
+
d->prev_val[2] = oldval;
d->prev_val[1] = oldprevval2;
if (union_p)
Re: PATCH trunk: gengtype honoring mark_hook-s inside struct inside union-s
On Wed, Oct 03, 2012 at 12:21:02PM +0300, Laurynas Biveinis wrote:
> Hello Basile -
>
> > 2012-10-02 Basile Starynkevitch
> >
> > * gengtype.c (walk_type): Emit mark_hook when inside a
> > struct of a union member.
>
> Can you send me off-list the gengtype output before and after the fix?
I messed something, the example I did send was wrong. Let's start all over
again.
Consider the following file
(I named this example on purpose differently than in the previous message)
/* file basilemarkh.h */
struct GTY ((mark_hook("mymarker"))) mytest_st {
int myflag;
tree mytree;
gimple mygimple;
};
#define MYUTAG 1
union GTY ((desc ("%0.u_int"))) myutest_un
{
int GTY ((skip)) u_int;
struct mytest_st GTY ((tag ("MYUTAG"))) u_mytest;
};
static GTY (()) union myutest_un *myutestptr;
static inline void mymarker (struct mytest_st *s)
{
s->myflag = 1;
}
/* eof basilemarkh.h */
###
With the gengtype from 4.7 in Debian/Sid/AMD64 (a 4.7.2 I believe)
/usr/lib/gcc/x86_64-linux-gnu/4.7/gengtype -D -v \
-r /usr/lib/gcc/x86_64-linux-gnu/4.7/gtype.state \
-P _g-4.7-basilemarkh.h basilemarkh.h
from generated _g-4.7-basilemarkh.h
/* functions code */
void
gt_ggc_mx_myutest_un (void *x_p)
{
union myutest_un * const x = (union myutest_un *)x_p;
if (ggc_test_and_set_mark (x))
{
switch ((*x).u_int)
{
case MYUTAG: ## no mark hook here, should have a call to
mymarker
gt_ggc_m_9tree_node ((*x).u_mytest.mytree);
gt_ggc_m_18gimple_statement_d ((*x).u_mytest.mygimple);
break;
default:
break;
}
}
}
### end of excerpt from generated _g-4.7-basilemarkh.h
With the gengtype from unpatched trunk svn rev 192031 the emitted
gt_ggc_mx_myutest_un is exactly the same.
Of course the ### comment above has been added manually by me Basile.
So I applied and I am proposing the following patch to gcc trunk 192031
(Laurynas, I did take your remarks into account)
# patch to trunk
Index: gcc/gengtype.c
===
--- gcc/gengtype.c (revision 192031)
+++ gcc/gengtype.c (working copy)
@@ -2810,6 +2810,7 @@ walk_type (type_p t, struct walk_type_data *d)
const char *oldval = d->val;
const char *oldprevval1 = d->prev_val[1];
const char *oldprevval2 = d->prev_val[2];
+ const char *struct_mark_hook = NULL;
const int union_p = t->kind == TYPE_UNION;
int seen_default_p = 0;
options_p o;
@@ -2833,7 +2834,14 @@ walk_type (type_p t, struct walk_type_data *d)
if (!desc && strcmp (o->name, "desc") == 0
&& o->kind == OPTION_STRING)
desc = o->info.string;
+ else if (!struct_mark_hook && strcmp (o->name, "mark_hook") == 0
+ && o->kind == OPTION_STRING)
+ struct_mark_hook = o->info.string;
+ if (struct_mark_hook)
+ oprintf (d->of, "%*s%s (&%s));\n",
+d->indent, "", struct_mark_hook, oldval);
+
d->prev_val[2] = oldval;
d->prev_val[1] = oldprevval2;
if (union_p)
# end of patch
with the following ChangeLog entry
# gcc/ChangeLog entry
2012-10-03 Basile Starynkevitch
* gengtype.c (walk_type): Emit mark_hook when inside a
struct of a union member.
# end of gcc/ChangeLog entry
If you apply my proposed patch the emitted function is
### from generated _gtrunk-basilemarkh.h with my patch to gengtype.c
/* functions code */
void
gt_ggc_mx_myutest_un (void *x_p)
{
union myutest_un * const x = (union myutest_un *)x_p;
if (ggc_test_and_set_mark (x))
{
switch ((*x).u_int)
{
case MYUTAG:
mymarker (&(*x).u_mytest));
gt_ggc_m_9tree_node ((*x).u_mytest.mytree);
gt_ggc_m_18gimple_statement_d ((*x).u_mytest.mygimple);
break;
default:
break;
}
}
}
end of excerpt from generated _gtrunk-basilemarkh.h
If you just use the gengtype from trunk 192031 without my patch
you get the same code as from gcc-4.7's gengtype:
from generated _g192031-basilemarkh.h
void
gt_ggc_mx_myutest_un (void *x_p)
{
union myutest_un * const x = (union myutest_un *)x_p;
if (ggc_test_and_set_mark (x))
{
switch ((*x).u_int)
{
case MYUTAG:
gt_ggc_m_9tree_node ((*x).u_mytest.mytree);
gt_ggc_m_18gimple_statement_d ((*x).u_mytest.mygimple);
break;
default:
break;
}
}
}
### end of excerpt from generated _g192031-basilemarkh.h
Is my patch here ok for trunk?
Regards.
--
Basile STARYN
Re: PATCH trunk: gengtype honoring mark_hook-s inside struct inside union-s
On Wed, Oct 03, 2012 at 01:02:44PM +0200, Basile Starynkevitch wrote:
> On Wed, Oct 03, 2012 at 12:21:02PM +0300, Laurynas Biveinis wrote:
> > Hello Basile -
> >
> > > 2012-10-02 Basile Starynkevitch
> > >
> > > * gengtype.c (walk_type): Emit mark_hook when inside a
> > > struct of a union member.
> >
> > Can you send me off-list the gengtype output before and after the fix?
>
> I messed something, the example I did send was wrong. Let's start all over
> again.
>
> Consider the following file
[...]
This is PR54809 on our bugzilla.
Thanks.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PATCH trunk: gengtype honoring mark_hook-s inside struct inside union-s
On Thu, Oct 04, 2012 at 06:51:35PM +0300, Laurynas Biveinis wrote:
> > 2012-10-03 Basile Starynkevitch
> >
> > * gengtype.c (walk_type): Emit mark_hook when inside a
> > struct of a union member.
>
> This is OK.
thanks, Committed revision 192092 to trunk.
I believe this patch should be backported into GCC 4.7 and 4.6
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PATCH trunk: gengtype honoring mark_hook-s inside struct inside union-s
On Thu, Oct 04, 2012 at 07:26:23PM +0200, Richard Guenther wrote:
> On Thu, Oct 4, 2012 at 7:24 PM, Basile Starynkevitch
> wrote:
> > On Thu, Oct 04, 2012 at 06:51:35PM +0300, Laurynas Biveinis wrote:
> >> > 2012-10-03 Basile Starynkevitch
> >> >
> >> > * gengtype.c (walk_type): Emit mark_hook when inside a
> >> > struct of a union member.
> >>
> >> This is OK.
> >
> > thanks, Committed revision 192092 to trunk.
> >
> >
> > I believe this patch should be backported into GCC 4.7 and 4.6
>
> I see no reason for this unless it is a regression.
If GCC 4.7 will have future micro releases, (like an hypothetical 4.7.3) they
will have the same bug.
What is the procedure to get this bug fixed in 4.7.3?
(and there are plugins for 4.7 affected by this bug, http://gcc-melt.org/ for
example)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PATCH trunk: gengtype honoring mark_hook-s inside struct inside union-s
On Wed, Oct 03, 2012 at 01:02:44PM +0200, Basile Starynkevitch wrote:
> So I applied and I am proposing the following patch to gcc trunk 192031
> (Laurynas, I did take your remarks into account)
> # patch to trunk
> Index: gcc/gengtype.c
> ===
> --- gcc/gengtype.c(revision 192031)
> +++ gcc/gengtype.c(working copy)
> @@ -2810,6 +2810,7 @@ walk_type (type_p t, struct walk_type_data *d)
> const char *oldval = d->val;
> const char *oldprevval1 = d->prev_val[1];
> const char *oldprevval2 = d->prev_val[2];
> + const char *struct_mark_hook = NULL;
> const int union_p = t->kind == TYPE_UNION;
> int seen_default_p = 0;
> options_p o;
> @@ -2833,7 +2834,14 @@ walk_type (type_p t, struct walk_type_data *d)
> if (!desc && strcmp (o->name, "desc") == 0
> && o->kind == OPTION_STRING)
> desc = o->info.string;
> + else if (!struct_mark_hook && strcmp (o->name, "mark_hook") == 0
> +&& o->kind == OPTION_STRING)
> + struct_mark_hook = o->info.string;
>
> + if (struct_mark_hook)
> + oprintf (d->of, "%*s%s (&%s));\n",
> + d->indent, "", struct_mark_hook, oldval);
Sorry for the typo, the patch should have only one closing parenthesis.
So I'm applying the following patch to trunk to correct it.
Index: gengtype.c
===
--- gengtype.c (revision 192094)
+++ gengtype.c (working copy)
@@ -2839,7 +2839,7 @@
struct_mark_hook = o->info.string;
if (struct_mark_hook)
- oprintf (d->of, "%*s%s (&%s));\n",
+ oprintf (d->of, "%*s%s (&%s);\n",
d->indent, "", struct_mark_hook, oldval);
d->prev_val[2] = oldval;
I hope that correcting such a typo falls into the "obvious patch" rule, so I
dare committing it
right now, reusing the same ChangeLog entry.
% svn commit gcc/gengtype.c
Sendinggcc/gengtype.c
Transmitting file data .
Committed revision 192095.
If you feel it is wrong to correct such a typo without asking, I'll revert this
obvious commit.
Apologies for the typo.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 09, 2012 at 11:20:48AM -0700, Ian Lance Taylor wrote:
> This patch to libbacktrace adds support for tracing through shared
> libraries. The libraries are found by calling dl_iterate_phdr, when it
> is available.
This functionality is definitely useful for meta-plugins like MELT
(since melt.so is dlopen-ing things)
>
> This patch has some preliminary support for tracing through libaries
> opened via dlopen, but there is no code for actually finding such
> libraries.
Perhaps you might use dladdr, on the few systems (notably GNU/Libc on Linux)
which have it?
>From man dlsym output:
int dladdr(void *addr, Dl_info *info);
The function dladdr() takes a function pointer and tries to resolve
name and file where it is located. Information is stored in the
Dl_info structure:
typedef struct {
const char *dli_fname; /* Pathname of shared object that
contains address */
void *dli_fbase; /* Address at which shared object
is loaded */
const char *dli_sname; /* Name of nearest symbol with address
lower than addr */
void *dli_saddr; /* Exact address of symbol named
in dli_sname */
} Dl_info;
If no symbol matching addr could be found, then dli_sname and dli_saddr
are set to NULL.
dladdr() returns 0 on error, and nonzero on success.
Or maybe I misunderstood libbacktrace and my comment is irrelevant. If it is
the case, sorry for the noise.
You could provide an extra API to register dlopen & dlclose to libbacktrace, if
that helps you
(of course, I would prefer avoiding that)
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH] make gengtype more robust against user error
On Fri, 2013-10-25 at 17:37 -0400, David Malcolm wrote:
> This patch addresses various forms of failure described in
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html
>
> It adds a "default: gcc_unreachable();" to the autogenerated switch()
> statement in the routines for a base class, converting various kinds of
> tag errors from leading to silent lack-of-field traversal into giving
> run-time assertion failures (addressing (F) and (G))
>
> It also issues an error within gengtype itself for a missing "desc"
> (failure "B"), turning this into an error message from gengtype.
>
> I found another potential failure mode:
>
> (H) If you had:
>
> class GTY((desc("%0.kind"), tag("0"))) foo
> {
> public:
> int kind;
> tree p;
> };
>
> class GTY((tag("1"))) bar : public foo
> {
> public:
> tree q;
> };
>
> static GTY(()) foo *dummy_foo;
>
> and there are no explicit pointers to "bar" in the code, gengtype
> treated it as unused, and silently omitted the case for it from
> foo's marking routine.
>
> I've updated set_gc_type_used so that it propagates usage down into
> subclasses (which recurses), fixing this issue.
>
> To do this efficiently we need to track subclasses in within gengtype,
> so the patch also adds that, and uses it to eliminate an O(N^2).
>
> Note that for error (G), if a class within the hierarchy omits a GTY
> marker, gengtype doesn't parse it at all, and so doesn't parse the
> inheritance information - so we can't issue a warning about this.
> However, the lack of a tag will trigger a run-time assertion failure
> due to hitting the "default: gcc_unreachable();" in the switch.
> The patch also adds a paragraph to the docs, spelling out the need
> for evary class in such a hierarchy to have a GTY marker.
>
> I believe this addresses all of the silent-lack-of-field-traversal
> issues, converting them to gengtype errors or runtime assertions.
> It also adds a handler for (E), turning this from a failure to
> compile bogus C to a specific error in gengtype.
>
> I'm bootstrapping/regtesting now.
> OK for trunk if that passes?
I don't have the power to approve this patch, but I hope it will get
accepted.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
On 10/31/2013 05:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.
[This is a revised version of the patches sent as:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01788.html
and
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01954.html
which got bogged down in discussion of hand-written GTY hooks. This
patch series updates things to make use of the new support in gengtype
for simple inheritance schemes]
The gimple statement types are currently implemented using a hand-coded
C inheritance scheme, with a "union gimple_statement_d" holding the
various possible structs for a statement.
The following series of patches convert it to a C++ hierarchy, using the
existing structs, eliminating the union. The "gimple" typedef changes
from being a
(union gimple_statement_d *)
to being a:
(struct gimple_statement_base *)
Very good idea. But please, document that in some texinfo file, probably
gcc/doc/gimple.texi
Gimple-s are so damn important, even for plugin writers, that a small
but up to date documentation is absolutely essential. You don"t need to
write a lot of doc, just the minimal stuff (which at least tells which
file should the plugin writer look into and list all the relevant classes).
I hope your patches (or similar ones) will be accepted in 4.9
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to GCCJIT.
It is bootstrapping, but I don't have any test cases
## gcc/jit/ChangeLog entry:
2015-07-15 Basile Starynkevitch
* libgccjit.h (gcc_jit_context_new_rvalue_from_long_long)
(gcc_jit_context_new_rvalue_from_int32)
(gcc_jit_context_new_rvalue_from_int64)
(gcc_jit_context_new_rvalue_from_intptr): New function
declarations.
* libgccjit.map: New entries for above functions.
* libgccjit.c (gcc_jit_context_new_rvalue_from_long_long)
(gcc_jit_context_new_rvalue_from_int32)
(gcc_jit_context_new_rvalue_from_int64)
(gcc_jit_context_new_rvalue_from_intptr): New functions.
###
Comments are welcome. Ok for trunk?
see https://gcc.gnu.org/ml/jit/2015-q3/msg00085.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/libgccjit.c
===
--- gcc/jit/libgccjit.c (revision 225842)
+++ gcc/jit/libgccjit.c (working copy)
@@ -1154,6 +1154,70 @@ gcc_jit_context_new_rvalue_from_long (gcc_jit_cont
->new_rvalue_from_const (numeric_type, value));
}
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_long_long (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ long long value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, "NULL context");
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ ->new_rvalue_from_const (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int32 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int32_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, "NULL context");
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ ->new_rvalue_from_const (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int64 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int64_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, "NULL context");
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ ->new_rvalue_from_const (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_intptr (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ intptr_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, "NULL context");
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ ->new_rvalue_from_const (numeric_type, value));
+}
+
+
/* Public entrypoint. See description in libgccjit.h.
This is essentially equivalent to:
Index: gcc/jit/libgccjit.h
===
--- gcc/jit/libgccjit.h (revision 225842)
+++ gcc/jit/libgccjit.h (working copy)
@@ -752,6 +752,26 @@ gcc_jit_context_new_rvalue_from_long (gcc_jit_cont
long value);
extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_long_long (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ long long value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int32 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int32_t value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int64 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int64_t value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_intptr (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ intptr_t value);
+
+extern gcc_jit_rvalue *
gcc_jit_context_zero (gcc_jit_context *ctxt,
gcc_jit_type *numeric_type);
Index: gcc/jit/libgccjit.map
===
--- gcc/jit/libgccjit.map (revision 225842)
+++ gcc/jit/libgccjit.map (working copy)
@@ -61,7 +61,10 @@ LIBGCCJIT_ABI_0
gcc_jit_context_new_param;
gcc_jit_context_new_rvalue_from_double;
gcc_jit_context_new_rvalue_from_int;
+gcc_jit_context_new_rvalue_from_int32;
+gcc_jit_context_new_rvalue_from_int64;
gcc_jit_context_new_rvalue_from_long;
+gcc_jit_cont
Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
Does this actually link and run? This appears to be missing some
implementations of the template specializations in jit/jit-recording.c
for the new specializations of new_rvalue_from_const. If these are
missing, I'd expect to see a linker error at run-time when attempting
to run client code that links against such a libgccjit.so.
It does bootstrap (in the GCC sense). I suspect that C++ integral
promotion or casting rules are enough to have something being linked,
but probably not what is really needed. And I'm testing that on
x86-64/Linux where the patch is almost useless.
Thanks for your other comments. I'm trying to understand them and I am
working on that.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
* dump_to_reproducer support (most testcases attempt to dump their
contexts to a .c file and then sanity-check the generated c by
compiling them, though not running them; see jit.exp). A new API
entrypoint needs to "know" how to write itself back out to C (by
implementing gcc::jit::recording::memento::write_reproducer for the
appropriate memento subclass).
I'm sorry, but I can't understand the above comment. Where is the
"Implementation of recording::memento::write_reproducer for longs." I
can't find such comment in jit-recording.c!
BTW, it is really a pity that even a brand new subtree like gcc/jit/,
coded mostly in C++, uses *.c
as the file extension for newly introduced C++ files. There is no legacy
reason to use *.c extensions for new C++ files (as we had for source
files of twenty years of age). I really find that confusing. And no
comment mention that it is C++ not C!
It makes me almost cry :-)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH (v2) trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 21:16, David Malcolm wrote:
Perhaps, but note that nothing in a regular gcc bootstrap uses
libgccjit, so you *might* still have a latent linking error that shows
up only at run time. Running the jit testsuite is the best way to be
sure.
And I'm testing that on
x86-64/Linux where the patch is almost useless.
Thanks for your other comments. I'm trying to understand them and I am
working on that.
Cheers
Here (attached gcc-jitlonglong-r225860.diff)
is an improved version of my patch against trunk r225860.
Thanks to David Malcom for the kind help.
### gcc/jit/ ChangeLog entry
2015-07-16 Basile Starynkevitch
* jit-playback.c: Mention that it is in C++.
(new_rvalue_from_const ): New.
* jit-recording.c: Mention that it is in C++.
(recording::memento_of_new_rvalue_from_const ): New
instanciated template.
(memento_of_new_rvalue_from_const ::make_debug_string):
New specialized function.
(memento_of_new_rvalue_from_const ::get_wide_int): New
specialized function.
(recording::memento_of_new_rvalue_from_const ::write_reproducer): Likewise.
* libgccjit.c: Mention that it is in C++.
(gcc_jit_context_new_rvalue_from_long_long): New function.
(gcc_jit_context_new_rvalue_from_int32): New function.
(gcc_jit_context_new_rvalue_from_int64): New function.
(gcc_jit_context_new_rvalue_from_intptr): New function.
* libgccjit.h: #include
(gcc_jit_context_new_rvalue_from_long_long): New declaration.
In the declarations of the functions below, a short comment
explains that they are convenience functions.
(gcc_jit_context_new_rvalue_from_int32): New declaration.
(gcc_jit_context_new_rvalue_from_int64): New declaration.
(gcc_jit_context_new_rvalue_from_intptr): New declaration.
* libgccjit.map: Add LIBGCCJIT_ABI_4 for new functions
e.g. gcc_jit_context_new_rvalue_from_long_long,
## gcc/testsuite/ChangeLog entry
* test-constants.c (make_test_of_long_long_constant): New function.
(make_tests_of_long_long_constants): New.
(verify_long_long_constants): New.
(create_code): Call make_tests_of_long_long_constants.
(verify_code): Call verify_long_long_constants.
I have mixed feelings about adding the
gcc_jit_context_new_rvalue_from_int32
gcc_jit_context_new_rvalue_from_int64 &
gcc_jit_context_new_rvalue_from_intptr functions.
On one hand, their name is very suggestive, and most programmers know
about . I should confess that I discovered only recently that
long long is guaranteed by C99 standard to be at least 64 bits (I
thought that the standard just required that long long is at least as
big as long).
On the other hand, we are adding more functions to the ABI, and indeed
the gcc_jit_context_new_rvalue_from_long_long is in principle enough.
Perhaps we should simply document that for int32_t, int64_t, intptr_t
types, the GCCJIT user should test the sizeof intptr_t and call the
appropriate function?
BTW some bytecodes or VMs (in particular the JVM) are hardcoding the
size of some integers, so dealing explicitly with int32_t & int64_t
definitely makes sense.
The patch is passing the test that I have added, on Debian/x86-64.
Comments are welcome, including perhaps an Ok for trunk...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/jit-playback.c
===
--- gcc/jit/jit-playback.c (revision 225860)
+++ gcc/jit/jit-playback.c (working copy)
@@ -1,4 +1,5 @@
-/* Internals of libgccjit: classes for playing back recorded API calls.
+/* This jit-playback.c file is in -*- C++ -*- ...
+ Internals of libgccjit: classes for playing back recorded API calls.
Copyright (C) 2013-2015 Free Software Foundation, Inc.
Contributed by David Malcolm .
@@ -573,6 +574,30 @@ new_rvalue_from_const (type *type,
}
}
+
+/* Specialization of making an rvalue from a const, for host . */
+
+template <>
+rvalue *
+context::
+new_rvalue_from_const (type *type,
+ long long value)
+{
+ // FIXME: type-checking, or coercion?
+ tree inner_type = type->as_tree ();
+ if (INTEGRAL_TYPE_P (inner_type))
+{
+ tree inner = build_int_cst (inner_type, value);
+ return new rvalue (this, inner);
+}
+ else
+{
+ REAL_VALUE_TYPE real_value;
+ real_from_integer (&real_value, VOIDmode, value, SIGNED);
+ tree inner = build_real (inner_type, real_value);
+ return new rvalue (this, inner);
+}
+}
/* Specialization of making an rvalue from a const, for host . */
template <>
Index: gcc/jit/jit-recording.c
===
--- gcc/jit/jit-recording.c (revision 225860)
+++ gcc/jit/jit-re
Re: [patch] Create gimple-expr..[ch] ... was Re: RFC: gimple.[ch] break apart
On Tue, Nov 05, 2013 at 11:26:46AM -0500, Andrew MacLeod wrote:
>
> I decided to name the new file gimple-expr.[ch] instead of
> gimple-decl This will eventually split into gimple-type.[ch],
> gimple-decl.[ch], and gimple-expr.[ch].
Since we are adding *new* C++ files, can't we please name them *.cc
for the implementation part, so at least create gimple-expr.h and
gimple-expr.cc but not gimple-expr.c, please!
There are some reasons to keep existing *.c files containing C++ code
(IMHO the reasons are bad ones, and related to poor habits and to
deficiencies in the version control system we have to use,
but I really don't want to open that debate again).
But for **NEW** files which are definitely in C++, I don't understand
why they should be named .c files; this is confusing for all (and,
for instance, when compiling them with Clang we are getting -IMHO
rightly- some warnings about the file naming).
If I remember well, there have been (in the discussion about naming C++ source
files of GCC) a suggestion (and perhaps even a consensus),
probably by Diego Novillo, to name *.cc our new files which are in C++.
Having old C++ files named *.c is already a big frustration
(most editors are by default configured to handle them as C, not as C++, files
and most developers, notably newbies to GCC contributions,
are expecting them to be C files not C++ ones).
But IMHO having new source files inside GCC coded in C++ with a *.c file
extension
is non-sense; such files should have a .cc (or maybe .cpp or .cxx) extension,
not a .c extension.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
patch ping: diagnostics finalization and plugins
Hello all,
I'm pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00056.html
##
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 204671)
+++ gcc/toplev.c(working copy)
@@ -1968,11 +1968,13 @@ toplev_main (int argc, char **argv)
if (warningcount || errorcount || werrorcount)
print_ignored_options ();
- diagnostic_finish (global_dc);
- /* Invoke registered plugin callbacks if any. */
+ /* Invoke registered plugin callbacks if any. Some plugins could
+ emit some diagnostics here. */
invoke_plugin_callbacks (PLUGIN_FINISH, NULL);
+ diagnostic_finish (global_dc);
+
finalize_plugins ();
location_adhoc_data_fini (line_table);
if (seen_error () || werrorcount)
gcc/ChangeLog entry
2013-11-11 Basile Starynkevitch
* toplev.c (toplev_main): Move PLUGIN_FINISH invocation before
diagnostic_finish.
Ok for trunk?
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Add __auto_type C extension, use it in
On Wed, 2013-11-13 at 11:39 +0100, Richard Biener wrote:
> On Wed, Nov 13, 2013 at 1:39 AM, Joseph S. Myers
> wrote:
> > contains what C11 describes as "generic functions".
> > Although DR#419 makes clear that users cannot #undef these macros (or
> > otherwise suppress use of a macro definition) and expect to find an
> > underlying function, they still need to behave like functions as
> > regards evaluating their arguments exactly once (see C11 7.1.4).
> >
> > I noted when adding to mainline that some of the macro
> > definitions there failed that requirement in the case where the
> > pointer argument had variably modified type, because then typeof
> > evaluates its argument and so that argument would be evaluated twice.
> > Avoiding such double evaluation requires defining the type of a
> > temporary variable, and initializing it with the pointer argument,
> > with a single evaluation. To achieve this, this patch adds a new GNU
> > C extension __auto_type, essentially a restricted version of C++11
> > auto, and uses it in .
>
> I suppose you didn't use '__auto' because that's much more likely
> used elsewhere than '__auto_type'?
I have no idea, but does anyone knows if other free compilers (notably
Clang/LLVM) are adding a similar feature?
If they do, perhaps (if it is not too painful) we should use the same
keyword (i.e. __auto_type) and a similar semantics.
And I also like that feature, but it should be documented outside of the
support of since it is genuinely useful by itself (e.g. as
an alternative to typeof).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
Hello All
After http://gcc.gnu.org/ml/gcc/2013-11/msg00360.html &
http://gcc.gnu.org/ml/gcc/2013-11/msg00361.html &
http://gcc.gnu.org/ml/gcc/2013-11/msg00347.html I am proposing the
following patch
## patch
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 204976)
+++ gcc/plugin.def (working copy)
@@ -92,6 +92,10 @@
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
+/* Called when a file is #include-d or given thru #line directive. */
+DEFEVENT (PLUGIN_INCLUDE_FILE)
+
+
/* After the hard-coded events above, plugins can dynamically allocate
events
at run time.
PLUGIN_EVENT_FIRST_DYNAMIC only appears as last enum element. */
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 204976)
+++ gcc/c-family/c-opts.c (working copy)
@@ -34,6 +34,7 @@
#include "debug.h" /* For debug_hooks. */
#include "opts.h"
#include "options.h"
+#include "plugin.h"/* For PLUGIN_INCLUDE_FILE event. */
#include "mkdeps.h"
#include "c-target.h"
#include "tm.h"/* For BYTES_BIG_ENDIAN,
@@ -43,6 +44,7 @@
TARGET_OPTF. */
#include "tm_p.h" /* For C_COMMON_OVERRIDE_OPTIONS. */
+
#ifndef DOLLARS_IN_IDENTIFIERS
# define DOLLARS_IN_IDENTIFIERS true
#endif
@@ -1397,6 +1399,16 @@
else
fe_file_change (new_map);
+ if (new_map
+ && (new_map->reason == LC_ENTER || new_map->reason == LC_RENAME))
+{
+ /* Signal to plugins that a file is included. This could happen
+several times. */
+ invoke_plugin_callbacks
+ (PLUGIN_INCLUDE_FILE,
+const_cast (ORDINARY_MAP_FILE_NAME (new_map)));
+}
+
if (new_map == 0 || (new_map->reason == LC_LEAVE && MAIN_FILE_P
(new_map)))
{
pch_cpp_save_state ();
### gcc/ChangeLog entry
2013-11-18 Basile Starynkevitch
* plugins.def (PLUGIN_INCLUDE_FILE): New event.
### gcc/c-family/ChangeLog entry
2013-11-18 Basile Starynkevitch
* c-opts.c: Include plugin.h header.
(cb_file_change): Sent plugin event PLUGIN_INCLUDE_FILE.
###
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Mon, Nov 18, 2013 at 10:50:10PM +, Joseph S. Myers wrote:
> On Mon, 18 Nov 2013, Basile Starynkevitch wrote:
>
> > @@ -43,6 +44,7 @@
> >TARGET_OPTF. */
> > #include "tm_p.h" /* For C_COMMON_OVERRIDE_OPTIONS. */
> >
> > +
> > #ifndef DOLLARS_IN_IDENTIFIERS
> > # define DOLLARS_IN_IDENTIFIERS true
> > #endif
>
> This is a spurious diff hunk that should not be in this patch.
>
> OK minus the spurious change in the absence of objections from the plugin
> maintainers within 48 hours (or in the presence of approval from either of
> them).
Thanks for your attention. I am attaching a slightly improved patch
against trunk svn rev. 305009 (the improvements are removing the spurious
diff hunk, and better comments.)
# gcc/c-family/ChangeLog entry :
2013-11-19 Basile Starynkevitch
* c-opts.c: Include plugin.h.
(cb_file_change): Invoke plugin event PLUGIN_INCLUDE_FILE.
# gcc/ChangeLog entry :
2013-11-19 Basile Starynkevitch
* plugin.def (PLUGIN_INCLUDE_FILE): New event, invoked in
cb_file_change.
###
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 205009)
+++ gcc/c-family/c-opts.c (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3. If not see
#include "debug.h" /* For debug_hooks. */
#include "opts.h"
#include "options.h"
+#include "plugin.h" /* For PLUGIN_INCLUDE_FILE event. */
#include "mkdeps.h"
#include "c-target.h"
#include "tm.h" /* For BYTES_BIG_ENDIAN,
@@ -1397,6 +1398,17 @@ cb_file_change (cpp_reader * ARG_UNUSED (pfile),
else
fe_file_change (new_map);
+ if (new_map
+ && (new_map->reason == LC_ENTER || new_map->reason == LC_RENAME))
+{
+ /* Signal to plugins that a file is included. This could happen
+ several times with the same file path, e.g. because of
+ several '#include' or '#line' directives... */
+ invoke_plugin_callbacks
+ (PLUGIN_INCLUDE_FILE,
+ const_cast (ORDINARY_MAP_FILE_NAME (new_map)));
+}
+
if (new_map == 0 || (new_map->reason == LC_LEAVE && MAIN_FILE_P (new_map)))
{
pch_cpp_save_state ();
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 205009)
+++ gcc/plugin.def (working copy)
@@ -92,6 +92,12 @@ DEFEVENT (PLUGIN_EARLY_GIMPLE_PASSES_END)
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+DEFEVENT (PLUGIN_INCLUDE_FILE)
+
+
/* After the hard-coded events above, plugins can dynamically allocate events
at run time.
PLUGIN_EVENT_FIRST_DYNAMIC only appears as last enum element. */
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 16:16 +, Joseph S. Myers wrote:
> On Tue, 19 Nov 2013, Basile Starynkevitch wrote:
>
> > Thanks for your attention. I am attaching a slightly improved patch
> > against trunk svn rev. 305009 (the improvements are removing the spurious
> > diff hunk, and better comments.)
>
> Still OK in the absence of plugin maintainer objections.
Thanks: Committed revision 205038.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
> > Thanks: Committed revision 205038.
>
> This seems to break several g++ tests: see
> http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
> On x86_64-apple-darwin13, the ICE is
>
> cc1: error: cannot load plugin ./one_time_plugin.so
> dlopen(./one_time_plugin.so, 10): image not found
> /opt/gcc/work/gcc/testsuite/gcc.dg/plugin/one_time-test-1.c:1:0: internal
> compiler error: in invoke_plugin_callbacks_full, at plugin.c:509
> /* Test that pass is inserted and invoked once. */
> ^
I don't have an Apple machine, but I cannot understand the logic (in
particular, did you make clean before recompiling and running the test).
The patch only added a new event. How can just adding a new event break
the thing?
I'm beginning more tests now, but I only have access to Gnu Linux x86-64
systems...
Or is it some MacOSX specific bug? (BTW, I thought that GCC plugins
never worked on MacOSX or on Windows)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
> > Thanks: Committed revision 205038.
>
> This seems to break several g++ tests: see
> http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
> On x86_64-apple-darwin13, the ICE is
I would guess that the following trivial patch should correct that:
# patch against svn rev 205052
Index: gcc/plugin.c
===
--- gcc/plugin.c(revision 205052)
+++ gcc/plugin.c(working copy)
@@ -529,6 +529,7 @@ invoke_plugin_callbacks_full (int event, void *gcc
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
/* Iterate over every callback registered with this event and
call it. */
#
If that patch correct the bug, I guess that I could apply it under the
"obvious bugfix" rule. Could you check that it works on your MacOSX?
Apologies for my mistake.
Thanks
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
> > Thanks: Committed revision 205038.
>
> This seems to break several g++ tests: see
> http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
> On x86_64-apple-darwin13, the ICE is
>
> cc1: error: cannot load plugin ./one_time_plugin.so
Actually, when we add hard coded plugin events we should never forget,
like I just did, to edit invoke_plugin_callbacks_full.
Diego and all, can I add the following patch to the trunk. One is just a
comment inside plugin.def to recall that invoke_plugin_callbacks_full
should be edited, and another is the tiny fix on that function in
plugin.c
### gcc/ChangeLog entry
2013-11-19 Basile Starynkevitch
* plugin.def: Add comment about register_callback and
invoke_plugin_callbacks_full.
* plugin.c (register_callback, invoke_plugin_callbacks_full):
Handle PLUGIN_INCLUDE_FILE event.
###
Apologies for my mistake. Hope this will be approved quickly before 4.9
stage 3! (I will later submit a documentation patch)
BTW, I am not very happy about some events in plugin.def not being real
events. IMHO I would prefer that PLUGIN_PASS_MANAGER_SETUP,
PLUGIN_REGISTER_GGC_ROOTS, PLUGIN_REGISTER_GGC_CACHES be removed,
because they are not real events (and they should have their own public
functions in plugin.h, e.g. add functions like
plugin_pass_manager_setup, plugin_register_ggc_roots,
plugin_register_ggc_caches in gcc/gcc-plugin.h). Unfortunately, we don't
have time for such an improvement for 4.9
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/plugin.c
===
--- gcc/plugin.c (revision 205052)
+++ gcc/plugin.c (working copy)
@@ -452,6 +452,7 @@ register_callback (const char *plugin_name,
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
struct callback_info *new_callback;
if (!callback)
@@ -529,6 +530,7 @@ invoke_plugin_callbacks_full (int event, void *gcc
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
/* Iterate over every callback registered with this event and
call it. */
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 205052)
+++ gcc/plugin.def (working copy)
@@ -97,6 +97,9 @@ DEFEVENT (PLUGIN_NEW_PASS)
as a const char* pointer. */
DEFEVENT (PLUGIN_INCLUDE_FILE)
+/* When adding a new hard-coded plugin event, don't forget to edit in
+ file plugin.c the functions register_callback and
+ invoke_plugin_callbacks_full accordingly! */
/* After the hard-coded events above, plugins can dynamically allocate events
at run time.
Re: [jit] Drop libgccjit.pc
On Mon, 2014-10-20 at 13:54 -0400, David Malcolm wrote:
> Committed to branch dmalcolm/jit:
>
> pkg-config appears to be controversial, so don't provide a .pc file.
I would put it under contrib/; it is controversial, but some would like
to have it.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, 2014-11-12 at 14:36 +0100, Basile Starynkevitch wrote:
> On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote:
> > > Most plugin don't need any configure, because they are installed in
> > > a version specific directory (like
> > > /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin
> > > for example). I don't think it is wise to require plugin to be
> > > autoconf-configurable. Their Makefile simply uses
> > > $(shell gcc -print-file-name=plugin), there is no need to complex
> > > autoconf machinery.
> >
> > If you use $(shell gcc -print-file-name=plugin), there is no point
> > to include plugin-version.h, just use __GNUC__/__GNUC_MINOR__ ?
>
>
> I could compile a plugin (notably for a GCC cross-compiler) with a GCC version
> different of the GCC targetting the plugin. I could also compile a
> plugin with Clang or some other non-GCC compiler. In both cases
> plugin-version.h is needed with its GCCPLUGIN_VERSION.
I'm trying to patch GCC to get a plugin-version.c file generated, but I
can't get that work. Here is attached a buggy patch against trunk svn
r217460 which does not work. Could any one help me to catch my mistake
please?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 217460)
+++ fixincludes/fixincl.x (working copy)
@@ -1,12 +1,12 @@
/* -*- buffer-read-only: t -*- vi: set ro:
- *
+ *
* DO NOT EDIT THIS FILE (fixincl.x)
- *
- * It has been AutoGen-ed October 21, 2014 at 10:18:16 AM by AutoGen 5.16.2
+ *
+ * It has been AutoGen-ed
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Oct 21 10:18:17 CEST 2014
+/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Nov 13 07:50:38 MET 2014
*
* You must regenerate it. Use the ./genfixes script.
*
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 217460)
+++ gcc/Makefile.in (working copy)
@@ -1324,6 +1324,7 @@
opts-global.o \
passes.o \
plugin.o \
+ plugin-version.o \
postreload-gcse.o \
postreload.o \
predict.o \
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 217460)
+++ gcc/configure.ac (working copy)
@@ -1656,7 +1656,25 @@
else
gcc_REVISION=""
fi
+
+cat > plugin-version.c < plugin-version.h <
bad patch for GCCPLUGIN_VERSION... help needed!
Hello All, In https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01393.html I posted a bad patch (to generate a plugin-version.c for gcc_version outside of plugin-version.h) but I can't find out what is wrong? Could any person much more familiar with autoconf that I am take a few seconds to look at it, please! I'm sure my mistake is trivial, but I cannot find it. I really hope this would go into GCC 5.0 (and the delay is short), because MELT http://gcc-melt.org/ is needing it. Regards & thanks for your help. -- Basile Starynkevitch http://starynkevitch.net/Basile/
Re: [PATCH 2/2] jit: add switch statements
On 06/25/2015 09:13 PM, David Malcolm wrote:
Some interpreters/VMs support a switch statement (for example the JVM
has opcodes "lookupswitch" and "tableswitch"). GCC has a set of
optimizations for efficiently handling switch statements, so it makes
sense to directly expose switch statements in the libgccjit API.
Yes, I hope that feature will be incorporated quickly in gccjit. I don't
have the power to approve that patch, but I hope it will be approved.
This patch implements a switch statement, but it isn't quite ready for
committing to trunk yet:
* It relies on gcc/typed-splay-tree.h in the previous patch
* It extends the libgccjit API. It's not clear to me yet how to
manage extensions of the libgccjit API: should I use symbol maps
and versioning, or bump the SONAME? I'm thinking of providing
precanned feature macros within libgccjit.h e.g:
#define LIBGCCJIT_HAVE_SWITCH_STATEMENT
for the benefit of client code that doesn't use configure
scripts.
Perhaps just exposing the major and minor version of the GCC supporting
that GCCJIT is enough (like it was done for plugins, e.g.
GCCPLUGIN_VERSION etc)?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Four jit backports to gcc 5 branch
On Mon, Jun 29, 2015 at 11:44:31AM -0400, David Malcolm wrote: > I've gone over the changes to the gcc/jit and gcc/testsuite/jit.dg > directories in trunk since gcc 5 and backported the following 4 changes > from trunk to the gcc-5-branch: > I'll be delighted if switch statements ability would be backported to GCC 5. (Its absence is IMHO a severe bug in GCCJIT, but perhaps GCC rules forbid backporting new features, even when they correct a huge deficiency and when the patch adding them is probably quite small). Cheers. -- Basile Starynkevitch http://starynkevitch.net/Basile/
PATCH GCC5.0: conditionally skip gcc_version in gcc-plugin.h
Hello All,
Some plugins (including MELT, see http://gcc-melt.org/ for more)
are made of several C++ source files which all include "plugin-version.h"
because they have some C++ code which depends upon the particular version
of GCC.
So they typically code
#if GCCPLUGIN_VERSION >= 4009
/* code for GCC 4.9 or newer. */
#else
/* code for GCC 4.8 */
#endif /*GCCPLUGIN_VERSION*/
after including "plugin-version.h"; however that file also defines static
data, notably `gcc_version`. That data symbol may be useless in most of
the plugin files -except the one initializing the plugin. Having several
useless data symbols may disturb the debugger (since the static symbol
`gcc_version` is no longer unique) and may consume some tiny useless data
(at least when the plugin is compiled with -O0).
The attached small patch (for trunk svn rev. 217404) disables the definition
of `gcc_version` when the preprocessor symbol GCCPLUGIN_SKIP_VERSION_DATA
is defined as 1 before #include "plugin-version.h"
### gcc/ChangeLog entry:
2014-11-12 Basile Starynkevitch
* configure.ac (plugin-version.h): Don't define version data
when GCCPLUGIN_SKIP_VERSION_DATA was #define-d as 1.
* doc/plugins.texi: (Plugins building): Document
GCCPLUGIN_SKIP_VERSION_DATA. Put it with GCCPLUGIN_VERSION* names
in the function index.
###
Ok for trunk? Comments are welcome.
Regards
--
Basile Starynkevitch http://starynkevitch.net/Basile
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 217404)
+++ gcc/configure.ac (working copy)
@@ -1664,6 +1664,10 @@
#define GCCPLUGIN_VERSION_PATCHLEVEL `echo $gcc_BASEVER | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$/\1/'`
#define GCCPLUGIN_VERSION (GCCPLUGIN_VERSION_MAJOR*1000 + GCCPLUGIN_VERSION_MINOR)
+/* Some plugins might not want the data below, they would define
+ GCCPLUGIN_SKIP_VERSION_DATA as 1 before including this. */
+
+#if !GCCPLUGIN_SKIP_VERSION_DATA
static char basever[] = "$gcc_BASEVER";
static char datestamp[] = "$gcc_DATESTAMP";
static char devphase[] = "$gcc_DEVPHASE";
@@ -1675,6 +1679,7 @@
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
configuration_arguments};
+#endif /* GCCPLUGIN_SKIP_VERSION_DATA */
EOF
changequote([,])dnl
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 217404)
+++ gcc/doc/plugins.texi (working copy)
@@ -157,6 +157,16 @@
but you can also check the individual fields if you want a less strict check.
+A plugin might want to include in some of its source files the
+@file{plugin-version.h} header for preprocessor constants
+@code{GCCPLUGIN_VERSION} without defining the static symbol
+@code{gcc_version}. In that case it should define the preprocessor
+symbol @code{GCCPLUGIN_SKIP_VERSION_DATA} to @code{1} before including
+that header.
+@findex GCCPLUGIN_VERSION
+@findex GCCPLUGIN_SKIP_VERSION_DATA
+@findex gcc_version
+
@subsection Plugin callbacks
Callback functions have the following prototype:
@@ -488,6 +498,10 @@
#error this GCC plugin is for GCC 4.7
#endif
@end smallexample
+@findex GCCPLUGIN_VERSION_MAJOR
+@findex GCCPLUGIN_VERSION_MINOR
+@findex GCCPLUGIN_VERSION_PATCHLEVEL
+@findex GCCPLUGIN_VERSION
The following GNU Makefile excerpt shows how to build a simple plugin:
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, Nov 12, 2014 at 02:12:07PM +0100, Jakub Jelinek wrote: > On Wed, Nov 12, 2014 at 01:55:12PM +0100, Basile Starynkevitch wrote: > > Hello All, > > > > Some plugins (including MELT, see http://gcc-melt.org/ for more) > > are made of several C++ source files which all include "plugin-version.h" > > because they have some C++ code which depends upon the particular version > > of GCC. > > > > So they typically code > > > > #if GCCPLUGIN_VERSION >= 4009 > > /* code for GCC 4.9 or newer. */ > > #else > > /* code for GCC 4.8 */ > > #endif /*GCCPLUGIN_VERSION*/ > > Can't you just remember that version in configure of your plugin? Most plugin don't need any configure, because they are installed in a version specific directory (like /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin for example). I don't think it is wise to require plugin to be autoconf-configurable. Their Makefile simply uses $(shell gcc -print-file-name=plugin), there is no need to complex autoconf machinery. And even a plugin for a particular version of GCC is usually made of several files, all of them with #include "plugin-version.h"; there is no need to define several times gcc_version. (another possibility might be to make gcc_version an external symbol with public visibility inside the cc1 or cc1plus executable) Thanks for your comment. Cheers. -- Basile Starynkevitchhttp://starynkevitch.net/Basile/
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote: > On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote: > > Most plugin don't need any configure, because they are installed in > > a version specific directory (like /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin > > for example). I don't think it is wise to require plugin to be > > autoconf-configurable. Their Makefile simply uses > > $(shell gcc -print-file-name=plugin), there is no need to complex > > autoconf machinery. > > If you use $(shell gcc -print-file-name=plugin), there is no point > to include plugin-version.h, just use __GNUC__/__GNUC_MINOR__ ? I could compile a plugin (notably for a GCC cross-compiler) with a GCC version different of the GCC targetting the plugin. I could also compile a plugin with Clang or some other non-GCC compiler. In both cases plugin-version.h is needed with its GCCPLUGIN_VERSION. Cheers. -- Basile Starynkevitch http://starynkevitch.net/Basile/
Re: [wwwdocs] extensions.html - remove "rogue" MELT page
On 6/15/19 9:45 PM, Gerald Pfeifer wrote: On Sun, 15 Jul 2018, Basile Starynkevitch wrote: Basile, should we generally remove this reference to GCC MELT? Yes. I am no more working on MELT, but I did begin to work on its successor: Sorry for the delay - I finally applied the patch below. If/when you want that successor to be listed on our extensions page, please advise (ideally submitting a patch, or even going ahead an applying it and just posting the patch). The successor (Bismon) is not ready, it is free software (GPLv3+ license), but still unreleased. So alpha stage. And it is a research project (so obligation of means, not of results). You could look at the code on http://github.com/bstarynk/bismon/ (the copyright belongs to my employer, but could be transfered to FSF when/if wanted). You could read a technical draft report on Bismon on http://starynkevitch.net/Basile/bismon-chariot-doc.pdf but this is a draft report and I am quite often improving it; feel free to provide any feedback to me (by email) about it; the title of that report is quite baroque, but mandated by the H2020 project funding the work. Notice that H2020 projects (see https://en.wikipedia.org/wiki/Framework_Programmes_for_Research_and_Technological_Development#Horizon_2020 for more) are excessively bureaucratic (and more than previous European research projects), and not very FSF or GNU or free software friendly. I don't even know if that Bismon will be ready for GCC before I am retiring. (probably in 2024, and perhaps in 2023). I do know that once retired, I won't work on Bismon (and probably won't work much on GCC neither). I would work on some other free software project (also GPLv3+). I am waiting for my retirement Cheers. -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: JIT patch: add gcc_jit_magic_int
On 06/07/2016 09:19 PM, Andrew Pinski wrote:
On Mon, May 23, 2016 at 5:26 AM, Basile Starynkevitch
wrote:
Hello All,
As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is
difficult (or tricky without using dirty tricks involving the GCC plugin
headers) to use GCCJIT to emit code equivalent to the following C file:
extern int a;
int get_atomic_a (void) {
return __atomic_load_n (&a, __ATOMIC_SEQ_CST);
}
The issue is that __ATOMIC_SEQ_CST is a magic preprocessor (but
non-standard!) symbol which might not be available
(or might have a different value) in the C code for GCCJIT building such an
AST.
So we need a function to retrieve some magic integral value from the GCCJIT
compiler.
Huh?Why can't you just use the enum:
enum memmodel
{
MEMMODEL_RELAXED = 0,
MEMMODEL_CONSUME = 1,
MEMMODEL_ACQUIRE = 2,
MEMMODEL_RELEASE = 3,
MEMMODEL_ACQ_REL = 4,
MEMMODEL_SEQ_CST = 5,
MEMMODEL_LAST = 6,
MEMMODEL_SYNC_ACQUIRE = MEMMODEL_ACQUIRE | MEMMODEL_SYNC,
MEMMODEL_SYNC_RELEASE = MEMMODEL_RELEASE | MEMMODEL_SYNC,
MEMMODEL_SYNC_SEQ_CST = MEMMODEL_SEQ_CST | MEMMODEL_SYNC
};
(sorry for the late reply)
I think that Andrew Pinski is right, and that we should make that enum
available in libgccjit.h.
David Malcolm, please tell us how should that be done? Would you accept
a #include "coretypes.h" inside libgccjit.h? Or should I copy paste the
enum memmodel into libgccjit.h?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH 0/3] Support for mandatory tail calls
On 05/19/2016 12:12 AM, Jeff Law wrote:
On 05/17/2016 04:01 PM, David Malcolm wrote:
There have been requests [1] for libgccjit to better support
functional programming by supporting the contination-passing style,
in which every function "returns" by calling a "continuation"
function pointer.
These calls must be guaranteed to be implemented as a jump,
otherwise the program could consume an arbitrary amount of stack
space as it executed.
This patch kit implements this.
Patch 1 is a preliminary tweak to calls.c
Patch 2 implements a new flag in tree.h: CALL_EXPR_MUST_TAIL_CALL,
which makes calls.c try harder to implement a flagged call as a
tail-call/sibling call, and makes it issue an error if
the optimization is impossible. It doesn't implement any
frontend support for setting the flag (instead using a plugin
to test it). We had some discussion on the jit list about possibly
introducing a new builtin for this, but the patch punts on this
issue.
I wonder if we should have an attribute so that the flag can be set
for C/C++ code. I've seen requests for forcing tail calls in C/C++
code several times in the past, precisely to support continuations.
Why an attribute? Attributes are on declarations. I think it should
better be some pragma like _Pragma(GCC tail cail, foo(x,y)) or some
builtin (or else some syntax extension like goto return foo(x,y); ...)
because what we really want is to annotate a particular call to be
tail-recursive.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
JIT patch: add gcc_jit_magic_int
Hello All,
As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is
difficult (or tricky without using dirty tricks involving the GCC plugin
headers) to use GCCJIT to emit code equivalent to the following C file:
extern int a;
int get_atomic_a (void) {
return __atomic_load_n (&a, __ATOMIC_SEQ_CST);
}
The issue is that __ATOMIC_SEQ_CST is a magic preprocessor (but non-standard!)
symbol which might not be available
(or might have a different value) in the C code for GCCJIT building such an AST.
So we need a function to retrieve some magic integral value from the GCCJIT
compiler.
The attached patch (relative to trunk svn 236583) is a first attempt to solve
that issue
(and also give ability to query some other magic numbers).
Proposed ChangeLog entry (in gcc/jit/)
2016-05-23 Basile Starynkevitch
* libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_magic_int): New macro.
(gcc_jit_magic_int): New public function declaration.
* libgccjit.c: Include "cppbuiltin.h", "options.h", "flag-types.h"
(gcc_jit_magic_int): New function.
* libgccjit.map: Add gcc_jit_magic_int to LIBGCCJIT_ABI_6.
Comments (or an ok to commit) are welcome. (I am not sure that
__SANITIZE_ADDRESS__ is correctly handled,
because I would believe that optimization flags are not globals in GCCJIT)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/libgccjit.h
===
--- gcc/jit/libgccjit.h (revision 236583)
+++ gcc/jit/libgccjit.h (working copy)
@@ -1387,6 +1387,27 @@
gcc_jit_rvalue_set_bool_require_tail_call (gcc_jit_rvalue *call,
int require_tail_call);
+
+ /* Magical integer values useful in the compiler; similar to
+ predefined C macros like __GNUC__, __GNUC_MINOR__,
+ __GNUC_PATCHLEVEL__, __ATOMIC_RELAXED, __ATOMIC_SEQ_CST,
+ __ATOMIC_ACQUIRE, __ATOMIC_RELEASE, __ATOMIC_ACQ_REL,
+ __ATOMIC_CONSUME, __PIC__, __PIE__, etc. Typical usage would be:
+
+bool err=false;
+int mypic = gcc_jit_magic_int("__PIC__", &err);
+if (err) somethinggotwrong();
+
+This function is expected to be rarely called, typically once at
+initialization time.
+
+ This API entrypoint was added in LIBGCCJIT_ABI_6; you can test for its
+ presence using
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_magic_int
+ */
+#define LIBGCCJIT_HAVE_gcc_jit_magic_int
+extern int gcc_jit_magic_int(const char*name, bool*errp);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
Index: gcc/jit/libgccjit.c
===
--- gcc/jit/libgccjit.c (revision 236583)
+++ gcc/jit/libgccjit.c (working copy)
@@ -23,6 +23,9 @@
#include "coretypes.h"
#include "timevar.h"
#include "typed-splay-tree.h"
+#include "cppbuiltin.h"
+#include "options.h"
+#include "flag-types.h"
#include "libgccjit.h"
#include "jit-recording.h"
@@ -2970,3 +2973,44 @@
call->set_require_tail_call (require_tail_call);
}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+int gcc_jit_magic_int(const char*name, bool*errp)
+{
+ static int major, minor, patchlevel;
+ if (!major) /* call once: */
+parse_basever (&major, &minor, &patchlevel);
+
+ RETURN_VAL_IF_FAIL (name,
+ errp?((*errp=true),0):0,
+ NULL, NULL,
+ "NULL name");
+ RETURN_VAL_IF_FAIL (name[0] == '_' && name[1] == '_',
+ errp?((*errp=true),0):0,
+ NULL, NULL,
+ "name should start with two underscores");
+#define HAVE_MAGIC_INT(NamStr,Val) do { \
+ if (!strcmp(name, NamStr)) { \
+ if (errp) *errp = false; \
+ return Val; }} while(0)
+ // keep these in alphabetical order...
+ HAVE_MAGIC_INT("__ATOMIC_ACQUIRE", MEMMODEL_ACQUIRE);
+ HAVE_MAGIC_INT("__ATOMIC_ACQ_REL", MEMMODEL_ACQ_REL);
+ HAVE_MAGIC_INT("__ATOMIC_CONSUME", MEMMODEL_CONSUME);
+ HAVE_MAGIC_INT("__ATOMIC_RELAXED", MEMMODEL_RELAXED);
+ HAVE_MAGIC_INT("__ATOMIC_RELEASE", MEMMODEL_RELEASE);
+ HAVE_MAGIC_INT("__ATOMIC_SEQ_CST", MEMMODEL_SEQ_CST);
+ HAVE_MAGIC_INT("__GNUC_MINOR__", minor);
+ HAVE_MAGIC_INT("__GNUC_PATCHLEVEL__", patchlevel);
+ HAVE_MAGIC_INT("__GNUC__", major);
+ HAVE_MAGIC_INT("__PIC__", flag_pic);
+ HAVE_MAGIC_INT("__PIE__", flag_pie);
+ HAVE_MAGIC_INT("__SANITIZE_ADDRESS__", flag_sanitize & SANITIZE_ADDRESS);
+ HAVE_MAGIC_INT("__SANITIZE_THREAD__", flag_sanitize & SANITIZE_THREAD);
+#undef HAVE_MAGIC_INT
+ RETURN_VAL_IF_FAIL_PRINTF1 (false,
Re: patch introducing a hook for lra register usage leveling
On Thu, May 30, 2013 at 04:20:46PM -0400, Vladimir Makarov wrote:
> Investigating size increase of LRA generated code on PPC64 (> 0.2%
> on SPEC2006), I found that register usage leveling can hurt
> cross-jumping optimization for ppc besides if-conversion one for
> targets with conditional execution.
>
> So I decided to introduce a machine target hook switching on the
> optimization (I believe introducing an option would be to much).
> The following patch implements it. Currently only x86/x86-64 uses
> register usage leveling.
Did you consider providing plugin hooks for that purpose?
It might be a good idea, for back-end related plugins (which probably don't
exist today).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH] Proof of concept: multiple gc heaps
On Fri, Jun 14, 2013 at 11:21:06PM -0400, David Malcolm wrote:
> I'm hoping that gcc 4.9 can support multiple "parallel universes" of gcc
> state within one process, to ultimately support gcc usage as a library,
> where multiple client threads can each have their own gcc context (or
> "universe").
>
> One issue with the above is the garbage collector.
>
> I think there are two possible ways in which "universe instances" could
> interact with the GC:
>
> (a) have the universe instances be GC-managed: all parallel universes
> share the same heap, requiring a rewrite of the GC code to be
> thread-safe,
>
> or
>
> (b) have the "universe instance"/context manage GC, so that the state of
> GC is per-universe: each universe has its own GC heap, entirely
> independent of each other universe's GC heap. You can't share GC
> pointers between universes.
>
> I don't think (a) is feasible.
I agree, but what would be the purpose to run many threads of GCC in parallel
which don't share anything?
At the very least, I would expect predefined global trees to be common to all
of them.
I'm thinking at least of The global_trees array.
And don't forget plugins, which can (and do, for MELT) run the Ggc collector,
and use the
PLUGIN_GGC_START, PLUGIN_GGC_MARKING, PLUGIN_GGC_END
I do think that making (in the long term) GCC usable as a library (like LLVM
is) is a
worthwhile goal, but I don't think that aiming that future library to be
multi-threadable
(or thread-friendly) is very realistic. At least, we should make the two goals
separate:
first, make GCC a library, then (and later) make that library thread friendly.
So I might not be very happy of your patch
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes
On Fri, 2013-07-26 at 11:04 -0400, David Malcolm wrote:
> This patch is the hand-written part of the conversion of passes from
> C structs to C++ classes. It does not work without the subsequent
> autogenerated part, which is huge.
>
> Given that the autogenerated part of the conversion is very large
> (500k), for the sake of human comprehension I have kept the change as
> two separate patches to keep the hand-written changes separate from the
> automatically-generated ones. I would commit these as two separate
> changes to SVN in order to keep this readability for posterity in the
> logs as well as at review-time.
>
> This pair of patches eliminates the mutable global variables
> representing the passes, allowing for multiple compilation contexts in
> one process, potentially with different combinations of passes, and with
> pass instance owning additional data.
>
> It converts the hierarchy of opt_pass types into an actual C++ class
> hierarchy, where each of:
>
> * gimple_opt_pass
> * rtl_opt_pass
> * ipa_opt_pass_d
> * simple_ipa_opt_pass
>
> all become subclasses of opt_pass.
[...]
This looks good to me. I suggest adding into the `opt_pass` class two
constant fields for the approximate source location of the pass, e.g. a
field const char* _file; and another const unsigned _lineno; initialized
with __FILE__ and __LINE__ respectively.
This won't cost much (we don't have zillions of instances of
opt_pass) and would help a lot finding where (in which source file)
an actual pass is.
This is particularly useful for newbies writing plugins (which are
trying to add new passes). It takes a lot of time to them to find which
actual source file inside the compiler is implementing a given
(existing) pass.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Passes are now C++ classes (was Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes)
On Mon, 2013-08-05 at 17:03 -0400, David Malcolm wrote:
> On Mon, 2013-07-29 at 15:41 -0600, Jeff Law wrote:
> > On 07/26/2013 09:04 AM, David Malcolm wrote:
> > > This patch is the hand-written part of the conversion of passes from
> > > C structs to C++ classes. It does not work without the subsequent
> > > autogenerated part, which is huge.
> > [ ... ]
> > With the changes from pipeline -> pass_manager this is fine. As is the
> > follow-up autogenerated patch.
>
> I've committed this and the other patches that needed to go with it to
> trunk, with the name fix, having successfully bootstrapped and tested
> them on x86_64-unknown-linux-gnu - so opt_pass is now a C++ class
> hierarchy, allowing for pass instances to hold pass-specific data
> (albeit not GTY refs yet),
Did you follow my suggestion of putting __FILE__ and __LINE__ in
instances of opt_pass? I really hope that will go into 4.9!
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
small patch to accept = inside plugin arguments
Hello All,
It should be perfectly possible for a plugin argument to contain the
equal sign.
For plugin with scripting or DSL behavior (like MELT, see
http://gcc-melt.org/ for more) it is useful to pass some commands
or expressions to the plugin. For MELT we might want to run
gcc -fplugin=melt -fplugin-arg-melt-mode=eval \
-fplugin-arg-melt-arg='(== 1 2)' empty.c
for plugins accepting some shell command to be run by system or popen,
passing -fplugin-arg-foo-command='env FOO=bar doit arg' would be
perfectly ok, but is not.
The small attached patch relative to trunk 201571 should solve the
issue.
# gcc/ChangeLog entry
2013-08-07 Basile Starynkevitch
* plugin.c (parse_plugin_arg_opt): Accept equal sign inside
plugin argument.
Comments are welcome. Ok for trunk?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/plugin.c
===
--- gcc/plugin.c (revision 201571)
+++ gcc/plugin.c (working copy)
@@ -241,16 +241,13 @@ parse_plugin_arg_opt (const char *arg)
}
else if (*ptr == '=')
{
- if (key_parsed)
-{
- error ("malformed option -fplugin-arg-%s (multiple '=' signs)",
- arg);
- return;
-}
- key_len = len;
- len = 0;
- value_start = ptr + 1;
- key_parsed = true;
+ if (!key_parsed)
+ {
+ key_len = len;
+ len = 0;
+ value_start = ptr + 1;
+ key_parsed = true;
+ }
continue;
}
else
GCC trunk 4.9: documentation patch on plugins
Dear all,
The attached patch to trunk svn.rev 207422 is slightly improving the
documentation
of plugins (notably the few features & bugfixes I have introduced in 4.9)
gcc/ChangeLog entry
2014-02-03 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
Comments are welcome. Recall that I am not a native English speaker,
so please improve my wordings in the documentation.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 207422)
+++ gcc/doc/plugins.texi (working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
Ping GCC trunk 4.9: documentation patch on plugins
Hello All,
I am pinging this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Addition of options in GCC
On Mon, Feb 24, 2014 at 12:32:22PM +0100, Alangi Derick wrote:
> Hi
> When looking at the gcc/gcc.c file, i noticed that some basic
> options were not added to notify the user of gcc to be able to use it
> and its essence. So due to this, i added some of the options like the
> -ansi option. This file contains some other options like the -w and -Q
> options.
gcc is mostly a driver program. The real work happens in cc1 or cc1plus (which
is started by gcc). So you need to look inside gcc/toplev.c and gcc/*.opt
files....
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH] Add some more headers to PLUGIN_HEADERS (PR plugins/59335)
On Wed, 2014-03-05 at 15:00 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR requests beyond the already commited ones some further headers.
>
> Tested with make install, ok for trunk?
I am not authorized to approve that, but I hope it will be committed.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Ping^2 GCC trunk 4.9: documentation patch on plugins
Hello All,
I am pinging again this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
(pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on febµ.17th
2014)
gcc/ChangeLog entry
2014-03-08 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
the patch:
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 207422)
+++ gcc/doc/plugins.texi(working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
#####
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Ping^3 GCC trunk 4.9: documentation patch on plugins
On Sat, 2014-03-08 at 11:15 +0100, Basile Starynkevitch wrote:
> I am pinging again this documentation patch
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
> (pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on
> febµ.17th 2014)
and also pinged at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00387.html on march 8th
2014
gcc/ChangeLog entry
2014-03-18 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention
PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain
PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after
PLUGIN_FINISH.
Explain what pragmas with expansion are.
the patch:
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 207422)
+++ gcc/doc/plugins.texi(working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing
callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO,
PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should
be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path
as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
#
Ok for 4.9?
Regards
Re: Ping^3 GCC trunk 4.9: documentation patch on plugins
Hello Diego & all,
Here is a slightly improved patch to follow Diego's comments on
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00863.html
(since Diego improved the wording extracted from comments
in gcc/plugin.def I am also patching the comments in that file).
### gcc/Changelog entry
2014-03-18 Basile Starynkevitch
* plugin.def: Improve comment for PLUGIN_INCLUDE_FILE.
* doc/plugins.texi (Plugin callbacks): Mention
PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain
PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after
PLUGIN_FINISH.
Explain what pragmas with expansion are.
the [improved] patch against trunk 208643 is attached.
Ok for GCC trunk 4.9?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 208643)
+++ gcc/doc/plugins.texi (working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given via the #line directive.
+ This could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are supporting
+preprocessor expansions. For an example of using such a pragma:
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 208643)
+++ gcc/plugin.def (working copy)
@@ -92,8 +92,8 @@
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
-/* Called when a file is #include-d or given thru #line directive.
- Could happen many times. The event data is the included file path,
+/* Called when a file is #include-d or given via the #line directive.
+ this could happen many times. The event data is t
Re: Ping^3 GCC trunk 4.9: documentation patch on plugins
On Tue, 2014-03-18 at 08:53 -0400, Diego Novillo wrote:
> OK with:
>
> +Pragmas registered with @code{c_register_pragma_with_expansion} or
> +@code{c_register_pragma_with_expansion_and_data} are supporting
> +preprocessor expansions. For an example of using such a pragma:
>
> s/are supporting/support/
> s/For an example of using such a pragma/For example/
>
Thanks for the review.
Committed revision 208660.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Mention of gcc 4.5 as first version with plugin support
On Fri, 11 Jan 2013 09:58:49 +0100
Dodji Seketeli wrote:
> Thank you Dave for this documentation patch that looks OK to my casual
> eyes. Let's CC the documentation maintainers.
>
> Dave Johansen a écrit:
>
> >
> > +GCC plugin support is available in GCC version 4.5.0 and
> > +later.
Maybe we should say that a later version is preferable.
IIRC 4.5 plugin support was not very good -it was more an experimental stage
than
anything else. I believe that we should not encourage people to write plugins
against
4.5.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [CPP] Add pragmas for emitting diagnostics
On Tue, Sep 25, 2012 at 04:25:08PM +0200, Florian Weimer wrote:
> This patch adds support for #pragma GCC warning and #pragma GCC
> error. These pragmas can be used from preprocessor macros, unlike
> the existing #warning and #error directives. Library authors can
> use these pragmas to add deprecation warnings to macros they define.
>
> Bootstrapped and tested on x86_64-redhat-linux-gnu, with no apparent
> regressions. Okay for trunk?
I can't approve your patch, but I find it useful and wish it would be accepted.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH] [MELT] An alternative probe for GCC MELT
On Wed, Sep 26, 2012 at 10:28:14PM +0200, Alexandre Lissy wrote:
> Hello,
>
> As I reported on the gcc-m...@googlegroups.com list, I experienced bad
> behavior of the GtkMM probe for MELT. I identified the issue as linked
> to the amount of inline buttons added in the source code, but was not
> able to fix or identify the root of the issue. Since I'm not very
> skilled with C++ and Gtk, I decided to provide another implementation of
> the probe, writing it using Qt4 and Python. I hope it makes the source
> easier to read and hack.
>
> It's now nearly as functionnal as the original one, so I'm proposing the
> attached patch that adds this probe under the contrib/ directory.
Thanks. I just commited svn rev 191773 on the MELT branch
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [6/6] Fold prev/next into gimple: do it
On Wed, 2 May 2012 03:47:17 +0200 (CEST)
Michael Matz wrote:
> There's one thing I'd like an opinion about: I've added two new flags to
> gimple_statement_base: start_of_seq and end_of_seq, and I had to
> shorten the uid member by two bits for that. The two flags are used only
> for asserts (though they are updated always, they just aren't read except
> in asserts). As I'm now finished developing this thing I'm not super sure
> about the usefullness of the asserts anymore, IIRC they didn't hit very
> often while developing; rather bugs usually turned into endless loops in
> sequence walkers. So, I'd be happy to take them out again, straighten the
> asserts and leave uid be a normal 32bit integer. Just tell me.
I believe that uid should stay normal integers. Plugins may find a use for all
the
available bits. And perhaps even developers of other passes.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PING PATCH: break lines in announce_function
Hello All,
I am pinging the patch http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
# patch
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 187587)
+++ gcc/toplev.c(working copy)
@@ -229,6 +229,12 @@
{
if (!quiet_flag)
{
+
+ static long count;
+ count++;
+ if (count % 8 == 0)
+putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, "%s ",
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
### gcc/ChangeLog entry
2011-05-16 Basile Starynkevitch
* toplev.c (announce_function): Output newline periodically.
###
Ok for trunk?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I am pinging the patch
> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
> > below for trunk svn 187587
--- gcc/toplev.c(revision 187587)
+++ gcc/toplev.c(working copy)
@@ -229,6 +229,11 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+ static long count;
+ count++;
+ if (count % 8 == 0)
+putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, "%s ",
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
> So - why? I like it the way it is.
Because, as I explained in
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
you have arbitrarily long output lines, and that is unpleasant, in particular
when running under gdb
or under emacs (also, there may be buffering issues: if GCC misbehave, stderr
might not be flushed
often enough...)
The announce_function is quite rarely really used (because quiet_flag is almost
always true),
and it is used mostly to debug GCC (or plugins), and in that case having not
too large output
is quite useful in practice. The patch above is quick & dirty but seems enough.
Do you want me to add a comment like /* Hack to avoid very large output lines.
*/ before?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: PING PATCH: break lines in announce_function
On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
> wrote:
> > On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> >> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> >> wrote:
> >> > Hello All,
> >> >
> >> > I am pinging the patch
> >> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
> >> > below for trunk svn 187587
> >
> > --- gcc/toplev.c (revision 187587)
> > +++ gcc/toplev.c (working copy)
> > @@ -229,6 +229,11 @@ announce_function (tree decl)
> > {
> > if (!quiet_flag)
> > {
> > + static long count;
> > + count++;
> > + if (count % 8 == 0)
> > + putc('\n', stderr);
> > +
> > if (rtl_dump_and_exit)
> > fprintf (stderr, "%s ",
> > identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME
> > (decl;
> >
> >
> >> So - why? I like it the way it is.
> >
> > Because, as I explained in
> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html without that patch
> > you have arbitrarily long output lines, and that is unpleasant, in
> > particular when running under gdb
> > or under emacs (also, there may be buffering issues: if GCC misbehave,
> > stderr might not be flushed
> > often enough...)
>
> stderr is unbuffered
>
> > The announce_function is quite rarely really used (because quiet_flag is
> > almost always true),
> > and it is used mostly to debug GCC (or plugins), and in that case having
> > not too large output
> > is quite useful in practice. The patch above is quick & dirty but seems
> > enough.
> > Do you want me to add a comment like /* Hack to avoid very large output
> > lines. */ before?
>
> No, I want the large line to stay as-is. It's pleasant for me.
Do you have any hints or tricks to have this work well when running cc1 under
emacs
(eg in a *shell* or *gud-cc1* Emacs buffer)?
Without that patch displaying happen too late (and eats a lot of Emacs CPU)!!
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [MELT] Add a few tree primitives
On Tue, 2 Aug 2011 17:02:05 +0200
Romain Geissler 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).
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).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [GCC-MELT-151] [MELT] Add a few tree primitives
On Tue, 2 Aug 2011 19:13:04 +0200
Romain Geissler 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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH] [MELT] Fix loading of .c files
On Mon, Aug 29, 2011 at 12:21:12PM +0200, Alexandre Lissy wrote:
> Files containing the MELT translated to C code were not loaded correctly
> due to bad search path when working with an installed plugin. Present
> commit fixes this by:
> - using a melt find to search in current dir
> - ensuring the melt_modulename in melt descriptor only contains the
>module name, and no path component
Are you sure of that patch? It seems that it loops on the hello world tiny
test I added in the MELT branch rev 178154
Does it work for you when merging with latest MELT updates (ie when applying
that patch to rev 178154 of the MELT branch?
(I am investigating)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH, libiberty] correct md5_process_bytes with unaligned pointers
On Fri, 16 Sep 2011 14:46:57 +0200
Pierre Vittet wrote:
> Hello,
[...]
> The patch also remove a preprocessor #if testing if
> _STRING_ARCH_unaligned is defined. This symbol is never defined in gcc
> and could be only used in CFLAGS. Looking at the code, it does not looks
> usefull to define it (and it is only tested on libiberty/md5.c and
> libiberty/sha1.c), as we already check the pointer alignement, so
> removing it clean the code. I searched on google, and it does not looks
> to be used. Does anyone want it or thing that it should not be removed?
>
> Ok for trunk ?
I can't formally approve this patch, but I do hope it will be reviewed and
approved soon.
See http://gcc.gnu.org/ml/gcc-help/2011-09/msg00126.html
and http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html
and
http://groups.google.com/group/gcc-melt/browse_thread/thread/292c394fea5089c7
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH, MELT] correct meltgc_string_hex_md5sum_file_sequence
On Mon, 19 Sep 2011 20:02:16 +0200
Pierre Vittet wrote:
> Hello
>
> Here is a patch allowing to compute correctly the md5 of a file sequence
> even with the bug rapported here:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html.
>
> The function will work with both gcc 4.6 without the patch and a gcc
> with the patch applied.
Thanks. I committed the patch (rev 178983 of MELT branch), with a slightly
changed
ChangeLog.MELT entry:
2011-09-19 Pierre Vittet
* melt-runtime.c (meltgc_string_hex_md5sum_file_sequence): Catenated
files stream call md5_process_block, we only call md5_process_bytes
for the last data of the last file.
Pierre found a painful bug in GCC trunk's libiberty/md5.c, which is impacting
GCC MELT.
The issue is that when fed with several files, a wrong checksum was computed,
because of
pointer alignment mess.
Pierre's current patch is workaround for MELT; but both Pierre & me hope that
the patch
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html will eventually be
reviewed and
accepted.
The workaround is still needed inside MELT, because we both want it to work as a
plugin with current gcc 4.6.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: misbehaviour with md5_process_bytes and maybe in optimization
On Fri, 23 Sep 2011 12:19:57 -0700
Ian Lance Taylor wrote:
> I committed this patch to mainline to fix the problem. Bootstrapped on
> x86_64-unknown-linux-gnu.
>
> 2011-09-23 Ian Lance Taylor
>
> * md5.c (md5_process_bytes): Correct handling of unaligned
> buffer.
This is *exactly* the same patch as
Pierre Vittet proposed in
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html
(but Pierre's patch has not been reviewed).
Perhaps the ChangeLog might also mention Pierre Vittet for that particular
patch???
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
patch about MELT for GCC extensions.html page
Hello All
Gerald suggested me to submit a patch to the http://gcc.gnu.org/extensions.html
page about GCC MELT.
I am attaching it.
Gerald, if the patch is OK, could you please apply it?
I am very uneasy about CVS for the GCC website.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--- extensions-old.html 2011-09-27 12:39:51.0 +0200
+++ extensions-new.html 2011-09-27 12:50:29.0 +0200
@@ -43,6 +43,19 @@
tree. Please direct feedback and bug reports to their respective
maintainers, not our mailing lists.
+http://gcc-melt.org/";>GCC MELT
+
+MELT is a high-level domain specific language to ease the
+ development of GCC extensions. It is available as a GCC experimental
+ branch on svn://gcc.gnu.org/svn/gcc/branches/melt-branch,
+ and also as a GCC [meta-] plugin (GPLv3 licensed, FSF
+ copyrighted).
+
+The MELT language is translated to C, and provides powerful
+ features (pattern-matching, functional, object, reflective
+ programming styles, ability to mix C and MELT code, Lisp look, ...)
+ to ease development of GCC plugin-like extensions.
+
http://pdp10.nocrew.org/gcc/";>PDP-10 port
This is an experimental port of GCC to the DEC PDP-10
Re: [PATCH 2/3] Use urandom to get random seed
On Wed, 28 Sep 2011 16:56:32 +0200
Andi Kleen wrote:
> > I suppose we might get interrupted before anything is read and
> > read can return with -1 (I suppose partial reads are quite unlikely
> > though)? Thus, don't we need the usual EINTR loop?
>
> When we get interrupted gcc will die. I don't think gcc handles any
> asynchronous signals, right?
That depends upon the signal. If we got SIGCHLD or SIGWINCH, the call to read
probably
gets EINTR, but the signal is ignored unless explicitly handled.
So I would suggest testing for EINTR.
Besides, perhaps some plugins could install their signal handlers
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [Patch] Support DEC-C extensions
On Thu, 29 Sep 2011 17:10:26 +0200
Tristan Gingold wrote:
> Hi,
>
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
> extension that is difficult to work-around as it is used in the system
> headers: varargs without named argument. It makes sense on VMS because of
> its ABI which pass the number of arguments used.
>
I believe that such an extension is useful on other systems, even when their
ABI don't
pass the number of arguments.
The use case I would have in mind is when the signature of the called function
(that is
the number & types of arguments) is determined by something else, perhaps a
global
variable or data. Think e.g. of a printf-like function, except that the format
string is
conventionally assigned to some fixed global before calling it.
Perhaps also the comments and explanation might reflect such kind of usage?
And perhaps then such an extension might be trigerred by a flag which don't
even mention
DEC. Eg -fveryvariadic-extensions ?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [Patch] Support DEC-C extensions
On Fri, 30 Sep 2011 09:24:03 +0200
Tristan Gingold wrote:
>
> On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> > I believe that such an extension is useful on other systems, even when
> > their ABI don't
> > pass the number of arguments.
> >
> > The use case I would have in mind is when the signature of the called
> > function (that is
> > the number & types of arguments) is determined by something else, perhaps a
> > global
> > variable or data. Think e.g. of a printf-like function, except that the
> > format string is
> > conventionally assigned to some fixed global before calling it.
>
> In fact you can't access to the arguments with ANSI-C as va_start needs a
> named argument. So you can't write such code.
I agree with that point, but that suggests that such a function is not DEC
like. (and
IIRC, in the good days of ten years ago, not today's ,
such a
function was possible).
I was only saying that there is no reason to call such an extension DEC-like.
And
apparently, you tested it on a x86/Linux which is not a DEC system :-)
And I do think that such an extension can be useful.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Initial shrink-wrapping patch
Hello,
Regarding this shrink-wrapping patch, I would suggest to describe, in a
comments of one or two sentences, what shkink-wrapping means in the context
of GCC.
http://en.wikipedia.org/wiki/Shrink_wrap does not help much in understanding
that.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [Patch] Support DEC-C extensions
On Mon, Oct 03, 2011 at 03:16:11PM +0200, Tristan Gingold wrote:
>
> On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
>
> Is it ok with this option name (-fdecc-extensions) or do you prefer a more
> generic option name,
> such as -fallow-unnamed-variadic-functions ?
My preference is to avoid using the -fdecc-extensions and use a more
explanative & generic option name.
But my (non-native English speaker) understanding of
-fallow-unnamed-variadic-functions is misleading: I read it to allow
anonymous functions (think of lambda) which happends to be variadic, which
is not what your patch gives.
What about -fallow-fully-variadic-functions or
-fallow-very-variadic-functions ?
And we could also imagine having a GCC #pragma which change the acceptance
of variadic functions.
By the way, I also regret the name of -fms-extensions option;
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Unnamed-Fields.html#Unnamed-Fields
because accepting an unamed field should not be percieved as MicroSoft
specific, but as a unseful language extension.
[My point is that language extensions should not be enabled by options
containing a brand or a trademark which suggested them, they should be named
by options which are evocative of what the extension provides.]
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: C++ PATCH to add auto return type deduction with -std=c++1y
On Sun, 25 Mar 2012 12:17:10 +0200 (CEST)
Marc Glisse wrote:
> On Sun, 25 Mar 2012, Jason Merrill wrote:
>
> > As I mentioned in my patch to add -std=c++1y, I've been working on a
> > proposal
> > for the next standard to support return type deduction for normal
> > functions,
> > not just lambdas. This patch implements that proposal.
>
> Nice. I like the way you seem to be going for the basic, uncontroversial
> version (extensions can always be discussed later), instead of trying to
> figure out something universal.
>
> If I understand correctly, you pick the first return statement for type
> deduction, and other returns (if any) are only checked afterwards for
> exact consistency [...]
I am not a C++ or a GCC front-end expert, but I am not sure it is the right
approach for
functions starting with
if (!p) return nullptr;
where p is a formal argument.
Or perhaps I am misunderstanding what Marc is saying.
I would rather suggest using all the return statements to infer the type of the
function,
not only the first one.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH: break lines in announce_function
Hello All,
When running cc1 in verbose mode, the announce_function from gcc/toplevel.c
displays the name of the function. However, it never emits any newline
characters. As a result, the stderr stream may contains very long lines,
which is visually unpleasant and tend to block Emacs when running cc1 -v
inside an Emacs buffer (or agdb session inside Emacs).
The attached patch (backbported from the MELT branch, where it is very
useful) fixes this issue by adding a newline once every eight identifiers.
gcc/ChangeLog entry
2011-02-10 Basile Starynkevitch
* toplev.c (announce_function): Emit newline periodically.
Ok for trunk?
Thanks
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/toplev.c
===
--- gcc/toplev.c (revision 184084)
+++ gcc/toplev.c (working copy)
@@ -234,6 +234,12 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
+
+ static long count;
+ count++;
+ if (count % 8 == 0)
+putc('\n', stderr);
+
if (rtl_dump_and_exit)
fprintf (stderr, "%s ",
identifier_to_locale (IDENTIFIER_POINTER (DECL_NAME (decl;
merged trunk 173996 into MELT branch
Hello
I merged the trunk into MELT branch.
Apparently the libgo buf on _IPPORT_RESERVED is still there
sysinfo.go:2178:7: error: redefinition of '_IPPORT_RESERVED'
sysinfo.go:1864:7: note: previous definition of '_IPPORT_RESERVED' was here
make[4]: *** [syscalls/syscall.lo] Error 1
make[4]: Leaving directory
`/usr/src/Lang/_Obj_Gcc_Melt/x86_64-unknown-linux-gnu/libgo'
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH, MELT] add dominance functions
On Sun, 22 May 2011 15:24:30 +0200 (CEST)
Gerald Pfeifer wrote:
> On Fri, 20 May 2011, Basile Starynkevitch wrote:
> > By the way, I am quite happy of Pierre patches to the MELT branch. Is
> > this enough to get him a write access to GCC SVN (all legalese is done)?
> > I fear that to really get that write access, Pierre would also need to
> > have accepted patches to the trunk (i.e. that writing good patches to a
> > branch is not enough)... I still don't understand the criteria to admit
> > Pierre to the Write After Approval list of maintainers with a write
> > access to GCC SVN...
>
> This indeed is a bit of an unusual situation. Are you planning to,
> realistically, merge the MELT branch into mainline at one point?
I am dreaming of either merging MELT into mainline, or at least having
it be an essential GCC plugin distributed with GCC (ideally, I
would prefer MELT to be merged, because that would give it more
visibility).
But I don't know how realistic is that dream. And I even don't know how
to make it happen. (The main issue being: who will review a 60KLOC
patch, most of it being in a "bizarre" language, MELT itself??)
As I told in informal discussions at some GCC Summits, I feel that MELT
is or may become a bit like the tree-browser.c : something useful
enough to some people to be integrated into mainline, even if most GCC
users don't even know about that functionality, and don't care or use
it when compiling their software. I am quite sure that 99% of GCC users
don't need or know about tree-browser.c and could use GCC with the
tree-browser disabled! I believe it could be the same for MELT: it
would be useful to a small fraction of users, but to them it would
bring enough value.
I am believing that Pierre's work can indeed attract much more attention
to MELT, because it shows very well MELT's interest: providing a
higher-level formalism which makes possible extra features (e.g.
specific warnings, in Pierre's GSOC work case) which would not be
realistically or economically possible without MELT.
The point is that MELT is usually quite near to the mainline: we
carefully avoid adding things into MELT which make MELT incompatible
with the mainline (unless we believe it shows a feature which should be
accepted), because we strongly want MELT to be either compilable as a
branch or as a plugin (to the next GCC release).
To be more specific, the difference between MELT (as a branch) and the
trunk are two lines in gengtype.c, a few lines in toplevel.c, some
additional options & parameters (common.opt, params.def), and the whole
MELT infrastructure (melt-runtime.[ch], melt/generated/*, melt/*) which
is by default disabled. So the behavior of the MELT branch when no MELT
specific program options are given is exactly the behavior of the trunk
(which was last merged into MELT). This is done on purpose, because
MELT can also be built and used as a GCC plugin, so its behavior is
"plugin-like": unless enabled (by options -fmelt*), MELT branch does
exactly what the trunk do. And even when required by -fmelt* arguments
to cc1, MELT branch behavior is exactly that of the melt.so plugin
(except that arguments which are -fmelt* to the MELT branch becomes
-fplugin-arg-melt-* arguments for -fplugin=melt). Internally, the MELT
branch registers a pseudo builtin/MELT plugin and uses the plugin hooks
(only when enabled).
The distributed MELT plugin is made of files extracted from the MELT
branch: the melt.so plugin is obtained by compiling melt-runtime.c as a
plugin...
Regards.
PS. I surely don't want to start a useless flamewar...
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: external declaration of dominance debug functions
On Mon, May 23, 2011 at 10:33:55AM +0200, Piervit wrote:
>
> Here is a two lines patch, allowing to use debug_dominance_info and
> debug_dominance_tree functions outside of gcc/dominance.c.
> +extern void debug_dominance_info (enum cdi_direction dir);
> +extern void debug_dominance_tree (enum cdi_direction dir, basic_block root);
> +
> #include "cfghooks.h"
Please put all declarations after the #include, and add a simple comment
describing
what the functions are doing.
With this improvement, I really hope the patch will be accepted,
because plugins really need to be able to call all the debug printing routines.
As I told many times, debug printing routines are more useful
for novice plugin developers that to experts working since many years on GCC.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: external declaration of dominance debug functions
On Mon, 23 May 2011 11:56:32 +0200
Piervit wrote:
> Le Mon, 23 May 2011 11:30:34 +0200,
> Richard Guenther a écrit :
>
> > On Mon, May 23, 2011 at 10:33 AM, Piervit wrote:
> > > Hello,
> > >
> > > Here is a two lines patch, allowing to use debug_dominance_info and
> > > debug_dominance_tree functions outside of gcc/dominance.c. For the
> > > moment, those functions are not declared in any gcc/*.h files (as
> > > far as I know after trying a grep). I have added them as external
> > > functions into gcc/basic-block.h. I feel this is useful to be able
> > > to call those functions from others files, for exemple from plugins.
> >
> > debug_* functions are supposed to be used from interactive gdb
> > sessions. They should not be advertised in public headers.
> >
> > Richard.
> >
> > > ChangeLog:
> > >
> > > 2011-05-23 Pierre Vittet
> > >
> > > * basic-block.h (debug_dominance_info, debug_dominance_tree):
> > > Add declaration.
>
> Thank you for your answer. I am sorry I was not aware of this rule.
> However I have try the following command in the gcc/ directory:
>
> pierre@zenwalk gcc %grep " debug_*" *.h | wc -l
> 231
>
> And the majority of the result are debug_* functions in header file,
> such as extern void debug_tree (tree); in tree.h, extern void
> debug_pass (void); in tree-pass.h and many others.
I was expecting Richard Guenther to say no at first to any patch,
especially when it is by a newbie. (Sorry Richie, but you do have your
reputation). But I would like to hear the position of others (in
particular Diego Novillo, who did long time ago accept a similar patch
from my part).
If really all debug_* functions are only for the ease of gdb, they
should not be declared in public header files and should not be
available to plugins. I believe on the contrary that plugin coders need
much more than experienced GCC hackers some debug help, and that indeed
the existing debug functions are helping them.
So I don't buy Richie's argument. Otherwise, someone would propose a
patch to remove the hundreds of debug_ declarations in public header
files (i.e. those visible to plugins), and if he did, I hope such a
naughty patch won't be accepted.
As I told many many times, debug functions are mostly useful to newbies
and to plugin developers. People (like Richie) working on GCC since the
previous century don't need them. But people working on some plugins
for a few months (or young newbies starting to work on GCC) will be
desperate if these functions vanished. And these debug functions don't
cost at all: they are never called in normal GCC executions! So I don't
understand why declaring in a plugin header an existing debug function
is such an issue.
Hence, as Pierre's GSOC mentor, I told him to perservate on this patch
and I hope it will be accepted some day!!
GCC need more facilities for newbies & plugin developpers, not less!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: external declaration of dominance debug functions
On Mon, 23 May 2011 22:23:01 +0200
Richard Guenther wrote:
[...]
> plugin header? what's that?
[...]
The headers made available to and installed for plugins,
thru the PLUGIN_HEADERS variable of the gcc/Makefile.in near line 4572
After installation, plugin developers can access them because they got
installed under $(gcc -print-file-name=plugin)/include
And I strongly believe that debug functions should be declared in some
files installed there. Which file is somehow an important
implementation detail.
I am not at all sure that putting all debug functions into a
debug-functions.h brings more modularity. Because debug functions belong
more to the sub-part of GCC they are related to. So I see no win in
moving debug_tree from tree.h to an hypothetical debug-functions.h;
hence I believe that Pierre's patch is indeed necessary.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH: Add pause intrinsic
On Wed, 25 May 2011 11:26:51 +0100
Andrew Haley wrote:
> On 05/24/2011 07:28 PM, H.J. Lu wrote:
>
> > This patch implements pause intrinsic suggested by Andi. OK
> > for trunk?
>
> What does "full memory barrier" here mean?
>
> +@table @code
> +@item void __builtin_ia32_pause (void)
> +Generates the @code{pause} machine instruction with full memory barrier.
> +@end table
>
> There a memory clobber, but no barrier instruction AFAICS. The
> doc needs to explain it a bit better.
Perhaps the doc might explain why is it necessary to have a builtin for
two independent roles: first, the full compiler memory barrier (which
probably means to spill all the registers on the stack - definitely a
task for a compiler); second, to "pause" the processor (which might
also mean to flush or invalidate some data caches). In particular, I
would naively imagine that we might have a more generic builtin for the
compiler memory barrier (which probably could be independent of the
particular ia32 target), and in that case which can't we just implement
the pause ia32 builtin as builtin_compiler_barrier(); asm ("pause")?
I find the above documentation too short and (being a non native
English speaker) I would prefer it to be much longer. I am not able to
suggest better phrasing (because I still did not entirely understood
what that builtin_ia32_pause is useful or needed).
And if there was a builtin_compiler_barrier () I would believe it can
have a lot of other uses. Any generated C code which wants some
introspection or some garbage collection write barrier might want it
too! [perhaps even I might find later such thing useful in C code
generated by MELT]
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH: Add pause intrinsic
On Wed, 25 May 2011 12:31:17 -0700
"H.J. Lu" wrote:
> On Wed, May 25, 2011 at 12:17 PM, Basile Starynkevitch
> wrote:
> > Perhaps the doc might explain why is it necessary to have a builtin for
> > two independent roles: first, the full compiler memory barrier (which
> > probably means to spill all the registers on the stack - definitely a
> > task for a compiler); second, to "pause" the processor (which might
> > also mean to flush or invalidate some data caches). In particular, I
> > would naively imagine that we might have a more generic builtin for the
> > compiler memory barrier (which probably could be independent of the
> > particular ia32 target), and in that case which can't we just implement
> > the pause ia32 builtin as builtin_compiler_barrier(); asm ("pause")?
> >
>
> We may need
>
> builtin_compiler_barrier();
> asm ("pause");
> builtin_compiler_barrier();
I don't understand why the second builtin_compiler_barrier() after the
asm ("pause") would be needed? Could you please explain why should we
need it? My feeling was that after the first builtin_compiler_barrier
() and hence after the asm ("pause") no register would contain valid
data, and the compiler would have to reload from memory everything. So
why do you think the second is needed???
Or perhaps I misunderstood completely all the issues!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH: Add pause intrinsic
On Thu, 26 May 2011 09:12:06 -0700
Andi Kleen wrote:
> Basile Starynkevitch writes:
> >
> > Perhaps the doc might explain why is it necessary to have a builtin for
> > two independent roles: first, the full compiler memory barrier (which
> > probably means to spill all the registers on the stack - definitely a
> > task for a compiler); second, to "pause" the processor (which might
> > also mean to flush or invalidate some data caches). In particular, I
> > would naively imagine that we might have a more generic builtin for the
> > compiler memory barrier (which probably could be independent of the
> > particular ia32 target), and in that case which can't we just implement
> > the pause ia32 builtin as builtin_compiler_barrier(); asm ("pause")?
>
> Because a pause() which can be freely moved around is pretty much
> useless. Think about it. And a memory barrier is the standard
> way to prevent moving around in relation to other code.
I thought that there is a syntax, perhaps volatile asm("pause"), which
forbids the compiler to move an asm statement? Or is the "memory" thing?
(I am not very used to GCC asm).
Still, is there a way to ask GCC to spill all data from registers to
memory, and to require GCC to consider all registers crappy and to
reload them when needed? I would imagine that such a feature is useful,
and most importantly, that it should not be specific to ia32!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH: Add pause intrinsic
On Thu, 26 May 2011 13:48:13 -0400
Paul Koning wrote:
> Relax? Weird. "Pause" is just as weird. It might be an ia32 instruction,
> so as an ia32 builtin it is a reasonable name But if you want a generic
> builtin, you need a name that actually has some plausible connection with
> what it does, and neither "pause" nor "relax" do that.
I still think that having a builtin which do a "compiler flush" that is
which spill all registers to memory is useful, eg a
builtin_compiler_flush()
And I even think there is another reason to use it. If you are
debugging a program compiled with -O2 -g, and if you know where there
could be a bug or a fault, temporarily adding a call to that
builtin_compiler_flush () would probably help the gdb debugger a lot.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH: adding invoking_program to plugin_gcc_version
Hello All,
The attached patch to trunk 174518 adds a field invoking_program to the
plugin_gcc_version structure. It informs the plugin about the program
"cc1", "cc1plus", "lto1" using them.
# gcc/ChangeLog entry ##
2011-06-01 Basile Starynkevitch
* gcc-plugin.h (struct plugin_gcc_version): Add invoking_program field.
* toplev.c (general_init): Fill invoking_program field of gcc_version.
* configure.ac: Ditto.
* configure: Regenerate.
See http://gcc.gnu.org/ml/gcc/2011-06/msg0.html &
http://gcc.gnu.org/ml/gcc/2011-05/msg00324.html for why I believe it is useful.
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/configure
===
--- gcc/configure (revision 174518)
+++ gcc/configure (working copy)
@@ -10977,7 +10977,9 @@ static char revision[] = "$gcc_REVISION";
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
- configuration_arguments};
+ configuration_arguments,
+/* Field invoking_program is set in general_init inside toplev.c. */
+ NULL};
EOF
# Internationalization
@@ -17517,7 +17519,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17520 "configure"
+#line 17522 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -17623,7 +17625,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17626 "configure"
+#line 17628 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
Index: gcc/toplev.c
===
--- gcc/toplev.c (revision 174518)
+++ gcc/toplev.c (working copy)
@@ -1148,6 +1148,7 @@ general_init (const char *argv0)
--p;
progname = p;
+ gcc_version.invoking_program = progname;
xmalloc_set_program_name (progname);
hex_init ();
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 174518)
+++ gcc/configure.ac (working copy)
@@ -1521,7 +1521,9 @@ static char revision[] = "$gcc_REVISION";
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
- configuration_arguments};
+ configuration_arguments,
+/* Field invoking_program is set in general_init inside toplev.c. */
+ NULL};
EOF
changequote([,])dnl
Index: gcc/gcc-plugin.h
===
--- gcc/gcc-plugin.h (revision 174518)
+++ gcc/gcc-plugin.h (working copy)
@@ -70,6 +70,8 @@ struct plugin_gcc_version
const char *devphase;
const char *revision;
const char *configuration_arguments;
+ /* Short string like "cc1" or "lto1" giving the invoking program. */
+ const char *invoking_program;
};
/* Object that keeps track of the plugin name and its arguments. */
Re: PATCH: adding invoking_program to plugin_gcc_version
On Wed, 1 Jun 2011 07:52:48 +0200
Basile Starynkevitch wrote:
>
> Hello All,
>
> The attached patch to trunk 174518 adds a field invoking_program to the
> plugin_gcc_version structure. It informs the plugin about the program
> "cc1", "cc1plus", "lto1" using them.
Wrong patch, here is a better one
# gcc/ChangeLog entry ##
2011-06-01 Basile Starynkevitch
* gcc-plugin.h (struct plugin_gcc_version): Add invoking_program field.
* configure.ac: Ditto.
* configure: Regenerate.
* plugin.c (initialize_plugins): Set invoking_program.
########
Ok if it bootstraps?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/configure
===
--- gcc/configure (revision 174518)
+++ gcc/configure (working copy)
@@ -10977,7 +10977,9 @@ static char revision[] = "$gcc_REVISION";
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
- configuration_arguments};
+ configuration_arguments,
+/* Field invoking_program is set in general_init inside toplev.c. */
+ NULL};
EOF
# Internationalization
@@ -17517,7 +17519,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17520 "configure"
+#line 17522 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -17623,7 +17625,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17626 "configure"
+#line 17628 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 174518)
+++ gcc/configure.ac (working copy)
@@ -1521,7 +1521,9 @@ static char revision[] = "$gcc_REVISION";
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
- configuration_arguments};
+ configuration_arguments,
+/* Field invoking_program is set in general_init inside toplev.c. */
+ NULL};
EOF
changequote([,])dnl
Index: gcc/gcc-plugin.h
===
--- gcc/gcc-plugin.h (revision 174518)
+++ gcc/gcc-plugin.h (working copy)
@@ -70,6 +70,8 @@ struct plugin_gcc_version
const char *devphase;
const char *revision;
const char *configuration_arguments;
+ /* Short string like "cc1" or "lto1" giving the invoking program. */
+ const char *invoking_program;
};
/* Object that keeps track of the plugin name and its arguments. */
Index: gcc/plugin.c
===
--- gcc/plugin.c (revision 174518)
+++ gcc/plugin.c (working copy)
@@ -632,6 +632,7 @@ initialize_plugins (void)
timevar_push (TV_PLUGIN_INIT);
#ifdef ENABLE_PLUGIN
+ gcc_version.invoking_program = progname;
/* Traverse and initialize each plugin specified in the command-line. */
htab_traverse_noresize (plugin_name_args_tab, init_one_plugin, NULL);
#endif
Re: [PATCH] c-pragma: adding a data field to pragma_handler
On Wed, 01 Jun 2011 18:54:38 +0200
Pierre wrote:
> This patch is about the pragmas.
>
> In c-family/c-pragma.h, we declare a pragma_handler which is a function
> accepting cpp_reader as parameter.
>
> I have changed this handler in order to accept a second parameter which
> is a void *, allowing to give extra datas to the handler. I think this
> data field might be of general use: we can have condition or data at
> register time that we want to express in the handler. I guess this is a
> common way to pass data to an handler function.
I find this patch interesting and useful (& not only for MELT).
A general coding rule in C seems to be that every time function can be
variably called thru indirect pointers (which can have several
different functions as value), they better take an extra data argument.
This is the case, in particular, inside Glib & GTK, inside the Linux
kernel, and on several other occurrences in GCC.
A use case of such pragma handlers with data for pragmas would be a
plugin which permit some messages to other channels than stdout/stderr
(e.g. other files, or a pipe, or the D-Bus, or a widget, or a web
service...). Then the same routine would handle
#pragma GCCPLUGIN message_to_file "foo"
and
#pragma GCCPLUGIN message_to_pipe "bar"
and the data pointer would be different (an fopen-ed or popen-ed
FILE*, or even an std::ostream& if the plugin is coded in C++).
I am not authorized to ok the patch (I believe the changelog had some
typos), but I hope someone will review & ok it.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Dump before flag
On Wed, 1 Jun 2011 13:26:24 -0700
Xinliang David Li wrote:
> Hi, this is a simple patch that support dump_before flag. E.g,
>
> -fdump-tree-pre-before
>
> This is useful for diffing the the IR before and after a pass.
Perhaps you forgot to actually attach the patch?
> Gcc dumping needs more cleanups -- such as allowing IR only dump,
> allowing IR dumping for a particular function etc. The exposure of
> 'dumpfile' (instead of a dumping_level () function) makes those change
> a little messy, but can be done.
I don't understand what you mean by a dumping_level () function. What
should that hypothetical function do? (I'm wrongly guessing it would
return an integer, but IIRC dumpfile is a FILE*)
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Add missing ChangeLog entry
On Thu, 02 Jun 2011 11:12:12 +0100
Nathan Sidwell wrote:
> On 06/01/11 15:32, Ian Lance Taylor wrote:
> > I noticed that we have a --with-specs option in gcc/configure.ac, added
> > in revision 155208 with this e-mail message:
> > http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00132.html
>
> sorry about that. How's the attachd documentation?
[...]
+@item --with-specs=@var{specs}
+Specify additional command line driver SPECS. This can be useful if
+you to turn on a non-standard feature by default without modifying the
+compiler's source code, for instance
+@option{--with-specs=%@{!fcommon:%@{!fno-common:-fno-common@}@}}.
I am not a native English speaker, and my english is bad. But perhaps it should
be
"this can be useful if you *want* to turn on"
I feel that the 'want' word is missing...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: libquadmath with older versions of gcc
On Thu, 2 Jun 2011 14:44:05 -0700 (PDT)
Syed Bilal Mehdi wrote:
[...]
> I am using old version of Matlab that requires me to use gcc-4.1 (or
> gcc-4.2.0 as the latest).
[...]
Do you understand why? My naive opinion is that, for C code, you could
use a latest gcc, even 4.6. (for C++ it really could be false, because
e.g. of mangling issues).
Did you try using gcc-4.6? What is concretely happening?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH] c-pragma: adding a data field to pragma_handler
On Fri, 03 Jun 2011 17:31:25 +0200
Pierre Vittet wrote:
> Thank you for your answer!
>
> I send you a new patch
> I have corrected the errors you raised.
>
> I have make my patch compatible with the old use of c_register_pragma
> and c_register_pragma_with_expansion.
I find the patch quite interesting, but I cannot approve it.
void
+c_register_pragma_with_expansion_and_data (const char *space, const char *name,
+
pragma_handler_2arg handler,
+ void * data)
Perhaps there are some spaces (vs tabs) issues here.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Patch: aesthetics for gcc/cp/cxx-pretty-print.c
On Sun, 05 Jun 2011 19:17:48 -0700
Bruce Korb wrote:
> It also caused a code analysis tool to wander off into the weeds.
> + if (DECL_NONSTATIC_MEMBER_FUNCTION_P (t))
> +pp_cxx_decl_specifier_seq (pp, TREE_TYPE (TREE_TYPE (t))), break;
> + /* FALLTHROUGH */
I believe the usual GCC style is using braces, e.g
if (DECL_NONSTATIC_MEMBER_FUNCTION_P (t))
{
pp_cxx_decl_specifier_seq (pp, TREE_TYPE (TREE_TYPE (t)));
break;
}
/* FALLTHROUGH */
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
