Re: push_rounding vs memcpy vs stack_pointer_delta
DJ Delorie writes: > The m32c-elf with -mcpu=m32c has a word-aligned stack and uses pushes > for arguments (i.e. not accumulate_outgoing_args). In this test case, > one of the arguments is memcpy'd into place, and an assert fails: m68k has a similar configuration, and I've never seen this assertion fail. But it doesn't pass arguments in registers. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
New GCC mirror
Hi, we set up a new GCC mirror for the community. URL: http://mirrors.concertpass.com/gcc/ Organization/Contact: ConcertPass (ad...@mirrors.concertpass.com) Location: United States, Michigan Please, add it to your mirror list page. Thanks
record_component_aliases will not record the bases with no field declaration
Hi, record_component_aliases only handle fields of a record type, and would ignore the base of this record if the base has no field declaration. Is this a bug or on purpose? Thanks. -- Lin Zuojian
Re: record_component_aliases will not record the bases with no field declaration
On Fri, Aug 29, 2014 at 11:50 AM, lin zuojian wrote: > Hi, > record_component_aliases only handle fields of a record type, and > would ignore the base of this record if the base has no field > declaration. > Is this a bug or on purpose? It's on purpose as you can't "access" that base and thus the base is meaningless for alias analysis. Richard. > Thanks. > -- > Lin Zuojian
Re: record_component_aliases will not record the bases with no field declaration
Thanks Richard. --- Lin Zuojian
Re: selective linking of floating point support for *printf / *scanf
On 08/29/2014 12:04 AM, Thomas Preud'homme wrote: >> So are you saying you are stuck with printf_float? > > It's not printf_float but _printf_float. I was told double underscore is only > necessary with old toolchain as they might add a leading underscore. So > _printf_float should not pose any kind of problem. Yes, it does. The namespace reserved for the implementation is _[_A-Z]. The namespace _[a-z] is still available for the user. Which means the user can declare their own _printf_float, and WE (as the implementation) MUST NOT INTERFERE with it. Since WE are the implementation, we should use the namespace reserved for us, namely __printf_float. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
GCC plugins & GGC & explicit gcc_free
Hello All, [[I know that this is a sensitive issue, and I also know that I am in the minority believing that a garbage collection is useful inside the GCC compiler]] How should plugins deal with data that is explicitly gcc_free-d outside of ggc_collect? In particular, plugins are apparently allowed to have their own GTY-ed data (which is very good, I certainly don't want that feature to disappear). I'm particularly thinking of "static analysis" (or "observing") plugins, which would take advantage of the GCC compiler to add some extra measures and analysis but which won't change anything observable in the GCC internal representations (e.g. plugins that won't add or remove any Gimple inside existing functions, for instance). I believe that such "observing" plugins should certainly be allowed to register a pass which would put some data (e.g. tree-s or basic_block-s) inside some GTY-ed variable and examine it much later, perhaps even at PLUGIN_FINISH time (and certainly at PLUGIN_FINISH_UNIT time). This would make sense if such a plugin would like to make some detailed statistics, serialize *some* of the Gimple or Tree-s in a database, etc. However, such a plugin could crash, because at several occasions ggc_free is *forcibly* called *outside* of the garbage collector - and there is no mechanism (finalization, plugin hooks) to communicate that deletion to the plugin. So such a plugin will keep a *stale* data referenced by its GTY-ed roots. I have a concrete example within my MELT branch -currently close to GCC 4.9- & plugin (see http://gcc-melt.org/ if you never heard of MELT). the justcountipa pass I have in file gcc/melt/xtramelt-ana-simple.melt near lines 840 and following. It stores some global MELT data singleton of CLASS_JUSTCOUNTIPA_DATA in the MELT pass, and that data stays available, so is never freed by the GGC. Unfortunately, that data contains (very indirectly) some tree-s and edge-s which have been *explicitly* ggc_free-d, e.g. by execute_todo calling indirectly cleanup_tree_cfg calling indirectly free_edge. If you are interested here is the offending backtrace (with a watchpoint triggered when ggc_free is overwriting, by enable-checking code, some edge still kept in MELT global data thru a GTY-ed variable) 0 in memset of ../sysdeps/x86_64/memset.S:65 1 in ggc_free of /usr/src/Lang/basile-melt-gcc/gcc/ggc-page.c:1544 2 in free_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:92 3 in remove_edge_raw of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:351 4 in remove_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:418 5 in remove_phi_nodes_and_edges_for_unreachable_block of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:1934 6 in remove_bb of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:2016 7 in delete_basic_block of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:565 8 in remove_forwarder_block of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:529 9 in cleanup_tree_cfg_bb of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:633 10 in cleanup_tree_cfg_1 of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:675 11 in cleanup_tree_cfg_noloop of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:731 12 in cleanup_tree_cfg of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:786 13 in execute_function_todo of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1811 14 in do_per_function of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1574 15 in execute_todo of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1887 16 in execute_one_pass of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2247 17 in execute_pass_list of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2286 18 in execute_pass_list of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2287 19 in do_per_function_toporder of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1630 20 in execute_ipa_pass_list of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2617 21 in ipa_passes of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2043 22 in compile of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2174 23 in finalize_compilation_unit of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2329 If I continue the above execution my MELT plugin crashes (in GGC marking routines) because the stale edge has been free-d and reused later. Of course, a dirty workaround is for me to clear manually that data before it could be seen by the GGC marking garbage collector. And such a workaround is working. But I really find it shameful. Unfortunately, the data which are manually freed outside of ggc_collect (so which should perhaps not be kept without care in GTY-ed variables inside plugins) is not exactly documented. >From my biased point of view, I would much prefer if ggc_free was called *only* from ggc_collect. Sadly, I believe that few GCC people would agree with that. Or we could have ggc_free called only from ggc_collect, and add a new ggc_becomes_freeable routine (and every call to ggc_free outside of ggc_collect would be replaced by a call to ggc_becomes_freeable which for exam
Re: selective linking of floating point support for *printf / *scanf
On 08/29/2014 09:51 AM, Grissiom wrote: >> Yes, it does. The namespace reserved for the implementation is _[_A-Z]. >> The namespace _[a-z] is still available for the user. Which means the >> user can declare their own _printf_float, and WE (as the implementation) >> MUST NOT INTERFERE with it. Since WE are the implementation, we should >> use the namespace reserved for us, namely __printf_float. >> >> > You mean _[_a-z] (lower case) is the namespace reserved for implementation, > right? No, I spoke correctly. The namespace reserved for the implementation is all double underscores, and all single underscore followed by a capital. Single underscore followed by a lower case is NOT reserved for the implementation, and is therefore free for use by the user, and therefore the implementation must not interfere with the user's use of that namespace. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: selective linking of floating point support for *printf / *scanf
On 08/29/2014 10:03 AM, Eric Blake wrote: > On 08/29/2014 09:51 AM, Grissiom wrote: >>> Yes, it does. The namespace reserved for the implementation is _[_A-Z]. >>> The namespace _[a-z] is still available for the user. Which means the >>> user can declare their own _printf_float, and WE (as the implementation) >>> MUST NOT INTERFERE with it. Since WE are the implementation, we should >>> use the namespace reserved for us, namely __printf_float. >>> >>> >> You mean _[_a-z] (lower case) is the namespace reserved for implementation, >> right? > > No, I spoke correctly. The namespace reserved for the implementation is > all double underscores, and all single underscore followed by a capital. > Single underscore followed by a lower case is NOT reserved for the > implementation, and is therefore free for use by the user, and therefore > the implementation must not interfere with the user's use of that namespace. Quoting POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm > The following identifiers are reserved regardless of the inclusion of headers: > > 1. > With the exception of identifiers beginning with the prefix _POSIX_, all > identifiers that begin with an and either an uppercase letter or > another are always reserved for any use by the implementation. > 2. > All identifiers that begin with an are always reserved for > use as identifiers with file scope in both the ordinary identifier and tag > name spaces. >... Of course, that list feels a bit too restrictive in light of existing standardized uses of underscore followed by capital. such as _Bool and _Exit in C99; and C11 has introduced even more things like _Noreturn. But the REASON that C has been able to extend the language and add more keywords beginning with underscore-capital is precisely because those names were reserved for the implementation, not the user, so it can't break any user code. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: GCC plugins & GGC & explicit gcc_free
On August 29, 2014 5:29:43 PM CEST, Basile Starynkevitch wrote: >Hello All, > >[[I know that this is a sensitive issue, and I also know that I am in >the minority believing that a garbage collection is useful inside the >GCC compiler]] > >How should plugins deal with data that is explicitly gcc_free-d outside >of ggc_collect? > >In particular, plugins are apparently allowed to have their own GTY-ed >data (which is very good, I certainly don't want that feature to >disappear). I'm particularly thinking of "static analysis" (or >"observing") plugins, which would take advantage of the GCC compiler to >add some extra measures and analysis but which won't change anything >observable in the GCC internal representations (e.g. plugins that won't >add or remove any Gimple inside existing functions, for instance). > >I believe that such "observing" plugins should certainly be allowed to >register a pass which would put some data (e.g. tree-s or >basic_block-s) >inside some GTY-ed variable and examine it much later, perhaps even at >PLUGIN_FINISH time (and certainly at PLUGIN_FINISH_UNIT time). This >would make sense if such a plugin would like to make some detailed >statistics, serialize *some* of the Gimple or Tree-s in a database, >etc. > >However, such a plugin could crash, because at several occasions >ggc_free is *forcibly* called *outside* of the garbage collector - and >there is no mechanism (finalization, plugin hooks) to communicate that >deletion to the plugin. So such a plugin will keep a *stale* data >referenced by its GTY-ed roots. > >I have a concrete example within my MELT branch -currently close to GCC >4.9- & plugin (see http://gcc-melt.org/ if you never heard of MELT). >the justcountipa pass I have in file gcc/melt/xtramelt-ana-simple.melt >near lines 840 and following. It stores some global MELT data singleton >of CLASS_JUSTCOUNTIPA_DATA in the MELT pass, and that data stays >available, so is never freed by the GGC. Unfortunately, that data >contains (very indirectly) some tree-s and edge-s which have been >*explicitly* ggc_free-d, e.g. by execute_todo calling indirectly >cleanup_tree_cfg calling indirectly free_edge. > >If you are interested here is the offending backtrace (with a >watchpoint >triggered when ggc_free is overwriting, by enable-checking code, some >edge still kept in MELT global data thru a GTY-ed variable) > >0 in memset of ../sysdeps/x86_64/memset.S:65 >1 in ggc_free of /usr/src/Lang/basile-melt-gcc/gcc/ggc-page.c:1544 >2 in free_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:92 >3 in remove_edge_raw of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:351 >4 in remove_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:418 >5 in remove_phi_nodes_and_edges_for_unreachable_block >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:1934 >6 in remove_bb of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:2016 >7 in delete_basic_block >of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:565 >8 in remove_forwarder_block >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:529 >9 in cleanup_tree_cfg_bb >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:633 >10 in cleanup_tree_cfg_1 >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:675 >11 in cleanup_tree_cfg_noloop >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:731 >12 in cleanup_tree_cfg >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:786 >13 in execute_function_todo >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1811 >14 in do_per_function of >/usr/src/Lang/basile-melt-gcc/gcc/passes.c:1574 >15 in execute_todo of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1887 >16 in execute_one_pass >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2247 >17 in execute_pass_list >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2286 >18 in execute_pass_list >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2287 >19 in do_per_function_toporder >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1630 >20 in execute_ipa_pass_list >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2617 >21 in ipa_passes of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2043 >22 in compile of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2174 >23 in finalize_compilation_unit >of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2329 > >If I continue the above execution my MELT plugin crashes (in GGC >marking >routines) because the stale edge has been free-d and reused later. > >Of course, a dirty workaround is for me to clear manually that data >before it could be seen by the GGC marking garbage collector. And such >a >workaround is working. But I really find it shameful. > >Unfortunately, the data which are manually freed outside of ggc_collect >(so which should perhaps not be kept without care in GTY-ed variables >inside plugins) is not exactly documented. > >From my biased point of view, I would much prefer if ggc_free was >called >*only* from ggc_collect. Sadly, I believe that few GCC people would >agree with that. Or we could have ggc_free called only from >ggc
Re: GCC plugins & GGC & explicit gcc_free
On Fri, 2014-08-29 at 19:58 +0200, Richard Biener wrote:
>
> You are in the same situation as any other pass would be. Don't hang on
> things that can get stale.
>
> There is no point in keeping a pointer to a deleted edge.
Yes there is. The use case is to make some statistics on edges and to
print these at FINISH_UNIT time.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Enable EBX for x86 in 32bits PIC code
On 08/28/14 12:58, Uros Bizjak wrote: On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich wrote: On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix ebx register, use speudo register for GOT base address and let allocator do the rest. This should be similar to how clang and icc work with GOT base address. I've been working for some time on such patch and now want to share my results. (define_insn "*pushtf" [(set (match_operand:TF 0 "push_operand" "=<,<") - (match_operand:TF 1 "general_no_elim_operand" "x,*roF"))] + (match_operand:TF 1 "nonimmediate_no_elim_operand" "x,*roF"))] Can you please explain the reason for this change (and a couple of similar changes to push patterns) ? I'd recommend dropping them from the WIP postings. jeff
Re: Enable EBX for x86 in 32bits PIC code
On 08/28/14 07:01, Uros Bizjak wrote: On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich wrote: Hi, On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in 32bit PIC mode. It was decided that the best approach would be to not fix ebx register, use speudo register for GOT base address and let allocator do the rest. This should be similar to how clang and icc work with GOT base address. I've been working for some time on such patch and now want to share my results. +#define PIC_OFFSET_TABLE_REGNUM \ + ((TARGET_64BIT && (ix86_cmodel == CM_SMALL_PIC \ + || TARGET_PECOFF)) \ + || !flag_pic ? INVALID_REGNUM \ + : X86_TUNE_RELAX_PIC_REG ? (pic_offset_table_rtx ? INVALID_REGNUM \ + : REAL_PIC_OFFSET_TABLE_REGNUM) \ + : reload_completed ? REGNO (pic_offset_table_rtx) \ : REAL_PIC_OFFSET_TABLE_REGNUM) I'd like to avoid X86_TUNE_RELAX_PIC_REG and always treat EBX as an allocatable register. This way, we can avoid all mess with implicit xchgs in atomic_compare_and_swap_doubleword. Also, having allocatable EBX would allow us to introduce __builtin_cpuid builtin and cleanup cpiud.h. I think for the initial WIP patch it was fine. However I think we all agree that we want EBX as an allocatable register without any special conditions. So I'd recommend pulling this out of the WIP patches as well. Jeff
Re: Enable EBX for x86 in 32bits PIC code
On 08/28/14 02:37, Ilya Enkovich wrote:
2014-08-28 1:39 GMT+04:00 Jeff Law :
On 08/26/14 15:42, Ilya Enkovich wrote:
diff --git a/gcc/calls.c b/gcc/calls.c
index 4285ec1..85dae6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals
ATTRIBUTE_UNUSED,
call_expr_arg_iterator iter;
tree arg;
+if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
+ {
+ gcc_assert (pic_offset_table_rtx);
+ args[j].tree_value = make_tree (ptr_type_node,
+ pic_offset_table_rtx);
+ j--;
+ }
+
if (struct_value_addr_value)
{
args[j].tree_value = struct_value_addr_value;
So why do you need this? Can't this be handled in the call/call_value
expanders or what about attaching the use to CALL_INSN_FUNCTION_USAGE from
inside ix86_expand_call? Basically I'm not seeing the need for another
target hook here. I think that would significantly simply the patch as
well.
GOT base address become an additional implicit arg with EBX relaxed
and I handled it as all other args. I can move EBX initialization into
ix86_expand_call. Would still need some hint from target to init
pic_offset_table_rtx with proper value in the beginning of function
expand.
It doesn't really need to be an argument in the traditional sense and
adding it just complicates things with a target implementation detail as
far as I can see.
I think you'll find that if you have the call pattern emit a copy from
pic_offset_table_rtx into EBX and attach of use of EBX to the call then
most of the code you've written to add the implicit argument just
disappears.
jeff
Re: GCC plugins & GGC & explicit gcc_free
On Fri, Aug 29, 2014 at 07:58:14PM +0200, Richard Biener wrote: > On August 29, 2014 5:29:43 PM CEST, Basile Starynkevitch > wrote: > >Hello All, > > > >[[I know that this is a sensitive issue, and I also know that I am in > >the minority believing that a garbage collection is useful inside the > >GCC compiler]] > > > >How should plugins deal with data that is explicitly gcc_free-d outside > >of ggc_collect? > > > >In particular, plugins are apparently allowed to have their own GTY-ed > >data (which is very good, I certainly don't want that feature to > >disappear). I'm particularly thinking of "static analysis" (or > >"observing") plugins, which would take advantage of the GCC compiler to > >add some extra measures and analysis but which won't change anything > >observable in the GCC internal representations (e.g. plugins that won't > >add or remove any Gimple inside existing functions, for instance). > > > >I believe that such "observing" plugins should certainly be allowed to > >register a pass which would put some data (e.g. tree-s or > >basic_block-s) > >inside some GTY-ed variable and examine it much later, perhaps even at > >PLUGIN_FINISH time (and certainly at PLUGIN_FINISH_UNIT time). This > >would make sense if such a plugin would like to make some detailed > >statistics, serialize *some* of the Gimple or Tree-s in a database, > >etc. > > > >However, such a plugin could crash, because at several occasions > >ggc_free is *forcibly* called *outside* of the garbage collector - and > >there is no mechanism (finalization, plugin hooks) to communicate that > >deletion to the plugin. So such a plugin will keep a *stale* data > >referenced by its GTY-ed roots. > > > >I have a concrete example within my MELT branch -currently close to GCC > >4.9- & plugin (see http://gcc-melt.org/ if you never heard of MELT). > >the justcountipa pass I have in file gcc/melt/xtramelt-ana-simple.melt > >near lines 840 and following. It stores some global MELT data singleton > >of CLASS_JUSTCOUNTIPA_DATA in the MELT pass, and that data stays > >available, so is never freed by the GGC. Unfortunately, that data > >contains (very indirectly) some tree-s and edge-s which have been > >*explicitly* ggc_free-d, e.g. by execute_todo calling indirectly > >cleanup_tree_cfg calling indirectly free_edge. > > > >If you are interested here is the offending backtrace (with a > >watchpoint > >triggered when ggc_free is overwriting, by enable-checking code, some > >edge still kept in MELT global data thru a GTY-ed variable) > > > >0 in memset of ../sysdeps/x86_64/memset.S:65 > >1 in ggc_free of /usr/src/Lang/basile-melt-gcc/gcc/ggc-page.c:1544 > >2 in free_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:92 > >3 in remove_edge_raw of /usr/src/Lang/basile-melt-gcc/gcc/cfg.c:351 > >4 in remove_edge of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:418 > >5 in remove_phi_nodes_and_edges_for_unreachable_block > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:1934 > >6 in remove_bb of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfg.c:2016 > >7 in delete_basic_block > >of /usr/src/Lang/basile-melt-gcc/gcc/cfghooks.c:565 > >8 in remove_forwarder_block > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:529 > >9 in cleanup_tree_cfg_bb > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:633 > >10 in cleanup_tree_cfg_1 > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:675 > >11 in cleanup_tree_cfg_noloop > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:731 > >12 in cleanup_tree_cfg > >of /usr/src/Lang/basile-melt-gcc/gcc/tree-cfgcleanup.c:786 > >13 in execute_function_todo > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1811 > >14 in do_per_function of > >/usr/src/Lang/basile-melt-gcc/gcc/passes.c:1574 > >15 in execute_todo of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1887 > >16 in execute_one_pass > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2247 > >17 in execute_pass_list > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2286 > >18 in execute_pass_list > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2287 > >19 in do_per_function_toporder > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:1630 > >20 in execute_ipa_pass_list > >of /usr/src/Lang/basile-melt-gcc/gcc/passes.c:2617 > >21 in ipa_passes of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2043 > >22 in compile of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2174 > >23 in finalize_compilation_unit > >of /usr/src/Lang/basile-melt-gcc/gcc/cgraphunit.c:2329 > > > >If I continue the above execution my MELT plugin crashes (in GGC > >marking > >routines) because the stale edge has been free-d and reused later. > > > >Of course, a dirty workaround is for me to clear manually that data > >before it could be seen by the GGC marking garbage collector. And such > >a > >workaround is working. But I really find it shameful. > > > >Unfortunately, the data which are manually freed outside of ggc_collect > >(so which should perhaps not be kept without care in GTY-ed v
Re: GCC plugins & GGC & explicit gcc_free
On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders wrote: >> Of course we should make things more explicit here and move all data >> structures out of GC that are explicitly freed. Work in that direction is >> welcome. The CFG is in GC memory because it indirectly refers to trees (the >> single most reason why things are in GC space, fixable nowadays with custom >> GC marker routines) > > I thought it was also because of pch? That used to be true, but not anymore (ever since unit-at-a-time became the default). The CFG is only constructed after the front end is done writing a PCH. The CFG could be put back into arenas or pools, if custom markers are written and could be somehow called on objects that don't live in GGC space themselves. Right now, our marking is really just a dumb walk-everything approach, but it should be possible to use the hierarchy we have, starting from symtab and marking top-down - teaching custom markers to walk the CFG of a function body but to not mark basic blocks, edges, and whatever else makes up the CFG. > I'm hoping we'll soon be at a point where everything uses the overload > based gc scheme currently used for user gc which should hopefully make > custom marking easier, but pch will still be a big pain, and in fact is > by far the worst part of implementing marking functions. The first step really should be to simplify the marking for PCH itself: Annotate structures for which we know they should never end up in a PCH, and teach gengtype to just not write out marker functions for them (just abort instead). Things that should never be seen in a PCH: CFG basic blocks and edges, symtab nodes, GIMPLE, RTL (I think), ... If you teach gengtype to punt on those types, transitioning to custom marking should be far easier. Ciao! Steven
Re: GCC plugins & GGC & explicit gcc_free
On Sat, Aug 30, 2014 at 12:54:16AM +0200, Steven Bosscher wrote: > On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders > wrote: > > >> Of course we should make things more explicit here and move all data > >> structures out of GC that are explicitly freed. Work in that direction is > >> welcome. The CFG is in GC memory because it indirectly refers to trees > >> (the single most reason why things are in GC space, fixable nowadays with > >> custom GC marker routines) > > > > I thought it was also because of pch? > > That used to be true, but not anymore (ever since unit-at-a-time > became the default). The CFG is only constructed after the front end > is done writing a PCH. I was thinking about http://gcc.gnu.org/ml/gcc/2014-07/msg00298.html according to that we can't move symtab_node and friends, but maybe we can move edges and basic blocks. Trev > The CFG could be put back into arenas or pools, if custom markers are > written and could be somehow called on objects that don't live in GGC > space themselves. Right now, our marking is really just a dumb > walk-everything approach, but it should be possible to use the > hierarchy we have, starting from symtab and marking top-down - > teaching custom markers to walk the CFG of a function body but to not > mark basic blocks, edges, and whatever else makes up the CFG. > > > > I'm hoping we'll soon be at a point where everything uses the overload > > based gc scheme currently used for user gc which should hopefully make > > custom marking easier, but pch will still be a big pain, and in fact is > > by far the worst part of implementing marking functions. > > The first step really should be to simplify the marking for PCH > itself: Annotate structures for which we know they should never end up > in a PCH, and teach gengtype to just not write out marker functions > for them (just abort instead). Things that should never be seen in a > PCH: CFG basic blocks and edges, symtab nodes, GIMPLE, RTL (I think), > ... If you teach gengtype to punt on those types, transitioning to > custom marking should be far easier. > > Ciao! > Steven
RE: selective linking of floating point support for *printf / *scanf
> From: Grissiom [mailto:chaos.pro...@gmail.com] > Sent: Friday, August 29, 2014 11:51 PM > > Yes, it does. The namespace reserved for the implementation is _[_A-Z]. > The namespace _[a-z] is still available for the user. Which means the > user can declare their own _printf_float, and WE (as the implementation) > MUST NOT INTERFERE with it. Since WE are the implementation, we should > use the namespace reserved for us, namely __printf_float. Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause states: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." Next clause express how single underscore not followed by a capital letter is reserved: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces." Since here we are talking about linkage, _printf_float is not safe according to the standard. Sigh. Ok I need to think about it. Thank you all for pointing out the problem with the current scheme. Best regards, Thomas
RE: selective linking of floating point support for *printf / *scanf
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > Of Thomas Preud'homme > Sent: Saturday, August 30, 2014 12:27 PM > Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause > states: > > "All identifiers that begin with an underscore and either an uppercase letter > or > another underscore are always reserved for any use." > > Next clause express how single underscore not followed by a capital letter > is > reserved: > > "All identifiers that begin with an underscore are always reserved for use as > identifiers > with file scope in both the ordinary and tag name spaces." > > Since here we are talking about linkage, _printf_float is not safe according > to the > standard. Sorry for restating what Eric Blake already said, I didn't see his message at first as it was (surprisingly) classified as spam. Best regards, Thomas
