getrlimit compatibility issues
Hi,
with LTO early debug and LTO bootstrap I now get
/usr/include/sys/resource.h:51:12: error: type of ‘getrlimit’ does not
match original declaration [-Werror=lto-type-mismatch]
extern int getrlimit (__rlimit_resource_t __resource,
^
/usr/include/sys/resource.h:51:12: note: type mismatch in parameter 1
extern int getrlimit (__rlimit_resource_t __resource,
^
/usr/include/sys/resource.h:43:13: note: type ‘__rlimit_resource_t’ should
match type ‘__rlimit_resource_t’
typedef int __rlimit_resource_t;
^
/usr/include/sys/resource.h:39:32: note: the incompatible type is defined
here
typedef enum __rlimit_resource __rlimit_resource_t;
^
/usr/include/sys/resource.h:51:12: note: ‘getrlimit’ was previously
declared here
extern int getrlimit (__rlimit_resource_t __resource,
^
the issue is wrt C / C++ context where glibc headers have
#if defined __USE_GNU && !defined __cplusplus
typedef enum __rlimit_resource __rlimit_resource_t;
typedef enum __rusage_who __rusage_who_t;
typedef enum __priority_which __priority_which_t;
#else
typedef int __rlimit_resource_t;
typedef int __rusage_who_t;
typedef int __priority_which_t;
#endif
and the enum is unsigned:
(gdb) p debug_tree (0x7fffe7aa2690)
constant 32>
unit size constant 4>
which currently isn't compatible with signed int.
I'm now double-checking unpatched LTO bootstrap but I guess I somehow
just keep streaming some more decls or get different partitioning.
I know in the end you'd like to make int and unsigned int compatible
for this check(?) but I wonder whether glibc really desired to make
the enum unsigned... it's just
/* Kinds of resource limit. */
enum __rlimit_resource
{
/* Per-process CPU limit, in seconds. */
RLIMIT_CPU = 0,
...
#define RLIMIT_NLIMITS __RLIMIT_NLIMITS
#define RLIM_NLIMITS __RLIM_NLIMITS
};
one reason I get here might be also that somehow the locations of
the decls are not in-system-header. This would be an artifact of
LTO location streaming I guess.
Oh, seems unpatched LTO bootstrap is broken (possibly by me).
Richard.
Re: getrlimit compatibility issues
On Mon, 31 Aug 2015, Richard Biener wrote:
>
> Hi,
>
> with LTO early debug and LTO bootstrap I now get
>
> /usr/include/sys/resource.h:51:12: error: type of ‘getrlimit’ does not
> match original declaration [-Werror=lto-type-mismatch]
> extern int getrlimit (__rlimit_resource_t __resource,
> ^
> /usr/include/sys/resource.h:51:12: note: type mismatch in parameter 1
> extern int getrlimit (__rlimit_resource_t __resource,
> ^
> /usr/include/sys/resource.h:43:13: note: type ‘__rlimit_resource_t’ should
> match type ‘__rlimit_resource_t’
> typedef int __rlimit_resource_t;
> ^
> /usr/include/sys/resource.h:39:32: note: the incompatible type is defined
> here
> typedef enum __rlimit_resource __rlimit_resource_t;
> ^
> /usr/include/sys/resource.h:51:12: note: ‘getrlimit’ was previously
> declared here
> extern int getrlimit (__rlimit_resource_t __resource,
> ^
>
> the issue is wrt C / C++ context where glibc headers have
>
> #if defined __USE_GNU && !defined __cplusplus
> typedef enum __rlimit_resource __rlimit_resource_t;
> typedef enum __rusage_who __rusage_who_t;
> typedef enum __priority_which __priority_which_t;
> #else
> typedef int __rlimit_resource_t;
> typedef int __rusage_who_t;
> typedef int __priority_which_t;
> #endif
>
> and the enum is unsigned:
>
> (gdb) p debug_tree (0x7fffe7aa2690)
> size bitsizetype> constant 32>
> unit size 0x762851f8 sizetype> constant 4>
>
> which currently isn't compatible with signed int.
>
> I'm now double-checking unpatched LTO bootstrap but I guess I somehow
> just keep streaming some more decls or get different partitioning.
>
> I know in the end you'd like to make int and unsigned int compatible
> for this check(?) but I wonder whether glibc really desired to make
> the enum unsigned... it's just
>
> /* Kinds of resource limit. */
> enum __rlimit_resource
> {
> /* Per-process CPU limit, in seconds. */
> RLIMIT_CPU = 0,
> ...
> #define RLIMIT_NLIMITS __RLIMIT_NLIMITS
> #define RLIM_NLIMITS __RLIM_NLIMITS
> };
>
> one reason I get here might be also that somehow the locations of
> the decls are not in-system-header. This would be an artifact of
> LTO location streaming I guess.
>
> Oh, seems unpatched LTO bootstrap is broken (possibly by me).
The following two patches are necessary to bring back LTO bootstrap
to the point where it runs LTRANS stage for cc1 and friends. It
then still breaks (I have to analyze why).
The first patch avoids replacing strrchr with __builtin_strrchr
in the abstract origin for IPA transforms. The second patch avoids
the above getrlimit errors by properly streaming whether locations
are in system headers or not.
I'm currently separately bootstrapping and testing them on
x86_64-unknown-linux-gnu.
2015-08-31 Richard Biener
lto/
* lto-symtab.c (lto_symtab_prevailing_decl): Remove redundant
test, do not replace a non-builtin with a builtin.
* lto.c (compare_tree_sccs_1): Do not merge things we stream
as builtins vs. non-builtins.
Index: gcc/lto/lto-symtab.c
===
--- gcc/lto/lto-symtab.c(revision 227293)
+++ gcc/lto/lto-symtab.c(working copy)
@@ -798,11 +798,6 @@ lto_symtab_prevailing_decl (tree decl)
if (TREE_CODE (decl) == FUNCTION_DECL && DECL_ABSTRACT_P (decl))
return decl;
- /* Likewise builtins are their own prevailing decl. This preserves
- non-builtin vs. builtin uses from compile-time. */
- if (TREE_CODE (decl) == FUNCTION_DECL && DECL_BUILT_IN (decl))
-return decl;
-
/* Ensure DECL_ASSEMBLER_NAME will not set assembler name. */
gcc_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
@@ -811,5 +806,9 @@ lto_symtab_prevailing_decl (tree decl)
if (!ret)
return decl;
+ /* Do not replace a non-builtin with a builtin. */
+ if (is_builtin_fn (ret->decl))
+return decl;
+
return ret->decl;
}
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 227293)
+++ gcc/lto/lto.c (working copy)
@@ -1054,8 +1054,10 @@ compare_tree_sccs_1 (tree t1, tree t2, t
return false;
- /* We don't want to compare locations, so there is nothing do compare
- for TS_DECL_MINIMAL. */
+ /* We want to compare locations up to the point where it makes
+ a difference for streaming - thus whether the decl is builtin or not. */
+ if (CODE_CONTAINS_STRUCT (code, TS_DECL_MINIMAL))
+compare_values (streamer_handle_as_builtin_p);
if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
{
2015-08-31 Richard Biener
* lto-streamer.h (lto_location_cache::cached_location::sysp): Add.
(lto_location_cache::current_sysp): Likewise.
(output_block::current_sysp): Likewise.
* lto-streamer-in.c (lto_location_cache::cmp_loc): Compare sysp.
(lto_location
Re: Predictive commoning leads to register to register moves through memory.
On Fri, Aug 28, 2015 at 5:48 PM, Jeff Law wrote: > On 08/28/2015 09:43 AM, Simon Dardis wrote: > >> Following Jeff's advice[1] to extract more information from GCC, I've >> narrowed the cause down to the predictive commoning pass inserting >> the load in a loop header style basic block. However, the next pass >> in GCC, tree-cunroll promptly removes the loop and joins the loop >> header to the body of the (non)loop. More oddly, disabling >> conditional store elimination pass or the dominator optimizations >> pass or disabling of jump-threading with --param >> max-jump-thread-duplication-stmts=0 nets the above assembly code. Any >> ideas on an approach for this issue? > > I'd probably start by looking at the .optimized tree dump in both cases to > understand the difference, then (most liklely) tracing that through the RTL > optimizers into the register allocator. It's the known issue of LIM (here the one after pcom and complete unrolling of the inner loop) being too aggressive with store-motion. Here the comptete array is replaced with registers for the outer loop. Were 'poly' a local variable we'd have optimized it away completely. : _8 = 1.0e+0 / pretmp_42; _12 = _8 * _8; poly[1] = _12; : # prephitmp_30 = PHI <_12(6), _36(9)> # T_lsm.8_22 = PHI <_8(6), pretmp_42(9)> poly_I_lsm0.10_38 = MEM[(double *)&poly + 8B]; _2 = prephitmp_30 * poly_I_lsm0.10_38; _54 = _2 * poly_I_lsm0.10_38; _67 = poly_I_lsm0.10_38 * _54; _80 = poly_I_lsm0.10_38 * _67; _93 = poly_I_lsm0.10_38 * _80; _106 = poly_I_lsm0.10_38 * _93; _19 = poly_I_lsm0.10_38 * _106; count_23 = count_28 + 1; if (count_23 != iterations_6(D)) goto ; else goto ; : poly[2] = _2; poly[3] = _54; poly[4] = _67; poly[5] = _80; poly[6] = _93; poly[7] = _106; poly[8] = _19; i1 = 9; T = T_lsm.8_22; note that DOM misses to CSE poly[1] (a known defect), but heh, doing that would only increase register pressure even more. Note the above is on x86_64. Richard. > jeff
Re: Problem with tree pass pre
On Mon, Aug 31, 2015 at 6:51 AM, shmeel gutl wrote: > When dealing with an array with known values, pre will evaluate the first > iteration of a loop over the elements. The code generator with then jump > into the loop. This is at best increasing the size of the code. It also > creates inferior code when the hardware supports zero overhead loops. The > attached code demonstrates the difference between an unknown array and a > known array. The loop size has been picked large enough for cunrolli to not > fully unroll the loop. The problem did not exist in gcc 4.8. I think you were just lucky with GCC 4.8 - the issue is present since forever. Basically it's because we treat a constant as available. So PRE might end up rotating the loop, inserting the 2nd iteration on the latch edge. Unfortunately this transform sometimes improves code-gen, it would be quite simple to disallow this kind of transform generally though. Richard. > >
Re: getrlimit compatibility issues
> @@ -811,5 +806,9 @@ lto_symtab_prevailing_decl (tree decl) >if (!ret) > return decl; > > + /* Do not replace a non-builtin with a builtin. */ > + if (is_builtin_fn (ret->decl)) > +return decl; > + Yep, this looks like a resonable direction. It will break the one declaration rule in a more wild sense than current frontends does so, because if a builtin win as a prevailing declaration, we end up with no merging at all. I wonder if we don't want to always prevail to first non-builtin variant? (and yep, i need to push out the syntatctic aliases patch which will make duplicated decls well behaved; will try to do so soonish) Honza
Re: getrlimit compatibility issues
On Mon, 31 Aug 2015, Jan Hubicka wrote:
> > @@ -811,5 +806,9 @@ lto_symtab_prevailing_decl (tree decl)
> >if (!ret)
> > return decl;
> >
> > + /* Do not replace a non-builtin with a builtin. */
> > + if (is_builtin_fn (ret->decl))
> > +return decl;
> > +
>
> Yep, this looks like a resonable direction. It will break the one declaration
> rule in a more wild sense than current frontends does so, because if a builtin
> win as a prevailing declaration, we end up with no merging at all.
> I wonder if we don't want to always prevail to first non-builtin variant?
I think we already try. But this can be tricky as seen by the following
which is needed to finally fix LTO bootstrap on trunk ...
Basically there are some function decls that do not go through
lto-symtab handling because they are not in any CUs cgraph but
only exist because they are refered to from BLOCK abstract origins
(and thus also LTRANS boundary streaming doesn't force them
into the cgraph). For example during LTO bootstrap I see
this from inlining of split functions where both split parts and
the original function are optimized away before stream-out.
We hit
static void
gen_inlined_subroutine_die (tree stmt, dw_die_ref context_die)
{
...
/* Make sure any inlined functions are known to be inlineable. */
gcc_checking_assert (DECL_ABSTRACT_P (decl)
|| cgraph_function_possibly_inlined_p (decl));
a lot without the following fixes. I suppose we _can_ merge
function decls which just differ in DECL_POSSIBLY_INLINED if
we make sure to "merge" the flag during tree merging. But
that's for a followup, below is for correctness.
We were also missing to compare DECL_ABSTRACT_ORIGIN during
tree merging (not sure if that caused any issue, I just run
into the clone abstract origin issue above and saw that).
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, I'll throw
it on regular bootstrap & test and then plan to commit it unless
you object that lto-symtab.c hunk...
Richard.
2015-08-31 Richard Biener
lto/
* lto.c (compare_tree_sccs_1): Compare DECL_ABSTRACT_ORIGIN.
* lto-symtab.c (lto_symtab_merge): Merge DECL_POSSIBLY_INLINED flag.
(lto_symtab_prevailing_decl): Do not replace a decl that didn't
participate in merging with something else.
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 227339)
+++ gcc/lto/lto.c (working copy)
@@ -1305,6 +1305,7 @@ compare_tree_sccs_1 (tree t1, tree t2, t
compare_tree_edges (DECL_SIZE (t1), DECL_SIZE (t2));
compare_tree_edges (DECL_SIZE_UNIT (t1), DECL_SIZE_UNIT (t2));
compare_tree_edges (DECL_ATTRIBUTES (t1), DECL_ATTRIBUTES (t2));
+ compare_tree_edges (DECL_ABSTRACT_ORIGIN (t1), DECL_ABSTRACT_ORIGIN
(t2));
if ((code == VAR_DECL
|| code == PARM_DECL)
&& DECL_HAS_VALUE_EXPR_P (t1))
Index: gcc/lto/lto-symtab.c
===
--- gcc/lto/lto-symtab.c(revision 227339)
+++ gcc/lto/lto-symtab.c(working copy)
@@ -312,6 +312,11 @@ lto_symtab_merge (symtab_node *prevailin
if (TREE_CODE (decl) == FUNCTION_DECL)
{
+ /* Merge decl state in both directions, we may still end up using
+the new decl. */
+ DECL_POSSIBLY_INLINED (prevailing_decl) |= DECL_POSSIBLY_INLINED (decl);
+ DECL_POSSIBLY_INLINED (decl) |= DECL_POSSIBLY_INLINED (prevailing_decl);
+
if (warn_type_compatibility_p (TREE_TYPE (prevailing_decl),
TREE_TYPE (decl)))
return false;
@@ -798,6 +803,18 @@ lto_symtab_prevailing_decl (tree decl)
if (TREE_CODE (decl) == FUNCTION_DECL && DECL_ABSTRACT_P (decl))
return decl;
+ /* When decl did not participate in symbol resolution leave it alone.
+ This can happen when we streamed the decl as abstract origin
+ from the block tree of inlining a partially inlined function.
+ If all, the split function and the original function end up
+ optimized away early we do not put the abstract origin into the
+ ltrans boundary and we'll end up ICEing in
+ dwarf2out.c:gen_inlined_subroutine_die because we eventually
+ replace a decl with DECL_POSSIBLY_INLINED set with one without. */
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ && ! cgraph_node::get (decl))
+return decl;
+
/* Ensure DECL_ASSEMBLER_NAME will not set assembler name. */
gcc_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
zlib: CHM binary file in source tree
Hello, In the zlib contrib section there is CHM binary file, that gets copied/imported into other projects embedding zlib, such GCC, GDB, etc... * https://github.com/madler/zlib/commits/master/contrib/dotzlib/DotZLib.chm * https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4d6758ff95985b4022e2a0a33b4540b39d6574a8 * https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=5ca28f792883afb409ae145666fc3662c3a3aed5 Could you please consider dropping such binary file and/or build it from sources? Thanks for considering. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
I have completed a full conversion
That's the good news. The bad news is, it took around 36 hours. This is gonna be a long epic. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: 33 unknowns left
On Wed, 26 Aug 2015, Joseph Myers wrote: kristerw = kristerw Krister Walfridsson Yes, this is my current address (the "cato@" address mentioned in some other mail is obsolete). [I have been away from GCC development for a long time, but I plan to start contributing in a few weeks -- as soon as I have managed to catch up on what has happened the last couple of years...] /Krister
GTY / gengtype question - adding a new header file
I have a question about gengtype and GTY. I was looking at adding some
code to mips.c and it occurred to me that that file was getting very
large (19873 lines). So I wanted to add a new .c file instead but that
file needed some types that were defined in mips.c and not in a header file.
Specifically it needed the MIPS specific machine_function structure that
is defined in mips.c with:
struct GTY(()) machine_function {
I think I could just move this to mips.h and things would be fine but
I didn't want to do that because mips.h is included in tm.h and is visible
to the generic GCC code. Currently machine_function is not visible to the
generic GCC code and so I wanted to put machine_function in a header file
that could only be seen/used by mips specific code. So I created
mips-private.h and added it to extra_headers in config.gcc.
The problem is that if I include mips-private.h in mips.c instead of
having the actual definition of machine_function in mips.c then my
build fails and I think it is due to how and where gengtype scans for GTY
uses.
I couldn't find an example of a platform that has a machine specific header
file that was not visible to the generic GCC code and that has GTY types
in it so I am not sure what I need to do to get gengtype to scan
mips-private.h or if this is even possible (or wise).
Steve Ellcey
sell...@imgtec.com
Re: Problem with tree pass pre
On 31-Aug-15 02:19 PM, Richard Biener wrote: On Mon, Aug 31, 2015 at 6:51 AM, shmeel gutl wrote: When dealing with an array with known values, pre will evaluate the first iteration of a loop over the elements. The code generator with then jump into the loop. This is at best increasing the size of the code. It also creates inferior code when the hardware supports zero overhead loops. The attached code demonstrates the difference between an unknown array and a known array. The loop size has been picked large enough for cunrolli to not fully unroll the loop. The problem did not exist in gcc 4.8. I think you were just lucky with GCC 4.8 - the issue is present since forever. Basically it's because we treat a constant as available. So PRE might end up rotating the loop, inserting the 2nd iteration on the latch edge. Unfortunately this transform sometimes improves code-gen, it would be quite simple to disallow this kind of transform generally though. Richard. It seems to be a bad optimization for zero overhead loops and/or software pipelining. Can it be disabled when these features are available. Shmeel
RE: Repository for the conversion machinery
Hi, Current email address for Xuepeng Guo is terry@arm.com Best regards, Thomas > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Eric S. Raymond > Sent: Thursday, August 27, 2015 10:38 PM > To: gcc@gcc.gnu.org > Subject: Repository for the conversion machinery > > I've made it available at: > > http://thyrsus.com/gitweb/?p=gcc-conversion.git > > The interesting content is gcc.map (the contributor map) and gcc.lift. > > Presently the only command in gcc.lift expunges the hooks directory. > -- > http://www.catb.org/~esr/";>Eric S. > Raymond
Re: Repository for the conversion machinery
"Eric S. Raymond" writes: > I've made it available at: > > http://thyrsus.com/gitweb/?p=gcc-conversion.git > > The interesting content is gcc.map (the contributor map) and gcc.lift. The current entry ro = Rainer Orth lists my old email address. Please use r...@cebitec.uni-bielefeld.de instead. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Action stamps
On 08/29/2015 10:58 AM, Dominique d'Humières wrote:
For Jakub or anyone else wanting a key to associate a file with a commit, they
can decide for themselves
what date format they want to use and whether to bother with the user id. I
would think that if he is only
interested in commits on the trunk (and so should use log --first-parent), the
timestamp is sufficient.
I share Jakub’s concern about having access to an increasing labeling of the
revisions. What would be the replacement of « svn update -r »?
Given git aliases:
stamp = show -s --format='%cI!%ce'
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
shs = "!f(){ git show $(git smaster $1); }; f"
slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
sco = "!f(){ git checkout $(git smaster $1); }; f"
and an action stamp 2015-08-20T20:55:15Z!jason, then
git sco 2015-08-20T20:55:15Z\!jason
will check out the (most recent) commit with that stamp. It also works
with just the timestamp.
A timestamp gives you a simple increasing (though sparse) label, though
it might not always be unique; when I locally rebase several patches I
sometimes get two or three with the same timestamp, which I expect to be
preserved if I push them upstream.
Jason
