Jeff Law wrote:
> * Makefile.in (OBJS): Add gimple-ssa-isolate-paths.o
> * common.opt (-fisolate-erroneous-paths): Add option and
> documentation.
> * gimple-ssa-isolate-paths.c: New file.
This causes compiler segfaults for me when building Python 2.7.5.
See http://gcc.gnu
On Mon, Nov 11, 2013 at 10:55 AM, Eric Botcazou wrote:
>> Simply trapping doesn't tell you anything about caused the trap.
>> There are at least two distinct possibilities: NULL pointer
>> dereference and integer division by zero. There should be some way to
>> distinguish those two cases. It's
> Simply trapping doesn't tell you anything about caused the trap.
> There are at least two distinct possibilities: NULL pointer
> dereference and integer division by zero. There should be some way to
> distinguish those two cases. It's reasonably easy to do so in a
> signal handler. When should
On Mon, Nov 11, 2013 at 9:41 AM, Eric Botcazou wrote:
>> But throw what? It is up to the runtimes of -fnon-call-exceptions languages
>> to decide if they actually want to throw or do something else in the signal
>> handlers, and what exactly to throw.
>
> Throw nothing per se, __builtin_throw wou
> But throw what? It is up to the runtimes of -fnon-call-exceptions languages
> to decide if they actually want to throw or do something else in the signal
> handlers, and what exactly to throw.
Throw nothing per se, __builtin_throw would simply trap and ensure that the
exception thrown by the s
On Mon, Nov 11, 2013 at 8:27 AM, Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 09:24:27AM -0700, Jeff Law wrote:
>> On 11/11/13 02:33, Eric Botcazou wrote:
>> >>However, that brings up an couple interesting questions.
>> >>
>> >>Let's say we find a NULL pointer which reaches a return statement in
On Mon, Nov 11, 2013 at 09:24:27AM -0700, Jeff Law wrote:
> On 11/11/13 02:33, Eric Botcazou wrote:
> >>However, that brings up an couple interesting questions.
> >>
> >>Let's say we find a NULL pointer which reaches a return statement in a
> >>function which is marked as returns_nonnull. In that
On 11/11/13 02:33, Eric Botcazou wrote:
However, that brings up an couple interesting questions.
Let's say we find a NULL pointer which reaches a return statement in a
function which is marked as returns_nonnull. In that case there is no
dereference. Presumably for that kind of scenario we'll
On 11/11/13 05:16, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:11 AM, Jeff Law wrote:
On 11/10/13 05:34, Eric Botcazou wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo, no?
Th
On Mon, Nov 11, 2013 at 4:11 AM, Jeff Law wrote:
> On 11/10/13 05:34, Eric Botcazou wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo
> However, that brings up an couple interesting questions.
>
> Let's say we find a NULL pointer which reaches a return statement in a
> function which is marked as returns_nonnull. In that case there is no
> dereference. Presumably for that kind of scenario we'll just keep the
> builtin trap.
>
On 11/10/13 05:34, Eric Botcazou wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo, no?
That is true. OK, I can see an argument that when using
-fnon-call-exceptions that kind of code s
> > But I think that you cannot transform
> >
> > foo ()
> > {
> >
> > *0 = 1;
> >
> > }
> >
> > to __builtin_trap as you can catch the trap via an exception handler
> > in a caller of foo, no?
>
> That is true. OK, I can see an argument that when using
> -fnon-call-exceptions that kind of
On 11/06/13 08:27, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 04:23:06PM +0100, Richard Biener wrote:
In that case I think it would be fine to run the isolate paths
optimization, but to not omit the actual dereference of the NULL
pointer (possibly the dereference could be followed by a trap).
On Wed, Nov 06, 2013 at 09:15:57AM -0700, Jeff Law wrote:
> On 11/06/13 08:27, Jakub Jelinek wrote:
> >On Wed, Nov 06, 2013 at 04:23:06PM +0100, Richard Biener wrote:
> >>>In that case I think it would be fine to run the isolate paths
> >>>optimization, but to not omit the actual dereference of the
On 11/06/13 08:23, Richard Biener wrote:
On Wed, Nov 6, 2013 at 4:20 PM, Ian Lance Taylor wrote:
On Wed, Nov 6, 2013 at 7:15 AM, Richard Biener
wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a calle
On 11/06/13 08:20, Ian Lance Taylor wrote:
On Wed, Nov 6, 2013 at 7:15 AM, Richard Biener
wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo, no?
That is true. OK, I can see an argument
On 11/06/13 08:08, Ian Lance Taylor wrote:
The recent -fisolate-erroneous-paths optimization will change code
like this:
if (p == NULL) { printf ("NULL\n"); }
x = *p;
into code like this:
if (p == NULL) { printf ("NULL\n"); __builtin_trap (); }
x = *p;
That is, it will insert
On Wed, Nov 06, 2013 at 04:23:06PM +0100, Richard Biener wrote:
> > In that case I think it would be fine to run the isolate paths
> > optimization, but to not omit the actual dereference of the NULL
> > pointer (possibly the dereference could be followed by a trap).
>
> Yeah, we need the trap to
On Wed, Nov 6, 2013 at 4:20 PM, Ian Lance Taylor wrote:
> On Wed, Nov 6, 2013 at 7:15 AM, Richard Biener
> wrote:
>>
>> But I think that you cannot transform
>>
>> foo ()
>> {
>> *0 = 1;
>> }
>>
>> to __builtin_trap as you can catch the trap via an exception handler
>> in a caller of foo, no?
>
On Wed, Nov 6, 2013 at 7:15 AM, Richard Biener
wrote:
>
> But I think that you cannot transform
>
> foo ()
> {
> *0 = 1;
> }
>
> to __builtin_trap as you can catch the trap via an exception handler
> in a caller of foo, no?
That is true. OK, I can see an argument that when using
-fnon-call-exc
On Wed, Nov 6, 2013 at 4:08 PM, Ian Lance Taylor wrote:
> On Wed, Nov 6, 2013 at 6:29 AM, Richard Biener
> wrote:
>> On Wed, Nov 6, 2013 at 3:24 PM, Ian Lance Taylor wrote:
>>> On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse wrote:
On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
> This p
On Wed, Nov 6, 2013 at 6:29 AM, Richard Biener
wrote:
> On Wed, Nov 6, 2013 at 3:24 PM, Ian Lance Taylor wrote:
>> On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse wrote:
>>> On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
>>>
This patch actually breaks the Go testsuite. In Go dereferencing a
On Wed, Nov 6, 2013 at 3:24 PM, Ian Lance Taylor wrote:
> On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse wrote:
>> On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
>>
>>> This patch actually breaks the Go testsuite. In Go dereferencing a
>>> nil pointer is well-defined: it causes panic that can be caug
On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse wrote:
> On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
>
>> This patch actually breaks the Go testsuite. In Go dereferencing a
>> nil pointer is well-defined: it causes panic that can be caught. This
>> breaks a test for that functionality by changing t
On Tue, 5 Nov 2013, Ian Lance Taylor wrote:
This patch actually breaks the Go testsuite. In Go dereferencing a
nil pointer is well-defined: it causes panic that can be caught. This
breaks a test for that functionality by changing the panic to a
builtin_trap.
That's not a big deal; I'll just d
On 11/05/13 22:24, Ian Lance Taylor wrote:
On Mon, Nov 4, 2013 at 5:57 PM, Jeff Law wrote:
* Makefile.in (OBJS): Add gimple-ssa-isolate-paths.o
* common.opt (-fisolate-erroneous-paths): Add option and
documentation.
* gimple-ssa-isolate-paths.c: New file.
On Mon, Nov 4, 2013 at 5:57 PM, Jeff Law wrote:
>
> * Makefile.in (OBJS): Add gimple-ssa-isolate-paths.o
> * common.opt (-fisolate-erroneous-paths): Add option and
> documentation.
> * gimple-ssa-isolate-paths.c: New file.
> * gimple.c (check_loadstore): New
On 11/05/13 04:53, Richard Biener wrote:
Fortran front-end doesn't provide this IIRC.
Are you sure? omp lowering makes unconditional use of it and I see
it created in f95-lang.c. There are various other unconditional uses
one covering vararg functions, one exceptions. I doubt we have a
lang
On 11/05/13 04:53, Richard Biener wrote:
Fortran front-end doesn't provide this IIRC.
Are you sure? omp lowering makes unconditional use of it and I see
it created in f95-lang.c. There are various other unconditional uses
one covering vararg functions, one exceptions. I doubt we have a
lang
On Tue, Nov 5, 2013 at 2:57 AM, Jeff Law wrote:
> On 11/04/13 06:19, Richard Biener wrote:
>>
>> On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law wrote:
>>>
>>>
>>> I've incorporated the various suggestions from Marc and Richi, except for
>>> Richi's to integrate this into jump threading.
>>>
>>> I've a
On 11/04/13 06:19, Richard Biener wrote:
On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law wrote:
I've incorporated the various suggestions from Marc and Richi, except for
Richi's to integrate this into jump threading.
I've also made the following changes since the last version:
1. Added more tes
On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law wrote:
>
> I've incorporated the various suggestions from Marc and Richi, except for
> Richi's to integrate this into jump threading.
>
> I've also made the following changes since the last version:
>
> 1. Added more testcases.
>
> 2. Use infer_nonnull
I've incorporated the various suggestions from Marc and Richi, except
for Richi's to integrate this into jump threading.
I've also made the following changes since the last version:
1. Added more testcases.
2. Use infer_nonnull_range, moving it from tree-vrp.c
into gimple.c. Minor imp
34 matches
Mail list logo
