public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
@ 2014-01-14 14:24 mrestelli at gmail dot com
2014-01-14 19:57 ` [Bug fortran/59806] " anlauf at gmx dot de
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: mrestelli at gmail dot com @ 2014-01-14 14:24 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/59806] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
2014-01-14 14:24 [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure mrestelli at gmail dot com
@ 2014-01-14 19:57 ` anlauf at gmx dot de
2014-01-16 21:33 ` [Bug fortran/59806] [4.9 Regression] " dominiq at lps dot ens.fr
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: anlauf at gmx dot de @ 2014-01-14 19:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806
Harald Anlauf <anlauf at gmx dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gmx dot de
--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> ---
Possibly related to or duplicate of PR 59440.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/59806] [4.9 Regression] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
2014-01-14 14:24 [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure mrestelli at gmail dot com
2014-01-14 19:57 ` [Bug fortran/59806] " anlauf at gmx dot de
@ 2014-01-16 21:33 ` dominiq at lps dot ens.fr
2014-01-17 19:29 ` dominiq at lps dot ens.fr
2014-01-17 19:52 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-01-16 21:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-01-16
Known to work| |4.8.2
Summary|ICE with -ggdb AND |[4.9 Regression] ICE with
|-finit-real=snan AND |-ggdb AND -finit-real=snan
|namelist variable AND |AND namelist variable AND
|internal procedure |internal procedure
Ever confirmed|0 |1
Known to fail| |4.9.0
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Possibly related to or duplicate of PR 59440.
Probably related, but at r206648 the test compiles with -g, but adding
-finit-real=* to -g triggers the ICE.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/59806] [4.9 Regression] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
2014-01-14 14:24 [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure mrestelli at gmail dot com
2014-01-14 19:57 ` [Bug fortran/59806] " anlauf at gmx dot de
2014-01-16 21:33 ` [Bug fortran/59806] [4.9 Regression] " dominiq at lps dot ens.fr
@ 2014-01-17 19:29 ` dominiq at lps dot ens.fr
2014-01-17 19:52 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-01-17 19:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
AFAICT this PR is fixed by r206711.
Jakub, do want to add the test in comment 0 (with -g -finit-real=snan) to the
test suite? If not, I think this PR can be closed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/59806] [4.9 Regression] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
2014-01-14 14:24 [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure mrestelli at gmail dot com
` (2 preceding siblings ...)
2014-01-17 19:29 ` dominiq at lps dot ens.fr
@ 2014-01-17 19:52 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-17 19:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I would say this doesn't add anything on top of the 3 committed testcases.
*** This bug has been marked as a duplicate of bug 59440 ***
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-17 19:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-14 14:24 [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure mrestelli at gmail dot com
2014-01-14 19:57 ` [Bug fortran/59806] " anlauf at gmx dot de
2014-01-16 21:33 ` [Bug fortran/59806] [4.9 Regression] " dominiq at lps dot ens.fr
2014-01-17 19:29 ` dominiq at lps dot ens.fr
2014-01-17 19:52 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).