Re: GCC_FOR_TARGET settings being overridden by toplevel Makefile
On 03/02/2011 10:00 PM, Ian Lance Taylor wrote: That does not sound like the right approach to me. Why not add the new flags to GCC_FOR_TARGET at top-level? It seems to me that GCC_FOR_TARGET should mean the same thing at all levels. I agree. Why is it incorrect to use those flags when, say, compiling libgcc? Paolo
Re: TYPE_UID(node) macro value
Hi, On Wed, 2 Mar 2011, Kyle Girard wrote: > > > Can I count on the uid for a type in a header to be the same across > > > all compilation units that use that header? > > > > ... no. > > > > Is there anyway in gcc to get a unique id for a type that would be the > same across compilation units? Such a unique id is impossible with bounded numbers (and TYPE_UID is only an int). There are more than 2^32 types. The best you can do is some hash value, and even then it depends on how you define type equality. In GCC we currently have multiple definitions of equality (pointer equality, structural equality on some members (type_hash_eq), equality based on compatibility (gimple_type_eq), equality based on compatibility ignoring incomplete submembers (gimple_canonical_type_eq), and some adhoc variants working for only a subset of types). > Or would I have to come up with my own encoding somehow? You would have to, yes. But see above, it's not totally trivial. You'll have to carefully think about when types are the same. Ciao, Michael.
RFC: [4.7] Adding CUMULATIVE_ARGS to targetm.calls.function_ok_for_sibcall?
Is it ok to extend targetm.function_ok_for_sibcall so that it passes
also a pointer to the callee's CUMULATIVE_ARGS structure?
In some situation it is quite tedious to recompute information like
which hard regs are used to pass arguments from the passed trees (call
expression resp., decl). This information in readily available in
args_so_far.
Ports like s390 or avr could avoid recomputation of information just
computed. (avr does not implement tail calls yet).
Patch lined out below (not yet patched any backends).
Technically, shall docs patch be against doc/tm.texi or doc/tm.texi.in?
Johann
--
Index: doc/tm.texi.in
===
--- doc/tm.texi.in (revision 170651)
+++ doc/tm.texi.in (working copy)
@@ -4889,7 +4889,14 @@ the function prologue. Normally, the pr
@hook TARGET_FUNCTION_OK_FOR_SIBCALL
True if it is ok to do sibling call optimization for the specified
call expression @var{exp}. @var{decl} will be the called function,
-or @code{NULL} if this is an indirect call.
+or @code{NULL} if this is an indirect call. The argument @var{cum}
+points to the @code{CUMULATIVE_ARGS} data structure of the called
+function. This hook runs just before the last call to
+@code{FUNCTION_ARG} resp. @code{FUNCTION_INCOMING_ARG} with
+@code{mode=VOIDmode}. @var{cum} serves informational purposes like,
+e.g. what hard registers are used to pass arguments to the
+callee (which might be tedious to recompute from @var{exp} or
+@var{decl} alone).
It is not uncommon for limitations of calling conventions to prevent
tail calls to functions outside the current unit of translation, or
Index: target.def
===
--- target.def (revision 170651)
+++ target.def (working copy)
@@ -1424,7 +1424,7 @@ DEFHOOK
DEFHOOK
(function_ok_for_sibcall,
"",
- bool, (tree decl, tree exp),
+ bool, (tree decl, tree exp, CUMULATIVE_ARGS *cum),
hook_bool_tree_tree_false)
/* Establish appropriate back-end context for processing the function
Index: calls.c
===
--- calls.c (revision 170651)
+++ calls.c (working copy)
@@ -2323,7 +2323,7 @@ expand_call (tree exp, rtx target, int i
#endif
/* Check whether the target is able to optimize the call
into a sibcall. */
- || !targetm.function_ok_for_sibcall (fndecl, exp)
+ || !targetm.function_ok_for_sibcall (fndecl, exp, &args_so_far)
/* Functions that do not return exactly once may not be sibcall
optimized. */
|| (flags & (ECF_RETURNS_TWICE | ECF_NORETURN))
Re: GCC_FOR_TARGET settings being overridden by toplevel Makefile
On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini wrote: > On 03/02/2011 10:00 PM, Ian Lance Taylor wrote: >> >> That does not sound like the right approach to me. Why not add the new >> flags to GCC_FOR_TARGET at top-level? It seems to me that >> GCC_FOR_TARGET should mean the same thing at all levels. > > I agree. Why is it incorrect to use those flags when, say, compiling > libgcc? They would be OK, but what puzzled me is that toplevel Makefile.in and gcc/Makefile.in have *different* definitions of GCC_FOR_TARGET. So, independently of what I'm trying to do, the definition of GCC_FOR_TARGET inside gcc/Makefile.in is always dead: Makefile.in: GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) @GCC_FOR_TARGET@ gcc/Makefile.in: GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld So, the variable will be set to different values if you run 'make' from toplevel or from gcc/ Is that by design? Thanks. Diego.
Re: RFC: [4.7] Adding CUMULATIVE_ARGS to targetm.calls.function_ok_for_sibcall?
Quoting Georg-Johann Lay : Is it ok to extend targetm.function_ok_for_sibcall so that it passes also a pointer to the callee's CUMULATIVE_ARGS structure? CUMULATIVE_ARGS is a target-dependent type, and thus every use of it in the interface of target hooks should be considered a bug. See PR46500.
Re: new libjava bootstrap failure
On 02/03/2011 21:37, Ralf Wildenhues wrote: > * Jack Howarth wrote on Wed, Mar 02, 2011 at 06:08:22PM CET: >> On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote: >>> Jack, the actual issue you're seeing might well be the result of some >>> missing dependency. With parallel build failures, it is most important >>> to see output from make, back to at least the first error that happened. >>> That can be arbitrarily far back, and in GCC it is not uncommon to have >>> it happen a few thousand lines before the end of the log. Please save >>> such logs for future reports. > >> A second repetition of the original build with --enable-build-with-cxx >> completed without errors. > > Race conditions can be very tricky to win; successful builds are never a > proof of their absence. It might only happen again in a few months, or > only under a certain system load. There really shouldn't be a race between configure-target-libjava and all-target-libjava though. It shouldn't even be possible. I suspect random glitch attack. Transient network/file io error or something like that. cheers, DaveK
Re: RFC: [4.7] Adding CUMULATIVE_ARGS to targetm.calls.function_ok_for_sibcall?
Joern Rennecke wrote: Quoting Georg-Johann Lay : Is it ok to extend targetm.function_ok_for_sibcall so that it passes also a pointer to the callee's CUMULATIVE_ARGS structure? CUMULATIVE_ARGS is a target-dependent type, and thus every use of it in the interface of target hooks should be considered a bug. See PR46500. Thanks for pointing me to that thread. So the question is if such an extension would be okay in principle after cumulative_args_t, or whatever it will eventually be, has found it's way into mainline? Johann
Re: how can I write a right V32QI Unpack Low Data insn pattern?
On 02/03/2011 15:14, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 02/03/2011 07:56, Liu wrote:
>>
>>> The wrong code is :
>>> L9284: ATTRIBUTE_UNUSED_LABEL
>>> x3 = XEXP (x2, {);
>>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
>>> goto L9285;
>>> goto ret0;
>> Well, that's coming from here:
>>
>> else
>> printf ("%sx%d = XEXP (x%d, %c);\n",
>> indent, depth + 1, depth, newpos[depth]);
>> ++depth;
>
> Interesting. Looks you have a define_insn which has too many entries.
> It can only have 26 elements, but, annoyingly, genrecog doesn't check
> for that.
>
> It's a bit odd to have more than 26 elements. Do you have any
> incredibly large define_insn patterns?
It's that huge parallel full of (const_int)s that OP quoted at us in the
first post.
cheers,
DaveK
gcc-4.5-20110303 is now available
Snapshot gcc-4.5-20110303 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110303/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 170665 You'll find: gcc-4.5-20110303.tar.bz2 Complete GCC (includes all of below) MD5=2febdbd23eb3d80f742c00b4d579e05c SHA1=31893a0b98692ea56bc4863382c64e4a6c4a89dc gcc-core-4.5-20110303.tar.bz2C front end and core compiler MD5=906b0af37f0d2d63b2b47d52ac3a SHA1=1bd2f986fbaa02e3e26546219aefbe454226f313 gcc-ada-4.5-20110303.tar.bz2 Ada front end and runtime MD5=533bcb370e176c55d687eebd6a302624 SHA1=68e244894822883f66ca6d5dab64bce7235cc631 gcc-fortran-4.5-20110303.tar.bz2 Fortran front end and runtime MD5=ce009cff6cccaed6c617c9dfefdd4e73 SHA1=d143c6e779a236deac984ec2eccc769c98ee7152 gcc-g++-4.5-20110303.tar.bz2 C++ front end and runtime MD5=b565567557c0d3ef4b0250295b033663 SHA1=40e2118fb9aac36a9d807f86ccf47faa98ed6280 gcc-go-4.5-20110303.tar.bz2 Go front end and runtime MD5=910905d53be9a294e6aa7dad9f635c6a SHA1=f9e6656ac00859c3584e0d832f58de99d1092736 gcc-java-4.5-20110303.tar.bz2Java front end and runtime MD5=de453ef2c9ea0e3a8bf718ef97f93cae SHA1=63a894ef1e498f5e0c474afdfe8a7c92472823d9 gcc-objc-4.5-20110303.tar.bz2Objective-C front end and runtime MD5=18e30d8e7467e3385138ee75da7fd9c4 SHA1=dd535947b762122ba5e11f754287931b2ec5d405 gcc-testsuite-4.5-20110303.tar.bz2 The GCC testsuite MD5=2ee9aade68443d2051f863711da6c4af SHA1=99627915bfd1bbe63ca51efdfa39aceef3cd5bfd Diffs from 4.5-20110224 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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 can I write a right V32QI Unpack Low Data insn pattern?
On Thu, Mar 3, 2011 at 11:09 AM, Ian Lance Taylor wrote: > Liu writes: > >>> It's a bit odd to have more than 26 elements. Do you have any >>> incredibly large define_insn patterns? >>> >> Yes, I have some 80 lines define_insn patterns, are they incredibly large? > > An 80 line pattern is incredibly large, yes. The size of the overall > define_insn doesn't matter, just the size of the pattern. > >> I try your patch, but it get the same error still. > > Bother. Are you sure that genrecog ran again? Can you send us an > example of a very large define_insn pattern? > > Ian > Oh I get! Your patch made it! Thank you! Ina.
Re: GCC_FOR_TARGET settings being overridden by toplevel Makefile
On 03/03/2011 05:26 PM, Diego Novillo wrote: On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini wrote: On 03/02/2011 10:00 PM, Ian Lance Taylor wrote: That does not sound like the right approach to me. Why not add the new flags to GCC_FOR_TARGET at top-level? It seems to me that GCC_FOR_TARGET should mean the same thing at all levels. I agree. Why is it incorrect to use those flags when, say, compiling libgcc? They would be OK, but what puzzled me is that toplevel Makefile.in and gcc/Makefile.in have *different* definitions of GCC_FOR_TARGET. So, independently of what I'm trying to do, the definition of GCC_FOR_TARGET inside gcc/Makefile.in is always dead: Makefile.in: GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) @GCC_FOR_TARGET@ gcc/Makefile.in: GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld So, the variable will be set to different values if you run 'make' from toplevel or from gcc/ Is that by design? They should be kept in sync as much as possible. The ability to run 'make' from gcc/ is a feature, and "make check" needs a definition of GCC_FOR_TARGET. Paolo
