--- 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 h
--- 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 t
--- 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
--- 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 te
--- 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 te
--- 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 le
--- 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
--- 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
--- 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 firs
--- 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
--- 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 al
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d at domob dot eu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
--- 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 i
--- 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; t
--- 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
--- 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
--- 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
--- 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.
--- 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 a
--- 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
--- 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 construct
--- 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
--- 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 ad
23 matches
Mail list logo