Bug C++ 111974 (Segmentation fault of GCC, ubuntu 23.10, compiling RefPerSys 041d5d70aefd)
Hello all, Sorry for this non-minimal bug report. I was unable to make a shorter or minimal bug example. RefPerSys is a GPLv3+ open source project for an inference engine. See http://refpersys.org/ for ambitions and some details. (I am currently more interested in working on RefPerSys than on debugging GCC, to which I did contribute earlier). RefPerSys is itself on github in https://github.com/RefPerSys/RefPerSys/ I am compiling RefPerSys (mostly C++ code, including some self generated, which is including in the below snapshot) on Ubuntu 23.10 whose g++ has version (Ubuntu 13.2.0-4ubuntu3) 13.2.0 on a desktop with AMD Ryzen Threadripper 2970WX The RefPerSys commit is https://github.com/RefPerSys/RefPerSys/commit/041d5d70aefd047de4eb456432853beefffb4120 and has a few tests: eg make test00 test01 did work a few days ago. I uploaded to http://refpersys.org/refpersys-gcc13bug-snapshot-25oct2023-git041d5d70aefd0.tar.bz2 a bzip2 compressed tarball (29246912 bytes) of md5sum 6b1d2985ce86bd1718d05af3d93a84f9 That tarball is likely to be removed in a few months. The disk space for the RefPerSys source code (with object files) take less than 200 Mbytes. To reproduce the GCC bug, run make (GNU make 4.3 from Ubuntu) in the tarball If you did reproduce it, please email me (Basile Starynkevitch, in France) to bas...@starynkevitch.net Regards -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
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: [wwwdocs] extensions.html - remove "rogue" MELT page
On 6/15/19 9:45 PM, Gerald Pfeifer wrote: On Sun, 15 Jul 2018, Basile Starynkevitch wrote: Basile, should we generally remove this reference to GCC MELT? Yes. I am no more working on MELT, but I did begin to work on its successor: Sorry for the delay - I finally applied the patch below. If/when you want that successor to be listed on our extensions page, please advise (ideally submitting a patch, or even going ahead an applying it and just posting the patch). The successor (Bismon) is not ready, it is free software (GPLv3+ license), but still unreleased. So alpha stage. And it is a research project (so obligation of means, not of results). You could look at the code on http://github.com/bstarynk/bismon/ (the copyright belongs to my employer, but could be transfered to FSF when/if wanted). You could read a technical draft report on Bismon on http://starynkevitch.net/Basile/bismon-chariot-doc.pdf but this is a draft report and I am quite often improving it; feel free to provide any feedback to me (by email) about it; the title of that report is quite baroque, but mandated by the H2020 project funding the work. Notice that H2020 projects (see https://en.wikipedia.org/wiki/Framework_Programmes_for_Research_and_Technological_Development#Horizon_2020 for more) are excessively bureaucratic (and more than previous European research projects), and not very FSF or GNU or free software friendly. I don't even know if that Bismon will be ready for GCC before I am retiring. (probably in 2024, and perhaps in 2023). I do know that once retired, I won't work on Bismon (and probably won't work much on GCC neither). I would work on some other free software project (also GPLv3+). I am waiting for my retirement Cheers. -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: 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, _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
Re: [wwwdocs] extensions.html - remove "rogue" MELT page
On 07/15/2018 07:12 AM, Basile Starynkevitch wrote: On 07/14/2018 10:17 PM, Gerald Pfeifer wrote: I noticed that http://gcc-melt.org now redirects to http://www.gcc-melt.org which looks like a default, and empty, Wordpress installation. I went ahead and applied the patch below. Basile, should we generally remove this reference to GCC MELT? Gerald Index: extensions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v retrieving revision 1.59 diff -u -r1.59 extensions.html --- extensions.html 2 Jun 2018 21:16:09 - 1.59 +++ extensions.html 14 Jul 2018 20:14:45 - @@ -21,7 +21,7 @@ analysis, debugging, and performance tuning in concurrent code. -http://gcc-melt.org;>GCC MELT +GCC MELT MELT is a high-level domain specific language to ease the development of GCC extensions. It is available as a GCC experimental Yes. I am no more working on MELT, but I did begin to work on its successor: https://github.com/bstarynk/bismon I forgot to tell that the old GCC MELT pages are still online, but the gcc-melt.org domain has vanished. The old GCC MELT pages are available on http://starynkevitch.net/Basile/gcc-melt/ Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: [wwwdocs] extensions.html - remove "rogue" MELT page
On 07/14/2018 10:17 PM, Gerald Pfeifer wrote: I noticed that http://gcc-melt.org now redirects to http://www.gcc-melt.org which looks like a default, and empty, Wordpress installation. I went ahead and applied the patch below. Basile, should we generally remove this reference to GCC MELT? Gerald Index: extensions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v retrieving revision 1.59 diff -u -r1.59 extensions.html --- extensions.html 2 Jun 2018 21:16:09 - 1.59 +++ extensions.html 14 Jul 2018 20:14:45 - @@ -21,7 +21,7 @@ analysis, debugging, and performance tuning in concurrent code. -http://gcc-melt.org;>GCC MELT +GCC MELT MELT is a high-level domain specific language to ease the development of GCC extensions. It is available as a GCC experimental Yes. I am no more working on MELT, but I did begin to work on its successor: https://github.com/bstarynk/bismon Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France
Re: JIT patch: add gcc_jit_magic_int
On 06/07/2016 09:19 PM, Andrew Pinski wrote:
On Mon, May 23, 2016 at 5:26 AM, Basile Starynkevitch
<bas...@starynkevitch.net> wrote:
Hello All,
As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is
difficult (or tricky without using dirty tricks involving the GCC plugin
headers) to use GCCJIT to emit code equivalent to the following C file:
extern int a;
int get_atomic_a (void) {
return __atomic_load_n (, __ATOMIC_SEQ_CST);
}
The issue is that __ATOMIC_SEQ_CST is a magic preprocessor (but
non-standard!) symbol which might not be available
(or might have a different value) in the C code for GCCJIT building such an
AST.
So we need a function to retrieve some magic integral value from the GCCJIT
compiler.
Huh?Why can't you just use the enum:
enum memmodel
{
MEMMODEL_RELAXED = 0,
MEMMODEL_CONSUME = 1,
MEMMODEL_ACQUIRE = 2,
MEMMODEL_RELEASE = 3,
MEMMODEL_ACQ_REL = 4,
MEMMODEL_SEQ_CST = 5,
MEMMODEL_LAST = 6,
MEMMODEL_SYNC_ACQUIRE = MEMMODEL_ACQUIRE | MEMMODEL_SYNC,
MEMMODEL_SYNC_RELEASE = MEMMODEL_RELEASE | MEMMODEL_SYNC,
MEMMODEL_SYNC_SEQ_CST = MEMMODEL_SEQ_CST | MEMMODEL_SYNC
};
(sorry for the late reply)
I think that Andrew Pinski is right, and that we should make that enum
available in libgccjit.h.
David Malcolm, please tell us how should that be done? Would you accept
a #include "coretypes.h" inside libgccjit.h? Or should I copy paste the
enum memmodel into libgccjit.h?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
JIT patch: add gcc_jit_magic_int
Hello All,
As I explained in https://gcc.gnu.org/ml/jit/2016-q2/msg00042.html it is
difficult (or tricky without using dirty tricks involving the GCC plugin
headers) to use GCCJIT to emit code equivalent to the following C file:
extern int a;
int get_atomic_a (void) {
return __atomic_load_n (, __ATOMIC_SEQ_CST);
}
The issue is that __ATOMIC_SEQ_CST is a magic preprocessor (but non-standard!)
symbol which might not be available
(or might have a different value) in the C code for GCCJIT building such an AST.
So we need a function to retrieve some magic integral value from the GCCJIT
compiler.
The attached patch (relative to trunk svn 236583) is a first attempt to solve
that issue
(and also give ability to query some other magic numbers).
Proposed ChangeLog entry (in gcc/jit/)
2016-05-23 Basile Starynkevitch <bas...@starynkevitch.net>
* libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_magic_int): New macro.
(gcc_jit_magic_int): New public function declaration.
* libgccjit.c: Include "cppbuiltin.h", "options.h", "flag-types.h"
(gcc_jit_magic_int): New function.
* libgccjit.map: Add gcc_jit_magic_int to LIBGCCJIT_ABI_6.
Comments (or an ok to commit) are welcome. (I am not sure that
__SANITIZE_ADDRESS__ is correctly handled,
because I would believe that optimization flags are not globals in GCCJIT)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/libgccjit.h
===
--- gcc/jit/libgccjit.h (revision 236583)
+++ gcc/jit/libgccjit.h (working copy)
@@ -1387,6 +1387,27 @@
gcc_jit_rvalue_set_bool_require_tail_call (gcc_jit_rvalue *call,
int require_tail_call);
+
+ /* Magical integer values useful in the compiler; similar to
+ predefined C macros like __GNUC__, __GNUC_MINOR__,
+ __GNUC_PATCHLEVEL__, __ATOMIC_RELAXED, __ATOMIC_SEQ_CST,
+ __ATOMIC_ACQUIRE, __ATOMIC_RELEASE, __ATOMIC_ACQ_REL,
+ __ATOMIC_CONSUME, __PIC__, __PIE__, etc. Typical usage would be:
+
+bool err=false;
+int mypic = gcc_jit_magic_int("__PIC__", );
+if (err) somethinggotwrong();
+
+This function is expected to be rarely called, typically once at
+initialization time.
+
+ This API entrypoint was added in LIBGCCJIT_ABI_6; you can test for its
+ presence using
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_magic_int
+ */
+#define LIBGCCJIT_HAVE_gcc_jit_magic_int
+extern int gcc_jit_magic_int(const char*name, bool*errp);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
Index: gcc/jit/libgccjit.c
===
--- gcc/jit/libgccjit.c (revision 236583)
+++ gcc/jit/libgccjit.c (working copy)
@@ -23,6 +23,9 @@
#include "coretypes.h"
#include "timevar.h"
#include "typed-splay-tree.h"
+#include "cppbuiltin.h"
+#include "options.h"
+#include "flag-types.h"
#include "libgccjit.h"
#include "jit-recording.h"
@@ -2970,3 +2973,44 @@
call->set_require_tail_call (require_tail_call);
}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+int gcc_jit_magic_int(const char*name, bool*errp)
+{
+ static int major, minor, patchlevel;
+ if (!major) /* call once: */
+parse_basever (, , );
+
+ RETURN_VAL_IF_FAIL (name,
+ errp?((*errp=true),0):0,
+ NULL, NULL,
+ "NULL name");
+ RETURN_VAL_IF_FAIL (name[0] == '_' && name[1] == '_',
+ errp?((*errp=true),0):0,
+ NULL, NULL,
+ "name should start with two underscores");
+#define HAVE_MAGIC_INT(NamStr,Val) do { \
+ if (!strcmp(name, NamStr)) { \
+ if (errp) *errp = false; \
+ return Val; }} while(0)
+ // keep these in alphabetical order...
+ HAVE_MAGIC_INT("__ATOMIC_ACQUIRE", MEMMODEL_ACQUIRE);
+ HAVE_MAGIC_INT("__ATOMIC_ACQ_REL", MEMMODEL_ACQ_REL);
+ HAVE_MAGIC_INT("__ATOMIC_CONSUME", MEMMODEL_CONSUME);
+ HAVE_MAGIC_INT("__ATOMIC_RELAXED", MEMMODEL_RELAXED);
+ HAVE_MAGIC_INT("__ATOMIC_RELEASE", MEMMODEL_RELEASE);
+ HAVE_MAGIC_INT("__ATOMIC_SEQ_CST", MEMMODEL_SEQ_CST);
+ HAVE_MAGIC_INT("__GNUC_MINOR__", minor);
+ HAVE_MAGIC_INT("__GNUC_PATCHLEVEL__", patchlevel);
+ HAVE_MAGIC_INT("__GNUC__", major);
+ HAVE_MAGIC_INT("__PIC__", flag_pic);
+ HAVE_MAGIC_INT("__PIE__", flag_pie);
+ HAVE_MAGIC_INT("__SANITIZE_ADDRESS__", flag_sanitize & SANITIZE_ADDRESS);
+ HAVE_MAGIC_INT("__SANITIZE_THREAD__", flag_sanitize & SANITIZE_THREAD);
+#undef HAVE_MAGIC_INT
+ RETURN_VAL_IF_FAIL_PRINTF1 (false, errp?((*errp=true),0):0,
+
Re: [PATCH 0/3] Support for mandatory tail calls
On 05/19/2016 12:12 AM, Jeff Law wrote:
On 05/17/2016 04:01 PM, David Malcolm wrote:
There have been requests [1] for libgccjit to better support
functional programming by supporting the contination-passing style,
in which every function "returns" by calling a "continuation"
function pointer.
These calls must be guaranteed to be implemented as a jump,
otherwise the program could consume an arbitrary amount of stack
space as it executed.
This patch kit implements this.
Patch 1 is a preliminary tweak to calls.c
Patch 2 implements a new flag in tree.h: CALL_EXPR_MUST_TAIL_CALL,
which makes calls.c try harder to implement a flagged call as a
tail-call/sibling call, and makes it issue an error if
the optimization is impossible. It doesn't implement any
frontend support for setting the flag (instead using a plugin
to test it). We had some discussion on the jit list about possibly
introducing a new builtin for this, but the patch punts on this
issue.
I wonder if we should have an attribute so that the flag can be set
for C/C++ code. I've seen requests for forcing tail calls in C/C++
code several times in the past, precisely to support continuations.
Why an attribute? Attributes are on declarations. I think it should
better be some pragma like _Pragma(GCC tail cail, foo(x,y)) or some
builtin (or else some syntax extension like goto return foo(x,y); ...)
because what we really want is to annotate a particular call to be
tail-recursive.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
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} ***
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: 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
<bas...@starynkevitch.net> 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} ***
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} ***
magic 8 constant (bits / byte maybe?) in GCC JIT memento_of_new_rvalue_from_const long::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 long. */
template
bool
memento_of_new_rvalue_from_const long::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
PATCH (v2) trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 21:16, David Malcolm wrote:
Perhaps, but note that nothing in a regular gcc bootstrap uses
libgccjit, so you *might* still have a latent linking error that shows
up only at run time. Running the jit testsuite is the best way to be
sure.
And I'm testing that on
x86-64/Linux where the patch is almost useless.
Thanks for your other comments. I'm trying to understand them and I am
working on that.
Cheers
Here (attached gcc-jitlonglong-r225860.diff)
is an improved version of my patch against trunk r225860.
Thanks to David Malcom for the kind help.
### gcc/jit/ ChangeLog entry
2015-07-16 Basile Starynkevitch bas...@starynkevitch.net
* jit-playback.c: Mention that it is in C++.
(new_rvalue_from_const long): New.
* jit-recording.c: Mention that it is in C++.
(recording::memento_of_new_rvalue_from_const long long): New
instanciated template.
(memento_of_new_rvalue_from_const long long::make_debug_string):
New specialized function.
(memento_of_new_rvalue_from_const long long::get_wide_int): New
specialized function.
(recording::memento_of_new_rvalue_from_const long
long::write_reproducer): Likewise.
* libgccjit.c: Mention that it is in C++.
(gcc_jit_context_new_rvalue_from_long_long): New function.
(gcc_jit_context_new_rvalue_from_int32): New function.
(gcc_jit_context_new_rvalue_from_int64): New function.
(gcc_jit_context_new_rvalue_from_intptr): New function.
* libgccjit.h: #include stdint.h
(gcc_jit_context_new_rvalue_from_long_long): New declaration.
In the declarations of the functions below, a short comment
explains that they are convenience functions.
(gcc_jit_context_new_rvalue_from_int32): New declaration.
(gcc_jit_context_new_rvalue_from_int64): New declaration.
(gcc_jit_context_new_rvalue_from_intptr): New declaration.
* libgccjit.map: Add LIBGCCJIT_ABI_4 for new functions
e.g. gcc_jit_context_new_rvalue_from_long_long,
## gcc/testsuite/ChangeLog entry
* test-constants.c (make_test_of_long_long_constant): New function.
(make_tests_of_long_long_constants): New.
(verify_long_long_constants): New.
(create_code): Call make_tests_of_long_long_constants.
(verify_code): Call verify_long_long_constants.
I have mixed feelings about adding the
gcc_jit_context_new_rvalue_from_int32
gcc_jit_context_new_rvalue_from_int64
gcc_jit_context_new_rvalue_from_intptr functions.
On one hand, their name is very suggestive, and most programmers know
about stdint.h. I should confess that I discovered only recently that
long long is guaranteed by C99 standard to be at least 64 bits (I
thought that the standard just required that long long is at least as
big as long).
On the other hand, we are adding more functions to the ABI, and indeed
the gcc_jit_context_new_rvalue_from_long_long is in principle enough.
Perhaps we should simply document that for int32_t, int64_t, intptr_t
types, the GCCJIT user should test the sizeof intptr_t and call the
appropriate function?
BTW some bytecodes or VMs (in particular the JVM) are hardcoding the
size of some integers, so dealing explicitly with int32_t int64_t
definitely makes sense.
The patch is passing the test that I have added, on Debian/x86-64.
Comments are welcome, including perhaps an Ok for trunk...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/jit-playback.c
===
--- gcc/jit/jit-playback.c (revision 225860)
+++ gcc/jit/jit-playback.c (working copy)
@@ -1,4 +1,5 @@
-/* Internals of libgccjit: classes for playing back recorded API calls.
+/* This jit-playback.c file is in -*- C++ -*- ...
+ Internals of libgccjit: classes for playing back recorded API calls.
Copyright (C) 2013-2015 Free Software Foundation, Inc.
Contributed by David Malcolm dmalc...@redhat.com.
@@ -573,6 +574,30 @@ new_rvalue_from_const long (type *type,
}
}
+
+/* Specialization of making an rvalue from a const, for host long long. */
+
+template
+rvalue *
+context::
+new_rvalue_from_const long long (type *type,
+ long long value)
+{
+ // FIXME: type-checking, or coercion?
+ tree inner_type = type-as_tree ();
+ if (INTEGRAL_TYPE_P (inner_type))
+{
+ tree inner = build_int_cst (inner_type, value);
+ return new rvalue (this, inner);
+}
+ else
+{
+ REAL_VALUE_TYPE real_value;
+ real_from_integer (real_value, VOIDmode, value, SIGNED);
+ tree inner = build_real (inner_type, real_value);
+ return new rvalue (this, inner);
+}
+}
/* Specialization of making an rvalue from a const, for host double. */
template
Index: gcc/jit/jit-recording.c
PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to GCCJIT.
It is bootstrapping, but I don't have any test cases
## gcc/jit/ChangeLog entry:
2015-07-15 Basile Starynkevitch bas...@starynkevitch.net
* libgccjit.h (gcc_jit_context_new_rvalue_from_long_long)
(gcc_jit_context_new_rvalue_from_int32)
(gcc_jit_context_new_rvalue_from_int64)
(gcc_jit_context_new_rvalue_from_intptr): New function
declarations.
* libgccjit.map: New entries for above functions.
* libgccjit.c (gcc_jit_context_new_rvalue_from_long_long)
(gcc_jit_context_new_rvalue_from_int32)
(gcc_jit_context_new_rvalue_from_int64)
(gcc_jit_context_new_rvalue_from_intptr): New functions.
###
Comments are welcome. Ok for trunk?
see https://gcc.gnu.org/ml/jit/2015-q3/msg00085.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/jit/libgccjit.c
===
--- gcc/jit/libgccjit.c (revision 225842)
+++ gcc/jit/libgccjit.c (working copy)
@@ -1154,6 +1154,70 @@ gcc_jit_context_new_rvalue_from_long (gcc_jit_cont
-new_rvalue_from_const long (numeric_type, value));
}
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_long_long (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ long long value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, NULL context);
+ JIT_LOG_FUNC (ctxt-get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ -new_rvalue_from_const long long (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int32 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int32_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, NULL context);
+ JIT_LOG_FUNC (ctxt-get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ -new_rvalue_from_const int32_t (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int64 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int64_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, NULL context);
+ JIT_LOG_FUNC (ctxt-get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ -new_rvalue_from_const int64_t (numeric_type, value));
+}
+
+
+/* Public entrypoint. See description in libgccjit.h. */
+
+gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_intptr (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ intptr_t value)
+{
+ RETURN_NULL_IF_FAIL (ctxt, NULL, NULL, NULL context);
+ JIT_LOG_FUNC (ctxt-get_logger ());
+ RETURN_NULL_IF_FAIL_NONNULL_NUMERIC_TYPE (ctxt, numeric_type);
+
+ return ((gcc_jit_rvalue *)ctxt
+ -new_rvalue_from_const intptr_t (numeric_type, value));
+}
+
+
/* Public entrypoint. See description in libgccjit.h.
This is essentially equivalent to:
Index: gcc/jit/libgccjit.h
===
--- gcc/jit/libgccjit.h (revision 225842)
+++ gcc/jit/libgccjit.h (working copy)
@@ -752,6 +752,26 @@ gcc_jit_context_new_rvalue_from_long (gcc_jit_cont
long value);
extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_long_long (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ long long value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int32 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int32_t value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_int64 (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ int64_t value);
+
+extern gcc_jit_rvalue *
+gcc_jit_context_new_rvalue_from_intptr (gcc_jit_context *ctxt,
+ gcc_jit_type *numeric_type,
+ intptr_t value);
+
+extern gcc_jit_rvalue *
gcc_jit_context_zero (gcc_jit_context *ctxt,
gcc_jit_type *numeric_type);
Index: gcc/jit/libgccjit.map
===
--- gcc/jit/libgccjit.map (revision 225842)
+++ gcc/jit/libgccjit.map (working copy)
@@ -61,7 +61,10 @@ LIBGCCJIT_ABI_0
gcc_jit_context_new_param;
gcc_jit_context_new_rvalue_from_double;
gcc_jit_context_new_rvalue_from_int;
+gcc_jit_context_new_rvalue_from_int32;
+gcc_jit_context_new_rvalue_from_int64;
gcc_jit_context_new_rvalue_from_long;
+gcc_jit_context_new_rvalue_from_long_long
Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
* dump_to_reproducer support (most testcases attempt to dump their
contexts to a .c file and then sanity-check the generated c by
compiling them, though not running them; see jit.exp). A new API
entrypoint needs to know how to write itself back out to C (by
implementing gcc::jit::recording::memento::write_reproducer for the
appropriate memento subclass).
I'm sorry, but I can't understand the above comment. Where is the
Implementation of recording::memento::write_reproducer for longs. I
can't find such comment in jit-recording.c!
BTW, it is really a pity that even a brand new subtree like gcc/jit/,
coded mostly in C++, uses *.c
as the file extension for newly introduced C++ files. There is no legacy
reason to use *.c extensions for new C++ files (as we had for source
files of twenty years of age). I really find that confusing. And no
comment mention that it is C++ not C!
It makes me almost cry :-)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc...
On 07/15/2015 20:52, David Malcolm wrote:
On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote:
Hello All and David Malcolm
The attached patch (relative to trunk r224842) is adding
gcc_jit_context_new_rvalue_from_long_long and similar functions to
GCCJIT.
Does this actually link and run? This appears to be missing some
implementations of the template specializations in jit/jit-recording.c
for the new specializations of new_rvalue_from_const. If these are
missing, I'd expect to see a linker error at run-time when attempting
to run client code that links against such a libgccjit.so.
It does bootstrap (in the GCC sense). I suspect that C++ integral
promotion or casting rules are enough to have something being linked,
but probably not what is really needed. And I'm testing that on
x86-64/Linux where the patch is almost useless.
Thanks for your other comments. I'm trying to understand them and I am
working on that.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
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: basileatstarynkevitchdotnet 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
Re: Four jit backports to gcc 5 branch
On Mon, Jun 29, 2015 at 11:44:31AM -0400, David Malcolm wrote: I've gone over the changes to the gcc/jit and gcc/testsuite/jit.dg directories in trunk since gcc 5 and backported the following 4 changes from trunk to the gcc-5-branch: I'll be delighted if switch statements ability would be backported to GCC 5. (Its absence is IMHO a severe bug in GCCJIT, but perhaps GCC rules forbid backporting new features, even when they correct a huge deficiency and when the patch adding them is probably quite small). Cheers. -- Basile Starynkevitch http://starynkevitch.net/Basile/
Re: [PATCH 2/2] jit: add switch statements
On 06/25/2015 09:13 PM, David Malcolm wrote:
Some interpreters/VMs support a switch statement (for example the JVM
has opcodes lookupswitch and tableswitch). GCC has a set of
optimizations for efficiently handling switch statements, so it makes
sense to directly expose switch statements in the libgccjit API.
Yes, I hope that feature will be incorporated quickly in gccjit. I don't
have the power to approve that patch, but I hope it will be approved.
This patch implements a switch statement, but it isn't quite ready for
committing to trunk yet:
* It relies on gcc/typed-splay-tree.h in the previous patch
* It extends the libgccjit API. It's not clear to me yet how to
manage extensions of the libgccjit API: should I use symbol maps
and versioning, or bump the SONAME? I'm thinking of providing
precanned feature macros within libgccjit.h e.g:
#define LIBGCCJIT_HAVE_SWITCH_STATEMENT
for the benefit of client code that doesn't use configure
scripts.
Perhaps just exposing the major and minor version of the GCC supporting
that GCCJIT is enough (like it was done for plugins, e.g.
GCCPLUGIN_VERSION etc)?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
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 gc/gc.h
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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
bad patch for GCCPLUGIN_VERSION... help needed!
Hello All, In https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01393.html I posted a bad patch (to generate a plugin-version.c for gcc_version outside of plugin-version.h) but I can't find out what is wrong? Could any person much more familiar with autoconf that I am take a few seconds to look at it, please! I'm sure my mistake is trivial, but I cannot find it. I really hope this would go into GCC 5.0 (and the delay is short), because MELT http://gcc-melt.org/ is needing it. Regards thanks for your help. -- Basile Starynkevitch http://starynkevitch.net/Basile/
PATCH GCC5.0: conditionally skip gcc_version in gcc-plugin.h
Hello All,
Some plugins (including MELT, see http://gcc-melt.org/ for more)
are made of several C++ source files which all include plugin-version.h
because they have some C++ code which depends upon the particular version
of GCC.
So they typically code
#if GCCPLUGIN_VERSION = 4009
/* code for GCC 4.9 or newer. */
#else
/* code for GCC 4.8 */
#endif /*GCCPLUGIN_VERSION*/
after including plugin-version.h; however that file also defines static
data, notably `gcc_version`. That data symbol may be useless in most of
the plugin files -except the one initializing the plugin. Having several
useless data symbols may disturb the debugger (since the static symbol
`gcc_version` is no longer unique) and may consume some tiny useless data
(at least when the plugin is compiled with -O0).
The attached small patch (for trunk svn rev. 217404) disables the definition
of `gcc_version` when the preprocessor symbol GCCPLUGIN_SKIP_VERSION_DATA
is defined as 1 before #include plugin-version.h
### gcc/ChangeLog entry:
2014-11-12 Basile Starynkevitch bas...@starynkevitch.net
* configure.ac (plugin-version.h): Don't define version data
when GCCPLUGIN_SKIP_VERSION_DATA was #define-d as 1.
* doc/plugins.texi: (Plugins building): Document
GCCPLUGIN_SKIP_VERSION_DATA. Put it with GCCPLUGIN_VERSION* names
in the function index.
###
Ok for trunk? Comments are welcome.
Regards
--
Basile Starynkevitch http://starynkevitch.net/Basile
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 217404)
+++ gcc/configure.ac (working copy)
@@ -1664,6 +1664,10 @@
#define GCCPLUGIN_VERSION_PATCHLEVEL `echo $gcc_BASEVER | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$/\1/'`
#define GCCPLUGIN_VERSION (GCCPLUGIN_VERSION_MAJOR*1000 + GCCPLUGIN_VERSION_MINOR)
+/* Some plugins might not want the data below, they would define
+ GCCPLUGIN_SKIP_VERSION_DATA as 1 before including this. */
+
+#if !GCCPLUGIN_SKIP_VERSION_DATA
static char basever[] = $gcc_BASEVER;
static char datestamp[] = $gcc_DATESTAMP;
static char devphase[] = $gcc_DEVPHASE;
@@ -1675,6 +1679,7 @@
static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
configuration_arguments};
+#endif /* GCCPLUGIN_SKIP_VERSION_DATA */
EOF
changequote([,])dnl
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 217404)
+++ gcc/doc/plugins.texi (working copy)
@@ -157,6 +157,16 @@
but you can also check the individual fields if you want a less strict check.
+A plugin might want to include in some of its source files the
+@file{plugin-version.h} header for preprocessor constants
+@code{GCCPLUGIN_VERSION} without defining the static symbol
+@code{gcc_version}. In that case it should define the preprocessor
+symbol @code{GCCPLUGIN_SKIP_VERSION_DATA} to @code{1} before including
+that header.
+@findex GCCPLUGIN_VERSION
+@findex GCCPLUGIN_SKIP_VERSION_DATA
+@findex gcc_version
+
@subsection Plugin callbacks
Callback functions have the following prototype:
@@ -488,6 +498,10 @@
#error this GCC plugin is for GCC 4.7
#endif
@end smallexample
+@findex GCCPLUGIN_VERSION_MAJOR
+@findex GCCPLUGIN_VERSION_MINOR
+@findex GCCPLUGIN_VERSION_PATCHLEVEL
+@findex GCCPLUGIN_VERSION
The following GNU Makefile excerpt shows how to build a simple plugin:
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, Nov 12, 2014 at 02:12:07PM +0100, Jakub Jelinek wrote: On Wed, Nov 12, 2014 at 01:55:12PM +0100, Basile Starynkevitch wrote: Hello All, Some plugins (including MELT, see http://gcc-melt.org/ for more) are made of several C++ source files which all include plugin-version.h because they have some C++ code which depends upon the particular version of GCC. So they typically code #if GCCPLUGIN_VERSION = 4009 /* code for GCC 4.9 or newer. */ #else /* code for GCC 4.8 */ #endif /*GCCPLUGIN_VERSION*/ Can't you just remember that version in configure of your plugin? Most plugin don't need any configure, because they are installed in a version specific directory (like /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin for example). I don't think it is wise to require plugin to be autoconf-configurable. Their Makefile simply uses $(shell gcc -print-file-name=plugin), there is no need to complex autoconf machinery. And even a plugin for a particular version of GCC is usually made of several files, all of them with #include plugin-version.h; there is no need to define several times gcc_version. (another possibility might be to make gcc_version an external symbol with public visibility inside the cc1 or cc1plus executable) Thanks for your comment. Cheers. -- Basile Starynkevitchhttp://starynkevitch.net/Basile/
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote: On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote: Most plugin don't need any configure, because they are installed in a version specific directory (like /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin for example). I don't think it is wise to require plugin to be autoconf-configurable. Their Makefile simply uses $(shell gcc -print-file-name=plugin), there is no need to complex autoconf machinery. If you use $(shell gcc -print-file-name=plugin), there is no point to include plugin-version.h, just use __GNUC__/__GNUC_MINOR__ ? I could compile a plugin (notably for a GCC cross-compiler) with a GCC version different of the GCC targetting the plugin. I could also compile a plugin with Clang or some other non-GCC compiler. In both cases plugin-version.h is needed with its GCCPLUGIN_VERSION. Cheers. -- Basile Starynkevitch http://starynkevitch.net/Basile/
Re: PATCH GCC5.0: conditionally skip gcc_version in plugin-version.h
On Wed, 2014-11-12 at 14:36 +0100, Basile Starynkevitch wrote:
On Wed, Nov 12, 2014 at 02:29:13PM +0100, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 02:20:22PM +0100, Basile Starynkevitch wrote:
Most plugin don't need any configure, because they are installed in
a version specific directory (like
/usr/lib/gcc/x86_64-linux-gnu/4.9/plugin
for example). I don't think it is wise to require plugin to be
autoconf-configurable. Their Makefile simply uses
$(shell gcc -print-file-name=plugin), there is no need to complex
autoconf machinery.
If you use $(shell gcc -print-file-name=plugin), there is no point
to include plugin-version.h, just use __GNUC__/__GNUC_MINOR__ ?
I could compile a plugin (notably for a GCC cross-compiler) with a GCC version
different of the GCC targetting the plugin. I could also compile a
plugin with Clang or some other non-GCC compiler. In both cases
plugin-version.h is needed with its GCCPLUGIN_VERSION.
I'm trying to patch GCC to get a plugin-version.c file generated, but I
can't get that work. Here is attached a buggy patch against trunk svn
r217460 which does not work. Could any one help me to catch my mistake
please?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 217460)
+++ fixincludes/fixincl.x (working copy)
@@ -1,12 +1,12 @@
/* -*- buffer-read-only: t -*- vi: set ro:
- *
+ *
* DO NOT EDIT THIS FILE (fixincl.x)
- *
- * It has been AutoGen-ed October 21, 2014 at 10:18:16 AM by AutoGen 5.16.2
+ *
+ * It has been AutoGen-ed
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Oct 21 10:18:17 CEST 2014
+/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Nov 13 07:50:38 MET 2014
*
* You must regenerate it. Use the ./genfixes script.
*
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 217460)
+++ gcc/Makefile.in (working copy)
@@ -1324,6 +1324,7 @@
opts-global.o \
passes.o \
plugin.o \
+ plugin-version.o \
postreload-gcse.o \
postreload.o \
predict.o \
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 217460)
+++ gcc/configure.ac (working copy)
@@ -1656,7 +1656,25 @@
else
gcc_REVISION=
fi
+
+cat plugin-version.c EOF
+/* generated file plugin-version.c for GCC */
+#include plugin-version.h
+static const char basever[] = $gcc_BASEVER;
+static const char datestamp[] = $gcc_DATESTAMP;
+static const char devphase[] = $gcc_DEVPHASE;
+static const char revision[] = $gcc_REVISION;
+
+/* FIXME plugins: We should make the version information more precise.
+ One way to do is to add a checksum. */
+
+const struct plugin_gcc_version gcc_version = {basever, datestamp,
+ devphase, revision,
+ configuration_arguments};
+EOF
+
cat plugin-version.h EOF
+/* generated header plugin-version.h for GCC */
#include configargs.h
#define GCCPLUGIN_VERSION_MAJOR `echo $gcc_BASEVER | sed -e 's/^\([0-9]*\).*$/\1/'`
@@ -1664,18 +1682,9 @@
#define GCCPLUGIN_VERSION_PATCHLEVEL `echo $gcc_BASEVER | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$/\1/'`
#define GCCPLUGIN_VERSION (GCCPLUGIN_VERSION_MAJOR*1000 + GCCPLUGIN_VERSION_MINOR)
-static char basever[] = $gcc_BASEVER;
-static char datestamp[] = $gcc_DATESTAMP;
-static char devphase[] = $gcc_DEVPHASE;
-static char revision[] = $gcc_REVISION;
+extern const struct plugin_gcc_version gcc_version;
+EOF
-/* FIXME plugins: We should make the version information more precise.
- One way to do is to add a checksum. */
-
-static struct plugin_gcc_version gcc_version = {basever, datestamp,
- devphase, revision,
- configuration_arguments};
-EOF
changequote([,])dnl
# Internationalization
Re: [jit] Drop libgccjit.pc
On Mon, 2014-10-20 at 13:54 -0400, David Malcolm wrote:
Committed to branch dmalcolm/jit:
pkg-config appears to be controversial, so don't provide a .pc file.
I would put it under contrib/; it is controversial, but some would like
to have it.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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
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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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 reason-string)
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: basileatstarynkevitchdotnet 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 reason-string)
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: basileatstarynkevitchdotnet 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 stdlib.h
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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Ping^3 GCC trunk 4.9: documentation patch on plugins
On Sat, 2014-03-08 at 11:15 +0100, Basile Starynkevitch wrote:
I am pinging again this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
(pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on
febµ.17th 2014)
and also pinged at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00387.html on march 8th
2014
gcc/ChangeLog entry
2014-03-18 Basile Starynkevitch bas...@starynkevitch.net
* doc/plugins.texi (Plugin callbacks): Mention
PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain
PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after
PLUGIN_FINISH.
Explain what pragmas with expansion are.
the patch:
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 207422)
+++ gcc/doc/plugins.texi(working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing
callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO,
PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should
be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path
as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{GCCPLUGIN} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
#
Ok for 4.9?
Regards
Re: Ping^3 GCC trunk 4.9: documentation patch on plugins
Hello Diego all,
Here is a slightly improved patch to follow Diego's comments on
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00863.html
(since Diego improved the wording extracted from comments
in gcc/plugin.def I am also patching the comments in that file).
### gcc/Changelog entry
2014-03-18 Basile Starynkevitch bas...@starynkevitch.net
* plugin.def: Improve comment for PLUGIN_INCLUDE_FILE.
* doc/plugins.texi (Plugin callbacks): Mention
PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain
PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after
PLUGIN_FINISH.
Explain what pragmas with expansion are.
the [improved] patch against trunk 208643 is attached.
Ok for GCC trunk 4.9?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 208643)
+++ gcc/doc/plugins.texi (working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given via the #line directive.
+ This could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{GCCPLUGIN} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are supporting
+preprocessor expansions. For an example of using such a pragma:
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 208643)
+++ gcc/plugin.def (working copy)
@@ -92,8 +92,8 @@
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
-/* Called when a file is #include-d or given thru #line directive.
- Could happen many times. The event data is the included file path,
+/* Called when a file is #include-d or given via the #line directive.
+ this could happen many times. The event data
Re: Ping^3 GCC trunk 4.9: documentation patch on plugins
On Tue, 2014-03-18 at 08:53 -0400, Diego Novillo wrote:
OK with:
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are supporting
+preprocessor expansions. For an example of using such a pragma:
s/are supporting/support/
s/For an example of using such a pragma/For example/
Thanks for the review.
Committed revision 208660.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Ping^2 GCC trunk 4.9: documentation patch on plugins
Hello All,
I am pinging again this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
(pinged at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01002.html on febµ.17th
2014)
gcc/ChangeLog entry
2014-03-08 Basile Starynkevitch bas...@starynkevitch.net
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
the patch:
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi(revision 207422)
+++ gcc/doc/plugins.texi(working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{GCCPLUGIN} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
#
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH] Add some more headers to PLUGIN_HEADERS (PR plugins/59335)
On Wed, 2014-03-05 at 15:00 +0100, Jakub Jelinek wrote:
Hi!
The PR requests beyond the already commited ones some further headers.
Tested with make install, ok for trunk?
I am not authorized to approve that, but I hope it will be committed.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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] 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: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Addition of options in GCC
On Mon, Feb 24, 2014 at 12:32:22PM +0100, Alangi Derick wrote:
Hi
When looking at the gcc/gcc.c file, i noticed that some basic
options were not added to notify the user of gcc to be able to use it
and its essence. So due to this, i added some of the options like the
-ansi option. This file contains some other options like the -w and -Q
options.
gcc is mostly a driver program. The real work happens in cc1 or cc1plus (which
is started by gcc). So you need to look inside gcc/toplev.c and gcc/*.opt
files
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Ping GCC trunk 4.9: documentation patch on plugins
Hello All,
I am pinging this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
GCC trunk 4.9: documentation patch on plugins
Dear all,
The attached patch to trunk svn.rev 207422 is slightly improving the
documentation
of plugins (notably the few features bugfixes I have introduced in 4.9)
gcc/ChangeLog entry
2014-02-03 Basile Starynkevitch bas...@starynkevitch.net
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_INCLUDE_FILE.
Italicize plugin event names in description. Explain that
PLUGIN_PRAGMAS has no sense for lto1. Explain PLUGIN_INCLUDE_FILE.
Remind that no GCC functions should be called after PLUGIN_FINISH.
Explain what pragmas with expansion are.
Comments are welcome. Recall that I am not a native English speaker,
so please improve my wordings in the documentation.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/doc/plugins.texi
===
--- gcc/doc/plugins.texi (revision 207422)
+++ gcc/doc/plugins.texi (working copy)
@@ -209,6 +209,10 @@
PLUGIN_EARLY_GIMPLE_PASSES_END,
/* Called when a pass is first instantiated. */
PLUGIN_NEW_PASS,
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+ PLUGIN_INCLUDE_FILE,
PLUGIN_EVENT_FIRST_DYNAMIC/* Dummy event used for indexing callback
array. */
@@ -229,15 +233,27 @@
@item @code{void *user_data}: Pointer to plugin-specific data.
@end itemize
-For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, PLUGIN_REGISTER_GGC_ROOTS
-and PLUGIN_REGISTER_GGC_CACHES pseudo-events the @code{callback} should be
-null, and the @code{user_data} is specific.
+For the @i{PLUGIN_PASS_MANAGER_SETUP}, @i{PLUGIN_INFO},
+@i{PLUGIN_REGISTER_GGC_ROOTS} and @i{PLUGIN_REGISTER_GGC_CACHES}
+pseudo-events the @code{callback} should be null, and the
+@code{user_data} is specific.
-When the PLUGIN_PRAGMAS event is triggered (with a null
-pointer as data from GCC), plugins may register their own pragmas
-using functions like @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion}.
+When the @i{PLUGIN_PRAGMAS} event is triggered (with a null pointer as
+data from GCC), plugins may register their own pragmas. Notice that
+pragmas are not available from @file{lto1}, so plugins used with
+@code{-flto} option to GCC during link-time optimization cannot use
+pragmas and do not even see functions like @code{c_register_pragma} or
+@code{pragma_lex}.
+The @i{PLUGIN_INCLUDE_FILE} event, with a @code{const char*} file path as
+GCC data, is triggered for processing of @code{#include} or
+@code{#line} directives.
+
+The @i{PLUGIN_FINISH} event is the last time that plugins can call GCC
+functions, notably emit diagnostics with @code{warning}, @code{error}
+etc.
+
+
@node Plugins pass
@section Interacting with the pass manager
@@ -376,10 +392,13 @@
@end smallexample
-The @code{PLUGIN_PRAGMAS} callback is called during pragmas
-registration. Use the @code{c_register_pragma} or
-@code{c_register_pragma_with_expansion} functions to register custom
-pragmas.
+The @i{PLUGIN_PRAGMAS} callback is called once during pragmas
+registration. Use the @code{c_register_pragma},
+@code{c_register_pragma_with_data},
+@code{c_register_pragma_with_expansion},
+@code{c_register_pragma_with_expansion_and_data} functions to register
+custom pragmas and their handlers (which often want to call
+@code{pragma_lex}) from @file{c-family/c-pragma.h}.
@smallexample
/* Plugin callback called during pragmas registration. Registered with
@@ -397,7 +416,15 @@
It is suggested to pass @code{GCCPLUGIN} (or a short name identifying
your plugin) as the ``space'' argument of your pragma.
+Pragmas registered with @code{c_register_pragma_with_expansion} or
+@code{c_register_pragma_with_expansion_and_data} are allowing
+preprocessor expansions, like e.g.
+@smallexample
+#define NUMBER 10
+#pragma GCCPLUGIN foothreshold (NUMBER)
+@end smallexample
+
@node Plugins recording
@section Recording information about pass execution
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 algorithm
#include memory
#include functional
#include cstdio
#include gc/gc_allocator.h
gc_allocatorint mygcalloc;
extern C void apply_to_each(int lo, int hi,
const std::functionvoid(int)f)
{
for (int i=lo; ihi; i++) f(i);
}
extern C void test_gc_closure(int mx)
{
std::functionvoid(int) 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 functional 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 cstdio
#include array
#include functional
#include algorithm
int sum (const std::arrayint,10a)
{
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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
checking GPL compatibility in MELT meta-plugin
-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: basileatstarynkevitchdotnet 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 bas...@starynkevitch.net 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/licenses/gcc-exception-3.1.en.html and MELT would have produced a your-foo.so MELT binary module. Later on, (perhaps a week after) you'll use that module to analyze (or perhaps even optimize - which is against the GCC runtime exception if you distribute the so compiled binary) some other-bar.cc file g++ -fplugin=melt -fplugin-arg-melt-extra=your-foo
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: basileatstarynkevitchdotnet 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 a.t...@warwick.ac.uk 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Mon, Nov 18, 2013 at 10:50:10PM +, Joseph S. Myers wrote:
On Mon, 18 Nov 2013, Basile Starynkevitch wrote:
@@ -43,6 +44,7 @@
TARGET_OPTF. */
#include tm_p.h /* For C_COMMON_OVERRIDE_OPTIONS. */
+
#ifndef DOLLARS_IN_IDENTIFIERS
# define DOLLARS_IN_IDENTIFIERS true
#endif
This is a spurious diff hunk that should not be in this patch.
OK minus the spurious change in the absence of objections from the plugin
maintainers within 48 hours (or in the presence of approval from either of
them).
Thanks for your attention. I am attaching a slightly improved patch
against trunk svn rev. 305009 (the improvements are removing the spurious
diff hunk, and better comments.)
# gcc/c-family/ChangeLog entry :
2013-11-19 Basile Starynkevitch bas...@starynkevitch.net
* c-opts.c: Include plugin.h.
(cb_file_change): Invoke plugin event PLUGIN_INCLUDE_FILE.
# gcc/ChangeLog entry :
2013-11-19 Basile Starynkevitch bas...@starynkevitch.net
* plugin.def (PLUGIN_INCLUDE_FILE): New event, invoked in
cb_file_change.
###
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 205009)
+++ gcc/c-family/c-opts.c (working copy)
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3. If not see
#include debug.h /* For debug_hooks. */
#include opts.h
#include options.h
+#include plugin.h /* For PLUGIN_INCLUDE_FILE event. */
#include mkdeps.h
#include c-target.h
#include tm.h /* For BYTES_BIG_ENDIAN,
@@ -1397,6 +1398,17 @@ cb_file_change (cpp_reader * ARG_UNUSED (pfile),
else
fe_file_change (new_map);
+ if (new_map
+ (new_map-reason == LC_ENTER || new_map-reason == LC_RENAME))
+{
+ /* Signal to plugins that a file is included. This could happen
+ several times with the same file path, e.g. because of
+ several '#include' or '#line' directives... */
+ invoke_plugin_callbacks
+ (PLUGIN_INCLUDE_FILE,
+ const_castchar* (ORDINARY_MAP_FILE_NAME (new_map)));
+}
+
if (new_map == 0 || (new_map-reason == LC_LEAVE MAIN_FILE_P (new_map)))
{
pch_cpp_save_state ();
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 205009)
+++ gcc/plugin.def (working copy)
@@ -92,6 +92,12 @@ DEFEVENT (PLUGIN_EARLY_GIMPLE_PASSES_END)
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
+/* Called when a file is #include-d or given thru #line directive.
+ Could happen many times. The event data is the included file path,
+ as a const char* pointer. */
+DEFEVENT (PLUGIN_INCLUDE_FILE)
+
+
/* After the hard-coded events above, plugins can dynamically allocate events
at run time.
PLUGIN_EVENT_FIRST_DYNAMIC only appears as last enum element. */
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 16:16 +, Joseph S. Myers wrote:
On Tue, 19 Nov 2013, Basile Starynkevitch wrote:
Thanks for your attention. I am attaching a slightly improved patch
against trunk svn rev. 305009 (the improvements are removing the spurious
diff hunk, and better comments.)
Still OK in the absence of plugin maintainer objections.
Thanks: Committed revision 205038.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
Thanks: Committed revision 205038.
This seems to break several g++ tests: see
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
On x86_64-apple-darwin13, the ICE is
cc1: error: cannot load plugin ./one_time_plugin.so
dlopen(./one_time_plugin.so, 10): image not found
/opt/gcc/work/gcc/testsuite/gcc.dg/plugin/one_time-test-1.c:1:0: internal
compiler error: in invoke_plugin_callbacks_full, at plugin.c:509
/* Test that pass is inserted and invoked once. */
^
I don't have an Apple machine, but I cannot understand the logic (in
particular, did you make clean before recompiling and running the test).
The patch only added a new event. How can just adding a new event break
the thing?
I'm beginning more tests now, but I only have access to Gnu Linux x86-64
systems...
Or is it some MacOSX specific bug? (BTW, I thought that GCC plugins
never worked on MacOSX or on Windows)
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
Thanks: Committed revision 205038.
This seems to break several g++ tests: see
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
On x86_64-apple-darwin13, the ICE is
I would guess that the following trivial patch should correct that:
# patch against svn rev 205052
Index: gcc/plugin.c
===
--- gcc/plugin.c(revision 205052)
+++ gcc/plugin.c(working copy)
@@ -529,6 +529,7 @@ invoke_plugin_callbacks_full (int event, void *gcc
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
/* Iterate over every callback registered with this event and
call it. */
#
If that patch correct the bug, I guess that I could apply it under the
obvious bugfix rule. Could you check that it works on your MacOSX?
Apologies for my mistake.
Thanks
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
On Tue, 2013-11-19 at 20:33 +0100, Dominique Dhumieres wrote:
Thanks: Committed revision 205038.
This seems to break several g++ tests: see
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
On x86_64-apple-darwin13, the ICE is
cc1: error: cannot load plugin ./one_time_plugin.so
Actually, when we add hard coded plugin events we should never forget,
like I just did, to edit invoke_plugin_callbacks_full.
Diego and all, can I add the following patch to the trunk. One is just a
comment inside plugin.def to recall that invoke_plugin_callbacks_full
should be edited, and another is the tiny fix on that function in
plugin.c
### gcc/ChangeLog entry
2013-11-19 Basile Starynkevitch bas...@starynkevitch.net
* plugin.def: Add comment about register_callback and
invoke_plugin_callbacks_full.
* plugin.c (register_callback, invoke_plugin_callbacks_full):
Handle PLUGIN_INCLUDE_FILE event.
###
Apologies for my mistake. Hope this will be approved quickly before 4.9
stage 3! (I will later submit a documentation patch)
BTW, I am not very happy about some events in plugin.def not being real
events. IMHO I would prefer that PLUGIN_PASS_MANAGER_SETUP,
PLUGIN_REGISTER_GGC_ROOTS, PLUGIN_REGISTER_GGC_CACHES be removed,
because they are not real events (and they should have their own public
functions in plugin.h, e.g. add functions like
plugin_pass_manager_setup, plugin_register_ggc_roots,
plugin_register_ggc_caches in gcc/gcc-plugin.h). Unfortunately, we don't
have time for such an improvement for 4.9
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Index: gcc/plugin.c
===
--- gcc/plugin.c (revision 205052)
+++ gcc/plugin.c (working copy)
@@ -452,6 +452,7 @@ register_callback (const char *plugin_name,
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
struct callback_info *new_callback;
if (!callback)
@@ -529,6 +530,7 @@ invoke_plugin_callbacks_full (int event, void *gcc
case PLUGIN_EARLY_GIMPLE_PASSES_START:
case PLUGIN_EARLY_GIMPLE_PASSES_END:
case PLUGIN_NEW_PASS:
+ case PLUGIN_INCLUDE_FILE:
{
/* Iterate over every callback registered with this event and
call it. */
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 205052)
+++ gcc/plugin.def (working copy)
@@ -97,6 +97,9 @@ DEFEVENT (PLUGIN_NEW_PASS)
as a const char* pointer. */
DEFEVENT (PLUGIN_INCLUDE_FILE)
+/* When adding a new hard-coded plugin event, don't forget to edit in
+ file plugin.c the functions register_callback and
+ invoke_plugin_callbacks_full accordingly! */
/* After the hard-coded events above, plugins can dynamically allocate events
at run time.
Re: 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
patch PLUGIN_HEADER_FILE event for tracing of header inclusions.
Hello All
After http://gcc.gnu.org/ml/gcc/2013-11/msg00360.html
http://gcc.gnu.org/ml/gcc/2013-11/msg00361.html
http://gcc.gnu.org/ml/gcc/2013-11/msg00347.html I am proposing the
following patch
## patch
Index: gcc/plugin.def
===
--- gcc/plugin.def (revision 204976)
+++ gcc/plugin.def (working copy)
@@ -92,6 +92,10 @@
/* Called when a pass is first instantiated. */
DEFEVENT (PLUGIN_NEW_PASS)
+/* Called when a file is #include-d or given thru #line directive. */
+DEFEVENT (PLUGIN_INCLUDE_FILE)
+
+
/* After the hard-coded events above, plugins can dynamically allocate
events
at run time.
PLUGIN_EVENT_FIRST_DYNAMIC only appears as last enum element. */
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 204976)
+++ gcc/c-family/c-opts.c (working copy)
@@ -34,6 +34,7 @@
#include debug.h /* For debug_hooks. */
#include opts.h
#include options.h
+#include plugin.h/* For PLUGIN_INCLUDE_FILE event. */
#include mkdeps.h
#include c-target.h
#include tm.h/* For BYTES_BIG_ENDIAN,
@@ -43,6 +44,7 @@
TARGET_OPTF. */
#include tm_p.h /* For C_COMMON_OVERRIDE_OPTIONS. */
+
#ifndef DOLLARS_IN_IDENTIFIERS
# define DOLLARS_IN_IDENTIFIERS true
#endif
@@ -1397,6 +1399,16 @@
else
fe_file_change (new_map);
+ if (new_map
+ (new_map-reason == LC_ENTER || new_map-reason == LC_RENAME))
+{
+ /* Signal to plugins that a file is included. This could happen
+several times. */
+ invoke_plugin_callbacks
+ (PLUGIN_INCLUDE_FILE,
+const_castchar* (ORDINARY_MAP_FILE_NAME (new_map)));
+}
+
if (new_map == 0 || (new_map-reason == LC_LEAVE MAIN_FILE_P
(new_map)))
{
pch_cpp_save_state ();
### gcc/ChangeLog entry
2013-11-18 Basile Starynkevitch bas...@starynkevitch.net
* plugins.def (PLUGIN_INCLUDE_FILE): New event.
### gcc/c-family/ChangeLog entry
2013-11-18 Basile Starynkevitch bas...@starynkevitch.net
* c-opts.c: Include plugin.h header.
(cb_file_change): Sent plugin event PLUGIN_INCLUDE_FILE.
###
Ok for trunk?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Add __auto_type C extension, use it in stdatomic.h
On Wed, 2013-11-13 at 11:39 +0100, Richard Biener wrote:
On Wed, Nov 13, 2013 at 1:39 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
stdatomic.h contains what C11 describes as generic functions.
Although DR#419 makes clear that users cannot #undef these macros (or
otherwise suppress use of a macro definition) and expect to find an
underlying function, they still need to behave like functions as
regards evaluating their arguments exactly once (see C11 7.1.4).
I noted when adding stdatomic.h to mainline that some of the macro
definitions there failed that requirement in the case where the
pointer argument had variably modified type, because then typeof
evaluates its argument and so that argument would be evaluated twice.
Avoiding such double evaluation requires defining the type of a
temporary variable, and initializing it with the pointer argument,
with a single evaluation. To achieve this, this patch adds a new GNU
C extension __auto_type, essentially a restricted version of C++11
auto, and uses it in stdatomic.h.
I suppose you didn't use '__auto' because that's much more likely
used elsewhere than '__auto_type'?
I have no idea, but does anyone knows if other free compilers (notably
Clang/LLVM) are adding a similar feature?
If they do, perhaps (if it is not too painful) we should use the same
keyword (i.e. __auto_type) and a similar semantics.
And I also like that feature, but it should be documented outside of the
support of stdatomic.h since it is genuinely useful by itself (e.g. as
an alternative to typeof).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
patch ping: diagnostics finalization and plugins
Hello all,
I'm pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00056.html
##
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 204671)
+++ gcc/toplev.c(working copy)
@@ -1968,11 +1968,13 @@ toplev_main (int argc, char **argv)
if (warningcount || errorcount || werrorcount)
print_ignored_options ();
- diagnostic_finish (global_dc);
- /* Invoke registered plugin callbacks if any. */
+ /* Invoke registered plugin callbacks if any. Some plugins could
+ emit some diagnostics here. */
invoke_plugin_callbacks (PLUGIN_FINISH, NULL);
+ diagnostic_finish (global_dc);
+
finalize_plugins ();
location_adhoc_data_fini (line_table);
if (seen_error () || werrorcount)
gcc/ChangeLog entry
2013-11-11 Basile Starynkevitch bas...@starynkevitch.net
* toplev.c (toplev_main): Move PLUGIN_FINISH invocation before
diagnostic_finish.
Ok for trunk?
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [patch] Create gimple-expr..[ch] ... was Re: RFC: gimple.[ch] break apart
On Tue, Nov 05, 2013 at 11:26:46AM -0500, Andrew MacLeod wrote:
I decided to name the new file gimple-expr.[ch] instead of
gimple-decl This will eventually split into gimple-type.[ch],
gimple-decl.[ch], and gimple-expr.[ch].
Since we are adding *new* C++ files, can't we please name them *.cc
for the implementation part, so at least create gimple-expr.h and
gimple-expr.cc but not gimple-expr.c, please!
There are some reasons to keep existing *.c files containing C++ code
(IMHO the reasons are bad ones, and related to poor habits and to
deficiencies in the version control system we have to use,
but I really don't want to open that debate again).
But for **NEW** files which are definitely in C++, I don't understand
why they should be named .c files; this is confusing for all (and,
for instance, when compiling them with Clang we are getting -IMHO
rightly- some warnings about the file naming).
If I remember well, there have been (in the discussion about naming C++ source
files of GCC) a suggestion (and perhaps even a consensus),
probably by Diego Novillo, to name *.cc our new files which are in C++.
Having old C++ files named *.c is already a big frustration
(most editors are by default configured to handle them as C, not as C++, files
and most developers, notably newbies to GCC contributions,
are expecting them to be C files not C++ ones).
But IMHO having new source files inside GCC coded in C++ with a *.c file
extension
is non-sense; such files should have a .cc (or maybe .cpp or .cxx) extension,
not a .c extension.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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] Conversion of gimple types to C++ inheritance (v3)
On 10/31/2013 05:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.
[This is a revised version of the patches sent as:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01788.html
and
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01954.html
which got bogged down in discussion of hand-written GTY hooks. This
patch series updates things to make use of the new support in gengtype
for simple inheritance schemes]
The gimple statement types are currently implemented using a hand-coded
C inheritance scheme, with a union gimple_statement_d holding the
various possible structs for a statement.
The following series of patches convert it to a C++ hierarchy, using the
existing structs, eliminating the union. The gimple typedef changes
from being a
(union gimple_statement_d *)
to being a:
(struct gimple_statement_base *)
Very good idea. But please, document that in some texinfo file, probably
gcc/doc/gimple.texi
Gimple-s are so damn important, even for plugin writers, that a small
but up to date documentation is absolutely essential. You dont need to
write a lot of doc, just the minimal stuff (which at least tells which
file should the plugin writer look into and list all the relevant classes).
I hope your patches (or similar ones) will be accepted in 4.9
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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
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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [PATCH] make gengtype more robust against user error
On Fri, 2013-10-25 at 17:37 -0400, David Malcolm wrote:
This patch addresses various forms of failure described in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html
It adds a default: gcc_unreachable(); to the autogenerated switch()
statement in the routines for a base class, converting various kinds of
tag errors from leading to silent lack-of-field traversal into giving
run-time assertion failures (addressing (F) and (G))
It also issues an error within gengtype itself for a missing desc
(failure B), turning this into an error message from gengtype.
I found another potential failure mode:
(H) If you had:
class GTY((desc(%0.kind), tag(0))) foo
{
public:
int kind;
tree p;
};
class GTY((tag(1))) bar : public foo
{
public:
tree q;
};
static GTY(()) foo *dummy_foo;
and there are no explicit pointers to bar in the code, gengtype
treated it as unused, and silently omitted the case for it from
foo's marking routine.
I've updated set_gc_type_used so that it propagates usage down into
subclasses (which recurses), fixing this issue.
To do this efficiently we need to track subclasses in within gengtype,
so the patch also adds that, and uses it to eliminate an O(N^2).
Note that for error (G), if a class within the hierarchy omits a GTY
marker, gengtype doesn't parse it at all, and so doesn't parse the
inheritance information - so we can't issue a warning about this.
However, the lack of a tag will trigger a run-time assertion failure
due to hitting the default: gcc_unreachable(); in the switch.
The patch also adds a paragraph to the docs, spelling out the need
for evary class in such a hierarchy to have a GTY marker.
I believe this addresses all of the silent-lack-of-field-traversal
issues, converting them to gengtype errors or runtime assertions.
It also adds a handler for (E), turning this from a failure to
compile bogus C to a specific error in gengtype.
I'm bootstrapping/regtesting now.
OK for trunk if that passes?
I don't have the power to approve this patch, but I hope it will get
accepted.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
