> > +
> > + num_args = gfc_intrinsic_argument_list_length (expr);
> > + args = XALLOCAVEC (tree, num_args);
> > +
> > + gfc_conv_intrinsic_function_args (se, expr, args, num_args);
> > +
> > + if (flag_coarray == GFC_FCOARRAY_LIB)
> > +{
> Can everything be put under the if?
> Does it work with -fcoarray=single?
IMO coarray=single should not generate code here, therefore putting
everything under the if should to fine.
Sorry for the comments ...
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
> >>
> >> The next patch will change the documentation related to the caf_get
> >> and caf_send functions and will add support for STAT= to the
> >> sendget function.
> >>
> >> In the meantime, is this patch OK for trunk?
> >>
> >
d regtests ok on x86_64-linux/F23.
Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
stat4cafsingle.clog
Description: Binary data
diff --git a/gcc/testsuite/gfortran.dg/coarray_stat_2.f90 b/gcc/testsuite/gfortran.dg/coarray_stat_2.f90
new file mode 10
Hi all,
committed the cosmetics patch as r238635.
Regards,
Andre
On Thu, 21 Jul 2016 14:57:32 +0200
Andre Vehreschild wrote:
> Hi all,
>
> the attached patch fixes some style issues in the caf code recently
> modified. Furthermore does it correct the function speci
t; On 21 July 2016 at 15:31, Andre Vehreschild wrote:
> > Hi all,
> >
> > the attached patch adds support for a stat parameter to caf_single's
> > caf_get() and caf_send() routines and adds a testcase.
> > Unfortunately is there not much that can go wrong in a caf_si
Hi all,
committed to gcc-6-branch as r238649, and
to gcc-5-branch as r238650.
Regards,
Andre
On Fri, 15 Jul 2016 11:29:37 +0200
Andre Vehreschild wrote:
> Hi Jerry,
>
> thanks for the fast review. Committed to trunk as r238368.
>
> Regards,
> Andre
>
>
trunk? And with one week delay for gcc-5- and -6-branch?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr70524_1.clog
Description: Binary data
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index e95c8dd..d52cd11 100644
--- a/gcc/fortran/trans
=
> --- gcc/testsuite/gfortran.dg/coarray_collectives_1.f90
> (revision 238665) +++
> gcc/testsuite/gfortran.dg/coarray_collectives_1.f90 (working
> copy) @@ -14,7 +14,7 @@ program test integer(8) :: i8
>character(len=19, kind=4) :: msg4
>
> - call co_sum("abc") ! { dg-error "must be a numeric type" }
> + call co_sum("abc") ! { dg-error "must have a numeric type" }
>call co_max(cmplx(1.0,0.0)) ! { dg-error "shall be of type
> integer, real or character" } call co_min(cmplx(0.0,1.0)) !
> { dg-error "shall be of type integer, real or character" }
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
le for fixing it as me.
Regards,
Andre
> Cheers
>
> Paul
>
> 2016-11-24 Andre Vehreschild
>
> PR fortran/78293
> * trans-expr.c (gfc_conv_procedure_call): Prepend deallocation
> of alloctable components to post, rather than adding to
> se
PING!
I know it's a lengthy patch, but comments would be nice anyway.
- Andre
On Tue, 22 Nov 2016 20:46:50 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch addresses the need of extending the API of the caf-libs to
> enable allocatable components asynch
Hi Jerry,
Tests with multiple images go into the opencoarrays testsuite. Still to push
though. The tests I have so far all pass.
- Andre
Am 30. November 2016 00:06:22 MEZ, schrieb Jerry DeLisle
:
>On 11/28/2016 10:33 AM, Andre Vehreschild wrote:
>> PING!
>>
>> I know it&#
enthusiasts will test it to bits before release!
>
> Regards
>
> Paul
>
>
> On 28 November 2016 at 19:33, Andre Vehreschild wrote:
> > PING!
> >
> > I know it's a lengthy patch, but comments would be nice anyway.
> >
> > - Andre
> >
&
tialized in this function
> [-Wmaybe-uninitialized]
>if (size == 0 || src_size == 0)
> ~^~~~
>
>
>
>
> 2016-11-30 14:30 GMT+01:00 Andre Vehreschild :
> > Hi Paul,
> >
> > thanks for the review. Committed with the changes reques
Hi all,
on IRC:
15:28:22 dominiq: vehre: add /* FALLTHROUGH */
Done and committed as obvious as r243023.
- Andre
On Wed, 30 Nov 2016 15:22:46 +0100
Andre Vehreschild wrote:
> Janus,
>
> those fallthroughs are fully intentional and each and everyone is documented.
> When you c
> /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2649:29: warning:
> >> > ‘src_size’ may be used uninitialized in this function
> >> > [-Wmaybe-uninitialized]
> >> >if (size == 0 || src_size == 0)
> >> > ~^~~~
Hi all,
and another aftermatch reported by Dominique. Fixing testcase
coarray_lib_alloc_4.f90 for 32-bit. Committed as obvious as r243101. Thanks for
reporting Dominique.
- Andre
On Wed, 30 Nov 2016 16:59:39 +0100
Andre Vehreschild wrote:
> Fixed -> r243034.
>
> - Andre
>
&
/= ["foo", "bar", "baz"])) call abort()
> >
> > write (*,*) any
> >
> > at the point of failure produces
> >
> > "foobarba"
> >
> > - David
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
ure that the handle of an allocatable component is
set to 0.
Bootstraped and regtested ok on x86_64-linux/F23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-02 Andre Vehreschild
* trans-arra
on x86_64-linux/F23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-02 Andre Vehreschild
PR fortran/78505
* trans-stmt.c (gfc_trans_allocate): Add sync all after the execution
of the whole allocate-st
as there is no
> carry involved. Note that the test compiles and executes with at least a
> clean trunk and 6.2.0.
>
> Cheers,
>
> Dominique
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-03 Andre Vehreschild
* trans-a
://gcc.gnu.org/ml/fortran/2016-11/msg00267.html
so they sled in with committing those changes and got a suitable Changelog-entry
while at it.
Thanks again for the review though.
- Andre
On Sat, 3 Dec 2016 09:05:23 -0800
Steve Kargl wrote:
> On Tue, Nov 22, 2016 at 06:56:16PM +0100, Andre Vehresch
course with appropriate Changelog-entry.
Regards,
Andre
On Sat, 3 Dec 2016 18:34:56 +0100
Dominique d'Humières wrote:
> > I also have addressed the ICEs with proc_pointer components.
>
> Confirmed, the patch LGTM.
>
> Thanks,
>
> Dominique
>
&g
e found that in this case "var" is
>the type node for one of the variables that it apparently is copying
>from the callee into the caller during the inlining.
>
>So I guess I'm asking how can it happen that the type node of a
>variable disappears?
>
>I have compare
c/work/libgomp/testsuite/libgomp.fortran/allocatable2.f90:46:0:
> internal compiler error: verify_gimple failed
>
> Dominique
>
> > Le 3 déc. 2016 à 19:51, Andre Vehreschild a écrit :
> >
> > Hi all,
> >
> > @Dominique: Thanks for checking. And also for po
f the patch. Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So it should
be applied.
Regards and thanks,
Andre
On Mon, 5 Dec 2016 19:02:32 +0100
Andre Vehreschild wrote:
> Hi Thomas,
>
> attached patch fixes the remaining open issu
frontend no longer
>>>uses this field.
>>>* trans-expr.c (gfc_map_intrinsic_function): Add a case to
>>>treat the LEN_TRIM intrinsic.
>>>
>>> 2016-12-07 Paul Thomas
>>>
>>>PR fortran/44265
>>>* gfortran.dg/char_result_14.f90: New test.
>>>* gfortran.dg/char_result_15.f90: New test.
>>>* gfortran.dg/char_result_16.f90: New test.
>>>* gfortran.dg/char_result_17.f90: New test.
>>>
>>>
>>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * ve...@gmx.de
anus
>
>
> 2016-12-08 Janus Weil
>
> PR fortran/61767
> * class.c (has_finalizer_component): Fix this function to detect only
> non-pointer non-allocatable components which have a finalizer.
>
> 2016-12-08 Janus Weil
>
> PR fortran/61
e: I will not commit before you are better and had the time to
test this.
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-08 Andre Vehreschild
PR fortran/78672
* data.c (create_character_initializer): Prevent accessing NULL-ptr.
Ping!
On Fri, 2 Dec 2016 13:28:40 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes on ICE, when freeing a scalar allocatable component in a
> derived typed coarray.
>
> Furthermore does it fix freeing of nested derived typed allocatable
> components. A
Ping!
On Fri, 2 Dec 2016 16:46:29 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch adds a call to sync_all after an ALLOCATE allocating a coarray.
> This is to adhere to standard wanting:
>
> ..., execution of the segment (11.6.2) following the statement is d
imension. So that
would at least access a NULL-pointer then.
From your follow-up mail:
> I remember now that rank can be negative, so your change is fine.
Well, that is not the reason the change is mandated: When the rank is 0 but a
corank is present, then the above still holds.
>
> >&& GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1) != NULL_TREE
> >&& VAR_P (GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1)))
> > {
>
> > diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
> > index 5ca716b..d953ec8 100644
> > --- a/gcc/fortran/trans-stmt.c
> > +++ b/gcc/fortran/trans-stmt.c
> > @@ -6464,7 +6464,8 @@ gfc_trans_deallocate (gfc_code *code)
> > && !(!last && expr->symtree->n.sym->attr.pointer))
> > {
> > if (is_coarray && expr->rank == 0
> > - && (!last || !last->u.c.component->attr.dimension))
> > + && (!last || !last->u.c.component->attr.dimension)
> > + && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr)))
> I’m a bit surprised by the need for this. Are there cases where coarrays
> don’t have a descriptor?
With my recently added support of allocatable components for coarrays of derived
types such an allocatable component can be a scalar. It is not a full coarray
because the coarray is one of its father objects.
I hope my comments helped a bit to shed some light why I propose these changes.
I am happy to get better solutions!
Improvements, comments and ideas are very welcome!!!
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Jerry,
thanks for the review. Committed as r243480.
Regards,
Andre
On Thu, 8 Dec 2016 12:10:55 -0800
Jerry DeLisle wrote:
> On 12/08/2016 05:42 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > On Fri, 2 Dec 2016 13:28:40 +0100
> > Andre Vehreschil
> 2016-12-08 Janus Weil
> >>
> >> PR fortran/61767
> >> * class.c (has_finalizer_component): Fix this function to detect only
> >> non-pointer non-allocatable components which have a finalizer.
> >>
> >> 2016-12-08 Janus Weil
> >>
> >> PR fortran/61767
> >> * gfortran.dg/finalize_31.f90: New test.
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Jerry,
thanks for the review. Committed as r243482.
Regards,
Andre
On Thu, 8 Dec 2016 12:12:02 -0800
Jerry DeLisle wrote:
> On 12/08/2016 05:43 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > On Fri, 2 Dec 2016 16:46:29 +0100
> > Andre Vehreschil
dre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-11 Andre Vehreschild
PR fortran/78672
* array.c (gfc_find_array_ref): Add flag to return NULL when no ref is
found instead of erroring out.
* data.c (gfc_assign_data_value): O
ics, as this is something that may need to be synchronized with
> > OpenCoarrays.
>
> Won’t that mean that coarray programs will fail due to ABI mismatch?
>
>
> FX
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi all,
I perceive that the git-mirror is lacking the commits of the last two days.
What did I miss? I have searched the gcc.gnu.org site already, but did not find
any reports.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
POINTER or REFERENCE.
Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-12 Andre Vehreschild
PR fortran/77785
* resolve.c (resolve_symbol): Correct attr lookup to
ready nearly done.
I just need to figure that what the state of regressions is with and without my
change.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
overed by any of
> your test cases? Since they are all compile-only, with errors being
> thrown at resolution stage, do they even get to the translation stage?
>
> Cheers,
> Janus
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Janne,
How about adding charlen_zero_node and one_node like the others have it to
prevent repeating ourselves?
- Andre
Am 12. Dezember 2016 20:39:38 MEZ, schrieb Janne Blomqvist
:
>On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild
>wrote:
>> Hi Janne,
>>
>> I fou
t is actually covered by any of
> >> your test cases? Since they are all compile-only, with errors being
> >> thrown at resolution stage, do they even get to the translation stage?
> >>
> >> Cheers,
> >> Janus
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
as well, but I wonder if it is actually covered by any of
> >> your test cases? Since they are all compile-only, with errors being
> >> thrown at resolution stage, do they even get to the translation stage?
> >>
> >> Cheers,
> >> Janus
> >
&
FERENCE.
> >> >> >
> >> >> > Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
> >> >>
> >> >> the resolve.c hunk is certainly ok. The trans-array.c part
Hi all,
attached patch fixes the issue by improving the check whether a call of the
caf-runtime-routines needs to be generated instead of a regular assignment.
Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc
>
> As for the patch - OK for trunk.
>
> Paul
>
> On 11 December 2016 at 14:01, Andre Vehreschild wrote:
> > Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all,
> >
> > thanks for all the input you gave on the patch I have present. I tried to
change bootstrapped and regtested fine on x86_64-linux/f23 therefore
committed as r243648.
Regards,
Andre
On Tue, 13 Dec 2016 10:52:08 -0800
Steve Kargl wrote:
> On Tue, Dec 13, 2016 at 07:32:33PM +0100, Andre Vehreschild wrote:
> >
> > attached patch fixes the issue b
e times. Exit early on bad class
> declarations to avoid ICE.
>
> 2016-12-15 Janus Weil
>
> PR fortran/78800
> * gfortran.dg/unlimited_polymorphic_27.f90: New test case.
--
Andre Vehreschild * Email: vehre ad gmx dot de
ven't found a way to do this in the front end.
Comments on these changes?
- Andre
On Tue, 13 Dec 2016 21:08:51 +0200
Janne Blomqvist wrote:
> On Mon, Dec 12, 2016 at 9:39 PM, Janne Blomqvist
> wrote:
> > On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild wrote:
> >> H
acter (len = 30), target :: x
> + character (len = 30), pointer :: s
> + s => foo (70_8)
> +contains
> + function foo (i)
> +integer (8) :: i
> +character (len = i), pointer :: foo
> +foo => x
> + end function foo
> +end program pr78757
>
> Jakub
--
Andre Vehreschild * Email: vehre ad gmx dot de
16, 2016 at 04:49:12PM +0100, Andre Vehreschild wrote:
> > the patch looks ok to me. I am wondering whether we should setup a routine
> > or a macro for doing such a DECL_EXPR like Fortran needs it. In your case
> > the TYPE_DECL is marked artificial and ignored in other cases not
ok on x86_64-linux/f23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite/ChangeLog:
2016-12-19 Andre Vehreschild
* gfortran.dg/class_assign_1.f08: New test.
gcc/fortran/ChangeLog:
2016-12-19 Andre Vehreschild
* tr
tested fine besides prior known
FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O1 (test for excess
errors)
on x86_64-linux/f23.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr78534_caf_v2.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/
On Tue, 20 Dec 2016 16:00:19 +0100
Jakub Jelinek wrote:
> On Tue, Dec 20, 2016 at 04:55:29PM +0200, Janne Blomqvist wrote:
> > On Tue, Dec 20, 2016 at 3:42 PM, Andre Vehreschild wrote:
> > > Hi all,
> > >
> > >> I think you should use bu
On Tue, 20 Dec 2016 16:40:13 +0100
Jakub Jelinek wrote:
> On Tue, Dec 20, 2016 at 04:29:07PM +0100, Andre Vehreschild wrote:
> > > The first one is GCC internal type for representing sizes, the latter is
> > > the C size_t (usually they have the same precision, they alway
w went to add the allocation into trans_class_assignment (). This allows
even more reuse of already present and needed data, e.g., the vptr.
Bootstrapped and regtested ok on x86_64-linux/f23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite/ChangeLo
ne
> +can get an error in the match. We bail out here and hope for
> +the best (the best being an error reported somewhere else). */
> + gfc_error ("Can not process after the IF statement shown at %C");
> + return MATCH_ERROR;
> +}
>
>m = gfc_match_pointer_assignment ();
>if (m == MATCH_YES)
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr69659 on trunk 7 and gcc-6-branch.
Ok for trunk and gcc-6?
Bootstrapped and regtested on x86_64-linux-gnu.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7be301d..403ce3a 100644
--- a/gcc/fortran
for trunk.
>
> Cheers
>
> Paul
>
> On 4 November 2016 at 01:57, Steve Kargl
> wrote:
> > On Thu, Nov 03, 2016 at 02:16:48PM +0100, Andre Vehreschild wrote:
> >>
> >> Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk?
> >>
> &
unk another obvious patch to fix an ICE on invalid code:
>
> https://gcc.gnu.org/viewcvs?rev=241993&root=gcc&view=rev
>
> Cheers,
> Janus
--
Andre Vehreschild * Email: vehre ad gmx dot de
20&root=gcc&view=rev
>
> Cheers,
> Janus
--
Andre Vehreschild * Email: vehre ad gmx dot de
giving full examples, I can only guess what you mean: The cases in the
> attachment are working as expected. Anything else?
That was what I've thought about. Thanks for testing that I am was mistaken.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
has a pointer to i
// and is valid for copying.
Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-11-15 Andre Vehreschild
PR fortran/78356
* class.c (gfc_i
a pointer
> >
> > temp = &src;
> > _vptr.copy(temp, &dst); // temp now points to memory that has a pointer to i
> > // and is valid for copying.
> >
> > Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?
>
> ok with me. Thanks
the wrong error messages in both gcc-7 and gcc-6.
Bootstraped and regtested on x86_64-linux/F23 for gcc-7 and -6. Ok for trunk
and gcc-6?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite/ChangeLog:
2016-11-18 Andre Vehreschild
PR for
ges in both gcc-7 and gcc-6.
> > Bootstraped and regtested on x86_64-linux/F23 for gcc-7 and -6. Ok for trunk
> > and gcc-6?
>
> Yes, looks good to me (at least for trunk; gcc-6 if you like).
>
> Thanks for the patch,
> Janus
--
Andre Vehreschild * Email: vehre ad gmx dot de
Whoops, hit send to fast. Here's the patch committed.
- Andre
On Sun, 20 Nov 2016 15:23:16 +0100
Andre Vehreschild wrote:
> Hi Janus,
>
> thanks for the review. Committed to trunk as r242637. Will wait one week
> before committing to 6.
>
> Regards,
> Andre
&
as its regtesting
has finished.
--
Andre Vehreschild * Email: vehre ad gmx dot de
cosmetics_4.clog
Description: Binary data
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 1708f7c..45e1369 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7855,9
rtran implements allocatable components in
derived coarrays nearly completely.
I know we are in stage 3. But the patch bootstraps and regtests ok on
x86_64-linux/F23. So, is it ok for trunk or shall it go to 7.2?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
libgfo
=
> > --- gcc/testsuite/gfortran.dg/pr78500.f90 (nonexistent)
> > +++ gcc/testsuite/gfortran.dg/pr78500.f90 (working copy)
> > @@ -0,0 +1,5 @@
> > +! { dg-do compile }
> > +class(t) function f() ! { dg-error "must be dummy, allocatable or
> > pointer" }
> > + f = 1 ! { dg-error "variable must not be polymorphic" }
> > +end
> > +
> >
> > --
> > Steve
--
Andre Vehreschild * Email: vehre ad gmx dot de
. Now the actual vtype is taken, i.e., the vptr component of
source='s object is taken. This is important when source references a
subclass.
Bootstrapped and regtested ok on x86_64-pc-linux-gnu/f23.
Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gcc dot gnu dot or
object is taken. This is important when source references a
> > subclass.
> >
> > Bootstrapped and regtested ok on x86_64-pc-linux-gnu/f23.
> >
> > Ok for trunk?
>
> The patch also solves the original problem.
>
> OK for trunk, and thanks a lot for the p
n/66082
> * trans-array.c (gfc_conv_array_parameter): Ensure that all
> non-variable arrays with allocatable components have the
> components deallocated after the procedure call.
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
I agree. Note that there is a test in the comment 3 of PR60255 that
> can be used to check the run time behavior (and possibly check the
> vtab issue).
>
> Dominique
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 0286c9e.
ng.
Regards,
Andre
> ifort compiles and runs it successfully and so I think that it would be
> nice if gfortran catches up on this one.
>
> Parenthetically, I wonder if this is not the time to implement PR53971...
> including responding to Mikael's comment?
>
> Anyway,
ore your patch for pr60255, it used to give a wrong length: 80 instead of
> 20 AFAICR).
>
> Note that the assert at fortran/class.c:236 is also triggered for pr61115.
>
> Thanks for working on these issues,
>
> Dominique
>
> >> On 8 December 2014 at 18:38, Andr
>
> > a.out(882,0x7fff75e1d310) malloc: *** error for object 0x7fc801c04978:
> > incorrect checksum for freed object - object was probably modified after
> > being freed. ...
> >
> > Dominique
>
>
>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel
Dear all,
sorry for the bad patch yesterday. Here is an update to that one. It fixes the
pr60289 is GNU-style checked, bootstraps and regtests ok on x86_64-linux-gnu.
Comments welcome.
Regards,
Andre
On Sat, 20 Dec 2014 16:38:23 +0100
Andre Vehreschild wrote:
> Dear all,
>
&g
Hi all,
during gfortran hacking I found a displaced comment and an indentation mistake.
Just to make sure those don't get mangled in my other patches, I submit them
here.
- Andre
gcc/fortran/ChangeLog:
2014-12-28 Andre Vehreschild
* trans-decl.c (gfc_finish_var_decl):
m the module to its place of use, which I adapted
to fully fix pr60357.
Regards,
Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
pr60255_5.clog
Description: Binary data
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 51
00130.html
Regards,
Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
pr60289_5.clog
Description: Binary data
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 05a948b..6038dd5 100644
--- a/gcc/fortran/resolve.c
should delay the fix of pr60255.
>
> Cheers,
>
> Dominique
>
> > Le 29 déc. 2014 à 11:07, Andre Vehreschild a écrit :
> >
> > Hi all,
> >
> > attached is the patch and changelog for fixing pr60255. All comments I
> > received have been integr
e
On Tue, 30 Dec 2014 16:35:48 +0100
Dominique d'Humières wrote:
> The new patch fixes the ICEs, but still emit the wrong codes reported in
> pr61337.
>
> Thanks and Happy New Year to all,
>
> Dominique
>
> > Le 30 déc. 2014 à 14:39, Andre Vehreschild a écrit :
&
ères wrote:
> >
> >> The new patch fixes the ICEs, but still emit the wrong codes reported in
> >> pr61337.
> >>
> >> Thanks and Happy New Year to all,
> >>
> >> Dominique
> >>
> >> > Le 30 déc. 2014 à 14:39, Andre V
when needed make it explicit
> > again in a future patch?
>
> I leave that up to you. In principle I'm fine with keeping it as it
> is. The only problem I see is that the function name sounds rather
> general, but it apparently expects the expression to be an ASSOCIATE
>
lem I see is that the function name sounds rather
> >> general, but it apparently expects the expression to be an ASSOCIATE
> >> symbol.
> >
> > I am nearly finished with the patch on allocatable scalar components and I
> > don't need the code there. Therefore I
an issue. Your patch
> correctly deals with it IMHO.
>
> Subject to the above change in the value of _len, I think that your
> patch is OK for trunk.
>
> With best regards
>
> Paul
>
> On 4 January 2015 at 13:40, Andre Vehreschild wrote:
> > Hi Janus, hi Pau
small functions the compiler will hold
all parameters in registers for a significant level of optimization, all the
overhead of memory access (I hope :-).
Bootstraps and regtests ok on x86_64-linux-gnu.
- Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Emai
have commit rights yet. If not, I will get to it sometime this
> week.
>
> Thanks for the patch.
>
> Paul
>
> On 10 January 2015 at 15:59, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch fixes the bug reported in pr 60334. The issue here was th
have a session of doing some commits later this week and will do
> this patch at that time.
>
> Cheers
>
> Paul
>
> On 11 January 2015 at 16:21, Andre Vehreschild wrote:
> > Hi Paul,
> >
> > thanks for the review. I do not have commits rights.
> >
&
Hi,
is this patch commited now? I don't have the rights to do so myself.
- Andre
On Sun, 28 Dec 2014 17:17:50 +0100
FX wrote:
>
> > 2014-12-28 Andre Vehreschild
> >
> >* trans-decl.c (gfc_finish_var_decl): Fixed displaced comment.
> >* trans-st
Hi,
please don't commit this patch yet. I am seeing non-explainable ICEs and wrong
code now. Just have to investigate.
- Andre
On Tue, 13 Jan 2015 12:42:13 +0100 Andre Vehreschild wrote:
> Hi Paul,
>
> thanks for the reviewed and the valued comments.
>
> Just for
ast/fold_convert(),
> for by ref not; however, there isn't one as INDIRECT_REF_P is the outermost
> operator.]
>
> Tobias
>
> PS: I haven't looked closer at the rest of the patch.
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
e.c: two line comment, one line actual code
- Testcase in gcc/testsuite/fortran.dg/unlimited_polymorphism_18.f90
Regards,
Andre
--
Andre Vehreschild
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c33936b..cb01a13 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
also be nice to indicate that not only the testcase
> doesn’t crash the compiler any more, but to confirm that it now generates the
> correct code (i.e. that we don’t turn an ice-on-valid bug into a wrong-code
> bug!).
>
> Cheers,
> FX
>
--
Andre Vehreschild * Kreuzherrenst
Hi all,
this patch somehow slipped my attention. Anyone for a review? Third time ping!
Rebased to current mainline.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Wed, 18 Sep 2024 12:30:23 +0200
Andre Vehreschild wrote:
> Hi all,
>
> bac
Ping ^ 4.
Really no one to review this 160 something patch?
Regtests ok on x86_64-pc-linux-gnu /Fedora 39? Ok for mainline?
- Andre
On Mon, 7 Oct 2024 12:52:29 +0200
Andre Vehreschild wrote:
> Hi all,
>
> this patch somehow slipped my attention. Anyone for a review? Third
ht be doing something wrong here, so please be patient and explain, what I
miss.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
patch or my
> shortened version.
>
> Thanks for the patch!
>
> Harald
>
>
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Is this ok?
> >
> > Regards and thanks for the review,
> > Andre
> >
> > On Tue, 1 Oct 2024 23:31:11 +0200
> >
es here and there,
> > see
> > commit log and source code for details.
> >
> > Code comments? Suggestions or remarks? - Before I apply this patch?
> >
> > Tobias
> >
> > PS: I am aware that C++ support is lacking. There is a pending patch
> > that needs
> > to be updated for this patch, probably some bitrotting, and in
> > particular for the
> > review comments, cf.
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633782.html
> > and https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639929.html
--
Andre Vehreschild * Email: vehre ad gmx dot de
401 - 500 of 686 matches
Mail list logo
