Robert Dewar wrote:
FX Coudert wrote:
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alludi
FX Coudert wrote:
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alluding to is that "real"
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alluding to is that "real" Fortran programmer
Toon Moene wrote:
In Fortran, integers are used to index arrays. So if you want integer
overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
FX Coudert wrote:
[ Sorry, I'm way, way behind ]
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use
On Feb 29, 2008, at 19:13, Richard Guenther wrote:
We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove
* Ross Ridge:
> At the risk of my curiousity getting me into more trouble, could any
> one explain to me how to access these "eip" and "trapno" members from
> a signal handler on Linux? I can't find any relevent documention with
> man nor Google.
I think you need sigaction with a SA_SIGINFO, and
Somehow this got stuck in the spam filter.
- Forwarded message from [EMAIL PROTECTED] -
Date: Sat, 01 Mar 2008 09:21:21 -0500
From: Joern Rennecke <[EMAIL PROTECTED]>
Reply-To: Joern Rennecke <[EMAIL PROTECTED]>
Subject: Re: [PATCH][4.3] Deprecate -ftrapv
Eric Botcazou wrote:
Perhaps if the current implementation is too broken, that might be
the most constructive approach ...
That's my opinion and the current state of affairs is a hindrance, so I think
that -ftrapv should be reimplemented from scratch if GCC is to be serious
about overflow che
Eric Botcazou wrote:
Well let's see .. we (AdaCore) will try to focus more attention on this
to evaluate whether it is feasible to get this feature working well
enough to use in GNAT.
We already did that several times: -ftrapv is too broken to be used for Ada.
In its current form, that's true
> Perhaps if the current implementation is too broken, that might be
> the most constructive approach ...
That's my opinion and the current state of affairs is a hindrance, so I think
that -ftrapv should be reimplemented from scratch if GCC is to be serious
about overflow checking. Of course we
> Well let's see .. we (AdaCore) will try to focus more attention on this
> to evaluate whether it is feasible to get this feature working well
> enough to use in GNAT.
We already did that several times: -ftrapv is too broken to be used for Ada.
--
Eric Botcazou
Ross Ridge:
>With INTO I don't see any way distignuish the SIGSEGV it generates on
>Linux from any of the myriad other ways a SIGSEGV can be generated.
Paolo Bonzini writes:
>sc.eip == 0xCE (if I remember x86 opcodes well :-) as I'm going by heart...)
The INTO instruction generates a trap excepti
Richard Guenther <[EMAIL PROTECTED]> writes:
> I believe at last years summit Ian told me that someone at google was
> working on this -- Ian is this still true?
Unfortunately that person moved on to other projects.
Ian
> The code with conditional jumps is bigger but less dependant on the
> OS environment or of any user code trying to install its own signal
> handlers (especially for SIGSEGV which multiplexes so many exception
> causes). The performance impact is probably small since the jumps
> will normally be
On Mon, Mar 03, 2008 at 01:38:01AM +0100, Andi Kleen wrote:
> [EMAIL PROTECTED] (Ross Ridge) writes:
>
> > Robert Dewar writes:
> > >Yes, and that is what we would want for Ada, so I am puzzled by your
> > >sigh. All Ada needs to do is to issue a constraint_error exception,
> > >it does not need t
Unless printing "This application has requested the Runtime to terminate
it in an unusual way." counts an issuing a contraint_error in Ada,
it seems to me that -ftrapv and Ada have differing requirements.
How can you portabilty and correctly generate a constraint_error if
the code generated by -
Ross Ridge wrote:
Ross Ridge writes:
On Unix-like systems you can catch SIGABRT, but even there how do you
tell that it didn't come from CTRL-\...
Oops, I forgot that CTRL-\ had it own signal SIGQUIT.
Ross Ridge
In fact I suspect that once you stop si
Ross Ridge writes:
> On Unix-like systems you can catch SIGABRT, but even there how do you
> tell that it didn't come from CTRL-\...
Oops, I forgot that CTRL-\ had it own signal SIGQUIT.
Ross Ridge
Andi Kleen wrote:
[EMAIL PROTECTED] (Ross Ridge) writes:
Easy: The signal frame that is passed as an argument to the signal handler
has a trapno member than will contain 4 for INTO. The only other case where
it would contain 4 would be a explicit int 4
OK, so that's exactly what is needed i
[EMAIL PROTECTED] (Ross Ridge) writes:
> Robert Dewar writes:
> >Yes, and that is what we would want for Ada, so I am puzzled by your
> >sigh. All Ada needs to do is to issue a constraint_error exception,
> >it does not need to know where the exception came from or why except
> >in very broad deta
Ross Ridge wrote:
Robert Dewar writes:
Yes, and that is what we would want for Ada, so I am puzzled by your
sigh. All Ada needs to do is to issue a constraint_error exception,
it does not need to know where the exception came from or why except
in very broad detail.
Unless printing "This appli
Robert Dewar writes:
>Yes, and that is what we would want for Ada, so I am puzzled by your
>sigh. All Ada needs to do is to issue a constraint_error exception,
>it does not need to know where the exception came from or why except
>in very broad detail.
Unless printing "This application has request
Robert Dewar write:
But, once again, using the processor specific JO instruction will be
much better for Ada than double length arithmetic, using JO does not
involve a "program crash with a vague exception".
*sigh* The possibility of using GCC's -ftrapv support to implement
overlow exception
Robert Dewar write:
>Usually there are ways of telling what is going on at a sufficiently
>low level, but in any case, code using the conditional jump instruction
>(jo/jno) is hugely better than what we do now (and it is often faster
>to usea jo than into).
Ross Ridge wrote:
>My point is that us
Ross Ridge wrote:
Robert Dewar write:
Usually there are ways of telling what is going on at a sufficiently
low level, but in any case, code using the conditional jump instruction
(jo/jno) is hugely better than what we do now (and it is often faster
to usea jo than into).
My point is that using
Robert Dewar write:
>Usually there are ways of telling what is going on at a sufficiently
>low level, but in any case, code using the conditional jump instruction
>(jo/jno) is hugely better than what we do now (and it is often faster
>to usea jo than into).
My point is that using INTO or some othe
Ross Ridge wrote:
Actually, that's a different issue than catching 100% of overflows,
which apparently Ada doesn't require.
Well basically Ada does require catching all overflows, the only issue
is the optimization issue that we already discussed, it would be
acceptable to not catch this. How
Mark Mitchell writes:
> However, I don't think doing all of that work is required to make this
> feature useful to people. You seem to be focusing on making -ftrapv
> capture 100% of overflows, so that people could depend on their programs
> crashing if they had an overflow. That might be usef
Steven Bosscher wrote:
There has been at least one incident of a software bug in certified
code, but it is very rare, and the record is impressive (no life
has been lost because of a software bug in the history of commercial
aviation).
I agree with all you've said so far, but this statement abo
> There has been at least one incident of a software bug in certified
> code, but it is very rare, and the record is impressive (no life
> has been lost because of a software bug in the history of commercial
> aviation).
I agree with all you've said so far, but this statement above is a bit
too op
Frank Ch. Eigler wrote:
Hi -
On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
[...]
(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)
As I say, it is mo
Hi -
On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote:
> [...]
> >(Off topic, but I'd expect that avionics software is engineered with
> >enough layers of protection, including catching traps, so that a
> >-ftrapv hit would not cause a deep impact.)
>
> As I say, it is more usual in a
(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)
Actually this discussion is not *so* off-topic.
if you regard -ftrapv as something that would be enabled in critica
Frank Ch. Eigler wrote:
Hi -
On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
[...] Safety-critical and security-critical software are two
totally different concepts. Be careful not to confuse them. In
safety-critical software, e.g. avionics system, it is not acceptable
for the s
Hi -
On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:
> [...] Safety-critical and security-critical software are two
> totally different concepts. Be careful not to confuse them. In
> safety-critical software, e.g. avionics system, it is not acceptable
> for the system to crash. In
Frank Ch. Eigler wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...] You seem to be focusing on making -ftrapv capture 100% of
overflows, so that people could depend on their programs crashing if
they had an overflow. That might be useful in two circumstances:
(a) getting bugs out (though
Mark Mitchell <[EMAIL PROTECTED]> writes:
> [...] You seem to be focusing on making -ftrapv capture 100% of
> overflows, so that people could depend on their programs crashing if
> they had an overflow. That might be useful in two circumstances:
> (a) getting bugs out (though for an example lik
On Sun, Mar 2, 2008 at 2:00 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > I missed once point noticed by Joseph also, that the libgcc implementation
> > uses signed types in the implementation of the trapping arithmetics.
> > Where we of cours
On Sat, 1 Mar 2008, Richard Guenther wrote:
> I missed once point noticed by Joseph also, that the libgcc implementation
> uses signed types in the implementation of the trapping arithmetics.
> Where we of course optimize away the overflow check, so the libgcc
> routines will never trap. (if it d
Richard Guenther wrote:
Nice plan. Though I doubt that even this simple one will be carried out,
as even the simple bugs in the current implementation stay around for at
least 5 years.
Well let's see .. we (AdaCore) will try to focus more attention on this
to evaluate whether it is feasible t
> I agree with everything you've written, including, in particular, that
> making this explicit in the IL (via special tree codes for, e.g.,
> trapping-add) would be best.
I'd be in favor of flags rather than new codes. For the most part, all
processing of non-trapping operations and trapping o
Mark Mitchell wrote:
However, I don't think doing all of that work is required to make this
feature useful to people. You seem to be focusing on making -ftrapv
capture 100% of overflows, so that people could depend on their programs
crashing if they had an overflow. That might be useful in t
On Sun, 2 Mar 2008, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > > > int f(int a, int b) { return 0 * (a + b); }
>
> > They are the natural interpretation of -ftrapv that's simplest to describe
> > in terms of the abstract machine of the C standard: any signed integer
> > arithmetic overf
Joseph S. Myers wrote:
int f(int a, int b) { return 0 * (a + b); }
They are the natural interpretation of -ftrapv that's simplest to describe
in terms of the abstract machine of the C standard: any signed integer
arithmetic overflow in the abstract machine (and maybe integer division by
0,
FX Coudert wrote:
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use (or would use) checking on signe
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use (or would use) checking on signed
overflow.
FX
Robert Dewar wrote:
The reason that we distinguish overflow checking from other kinds of
constraint checking is that a failure of an overflow check, unlike
for example the failure of a range check, can result in an incorrect
value, but cannot cause random memory destruction (like an out of range
Florian Weimer wrote:
* Robert Dewar:
Standard ML. I don't think there is a GCC front end (and it's not
likely that one will be feasible, at least until GCC supports a fitting
garbage collector).
Why is it a GCC issue to support a GC for ML, I don't get it ...
ML programs are mostly functio
Florian Weimer wrote:
Are we talking about the Ada semantics or GNAT without -gnato? In the
latter case, the documentation disagrees with you:
The reason that we distinguish overflow checking from other kinds
of range constraint checking is that a failure of an overflow
check ca
* Robert Dewar:
>> Standard ML. I don't think there is a GCC front end (and it's not
>> likely that one will be feasible, at least until GCC supports a fitting
>> garbage collector).
>
> Why is it a GCC issue to support a GC for ML, I don't get it ...
ML programs are mostly functional and alloca
* Robert Dewar:
> Florian Weimer wrote:
>> * Robert Dewar:
>>
>>> So here's exactly what happens now in Ada
>>>
>>> 1. If -gnato is not set (no overflow checking)
>>>
>>> In this case, the situation is exactly the same as C, and the front end
>>> ignores the possibility of overflow.
>>
>> It's C i
Florian Weimer wrote:
* Richard Kenner:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that re
Florian Weimer wrote:
* Robert Dewar:
So here's exactly what happens now in Ada
1. If -gnato is not set (no overflow checking)
In this case, the situation is exactly the same as C, and the front end
ignores the possibility of overflow.
It's C in -fwrapv mode, isn't it? (Otherwise, you can'
* Florian Weimer:
> * Richard Kenner:
>
>>> int f(int a, int b) { return 0 * (a + b); }
>>>
>>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>>> have properly defined semantics, those must include trapping if (a + b)
>>> overflows in the above code.
>>
>> Why? Is ther
* Richard Kenner:
>> int f(int a, int b) { return 0 * (a + b); }
>>
>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>> have properly defined semantics, those must include trapping if (a + b)
>> overflows in the above code.
>
> Why? Is there any language that requires
* Robert Dewar:
> So here's exactly what happens now in Ada
>
> 1. If -gnato is not set (no overflow checking)
>
> In this case, the situation is exactly the same as C, and the front end
> ignores the possibility of overflow.
It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is the
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > But arbitrary arithmetic expressions aren't marked as potentially trapping
> > / having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. I
On Sat, 2008-03-01 at 09:05 -0500, Robert Dewar wrote:
> Note that in Ada, you can often avoid one or both ends of
> the range check, e.g.
>
> type R is integer range 1 .. 10;
>
> RV : R;
>
> R := R + 1;
>
> no need for double length arithmetic here, you just check that the
> re
Joern Rennecke wrote:
Considering the trouble that you get when you try to generate branches in
a non-branch expander, we should probably have alternate named patterns
to be used in ports to processors that have no conditional trap facility,
or where a conditional trap is more expensive than a w
I missed once point noticed by Joseph also, that the libgcc implementation
uses signed types in the implementation of the trapping arithmetics.
Where we of course optimize away the overflow check, so the libgcc
routines will never trap. (if it does work in some cases then this
would be a missed o
On Fri, 29 Feb 2008, Robert Dewar wrote:
Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).
In fact, when I wrote the original -ftrapv code, it was for the sole purpose
of u
Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).
On the whole I think you'd want to benefit from tree-ssa optimizing
overflow checks where possible (including optimizing
Richard Kenner wrote:
No one needs a broken anything,
Not necessarily and perhaps not in this case. Let's suppose there was
an implementation of -ftrapv that did trap, but only about 80% of the
time. Such an implementation would nevertheless be useful in C since
there overflow is not a requir
Richard Guenther wrote:
On Sat, 1 Mar 2008, Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is
> IMHO this semantics asks for the frontend to implement the overflow
> check. Does the above mean that Ada does intermediate arithmetics
> in wider types?
No, it means that it must *either* do the arithmetic in wider types *or*
use arithmetic in the narrower types that checks for overflow.
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semanti
> No one needs a broken anything,
Not necessarily and perhaps not in this case. Let's suppose there was
an implementation of -ftrapv that did trap, but only about 80% of the
time. Such an implementation would nevertheless be useful in C since
there overflow is not a required feature of the lang
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semanti
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is the
> int f(int a, int b) { return 0 * (a + b); }
>
> get the potentially trapping arithmetic folded away. If -ftrapv is to
> have properly defined semantics, those must include trapping if (a + b)
> overflows in the above code.
Why? Is there any language that requires such semantics?
Richard Guenther wrote:
IMHO this semantics asks for the frontend to implement the overflow
check. Does the above mean that Ada does intermediate arithmetics
in wider types? I don't see how you could catch the B + C case
otherwise (assuming the range check for the assignment to A covers
all of
On Sat, Mar 1, 2008 at 2:57 PM, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Paolo Bonzini wrote:
> >> Seems a pity, this feature is really needed for Ada, which requires
> >> efficient overflow checking for signed arithmetic, and it seems
> >> useful for C, where signed overflow is undefined, and
Paolo Bonzini wrote:
Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.
Right now, Ada uses really horrible double length ar
On Sat, 1 Mar 2008, Robert Dewar wrote:
> Joseph S. Myers wrote:
>
> > But arbitrary arithmetic expressions aren't marked as potentially trapping /
> > having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping ari
Richard Kenner wrote:
Clearly. My point was that Ada doesn't need a *broken* -ftrapv. So if
there's no hope of fixing it, we might as well deprecate it.
Sure, but right now we have the start of a constructive discussion of
how to fix it, so the best thing would be to contribute positively to
Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.
Right now, Ada uses really horrible double length arithmetic to
do trapp
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > > You also need to deal with fold, which will optimize away potentially
> > > trapping computations with -ftrapv and runs before gimplification
> > > (possibly in association with making fold run at g
Joseph S. Myers wrote:
But arbitrary arithmetic expressions aren't marked as potentially trapping
/ having side-effects with -ftrapv, so cases such as
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined sema
On Fri, 29 Feb 2008, Robert Dewar wrote:
> > If it were done at gimplification time I imagine something like the libgcc
> > code would be used, but with conversions to/from unsigned inserted as
> > needed. It would be possible to do optimizations at gimplification time if
> > one argument is cons
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > You also need to deal with fold, which will optimize away potentially
> > trapping computations with -ftrapv and runs before gimplification
> > (possibly in association with making fold run at gimplification time and
> > not before).
>
> It shoul
Richard Guenther wrote:
So I would hestitate to deprecate it so quickly
Maybe you should organize some resources to fix its implementation
then?
Richard.
It's been on the list for over a decade, it's always harder to find
resources to fix performance problems that don't specifically show
up
On Fri, 29 Feb 2008, Robert Dewar wrote:
> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time. As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Fri, 29 Feb 2008, Mark Mitchell wrote:
>
> > Thanks for the explanations. It seems like tree-ssa should in theory make
> > it
> > easier to implement this; for example, at the point of gimplification one
> > could insert checks, and then just let
On Fri, 29 Feb 2008, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> > The tree optimizers do not recognize +-* of singed integers as
> > possibly trapping which causes functions to become const/pure that
> > should not and causes 'dead' code to be removed that should not.
>
> Thanks for the
> > Ada currently has to do this itself, precisely because -ftrapv doesn't
> > work, so it's not the case that Ada "needs" it.
>
> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back
> end. But right now, the
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> Do we need functionality like this for Ada or Java?
It is not needed for Java.
Tom
Joseph S. Myers wrote:
On Fri, 29 Feb 2008, Robert Dewar wrote:
Well no one "needs" anything in this sense, any interfaced is Turing
complete so there is *always* a work around deficiencies in the back end. But
right now, the "do this itself" is really horribly inefficient:
You can see the C
On Fri, 29 Feb 2008, Robert Dewar wrote:
> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back end. But
> right now, the "do this itself" is really horribly inefficient:
You can see the C code in libgcc2.c (__
David Daney wrote:
Mark Mitchell wrote:
Richard Guenther wrote:
This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time. As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it poss
Richard Kenner wrote:
Why doesn't it work? Can it be made to work relatively easily? Do we
need functionality like this for Ada or Java?
Ada currently has to do this itself, precisely because -ftrapv doesn't
work, so it's not the case that Ada "needs" it.
Well no one "needs" anything in thi
Richard Guenther wrote:
This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time. As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
bloc
Joseph S. Myers wrote:
You also need to deal with fold, which will optimize away potentially
trapping computations with -ftrapv and runs before gimplification
(possibly in association with making fold run at gimplification time and
not before).
Indeed. However, errors missed due to fold eli
On Fri, 29 Feb 2008, Mark Mitchell wrote:
> Thanks for the explanations. It seems like tree-ssa should in theory make it
> easier to implement this; for example, at the point of gimplification one
> could insert checks, and then just let everything else do its thing. I don't
> see how libcalls a
Richard Guenther wrote:
The tree optimizers do not recognize +-* of singed integers as
possibly trapping which causes functions to become const/pure that
should not and causes 'dead' code to be removed that should not.
Thanks for the explanations. It seems like tree-ssa should in theory
make
On Sat, 1 Mar 2008, Richard Guenther wrote:
> I seriously doubt anyone has used it for anything useful since at least
> the advent of tree-ssa. I see we for example warn for -fforce-mem
> in 4.2, but that is a no-op there. Do we have an option to disable
> such warnings? After all it would brea
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time. As nobody seems
> > to have the energy to ensure it is working I propose to dep
Mark Mitchell wrote:
Richard Guenther wrote:
This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time. As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it du
On Fri, 29 Feb 2008, Mark Mitchell wrote:
> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time. As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.
1 - 100 of 105 matches
Mail list logo
