clang vs free software
Helmut Eller : > > If nobody bothers with even > > considering the question, it would appear that it is not all that > > important... > > Maybe nobody bothers because using clang is easier than to fight with > FSF policies. <> It is never a good idea to exclude political and social ramifications from the software design and use decisions... It so happens that over the long hall, the free software ends up being technologically superiormost often. But this is besides the point. <> Clearly this is a complete break off now of the BSD community but there is another half of this story, because the platform that most of us have gotten compfortable with over the last decade is now being flanked on several levels for which the compiler keychain is maybe just the last straw. I think it might be necessary in the near future to just break with the current "Linux" platform altogether, and maybe rebuild a BSD based system with the FSF tool kit and start there as a new base. <> It is just another compiler in order to make non-free software. It is the free software platform as a whole that is being seriously strained. <> Uh huh. You know what, it won't matter with UEFI and if systemd continues to absorb the entire GNU toolkit. It is not just BSD that will no longer have GNU/Roots The GNU/Linux is almost dead in its own right. <> [QUOTE]"I'm an engineer. I choose the best tool for the job, politics be damned." You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one." [/QUOTE] Right now, it is hard to find a distribution that functions, and they have less GNU tools on them every day. << As I've said before, I don't personally care who wins; either tool will serve my needs. I would prefer to see both flourish and compete with each other. But that's not where things are heading unless GCC ups its game.>> That won't even scratch the surface. Consider this... UEFI puts a operating system between you and your hardware. Without a secure boot, it is a security flaw...outright. WITH a secure boot, it is no better than the Apple Appstore because you can't change the binaries and expect them to be signable. And then you have systemd, which is eating every peice of GNUtoolkit it can find, and then some. In fact, systemd is nearly a shelless operating system, and it certain doesn't need GCC, or the GNU toolkit. In fact, it smothers the need for a toolkit since all the hackable parts are being rounded up. It's stated goal is to make all distriubutions identical Boy, this is a F$$$thyylking innovatoin if I ever saw one. Who needs a compiler when you have a locked down Operating System that you have to beg for a TCP Socket from. And then there is android, and Chromium, the browser that spies on you (and YES the free version DOES spy on you), and Firefox feels like it is dieing... Java and MYSQL were eaten by Oracle This is not a bright time in the world. I feel earnestly bad for the youngsters growing up in this, and that includes my children and grandchildren. There is a need for some bold action. But fixing GCC for some marginal improvements at best... it needs to be done. It always needs to be done. But we need something else as well. Ruben -- -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Merging the ./config directory between GCC and Binutils
Hi! Yesterday, an outstanding fix was committed to the GCC repo for a not correctly regenerated file. Now that that's fixed, I'll merge the two ./config directories (unfortunately, both the Binutils and the GCC tree gained commits that weren't synced) and come up with a patch. I hope that there won't be too many commits in the mean time, to produce a lot of fuzz :) Once that's in sync again, I'll keep a script running to check that and report missing commits in any of the trees. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, träume ich. the second : signature.asc Description: Digital signature
Re: gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag.
Hi,
this is patch I commited to mainline
2014-11-22 Jan Hubicka
* ipa.c (symbol_table::remove_unreachable_nodes): Mark all inline clones
as having abstract origin used.
* ipa-inline-transform.c (can_remove_node_now_p_1): Drop abstract
origin check.
(clone_inlined_nodes): Copy abstract originflag.
* ipa-cgraph.c (working): Use get_create to get abstract origin node.
Index: ipa.c
===
--- ipa.c (revision 217890)
+++ ipa.c (working copy)
@@ -360,9 +360,18 @@ symbol_table::remove_unreachable_nodes (
&& DECL_ABSTRACT_ORIGIN (node->decl))
{
struct cgraph_node *origin_node
- = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node->decl));
- origin_node->used_as_abstract_origin = true;
- enqueue_node (origin_node, &first, &reachable);
+ = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node->decl));
+ if (origin_node && !origin_node->used_as_abstract_origin)
+ {
+ origin_node->used_as_abstract_origin = true;
+ gcc_assert (!origin_node->prev_sibling_clone);
+ gcc_assert (!origin_node->next_sibling_clone);
+ for (cgraph_node *n = origin_node->clones; n;
+ n = n->next_sibling_clone)
+ if (n->decl == DECL_ABSTRACT_ORIGIN (node->decl))
+ n->used_as_abstract_origin = true;
+ enqueue_node (origin_node, &first, &reachable);
+ }
}
/* If any symbol in a comdat group is reachable, force
all externally visible symbols in the same comdat
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c (revision 217890)
+++ ipa-inline-transform.c (working copy)
@@ -100,7 +100,6 @@ can_remove_node_now_p_1 (struct cgraph_n
the callgraph so references can point to it. */
return (!node->address_taken
&& !node->has_aliases_p ()
- && !node->used_as_abstract_origin
&& node->can_remove_if_no_direct_calls_p ()
/* Inlining might enable more devirtualizing, so we want to remove
those only after all devirtualizable virtual calls are processed.
@@ -218,6 +217,7 @@ clone_inlined_nodes (struct cgraph_edge
update_original, vNULL, true,
inlining_into,
NULL);
+ n->used_as_abstract_origin = e->callee->used_as_abstract_origin;
e->redirect_callee (n);
}
}
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 217890)
+++ lto-cgraph.c(working copy)
@@ -877,7 +877,8 @@ compute_ltrans_boundary (lto_symtab_enco
if (DECL_ABSTRACT_ORIGIN (node->decl))
{
struct cgraph_node *origin_node
- = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node->decl));
+ = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node->decl));
+ origin_node->used_as_abstract_origin = true;
add_node_to (encoder, origin_node, true);
}
}
Re: gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag.
Thanks for the fix. Is it ok to backport it to gcc-4_9?
Thanks,
Wei.
On Sat, Nov 22, 2014 at 1:08 PM, Jan Hubicka wrote:
> Hi,
> this is patch I commited to mainline
>
> 2014-11-22 Jan Hubicka
>
> * ipa.c (symbol_table::remove_unreachable_nodes): Mark all inline
> clones
> as having abstract origin used.
> * ipa-inline-transform.c (can_remove_node_now_p_1): Drop abstract
> origin check.
> (clone_inlined_nodes): Copy abstract originflag.
> * ipa-cgraph.c (working): Use get_create to get abstract origin node.
> Index: ipa.c
> ===
> --- ipa.c (revision 217890)
> +++ ipa.c (working copy)
> @@ -360,9 +360,18 @@ symbol_table::remove_unreachable_nodes (
> && DECL_ABSTRACT_ORIGIN (node->decl))
> {
> struct cgraph_node *origin_node
> - = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node->decl));
> - origin_node->used_as_abstract_origin = true;
> - enqueue_node (origin_node, &first, &reachable);
> + = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node->decl));
> + if (origin_node && !origin_node->used_as_abstract_origin)
> + {
> + origin_node->used_as_abstract_origin = true;
> + gcc_assert (!origin_node->prev_sibling_clone);
> + gcc_assert (!origin_node->next_sibling_clone);
> + for (cgraph_node *n = origin_node->clones; n;
> + n = n->next_sibling_clone)
> + if (n->decl == DECL_ABSTRACT_ORIGIN (node->decl))
> + n->used_as_abstract_origin = true;
> + enqueue_node (origin_node, &first, &reachable);
> + }
> }
> /* If any symbol in a comdat group is reachable, force
> all externally visible symbols in the same comdat
> Index: ipa-inline-transform.c
> ===
> --- ipa-inline-transform.c (revision 217890)
> +++ ipa-inline-transform.c (working copy)
> @@ -100,7 +100,6 @@ can_remove_node_now_p_1 (struct cgraph_n
> the callgraph so references can point to it. */
>return (!node->address_taken
> && !node->has_aliases_p ()
> - && !node->used_as_abstract_origin
> && node->can_remove_if_no_direct_calls_p ()
> /* Inlining might enable more devirtualizing, so we want to remove
> those only after all devirtualizable virtual calls are processed.
> @@ -218,6 +217,7 @@ clone_inlined_nodes (struct cgraph_edge
>update_original, vNULL, true,
>inlining_into,
>NULL);
> + n->used_as_abstract_origin = e->callee->used_as_abstract_origin;
> e->redirect_callee (n);
> }
> }
> Index: lto-cgraph.c
> ===
> --- lto-cgraph.c(revision 217890)
> +++ lto-cgraph.c(working copy)
> @@ -877,7 +877,8 @@ compute_ltrans_boundary (lto_symtab_enco
>if (DECL_ABSTRACT_ORIGIN (node->decl))
> {
> struct cgraph_node *origin_node
> - = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node->decl));
> + = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node->decl));
> + origin_node->used_as_abstract_origin = true;
> add_node_to (encoder, origin_node, true);
> }
> }
Re: gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag.
> Thanks for the fix. Is it ok to backport it to gcc-4_9? Yes, it is OK assuming that there are no problems with the patch for a week. (it ought to be safe) Honza
