Re: Has FSF stopped processing copyright paperwork

Le 26 avr. 2021 à 23:31, Gerald Pfeifer mailto:ger...@pfeifer.com>> a écrit : I got notified of copyright assignments related to GCC by copyright-cl...@fsf.org on April 5th, April 8th, April 22nd (two instances) and April 26th (today). So the process seems to be

Re: Has FSF stopped processing copyright paperwork

Hi, (Please note that this mail is *NOT* about the recent discussions about the relationship with the FSF. AFAIK to date FSF copyright assignment is still required to contribute to gcc and this request is solely about how to have one signed.) Few weeks later, I would like to know if anyone on the

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

Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit : > > Please make sure to get features intended for GCC 10 finished > and reviewed before the end of stage 1. > Hi, I understand my question comes very (most likely too) late, but are there any plans to switch the default C++ dialect to -std=g

Re: [EXT] Re: Can LTO minor version be updated in backward compatible way ?

On Thu, 18 Jul 2019, Florian Weimer wrote: > > Right and stable LTO bytecode really isn't on the radar at this time. > > Maybe it's better to serialize the non-preprocessed source code instead. > It would need some (hash-based?) deduplication. For #include > directives, the hash of the file would

Can LTO minor version be updated in backward compatible way ?

Hi, SuSE (Martin) annonunced today that fromw now on SuSE Tumbleweed will ship with LTO-built packages by default [1]. That's a good news, however I have a question wrt how you expect to support LTO in the future. I have been enabling it in my company for just few selected components and I run in

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

in those additional headers are private. Thus, you should define two sets of headers files (public and private ones), plus body c files, and import only public header files from public header files. Do you have any plan on starting integrating it to the trunk (or at least on an new branch on the official gcc repository) soon, like suggested by Richard ? I might help setting up the configure/makefile and later writing some wrappers. (although i don't have write permission). Cheers Romain Geissler

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

LTGCC_VERSION)" | $(GAWK) '{split($$3,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@ to this: echo "$(MELTGCC_VERSION)" | $(GAWK) '{split($$1,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@ (notice $$3 becomes $$1) Romain Geissler

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

Le 31 mars 2012 à 13:55, Romain Geissler a écrit : > > Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit : > >> I am surprised of your patch which indeed contains gcc/melt-build.tpl: >> >> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] >> -

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit : > I am surprised of your patch which indeed contains gcc/melt-build.tpl: > > -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] > -GAWK ?= gawk > +## AWK is needed [+ (. (tpl-file-line))+] > +AWK ?= awk > > > I really need GNU awk (

Re: Proposed plugin API for GCC

