[Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure

["mrestelli at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 59806
           Summary: ICE with -ggdb AND -finit-real=snan AND namelist
                    variable AND internal procedure
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mrestelli at gmail dot com

Hi all,
   the attached code results in an internal compiler error when
compiled with

gfortran -ggdb -finit-real=snan -c ice.f90

Removing -ggdb and/or -finit-real=snan the code compiles correctly.
Also, removing the namelist containing xx the problem disappears.

(Sorry for the long "summary", could't find a shorter one).

$ gfortran --version
GNU Fortran (GCC) 4.9.0 20140110 (experimental)


$ gfortran -ggdb -finit-real=snan -c ice.f90 
ice.f90: In function ‘prog’:
ice.f90:5:0: internal compiler error: in force_decl_die, at dwarf2out.c:20111
  real :: xx
 ^
0x704d34 force_decl_die
    gcc/dwarf2out.c:20111
0x705207 gen_namelist_decl
    gcc/dwarf2out.c:20632
0x700fd3 gen_decl_die
    gcc/dwarf2out.c:20435
0x71314f decls_for_scope
    gcc/dwarf2out.c:19969
0x6fe0ea gen_subprogram_die
    gcc/dwarf2out.c:18354
0x701014 gen_decl_die
    gcc/dwarf2out.c:20336
0x701df8 dwarf2out_function_decl
    gcc/dwarf2out.c:20776
0x75289c rest_of_handle_final
    gcc/final.c:4469
0x75289c execute
    gcc/final.c:4513




program prog

 implicit none

 real :: xx
 character(len=100) :: message

 ! removing the following line the problem disappears
 namelist /input/ xx

contains

 subroutine check()
  write(message,'(e8.2)') xx
 end subroutine check

end program prog
>From gcc-bugs-return-440325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 14:34:37 2014
Return-Path: <gcc-bugs-return-440325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9354 invoked by alias); 14 Jan 2014 14:34:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9300 invoked by uid 55); 14 Jan 2014 14:34:29 -0000
From: "nmm1 at cam dot ac.uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
Date: Tue, 14 Jan 2014 14:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nmm1 at cam dot ac.uk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-34678-4-268UFDtrEr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-34678-4@http.gcc.gnu.org/bugzilla/>
References: <bug-34678-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01467.txt.bz2
Content-length: 1670

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

--- Comment #25 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
On Jan 10 2014, vincent-gcc at vinc17 dot net wrote:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
>
>--- Comment #24 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> -
>
>(In reply to Nick Maclaren from comment #23)
>
>> If __STDC_IEC_559__ is unset or does not have the value 1, setting
>> STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and
>> Annex F), unless the implementation explicitly chooses to extend the
>> language to support it.
>
>You're wrong. The C standard doesn't say that.

I am sorry, but it is you that is wrong.

>6.10.8.3 says: "__STDC_IEC_559__ The integer constant 1, intended to indica
>te
>conformance to the specifications in annex F (IEC 60559 floating-point
>arithmetic)." and nothing about STDC FENV_ACCESS.

3.4.3 says:
    undefined behavior
    behavior, upon use of a nonportable or erroneous program construct
    or of erroneous data, for which this International Standard imposes
    no requirements

4. Conformance, paragraph 2, says:
    ...  Undefined behavior is otherwise indicated in this International
    Standard by the words "undefined behavior" or by the omission of any
    explicit definition of behavior.  There is no difference in emphasis
    among these three; they all describe "behavior that is undefined".

What "explicit definition of behavior" is there for the case when
STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one?

As there is none, it is undefined behaviour.  gcc can therefore do
whatever it likes.


Regards,
Nick Maclaren.
>From gcc-bugs-return-440327-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 14:39:50 2014
Return-Path: <gcc-bugs-return-440327-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16634 invoked by alias); 14 Jan 2014 14:39:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16304 invoked by uid 48); 14 Jan 2014 14:39:45 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/38518] Excessive compile time with -O3
Date: Tue, 14 Jan 2014 14:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.4.0
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-38518-4-r1kcDGMxh7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-38518-4@http.gcc.gnu.org/bugzilla/>
References: <bug-38518-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01469.txt.bz2
Content-length: 2613

http://gcc.gnu.org/bugzilla/show_bug.cgi?id8518

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevenb.gcc at gmail dot com

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue here is the DF machinery, or rather the fact that RTL invariant
motion
calls df_analyze () for each loop, thus

void
move_loop_invariants (void)
{
  struct loop *loop;

  if (flag_ira_loop_pressure)
    {
      df_analyze ();
      regstat_init_n_sets_and_refs ();
      ira_set_pseudo_classes (true, dump_file);
      calculate_loop_reg_pressure ();
      regstat_free_n_sets_and_refs ();
    }
  df_set_flags (DF_EQ_NOTES + DF_DEFER_INSN_RESCAN);
  /* Process the loops, innermost first.  */
  FOR_EACH_LOOP (loop, LI_FROM_INNERMOST)
    {
      curr_loop = loop;
      /* move_single_loop_invariants for very large loops
         is time consuming and might need a lot of memory.  */
      if (loop->num_nodes <= (unsigned) LOOP_INVARIANT_MAX_BBS_IN_LOOP)
        move_single_loop_invariants (loop);
    }

here move_single_loop_invariants -> find_invariants -> find_defs which
does

static void
find_defs (struct loop *loop, basic_block *body)
{
  unsigned i;
  bitmap blocks = BITMAP_ALLOC (NULL);

  for (i = 0; i < loop->num_nodes; i++)
    bitmap_set_bit (blocks, body[i]->index);

  if (dump_file)
    {
      fprintf (dump_file,
               "*****starting processing of loop %d ******\n",
               loop->num);
    }

  df_remove_problem (df_chain);
  df_process_deferred_rescans ();
  df_chain_add_problem (DF_UD_CHAIN);
  df_set_blocks (blocks);
  df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
  df_analyze ();
...

which is excessive.  It looks like the above DF stuff does not affects the
whole
function but only the BBs in the loop.  Still the fact that we iterate
from inner to outer loops still
makes the DF analysis time quadratic in the loop depth.

The testcase has only loops of depth 1 (but 2164 ones), so it seems that
the DF restriction to a set of BBs does not work as expected?

>From the profile I see that the most time spent in df_analyze is
inverted_post_order_compute and post_order_compute (obviosly not
region aware!) and then bitmap_set_bit and df_prune_to_subcfg.

I wonder if it isn't possible to either update the DF during the
transform, deal with partly out-of-date DF info (like process
loop siblings without re-calculating DF, and re-compute whole FN
DF after such iteration).