Re: Android native build of GCC
On 11/02/15 00:41, Cyd Haselton wrote: > >> >> I'd rather leave it on-list for future reference. The best thing >> would be for libfakechroot to be linked against libdl: that way, when >> dlopen() was called the link would be correctly satisfied. If that >> isn't possible (if dlopen() doesn't work or is incompatible) then >> libfakechroot shouldn't export the symbol for dlopen(). > > After experimenting with several builds of the fakechroot library I > can't see how this would be possible. Even when libdl is linked in, > hiding dlopen guarantees that the resulting library doesn't > intercept dlopen calls, which breaks the fakechroot environment and > removing the fakechroot dlopen code also ensures that dlopen calls > aren't intercepted. I don't get it. If libdl is linked in, why would you hide dlopen() ? Andrew.
Re: Android native build of GCC
On February 11, 2015 2:36:59 AM CST, Andrew Haley wrote: >On 11/02/15 00:41, Cyd Haselton wrote: >> >>> >>> I'd rather leave it on-list for future reference. The best thing >>> would be for libfakechroot to be linked against libdl: that way, >when >>> dlopen() was called the link would be correctly satisfied. If that >>> isn't possible (if dlopen() doesn't work or is incompatible) then >>> libfakechroot shouldn't export the symbol for dlopen(). >> >> After experimenting with several builds of the fakechroot library I >> can't see how this would be possible. Even when libdl is linked in, >> hiding dlopen guarantees that the resulting library doesn't >> intercept dlopen calls, which breaks the fakechroot environment and >> removing the fakechroot dlopen code also ensures that dlopen calls >> aren't intercepted. > >I don't get it. If libdl is linked in, why would you hide dlopen() ? > >Andrew. libdl was linked in the original, buggy libfakechroot...the one that exported dlopen(). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
On 02/11/2015 10:00 AM, Cyd Haselton wrote: > > > On February 11, 2015 2:36:59 AM CST, Andrew Haley wrote: >> On 11/02/15 00:41, Cyd Haselton wrote: >>> I'd rather leave it on-list for future reference. The best thing would be for libfakechroot to be linked against libdl: that way, >> when dlopen() was called the link would be correctly satisfied. If that isn't possible (if dlopen() doesn't work or is incompatible) then libfakechroot shouldn't export the symbol for dlopen(). >>> >>> After experimenting with several builds of the fakechroot library I >>> can't see how this would be possible. Even when libdl is linked in, >>> hiding dlopen guarantees that the resulting library doesn't >>> intercept dlopen calls, which breaks the fakechroot environment and >>> removing the fakechroot dlopen code also ensures that dlopen calls >>> aren't intercepted. >> >> I don't get it. If libdl is linked in, why would you hide dlopen() ? > > libdl was linked in the original, buggy libfakechroot...the one that exported > dlopen(). But if it was linked in, where did the dlopen() link error come from? It should have succeeded because dlopen() should have been found in libdl. I still don't get it. Andrew.
Re: Android native build of GCC
On Wed, Feb 11, 2015 at 5:27 AM, Andrew Haley wrote: > On 02/11/2015 10:00 AM, Cyd Haselton wrote: >> >> >> On February 11, 2015 2:36:59 AM CST, Andrew Haley wrote: >>> On 11/02/15 00:41, Cyd Haselton wrote: > > I'd rather leave it on-list for future reference. The best thing > would be for libfakechroot to be linked against libdl: that way, >>> when > dlopen() was called the link would be correctly satisfied. If that > isn't possible (if dlopen() doesn't work or is incompatible) then > libfakechroot shouldn't export the symbol for dlopen(). After experimenting with several builds of the fakechroot library I can't see how this would be possible. Even when libdl is linked in, hiding dlopen guarantees that the resulting library doesn't intercept dlopen calls, which breaks the fakechroot environment and removing the fakechroot dlopen code also ensures that dlopen calls aren't intercepted. >>> >>> I don't get it. If libdl is linked in, why would you hide dlopen() ? >> >> libdl was linked in the original, buggy libfakechroot...the one that >> exported dlopen(). > > But if it was linked in, where did the dlopen() link error come from? It > should have succeeded because dlopen() should have been found in libdl. > I still don't get it. > Neither do I...hence my confusion. Even more so because neither this nor Linux are systems I usually work with. I have an idea of what may be the problem, but it's just a guess, given my rudimentary understanding of how the linker, shared and dynamic libraries work. The original libfakechroot was cross-compiled to link against the system libc, and not the system libdlhence libdl not being found. The experiments I did with libfakechroot linked the sysroot libdl and not the system libdl, therefore all dlopen() calls went straight to the system libdl, bypassing the fakechroot environment. Does that sound plausible? Cyd
[ANN] ODB C++ ORM 2.4.0 Released
Hi, I am pleased to announce the release of ODB 2.4.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB is implemented as a GCC plugin and uses GCC's frontend for C++ parsing. Major new features in this release: * The plugin implementation is GCC 5-ready. * Support for bulk operations in Oracle and SQL Server. Bulk operations can be used to persist, update, or erase a range of objects using a single database statement execution which often translates to a significantly better performance. * Ability to join and load one or more complete objects instead of, or in addition to, a subset of their data members with a single SELECT statement execution (object loading views). * Support for specifying object and table join types in views (LEFT, RIGHT, FULL, INNER, or CROSS). * Support for calling MySQL and SQL Server stored procedures. * Support for defining persistent objects as instantiations of C++ class templates. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2015/02/11/odb-2-4-0-released/ For the complete list of new features in this version see the official release announcement: http://codesynthesis.com/pipermail/odb-announcements/2015/41.html ODB is written in portable C++ (both C++98/03 and C++11 are supported) and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64/ARM), Windows (x86/x86-64), Mac OS X (x86/x86_64), and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-5.x, MS Visual C++ 2005, 2008, 2010, 2012, and 2013, Sun Studio 12u2, and Clang 3.x. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides optional profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris
Re: Postpone expanding va_arg until pass_stdarg
On 10-02-15 17:57, Michael Matz wrote: Hi, On Tue, 10 Feb 2015, Tom de Vries wrote: I've added two modifications to gimplify_modify_expr: - the WITH_SIZE_EXPR in which the CALL_TREE is wrapped, is dropped after gimplification, but we need the size expression at expansion in pass_stdarg. So I added the size expression as argument to the internal function. [ And at pass_stdarg::execute, we wrap the result of gimplify_va_arg_internal in a WITH_SIZE_EXPR before generating the assign to the lhs ] Hmm, why do you need the WITH_SIZE_EXPR actually? For variable-sized types returned by va_arg? Yep. - we detect after gimplify_arg (&ap) whether it created a copy ap.1 of ap, rather than use ap itself, and if so, we copy the value back from ap.1 to ap after va_arg. My idea was to not generate temporaries and hence copies for non-scalar types, but rather construct the "result" of va_arg directly into the original LHS (that would then also trivially solve the problem of nno-copyable types). The copy mentioned here is of ap, not of the result of va_arg. In gimplify_modify_expr, we're already doing effort not to generate temporaries for call lhs, see comment: ... To prevent gimplify_expr from trying to create a new temporary for foo's LHS, we tell it that it should only gimplify until it reaches the CALL_EXPR. On return from gimplify_expr, the newly created GIMPLE_CALL will be the last statement in *PRE_P and all we need to do here is set 'a' to be its LHS ... I'm not really sure yet why std_gimplify_va_arg_expr has a part commented out. Michael, can you comment? I think I did that because of SSA form. The old sequence calculated vatmp = valist; vatmp = vatmp + boundary-1 vatmp = vatmp & -boundary (where the local variable in that function 'valist_tmp' is the tree VAR_DECL 'vatmp') and then continue to use valist_tmp. When in SSA form the gimplifier will rewrite this into: vatmp_1 = valist; vatmp_2 = vatmp_1 + boundary-1 vatmp_3 = vatmp_2 & -boundary but the local valist_tmp variable will continue to be the VAR_DECL, not the vatmp_3 ssa name. Basically whenever one gimplifies a MODIFY_EXPR while in SSA form it's suspicious. So the new code simply build the expression: ((valist + bound-1) & -bound) gimplifies that into an rvalue (most probably an SSA name) and uses that to go on generating code by making valist_tmp be that returned rvalue. I think you'll find that removing that code will make the SSA verifier scream or generate invalid code with -m32 when that hook is used. Thanks for the detailed explanation. I'm not sure I understand the problem well enough, so I'll try to trigger it and investigate. Thanks, - Tom
Re: Postpone expanding va_arg until pass_stdarg
On 10-02-15 14:46, Richard Biener wrote: This patch is a way to achieve that gimplification doesn't call the actual >gimplify_expr langhook, and it fixes the failure. But I'm guessing that's >not the proper way to fix this. More like Index: gcc/tree.c === --- gcc/tree.c (revision 220578) +++ gcc/tree.c (working copy) @@ -5815,6 +5815,7 @@ free_lang_data (void) still be used indirectly via the get_alias_set langhook. */ lang_hooks.dwarf_name = lhd_dwarf_name; lang_hooks.decl_printable_name = gimple_decl_printable_name; + lang_hooks.gimplify_expr = lhd_gimplify_expr; /* We do not want the default decl_assembler_name implementation, rather if we have fixed everything we want a wrapper around it asserting that all non-local symbols already got their assembler That worked, and allowed me to do a bootstrap on x86_64 for all languages and regtest for unix/ and unix/-m32 without any issues (other than scan-dump-tree failures for stdarg, since the va_list_gpr/fpr_size optimization is switched off). That leaves just teaching the va_list_gpr/fpr_size optimization to recognize ifn_va_arg. Thanks, - Tom
gcc-4.9-20150211 is now available
Snapshot gcc-4.9-20150211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 220631 You'll find: gcc-4.9-20150211.tar.bz2 Complete GCC MD5=782d7b37e66690ea34bf4b975c25173b SHA1=962fed8c457fe5327b67a75f81d71045fb2d9adb Diffs from 4.9-20150204 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
GCC 5.0 and OpenMP 4.0 accelerator : Adapteva/Parallella board
Hi, I would like to find out if this is the correct forum to ask/discuss about GCC 5's OpenMP 4.0 implementation, in particular the new accelerator feature which from what I understand, allows the compute to be offloaded to external GPU/accelerator. I have a Parallella board (ARM dual core) which has an Adapteva chip (16 cores) and I would like to build a GCC 5 version for it. I recall that the Adapteva is a supported CPU with GCC. If this is not the forum, please direct me to the correct forum to continue. Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows
