On 07/30/14 05:54, Marc Glisse wrote:
On Tue, 29 Jul 2014, David Malcolm wrote:
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-
On 07/22/14 03:03, Marc Glisse wrote:
I note you don't catch return &localvar in the isolation code -- it
looks like you just catch those which potentially flow from PHIs.
I thought I was handling it in the find_explicit_erroneous_behaviour
part of the patch (as opposed to the implicit part whi
On Tue, 29 Jul 2014, David Malcolm wrote:
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new pat
On Tue, 2014-07-29 at 21:13 +0200, Marek Polacek wrote:
> On Tue, Jul 29, 2014 at 02:58:03PM -0400, David Malcolm wrote:
> > This is possibly a dumb question, but what happens for a static local,
> > rather than an auto local? e.g.
> >
> > int *f (void)
> > {
> > static int i;
> > return &
On Tue, 29 Jul 2014, David Malcolm wrote:
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new pat
On Tue, Jul 29, 2014 at 02:58:03PM -0400, David Malcolm wrote:
> This is possibly a dumb question, but what happens for a static local,
> rather than an auto local? e.g.
>
> int *f (void)
> {
> static int i;
> return &i;
> }
This is fine. The variable i has a static storage duration, so
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
> On Sun, 27 Jul 2014, Richard Sandiford wrote:
>
> > Marc Glisse writes:
> >> Hello,
> >>
> >> I followed the advice in this discussion:
> >> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
> >>
> >> and here is a new patch. I made a
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too strange that
On Sun, 27 Jul 2014, Andreas Schwab wrote:
Marc Glisse writes:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
+ if (always_executed)
+ msg = "function returns address of local variable";
+ else
+
Marc Glisse writes:
> On Sun, 27 Jul 2014, Richard Sandiford wrote:
>
>> Marc Glisse writes:
>>> + if (always_executed)
>>> + msg = "function returns address of local variable";
>>> + else
>>> + msg = "function may return addres
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too strange that
Marc Glisse writes:
> Hello,
>
> I followed the advice in this discussion:
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
>
> and here is a new patch. I made an effort to isolate a path in at least
> one subcase so it doesn't look too strange that the warning is in this
> file. Compu
On Wed, 16 Jul 2014, Jeff Law wrote:
On 06/22/14 12:20, Marc Glisse wrote:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too stran
On 06/22/14 12:20, Marc Glisse wrote:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too strange that the warning is in this
file. Co
On 06/30/14 15:37, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+ && !is_global_var (valbase))
+ || TREE_CODE
On 07/02/14 06:19, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
On Wed, 2 Jul 2014, Alan Modra wrote:
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
> On Mon, 30 Jun 2014, Jeff Law wrote:
>
> >On 06/29/14 03:22, Marc Glisse wrote:
> >>
> >>After looking at PR 61597, I updated the 2 conditions to:
> >>
> >>+ if ((TREE_CODE (valbase) == VAR_DECL
> >>+ && !is_glob
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+ && !is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)
a PARM_DECL is
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+ && !is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)
a PARM_DECL is a local variable and returning its add
( https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html )
On Sun, 22 Jun 2014, Marc Glisse wrote:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
and here is a new patch. I made an effort to isolate a path in at least one
subcase s
21 matches
Mail list logo
