Assembly-level peepholes?
hello I haven't found anything in my digging, so I'd like to ask if anyone knows of any mechanism in GCC for conducting peephole optimization on generated code. GCC has a plugin mechanism. write your plugin doing so. I can imagine doing this as a pass over the generated code from within the backend, or as a separate process between cc1 and as. I'm working with a derivative of 4.3. Better share optimization code in the middle end. You really should upgrade your GCC. The current version is 15. Your GCC version is a decade old, and you won't find a lot of experts knowing that old version (4.3). NB. My open source project is an inference engine, see https://github.com/RefPerSys/RefPerSys/ -- Basile STARYNKEVITCH 8 rue de la Faïencerie 92340 Bourg-la-Reine mobile: +33 6 8501 2359 France http://starynkevitch.net/Basile/
About the effect of "O0" on inlining into a function
Hello Iain Sandoe wrote: If I declare a function __attribute__((noipa, optimize (“-O0”))), I was kinda expecting that it would not be optimized at all .. however it does not seem to prevent functions called by it from being inlined into its body .. I would suggest coding your GCC plugin to add such a behavior. (I think that your plugin should be open source) -- Basile STARYNKEVITCH 8 rue de la Faïencerie, 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ -gives my mobile number +33 6 8501 See/voir: https://github.com/RefPerSys/RefPerSys
Re: More C type errors by default for GCC 14
Hello all, After a suggestion by Eric Gallager Idea for a compromise: What if, instead of flipping the switch on all 3 of these at once, we staggered them so that each one becomes a default in a separate release? i.e., something like: - GCC 14: -Werror=implicit-function-declaration gets added to the defaults - GCC 15: -Werror=implicit-int gets added to the defaults - GCC 16: -Werror=int-conversion gets added to the defaults That would give people more time to catch up on a particular warning, rather than overwhelming them with a whole bunch all at once. Just an idea. Eli Zaretskii wrote on 10 may 2023, at 14:00 And that is just one example of perfectly valid reasons for not wanting or not being able to make changes to pacify GCC. Once again, my bother is not about "villains" who don't want to get their act together, my bother is about cases such as the one above, where the developers simply have no practical choice. And please don't tell me they should use an older GCC, because as systems go forward and are upgraded, older GCC will not work anymore. My experience is that for safety critical software (per DOI 178C, embedded in aircrafts, or for the French covid breathing machine on https://github.com/Recovid/Controller ) the regulations, funders, and authorities requires a very specific version of GCC with very specific compilation flags. Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the compilation flags (even changing -O1 by -O2) requires written (on paper) approval by a large number of human persons, and formal certifications (eg ISO9001, ISO27001 procedures) and lots of checks and headaches. I do know several persons making their living of these constraints. I do know several corporations making a living from them (and keeping decade older GCC compiler binaries on many disks). So I really think that for safety critical software (whose failure may impact lives) people are using an older (and well specified) GCC. Of course, to compile an ordinary business web service (e-shop for clothes) with e.g. libonion (from https://github.com/davidmoreno/onion ...) or to compile a zsh.org from source code (for or on a developer's laptop) the constraints are a lot lighter. Regards! PS : my pet open source project is the RefPerSys open source inference engine on http://refpersys.org/ and https://github.com/RefPerSys/RefPerSys ; it is explicitly thought for non-critical use (desktop, teaching, ...). -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
a small C (naive) program faster with clang than with gcc
Hello all, Consider the naive program (GPLv3+) to solve the cryptaddition `NEUF` + `DEUX` = `ONZE` onhttps://github.com/bstarynk/misc-basile/blob/master/CryptArithm/neuf%2Bdeux%3Donze/naive0.c (commit0d1bd0e <https://github.com/bstarynk/misc-basile/commit/0d1bd0ea8e2708036fcf126cc1f096be888360ab>) On Linux/x86-64 that source code compiled with gcc-12 -O3 is twice as slower as with clang -O3 (Debian/Sid or Ubuntu/22/10) Feel free to add it to some testsuite! Thanks -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ & refpersys.org
Re: No warning about duplicate values in enum
On 3/13/23 14:29, Marek Polacek wrote:
On Sat, Mar 11, 2023 at 04:48:14PM +, Jonathan Wakely via Gcc wrote:
On Sat, 11 Mar 2023, 12:53 Basile Starynkevitch,
wrote:
Hello all,
Andrea observed that:
In gcc 8.3.0, compiling
enum
test
{
FIRST = 1,
SECOND = 1,
THIRD = 2
};
int
main (void)
{
return 0;
}
generates no warning even with -Wextra.
I believe that the C standard (which I don't have here, but see also
https://port70.net/~nsz/c/c11/n1570.html or buy it from ISO) explicitly
allow duplicate values in enum.
Of course it does, it's perfectly valid. Nobody has said it should be
rejected. The request is for a warning, because for *some* uses of enums
duplicates are not wanted.
And as I said in the other thread about the very same issue, it's
<https://gcc.gnu.org/PR16186> which is assigned to me and I hope to
implement it for GCC 14.
Marek
Then consider perhaps:
prototyping that warning in your own GCC plugin (and test it on a bunch
of existing open source software).
adding some explicit new warning option to enable that new warning or
adding another option to disable that warning in a compilation unit.
adding some explicit #pragma to disable that new warning (with the hope
that tools generating C++ code would later -in 2024- emit the pragma
appropriately)
Since there are some valid, probably weird, cases (notably generated C++
code, or low level driver code where two different enum names need to
share some common values, ) where having duplicate values in enum
may make sense.
Regards
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org
No warning about duplicate values in enum
Hello all,
Andrea observed that:
In gcc 8.3.0, compiling
enum
test
{
FIRST = 1,
SECOND = 1,
THIRD = 2
};
int
main (void)
{
return 0;
}
generates no warning even with -Wextra.
I believe that the C standard (which I don't have here, but see also
https://port70.net/~nsz/c/c11/n1570.html or buy it from ISO) explicitly allow
duplicate values in enum.
For readability of some weird code, or in the case of C code generated by other
tools.
By the way, gcc version 12.2.0 (Debian 12.2.0-14) don't emit any warnings
neither when used on your example as gcc -Wall -Wextra -fanalyzer /tmp/andrea.c
-o /tmp/andrea
If you really want to get warnings, consider writing your GCC plugin (perhaps
starting with https://github.com/bstarynk/bismon/ ) or using static
analysis tools like https://frama-c.com/
Regards.
NB my pet open source project is the RefPerSys open source inference engine
(work in progress) on http://refpersys.org/
--
Basile Starynkevitch
92340 Bourg-la-Reine, France
http://starynkevitch.net/Basile/ and http://refpersys.org/
static analysis in GCC (starting from Bismon plugin)
Hello all I don't have much time to actively contribute to GCC, but those interested in static analysis with it might start (or reuse some code) from the Bismon <https://github.com/bstarynk/bismon> plugin (or consider also using the Frama-C <https://frama-c.com/> framework) Cheers PS. My pet open source project is the RefPerSys <http://refpersys.org/> open source inference engine with some code on https://github.com/RefPerSys/RefPerSys (if interested contact me by email to bas...@starynkevitch.net or basile.starynkevi...@cea.fr ...) -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ & refpersys.org
GCC -ftime-trace
Hello all, Shivansh Khare wrote: I have looked into the different starter projects that are offered in the [Wiki GSoC page](https://gcc.gnu.org/wiki/SummerOfCode) and I was particularly interested in the `-ftime-trace` project. The following is what is given as a short description about the problematic: "Implement something similar to Clang's -ftime-trace feature which generates performance reports that show where the compiler spends compile time. For more information, please check the following blog post. Are you aware of the existing -ftime-report option to GCC 12 or later? On Linux (and probably many other POSIX) systems, at least in straight (non-cross) x86-64 GCC compilers, implementing that should be not very difficult. Here are some insights. Read carefully https://man7.org/linux/man-pages/man7/time.7.html First, you could experiment by writing a GCC plugin doing that timing (in some experimental way). https://gcc.gnu.org/onlinedocs/gccint/Plugins.html Maybe consider later providing such a "standard" GCC plugin to do the timing. Modifying the pass manager https://gcc.gnu.org/onlinedocs/gccint/Pass-manager.html#Pass-manager to use clock_gettime system call. See https://man7.org/linux/man-pages/man2/clock_gettime.2.html It is related to plugin gate functions... Regards. BTW, my pet open source project is http://refpersys.org/ (symbolic inference engine, work in progress). -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: GSoC: Working on the static analyzer
On 2/14/22 13:59, Basile Starynkevitch wrote:
Hello,
Mir Immad asked:
Should the analyzer warn for code like this "when open fails" (like strchr
does when 'strchr' returns NULL)
int fd = open("NOFILE", O_RDONLY);
write(fd, "a", 1);
because of the bad file descriptor.
unless it is written like this:
if (!errno)
write(fd, "a", 1);
My opinion is yes, in most cases. BTW, the write should fail for a
read-only file descriptor.
A case (on Linux) where a check is probably not needed: isint
fd=open("/proc/self/exe", O_RDONLY); or int fd=open ("/dev/random",
O_RDONLY); done *near the beginning* of main. There are only
pathological cases where they won't succeed. I suspect that except for
very critical executable, testing such failures is practically useless.
And your analyzer might start from https://github.com/bstarynk/bismon/
or use https://frama-c.com/ <https://frama-c.com/>
PS. My pet project is http://refpersys.org/ (Soon generating code
compiled by GCC). It is not GCC related.
Be of course aware of Rice's theorem
<https://en.wikipedia.org/wiki/Rice%27s_theorem> 😁 so don't expect
writing the ultimate, perfect, static source code (or Gimple code) analyzer.
Cheers
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
GSoC: Working on the static analyzer
Hello,
Mir Immad asked:
Should the analyzer warn for code like this "when open fails" (like strchr
does when 'strchr' returns NULL)
int fd = open("NOFILE", O_RDONLY);
write(fd, "a", 1);
because of the bad file descriptor.
unless it is written like this:
if (!errno)
write(fd, "a", 1);
My opinion is yes, in most cases. BTW, the write should fail for a
read-only file descriptor.
A case (on Linux) where a check is probably not needed: isint
fd=open("/proc/self/exe", O_RDONLY); or int fd=open ("/dev/random",
O_RDONLY); done *near the beginning* of main. There are only
pathological cases where they won't succeed. I suspect that except for
very critical executable, testing such failures is practically useless.
And your analyzer might start from https://github.com/bstarynk/bismon/
or use https://frama-c.com/ <https://frama-c.com/>
PS. My pet project is http://refpersys.org/ (Soon generating code
compiled by GCC). It is not GCC related.
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Your GSoc'22 submission for GCC
Hello Mir Mimmad, If your future GSoC submission is about middle-end extensions to improve GCC warnings, you might consider starting from the Bismon static source code analyzer plugin on https://github.com/bstarynk/bismon/ <https://github.com/bstarynk/bismon/> and some /unofficial/ documentation on http://starynkevitch.net/Basile/bismon-doc.pdf <http://starynkevitch.net/Basile/bismon-doc.pdf> (in PDF format, A4 paper) Bismon is probably ending because of lack of funding. You could study its source code and (if your teachers and funding organizations agree) continue the work on it. I am supposed to work on Frama-C <https://frama- c.com/> instead next week (starting from october 2021). You could be interested by the DECODER European project, see http://www.decoder-project.eu/ <http://www.decoder-project.eu/> Regards. PS. My pet open source project is RefPerSys <http://refpersys.org/> (symbolic artificial intelligence). Jacques Pitrat's last book Artificial Beings: the Conscience of a Conscious Machine (ISBN-13: 978-1848211018) could interest you. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Exact inform format escape sequence (GCC 10 or GCC 11)
On 9/14/21 11:32 AM, Martin Liška wrote: On 9/10/21 15:05, Basile Starynkevitch wrote: Hello all, In the Bismon static source code analyzer on https://github.com/bstarynk/bismon/ commit ad8b6270691e (funded by http://decoder-project.eu/ ) which contains some GPLv3+ GCC plugin code under directory gccplugins/ I am getting when compiling it gcc10_metaplugin_BMGCC.cc: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: gcc10_metaplugin_BMGCC.cc:165:85: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 165 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: datestamp difference for %s:\n" | ^~~ 166 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc:169:84: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 169 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: devphase difference for %s:\n" | ^~~ 170 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc:174:89: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 174 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: configuration difference for %s:\n" | ^~~ 175 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc: In function ‘void parse_plugin_arguments(const char*, plugin_name_args*)’: gcc10_metaplugin_BMGCC.cc:405:53: warning: unquoted sequence of 2 consecutive space characters in format [-Wformat-diag] 405 | inform (UNKNOWN_LOCATION, "Bismon plugin %qs (%s:%d) will handle GCC include-file events with prefix %qs", | ^~ Hello. The warning -Wformat-diag is internal GCC warning that hasn't been documented. I'm CC'ing the warning author. Where can I read the complete specification of % escape sequences for inform? You can read it just in source code if I'm correct, that's the only option you have: gcc/c-family/c-format.c:3031. Sorry, even after looking inside it (function check_tokens presumably), I don't understand them. Could anyone on the list give a better explanation, or at least a dozen of examples covering most of the cases! Thanks -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Exact inform format escape sequence (GCC 10 or GCC 11)
Hello all, In the Bismon static source code analyzer on https://github.com/bstarynk/bismon/ commit ad8b6270691e (funded by http://decoder-project.eu/ ) which contains some GPLv3+ GCC plugin code under directory gccplugins/ I am getting when compiling it gcc10_metaplugin_BMGCC.cc: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: gcc10_metaplugin_BMGCC.cc:165:85: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 165 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: datestamp difference for %s:\n" | ^~~ 166 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc:169:84: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 169 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: devphase difference for %s:\n" | ^~~ 170 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc:174:89: warning: unquoted whitespace character ‘\x0a’ in format [-Wformat-diag] 174 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN: configuration difference for %s:\n" | ^~~ 175 | " plugin has %s, GCC had %s; this is risky.", | ~~ gcc10_metaplugin_BMGCC.cc: In function ‘void parse_plugin_arguments(const char*, plugin_name_args*)’: gcc10_metaplugin_BMGCC.cc:405:53: warning: unquoted sequence of 2 consecutive space characters in format [-Wformat-diag] 405 | inform (UNKNOWN_LOCATION, "Bismon plugin %qs (%s:%d) will handle GCC include-file events with prefix %qs", | ^~ Where can I read the complete specification of % escape sequences for inform? Thanks Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
GCC [RFC] Whole Program Devirtualization
Hello Feng Xue OS Your project is interesting, but ambitious. I think the major points are: *whole program analysis*. Static analysis tools like https://frama-c.com/ <https://frama-c.com/> or https://github.com/bstarynk/bismon/ <https://github.com/bstarynk/bismon/> could be relevant. Projects like https://www.decoder-project.eu/ <https://www.decoder-project.eu/> could be relevant. With cross-compilation, things are becoming harder. *abstract interpretation* might be relevant (but difficult and costly to implement). See wikipedia. *size of the whole program which is analyzed*. If the entire program (including system libraries like libc) has e.g. less than ten thousand routines and less than a million GIMPLE instructions in total, it make sense. But if the entire program is as large as the Linux kernel, or the GCC compiler, or the Firefox browser (all have many millions lines of source code) you probably won't be able to do whole program devirtualization in a few years of human work. *computed gotos* or *labels as values* (see https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html <https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html> for more) are making this difficult. But they do exist, and probably could be hidden in GNU glibc or libstdc++ internal code. *asm**statements are difficult*. They usually appear inside your libc. How would you deal with them? *Can you afford a month of computer time to compile a large software* with your whole program devirtualizer? In most cases, not, but Pitrat's book /Artificial Beings - the conscience of a conscious machine/ (ISBN 9781848211018) suggest cases where it might make sense (he is explaining a "compiler like system" which runs for a month of CPU time). My recommendation would be to *code first a simple GCC plugin as a proof of concept thing*, which reject programs which could not be realistically devirtualized, and store somewhere (in some database perhaps) a representation of them otherwise. I worked 3 years full time on https://github.com/bstarynk/bismon/ <https://github.com/bstarynk/bismon/> to achieve a similar goal (and I don't claim to have succeeded, and I don't have any more funding). My guess is that some code could be useful to you (then contact me by email both at work basile.starynkevi...@cea.fr and at home bas...@starynkevitch.net ) The most important thing: limit your ambition at first. Write a document (at least an internal one) stating what you won't do. Cheers -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
About porting GCC to backends which have a small number of registers. ....
To give just one small practical example, I'm told (by people who are more familiar with GCC internals than I) that it is not feasible with today's GCC to port to backends which have a small number of registers. I think (not sure) that could be attributed to j...@darrington.wattle.id.au - apologies if I am wrong. Why? GCC is doing many optimisations at the GIMPLE level. Why won't it be possible (even if very painful) to transform GIMPLE to some architecture with very few registers. IIRC, the TMS9900 (a microprocessor from texas instruments, in 1976) had very few hardware registers. One of them being a "pointer" to some "virtual register bank" on the call stack. http://www.bitsavers.org/components/ti/TMS9900/TMS_9900_Microprocessor_Data_Manual_May76.pdf I don't seen any impossibility in generating such instructions from GIMPLE. Of course, I am not candidate to do so... Cheers -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
static analysis above GCC (GSoC 2021)
On Fri, 2021-03-05 at 17:04 +0530, Ankur Saini via Gcc wrote: Hello, Hi Ankur While looking for some project to contribute on for GSOC 2021, I came across project about extending static analyser pass, especially the part that involve adding C++ support to it. You could look at the DECODER European project on https://www.decoder-project.eu/ and at the Bismon static source code analyzer funded by it (for a few more weeks) https://github.com/bstarynk/bismon Because of lack of funding, Bismon will probably be stopped in a few weeks. Cheers PS. My pet open source project is http://refpersys.org/ and I am seeking funding and applications for it. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
example GCC plugins?
Hello list, Does the GCC community consider adding example plugins in the next release of GCC? I would be happy (and I could get funded to, e.g. by CHARIOT <https://www.chariotproject.eu/>) to contribute one (of course GPLv3+ licensed, and FSF copyrighted). But before really starting coding it, I need (in particular for funding organizations, notably H2020 <https://en.wikipedia.org/wiki/Framework_Programmes_for_Research_and_Technological_Development#Horizon_2020>) to have some assurance that my plugin might be incorporated in the next GCC release. (BTW, I was the GCC MELT <http://starynkevitch.net/Basile/gcc-melt/> guy, and actively contributed, with Jérémie Salvucci, to GCC plugin infrastructure) The plugin I have in mind would embed some Turing complete interpreter with sqlite <https://sqlite.org/> and JSONRPC <https://www.jsonrpc.org/> abilities or HTTPS REST abilities (I started clips-rules-gcc <https://github.com/bstarynk/clips-rules-gcc>, but I tend to believe that rewriting something from scratch, above GCC garbage collection, would be easier). This in relation with Bismon <https://github.com/bstarynk/bismon/> (a GPLv3+ software described here <http://starynkevitch.net/Basile/bismon-chariot-doc.pdf>). Funding agencies and employer won't allow me to code a plugin which has absolutely no change to be used. Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
[off-topic] freelancing GCC plugin development activity
Hello List, This is off-topic here, but I would be interested in free-lance developing of GCC plugins (working remotely mostly from home, near Paris, France) for clients or corporations in the Euro zone. If some of you is interested by having me as a sub-contractor, please contact me privately by email to bas...@starynkevitch.net Thanks for reading. Cheers PS. My resume is here: http://starynkevitch.net/Basile/cv-Basile-Starynkevitch.pdf -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: GCC 8: adding, thru a plugin, an analyzing RTL pass after pro_and_epilogue issue with its reference_pass_name
On 4/10/19 8:44 PM, David Malcolm wrote:
On Wed, 2019-04-10 at 17:53 +0200, Basile Starynkevitch wrote:
I don't want to pollute the mailing list archive. My previous email is
on https://gcc.gnu.org/ml/gcc/2019-04/msg00133.html so please refer to
it. And that previous email mentions
http://starynkevitch.net/Basile/chariotdemo-2019-Apr-10-5414f7e3a173.tar.bz2
which is my self-contained example code.
Thanks for your help. I finally found my bug. It was my fault. I
incorrectly coded:
const pass_data pass_data_chariot_framesize =
{
GIMPLE_PASS, /* type */ /// WRONG should be RTL_PASS
"chariot_framesize", /* name */
OPTGROUP_NONE, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_ssa, /* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
0, /* todo_flags_finish */
};
and then I inserted such a wrong pass (it is not possible to insert a
GIMPLE_PASS after an existing RTL_PASS).
However, the result error message is very cryptic:
cc1: fatal error: pass ‘pro_and_epilogue’ not found but is referenced by
new pass ‘chariot_framesize’
perhaps the error message should mention a type mismatch.
Thanks for your help.
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
GCC 8: adding, thru a plugin, an analyzing RTL pass after pro_and_epilogue issue with its reference_pass_name
Hello All, This is work done for the CHARIOT H2020 project (see https://www.chariotproject.eu/ for more context) in relation with my BISMON project (see http://github.com/bstarynk/bismon/ for more, and, if you want more context, read the draft report on http://starynkevitch.net/Basile/bismon-chariot-doc.pdf but skip the few first pages for H2020 managers). I have to make a preliminary proof-of-concept that my BISMON project could be useful, with some ad-hoc GCC 8.3 plugin, to compute a crude approximation of the call stack of a tiny freestanding kernel (for x86 in 32 bits, so compiled with: gcc-8 -ffreestanding -m32 -O2 -Wall -fstack-usage and my plugin). I am working right now on that hand-written GCC 8.3 plugin. It inserts two GCC passes, and both passes are only analyzing passes (they don't change a single bit of GIMPLE or RTL representations). The first pass, named chariot_callgraph, is (oversimplifying) printing the call graph (and I will improve later that pass to communicate with BISMON). It is a pass of kind GIMPLE_PASS successfully inserted after the reference_pass_name "sra" and it works well enough. The second pass, named chariot_framesize, is (oversimplifying) expected to run with the printing the call frame size (and I will improve later that pass to communicate with BISMON). I want to insert that second pass following this explanation (in a comment of mine). /* the fun->su exists as soon as -fstack-usage is passed, but it is filled much later, by the RTL pass named "pro_and_epilogue" at gcc-8.3.0/gcc/config/i386/i386.c:13930 in function ix86_expand_prologue; that pass is pass_data_thread_prologue_and_epilogue defined in gcc/function.c line 6553 ... */ To insert that second pass, I tried many things and failed. I was expecting that an rtl- prefix is needed for an RTL pass. My plugin_init contains struct register_pass_info my_framesize_pass_info; my_framesize_pass_info.pass = make_pass_chariot_framesize (g); //#warning the below reference pass name is wrong for my_framesize_pass_info my_framesize_pass_info.reference_pass_name = "rtl-pro_and_epilogue"; my_framesize_pass_info.ref_pass_instance_number = 1; my_framesize_pass_info.pos_op = PASS_POS_INSERT_AFTER; register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &my_framesize_pass_info); But for some reason I cannot understand the reference_pass_name is wrong. Using "rtl-pro_and_epilogue" don't work. And I tried many variants without any success during several hours. So what is the reference_pass_name to use with register_callback like above to mention that pass_data_thread_prologue_and_epilogue defined in gcc/function.c line 6553 ? The entire code (of that proof-of-concept work in progress) is temporarily available on http://starynkevitch.net/Basile/chariotdemo-2019-Apr-10-5414f7e3a173.tar.bz2 which is a small archive of 14340 bytes. Please notice that the code I have written in collaboration with my colleagues Franck Védrine (in BCC) and Yves Lhuillier at CEA LIST is under GPLv3+ license. But that example also contains some third-party tiny code taken from https://wiki.osdev.org/Bare_Bones and in good faith we don't know what license is that code (files kernel.c etc...) but we guess it is morally in the public domain or open source (but we are not lawyers) since given as an example on some wiki page. Regards -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: Warning for C Parameter Name Mismatch
On 3/10/19 12:54 PM, David Brown wrote:
On 10/03/2019 07:11, Basile Starynkevitch wrote:
(I am reading the GCC mailing list in digest mode)
On 3/9/19 10:58 PM, gcc-digest-h...@gcc.gnu.org wrote:
On Fri, 8 Mar 2019, Joel Sherrill wrote:
Can gcc report when the parameter name in a C prototype
does not match that used in the implementation?
int f(int x);
int f(int y) {...}
I think this would be normal and expected - an installed header
would use
a reserved-namespace name for the parameter while the implementation
uses
a non-reserved name that's more convenient for use within the
implementation. (Thus anything like this would only be useful if it
can
know that it's e.g. OK to have __y and y as the names, and some code no
doubt uses other such conventions relating the two names.)
I can appreciate that a warning like this is not for everyone. But
/I/ would like and use such a warning for my own code.
May I remind to all that this is a typical case for you writing a GCC
plugin. You want a warning that few other people want, and that
warning is tied to your particular coding style.
You could avoid that warning by avoid naming the parameters in your
header files, so you would declare
int f (int /*x*/); in your header file.
You might want to get a warning, but since it is not of general use
(as many explained, not using the same name in the header and in the
implementation of a given function parameter makes a lot of sense in
general, even if you dislike such as style) you really should
consider writing your own GCC plugin for that purpose.
How to write such a GCC plugin is a different question, and should be
asked as such.
Cheers.
I fully agree that this is not a warning everyone will want - but I
disagree with the idea that it is a specialist or unusual warning.
Remember, no one is asking for it to be in -Wall or -Wextra. gcc has
many, many warnings available, and a large proportion of them will
only be useful to a small proportion of users. You could certainly
say that of things like "-Wmissing-prototypes",
"-Wmissing-declarations" and "-Wredundant-decls". I fail to see that
this suggestion is at all different.
In particular, I see this warning being of little use for large C /
C++ applications with code split into multiple libraries. But I see
it as being of a good deal of use in small-systems embedded
programming where you have a smaller code base, all compiled together
in one project, and where coding conventions and styles are often
strict. That will apply to only a very small proportion of people
programming for x86-64 targets - but a very high proportion of those
programming for AVR, msp430, ARM Cortex-M, and most of the other
targets of gcc. It is easy to forget or underestimate the huge range
of types of programming done with gcc - there are many of us for whom
warnings like this would be a useful tool.
However, you are right that plugins could be a way to achieve this. I
think the Python plugin could be a good way to prototype features like
this - and if it is useful, then it could be moved into gcc main.
In the long term, the question becomes philosophical. I would be really
happy if every future GCC release would come with a small set of
"example" plugins for various unusual warnings. And I even think that
such an approach will favor outside people to write plugins for their needs.
I am not so sure that making an even larger cc1plus binary is wanted.
Of course, I am making the hypothesis that plugins are as necessary as
directories to host GCC.
Cheers
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
Re: Warning for C Parameter Name Mismatch
(I am reading the GCC mailing list in digest mode)
On 3/9/19 10:58 PM, gcc-digest-h...@gcc.gnu.org wrote:
On Fri, 8 Mar 2019, Joel Sherrill wrote:
Can gcc report when the parameter name in a C prototype
does not match that used in the implementation?
int f(int x);
int f(int y) {...}
I think this would be normal and expected - an installed header would use
a reserved-namespace name for the parameter while the implementation uses
a non-reserved name that's more convenient for use within the
implementation. (Thus anything like this would only be useful if it can
know that it's e.g. OK to have __y and y as the names, and some code no
doubt uses other such conventions relating the two names.)
I can appreciate that a warning like this is not for everyone. But
/I/ would like and use such a warning for my own code.
May I remind to all that this is a typical case for you writing a GCC
plugin. You want a warning that few other people want, and that warning
is tied to your particular coding style.
You could avoid that warning by avoid naming the parameters in your
header files, so you would declare
int f (int /*x*/); in your header file.
You might want to get a warning, but since it is not of general use (as
many explained, not using the same name in the header and in the
implementation of a given function parameter makes a lot of sense in
general, even if you dislike such as style) you really should consider
writing your own GCC plugin for that purpose.
How to write such a GCC plugin is a different question, and should be
asked as such.
Cheers.
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
[RFC] Adding Python as a possible language and it's usage
Hello All, In https://gcc.gnu.org/ml/gcc/2018-07/msg00233.html Martin Liška wrote: I've recently touched AWK option generate machinery and it's quite unpleasant to make any adjustments. My question is simple: can we starting using a scripting language like Python and replace usage of the AWK scripts? It's probably question for Steering committee, but I would like to see feedback from community. I would suggest also (and perhaps instead) considering using GNU Guile https://www.gnu.org/software/guile/ (personally, I prefer Guile to Python, but that is just my preference) Since Guile is the preferred GNU scripting language (for example Guile is a GNU project, but AFAIK Python is not). BTW, I dislike Python syntax (my personal taste is an allergy to significant spaces, but I admit it is just a matter of taste and I could contribute some Python code in the future if it becomes needed). Also, I am noticing that these days the Python project might have some governance issues (see e.g. https://lwn.net/Articles/759654/ in case you did not heard about it). However, the idea of depending more deeply on a good scripting language in GCC is very pleasant. Regards -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Ann: MELT plugin 1.3 release candidate 2 for GCC 5 or GCC 6
Dear All,
It is my pleasure to announce the MELT plugin 1.3 release candidate 2
for GCC 5 & GCC 6
(hosted and usable on Linux preferably).
MELT -see http://gcc-melt.org/ for more (or
http://starynkevitch.net/Basile/gcc-melt/ which points to the same web
pages and resources) - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
Please download the bzip2 compress source tar archive from
http://gcc-melt.org/melt-1.3-rc2-plugin-for-gcc-5-or-6.tar.bz2
It is a file of 4013849 bytes (3.9Mbytes) and md5sum
eb4df214b293caabec07be4a672eda4e
NEWS for 1.3 MELT plugin for GCC 5 & GCC 6
[[may XX, 2016]]
Bug fixes
=
Rare garbage collection bug fixed (noticed with GCC 5).
Language features
=
No significant new language feature.
Runtime features
We did keep compatibility with GCC 5 & GCC 6.
Since gengtype does not admit conditionals (see messages following
https://gcc.gnu.org/ml/gcc/2016-02/msg00156.html ...) we had to hack
our build system. The MELT plugin now use some melt-runtypes.h
symlink to a version specific file, which has typedef-s like
typedef gimple* melt_gimpleptr_t; // gimple is now a struct
Added plugin options:
-fplugin-melt-arg-verbose-full-gc: if set to 1 or Y, a message is
output to stderr on MELT full garbage collections.
-fplugin-melt-arg-mmap-reserve: don't use it, except to debug the
MELT runtime. See comment in melt-runtime.cc
The MELT runtime (that it the MELT plugin melt.so) could be built with
-DMELT_HAVE_RUNTIME_DEBUG=1 to enable MELT runtime debugging. This is
rarely useful for MELT users.
w.r.t. MELT plugin 1.3 rc1 I have made a few bug fixes (including
perhaps some annoying GC bug that I cannot reproduce anymore).
Please try to build & use that release candidate 2 and report bugs to
gcc-m...@googlegroups.com
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} ***
Ann: MELT plugin 1.3 release candidate 1 for GCC 5 or GCC 6
Hello All,
It is my pleasure to announce the MELT plugin 1.3 release candidate 1
for GCC 5 & GCC 6
(hosted on Linux preferably).
MELT -see http://gcc-melt.org/ for more (or
http://starynkevitch.net/Basile/gcc-melt/ which points to the same web
pages and resources) - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
Please download the bzip2 compress source tar archive from
http://gcc-melt.org/melt-plugin-1.3-rc1-for-gcc-5-or-6.tar.bz2
It is a file of 4003571 bytes (3.9Mb) and md5sum
85f21dd54b896bce71678951f1e812ec
NEWS for 1.3 MELT plugin for GCC 5 & GCC 6
[[may XX, 2016]]
Bug fixes
=
Rare garbage collection bug fixed (noticed with GCC 5).
Language features
=
No significant new language feature.
Runtime features
We did keep compatibility with GCC 5 & GCC 6.
Since gengtype does not admit conditionals (see messages following
https://gcc.gnu.org/ml/gcc/2016-02/msg00156.html ...) we had to hack
our build system. The MELT plugin now use some melt-runtypes.h
symlink to a version specific file, which has typedef-s like
typedef gimple* melt_gimpleptr_t; // gimple is now a struct
Please try to build & use that release candidate and report bugs to
gcc-m...@googlegroups.com
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} ***
stable plugin introspection API ... Where?
Dear all
In https://gcc.gnu.org/ml/gcc/2016-02/msg00157.html
Richard Biener (richard dot guenther at gmail dot com) is mentioning:
Help with picking up the partially completed work on a stable plugin
(introspection) API is of course welcome.
Can anyone explain me what and where is that stable plugin introspection
API?
In https://gcc.gnu.org/ml/gcc/2016-02/msg00159.html I (Basile) wrote:
> What exact functions (their name, the source files defining them) in
the current GCC trunk
> are you referring to by your "introspection" word? Last time I
checked (a few months ago)
> there where nothing related to that. Today, the only occurrences of
introspection
> (in GCC trunk svn rev233268) are in Java part and in the libsanitizer.
FWIW, Richard Beiner did not had time or wish to answer to that
(I've got no answer neither privately nor on the list).
So I am rephrasing my question:
which functions and source files are relevant today in the trunk for a "stable
plugin introspection API"?
I did try to find something related, but my search is completely unsuccessful
yet.
My feeling (and I really hope to be wrong, because any reflective or
introspective
ability in GCC would help my work in the MELT plugin, see http://gcc-melt.org/
for more, a big lot)
is that today there is no plugin-related introspection API at all in GCC. It
still
looks today (february 20165) as a wish or some vaporware.
I still hope to be very wrong, but then please enlighten me by naming the
actual functions and source files
related to the plugin introspection API. Or give me some source files and line
numbers
(in the GCC trunk, i.e. future GCC 6, of february 2016) if you like so.
Since I am not a native English speaker, I am referring to:
https://en.wikipedia.org/wiki/Type_introspection
https://en.wikipedia.org/wiki/Reflection_%28computer_programming%29
https://en.wikipedia.org/wiki/Homoiconicity
https://en.wikipedia.org/wiki/Metadata
https://en.wikipedia.org/wiki/Metaclass
(BTW, MELT does have some of these, but they are currently for MELT specific
features,
not yet for general GCC ones; this means that I -Basile- value & cherish these
features
a lot and I am hungry
to have them inside GCC)
So it looks like Richard see a "partially completed work" on "plugin introspection
API"
while I (Basile) don't see even the smallest start about it (or even consensus
about wishing that).
I hope to be wrong, so please point me some actual piece of code related to
that in GCC 6.
FWIW, it is possible for some C++ program to have some metadata. Qt is a
concrete example.
http://doc.qt.io/qt-5/metaobjects.html;
GTK is explicitly mentioning Introspection in
https://wiki.gnome.org/Projects/GObjectIntrospection
but I don't see anything remotely related to such things inside GCC.
AFAIU, we don't have any programmatic way to query the GCC API useful in
plugins today.
So please help me finding some related features in current GCC 6 (trunk) code
base (in February 2016).
I'm sure that most plugin writers would be pleased to know about that.
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: gengtype: conditional GTY ? (to add before GCC 6 release)
On 02/12/16 14:38, Richard Biener wrote:
On Fri, Feb 12, 2016 at 1:23 PM, Basile Starynkevitch
wrote:
I am tempted to try implementing a conditional GTY,
[...]
but this makes sense only if such a gengtype patch would go both into GCC 6
and into the next microrelease of GCC 5, i.e. GCC 5.4
I'm afraid that the current stage rules forbid that. Or, could such a patch
be considered as a bug fix?
Sorry, no.
I was afraid (but I am not surprised) of such a reply.
So won't spend any additional minute on patching gengtype.
So I will have to generate some additional file in MELT (containing
simply the
typedef gimple* melt_gimpleptr_t;
line) and hack the build procedure.
The plugin API was never considered stable and thus plugins have to
deal with incompatibilites as they arise.
Help with picking up the partially completed work on a stable plugin
(introspection) API
is of course welcome.
What exact functions (their name, the source files defining them) in the
current GCC trunk are you referring to by your "introspection" word?
Last time I checked (a few months ago) there where nothing related to
that. Today, the only occurrences of introspection (in GCC trunk svn
rev233268) are in Java part and in the libsanitizer.
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} ***
gengtype: conditional GTY ? (to add before GCC 6 release)
Hello All,
This is motivated by MELT, but I believe it would be useful to every GCC
plugin which tries to be
compilable both for GCC 5 & GCC 6.
The technical issue described in
https://gcc.gnu.org/ml/gcc/2016-02/msg00149.html is that the gimple
identifier in plugins has changed from pointer (in GCC 5 and earlier) to
class.
I feel that is a very major change w.r.t. plugins. Most (and probably
all) GCC plugins will be affected.
(A cosmetic patch might be to name gimpleinstance what is today gimple)
A tempting way might be
#if GCCPLUGIN_VERSION >= 6000
typedef gimple* melt_gimpleptr_t;
#else
typedef gimple melt_gimpleptr_t;
#endif /* GCC 6 */
unfortunately, that does not work today, because gengtype does not get
preprocessed input (and does not invoke the preprocessor).
Perhaps we should consider patching gengtype to enable conditional GTY-s
at least for typedefs.
I am tempted to try implementing a conditional GTY, perhaps
typedef GTY((when(WANTPOINTER)) gimple* melt_gimpleptr_t;
and
typedef GTY((unless(WANTPOINTER)) gimple melt_gimpleptr_t;
then, add a condition argument to gengtype processor, perhaps invoking
it as
gengtype -CWANTPOINTER
or
gengtype --condition WANTPOINTER
but this makes sense only if such a gengtype patch would go both into
GCC 6 and into the next microrelease of GCC 5, i.e. GCC 5.4
I'm afraid that the current stage rules forbid that. Or, could such a
patch be considered as a bug fix?
Opinions are welcome!
Regards.
PS. The very dirty alternative would be to feed gengtype with different
variants of inputs. That is ugly.
--
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: gengtype: missing `tag' option (MELT branch)
On 02/11/16 23:13, David Malcolm wrote:
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch
(svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch
any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
`tag'
option for type `gimple'
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
In r227941, "gimple" changed meaning. It's no longer a pointer to a
statement; instead, it's now the statement struct itself (see e.g.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00765.html )
Try changing these to "gimple *".
That surely helps a lot. My feeling is that such a drastic change might
justify a comment in gcc/coretypes.h (for those porting a plugin from
GCC 5 to newer versions of GCC)
Thanks, 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} ***
gengtype: missing `tag' option (MELT branch)
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch (svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
gengtype write #1 gt-go-go-lang.h
gengtype write #2 gt-jit-dummy-frontend.h
gengtype write #3 gt-c-c-decl.h
gengtype write #4 gt-cp-tree.h
gengtype write #5 gt-fortran-f95-lang.h
gengtype write #6 gtype-desc.c
gengtype write #7 gtype-lto.h
gengtype write #8 gtype-java.h
gengtype write #9 gtype-ada.h
gengtype write #10 gtype-desc.h
gengtype wrote 10 files.
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
FWIW, the gcc/melt/generated/meltrunsup.h file did not change in the
MELT branch since long time ago.
Do you have any clues about what has changed in gengtype about these tag
options in GCC 6? Or about the gimple type?
Regards.
PS. Of course the bug is very probably in the MELT branch, but it has
been a long time since I dived into gengtype. I can't figure out the error.
--
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} ***
Ann: MELT plugin 1.2.0 for GCC 4.9 & 5.
Hello All, It is my pleasure to announce the MELT plugin 1.2.0 for GCC 4.9 & GCC 5. MELT is a domain specific language to extend or customize the GCC http://gcc.gnu.org/ compiler. See http://gcc-melt.org/ for more about MELT. It is implemented as a GCC plugin, FSF copyrighted and GPLv3+ licensed. The MELT plugin 1.2.0 release (for GCC GCC 4.9 or GCC 5.*) is available (since july 24th, 2015) from http://gcc-melt.org/melt-1.2.0-plugin-for-gcc-4.9-or-5.tar.bz2 as a bzip2-ed tar source file of md5sum e718e8686a947f801d7fba4f3e699f80, and of 4075486 bytes (4.0 Megabytes), extracted from MELT branch svn revision 226151.. It brings significant features and bug fixes. Please upgrade. Notice that some packaged versions of GCC 5 on some Linux distributions (some versions of Debian) has a bug affecting MELT. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793478 You might need to upgrade your package, or fix it by editing the plugin-version.h of that package. Its GCCPLUGIN_VERSION_MINOR is incorrect. NEWS for 1.2 MELT plugin for GCC 4.9 and 5.x [[july 24th, 2015]] Bug fixes = More verbose messages about quote with more than one argument. Language features = The _MELT_FILE_ and _MELT_LINE_ identifiers are not symbols, but expanded to the file name and line number; this is probably a discutable feature, better use (this_file) and (this_line) macros... Runtime features Ported to GCC 4.9 & GCC 5.x types. ### Please report bugs to gcc-m...@googlegroups.com Regards. -- Basile Starynkevitch http://starynkevitch.net/Basile/ Francebasile starynkevitch.net working on http://gcc-melt.org/ Opinions are only mine!
magic 8 constant (bits / byte maybe?) in GCC JIT memento_of_new_rvalue_from_const ::get_wide_int
Hello All,
In GCC trunk svn 225726 the file gcc/jit/jit-recording.c contains the
following code near line 4168:
/* The get_wide_int specialization for . */
template <>
bool
memento_of_new_rvalue_from_const ::get_wide_int (wide_int *out) const
{
*out = wi::shwi (m_value, sizeof (m_value) * 8);
return true;
}
I am guessing that the magic constant 8 above (i.e. line 4170) is the
bits per char on the host machine, but I am not entirely sure of that.
(Maybe it is the bits per char on the target, but I guess not)
Is my understanding correct?
Do we care about running GCCJIT on weird host machines where char is
not a 8 bit byte?
Do we care abour running GCCJIT for cross-compilation to weird target
machines where char is not a 8 bits byte?
Out of curiosity, what are today the systems for which GCC is hosted,
or is targetted, on something where char are not an 8 bits byte?
Regards.
--
Basile Starynkevitch http://starynkevitch.net/Basile/
France
GCC/JIT and precise garbage collection support?
Hello All,
(this is triggered by a question on the Ocaml mailing list asking about
SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
GCCJIT)
We might want to support better good garbage collection schemes in GCC,
particularily in GCCJIT. This is a
thing that LLVM is known to be weak at, and we might aim to do much
better. If we did, good frontends for
good functional languages (e.g. F#, Ocaml, Haskell) might in the future
profit of GCC technology. And even a Javascript engine based on GCCJIT
could profit.
A good GC is very probably a precise (sometimes generational copying) GC
with write barriers
(read the http://gchandbook.org/ for more, or at least the wikipage
about garbage collection). So a good GC is changing pointers.
So we need to know where, and provide a mechanism for, pointer values
are located in the call stack (of the GCCJIT generated code), and
probably provide some write barrier machinery.
In my incomplete understanding, this requires cooperation between GCC
backend and middle-end; it perhaps mean in the GIMPLE level that we mark
some trees for local variables as been required to be spilled (by the
backend) at some well defined location in the call frame, and be able to
query that location (i.e. its offset).
Perhaps a possible approach might be to add, at the C front-end level,
an extra variable attribute telling that the variable should be spilled
always at the same offset in the call frame, to have some machinery to
query the value of that fixed offset, and to also have a GCC builtin
which flushes all the registers into the call frame?
This is just food for thoughts and still fuzzy in my head. Comments are
welcome (including things like we should not care at all about GC).
Notice that if we had such support for garbage collection, the (dying)
Java front-end could be resurrected to provide a faster GC than Boehm
GC. And GCC based compilers for languages like Go or D which have
garbage collection could also profit. (even MELT might take advantage of
that).
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} ***
configure --program-suffix could change gccjit library path?
Hello All, Imagine that someone (e.g. a distribution packager) wants to have several versions of gccjit like he does have several versions of gcc. Concretely, GCC 5.2 with GCC 6.1 I would believe that the --program-suffix argument of /configure would be useful. So he/she would compile GCC 5.2 with a --program-suffix=-5 argument to configure, and would like the gcc compiler to go in /usr/local/bin/gcc-5 and the GCCJIT library to go in /usr/local/lib/libgccjit-5.so, so users of GCCJIT 5.1 would link with -lgccjit-5 And he/she would also compiile GCC 6.1 with a --program-suffix=-6 argument to configure and would like the gcc compiler to go in /usr/local/bin/gcc-6 and the GCCJIT library to go in /usr/local/lib/libgccjit-6.so so users ofg GCCJIT 6.1 woudl link with -lgccjit-6 Having two different GCCJIT libraries is IMHO a legitimate wish (likewise, one can easily have several versions of LLVM libraries on Debian). AFAIU, the --program-suffix is not yet understood by GCCJIT configuration things. This is a wish, since I don't know autoconf well enough to be able to propose any patch. Or perhaps there is some existing configure switch already related to location of libgccjit? Regards. -- Basile Starynkevitch http://starynkevitch.net/Basile/ France
mixing JIT and GCC (with a precompiled header?)?
Hello all,
Suppose that I have some header file in C myhead.h, containing notably
// Boehm's garbage collector, notably defines GC_malloc_atomic & GC_malloc
#include
struct myintvec_st {
unsigned vsiz; // allocated size
unsigned vlen; // used length, always <= vsiz
int varr[];
};
static inline struct myintvec_st*vec_alloc(unsigned siz) {
size_t fullsiz = sizeof(struct myintvec_st)+siz*sizeof(int));
struct myintvec_st* v = GC_malloc_atomic(fullsiz);
memset(v, 0, fullsiz);
v->vsiz = siz;
return v;
}
and many other struct declaration and static inline functions and extern
function declarations.
Now, I would like to use libgccjit with a context which contains all
the functions & structures from file myhead.h, in particular because I
want to JIT some calls to inlined static functions, and I expect the
gccjit to do the inlining (assuming I am using JIT with -O2 by calling
gcc_jit_context_set_int_option with
GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL to 2).
How is that possible? What should be done to make that possible?
I imagine that we might need a new function which initialize a
gcc_jit_context from a precompiled header...
Where should it go?
Regards.
--
Basile Starynkevitch http://starynkevitch.net/Basile/
FOSDEM talk on GCC MELT (Lisp devroom)
Hello All
(sorry for the self-promotion)
I'm giving tomorrow january 31st 2015, at FOSDEM2015 (Lisp Dev Room) an
hour talk about GCC MELT
MELT is a Lispy domain specific language (implemented as a
GPLv3+licensed, FSF copyrighted, meta-plugin for GCC) to extend and
customize the GCC compiler.
About the GCC compiler, see http://gcc.gnu.org/
About MELT, see http://gcc-melt.org/
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} ***
Ann: MELT plugin 1.1.3 for GCC 4.8 & 4.9
Dear All,
It is my pleasure to announce the MELT plugin 1.1.3 for GCC 4.8 or 4.9
MELT is a high-level domain specific language and plugin to customize
GCC, see http://gcc-melt.org/ for details.
It is free software, GPLv3+ licensed, FSF copyrighted.
You can download the source tarball from
http://gcc-melt.org/melt-plugin-1.1.3-for-gcc-4.8-or-4.9.tar.bz2
this is a bzip2-ed tarball of 4124848 bytes (4.0Mbytes) extracted from
the GCC MELT branch svn rev. 217521 on november 13th, 2014
It brings several new features and significant bug fixes w.r.t. previous
MELT 1.1.2 (of august 31st 2014)
NEWS for 1.1.3 MELT plugin for GCC 4.8 & 4.9
[[november 13th, 2014]]
Bug-fix & feature-increase with significant improvements release
w.r.t. to MELT plugin 1.1.2.
Bug fixes
=
Better working macros, and improved documentations
Language improvement
Improved macro constructs.
All common (i.e. non-language specific) tree codes are handled, at
least thru an automatically generated cmatcher.
All non-OMP gimple codes are handled.
Better handling of variadic tree & gimple constructs.
Added gimple_call_args & gimple_call_more_args quasi-cmatcher,
gimple_switch handling, and functions to build them with a MELT
sequence (tuple or list) of constituents.
Variadic and polytypic add2list.
End-user improvements
=
Better eval mode. More informative error messages.
Documentation generated in several HTML files.
###
Please report bugs and comments to gcc-m...@googlegroups.com
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} ***
Ann: MELT 1.1.2 plugin for GCC 4.8 & 4.9 release (bugfixes)
Dear All,
It is my pleasure to announce the MELT 1.1.2 plugin for GCC 4.8 & 4.9.
MELT -see http://gcc-melt.org/ for more- is a domain specific language
to extend GCC, and a GCC plugin (free software, GPLv3 licensed, FSF
copyrighted).
This (mostly bug-fixing) release is available from
http://gcc-melt.org/melt-1.1.2-plugin-for-gcc-4.8-or-4.9.tar.bz2
as a bzip2-ed tar source file of md5sum
fab80bfaee76abea1513c69f504ab49f, and of 3936275 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 214717. It brings bug fixes with
respect to MELT 1.1.1 (so you should upgrade).
Bug fixes
=
Better plugin build (ending message mention that probe is obsolete)
All passes data are cleared in hook_all_passes_end.
Gives an error message for unknown mode.
Reject loading twice the same MELT module.
register_pre_genericize_first & register_pre_genericize_last
should work.
mixbigint-s are understood by output_json.
assert_msg don't loop with non-value arguments.
do_blocking_jsonrpc2_call returns secondarily the time in
milliseconds needed to process the JSONRPC call.
register_gcc_attribute works, and is a macro.
tree_chain_to_tuple is a new function.
#
Please ask questions and give feedback (successes or bug reports) on
gcc-m...@googlegroups.com list.
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: GCC plugins & GGC & explicit gcc_free
On Fri, 2014-08-29 at 19:58 +0200, Richard Biener wrote:
>
> You are in the same situation as any other pass would be. Don't hang on
> things that can get stale.
>
> There is no point in keeping a pointer to a deleted edge.
Yes there is. The use case is to make some statistics on edges and to
print these at FINISH_UNIT time.
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} ***
GCC plugins & GGC & explicit gcc_free
d be replaced by a call to
ggc_becomes_freeable which for example would call ggc_free if not plugin
is loaded, and stays a no-op if some plugins are loaded...).
Perhaps we could improve the situation e.g.
document more when and which data is cleaned up
add a finalizer plugin hook for the few static calls to ggc_free, but
that probably would be quite expensive (e.g. we'll run that hook from
free_edge in gcc/cfg.c ...) because ggc_free is probably called a big
lot of times.
more realistically, add plugin hooks in cleanup routines, notably in
cleanup_cfg file gcc/cfgcleanup.c
Please comment on this. If we agree on something I'll try to propose
some patch to GCC 5.0 during its stage 1.
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} ***
consistent naming of passes....
Hello all,
When I compile some file (precisely, the gcc/melt-runtime.cc from the latest
melt branch) with -O1 -fdump-passes (using GCC 4.9) I'm getting
notably
ipa-cp : OFF
ipa-cdtor : OFF
ipa-inline : ON
ipa-pure-const : ON
ipa-static-var : ON
ipa-pta : OFF
ipa-simdclone : OFF
*free_cfg_annotations : ON
However, in file gcc/ipa-inline.c there is
const pass_data pass_data_ipa_inline =
{
IPA_PASS, /* type */
"inline", /* name */
OPTGROUP_INLINE, /* optinfo_flags */
false, /* has_gate */
true, /* has_execute */
TV_IPA_INLINING, /* tv_id */
I find strange that the two names (the one given by -fdump-passes and the one
in the pass_data_ipa_inline object) are different.
When I try to insert a plugin pass (actually in MELT, file
gcc/melt/xtramelt-ana-simple.melt) named "inline" it gives:
cc1plus: fatal error: pass 'inline' not found but is referenced by new pass
'melt_justcountipa'
If I use "ipa-inline" I'm getting
cc1plus: fatal error: pass 'ipa-inline' not found but is referenced by new pass
'melt_justcountipa'
How should a plugin writer find the name of the reference pass to insert his
own new pass? At the very least it should be documented, and preferably it
should be identical to output of -fdump-passes
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} ***
Ann: MELT 1.1.1 plugin for GCC 4.8 & 4.9
It is my pleasure to announce the MELT 1.1.1 plugin for GCC 4.8 and 4.9 The MELT plugin 1.1.1 release (for GCC 4.8 or 4.9) is available (since august 11th, 2014) from http://gcc-melt.org/melt-1.1.1-plugin-for-gcc-4.8-or-4.9.tar.bz2 as a bzip2-ed tar source file of md5sum 5879dd6931d169bb64384b33537624e2, and of 3899914 bytes (3.8 Megabytes), extracted from MELT branch svn revision 213809. It brings bug fixes with respect to MELT 1.1 (so you should upgrade). NEWS for 1.1.1 MELT plugin for GCC 4.8 & 4.9 [[august, 11th, 2014]] Bug-fix release w.r.t. to MELT plugin 1.1 Bug fixes = connect_to_server works better for AF_UNIX socket. JSONRPC works better. double boxed and unboxed data works. pragma works better. Users of MELT 1.1 are invited to upgrade. Regards -- Basile Starynkevitch http://starynkevitch.net/Basile Opinions are mine only!
Ann: MELT plugin 1.1 release available for GCC 4.8 & 4.9
Dear All,
It is my pleasure to announce the MELT plugin 1.1 release for GCC 4.8 &
4.9 (hosted preferably on Linux). I've corrected all the bugs found in
MELT 1.1rc1.
MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
The MELT plugin 1.1 release (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 27th,
2014) from
http://gcc-melt.org/melt-1.1-plugin-for-gcc-4.8-or-4.9.tar.bz2
This is a bzipped2 source tar archive of 3891501 bytes (3.8 Mbytes) of
md5sum dcd4332f91140f12bee51ae4d33f66f0
This MELT 1.1 plugin is extracted from the GCC MELT branch svn revision
213094
NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 27th, 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).
End-user improvements
=
***
The module list files *.modlis accept conditioned extra
modules. Within them, a line like
?findgimple xtramelt-ana-simple.optimized
means that: if the mode is findgimple, load the xtramelt-ana-simple
module in its optimized flavour.
The predefined modules now are named libmelt*.melt for standard
library modules and xtramelt*.melt for extra modules.
Language improvements
=
Add support for JSON (parsing and emitting JSON format) and
JSONRPC2 client with TCP/IP transport. See
DO_BLOCKING_JSONRPC2_CALL, MAKE_JSON_PARSER, OUTPUT_JSON, etc...
This requires an UTF-8 locale.
***
Several bug fixes, notably MELT-SFT-8. Better variadic binding.
Many small improvements.
***
The MODULE_IS_GPL_COMPATIBLE directive is now required to avoid
warnings. Your modules should be GPL compatible, and state that with
a directive like
(MODULE_IS_GPL_COMPATIBLE )
for example
(MODULE_IS_GPL_COMPATIBLE "GPLv3")
Runtime improvements
***
The old GTKmm (or Qt/Python) probe is becoming deprecated. A
partial support for JSON & JsonRpc2 client is available. A
web-based MELT monitor is in the works, but not yet released.
***
Input channel handlers can be either paragraph oriented (like in
previous MELT releases) or raw input.
***
We don't use setjmp but C++ exceptions
***
melt_walk_use_def_chains adapted for GCC 4.9, and compatibility with
GCC 4.9
***
The successful modes list is printed.
***
Nearly systematic use of hooks.
***
Improved support of pragmas, with both REGISTER_EXPANDED_PRAGMA &
REGISTER_PLAIN_PRAGMA function.
***
Sorting primitives like multiple_sort are fully reentrant, so their
compare routine might do a sort itself!
***
Remove old option handling, REGISTER_OPTION is removed.
Bug and success reports are welcome on gcc-m...@googlegroups.com
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} ***
Ann: MELT plugin 1.1 release candidate 1 available
Dear All,
It is my please to announce the MELT plugin 1.1 release candidate 1 for
GCC 4.8 and 4.9 (hosted preferably on Linux).
MELT -see http://gcc-melt.org/ for more - is a domain specific language
and meta-plugin (free software GPLv3+ licensed, FSF copyrighted) to
easily extend and customize the GCC compiler.
The MELT plugin 1.1 release candidate 1 (for GCC 4.8 or 4.9, with major
updates since previous MELT plugin 1.0.2) is available (since july 26th,
2014) from
http://gcc-melt.org/melt-1.1-rc1-plugin-for-gcc-4.8-or-4.9.tar.bz2
as a bzip2-ed tar source file of md5sum
3b7ea46dddac2e81927c211ca6a90201, and of 3891814 bytes (3.8 Megabytes),
extracted from MELT branch svn revision 213071.
NEWS for 1.1 MELT plugin for GCC 4.8 & 4.9
[[july 2014]]
This is a major release (with perhaps some small incompatibilities
with previous MELT plugin releases).
End-user improvements
=
***
The module list files *.modlis accept conditioned extra
modules. Within them, a line like
?findgimple xtramelt-ana-simple.optimized
means that: if the mode is findgimple, load the xtramelt-ana-simple
module in its optimized flavour.
The predefined modules now are named libmelt*.melt for standard
library modules and xtramelt*.melt for extra modules.
Language improvements
=
Add support for JSON (parsing and emitting JSON format) and
JSONRPC2 client with TCP/IP transport. See
DO_BLOCKING_JSONRPC2_CALL, MAKE_JSON_PARSER, OUTPUT_JSON, etc...
This requires an UTF-8 locale.
***
Several bug fixes, notably MELT-SFT-8. Better variadic binding.
Many small improvements.
***
The MODULE_IS_GPL_COMPATIBLE directive is now required to avoid
warnings. Your modules should be GPL compatible, and state that with
a directive like
(MODULE_IS_GPL_COMPATIBLE )
for example
(MODULE_IS_GPL_COMPATIBLE "GPLv3")
Runtime improvements
***
The old GTKmm (or Qt/Python) probe is becoming deprecated. A
partial support for JSON & JsonRpc2 client is available. A
web-based MELT monitor is in the works, but not yet released.
***
Input channel handlers can be either paragraph oriented (like in
previous MELT releases) or raw input.
***
We don't use setjmp but C++ exceptions
***
melt_walk_use_def_chains adapted for GCC 4.9, and compatibility with
GCC 4.9
***
The successful modes list is printed.
***
Nearly systematic use of hooks.
***
Improved support of pragmas, with both REGISTER_EXPANDED_PRAGMA &
REGISTER_PLAIN_PRAGMA function.
***
Sorting primitives like multiple_sort are fully reentrant, so their
compare routine might do a sort itself!
***
Remove old option handling, REGISTER_OPTION is removed.
Bug and success reports are welcome on gcc-m...@googlegroups.com
(If I get no annoying critical bug report, I will release MELT plugin
1.1 in the next few days)
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} ***
ICE with atomic_store
Hello All,
The following code:
#include
struct s1_st {
char* i_name;
struct s1_st* i_foo;
};
void clear_s1 (struct s1_st*s)
{
__atomic_store(s->i_name, NULL, __ATOMIC_SEQ_CST);
}
gives an ICE when compiled (on Debian/Sid/amd64) by GCC 4.8 & 4.9 (I did not
test it on the trunk yet)
(For some strange reason, probably on my side, I'm not able to change the
password on bugzilla. So I'm reporting that bug here, sorry for the
inconvenience).
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: Gcc plugin for modification of source code ?
On Sun, 2014-06-15 at 02:40 +0530, Mohsin Khan wrote:
> Hi,
> I'm working on a gcc plugin project. I had a doubt, can somebody help
> me on this.
[no need to ask on gcc-help@; plugins are definitely gcc internals
related and should better be discussed on gcc@gcc.gnu.org]
> Can we write a plugin (which works after a pass like cfg or any other)
> which can modify the source code of .C file, for example insert
> comments before function definitions or insert a new IF Block in the
> .C file. And after modification it writes the entire modified code to
> a new .C file. Is this type of plugin possible in GCC. If yes, please
> tell me how and if No, please tell me why.
If your source file does not contain any #line directive, a GCC plugin
(or a MELT extension, see http://gcc-melt.org/ for more) is able to get
the source code position of every Gimple instruction. (But did you think
about instruction obtained by some macro expansions?).
With that information, you can indeed transform the C source as you
wish. It might not be simple (you need to build an editor-like internal
represention of each line of the source code).
However, modifying the Gimple representation (without modifying any C++
source file) is probably simpler.
What exactly do you want to achieve? Are you sure that a source to
source transformation is worthwhile -given that you can transform
internal GCC representations like Gimples-?
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: How can I get started as a GCC developer
On Tue, Jun 10, 2014 at 06:30:54PM +0800, Anonymous User wrote:
I'm not sure that being anonymous is helpful on GCC
(and it might even be frowned upon, but I don't want to start a flamewar) I
think that you need and you want
to be identified. Besides, working on GCC is difficult; you'll soon be proud of
being able
to work on it, and that also wants you to be identified.
You surely need to start with legal stuff. They take time (perhaps months, and
surely weeks!).
Read carefully http://gcc.gnu.org/contribute.html#legal
Once all is done and signed (both by FSF and you or your employer), add your
real name in MAINTAINERS file.
>
> So how can I gain a systematic understanding of the internals of GCC in
> order to get started with some serious work?
I'm definitely biaised, but I suggest first to be able to write some GCC
plugins
(or some MELT extensions, see http://gcc-melt.org/ for more).
Read in particular my latest slides
http://gcc-melt.org/gcc-plugin-MELT-LinuxCollabSummit2014.pdf
(GCC plugins thru the MELT examples). They give a lot of pointers.
Don't forget to read http://www.cse.iitb.ac.in/grc/
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: Roadmap for 4.9.1, 4.10.0 and onwards?
On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
> Hi,
> I've been tracking the latest releases of gcc since 4.7 or so (variously
> interested in C++1y support, cilk and openmp).
> One thing I've found hard to locate is information about planned inclusions
> for future releases.
> As much relies on unpredictable community contributions I don't expect there
> to be a concrete or reliable plan.
> However, equally I'm sure the steering committee have some ideas over what
> ought
> to be upcoming releases.
As a whole, the steering committee does not have any idea, because GCC
development is based upon volunteer contributions.
However, some members of the steering committee might work in large
organization having a team of GCC contributors. That team might have its
own (private) agenda. But every patch has to be approved by someone
else.
So I don't think that the steering committee knows a lot more than you
and me.
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: True "no-exceptions" mode?
On Sun, 2014-05-18 at 12:33 -0300, Daniel Gutson wrote:
> Hi,
>
>I am needing a truly exceptions-clean (or exceptions-free) binary due to
> some embedding systems platform.
> -fno-exceptions is not enough of course.
Did you think of making some extension (using MELT, see
http://gcc-melt.org/ for more) or some plugin (in C++) which would
at least check that no exception gimple is going thru.
This might be adding a pass which would detect and bark when
exception-related gimples are used.
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} ***
slides of talk on "GCC plugins thru the MELT example" (Linux F. Collab. S)
Dear All,
I gave a talk on "GCC plugins thru the MELT example" at the Linux
Foundation Collaboration Summit (Friday, March 28th 2014, Napa Valley,
California, USA)
http://events.linuxfoundation.org/events/collaboration-summit/
The slides of my talk are available online at
http://gcc-melt.org/gcc-plugin-MELT-LinuxCollabSummit2014.pdf
There should be useful to anyone interested
in GCC plugins or MELT 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 mines, sont seulement les miennes} ***
Re: Inquireries
Hello Alangi Derick & the GCC list
[your subject "Inquireries" is mispelled and not very explicit; probably
should be Gimple conversion to source code]
On Sat, 2014-03-15 at 13:30 +0100, Alangi Derick wrote:
>The project name is: Converting different program
> representation levels of GCC back to the source code. It's not a
> trivial task but I saw substantial interest to that recently and it is
> found in the http://gcc.gnu.org/wiki/SummerOfCode page.
If you want to convert some Gimple back to C code, it is an interesting
project (but somehow difficult or even impossible, notably because of
of exceptions and Gimple code like GIMPLE_EH_FILTER, GIMPLE_CATCH
etc...). Plugins are probably a good way to make that. And the MELT
meta-plugin http://gcc-melt.org/ used to have some (incomplete) code -by
Jeremie Salvucci- which you could resurrect from
http://gcc.gnu.org/viewcvs/gcc/branches/melt-branch/gcc/obsolete-melt/xtramelt-c-generator.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: GNU C extension: Function Error vs. Success
On Mon, Mar 10, 2014 at 03:27:06PM +0100, Shahbaz Youssefi wrote:
> Hi,
>
> First, let me say that I'm not subscribed to the mailing list, so
> please CC myself when responding.
>
> This post is to discuss a possible extension to the GNU C language.
> Note that this is still an idea and not refined.
[]
>
> The Extension (Basic)
> =
>
> First, let's introduce a new syntax (note again, this is just an
> example. I don't suggest these particular symbols):
>
> float inverse(int x)
> {
> if (x == 0)
> fail;
> return 1.0f / x;
> }
>
> ...
> y = inverse(x) !! goto exit_inverse_failed;
>
Syntax is not that important. To experiment your idea,
I would suggest using a mixture of pragmas and builtins;
you could perhaps have a new builtin_shahbaz_fail() and a pragma
#pragma SHAHBAZ and then your temporary syntax would be
float inverse(int x)
{
if (x == 0) builtin_shahbaz_fail();
return 1.0f / x;
}
#pragma SHAHBAZ on_error_goto(exit_inverse_failed)
{ y = inverse(x); }
Then, you don't need to dig into GCC parser to add these builtin and pragma.
You could add them with a GCC plugin (in C++) or using MELT http://gcc-melt.org/
Once you added a GCC pass to support your builtin and pragma
(which is difficult, and means understanding the details of internals of GCC)
you could convince other people.
Notice that the GCC community is not friendly these days to new syntactic
constructs.
BTW, once you have implemented a builtin and a pragma you could use
preprocessor macros
to make these look more like your syntax.
I would believe that MELT is very well suited for such experiments.
Regards.
PS. Plugins cannot extend the C syntax (except thru attributes, builtins,
pragmas).
--
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} ***
status of current_pass (notably in gates) .... [possible bug in 4.9]
Hello All,
I am a bit confused (or unhappy) about the current_pass variable
(in GCC 4.9 svn rev.208447); I believe we have some incoherency about it.
It is generally (as it used to be in previous versions of GCC)
a global pointer to some opt_pass, declared in gcc/tree-pass.h line 590.
It is also (and independently), a local integer in function
connect_traces file gcc/bb-reorder.c line 1042. I feel that
for readability reasons the local current_pass should be renamed
current_pass_num in the function connect_traces.
But most importantly, I find confusing the way current_pass pointer is
globally set (and reset). The obvious policy seems to set current_pass to
"this" before calling any virtual methods on it (notably the gate and
the exec functions).
However, if one use -fdump-passes program argument to gcc (i.e. to cc1), then
dump_passes (from gcc/passes.c line 892) gets called. It then calls function
dump_one_pass (from gcc/passes.c line 851) which does line 857
is_on = pass->has_gate ? pass->gate () : true;
But in other occasions, notably in function execute_one_pass
(starting at gcc/passes.c line 2153) the global current_pass is
set (line 2166) before calling its gate function line 2170
gate_status = pass->has_gate ? pass->gate () : true;
I believe something should be done about this, since it seems to confuse
plugins (like MELT). Either we decide that current_pass is always set
before calling any virtual function on it (notably the gate) or we
decide that current_pass global should disappear (but then, what
about the curr_statistics_hash function from gcc/statistics.c line 93
which uses it line 98)?
Comments are welcome. I think we should do something about this before
releasing GCC 4.9...
The simplest thing would be to set current_pass in dump_one_pass....
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: [RFC] Meta-description for tree and gimple folding
On Thu, 2014-02-27 at 15:34 +0100, Richard Biener wrote:
>
> I've been hacking on a prototype that generates matching and
> simplification code from a meta-description.
For what it is worth, MELT has a similar feature. http://gcc-melt.org/
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: proposal to turn on some warnings by default
On Thu, 2014-02-27 at 10:14 +0100, David Brown wrote:
> On 27/02/14 07:50, Mingjie Xing wrote:
> > Hello,
> >
> > I'm wondering if it's a good idea to turn on some warnings by default
> > (or even promote them to error), such as -Wreturn-type on C. This
> > would help programmers to avoid some mistakes.
> >
> > Regards,
> > Mingjie
> >
>
> Personally, I think gcc should issue a warning if it is run without at
> least "-Wall" (or "-Wno-all"), telling the user that they have forgotten
> to enable warnings. /That/ would help people avoid mistakes. It should
> also warn if there is no optimisation level, to stop people accidentally
> generating big and slow code.
I totally agree with you. Perhaps in next release (after 4.9) we might
add something more in the spec file to enable e.g. Linux distribution
makers (or users compiling and configuring GCC from its source tarball)
to give that feature.
Maybe a way to tell in the spec file that -Wall (or some other global
and configurable option) is passed by default, unless some other options
is given to override it.
So, for people wanting -Wall without asking it explicitly it would be
possible to configure their spec file to have that. For other people
wanting maximal compatibility with the behavior of previous GCC versions
they would avoid hacking the spec file.
Look e.g. on stackoverflow.com the large amount of questions asked by
newbies users of GCC (or beginners in C programming) which could have
been avoided (or at least noticed) by -Wall
BTWX, when I teach some courses and have students use GCC I require them
to pass -Wall and to do the necessary to avoid any warnings.
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: Help Required on Missing GOTO statements in Gimple/SSA/CFG Pass ...
On Tue, 2014-02-18 at 11:17 +0530, Mohsin Khan wrote:
> Hi,
>
> I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
> I wrote a plugin and tried to count and see the Goto Statements using
> the gimple_stmt_iterator. I get gimple statements printed on my
> stdout, but I am not able to find the line which has goto statements.
I guess that most GOTOs are just becoming implicit as the link to the
next basic block.
Probably
if (!cond) goto end;
something;
end:;
has nearly the same Gimple representation than
while (cond) {
something;
}
BTW, did you consider using MELT http://gcc-melt.org/ to code your GCC
extension?
--
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: question about gtype-desc.c
On Tue, 2014-02-04 at 23:07 +, Iyer, Balaji V wrote:
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Tuesday, February 4, 2014 5:36 PM
> > To: Iyer, Balaji V
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: question about gtype-desc.c
> >
> > On Tue, Feb 04, 2014 at 10:26:20PM +, Iyer, Balaji V wrote:
> > > > > gtype-desc.c:8176: error: âstruct gimple_omp_for_iterâ has no
> > > > > member named âloop_countâ
> > > > > gtype-desc.c:8178: error: âstruct gimple_omp_for_iterâ has no
> > > > > member named âgrainâ
> > > > >
> > > > > These files are in the build directory. I deleted everything and
> > > > > reconfigured
> > > > but the error reappears.
[...]
> > What you did should be more than enough. But then, I didn't see
> > loop_count nor grain fields of gimple_omp_for_iter in your previously
> > posted patches (only your ChangeLog mentioned it). So, if you start with
> > wiping up the build directory, I think you have to grep where the fields
> > appear.
> >
>
> OK. Found the issue. I had the 2 fields enclosed inside a #if 0 and #endif
>
> I guess whatever that is reading the fields to create gtype-desc.c does not
> understand C/C++ pre-processing, and thus it didn't ignore the fields in
> between #if 0.
[...]
Yes. gengtype, the utility creating gtype-desc.c, does not care about
the C++ preprocessing. Ideally, I believe it should, but that is hard
work.
--
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} ***
implementation & optimization of std::function with and without allocator
Hello All,
Consider the below toy example (I'm using Boehm GC 7.2d as provided on
Debian/Sid/x86-64):
// filetestclogc.cc
#include
#include
#include
#include
#include
gc_allocator mygcalloc;
extern "C" void apply_to_each(int lo, int hi,
const std::function&f)
{
for (int i=lo; i f (
#if 0 /* we should accept this but we don't yet */
std::allocator_arg, mygcalloc,
#endif
[&](int i) {printf("i=%d\n", i);});
apply_to_each(0, mx, f);
}
First, my understanding of the C++11 standard thru
http://en.cppreference.com/w/cpp/utility/functional/function/function
(which I know is imperfect, but I find it much more readable than
n3337.pdf draft of C++11 )
is that in principle we should compile this code with the #if 0 replaced
by #if 1 (but we don't yet, our header says "TODO: needs
allocator_arg_t"). Perhaps the type of mygcalloc is wrong...
(I don't understand at all the issues of accepting allocators for
std::function)
Then, I am surprised (and a bit disappointed) that (using GCC 4.8.2 from
Debian) with
g++-4.8 -Wall -std=c++11 -O3 -S \
-fdump-tree-phiopt -fverbose-asm testclogc.cc
we are not inlining all the lambda stuff. I was expecting we'll do the
inlining, since similar experiments with std::array etc... are very well
optimized, like
#include
#include
#include
#include
int sum (const std::array&a)
{
int s=0;
std::for_each(a.begin(), a.end(),
[&](int i) {printf("i=%d\n", i); s += i;});
return s;
}
I am not at all expert on C++ optimization, so probably I am very naive.
If someone had time to explain what passes are optimizing this sum
function with g++ -std=c++11 -O3 I would be very happy (the handling of
lambda-s is really mysterious to me)...
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: checking GPL compatibility in MELT meta-plugin
On Thu, 2014-01-23 at 17:42 -0800, Ian Lance Taylor wrote: > On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch > wrote: > > > > Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software > > enthusiast and I like a lot the GPLv3 > > > > As you know, GCC has some technical devices to invite plugin developers > > to make GPL compliant plugins. > > http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html > > > > This is done thru the plugin_is_GPL_compatible symbol. Of course, some > > dishonest person could technically have & distribute a proprietary GCC > > plugin defining that symbol (IANAL, but I believe it won't be accepted > > in court, even if technically feasible). > > The plugin_is_GPL_compatible symbol is implemented by GCC and may > serve as an indication of intent by plugin developers. But it does > not by itself indicate whether a plugin may be used. The rules for > plugins are spelled out in the GCC Runtime Library Exception > (http://www.gnu.org/licenses/gcc-exception-3.1.html). A plugin that > follows those rules adds no restrictions to the generated code. A > plugin that does not follow those rules does add restrictions to the > generated code. This is true whether or not the plugin does anything > with the plugin_is_GPL_compatible symbol. In addition, and this might perhaps be more true for some future MELT extensions than for other plugins, a plugin could be used for code checking purposes (i.e. as a super-lint). In that view, one compile his/her application with some MELT extension -or some other plugin- for heuristic static analysis purposes - and won't distribute code so compiled, but only distribute code compiled without any plugin (or MELT extension). Probably http://clang-analyzer.llvm.org/ is used this way also. And also http://frama-c.com (developed by my colleagues from CEA, LIST) which is a LGPL static analyzer separate from any compiler. BTW, this is probably also the case (for proprietary software compiled with plain GCC) regarding the debugging -g flag: I imagine that it is more used by developers than on the finally released or distributed binary... I understand that http://www.gnu.org/licenses/gcc-exception-3.1.en.html is only relevant for distribution (i.e. propagation or conveying, in terms of GPLv3) of [binary] software compiled with GCC (If the compiled binary is discarded or only internally used, does it apply?) > > > > Do meta-plugins like MELT (& probably Python plugin) should be concerned > > about having some device to check compatibility with GPL licensing? I > > believe that yes... (David Malcolm: what is your feeling on this? How do > > you deal with that concern inside your Python plugin?) > > I think it would be reasonable for you to use something like > plugin_is_GPL_compatible. > > > > Can I just leave a warning, not an error, when the MELT macro > > module_is_gpl_compatible is not used in some user-provided *.melt code? > > If you are going to use it, then use it. Make it an error. The reason I was using a warning not an error is that MELT could perhaps in the future be used for static analysis of code (as or with -g), but that in that scenario the real released executable would very probably be compiled without MELT (and without -g) - and perhaps even by an older version of GCC! But I could make it an error if you wish. I just believe it should stay a warning > > > > Are my warning messages good enough; should I speak of "claim to be GPL > > compatible" in them, or should it be something else, e.g. "assert to be > > GPL compatible" or "promise to be GPL compatible", or "is GPL > > compatible" [which cannot be technically checked, only legally!]; please > > recall that English is not my native language! So any better suggestions > > are welcome! > > Hard to give an opinion on an incomplete phrase, but copying the error > message in gcc/plugin.c ought to be fine. Here are the precise messages for a given example. Assume you translate an hypothetical your-foo.melt extension into your-foo.so module and that file your-foo.melt does not use the MODULE_IS_GPL_COMPATIBLE macro to claim GPL compatibility: You'll first translate that your-foo.melt extension into a binary MELT module using something like [see http://gcc-melt.org/tutousemelt.html for details] gcc -fplugin=melt -fplugin-arg-melt-mode=translatetomodule \ -fplugin-arg-melt-arg=your-foo.melt \ -c emptyfile.c -o /dev/null During this translation you'll get messages from warmelt-outobj.melt: warning: MELT module your-foo does not claim GPL compatibility using MODULE_IS_GPL_COMPATIBLE macro notice: see http://www.gnu.org/licens
checking GPL compatibility in MELT meta-plugin
d
dlopen that code. There is no reason for that temporary C++ code to be
GPL (it is temporary and is deleted when MELT finishes, and the source
is just some program argument -fplugin-arg-melt-gimple-pattern=... to
the MELT plugin & to gcc).
So my concrete questions to the GCC community are:
Do meta-plugins like MELT (& probably Python plugin) should be concerned
about having some device to check compatibility with GPL licensing? I
believe that yes... (David Malcolm: what is your feeling on this? How do
you deal with that concern inside your Python plugin?)
Can I just leave a warning, not an error, when the MELT macro
module_is_gpl_compatible is not used in some user-provided *.melt code?
Are my warning messages good enough; should I speak of "claim to be GPL
compatible" in them, or should it be something else, e.g. "assert to be
GPL compatible" or "promise to be GPL compatible", or "is GPL
compatible" [which cannot be technically checked, only legally!]; please
recall that English is not my native language! So any better suggestions
are welcome!
Is it ok or good to give the
http://www.gnu.org/licenses/gcc-exception-3.1.en.html URL in a notice
message?
Is the MELT macro name module_is_gpl_compatible good enough? I was also
thinking of extension_is_gpl_compatible (I generally speak of *.melt
extension files producing *.cc generated C++ files compiled into *.so
MELT modules which are dlopened by the MELT runtime which is itself a
GCC plugin...)
Is the C++ symbol name in the generated C++ code
melt_module_is_gpl_compatible good enough (I really want it to start
with melt_ since this is a convention for the MELT runtime, to avoid
collisions with GCC symbols)?
I just committed today (jan.23, 2014) some patches to the MELT branch of
GCC (svn rev.206976) I also make a temporary MELT plugin snapshot
available on http://gcc-melt.org/melt-plugin-snapshot.tar.bz2 which is a
symlink to
http://gcc-melt.org/melt-plugin-snapshot-r206976-2014jan23.tar.bz2
This MELT plugin snapshot is probably buggy and instable. I barely
tested the features I just added.
If you (specially high-level members of GCC community, i.e. global
reviewers, plugin reviewers, or steering committee members, but also
other plain members like me) believe that all this is crappy or wrong,
please tell and I will revert my latest patches regarding all this. If
you believe it should be improved, please also tell. If you think it is
useful, please say so. If you have any comments about naming or
messages, please help!
Your feedback is expected and welcome!
Regards.
PS: if this is welcomed it will be part of next MELT plugin (i.e. MELT
plugin 1.1 - but I don't promise any date for its future release).
PPS: I have some meeting tomorrow and might not have time to read or
answer emails.
--
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} ***
Ann: MELT 1.0.2 plugin for GCC 4.7 & 4.8 (bug-fixing release)
Dear All,
MELT is a plugin and a domain specific language to extend and customize
your GCC compiler, see http://gcc-melt.org/ for more.
I am delighted to announce the MELT 1.0.2 plugin for GCC 4.7 and 4.8, a
bug-fixing release w.r.t. MELT 1.0.1
Please download it from
http://gcc-melt.org/melt-1.0.2-plugin-for-gcc-4.7-or-4.8.tar.bz2
It is a bzip2-ed tar source file of md5sum
07926d9d3ee18f7d0db523725fa7d709, and of 3756363 bytes (3.6Megabytes);
this bug-fixing release is obtained from MELT 1.0.1 (which was extracted
from MELT branch svn revision 204522) corrected with the
http://gcc-melt.org/patch-melt-plugin-1.0.1-to-1.0.2.diff
which you could also directly apply to your MELT 1.0.1 plugin source
tree.
With respect to MELT 1.0.1 this bug-fixing release corrects
https://sourceforge.net/p/gcc-melt/tickets/7/ (an annoying bug related
to -fplugin-arg-melt-mode=findgimple). Thanks to my students at Univ.
Pierre et Marie Curie, Paris, France (notably Boris de Finance and
others) for reporting the bug.
Please report bugs and ask questions on the gcc-melt googlegroup:
https://groups.google.com/forum/#!topic/gcc-melt
i.e. gcc-m...@googlegroups.com
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: [RFC] Replace Java with Go in default languages
On Wed, 2013-11-20 at 11:45 -0800, Ian Lance Taylor wrote:
> On Wed, Nov 20, 2013 at 8:45 AM, Alec Teal wrote:
> >
> > It was said before (when this first started) that Go wasn't ready. Another
> > language that looks cool but has yet to mature.
>
> Side issue clarification. I believe that Go is ready for any use one
> might care to put it to. The reasons I believe it is not suitable as
> a default-enabled language for GCC have to do with licensing and
> source code issues, not with the language or the compiler support for
> it.
Thanks for the point. Ian, could you explain more what you mean by
"source code issues". From my non-native English speaker point of view,
I'm understanding "software quality" (i.e. bugs) which is not what you
seems to mean.
BTW, I am rather in favor of Go becoming more used and perhaps
default-enabled (just because I like the language and I trust your
work on Go in GCC; the one major thing I miss in Go is dynamic loading à
la dlopen).
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: PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Mon, 2013-11-18 at 13:17 +, Joseph S. Myers wrote:
> On Sun, 17 Nov 2013, Basile Starynkevitch wrote:
>
> > What would be the good way to add such a plugin event to GCC 4.9?
>
> See the cpp_callbacks structure, used to make diagnostics go through GCC's
> diagnostics machinery, for example. I'm not clear why the existing
> callbacks (in particular the file_change one) wouldn't be enough.
Thanks for your reply (and your interest to my suggestion).
I am not sure to understand what you suggest (because I see several ways
to understand it).
The first would be to add inside file libcpp/directives.c in its
function _cpp_do_file_change (e.g. after line 1044 the statement
/* Signal to plugins that a header file is included. */
invoke_plugin_callbacks (PLUGIN_HEADER_FILE,
ORDINARY_MAP_FILE_NAME (map));
The second would be to add a new way to invoke plugin callbacks which
would be to add the file libcpp/internals.h to the list of plugin
exported headers. At the very least, this means to add into the
PLUGIN_HEADERS variable of gcc/Makefile.in several files from
libcpp/includes/ and possibley even libcpp/internals.h
I find that the second way introduce a policy change w.r.t plugins. Up
to now, we tried hard to define the way plugins interact with GCC thru
the plugins.h and plugins.def file, but it looks that you want yet
another way.
I strongly prefer adding a new plugin event (PLUGIN_HEADER_FILE) and
just use it (and document it) to adding a new way of having plugins
modify the behavior of GCC (thru our various hooks, in that case the
file_change callback).
What do you practically suggest? Don't you feel that adding a new plugin
event (PLUGIN_HEADER_FILE) to plugins.def and adding a single call to
invoke_plugin_callbacks much lighter and simpler than having the plugin
need several additional files (into PLUGIN_HEADERS make variable)
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} ***
PLUGIN_HEADER_FILE event for tracing of header inclusions.
Hello All,
I strongly believe that plugins should be able to be notified of
included headers. Notice that end-users already can be notified with the
-H option of gcc.
This is useful e.g. for plugins which are interfacing to some IDE (like
Eclispe, Geany, ...), because the editor really wants to know when a
header file is used.
MELT [see gcc-melt.org] certainly will be very happy if a
PLUGIN_HEADER_FILE event existed for that purpose. It would make its
probe (or the future "monitor" of MELT) much simpler, because every
included file would easily be passed to the MELT plugin and to the
probe. (Currently MELT deals with that by constructing a set of files
for the locations, but that is painful).
In principle the patch should be quite simple; add in function
linemap_add of libcpp/line-map.c, near line 380, for reason == LC_ENTER
just before testing set->trace_includes, some lines like
/* Signal to plugins that a header file is included. */
invoke_plugin_callbacks (PLUGIN_HEADER_FILE,
ORDINARY_MAP_FILE_NAME (map));
but that requires a #include "plugin.h" in that file libcpp/line-map.c,
and then GCC machinery (autodependencies for make, etc...) is unhappy
(because this requires -I$(srcdir)/../gcc to be added in the Makefile.in
of libcpp/)
What would be the good way to add such a plugin event to GCC 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} ***
Ann: MELT 1.0.1 plugin for GCC 4.7 & 4.8
Dear All,
I am delighted to announce MELT 1.0.1 plugin for GCC 4.7 & 4.8 ( a
bug-fixing release w.r.t MELT 1.0)
Please download it from
http://gcc-melt.org/melt-1.0.1-plugin-for-gcc-4.7-or-4.8.tar.bz2
It is a bzip2-ed tar source file of md5sum
c7c3dbf3edd4e5747ddcf4a30dad41c4 and of 3754405 bytes (3.6 Megabytes)
extracted from MELT branch svn revision 204522.
MELT is a Lispy like domain specific language to extend GCC implemented
as a GPLv3 plugin for GCC. See http://gcc-melt.org/ for more.
This 1.0.1 release provide just a bug fix with respect to MELT 1.0
announced on october 29th 2013 on
http://gcc.gnu.org/ml/gcc/2013-10/msg00269.html
A probable bug in GCC 4.7 gengtype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59028
which does not appear when compiling MELT 1.0 for GCC 4.8
mixed with a corrected bug from MELT 1.0 plugin
http://sourceforge.net/p/gcc-melt/tickets/6/
made necessary this bug-fixing MELT 1.0.1 release which does not bring
any new features w.r.t to MELT 1.0 but just circumvent the gengtype from
GCC 4.7 deficiency.
So you need to upgrade MELT if you have GCC 4.7 (since MELT 1.0 was not
easily installable with GCC 4.7), and you probably want to upgrade MELT
if you have GCC 4.8; you also need to install unifdef from
http://dotat.at/prog/unifdef/ or from your distribution.
NEWS for 1.0.1 MELT plugin for GCC 4.7 & 4.8 [and future 4.9?]
[[november 7th, 2013]]
This is just a bug-fix release for MELT-SFT-6 (see
https://sourceforge.net/p/gcc-melt/tickets/6/ for more); it adds a
workaround for GCC 4.7 gengtype inability to process operator
conversion. The unifdef utility is now required to build the MELT
plugin.
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} ***
Ann: MELT 1.0 plugin for GCC 4.7 & 4.8
f $1 ...
$9
expanded into variadic arguments. For example
(ERRROR_AT somelocation "this is an error with number $1 and tree
$2"
somenumber sometree)
The location can be null, or be given by some boxed gimple or boxed
tree.
***
* The ASSERT_MSG macro can have more arguments, which are shown
when the assertion fails.
***
* MELT registered passes have a unique number (for GCC 4.9).
***
* The runtime is named melt-runtime.cc since it is C++ code.
***
* MELT generated frames are classy because they are C++ classes.
As usual, many bug fixes... A ticket system is now available on
https://sourceforge.net/p/gcc-melt/tickets/ for bug reports.
####
Respectful 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} ***
Ann.: MELT 1.0 [rc2] plugin (release candidate 2) for GCC 4.7 or better
T WARNING_AT and INFORM_AT functions are available
for diagnostics. They take a format string with occurrences of $1 ... $9
expanded into variadic arguments. For example
(ERRROR_AT somelocation "this is an error with number $1 and tree $2"
somenumber sometree)
The location can be null, or be given by some boxed gimple or boxed tree.
***
* The ASSERT_MSG macro can have more arguments, which are shown
when the assertion fails.
***
* MELT registered passes have a unique number (for GCC 4.9).
***
* The runtime is named melt-runtime.cc since it is C++ code.
***
* MELT generated frames are classy because they are C++ classes.
As usual, many bug fixes... A ticket system is now available on
https://sourceforge.net/p/gcc-melt/tickets/ for bug reports.
##
Please download it, test it, and report any bugs or successes
on gcc-m...@googlegroups.com
I hope to release the MELT 1.0 plugin definitive release in a few days.
It hopefully should be very close to this 1.0 rc2.
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: GCC 4.8.2 Status Report / plugin related corrections
On Wed, Oct 09, 2013 at 01:04:52PM +0200, Jakub Jelinek wrote:
> Status
> ==
>
> The GCC 4.8.2-rc1 release candidate has been released.
> The branch is frozen now, all changes require release manager approval
> until the final release of GCC 4.8.2 which should happen roughly
> one week after the release candidate.
I still believe that http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
& http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
should also go into 4.8
(these two small patches have been accepted into trunk)
Both patches addresses bugs related to plugins.
The first enables a = in a plugin argument, and the second enable .cc files to
gengtype.
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} ***
MELT-1.0-rc1 plugin release candidate for GCC 4.7, 4.8 or newer
Dear All
It is my pleasure to announce the MELT 1.0 plugin for GCC 4.7 and 4.8
first release candidate.
Please download the bzip-ed tarball source from
http://gcc-melt.org/melt-1.0-rc1-plugin-for-gcc-4.7-or-4.8.tar.bz2
it is a bzip2-ed tar ball of md5sum 6f0620f07302105587ddb15902125948
and of 3691120 bytes extracted from GCC MELT Branch svn rev 203161
of october 3rd 2013
MELT 1.0 is bringing a lot of new features (a real macro system, the
ability to find -thru the command line only- gimple matching some given
pattern, etc), most of them announced in
https://groups.google.com/forum/#!topic/gcc-melt/V9IeLn8Q7xo
A more formal announcement will be made for the next release candidates.
MELT 1.0 is a significant milestone in MELT
I'm waiting for your bug reports etc... on gcc-m...@googlegroups.com
please.
I'm busy preparing my OWF talk on GCC MELT for tomorrow
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} ***
automatic dependencies, adding new files in branch...
Hello Tom and all
A big thanks for the automatic dependencies patch.
I want to merge the current trunk into the MELT branch, and I have some trouble
understanding how one should add new files into GCC (i.e. into a branch)
For the MELT branch, I just want to add gcc/melt-runtime.cc [which requires
melt/generated/meltrunsup.h and melt-runtime.h and melt-predef.h headers);
until now,
I had the following rules in its gcc/Makefile.in i.e. in
http://gcc.gnu.org/viewcvs/gcc/branches/melt-branch/gcc/Makefile.in
#
MELT_H= $(srcdir)/melt/generated/meltrunsup.h \
$(srcdir)/melt-runtime.h \
melt-predef.h
MELT_RUNTIME_C= $(srcdir)/melt-runtime.cc
## file melt-runtime-params-inc.c is generated and #include-d in melt-runtime.cc
melt-runtime-params-inc.c: build/melt-make-string$(build_exeext) Makefile
./build/melt-make-string$(build_exeext) \
melt_source_dir '$(melt_source_dir)' \
melt_header_dir '$(melt_header_dir)' \
melt_module_dir '$(melt_module_dir)' \
melt_module_make_command '$(MAKE)' \
melt_module_makefile '$(melt_installed_module_makefile)' \
melt_module_cflags '$(melt_installed_cflags)' \
melt_revision '$(shell echo -n $(REVISION_c) | tr -s [:space:] _)'
\
melt_default_probe '$(melt_default_probe)' \
melt_default_modlis '$(melt_default_modules_list)' > $@-tmp
mv $@-tmp $@
MELT_REVISION_STR := $(shell echo -n $(REVISION_c) | sed "s/ /_/g")
MELT_RUNTIME_CPPDEFS= \
-DMELT_REVISION='\"$(MELT_REVISION_STR)\"' \
-DMELT_GCC_VERSION=$(shell cat $(BASEVER) | $(AWK)
'{split($$0,vertab,"."); printf "%d", vertab[1]*1000+vertab[2]}')
melt-runtime.args: $(MELT_RUNTIME_C) melt-run-md5.h melt-runtime-params-inc.c
$(C_COMMON_H) \
$(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) \
$(GGC_H) $(BASIC_BLOCK_H) $(GIMPLE_H) $(CFGLOOP_H) \
tree-pass.h $(MELT_H) \
$(srcdir)/melt/generated/meltrunsup.h \
$(srcdir)/melt/generated/meltrunsup-inc.cc \
gt-melt-runtime.h $(PLUGIN_H) $(TOPLEV_H) $(VERSION_H) \
Makefile
@echo '@@**@@' building melt-runtime.args
@echo $(ALL_CFLAGS) $(ALL_CPPFLAGS) -I $(srcdir)/melt/generated/ \
$(MELT_RUNTIME_CPPDEFS) > melt-runtime.args-tmp
@echo " -I" $(realpath .) >> melt-runtime.args-tmp
@echo " -I" $(realpath include) >> melt-runtime.args-tmp
@echo " -I" $(realpath include-fixed) >> melt-runtime.args-tmp
@echo $(realpath $(MELT_RUNTIME_C)) >> melt-runtime.args-tmp
$(melt_move_if_change) melt-runtime.args-tmp melt-runtime.args
@echo -n '@@**@@' melt-runtime.args: ; cat melt-runtime.args ; echo
melt-runtime.o: $(MELT_RUNTIME_C) melt-run-md5.h melt-runtime-params-inc.c
$(C_COMMON_H) \
$(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) \
$(GGC_H) $(BASIC_BLOCK_H) $(GIMPLE_H) $(CFGLOOP_H) \
tree-pass.h $(MELT_H) \
$(srcdir)/melt/generated/meltrunsup.h \
$(srcdir)/melt/generated/meltrunsup-inc.cc \
gt-melt-runtime.h $(PLUGIN_H) $(TOPLEV_H) $(VERSION_H) \
| melt-runtime.args
ls -l melt-runtime.args
$(COMPILER) -c $(shell cat melt-runtime.args) $(OUTPUT_OPTION)
###
But I cannot figure out easily how to adapt these rules to the new Makefile.in
infrastructure.
Do you have any insights, in particular hints generic enough to be valuable
for other branches?
Perhaps adding a comment in the trunk's Makefile.in might be helpful too
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} ***
where to insert a new Simple IPA [measuring] pass from a plugin ?
Hello,
I want to insert, thru a plugin, a new IPA pass which won't change any
internal representation but will just count Gimples and functions at the IPA
level.
(for what it is worth, the plugin is MELT http://gcc-melt.org/
and the IPA pass is coded in MELT; but we can safely pretend
all this is C++ code - which in fact it is,
since MELT generates C++ code).
BTW, -fdump-passes show me notably:
tree-cfg: ON
*warn_function_return : ON
tree-ompexp : OFF
*build_cgraph_edges : ON
*free_lang_data : ON
ipa-visibility : ON
ipa-early_local_cleanups: ON
I have some issues finding the right place for such a pass. I was thinking of
passing
as the reference_pass_name of some struct register_pass_info either the
"ipa-visibility" string or the "visibility" string, but somehow that does not
work.
It is a pity that, AFAIK, a plugin cannot insert its pass in front of
the all_small_ipa_passes (the variable inside passes.c) - or of the
all_regular_ipa_passes; it would be
nice if we had some plugin API for such things. What do you think?
BTW, I also have a suggestion. We have some (relatively new) code
(perhaps from 4.8) which suggest names in error messages when an
identifier is misspelled..
Can't we use the same code (or at least same algorithm) to suggest
a pass name when given a mispelled pass name from a plugin?
In general, I find that we are a bit lacking documentation about where
and how a plugin can insert its own passes.
Regards.
PS. See also http://gcc.gnu.org/ml/gcc/2010-11/msg00638.html
--
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 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} ***
Re: Questions about LTO infrastructure and pragma omp target
On Fri, 2013-08-23 at 13:17 +0200, Jakub Jelinek wrote:
[...]
> Then the question is what the plugin should perform with these sections,
> whether it will compile each input .gnu.target_lto section hunk separately
> (as in non-LTO mode), or with -flto also LTO them together.
[...]
Since plugins are mentioned (and I guess Jakub was talking of linker
plugins) I would add that GCC plugins might want to add (and later use)
their own arbitrary LTO data in these sections.
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: New file extension
On Tue, Jul 30, 2013 at 11:51:35AM +, Joseph S. Myers wrote:
> On Tue, 30 Jul 2013, Basile Starynkevitch wrote:
>
> > I think it is a good idea now (except perhaps for the very few source files
> > which could still be compiled by a plain C, not C++, compiler; maybe we
> > don't have anymore them...).
>
> gcov-io.c is C code used for both host and target (one of the remaining
> bits of target library source not moved out of the gcc/ directory because
> of the complications of the dual way it's used), but it's used for the
> host (and built as C++ when so used) via #include in other .c files rather
> than being built directly.
>
> Various Ada runtime library files are also .c under gcc/ada - in general,
> I'm not sure which .c files there are used as C, C++ or both, and which
> are used for host, target or both; that would require careful
> investigation for any renaming.
Ok. Then we could at leat rename to *.cc those files which are obviously
directly
using C++ features (e.g. the class or virtual C++ keywords).
Maybe these files should before renaming have
#ifndef __cplusplus
#error should be compiled as C++ code
#endif
??
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: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree. Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either. In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line... That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
>
> Any issues with doing a mass rename then?
I think it is a good idea now (except perhaps for the very few source files
which could still be compiled by a plain C, not C++, compiler; maybe we
don't have anymore them...).
FWIW, when compiling GCC trunk with Clang3.4 (i.e. on Debian/Sid+Experimental)
I am getting warnings about *.c being a C++ file.
And I think newbies are distracted also by .c files being in C++ (not to mention
emacs or other editors being possibly confused).
So I am in favor of a massive renaming. (But please do it in one single huge
svn commit).
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} ***
Ann: MELT 0.9.9 plugin release for GCC 4.6, 4.7, 4.8
ut
the hook cannot be unknown: only applications can be done with
statically unknown operators.
***
* EVAL function
An EVAL function has been added, it wraps the existing
TRANSLATE_RUN_MELT_EXPRESSIONS utility function so works by
generating C/C++ code then loading and running it.
Runtime improvements
***
* To register your MELT pass, use the INSTALL_MELT_PASS_IN_GCC
function instead of the obsolete INSTALL_MELT_GCC_PASS
primitive. Notice that INSTALL_MELT_PASS_IN_GCC is incompatible
with the older INSTALL_MELT_GCC_PASS, because you need to pass
the :after keyword instead of the "after" cstring, etc, etc...
***
* Many plugin events are interfaced (using hook machinery).
Some of them are incompatible with previous MELT releases.
***
* Add macro melt_low_debug_value(Message,Value) to debug-print
some arbitrary MELT value in C/C++ code or chunk.
This goes thru a predefined hook, similar to the DEBUG macro of MELT.
***
* Add C variable melt_plugin_name containing the name of the MELT
plugin, useful for using register_callback.
***
* Raised default threshold for GC. The MELT full garbage
collector is less called.
***
* Many bug fixes and internal improvements... Emitted C/C++ code
contains more checks.. REPL and EVAL modes are working much better.
***
* More primitives and functions
#
Please download MELT plugin 0.9.9, and report success and bugs on
the gcc-melt googlegroup list : gcc-m...@googlegroup.com
(within a day, I will also announce on SourceForge & FreeCode ...)
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} ***
MELT 0.9.9 rc3 plugin release candidate for GCC 4.6, 4.7, 4.8
solete INSTALL_MELT_GCC_PASS
primitive. Notice that INSTALL_MELT_PASS_IN_GCC is incompatible
with the older INSTALL_MELT_GCC_PASS, because you need to pass
the :after keyword instead of the "after" cstring, etc, etc...
***
* Many plugin events are interfaced (using hook machinery).
Some of them are incompatible with previous MELT releases.
***
* Add macro melt_low_debug_value(Message,Value) to debug-print
some arbitrary MELT value in C/C++ code or chunk.
This goes thru a predefined hook, similar to the DEBUG macro of MELT.
***
* Add C variable melt_plugin_name containing the name of the MELT
plugin, useful for using register_callback.
***
* Raised default threshold for GC. The MELT full garbage
collector is less called.
***
* Many bug fixes and internal improvements... Emitted C/C++ code
contains more checks..
***
* More primitives and functions
#
Please report build successes and bugs on gcc-melt list at googlegroups.com :
gcc-m...@googlegroups.com
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} ***
MELT 0.9.9 rc2 plugin release candidate for GCC 4.6, 4.7, 4.8
Dear All,
It is my pleasure to annnounce the MELT plugin 0.9.9 rc2 release candidate 2.
This is a significant release of the MELT plugin (and the last able to work as
plugin to GCC 4.6)
See http://gcc.gnu.org/ml/gcc/2013-06/msg1.html for the details and the
important new features of MELT 0.9.9
This second release candidate fixes the following bugs w.r.t. 0.9.9rc1
* ability to compile as plugin for GCC 4.6
* adding variadic arithmetic operators + - * /
You can download the gnuzipped source tarball from
http://gcc-melt.org/melt-0.9.9-rc2-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
as a gzipped source tarball of 5713838 bytes of md5sum
e43477646d7955fda414a76e57dc31a1
extracted from MELT branch svn rev. 199607 on june 03rd 2012.
Please report bugs on gcc-melt googlegroup list that is
gcc-m...@googlegroups.com
If no significant bugs are reported (or found) I will probably make this
the 0.9.9 release of MELT plugin for GCC 4.6, 4.7, and 4.8
in a couple of days.
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} ***
MELT 0.9.9 rc1 plugin release candidate for GCC 4.6, 4.7, 4.8
Some of them are incompatible with previous MELT releases.
***
* Add macro melt_low_debug_value(Message,Value) to debug-print
some arbitrary MELT value in C/C++ code or chunk.
This goes thru a predefined hook, similar to the DEBUG macro of MELT.
***
* Add C variable melt_plugin_name containing the name of the MELT
plugin, useful for using register_callback.
***
* Many bug fixes and internal improvements... Emitted C/C++ code
contains more checks..
***
* More primitives and functions
#
Please download and report bugs on gcc-m...@googlegroups.com
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: libbacktrace & plugins....
On Mon, May 20, 2013 at 08:43:06AM -0700, Ian Lance Taylor wrote:
> On Mon, May 20, 2013 at 7:31 AM, Basile Starynkevitch
> wrote:
> >
> > Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV)
> > libbacktrace is apparently not able
> > to show backtrace information inside the plugin[s].
> >
> > I believe that, at least on GNU/Linux wich has dladdr, it would be nice to
> > extend libbacktrace
> > to show backtrace information inside plugins (at least those compiled with
> > -g).
> >
> > Is is reasonably feasible? I'm not familiar with libbacktrace, but (since
> > MELT would be very happy with that)
> > I might perhaps help
>
> That is actually supposed to work already. The code is in
> libbacktrace/elf.c. It calls dl_iterate_phdr to find all the shared
> libraries loaded into the process. I never tested it with dlopen so I
> can certainly believe that it doesn't work, but I don't know why it
> doesn't work.
Maybe I am wrong (I did not make any testcase for that).
I very rarely have a SIGSEGV in MELT (because usually my own backtrace
machinery works well),
and when it happens it usually happens inside MELT generated C code which is
dlopened
(and not always compiled with -g) by the melt.so plugin. (so it is not a direct
GCC plugin).
Sorry for the noise.
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} ***
libbacktrace & plugins....
Hello All,
Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV)
libbacktrace is apparently not able
to show backtrace information inside the plugin[s].
I believe that, at least on GNU/Linux wich has dladdr, it would be nice to
extend libbacktrace
to show backtrace information inside plugins (at least those compiled with -g).
Is is reasonably feasible? I'm not familiar with libbacktrace, but (since MELT
would be very happy with that)
I might perhaps help
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: -Og changes on 4.7.3?
On Sun, May 12, 2013 at 09:03:34PM -0400, Gene Smith wrote:
> Could the -Og patches for 4.8 be back-ported to 4.7.3? Or is there
> important 4.8 dependencies that would make this not practicable?
I have no idea about the hypothetical future GCC 4.7.4, but I guess that the
general policy would
be to avoid such a significant patch ...
> The patches to add -Og shown on gcc.patches list don't look
> extremely extensive.
But they may depend of other improvements in 4.8
>
> This would be for personal use and not necessarily proposed for
> general release.
For personal use it is so much simpler to just build GCC 4.8 and use it.
No good reason to stick to a patched GCC 4.7
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: Simple way to pass new #pragma to GIMPLE
On Tue, Apr 09, 2013 at 01:21:27PM +, Evgeny Gavrin wrote:
> Is there any simple way to add support of custom pragma-directive for C/C++ =
> front-ends?
> I'm trying to avoid lots of modifications on every level from pa=
> rser to GIMPLE.
Yes, make a GCC plugin (in C++) or better yet a MELT extension (see
http://gcc-melt.org/
for more about MELT which is a high-level domain specific language to extend
GCC)
to add your pragmas.
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: Obtaining a callsite address.
On Sun, Mar 10, 2013 at 10:54:39PM +1100, Matt Davis wrote:
> On Sun, Mar 10, 2013 at 9:35 PM, Basile Starynkevitch
> wrote:
> > On Sun, Mar 10, 2013 at 01:51:04PM +1100, Matt Davis wrote:
> >> I have a GIMPLE_CALL gimple object. I want to get the tree node
> >> representing the callsite for this particular instance of a call, how
> >> can I get this information?
> >
> > I'm not sure to understand your question (what exactly do you mean by
> > "callsite").
>
> Hi Basile,
> Thanks for the quick response. I have a particular instance of a
> function call within a function that I am analyzing (and
> transforming). I want the address of that function call, for which I
> do have a gimple_call instance of. I want to somehow create a symbol
> identifying that particular address/location for that instance of the
> function call. I need this address at runtime. I was inserting labels
> just after each function call, but the placement of my label was not
> always immediately after the function call, even if I set the label as
> being addressable and/or volatile.
I would rather put the label just before the function call, not after it. (or
maybe do both)
Maybe you could do something else, like generate debug related gimples
But I don't understand well what will happen to these added gimples after your
pass.
BTW, where exactly did you insert your 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 mines, sont seulement les miennes} ***
Re: Obtaining a callsite address.
On Sun, Mar 10, 2013 at 01:51:04PM +1100, Matt Davis wrote:
> I have a GIMPLE_CALL gimple object. I want to get the tree node
> representing the callsite for this particular instance of a call, how
> can I get this information?
I'm not sure to understand your question (what exactly do you mean by
"callsite").
However, the called function can be obtained by gimple_call_fndecl which gives
a tree.
If using MELT http://gcc-melt.org/ you just use a gimple_call pattern...
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: Bootstrapping process
On Fri, Feb 01, 2013 at 08:56:43PM +, Alec Teal wrote:
>
> If you could link such documentation but about the way GCC is built,
> then you'd be answering my question
http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides.
http://gcc-melt.org/docum.html has some slides notably
http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf
which might also help.
And you can find many other resources on the web too...
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: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 09:31:50PM +, Alec Teal wrote:
>
> It'd be really cool if GCC could compile to LLVM and also parse it.
There exist a dragonegg plugin to GCC which uses GCC front-end and LLVM
back-end (& middle-end)
http://dragonegg.llvm.org/
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: gcc : c++11 : full support : eta?
On Thu, Jan 24, 2013 at 08:11:25PM +, Alec Teal wrote:
> On 24/01/13 19:55, Diego Novillo wrote:
> >...
> I don't know enough yet but GCC seems to be partitioned, this back
> and front end,
There is also a middle-end in GCC (and IMNSHO the middle-end of GCC is its
biggest part; it is the thing which does not depend much on the source language
and on the target processor & system).
FWIW, there is some partial documentation about GCC (notably some slides I have
made) on http://gcc-melt.org/docum.html
(of course the main emphasis is on MELT, but there are some explanations about
GCC internals)
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: hard typdef - proposal - I know it's not in the standard
On Wed, Jan 23, 2013 at 06:53:06AM +, Alec Teal wrote:
> Hello,
>
> This suggestion is obviously about typdefs and discusses a
> *theoretical* implementation, well a few of them. Anyway please do
> read this though. I'm really sorry for the poor structure, my hands
> are really cold and I'm quite tired.
> I understand that this issue has been discussed A LOT and there are
> ways around the limitation, I suspect what I write is nothing new, I
> don't claim to be the first ever.
>
> Why not:
>
> make an "optional keyword", "hard", have a meaning if before
Make your "hard" an attribute of variables:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
Write a plugin http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
or a MELT extension (http://gcc-melt.org/ is a domain specific language to
extend GCC)
dealing with that attribute.
This would be a good way to experiment your idea.
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: Building GCC using C++
On Tue, Jan 15, 2013 at 11:36:53AM +0530, Uday P. Khedker wrote:
>
>
> Basile Starynkevitch wrote, On Tuesday 15 January 2013 11:34 AM:
> >My belief is that it is no more possible to configure a recent GCC straight
> >(non-cross) compiler without --enable-language=c++
> >(that is, if you ask only for --enable-languages=c either configure
> >should bark, or it should also implicitly add C++).
>
> I was able to build gcc-4.7.2 with --enable-languages=c only :-)
But does the build and installed binaries contain some g++ ? I guess they do!
In other words --enable-languages=c should silently imply
--enable-languages=c,c++
But I am not entirely sure.
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: Building GCC using C++
On Tue, Jan 15, 2013 at 11:16:54AM +0530, Uday P. Khedker wrote:
> I was trying to understand the exact meaning of a loose statement
> floating around ("gcc has moved to C++ from version 4.7 onwards).
>
> I reckon from http://gcc.gnu.org/wiki/gcc-in-cxx that now gcc is
> compiled using C++. However, the very first line of the description
> confused me. It says:
>
> >GCC has been building stages 2 and 3 in C++ mode for a while.
>
> My understanding was that stage 2 is built using the compiler created
> in stage 1 and stage 3 is built using the compiler created in stage 2.
> (Please see slide 17/53 in
> http://www.cse.iitb.ac.in/grc/gcc-workshop-12/downloads/slides/gccw12-config-build.pdf).
>
> Can someone tell me what is the meaning of building stage 2 in C++
> mode? If I restrict my languages (using --enable-languages) to C,
My belief is that it is no more possible to configure a recent GCC straight
(non-cross) compiler without --enable-language=c++
(that is, if you ask only for --enable-languages=c either configure
should bark, or it should also implicitly add C++).
I can't explain in the details how ...
Cheers, & best wishes for 2013.
--
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} ***
edges, plugins, and why they need a GC....
Hello All,
I've got the following behavior in some MELT extension, but I am translating
that as if it was a plain C plugin to GCC.
See https://groups.google.com/d/msg/gcc-melt/mHbiKcI8dZA/gCMT-943IjQJ for the
original issue.
My colleague Emmanuel Haucourt wants to dump some control flow information into
a file
(to be later analyzed by a static analyzer ALCOOL detecting deadlocks in some
multi-threaded
[pseudo-] code)
So he decided to copy some edge pointers in his plugin pass inserted after the
"phiopt" pass,
these edge are copied to some static GTY-ed data (actually, to some MELT
values, but from GCC
point of view, it is the same as some static GTY-ed data in his pass).
Later another pass (or plugin event) tries to access these edges and crashes
(because they have been forcibly destroyed).
However, edges are (unfortunately, and IMHO even wrongly) forcibly destroyed in
the "expand"
pass of file gcc/cfgexpand.c
So even if edges are GTY-ed, they get forcibly destroyed (by "expand" pass
calling cleanup_cfg
which calls remove_edge which forcibly calls ggc_free on them, even if they are
kept in some plugin
GTY-ed static data.
It would be more correct to have the Ggc doing its job, and to avoid
remove_edge calling ggc_free
(which would be called anyway at ggc_collect time).
Alternatively, (for those advocates of removing the GC instead of improving it)
every data in Ggc which is accessible from plugins should have a destroy event
(what Gtk or Qt do in that respect could be inspiring) or plugin hook,
to give plugins opportunity to clean their internal state, or use some smart
pointer.
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: Graphite TODO tasks
On Tue, Jan 01, 2013 at 03:23:06PM +0530, Shakthi Kannan wrote:
> Greetings!
>
> I would like to know if there are any TODO tasks that I can work on to
> get started with Graphite/GCC. I came across Tobias Grosser's post
> regarding Graphite development at:
>
> http://gcc.gnu.org/wiki/Graphite-4.8
In addition of that list, I would suggest adding plugin support & hooks into
graphite.
For instance, it is currently not really possible to make the Graphite-OpenCL
hack
as a plugin to GCC 4.8 (or the next GCC), because
(that was at least true more than a year ago, when I looked in details):
* some internal data are not GTY-ed inside graphite. It is quite important
for plugins
that the data they manipulate is properly GTY-ed and handled by Ggc
(and deleted only by the Ggc, so that plugin passes could manipulate them
easily,
share them between several passes, etc).
* there is no plugin hooks at all in graphite, even for simple things like
dealing
with induction variables, SCOP, etc... A lot of information computed by
graphite
passes could be useful to plugins.
As a general hint, my suggestion would be to improve Graphite till the
Graphite-OpenCL hack
could be coded as a GCC plugin. (I don't think that Graphite-OpenCL should be a
core feature
of GCC, I do think it is a typical use case for plugins, but the current
Graphite infrastructure
does not allow that because of nasty details. Today, to make Grahpite-OpenCL as
a plugin,
one have to copy-paste the code of Graphite passes, patche them as
Graphite-OpenCL did,
and replace the core Graphite passes with their Graphite-OpenCL improvement;
this is messy, error-prone, ugly; it would be better if Graphite gave enough
plugin hooks to avoid that).
If you add plugin abilities to Graphite passes, please document that!
Happy new year 2013 to everyone.
--
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} ***
Ann: MELT plugin 0.9.8 release for GCC 4.6, 4.7 & future 4.8
Dear All,
It is my pleasure to announce the MELT plugin 0.9.8 for GCC 4.6, 4.7 & future
4.8
Download
http://www.gcc-melt.org/melt-0.9.8-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
a gzipped source tarball of 5377928 bytes of md5sum
6c0721202857c44a8edb1ae2252605e8 extracted from MELT branch svn rev. 194693
on december 22nd 2012.
MELT is a high-level domain specific language to extend the GCC compiler.
See http://gcc-melt.org/ for more. Notice that the web site gcc-melt.org has
been revamped and contains much more information than before (and more tutorial
information
as web pages, even if that is still incomplete).
Download
http://www.gcc-melt.org/melt-0.9.8-plugin-for-gcc-4.6-or-4.7-or-4.8.tar.gz
If you wan a two-page printable leaflet about MELT download
gcc-melt.org/gcc-melt-sheet.pdf
NEWS for 0.9.8 MELT plugin for GCC 4.6 & 4.7 & future 4.8
[[december, 22th, 2012]]
Language improvements
=
* The LET syntax accepts bindings with the :auto ctype-annotation, like e.g.
(let ( (:auto four (+i 2 2)) )
(debug "four=" four))
the ctype is the obtained by the expression defining that binding
i.e. (+i 2 2) it the above example which is of ctype_long.
The default ctype annotation -which used to be :value- is now :auto
this change is upward compatible but is very significant.
* BOX-ing and CONSTANT_BOX-ing syntactic constructs
The (BOX ) syntax makes a mutable value boxing the given
stuff. So for example (BOX (+i 2 1)) is the same
as (MAKE_INTEGERBOX DISCR_INTEGER (+i 2 1))
The (CONSTANT_BOX ) syntax makes a constant value boxing the
given stuff. So for example (CONSTANT_BOX 1) is the same as
the expression (MAKE_INTEGERBOX DISCR_CONSTANT_INTEGER 1)
* UNBOX-ing syntactic construct
The (UNBOX ) is a convenient way to unbox values. For example
the expression (UNBOX :TREE V) is the same as (TREE_CONTENT V)
Runtime improvements
A new evalfile mode is available to evaluate expressions from a
file (default is standard input).
The evaluating modes are diplaying the last evaluated expression
using the debug depth parameter, which can be set with
-fplugin-arg-melt-debug-depth=10 program argument.
C-types have now autoboxing fields. Discriminants for constant
boxing of stuff have been added, notably
DISCR_CONSTANT_BASIC_BLOCK, DISCR_CONSTANT_EDGE,
DISCR_CONSTANT_GIMPLE, DISCR_CONSTANT_GIMPLE_SEQ,
DISCR_CONSTANT_LOOP, DISCR_CONSTANT_TREE
Vector from GCC 4.8 are now possible inside MELT.
A melt_intern_cstring function is available in C to intern
arbitrary null-terminated strings.
The melt-module.mk makefile is accepting the
GCCMELT_MODULE_VERBOSE_BUILD variable.
Several primitives have been added.
* Numerous bug fixes.
Comments are welcome, notably on the gcc-m...@googlegroups.com list.
I strongly invite every person downloading MELT to subscribe & read that list.
Merry Christmas and Happy New Year to everyone.
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: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>
> Note that I don't think that non-GC is inherently better than GC. In fact,
> using a GC leads to easier maintainable code. The fact that we are more
> memory hungry than necessary (and also maybe consume more compile-time
> than necessary) is because our GC isn't exactly using technology known
> for 25 years (generational and copying collection come to my mind).
I definitely agree with that. And FWIW,
MELT (http://gcc-melt.org/ has since its beginning a generational
copying garbage collector above ggc+gengtype, so that is definitely doable.
I would wish that GCC systematically used a generational copying GC scheme.
However, this requires that the GCC community agree with that goal (and
apparently,
most - or some - people want on the contrary to get rid of GC).
FWIW, C++ may help in having a manageable copying GC inside GCC,
provided every GCC contributor agree with it. (The hard point is that
garbage collection deals with a global -non-modular- property of
the GCC program -liveness of data-, so it is not feasible to introduce
a generational copying GC progressively or incrementally).
What a precise copying generational GC needs to know is all
the local (and global) variables containing GC-managed pointer data.
The important word is *all*, and that means that everyone should agree to
use it.
We could for instance have a template for every garbage collector local
pointer,
and declare everywhere locals like
gclocal pt1, pt2;
gclocal pg;
we could also have them handled by a preprocessor (à la gengtype) and make that
something like
GCLOCAL(tree pt1, pt2);
GCLOCAL(gimple pg);
Introducing a copying generational scheme would involve perhaps a bigger effort
than the vec.h transition, because a lot of GCC source files would have to be
somehow modified.
(there is an economical & social issue here: who is brave enough to spend time
to work on that?
Few people could take the risk to experiment that if an agreement on GC cannot
be reached)
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: RFC - Alternatives to gengtype
On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
> On 11/18/2012 07:06 PM, NightStrike wrote:
>
> >What's wrong with std::shared_ptr?
>
> The pointer needs two words, and the per-object overhead for the
> reference counts etc. is four words, if I'm counting correctly.
>
> (Other forms of reference counting have less overhead, of course,
> but you were asking about std::shared_ptr.)
Actually, this observation may favor a real garbage collector. Marking GC as
simple as ggc+gengtype usually have one (or a few) mark bits, so can consume
only a few bits (or perhaps a byte in some mark array) per object. Copying GC
could avoid consuming any more storage per object. Of course useless object may
stay in memory for a while -until the GC deletes them or reuse their memory-
but that observation is also true with traditional C++ "GC" techniques like
shared_ptr An object may be freed later than what should be possible.
And some GC techniques are quite friendly with L1 or L2 caches on the processor
chip.
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: Unifying the GCC Debugging Interface
On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
[]
> >> All of these functions come in two forms.
> >>
> >> function (FILE *, item_to_dump, formatting)
> >> function (item_to_dump, formatting)
Since we have switched to C++, it would be really nice to have dump functions
writing to a C++ std::ostream
Plugins would be very happy if the output stream was a C++ one (at least MELT
certainly will be happy).
Otherwise, they may spend a lot of boring effort to make that happen
(and fmemopen is less standard than std::ostream).
So please, let's dump to some std::ostream; it is much easy to use other
streams
(e.g. ostringstream-s) for other purposes (I am guessing that every language
binding
to plugins -we have MELT, Python, Lua, already) will be really happy to at
least be able to output to some memory buffer (and with ostream-s, we have much
more).
Ideally, we could have some default formatting and even get some operator <<
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: RFC - Alternatives to gengtype
On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
> On 18 November 2012 18:25, Basile Starynkevitch wrote:
> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> >> wrote:
> >> > I really think that GCC need some form of garbage collector.
> > [...]
> >>
> >> What's wrong with std::shared_ptr?
> > How does it deal with complex circular references that every compiler has?
> >
> > I'm understanding that std::shared_ptr cannot realiably deal with circular
> > references
> > (because it maintains essentially a reference counter).
> >
> > Could you explain me how std::shared_ptr deal with circular references?
>
> See http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html
Which mentions weak_ptr, which sort of prove my point.
You are suggesting that by appropriately and wisely mixing shared_ptr &
weak_ptr, some circular references could carefully be handled (with caution and
care).
I'm thinking that using them reliably in GCC (a so big piece of software that
very few people understand it enough) is practically impossible for newbies,
because it requires them to understand very deeply all
the possible interactions between other pieces of software and their own.
I do know about shared_ptr & weak_ptr (20+ years ago, I developped a lot of
NeWS code -NeWS was a graphical window server then developped at Sun and it has
also weak & shared references inside their PostScript superset). By experience,
these notions do not scale well to huge software base like GCC.
So my thinking is that, to lower the [huge] difficulties of enabling GCC
newbies to contribute robust code to GCC, a systematic approach like the one
given by gengtype+ggc, or the one possible with a real
garbage collector, you don't put the burden of knowing exactly where to put
shared_ptr, where to put auto_ptr, where to put weak_ptr, onto the shoulders of
GCC newbies. A garbage collector provides a systematic, fail-proof, solutions
(of course, even with a GC, memory leaks can happen; but they are much less
dangerous than sigsegv).
And notice also that the current GCC internal representations have very
incomplete documentation.
(most of the good documentation is outside GCC, e.g. on
http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ etc). There is nowhere on
gcc.gnu.org a clear picture (or a clear, but complete text) of all the major
GCC internal representations (gimple, gimple_seq, basic_block, edge, loop,
cgraph, ...) and all their interdependencies.
I believe that GCC needs to worry much more about attracting and keeping new
young talents, and systematic solutions (like the one provided by a garbage
collector) are much more appropriate
than shared_ptr+weak_ptr tricks.
I am in favor of more generic and easy solutions, than ones which require a
deep knowledge of an huge existing undocumented or under-documented code base
(even if such approaches would slow down the compilation time a little bit; so
I would accept the 5% slowdown possible with Boehm GC).
I notice (and I am not alone) that most young people attracted by working on
compilation of procedural languages are today lurking on LLVM, not on GCC.
Using std::shared_ptr & std::weak_ptr reliably is not realistic for newbies on
a such large (and such under-documented) legacy code base as GCC. Gengtype+ggc
is ugly, but it did provide a systematic way to add data inside GCC.
shared_ptr+weak_ptr don't provide a systematic way.
Regards.
PS. LLVM has also a decisive documentation advantage w.r.t. GCC
--
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: RFC - Alternatives to gengtype
On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> wrote:
> > I really think that GCC need some form of garbage collector.
[...]
>
> What's wrong with std::shared_ptr?
How does it deal with complex circular references that every compiler has?
I'm understanding that std::shared_ptr cannot realiably deal with circular
references
(because it maintains essentially a reference counter).
Could you explain me how std::shared_ptr deal with circular references?
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: RFC - Alternatives to gengtype
On Sun, Nov 18, 2012 at 11:25:55AM -0500, Diego Novillo wrote:
> I agree with the analysis of Uday and Basile. [...]
>
> However, let's discuss this topic in some other thread, please. I'd
> like to take this thread back to the original topic: what do we do
> with GC and PCH?
I really think that GCC need some form of garbage collector.
If it is Ggc+gengtype (to be improved), or Boehm GC, or even
some other GC (for instance both
http://starynkevitch.net/Basile/qishintro.html and
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-runtime.c
are or contain precise copying collectors that I wrote, and with
some effort that could be made nicely compatible with C++).
But my feeling is that a lot of people don't want GCC to
have any kind of garbage collector and dream of having only manual
allocation & de-allocation (I Basile personally think that it is not realistic
and not desirable, because it will make future contributions to GCC much more
costly to develop, and I probably would myself lose interest in GCC
when garbage collection will be removed).
Regarding PCH [pre-compiled header], I think that it is related to PPH
[pre-processed headers]
I don't understand yet if PPH is abandoned, or just post-poned. I was
believing it was a very mature experimental branch.
A very related question, now that we have switched to C++, is: do we accept
the idea of having a common ancestor class (e.g. a GccObject root class
for GCC, like GObject is for GTK and QObject is for Qt) with virtual methods
(i.e. do we accept a vtable) for essential GCC datatypes like edge, gimple,
basic_block and tree-s. My understanding is that many people firmly reject
such an idea (probably because it might perhaps make gimple one word fatter).
But I would easily imagine that having a single top GccObject root class,
with several virtual abstract methods inside, could considerably help
in implementing new garbage collection scheme and a lot of utility
functionality (e.g. for dump perhaps LTO & perhaps PCH
we would just have some virtual methods in GccObject for them).
I also don't understand if PCH is really important; I feel that very few people
are using it (in particular, because it practically requires a single header
file for all of the application). In other words, could we give up PCH
(probably not, but I don't understand why), e.g. give up PCH for GCC 5.0
(and aim to have PPH for GCC 5.1)?
My feeling is that the question of having a garbage collector inside GCC
is not the same as the question of keeping gengtype+ggc in its present form
(or in an improved form).
At last, I don't understand if experimenting with e.g. a single GccObject
root class is easily feasible (is it a matter of just adding some inheritance
in a few *.h files, or is it much worse than that).
Now, I do admit that I don't have a clear overall picture about GCC,
and that all global reviewers have a much better whole picture of GCC than I do.
BTW, perhaps what might be missing is a good analysis & detailed metrics
of the existing GCC source base. Perhaps some plugin or extension of GCC
could help to make it.
(I Basile would be very happy to work on a MELT extension to access and
measure and navigate inside the entire GCC compiler, but this is a quite
big project, and I don't know how could I be funded to work on this).
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} ***
