Juan Rodriguez-Carvajal reported at http://gcc.gnu.org/ml/fortran/2010-07/msg00057.html that compiling the following program ICEs with: f951.exe: internal compiler error: in output_constructor_regular_field, at varasm.c:4996 It works with GCC 4.5 and might be due to the constructor reorganization. Module CFML_String_Utilities implicit none private Type, Public :: Err_Text_Type integer :: nlines character (len=132), dimension(5) :: txt End Type Err_Text_Type Type (Err_Text_Type), public :: Mess_FindFMT = & Err_Text_Type(0, (/" "," "," "," "," "/)) End Module CFML_String_Utilities
I won't be able to start a regression hunt until this week-end.
(In reply to comment #1) > I won't be able to start a regression hunt until this week-end. Working: 2010-04-10-r158177 Failing: 2010-04-13-r158277 The array constructor work was merged as Rev. 158253 - thus, as written, I think it might be due to that check in: http://gcc.gnu.org/viewcvs?view=rev&revision=158253 Thus, the proper way is probably to find out what goes wrong rather than looking for the breaking patch ... By the way, I stumbled over PR 22210, which seems to be vaguely related (or obsoleted).
Reduced testcase: Type :: t character (len=32) :: txt(2) End Type Type (t) :: tt = t(/ " ", " " /)) print *, tt End Notes: * the vatiable 'tt' must be used, if not used only a warning is printed, no ICE * doing the same with INTEGER instead of CHARACTER works * explicitly assigning the txt component instead of using the structure constructor works
(In reply to comment #3) > Notes: > * the vatiable 'tt' must be used, if not used only a warning is printed, no > ICE > * doing the same with INTEGER instead of CHARACTER works > * explicitly assigning the txt component instead of using the structure > constructor works * if the string lengths of component and constructor match, then the compilation completes successfully as well I'd hazard the guess that some string length is not properly copied somewhere.
(In reply to comment #4) > I'd hazard the guess that some string length is not properly copied somewhere. Type :: t character (len=X) :: txt(2) End Type Type (t) :: tt = t((/ "12345", "67890" /)) print *, tt End compilation output X=3, 4.5 ok, but no truncation warning "123678" X=3, trunk ok, but no truncation warning "1236" <-- wrong X=5, 4.5 ok "1234567890" X=5, trunk ok "1234567890" X=7, 4.5 ok "1234567890" <-- wrong? X=7, trunk ICE In the last case, I'd expect the output "12345 67890 " - is 4.5 wrong here? Possibly related functions: resolve.c (resolve_structure_cons) array.c (gfc_resolve_character_array_constructor) decl.c (gfc_set_constant_character_len) Possibly related PR: PR42526
(In reply to comment #5) > compilation output > X=3, 4.5 ok, but no truncation warning "123678" The warning should be only printed with -Wcharacter-truncation (i.e. not by default), but I agree a warning would be nice. > X=7, 4.5 ok "1234567890" <-- wrong? As one sees from the output - the last characters are still uninitialized (i.e. '\0' as it is static variable): 0000000 3120 3332 3534 0000 3736 3938 0030 0a00 sp 1 2 3 4 5 nul nul 6 7 8 9 0 nul nul nl The issue is that the initializer is not space padded, i.e. (od -h -a) static struct t tt = {.txt={"12345", "67890"}}; should be static struct t tt = {.txt={"12345 ", "67890 "}}; For non-static initialization this works (GCC 4.5 and 4.6). > X=3, trunk ok, but no truncation warning "1236" <-- wrong Here, the dump looks as: static struct t tt = {.txt={"12345", "67890"}}; Thus, in case of 4.5 we forget to pad while for 4.6 we forget to pad and to truncate.
Different report, same problem: PR 45092
*** Bug 45092 has been marked as a duplicate of this bug. ***
Created attachment 21377 [details] Draft patch (for init-expr char constructors only) Some notes (all the following is about character strings): * The issue seems to be only initialization expressions (F2003 term; F2008: constant expressions) - for normal assignments the value seems to be correctly converted. * Scalars seem to be OK as well. * To handle are thus: Array constructors and array-valued PARAMETERs a) The attached patch handles structure constructors - including those which have elements which are PARAMETERs b) TODO: Using the following is valid but gives the same ICE than constructors with out the patch: character (len=5), parameter :: str(2) = [ "12345", "67890" ] Type (t) :: tt = t(str) c) ICE/Invalid: The following invalid code segfaults in check_constructor as "str" is not an initialization expression. (Not all constructors need to be, this one does): character (len=5) :: str(2) = [ "12345", "67890" ] Type (t) :: tt = t((/ str /)) d) One could consider warning about truncation (with -Wcharacter-truncation) - if the constructor contains literals which are too long - for parameters (also for those in constructors) the warning becomes useful.
(In reply to comment #9) b) TODO: Using the following is valid but gives the same ICE than constructors > with out the patch: s/than/as/ > d) One could consider warning about truncation (with -Wcharacter-truncation) - > if the constructor contains literals which are too long - for parameters (also > for those in constructors) the warning becomes useful. s/useful/less useful/
Created attachment 21380 [details] Better patch Fixed (b) by creating an array constructor - and fall through to the code for (a); fix (c) by adding a NULL check.
With the patch in comment #11 I get for the first tests of pr44857 and pr45092: f951: internal compiler error: in resolve_structure_cons, at fortran/resolve.c:931 These ICEs go away if I remove the lines + gfc_constructor *p = gfc_constructor_first (expr->value.constructor); + gcc_assert (cons->expr->ts.u.cl == p->expr->ts.u.cl); Further testing in progress.
Subject: Bug 44857 Author: burnus Date: Wed Aug 4 11:51:32 2010 New Revision: 162863 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162863 Log: 2010-08-04 Tobias Burnus <burnus@net-b.de> PR fortran/44857 * resolve.c (resolve_structure_cons): Fix handling of initialization structcture constructors with character elements of the wrong length. * array.c (gfc_check_iter_variable): Add NULL check. (gfc_resolve_character_array_constructor): Also truncate character length. 2010-08-04 Tobias Burnus <burnus@net-b.de> PR fortran/44857 * gfortran.dg/derived_constructor_char_1.f90: New. * gfortran.dg/derived_constructor_char_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/derived_constructor_char_1.f90 trunk/gcc/testsuite/gfortran.dg/derived_constructor_char_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
FIXED on the trunk (4.6). Thanks for the report!
Subject: Re: [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996 You're welcome. Thanks for your help. Norm ---- burnus at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: ============= ------- Comment #14 from burnus at gcc dot gnu dot org 2010-08-04 11:53 ------- FIXED on the trunk (4.6). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Subject: Bug 44857 Author: burnus Date: Wed Aug 4 18:49:23 2010 New Revision: 162871 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162871 Log: 2010-08-04 Tobias Burnus <burnus@net-b.de> PR fortran/45183 PR fortran/44857 * resolve.c (resolve_structure_cons): Fix freeing of charlen. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
Subject: Re: [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996 Hello, Your fix worked fine, and I am now again able to build my application. Thanks again. Yours truly, Norm Norman S. Clerman Consulting computer scientist ---- burnus at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: ============= ------- Comment #14 from burnus at gcc dot gnu dot org 2010-08-04 11:53 ------- FIXED on the trunk (4.6). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.