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,
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 unit
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 in
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 level
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 PR4650
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 failu
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 cons
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, th
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
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 incred
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 sho
11 matches
Mail list logo