d prefered a C++ API). Cheers Romain Geissler

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit : > On Sat, 31 Mar 2012 02:22:43 +0200 > Romain Geissler wrote: > >> >> I tried to build the latest melt-branch (not the generated tarball) on a mac. >> Here is the few change required to allow the build (not

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

Moreover, this kind of test should be in a configure file, not in a source file. On a mac, _POSIX_C_SOURCE is not defined by default, and defining it lead to errors while building other parts of GCC. Romain Geissler melt-mac-build.Changelog Description: Binary data melt-mac-build.diff Description: Binary data

Re: Proposed plugin API for GCC

Le 30 mars 2012 à 15:48, Ian Lance Taylor a écrit : > Romain Geissler writes: > >> Using structs with some sets of function pointers may break compatibility >> between minor release. > > Yes, but fortunately we have a good understanding of how not to do that. >

Re: Proposed plugin API for GCC

t changing the old ones). Anyway, you're suggestion to group functions in common names, that's just C++ motto. May the eventual plugin API in C++ (independently from internals being C++ or not) ? Romain Geissler

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit : > On Thu, 29 Mar 2012 22:45:27 +0200 > Romain Geissler wrote: > >> MELTGCC_BUILD_WITH_CXX = $(shell grep -q >> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ >> `$(MELTGCC) -print

Re: [GCC-MELT-386] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

#x27;+' operator in your regexp. Also, it would be welcome to allow any blank chars to separate words, not any the space char (\t for example). Thus, i changed space ' ' by [[:space:]] (tested with GNU grep). MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) Anyway, as i already told you, you don't look for gengtype and gtype.state at the right place. Romain Geissler

Re: gcc extensibility

Le 29 mars 2012 à 21:01, Gabriel Dos Reis a écrit : > On Thu, Mar 29, 2012 at 12:39 PM, Romain Geissler > wrote: >> Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit : >> >>> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler >>> wrote: >>>> Hi

Re: gcc extensibility

. I roughly see plugins as a solution in the middle : you keep the whole gcc in a single block, but still you can perform minor task on your own by dlopening a plugin.so of your own rather than breaking gcc in a proper structued libgcc. Of course, a beautiful defined and structed libgcc would be welcome, but

Re: gcc extensibility

Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit : > On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler > wrote: >> Hi >> >> Le 29 mars 2012 à 14:34, Niels Möller a écrit : >> >>> 1. I imagine the plugin API ought to stay in plain C, right? >> >

Re: gcc extensibility

e in C++, for the same reasons it was decided to slowly move the internals to C++. Romain Geissler

Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++)

need for all version. Cheers Romain Geissler

Re: gengtype installation in trunk?

Hi, I don't understand, you supported my patch when i contributed it, which performs exactly what you want ! Gengtype and gtype.state get installed in the trunk for more than a month ! Romain. Le 24 sept. 2011 à 17:09, Basile Starynkevitch a écrit : > Hello All, > > As you probably know, ge

Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

Le 22 sept. 2011 à 16:18, Diego Novillo a écrit : > On 11-09-22 09:40 , Dodji Seketeli wrote: >> Romain Geissler a écrit: >> >>> I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++. >>> >>> The followings does not currently trigger

Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE

Hi, I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++. The followings does not currently trigger the PLUGIN_FINISH_DECL (or not in all cases), but should them ? - function parameters (in the function prototype) - definition (with a function body) of a top-level function (whil

Re: [PLUGIN] dlopen and RTLD_NOW

when program is directly linked > against it, with LD_BIND_NOW=1 or not. > >        Jakub > Thanks, it works fine. I didn't know about weak symbols. Romain Geissler

[PLUGIN] dlopen and RTLD_NOW

use justified ? Romain Geissler

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

Le 8 août 2011 à 20:49, Ian Lance Taylor a écrit : > > However, since we currently permit plugins to call anything in gcc, I > think the answer is going to have to be that plugins which do that > should be compiled with C++. Ok, i'll move to C++ then, until a dedicated C plugin API comes out. >

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

gled symbols (and so built with g++). What's the new GCC policy about that ? Do plugins have to be built using g++ only, or does the plugin developer have the choice to use both gcc and g++ according to it's need (at the cost of adding extern "C" {…} in almost every headers to forbid mangling) ? Romain Geissler

Re: Romain Geissler copyright assignment

how do i proceed to get one ? Regards Romain Geissler.

Re: hash signature of cc1 etc....?

s are nothing more than shared object build with a bunch of header files. So you just need to correctly write header dependencies in your plugin Makefile and it will just work as needed. Anyway, GCC plugin API brings you plugin_default_version_check which performs checks on revision number + build con

Re: How to add a new pass?

t's only useful for debugging purpose. This number will be used in the tree-dump filename (if you ask for a particular dump), that's why *prefixed passes (that can't be dumped) use -1 as static pass number. So i'll advice you to check where your pass really is inserted otherwise (maybe with dump_passes()) Romain Geissler

[Melt] Runfile Mode and rest of compilation

ile -fmet-arg=trace.melt. But it seems that the rest of compilation is canceled, as the resulting test.o object file do not have the "main" symbol whereas test.c defines a main function. Is this behavior expected ? Romain Geissler

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

Le 14 juil. 2011 à 16:08, Pierre Vittet a écrit : > I have seen you were correcting things in the MELT build system, that is not > easy I think Is it working ? Take me (and Basile) informed. From my > system, it looks melt-sources directory is not correctly installed, moreover, > I am not s

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

Le 14 juil. 2011 à 12:42, Romain Geissler a écrit : > const char *fullname = lang_hooks.decl_printable_name (my_dec, 2l); Of course there is no 'l' at the end of the line. Just read: const char *fullname = lang_hooks.decl_printable_name (my_decl, 2);

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

e of any declaration (ie like my_namespace::my_class::my_value or int::my_namespace::my_class::my_method (int, const char *)) just do: const char *fullname = lang_hooks.decl_printable_name (my_dec, 2l); (with #include "langhooks.h") That's exactly what current_function_name() does with current_function_decl. Romain Geissler