This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR63307] Fix generation of new declarations in random order
- From: Jeff Law <law at redhat dot com>
- To: "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, "GCC Patches (gcc-patches at gcc dot gnu dot org)" <gcc-patches at gcc dot gnu dot org>
- Cc: "Jakub Jelinek (jakub at redhat dot com)" <jakub at redhat dot com>
- Date: Fri, 10 Oct 2014 13:41:46 -0600
- Subject: Re: [PATCH, PR63307] Fix generation of new declarations in random order
- Authentication-results: sourceware.org; auth=none
- References: <0EFAB2BDD0F67E4FB6CCC8B9F87D756969BB3310 at IRSMSX101 dot ger dot corp dot intel dot com>
On 10/04/14 05:54, Zamyatin, Igor wrote:
Hi!
The following patch does fix random order for new decls generation during Cilk_spawn generation.
As Jakub suggested in the PR first we deal with vectors, then sort them and only then perform necessary generation of new decls.
Bootstrapped and regtested on trunk/4.9.
For trunk I couldn't check with COMPARE_DEBUG since building fails somewhere else.
For 4.9 COMPARE_DEBUG building is ok.
Is it ok for trunk and backport into 4.9?
c-family/Changelog:
2014-10-03 Igor Zamyatin <igor.zamyatin@intel.com>
PR c/63307
* cilk.c: Include vec.h.
(struct cilk_decls): New structure.
(wrapper_parm_cb): Split this function to...
(fill_decls_vec): ...this...
(create_parm_list): ...and this.
(compare_decls): New function.
(for_local_cb): Remove.
(wrapper_local_cb): Ditto.
(build_wrapper_type): For now first traverse and fill vector of
declarations then sort it and then deal with sorted vector.
(cilk_outline): Ditto.
(declare_one_free_variable): Ditto.
OK for the trunk. No sure if Jakub wants to backport to 4.9 or not.
That'd be his call.
+
+static int
+compare_decls (const void *a, const void *b)
+{
+ const struct cilk_decls* t1 = (const struct cilk_decls*) a;
+ const struct cilk_decls* t2 = (const struct cilk_decls*) b;
+
+ return DECL_UID (t1->key) > DECL_UID (t2->key);
We really prefer fully specified sorts. For a qsort callback, this
doesn't look fully specified.
With that fixed, this should be OK.
jeff