> I wonder for example about
>
> type asm_written public visited SI
> size
> unit size
> align 32 symtab 1993070176 alias set -1 canonical type
> 0x2b1d76cbe540 precision 32 min -2147483648> max
> pointer_to_this >
> sizes-gimplified asm_written public
On Wed, May 6, 2009 at 9:17 PM, Richard Guenther
wrote:
> On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou wrote:
>>> What is missing to go forward with this plan?
>>
>> Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
>> some cases because move IVs are exposed and so ar
On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou wrote:
>> What is missing to go forward with this plan?
>
> Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
> some cases because move IVs are exposed and so are -fivopts' warts.
>
>> I am hitting type consistency problems
> What is missing to go forward with this plan?
Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
some cases because move IVs are exposed and so are -fivopts' warts.
> I am hitting type consistency problems again while trying to fix PR3 ...
Ideally this should be
On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou wrote:
> Hi,
>
> we're almost ready to get rid of the awkward semantics that is implemented in
> the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
> TREE_TYPE); this should overall simplify things, make the support for inv
> Yes, we could do that. Though a simpler form may be preferable, like
> directly specifying a constant range/anti-range instead of encoding these
> in (multiple) ASSERT_EXPRs.
>
> I will think of something.
Thanks.
> As for Ada - both function entry and exit constraints will be checked by
> the
On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou wrote:
>> I wonder what this exception in VRP looks like?
>
> I wasn't specifically referring to an exception in VRP. I think that, when
> checks are off, it would be sufficient for gigi to emit sort of assertions
> for arguments on function entry (l
> I wonder what this exception in VRP looks like?
I wasn't specifically referring to an exception in VRP. I think that, when
checks are off, it would be sufficient for gigi to emit sort of assertions
for arguments on function entry (like your VRP patch did) and for return
values on function cal
Dave Korn wrote:
Robert Dewar wrote:
The compiler
should not assume validity unless it can prove that the value is
actually in the declared range in my opinion.
We could add a "-fstrict-validity=" by analogy to "-fstrict-alias=". Ada
and C would want to have different default settings I im
On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou wrote:
> Hi,
>
> we're almost ready to get rid of the awkward semantics that is implemented in
> the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
> TREE_TYPE); this should overall simplify things, make the support for inv
Robert Dewar wrote:
> The compiler
> should not assume validity unless it can prove that the value is
> actually in the declared range in my opinion.
We could add a "-fstrict-validity=" by analogy to "-fstrict-alias=". Ada
and C would want to have different default settings I imagine.
che
Richard Kenner wrote:
There are many cases when you can prove the value can be treated as valid.
One interesting case is based on the fact that suppressing a
language-defined check is erroneous if that check would fail. So, for
A: = B + 1;
you *can* assume A is valid.
Yes, but I don
> we're almost ready to get rid of the awkward semantics that is
> implemented in the middle-end and the optimizers for subtypes
> (INTEGER_TYPEs with a non-null TREE_TYPE); this should overall simplify
> things, make the support for invalid values in Ada more robust and expose
> more optimization
13 matches
Mail list logo
