[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #5 from d at domob dot eu 2008-03-24 20:01 --- Created an attachment (id=15370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15370&action=view) Partly fixed patch This patch fixes the problem described above with respect to correct detection of seen_ts and adds some tests (hope this is ok); the string conversion problem is still failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #6 from d at domob dot eu 2008-03-25 12:44 --- After looking at the assembly dump, the problem with the strings seems to be that the literals are stored packed to each other in the data section and the array constructor simply lists the pointers to them and sets the length value to 7; thus, the shorter strings get the following character (that happens to be the first one of the next string) appended to them. Could we resolve this problem by keeping track for each string literal in which content it will accessed and padding them with spaces to the longest used length when dumping to the data section? Possibly when gfc_convert_expr is called on a string literal? BTW, is this a problem that affects other things also, for instance, user defined records? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #10 from d at domob dot eu 2008-03-25 16:40 --- (In reply to comment #7) > (In reply to comment #6) > > This string length change (and padding) needs to happen way earlier than that. > We should make it happen during the matching, when we convert the constructor > objects into the array constructor type. Hm, what about adding a case to gfc_resolve_character_array_constructor handling arrays *with* given length by padding all elements that are shorter? Would this work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #12 from d at domob dot eu 2008-03-25 17:10 --- (In reply to comment #11) > Sounds like the right place. Care should be taken because lengths are not > required to be constants, like in the following: > > call foo(8, "short") > call foo(2, "lenghty") > contains > subroutine foo(n,s) > character(len=*) s > integer n > print *, [ character(len=n) :: 'test', s ] > end subroutine > end Well, I'm not sure if the patch I've got in mind would handle this... I'm thinking of padding string literals shorter than the array's length at compile time when this length is constant. For non-constant lengths I suppose a runtime call would be needed to pad correctly? Is this important or should I first make constant lengths work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #13 from d at domob dot eu 2008-03-25 19:53 --- Created an attachment (id=15374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15374&action=view) Patch padding for constant character lengths This patch implements padding if the character length of the array is constant (it was much easier than I thought, and much less complicated than the solution I tried before--just know where...). It handles the original failure and also the test from comment #9 (if I understood correctly what the output should be), but it fails for the one in comment #11 with dynamic length. I did also add those two cases to the test suite, with the latter failing. This patch also provokes a failure of char_component_initializer_1.f90 of pr31487. Any hints why? -- d at domob dot eu changed: What|Removed |Added Attachment #15370|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #15 from d at domob dot eu 2008-04-01 08:12 --- The bootstrap problem is fixed, but with dynamic lengths I'm still struggling ;) However, the following program without typespec in the array constructor also fails (according to my judging what it should do) both with 4.3 and my (patched) SVN version; I don't have access to an unpatched one: PROGRAM test CALL foo (8, "short") CONTAINS SUBROUTINE foo (n, s) INTEGER :: n CHARACTER(len=*) :: s CHARACTER(len=n) :: arr(2) arr = (/ 'test', s /) WRITE (*,*) arr(1) WRITE (*,*) arr(2) WRITE (*,*) s WRITE (*,*) END SUBROUTINE foo END PROGRAM test Is this anouther bug or do I misinterpret something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #17 from d at domob dot eu 2008-04-01 12:53 --- I see, thanks! I thought it would be the longest length (i.e., clipped by the array definition assigned to). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #19 from d at domob dot eu 2008-04-04 20:27 --- Created an attachment (id=15429) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15429&action=view) Implements dynamic string length Finally, I managed to get dynamic string length working; however, this was more an experimentation thing for some parts. For instance, the generation of the tree-expression in gfc_trans_array_constructor was pure guessing and getting lucky, so I fear it is not quite done the right way; however, so far it works and I hope it is nearly correct now. This patch makes all my tests for constructor with typespec work, but it introduces two regression failures I'll still have to look at. And finally, I fear the style is yet to become perfect ;) -- d at domob dot eu changed: What|Removed |Added Attachment #15374|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #21 from d at domob dot eu 2008-04-06 15:28 --- Created an attachment (id=15435) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15435&action=view) Handles bounds checking and fixes regressions. This patch handles the bounds checking correctly, adds a test case if -std=f95 rejects array constructors with typespec, and fixes all regression failures, i.e., this makes the testsuite pass cleanly including all my own new test cases. However, I'm not quite sure about some things I did and if this is really the right way (although it seems to work), marked them mostly with XXX:. I'd be glad if someone could have a look at the patch and those places especially to see if all is ok or give comments how it should be done. And last but not least I'm not sure if I hit the right code style, I mostly doubt I did correctly insert the tab characters where they belong (as I'm used to indent with spaces only) ;) -- d at domob dot eu changed: What|Removed |Added Attachment #15429|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #23 from d at domob dot eu 2008-04-08 13:11 --- (In reply to comment #22) > > However, I'm not quite sure about some things I did [...] > > I think your patch is in a good enough shape to post it to [EMAIL PROTECTED] > and ask there for comments; this ensures that all gfortraners read it (and not > only three Fortraners) and it makes discussing easier than a in a bugreport. Ok, sent it in. > I think it is OK for now, but we need to fix it later. I found a test case > which crashes gfortran (ICE, internal compiler error) for nested character > constructors - even without typespec or bounds checks. See PR 35846. I think > this should be fixed together with the rest. I thought about possible solutions when introducing my global variable, namely either to pass them on the argument list down the stack (which is probably what I would do myself), or to abuse the function stack by saving the old value when setting and resetting it on return; while this seems a bit hackish to me, it means probably less changes... In any case, PR 35846 could be a nice other bug for me once this one is done ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #24 from d at domob dot eu 2008-04-11 20:26 --- (In reply to comment #23) > (In reply to comment #22) > > I think your patch is in a good enough shape to post it to [EMAIL PROTECTED] > > and ask there for comments; this ensures that all gfortraners read it (and > > not > > only three Fortraners) and it makes discussing easier than a in a bugreport. > > Ok, sent it in. Any news from the patch? Or is it usual to take some time to get responses? Hope it didn't get lost (or the responses in the gcc-patches volume on my machine...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/36112] New: Bounds-checking on character length not working for array-constructors
Bounds-checking for correct character length in array-constructors without
F2003 typespec (all strings are required to have the same length) does not work
sometimes, for instance the code
call test ("this is long")
contains
subroutine test(s)
character(len=*) :: s
character(len=128) :: arr(2)
arr = (/ s, "abc" /)
end subroutine test
end
Should give a runtime-error when compiled with "-fbounds-check" and run but it
doesn't; swapping the array constructor to be
arr = (/ "abc", s /)
does, however (which is presumably correct).
--
Summary: Bounds-checking on character length not working for
array-constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d at domob dot eu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #1 from d at domob dot eu 2008-05-03 13:31 --- Created an attachment (id=15568) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15568&action=view) Four test cases for character-array constructors This "patch" includes four test-cases that should all triger a bounds-checking runtime error for character-array-constructors (including the one given in the bug description); currently only one of them does this (also as written above). I'm not sure about the correct dejagnu-format and the expected error messages, but of course I'll adapt this during working on the patch if needed. Are the tests ok or do I misinterpret what the expected behaviour for them should be? Do you think we need more tests? Is there some thing despite character-arrays that could/should trigger a bounds-checking error, like values with different KIND parameters? Do we need succeeding test cases, maybe in combination with typespecs on array constructors (PR27997) when this is fixed? Thanks for the comments! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #2 from d at domob dot eu 2008-05-03 13:35 --- Just one more thought, for array-constructors with all constant strings/components with length known at compile-time we should maybe give a compiler error instead of a runtime-error? Or only a warning and no runtime-checking? I believe at least for those arrays at the moment gfc_resolve_char_array_constructor changes the string lengths so they all match which means this is because there's no runtime error (IIRC). If there should be an error, we could do it there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #3 from d at domob dot eu 2008-05-03 14:45 --- Created an attachment (id=15571) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15571&action=view) More tests and first code Four more test cases for different variations of character array constructors and a first draft implementation of the bounds-checking for all-known-length arrays; this however at the moment does not give a correct error message (locus, is given twice). I'm not familar with the error-reporting system yet, so any hints/comments how to fix this (if a compile-time error is even what we want here!). Now I'll look into the problem with constructors as in the bug report, and then we can put the patch in the right shape including the error message problem and such. -- d at domob dot eu changed: What|Removed |Added Attachment #15568|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #4 from d at domob dot eu 2008-05-03 18:26 ---
Now I've been analysing a test looking like:
test("abc", "foobar", "hello")
contains
subroutine test(r, s)
character(len=*) :: r, s
character(len=128) :: arr(2)
arr = (/ r, s /)
end subroutine test
end
Which does not trigger the bounds-error, too. It seems like the hidden
parameter _s (i.e. s's length) is used as the length of r for everything inside
the array constructor, that is for the bounds-checking runtime check (why it
does not trigger the error) and also for the memcpy call and related stuff.
So far I don't know why this is the case, but hopefully I'll find out later and
fix it... Of course I'd appreciate any hints ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/36112] Bounds-checking on character length not working for array-constructors
--- Comment #5 from d at domob dot eu 2008-05-04 11:23 --- Now I believe I found out where the problem might be; as far as I can tell, gfc_array_ctor_strlen in trans-array.c is the point where we determine the length of the elements of a character array constructor; in the loop over all elements, it seems that the output length is overwritten on each iteration, thus returning the length of the last element, as I reported above. I can't really tell how this value is used later and if this behaviour is correct and the error comes later, but breaking the loop there after the first iteration gives the correct result for the test-case I was looking at, so the problem might really be there. Any ideas/suggestions/comments on this? And now I'll probably really wait... :D -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug fortran/35846] ICE on nested character constructors
--- Comment #2 from d at domob dot eu 2008-05-20 07:33 --- Created an attachment (id=15655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15655&action=view) Hackish patch It seems the problem lies in gfc_conv_string_length, that can be called with a gfc_charlen whose length is NULL. This patch is somewhat a prove of concept of this, just creating a dummy length if it is NULL there; this prevents the ICEs described above. Of course this is surely not the correct place to do this initialization, I'll try to find it out later and work out a real patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug fortran/35846] ICE on nested character constructors
--- Comment #3 from d at domob dot eu 2008-05-21 15:06 --- Created an attachment (id=15663) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15663&action=view) Testcase without nested array constructors Actually, this does not depend on nested array constructors as this test-case proves (and also has nothing to do with the globals used for bounds-checking, it seems). I believe the problem is that the gfc_expr* corresponding to the concatenation doesn't have a cl->length set on its ts (because the arguments don't have one when resolution is called); this NULL later causes the ICE. When this expression turns up in an assignment, this does not matter as the expected length is known from the target's character length definition. But when there is no "expected" charlen (like in the nested constructor or in a function call as in this test) it is needed and the NULL pointer dereferenced. Hopefully I can soon come up with a real solution to this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug fortran/35846] ICE on nested character constructors
--- Comment #4 from d at domob dot eu 2008-05-21 15:06 --- Created an attachment (id=15664) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15664&action=view) Testcase without nested array constructors Actually, this does not depend on nested array constructors as this test-case proves (and also has nothing to do with the globals used for bounds-checking, it seems). I believe the problem is that the gfc_expr* corresponding to the concatenation doesn't have a cl->length set on its ts (because the arguments don't have one when resolution is called); this NULL later causes the ICE. When this expression turns up in an assignment, this does not matter as the expected length is known from the target's character length definition. But when there is no "expected" charlen (like in the nested constructor or in a function call as in this test) it is needed and the NULL pointer dereferenced. Hopefully I can soon come up with a real solution to this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #3 from d at domob dot eu 2008-06-13 17:04 --- Confirmed. I'll try to get this fixed! Might be funny, as I can't yet think of any reason why -std= should affect such a behaviour... But I also haven't looked at the code for this one deeper, so hopefully I'll find out soon! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug fortran/36517] Type-spec in array constructor: Invalid error for -std=f2003/f2008
--- Comment #4 from d at domob dot eu 2008-06-13 17:53 --- Created an attachment (id=15770) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15770&action=view) Probably obvious fix. Attached a simple fix by disabling this error if we are inside an array-constructor with typespec; the two tests above are included in the patch and work now. Regression-testing is just running, but I don't expect any errors there. If it succeeds, I'll submit the patch to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
[Bug fortran/36492] incorrect error when compiling
--- Comment #6 from d at domob dot eu 2008-06-13 20:36 --- Thanks for the additional hint, I'm into this. I've implemented some tests and am now working on integrating this fix with my pending patch for PR 36517. When the bogus error is fixed, I'll work on the ICE and hopefully we can fix PR 36517 and this one soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
