Hi,
On Sun, Dec 04, 2011 at 05:00:41PM +0100, Jan Hubicka wrote:
> > > No to what? To the fact that HOST_WIDEST_INT is host-dependent
> > > and thus should not be used to drive code generation? Or no to the
> > > fact that we can (and do) use int64_t as host integer type?
> >
> > No to the fact
> > No to what? To the fact that HOST_WIDEST_INT is host-dependent
> > and thus should not be used to drive code generation? Or no to the
> > fact that we can (and do) use int64_t as host integer type?
>
> No to the fact that int64_t should be used (and the occurrences in the LTO
> code
> are
> No to what? To the fact that HOST_WIDEST_INT is host-dependent
> and thus should not be used to drive code generation? Or no to the
> fact that we can (and do) use int64_t as host integer type?
No to the fact that int64_t should be used (and the occurrences in the LTO code
are OK). hwint.h i
On Sun, Dec 4, 2011 at 4:37 PM, Richard Guenther
wrote:
> On Sun, Dec 4, 2011 at 4:31 PM, Eric Botcazou wrote:
>>> This introduces host-dependent code generation differences, right?
>>> You can simply use int64_t for code that is run on the host only.
>>
>> Well, no, there is an entire file dedic
On Sun, Dec 4, 2011 at 4:31 PM, Eric Botcazou wrote:
>> This introduces host-dependent code generation differences, right?
>> You can simply use int64_t for code that is run on the host only.
>
> Well, no, there is an entire file dedicated to this business (hwint.h).
No to what? To the fact that
> I don't think that is related to C++ switch, because C++03 doesn't have
> long long, only C++11 and C99 has it. We apparently are using int64_t or
> uint64_t in a couple of places already though:
IMHO they should be audited and fixed if need be.
> ada/tb-gcc.c: uwx_get_reg ((struct uwx_env *)
> This introduces host-dependent code generation differences, right?
> You can simply use int64_t for code that is run on the host only.
Well, no, there is an entire file dedicated to this business (hwint.h).
--
Eric Botcazou
> On Thu, Dec 01, 2011 at 05:16:21PM +0100, Jan Hubicka wrote:
> > > This introduces host-dependent code generation differences, right?
> > > You can simply use int64_t for code that is run on the host only.
> >
> > Well, if we rely on int64_t being around now (that is probably the case with
> > C
On Thu, Dec 01, 2011 at 05:16:21PM +0100, Jan Hubicka wrote:
> > This introduces host-dependent code generation differences, right?
> > You can simply use int64_t for code that is run on the host only.
>
> Well, if we rely on int64_t being around now (that is probably the case with
> C++ switch),
> On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor wrote:
> > Hi,
> >
> > PR 50744 is an issue with an integer overflow when we propagate the
> > estimated size and time effects from callees to callers. Because such
> > paths in the parameter value graph can be arbitrarily long, we simply
> > need
On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor wrote:
> Hi,
>
> PR 50744 is an issue with an integer overflow when we propagate the
> estimated size and time effects from callees to callers. Because such
> paths in the parameter value graph can be arbitrarily long, we simply
> need to introduce a
Hi,
PR 50744 is an issue with an integer overflow when we propagate the
estimated size and time effects from callees to callers. Because such
paths in the parameter value graph can be arbitrarily long, we simply
need to introduce an artificial cap on these values. This is what the
patch below do
12 matches
Mail list logo
