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} ***