As far as I can tell, the problem in 62242 (and possibly 62246) is with a
string array constructor trying to deal with an array element whose value is a
character function that is described in an interface block and which has an
assumed-length result. I can't claim more than a superficial under
The problem is with substrings of allocatable string components of derived
types. The code seems to be trying to get the string length from typespec of
the derived type variable instead of from the component.
The attached patch gets the component typespec from the reference chain.
I don't unde
s.
Index: ChangeLog
===
--- ChangeLog (revision 226452)
+++ ChangeLog (working copy)
@@ -1877,6 +1877,13 @@
* interface.c (is_procptr_result): New function to check if an
expression is a procedure-pointer result.
(compare_actual_formal): Use it.
+
+2015_07_31 Louis Krup
hemselves. The textual part of your comment is
>perfectly clear.
>
>Many thanks for the patch.
>
>Paul
>
>PS Do you now have all the paperwork to commit the patch yourself?
>
>On 29 September 2015 at 09:36, Louis Krupp wrote:
>> Paul,
>>
>>
I have just added myself.
Index: ChangeLog
===
--- ChangeLog (revision 228379)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2015-10-02 Louis Krupp
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
2015-09-20 Kai
Revision 228368...
Louis
I'm ready to check it in.
Louis
On Sat, 03 Oct 2015 07:00:56 -0700 Dominique
d'Humières wrote
> AFAICT this patch has been approved by FX at
> https://gcc.gnu.org/ml/fortran/2015-07/msg00168.html. Any reason to not
> commit it?
>
> Dominique
>
>
Revision 228551...
Louis
The problem involves a derived type with a character component declared
CHARACTER(NULL()) or CHARACTER(NULL(n)), where mold argument n is an integer
pointer.
I might be missing something, but I'm not sure there's a point to having a
character variable whose length is the target of a null pointe
On Mon, 12 Oct 2015 08:41:43 -0700 Steve
Kargl wrote
> On Sun, Oct 11, 2015 at 10:18:48PM -0700, Louis Krupp wrote:
> > The problem involves a derived type with a character component declared
> > CHARACTER(NULL()) or CHARACTER(NULL(n)), where mold argument n is a
The problem: Statement labels within a type declaration are put in the
statement label tree belonging to the type declaration's namespace's (instead
of the current namespace). When the line is otherwise empty and an error is
issued, gfc_free_st_label tries to delete the label from the label tr
===
--- gcc/fortran/ChangeLog (revision 229307)
+++ gcc/fortran/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2015-10-26 Louis Krupp
+
+ PR fortran/66056
+ * fortran.h: Include namespace pointer in statement label
+ structure.
+ * symbol.c (gfc_get_st_label): Store
Revision 229390...
Louis
Fixed in revision 256011.
Fixed in revision 256720.
Fixed in revision 244601.
hu, 19 Jan 2017 04:52:54 -0800 Christophe Lyon wrote
>Hi,
>
>
>On 18 January 2017 at 22:45, Louis Krupp wrote:
>> Fixed in revision 244601.
>>
>
>I've noticed a new failure on arm/aarch64:
> compiler driver --help=fortran option(s): "^
Fixed in revision 240168.
Fixed in revision 240219.
Two possibilities:
1. malloc() doesn't silently return NULL on Darwin when it runs out of memory;
it always generates an error message.
2. setrlimit() doesn't work the same on Darwin as it does on Linux, and the
test program is hitting a system limit. It so happens that when I first looked
a
least one system, we can call
! it good.
Louis
On Mon, 19 Sep 2016 02:35:21 -0700 Christophe Lyon
wrote
> Hi,
>
>
> On 18 September 2016 at 21:19, Louis Krupp wrote:
> > Two possibilities:
> >
> > 1. malloc() doesn't silently
Fixed in revision 240341.
cc list as far as
I know.)
Louis Krupp
My target was gfortran.
In any case, someone else fixed this problem.
Louis
On Thu, 29 Sep 2016 11:10:15 -0700 Jeff Law wrote
> On 09/22/2016 04:52 PM, Louis Krupp wrote:
> > As of revision 240383 , i386.c isn't compiling. The errors are:
> >
>
Fixed in revision 240797.
Dominique,
Vous avez raison. I attached the wrong patch. I've resent the message with
the correct patch.
I tried to make pr69955.f90 run only on 64-bit Linux:
! { dg-do run { target x86_64-*-linux* } }
I'm not sure there's a portable way to query virtual memory usage, and testing
this on on
I've attached an updated patch for pr69955. It works just as you said.
Please let me know if this or my patch for pr57910 is OK to check in.
Louis
On Thu, 06 Oct 2016 14:30:29 -0700 Dominique d'Humières
wrote
>
> > Le 6 oct. 2016 à 19:35, L
Fixed in revision 240850.
Fixed in revision 240851.
===
--- gcc/fortran/ChangeLog (revision 227571)
+++ gcc/fortran/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2015-09-08 Louis Krupp
+
+ PR fortran/62242
+ * trans-array.c (get_array_ctor_all_strlen): Don't store length
+ tree po
Would anyone like me to spend some more time on this and perhaps clear up some
of the TODO items?
(Unlike some of you, I'm retired. I have time for this.)
Louis
== == == == == == Forwarded message == == == == == ==
>From : Louis Krupp
To : "gcc-patches","fortran"
> > I would not be surprised if there were a better way to do this.
> >
> > When I tweak gfc_trans_forall_1() to force usage of a temporary
> > for all assignments, all tests pass with the exception
> > of forall_8.f90, and the whole point of that test is making
> > sure that this particular forall *doesn't* use a temporary.
> >
> > Louis Krupp
>
>
>
32 matches
Mail list logo
