On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou ebotca...@adacore.com 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
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 Wed, May 6, 2009 at 9:04 PM, Eric Botcazou ebotca...@adacore.com 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
On Wed, May 6, 2009 at 9:17 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou ebotca...@adacore.com 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
I wonder for example about
integer_type 0x2b1d770a3300 integer
type integer_type 0x2b1d76cbe540 integer sizes-gimplified
asm_written public visited SI
size integer_cst 0x2b1d76cb0a20 constant 32
unit size integer_cst 0x2b1d76cb0690 constant 4
align 32 symtab
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
On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou ebotca...@adacore.com 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
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 Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou ebotca...@adacore.com 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
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
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 invalid
values in Ada more robust and expose more optimization
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
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
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.
cheers,
14 matches
Mail list logo
