Bingfeng,
to define the pragma you use something like this:
#define REGISTER_TARGET_PRAGMAS()
{
c_register_pragma (0, "unroll_factor",
support_unroll_pragma);
}
such that when you compile a loop
Alex,
Thank you very much. I know REGISTER_TARGET_PRAGMAS interface, but I
didn't realize you also use the same interface to create builtins. Did
you still need modify loop-unroll.c or other gcc files to detect
preceding "customop_unroll_pragma" instruction?
Cheers,
Bingfeng
-Original Messag
Hi,
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long scalar
is wide enough for a pointer. This is at least for w64 target not true. So
I want to know, if it would be good to introduce an gcc specific type for
Kai Tietz wrote:
> as I noticed, most hash value calculations are trying to use pointer
> values for building the value and assume that a long/unsigned long scalar
> is wide enough for a pointer. This is at least for w64 target not true. So
> I want to know, if it would be good to introduce an
Andrew,
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 11:45:50:
> Kai Tietz wrote:
>
> > as I noticed, most hash value calculations are trying to use pointer
> > values for building the value and assume that a long/unsigned long
scalar
> > is wide enough for a pointer. This is at least
On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> as I noticed, most hash value calculations are trying to use pointer
> values for building the value and assume that a long/unsigned long scalar
> is wide enough for a pointer. This is at least for w64 target not true.
Kai Tietz wrote:
> Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 11:45:50:
>
>> Kai Tietz wrote:
>>
>>> as I noticed, most hash value calculations are trying to use pointer
>>> values for building the value and assume that a long/unsigned long
> scalar
>>> is wide enough for a pointer.
Richard Guenther wrote:
> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> as I noticed, most hash value calculations are trying to use pointer
>> values for building the value and assume that a long/unsigned long scalar
>> is wide enough for a pointer. This is at
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 12:07:49:
> Richard Guenther wrote:
> > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]>
wrote:
> >> Hi,
> >>
> >> as I noticed, most hash value calculations are trying to use pointer
> >> values for building the value and assume
it's uintptr_t which should be used, if only as an intermediate cast -
(unsigned long)(uintptr_t)ptr.
That's not possible because, IIRC, gcc must compile on C90 systems.
Right, so the only type remaining is size_t. IIRC there is problem for
this type on some targets, too. AFAIC there are 24-
Andrew Haley <[EMAIL PROTECTED]> writes:
> Richard Guenther wrote:
>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> as I noticed, most hash value calculations are trying to use pointer
>>> values for building the value and assume that a long/unsigned long s
On Thu, May 29, 2008 at 01:57:51PM +0200, Richard Guenther wrote:
>
> A second release candidate for GCC 4.3.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.1-RC-20080529
>
> and shortly its mirrors. It has been generated from SVN revision 136151.
Nice to see that it still bu
Snapshot gcc-4.4-20080530 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080530/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
13 matches
Mail list logo
