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
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. Computing the dominance info just to tw
22 matches
Mail list logo