Re: whereis asm_nodes? how to migrate it for GCC v6.x?
Hi Segher, Thanks for your kind response! 在 2017年07月05日 18:52, Segher Boessenkool 写道: Hi Leslie, On Wed, Jul 05, 2017 at 05:36:15PM +0800, Leslie Zhai wrote: There was extern GTY(()) struct asm_node *asm_nodes; for GCC v4.x, but how to migrate it for v6.x? there is no asm_nodes deprecated log in ChangeLog-201X nor git log cgraph.h... please give me some hint, thanks a lot! symtab->first_asm_symbol ? yes! works for me :) such as: for (pa = symtab->first_asm_symbol (); pa; pa = pa->next)... Segher -- Regards, Leslie Zhai https://reviews.llvm.org/p/xiangzhai/
Re: RFC: Add ___tls_get_addr
On 05/07/17 17:18, H.J. Lu wrote: > On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote: >> On 05/07/17 16:38, H.J. Lu wrote: >>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by >>> GCCs older than GCC 4.9.4: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 >>> >>> continue to work even if vector instructions are used by functions called >>> from __tls_get_addr, which assumes 16-byte stack alignment as specified >>> by x86-64 psABI. >>> >>> We are considering to add an alternative interface, ___tls_get_addr, to >>> glibc, which doesn't realign stack. Compilers, which properly align stack >>> for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr, >>> if ___tls_get_addr is available. >>> >>> Any comments? >>> >>> >> >> what happens when new compiler generating the new symbol >> is used with old glibc? >> > > Compiler shouldn't do that. > i don't see how can the compiler not do that e.g. somebody building an old glibc from source with new compiler, then runs the tests, all tls tests would fail because the compiler generated the new symbol. or users interposing __tls_get_addr (asan) need to update their code. or there are cases when libraries built against one libc is used with another (e.g. musl can mostly use a libstdc++ compiled against glibc on x86_64) i think introducing new libc<->compiler abi should be done conservatively when it is really necessary and from Rich's mail it seems there is no need for new abi here.
Re: Getting spurious FAILS in testsuite?
On 08.06.2017 23:33, Andrew Pinski wrote: On Thu, Jun 8, 2017 at 2:25 PM, Jeff Law wrote: On 06/08/2017 04:24 AM, Christophe Lyon wrote: On 8 June 2017 at 11:57, Georg-Johann Lay wrote: On 05.06.2017 18:25, Jim Wilson wrote: On 06/01/2017 05:59 AM, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTFLAGS='ubsan.exp' comes up with spurious fails. This was discussed before, and the suspicion was that it was a linux kernel bug. There were multiple kernel fixes pointed at, it wasn't clear which one was required to fix it. I have Ubuntu 16.04 LTS on my laptop, and I see the problem. I can't run the ubsan testsuites with -j factor greater than one and get reproducible results. There may also be other ways to trigger the problem. See for instance the thread https://gcc.gnu.org/ml/gcc/2016-07/msg00117.html The first message in the thread from Andrew Pinski mentions that the log output is corrupted from apparent buffer overflow. Jim I have "Ubuntu 16.04.2 LTS". Asking this at DejaGNU's, I got the following pointer: https://lists.gnu.org/archive/html/dejagnu/2016-03/msg00034.html AFAIU there is a problem separating stdout and stderr? Be careful, I'm not a dejagnu maintainer/developer :-) I just meant to say I had "similar" problems, but according to this thread, I'm not the only one :( There was most definitely a linux kernel bug that affected the behavior of "expect" used by dejagnu in the past. THe gcc.gnu.org reference to a message from Pinski is the right one -- it identifies the problematical change in the kernel that mucked up expect's behavior. In the thread you'll find a reference to: https://bugzilla.kernel.org/show_bug.cgi?id=96311 This has long since been fixed. BUt I have no idea what version of hte kernel is in Ubuntu and whether or not it is subject to this problem. I think 4.10 or 4.11 has the full fix. There was still some bugs even in 4.8 (which was the one included with Ubuntu 1604). I only say this is because I have a 4.8 kernel which sees the problem but a 4.11 kernel does not. The behavior I see with a non fixed kernel is that the guailty tests will not run at all. With the fixed kernel, it will run. Thanks, Andrew FYI, I am on 4.11.2 now and the spurious FAILs persist. $ uname -a Linux 4.11.2-041102-generic #201705201036 SMP ... x86_64 GNU/Linux $ lsb_release -dicr Distributor ID: Ubuntu Description:Ubuntu 16.04.2 LTS Release:16.04 Codename: xenial Johann
How to migrate TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts for GCC v6.x?
Hi GCC developers,
As ChangeLog-2014 mentioned, tree-pass.h (TODO_verify_ssa,
TODO_verify_flow, TODO_verify_stmts...): Remove.
When I am trying to migrate:
static struct rtl_opt_pass pass_rtl_emit_function = { {
RTL_PASS, "rtl_emit_function", /* name */
#if (GCC_MINOR >= 8)
OPTGROUP_NONE, /* optinfo_flags */
#endif
NULL, /* gate */
rtl_emit_function, /* execute */
NULL, /* sub */
NULL, /* next */
0, /* static_pass_number */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts
} };
to GCC v6.x
const pass_data pass_data_rtl_emit_function = {
RTL_PASS, /* type */
"rtl_emit_function", /* name */
OPTGROUP_NONE, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
0, /* todo_flags_start */
TODO_df_finish,/* todo_flags_finish */
};
class pass_rtl_emit_function : public rtl_opt_pass {
public:
pass_rtl_emit_function(gcc::context *ctxt)
: rtl_opt_pass(pass_data_rtl_emit_function, ctxt) {}
virtual unsigned int execute(function *) { return rtl_emit_function(); }
};
I have no idea how to choose the todo_flags_XXX, please give me some
hint, thanks a lot!
--
Regards,
Leslie Zhai https://reviews.llvm.org/p/xiangzhai/
Re: RFC: Add ___tls_get_addr
On Thu, Jul 6, 2017 at 1:06 AM, Szabolcs Nagy wrote: > On 05/07/17 17:18, H.J. Lu wrote: >> On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote: >>> On 05/07/17 16:38, H.J. Lu wrote: On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by GCCs older than GCC 4.9.4: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 continue to work even if vector instructions are used by functions called from __tls_get_addr, which assumes 16-byte stack alignment as specified by x86-64 psABI. We are considering to add an alternative interface, ___tls_get_addr, to glibc, which doesn't realign stack. Compilers, which properly align stack for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr, if ___tls_get_addr is available. Any comments? >>> >>> what happens when new compiler generating the new symbol >>> is used with old glibc? >>> >> >> Compiler shouldn't do that. >> > > i don't see how can the compiler not do that > > e.g. somebody building an old glibc from > source with new compiler, then runs the tests, > all tls tests would fail because the compiler > generated the new symbol. Using ___tls_get_addr should be controlled by an option selected by compiler build time as well as run-time. > or users interposing __tls_get_addr (asan) need > to update their code. Yes. That is true. > or there are cases when libraries built against > one libc is used with another (e.g. musl can > mostly use a libstdc++ compiled against glibc > on x86_64) This happens every time when a new version of a function is added to glibc. musl has to deal with it. > i think introducing new libc<->compiler abi This is no different from adding a new version of a function to glibc. > should be done conservatively when it is really > necessary and from Rich's mail it seems there > is no need for new abi here. > See: https://sourceware.org/ml/libc-alpha/2017-07/msg00086.html -- H.J.
Re: RFC: Add ___tls_get_addr
On 07/05/2017 12:02 PM, Rich Felker wrote: > Note that if you make the change and have gcc generate calls to the > new ___tls_get_addr symbol, it's going to be problematic for people > trying to link to older glibc versions that don't have it. This is a normal problem to have, and there are solutions for this. As you ask, the real question is: Is it necessary? -- Cheers, Carlos.
Re: RFC: Add ___tls_get_addr
On Thu, Jul 06, 2017 at 04:06:55AM -0700, H.J. Lu wrote: > > or there are cases when libraries built against > > one libc is used with another (e.g. musl can > > mostly use a libstdc++ compiled against glibc > > on x86_64) > > This happens every time when a new version of a function > is added to glibc. musl has to deal with it. That's not a problem I really care about, but again, I don't think this change is necessary or beneficial. > > i think introducing new libc<->compiler abi > > This is no different from adding a new version of a function > to glibc. > > > should be done conservatively when it is really > > necessary and from Rich's mail it seems there > > is no need for new abi here. > > > > See: > > https://sourceware.org/ml/libc-alpha/2017-07/msg00086.html I don't see how the necessity follows from there. Rich
gcc-7-20170706 is now available
Snapshot gcc-7-20170706 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170706/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 250043 You'll find: gcc-7-20170706.tar.xzComplete GCC SHA256=01703ccc8296a726a854fedb33e8b28a30dedadc03b8c14e1b85f7114efd54e8 SHA1=e7c5e4eb62f19a0ce1eb5013c8e1538db612d332 Diffs from 7-20170629 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: How to migrate TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts for GCC v6.x?
在 2017年07月06日 17:02, Leslie Zhai 写道:
Hi GCC developers,
As ChangeLog-2014 mentioned, tree-pass.h (TODO_verify_ssa,
TODO_verify_flow, TODO_verify_stmts...): Remove.
When I am trying to migrate:
static struct rtl_opt_pass pass_rtl_emit_function = { {
RTL_PASS, "rtl_emit_function", /* name */
#if (GCC_MINOR >= 8)
OPTGROUP_NONE, /* optinfo_flags */
#endif
NULL, /* gate */
rtl_emit_function, /* execute */
NULL, /* sub */
NULL, /* next */
0, /* static_pass_number */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts
} };
to GCC v6.x
const pass_data pass_data_rtl_emit_function = {
RTL_PASS, /* type */
"rtl_emit_function", /* name */
OPTGROUP_NONE, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
0, /* todo_flags_start */
TODO_df_finish,/* todo_flags_finish */
Just 0
because const pass_data pass_data_dse migrate the todo_flags as
https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-dse.c#L818
};
class pass_rtl_emit_function : public rtl_opt_pass {
public:
pass_rtl_emit_function(gcc::context *ctxt)
: rtl_opt_pass(pass_data_rtl_emit_function, ctxt) {}
virtual unsigned int execute(function *) { return
rtl_emit_function(); }
};
I have no idea how to choose the todo_flags_XXX, please give me some
hint, thanks a lot!
--
Regards,
Leslie Zhai https://reviews.llvm.org/p/xiangzhai/
