[Bug fortran/20460] Nasty extensions that should always warn

[Bug fortran/20460] Nasty extensions that should always warn

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2006-05-07 16:41 -------
This one a very strange: what do the comments #4 and #5 do in this PR?

Anyhow, we know have -std=legacy for such features, including REAL DO loop
indices. The remaining question is: do we want to mark REAL array indices as
legacy (there's currently no warning about them in -std=gnu mode)?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2005-12-30 19:22:17         |2006-05-07 16:41:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de  2006-05-07 16:46 -------
Subject: Re:  Nasty extensions that should always warn

fxcoudert at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote on  
Sun, 07 May 2006:
> Anyhow, we know have -std=legacy for such features, including REAL DO loop
> indices. The remaining question is: do we want to mark REAL array indices as
> legacy (there's currently no warning about them in -std=gnu mode)?

(we didn't have STD_LEGACY when this PR was opened)

I think this would be a good idea.  IMO bad Fortran 77 habits can  
qualify as legacy nowadays.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-05-07 16:48 -------
(In reply to comment #7)
>> Anyhow, we know have -std=legacy for such features
>
> (we didn't have STD_LEGACY when this PR was opened)

Yes, I meant "we now have -std=legacy" :)

> I think this would be a good idea.  IMO bad Fortran 77 habits can  
> qualify as legacy nowadays.

I'll submit a patch when I find some time.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-05-07 16:41:32         |2006-05-07 16:48:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-05-10 14:58 -------
Subject: Bug 20460

Author: fxcoudert
Date: Wed May 10 14:58:48 2006
New Revision: 113672

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113672
Log:
        PR fortran/20460
        * resolve.c (gfc_resolve_index): Make REAL array indices a
        GFC_STD_LEGACY feature.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] [4.1 only] Nasty extensions that should always warn

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2006-05-11 21:39 -------
Subject: Bug 20460

Author: fxcoudert
Date: Thu May 11 21:39:06 2006
New Revision: 113713

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113713
Log:
        PR fortran/20460
        PR fortran/24549
        * parse.c (reject_statement): Clear gfc_new_block.
        * resolve.c (gfc_resolve_index): Make REAL array indices a
        GFC_STD_LEGACY feature.
        * gfortran.dg/error_recovery_1.f90: New test.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/error_recovery_1.f90
      - copied unchanged from r113671,
trunk/gcc/testsuite/gfortran.dg/error_recovery_1.f90
Modified:
    branches/gcc-4_1-branch/gcc/fortran/ChangeLog
    branches/gcc-4_1-branch/gcc/fortran/parse.c
    branches/gcc-4_1-branch/gcc/fortran/resolve.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[fxcoudert at gcc dot gnu dot org]

------- Comment #11 from fxcoudert at gcc dot gnu dot org  2006-05-11 21:40 -------
Fixed on mainline and 4.1


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.1.1                       |
      Known to work|4.2.0                       |4.2.0 4.1.1
         Resolution|                            |FIXED
            Summary|[4.1 only] Nasty extensions |Nasty extensions that should
                   |that should always warn     |always warn
   Target Milestone|---                         |4.1.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-03-30 18:57 -------
Subject: Re: [PR tree-optimization/20460] add phi args to dests of
	dce-redirected edges

On Wed, 2005-03-30 at 02:56 -0300, Alexandre Oliva wrote:
> When remove_dead_stmt() redirects a control stmt, the edge redirection
> reserves space for the phi arg for the new incoming edge in all phi
> nodes, but, instead of filling them in with information obtained from
> the edge redirection, we simply discard this information.  This leaves
> NULL in the phi args, which may cause crashes later on.
> 
> This patch fixes the problem by filling in the phi args using the
> PENDING_STMT list created during edge redirection.  This appears to be
> the intended use for this information, and it is used similarly in
> e.g. loop unrolling.
> 
> Bootstrapping mainline and 4.0 branch on amd64-linux-gnu, and mainline
> on i686-pc-linux-gnu.  Ok to install if bootstrap and regtesting pass?
> 
> The patch below is for the 4.0 branch, but it applies cleanly and
> correctly in mainline as well, since it's just a few lines off.


       /* Redirect the first edge out of BB to reach POST_DOM_BB.  */
       redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
-      PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+      flush_pending_stmts (EDGE_SUCC (bb, 0));



I'm having trouble seeing how this can be correct.

AFAICT this assumes that EDGE_SUCC (bb, 0)->dest before the redirection
has similar PHI as post_dom_bb and that the PHIs appear in the same
order in both blocks.  I'm not sure you can make that assumption.


This code is triggered rarely, I would expect it to be even rarer still
for POST_DOM_BB to have PHI nodes.  You could probably just ignore dead
control statements where the post dominator has PHI nodes and I doubt
it would ever be noticed.

Jeff



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[aoliva at redhat dot com]

------- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-30 05:56 -------
Subject: [PR tree-optimization/20460] add phi args to dests of dce-redirected edges

When remove_dead_stmt() redirects a control stmt, the edge redirection
reserves space for the phi arg for the new incoming edge in all phi
nodes, but, instead of filling them in with information obtained from
the edge redirection, we simply discard this information.  This leaves
NULL in the phi args, which may cause crashes later on.

This patch fixes the problem by filling in the phi args using the
PENDING_STMT list created during edge redirection.  This appears to be
the intended use for this information, and it is used similarly in
e.g. loop unrolling.

Bootstrapping mainline and 4.0 branch on amd64-linux-gnu, and mainline
on i686-pc-linux-gnu.  Ok to install if bootstrap and regtesting pass?

The patch below is for the 4.0 branch, but it applies cleanly and
correctly in mainline as well, since it's just a few lines off.

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	PR tree-optimization/20460
	* tree-ssa-dce.c (remove_dead_stmt): Add phi args to phi nodes
	affected by an edge redirection.

Index: gcc/tree-ssa-dce.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-dce.c,v
retrieving revision 2.32
diff -u -p -r2.32 tree-ssa-dce.c
--- gcc/tree-ssa-dce.c 17 Feb 2005 16:19:44 -0000 2.32
+++ gcc/tree-ssa-dce.c 30 Mar 2005 05:28:09 -0000
@@ -810,7 +810,7 @@ remove_dead_stmt (block_stmt_iterator *i
 
       /* Redirect the first edge out of BB to reach POST_DOM_BB.  */
       redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
-      PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+      flush_pending_stmts (EDGE_SUCC (bb, 0));
       EDGE_SUCC (bb, 0)->probability = REG_BR_PROB_BASE;
       EDGE_SUCC (bb, 0)->count = bb->count;
 
Index: gcc/testsuite/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	PR tree-optimization/20640
	* gcc.dg/torture/tree-loop-1.c: New.

Index: gcc/testsuite/gcc.dg/torture/tree-loop-1.c
===================================================================
RCS file: gcc/testsuite/gcc.dg/torture/tree-loop-1.c
diff -N gcc/testsuite/gcc.dg/torture/tree-loop-1.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/gcc.dg/torture/tree-loop-1.c 30 Mar 2005 05:28:22 -0000
@@ -0,0 +1,21 @@
+/* PR tree-optimization/20640 */
+
+/* After unrolling the loop, we'd turn some conditional branches into
+   unconditional ones, but branch redirection would fail to compute
+   the PHI args for the PHI nodes in the replacement edge
+   destination, so they'd remain NULL causing crashes later on.  */
+
+/* { dg-do compile } */
+
+static int a = 0;
+extern int foo (void);
+extern int *bar (void) __attribute__ ((__const__));
+
+void
+test (int x)
+{
+  int b = 10;
+  while (foo () == -1 && *bar () == 4 && b > 0)
+    --b;
+  a = x;
+}

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-03-14 10:56 -------
Ok, thanks for clarifying.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-03-14 06:34 -------
While I can agree that REAL DO loop indices should cause a warning, 
it is incorrect to call this feature an extension to the language.
Fortran 77 permitted such indices.  Fortran 90 declared them to
be obsolescent, which means the feature was permitted.  Fortran 95
finally deleted them.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460

[Bug fortran/20460] Nasty extensions that should always warn

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-13 18:44 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-13 18:44:38
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460