TREE_CODE (expr) == REALPART_EXPR)
> > {
> > @@ -1170,6 +1186,7 @@ build_access_from_expr_1 (tree expr, gimple *stmt,
> > bool write) case COMPONENT_REF:
> > case ARRAY_REF:
> > case ARRAY_RANGE_REF:
> > +case BIT_FIELD_REF:
> >ret = create_access (expr, stmt, write);
> >break;
> >
> > @@ -1549,6 +1566,7 @@ make_fancy_name_1 (tree expr)
> >obstack_grow (_obstack, buffer, strlen (buffer));
> >break;
> >
> > +case BIT_FIELD_REF:
> > case ADDR_EXPR:
> >make_fancy_name_1 (TREE_OPERAND (expr, 0));
> >break;
> > @@ -1564,7 +1582,6 @@ make_fancy_name_1 (tree expr)
> > }
> >break;
> >
> > -case BIT_FIELD_REF:
> > case REALPART_EXPR:
> > case IMAGPART_EXPR:
> >gcc_unreachable (); /* we treat these as scalars. */
> > @@ -3769,7 +3786,8 @@ sra_modify_expr (tree *expr, gimple_stmt_iterator
> > *gsi, bool write) tree type, bfr, orig_expr;
> >bool partial_cplx_access = false;
> >
> > - if (TREE_CODE (*expr) == BIT_FIELD_REF)
> > + if (TREE_CODE (*expr) == BIT_FIELD_REF
> > + && (write || !sra_handled_bf_read_p (*expr)))
> > {
> >bfr = *expr;
> >expr = _OPERAND (*expr, 0);
> >
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
in the beginning. I must have done something wrong.
Please accept my apologies and regards,
Andre
On Fri, 29 Sep 2023 15:13:56 +0200
Andre Vehreschild via Fortran wrote:
> Hi Paul,
>
> thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c
> and backport
ed - it's fine for trunk and, I would suggest, 13-branch.
>
> Cheers
>
> Paul
>
> On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote:
> >
> > Hi Paul,
> >
> > thanks for the quick review. I've added a testcase with a module and a
> &g
dre,
>
> The patch looks fine to me. Since you mention it in the comment, is it
> worth declaring the derived type 'foo' in a module and giving it a
> final routine?
>
> Thanks for the patch.
>
> Paul
>
> On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran
> wro
inside the derived type
into the block guard by its allocated check.
Regtested ok on f37/x86_64. Ok for master?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e0fc8ebc46b..8e94a9a469f 100644
--- a/gcc
gfc_free_expr (tmp);
> tmp = gfc_copy_expr (*newp);
> }
>
> or rather
>
>if (inquiry->next)
> gfc_replace_expr (tmp, *newp);
>
> at least shrinks the leak a bit. (Untested otherwise).
>
> OK with one of the above changes (provided it survives regtest
7 gfc_parse_file()
> ../../gcc-trunk/gcc/fortran/parse.cc:7235
> 0xa40a1f gfc_be_parse_file
> ../../gcc-trunk/gcc/fortran/f95-lang.cc:229
>
> The fortran-dump confirms that n is not simplified to a constant.
> So while you're at it, do you also see a solution to this variant
Hi Harald,
I do get why this happens. I still don't get why I have to do this
'optimization' manually. I mean, this rewriting of expressions is needed in
more than one location and most probably already present somewhere. So who
can point me in the right direction?
Regards,
Andre
Andre
-linux-gnu/Fedora 37.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
* expr.cc (gfc_match_init_expr): Prevent PDT analysis for function
calls.
* simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt
component
Hi everyone,
sorry for missing out on the gcc-11 backport, but better late than never.
Committed backport as ae57aae60d1.
Regards,
Andre
On Wed, 23 Jun 2021 11:21:45 +0200
Tobias Burnus wrote:
> On 23.06.21 10:23, Andre Vehreschild wrote:
>
> > Will wait two weeks fo
Hi all,
two weeks have passed with no complains about the patch for PR103970. Therefore
backported and pushed to gcc-11 as 680ee9c3332.
Regards,
Andre
On Fri, 28 Jan 2022 12:39:17 +0100
Andre Vehreschild wrote:
> Hi Tobias,
>
> I don't know why that bootstrapped initially
with submit
26e237fb5b8.
Thanks for pointing this out.
Regards,
Andre
On Fri, 28 Jan 2022 10:36:23 +0100
Andre Vehreschild via Fortran wrote:
> Hi Tobias,
>
> ups, sorry, reverted immediately.
>
> Regards,
> Andre
>
> On Fri, 28 Jan 2022 10:27:26 +010
riptor_data_set (, cdesc, comp); |
> ~^~~~
> ../../repos/gcc/gcc/fortran/trans-array.cc:9082:16: note: ‘cdesc’ was
> declared here 9082 | tree cdesc; |^ cc1plus:
> all warnings being treated as errors make[3]: *** [Makefile:1143:
> fortran/trans-array.o] Error 1
>
> T
um 17:32 schrieb Andre Vehreschild via Fortran:
> > Hi all,
> >
> > attached patch fixes wrong code generation when broadcasting a derived type
> > containing allocatable and non-allocatable scalars. Furthermore does it
> > prevent broadcasting of coarray-tokens, whic
.
Bootstrapped and regtested ok on x86_64-linux/F35.
Ok, for trunk and backport to 12 and 11-branch after decent time?
I perceived that 12 is closed for this kind of bugfix, therefore asking ok for
13.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2022-01-24
in the testsuite provides a variable for stat.
Will wait two weeks for any errors introduced by this patch before backporting
to gcc-11, ok?
Regards,
Andre
On Tue, 22 Jun 2021 10:37:27 +0200
Tobias Burnus wrote:
> Hi Andre,
>
> On 22.06.21 09:40, Andre Vehreschild via Fort
_CO_SUM:
> and, with -fcoarray=single, errmsg is not touched
> as stat is (unconditionally) 0 (success)..
>
>
> On 19.06.21 13:23, Andre Vehreschild via Fortran wrote:
> > PING!
> >
> > On Fri, 4 Jun 2021 18:05:18 +0200
> > Andre Vehreschild wrote:
> >
PING!
On Fri, 4 Jun 2021 18:05:18 +0200
Andre Vehreschild wrote:
> Ping!
>
> On Fri, 21 May 2021 15:33:11 +0200
> Andre Vehreschild wrote:
>
> > Hi,
> >
> > the attached patch fixes an issue when calling CO_BROADCAST in
> > -fcoarray=single m
Hi Steve, hi all,
the patch for pr98301 has been backported to gcc-11 as
002745ca3668fc5e87c22acc81caaeaaadf9c47a
Regards,
Andre
On Sat, 5 Jun 2021 09:27:16 -0700
Steve Kargl wrote:
> On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote:
> >
> > I was as
--
Andre Vehreschild * Email: vehre ad gmx dot de
Steve Kargl
PR fortran/98301 - random_init() is broken
Correct implementation of random_init() when -fcoarray=lib is given.
Backport from mainline.
gcc/fortran/ChangeLog:
PR fortran/98301
* trans-decl.c (gfc_build_builtin_function_decls): Move
Ping!
On Fri, 21 May 2021 15:33:11 +0200
Andre Vehreschild wrote:
> Hi,
>
> the attached patch fixes an issue when calling CO_BROADCAST in
> -fcoarray=single mode, where the optional but non-present (in the calling
> scope) stat variable was assigned to before checking for it be
discussion on the mailing lists?
Thanks for your help,
Andre
On Sat, 22 May 2021 19:58:57 +0200
Martin Liška wrote:
> On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote:
> > Hi Steve and Jerry,
> >
> > thanks for the ok'ing.
> >
> > C
yes, please commit
>
> On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote:
> > On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote:
> >> Ping, ping!
> >>
> >> Please find attached a rebased version of the patch for the RANDOM_INIT
> >> issue wi
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
PR fortran/100337
* trans-intrinsic.c (conv_co_collective): Check stat for null ptr
before dereferrencing.
gcc/testsuite/ChangeLog:
PR fortran/100337
* gfortran.dg/coarray_collectives_17.f90: New test.
diff --git a/gcc
wrote:
> On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> > Ping!
> >
> > Ok for trunk?
> >
> > I have looked at other patches, but none was patching any location I have
> > worked on previously. Therefore I can't return the favor of reviewing
ss actual arguments passed to non-descriptor formal args by
> using the data pointer, stored as the symbol's backend decl.
>
> gcc/testsuite/ChangeLog
>
> PR fortran/46691
> PR fortran/99819
> * gfortran.dg/class_dummy_6.f90: New test.
> * gfortran.dg/class_dummy_6.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
Ping!
Ok for trunk?
I have looked at other patches, but none was patching any location I have
worked on previously. Therefore I can't return the favor of reviewing any
currently open patches and have to ask for volunteers here.
- Andre
On Mon, 26 Apr 2021 12:36:36 +0200
Andre Vehreschild via
recovery.
- Andre
Andre Vehreschild
ders.
> > * nca/sync.h: Remove include of shared_memory.h and alloc.h.
> > * nca/util.h: Do not include stdint.h and stddef.h; include
> > limits.h and assert.h.
> > * nca/wrapper.c: Remove include for sync.h, util.h and
> > collective_subroutine.h. Move include of string.h after other
> > headers.
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
is reasonable it's fine.
--
Andre Vehreschild * Email: vehre ad gmx dot de
Oct 2020 13:28:56 +0200
Tobias Burnus wrote:
> Hi Andre,
>
> On 10/7/20 12:21 PM, Andre Vehreschild wrote:
> > I am confused. Given that on 2. Oct. 2020 you committed changes to the
> > caf-fn_spec strings means: you don't need anymore help on this?
>
> Do you m
o_broadcast")), ".W.WW.",
> void_type_node, 5, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_co_max = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_max")), "W.WW",
> + get_identifier (PREFIX("caf_co_max")), ".W.WW..",
> void_type_node, 6, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, integer_type_node, size_type_node);
>
>gfor_fndecl_co_min = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_min")), "W.WW",
> + get_identifier (PREFIX("caf_co_min")), ".W.WW..",
> void_type_node, 6, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, integer_type_node, size_type_node);
>
>gfor_fndecl_co_reduce = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_reduce")), "W.R.WW",
> + get_identifier (PREFIX("caf_co_reduce")), ".W.R.WW..",
> void_type_node, 8, pvoid_type_node,
> build_pointer_type (build_varargs_function_type_list (void_type_node,
> NULL_TREE)),
> @@ -4053,12 +4053,12 @@ gfc_build_builtin_function_decls (void)
> integer_type_node, size_type_node);
>
>gfor_fndecl_co_sum = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_sum")), "W.WW",
> + get_identifier (PREFIX("caf_co_sum")), ".W.WW.",
> void_type_node, 5, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_caf_is_present = gfc_build_library_function_decl_with_spec
> (
> - get_identifier (PREFIX("caf_is_present")), "RRR",
> + get_identifier (PREFIX("caf_is_present")), ".R.R",
> integer_type_node, 3, pvoid_type_node, integer_type_node,
> pvoid_type_node);
> }
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Honza, Tobias,
Yes, I am willing to help and will do so as soon as my small vacation ends
on Monday.
Regards,
Andre
Andre Vehreschild * ve...@gmx.de
Am 30. September 2020 19:12:48 schrieb Tobias Burnus :
Hi Honza,
On 9/30/20 6:12 PM, Jan Hubicka wrote:
_gfortran_caf_co_sum
Hi Tobias,
I see. Then OK for trunk by me.
- Andre
On Wed, 16 Sep 2020 10:35:53 +0200
Tobias Burnus wrote:
> Hi Andre,
>
> On 9/16/20 9:58 AM, Andre Vehreschild wrote:
> > + st->n.sym = NULL;
> >
> > Don't we need free or unlink the st node from the symt
s,
> mostly related to polymorphism (vtab etc.).)
>
> OK for the trunk?
>
> Tobias
>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3837536 * ve...@gmx.de
ut the old code looked so dubious that I wonder why
it worked in the first place. Have you tried with a mapped type?
Regards,
Andre
--
Andre Vehreschild * ve...@gmx.de
a global symbol
> issue an error if the symbol type is known as is not a common
> block name.
>
> 2020-09-04 Mark Eggleston
>
> gcc/testsuite/
>
> PR fortran/95614
> * gfortran.dg/pr95614_1.f90: New test.
> * gfortran.dg/pr95614_2.f90: New test.
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
_location,
+"Sorry, polymorphic arrays not yet supported for "
+"firstprivate");
I totally agree that this is hackish and I don't like for that. But I can't
come up with a better solution at the moment.
The remainder looks ok to me.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
8 Paul Thomas
>
> gcc/fortran
> PR fortran/96495
> * trans-expr.c (gfc_conv_procedure_call): Take the deallocation
> of allocatable result components of a scalar result outside the
> scalarization loop. Find and use the stored result.
>
> gcc/testsuite/
> PR fortran/96
Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
commit feb00c16ba50473e32a0c4adda470a0111603aed
Author: Andre Vehreschild
Date: Fri Aug 28 11:48:31 2020 +0200
Fix ICE when compiling with -fcoarray=single, when derefing a non-array.
gcc/fortran
obias
>
> On 8/19/20 2:51 PM, Tobias Burnus wrote:
> > Am 18.08.20 um 19:33 schrieb Andre Vehreschild:
> >> +case OMP_DEVICE_TYPE_HOST:
> >> + MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits);
> >> Why also NOHOST here?
> >
Hi,
commited with the input by Tobias applied. The full commit message now is:
Fix obvious typo were errmsg_len was assigned to errmsg.
gcc/fortran/ChangeLog:
2020-08-20 Andre Vehreschild
PR fortran/94958
* trans-array.c (gfc_bcast_alloc_comp
raße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Tobias,
On Tue, 18 Aug 2020 19:14:30 +0200
Tobias Burnus wrote:
> On 8/18/20 7:04 PM, Andre Vehreschild wrote:
>
> > attached patch fixes an obvious typo in the routine gathering arguments for
> > co_broadcast(). See pr94958 for a detailed analysis, please.
>
>
Hi all,
attached patch fixes an obvious typo in the routine gathering arguments for
co_broadcast(). See pr94958 for a detailed analysis, please.
Regtests ok on FC31/x86_64. Will commit as obvious on Thursday, if no one
objects.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx
ure string lengths of deferred length components
> are set. For parentheses operator apply string length to both
> the primary expression and the enclosed expression.
>
> gcc/testsuite/
> PR fortran/96100
> PR fortran/96101
> * gfortran.dg/char_length_23.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
re back! Any help with bugfixing is
> highly appreciated, and Coarrays certainly can use
> some work.
>
> The patch is OK for trunk.
>
> Best regards
>
> Thomas
--
Andre Vehreschild * Email: vehre ad gmx dot de
to coarray programs to
crash/hang. This patch fixes at least the misbehavior reported in the PR. More
to come.
Regtests ok on FC31.x86_64. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2020-08-10 Andre Vehreschild
PR
<ka...@gcc.gnu.org>
>
>* gfortran.h: Remove prototype.
>* symbol.c (gfc_new_undo_checkpoint): Remove unused function.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
1)), len(s(3:2))
> end program foo
> % gfc -o z a.f90
> % ./z
>0 0
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
roduced this, I'll do it within a few days (unless, of
> > course, somebody beats me to it, which I won't mind :-)
>
> OK, not a few days, but a few hours :-)
>
> Here is the diff. OK to commit to gcc-docs?
>
> Regards
>
> Thomas
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
tran/70870
> * data.c (gfc_assign_data_value): Check that a data object does
> not also have default initialization.
>
> 2018-05-09 Steven G. Kargl <ka...@gcc.gnu.org>
>
> PR fortran/70870
> * gfortran.dg/pr70870_1.f90: New test.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
g copy)
> @@ -0,0 +1,8 @@
> +! { dg-do compile }
> +! PR fortran/85521
> +program p
> + character(3) :: c = 'abc'
> + character(3) :: z(1)
> + z = [ c(:-2) ]
> + print *, z
> +end
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
.
Regards,
Andre
On Sat, 5 May 2018 09:38:08 -0700
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 04/30/2018 01:52 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch partially reverts r259385 preventing an ICE. At the same time
>
,
gcc-8/-7/-6?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-04-30 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/85507
* dependency.c (gfc_dep_resolver): Revert looking at coarray dimension
introduced by r
Hi all,
because pr81773 is a 6-/7-/8-regression I have backported it to gcc-6 as r259741
and gcc-7 as r259742.
Regards,
Andre
On Sat, 14 Apr 2018 16:46:53 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi Paul,
>
> thank you for the review. Committed as r25938
gt; On 13 April 2018 at 08:34, Andre Vehreschild <ve...@gmx.de> wrote:
> > Ping
> >
> > On Sun, 8 Apr 2018 14:25:50 +0200
> > Andre Vehreschild <ve...@gmx.de> wrote:
> >
> >> Hi all,
> >>
> >> attached patch fixes (to my knowledg
k for start, end or
> stride being defined by an outer implied DO loop.
>
> 2018-04-14 Thomas Koenig <tkoe...@gcc.gnu.org>
>
> PR fortran/85387
> * gfortran.dg/implied_do_io_5.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
Ping
On Sun, 8 Apr 2018 14:25:50 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where the
> result of a coarray get() operation is assigned to an array using a vector as
> index. It took
which is a very complicated concept in the gfortran
and I haven't worked with before, therefore a steep learning curve. I hope to
be on track more often soon.
- Andre
>
>
> Damian
>
> On February 19, 2018 at 9:32:06 AM, Andre Vehreschild (ve...@gmx.de) wrote:
>
> Hi all,
>
with expertise on
using the scalarizer are especially welcome.
Bootstrapped and regtested on x86_64-linux/f27.
Ok for trunk? Backports?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-04-08 Andre Vehreschild <ve...@gcc.gnu.org>
Hi all,
no objections received therefore committed as r257813. Thanks for fast review
Jerry.
- Andre
On Sun, 18 Feb 2018 18:33:07 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Well, after discussing on IRC whether RM should be bothered, I was asked to
> simplify release ma
Well, after discussing on IRC whether RM should be bothered, I was asked to
simplify release managers lives and propose, that if no one objects within one
day, I will merge the patch. So any objections?
- Andre
On Sun, 18 Feb 2018 18:07:28 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
to merge it: Ok to merge to trunk?
Regards,
Andre
On Sun, 18 Feb 2018 08:53:41 -0800
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 02/18/2018 07:39 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch fixes an issue with the coarray API. When a comp
/o reallocation) did.
Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-02-18 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.texi: Document additional src/dst_type. Fix some
Er, the revision is 257567. Sorry pressed to quickly.
- Andre
On Sun, 11 Feb 2018 20:00:05 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> approved on IRC by Kargl. Thanks for the quick review. Committed as r
>
> Regards,
> Andre
>
> On S
Hi all,
approved on IRC by Kargl. Thanks for the quick review. Committed as r
Regards,
Andre
On Sun, 11 Feb 2018 18:13:35 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes a small coarray issue on ultimate component coarrays. The
> coar
.
Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
caf_nullify_and_doc_fix_v1.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 11246696e18..9ffe6ade661
; >> If not, well... one possible decision would be to wait for gcc-8 to
> >> fix this.
> >>
> >> > or does it mean that there will need to be work done on OpenCoarrays
> >> to support the changes
> >>
> >> This, I don't know, never having looked at the OpenCoarrays source.
> >>
> >> Regards
> >>
> >> Thomas
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
= gfc_find_derived_vtab (sym);
> + gfc_set_sym_referenced (vtab);
> + }
> +
> return true;
> }
Besides that I think this is OK.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
nt of the array
> descriptor change between trunk and 7-branch :-)
>
> OK for trunk and 7-branch.
>
> Thanks
>
> Paul
>
>
> On 4 November 2017 at 10:27, Andre Vehreschild <ve...@gmx.de> wrote:
> > Ping!
> >
> > On Wed, 1 Nov 2017 12:27:1
Ping!
On Wed, 1 Nov 2017 12:27:11 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> during development on OpenCoarrays I found these three issues in gfortran:
>
> - caf_send: Did not treat char arrays as arrays when calling caf_send.
> - gfc_trans_
, but within.
- get_array_span: When doing pointer arithmetic on char arrays the character
kind was not applied.
The attached patch fixes all of these issues for trunk and gcc-7. Bootstrapped
and regtested on x86_64-linux-gnu/f25. Ok for trunk and gcc-7?
Regards,
Andre
--
Andre Vehreschild
0850
> * trans_expr.c (gfc_conv_procedure_call): When passing a class
> argument to an unlimited polymorphic dummy, it is wrong to cast
> the passed expression as unlimited, unless it is unlimited. The
> correct way is to assign to each of the fields and set the _len
> field to zero.
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi all,
I got no direct objections therefore committed as r254197 to trunk and r254198
to gcc-7.
@Steve, I will take a look at what you pointed.
- Andre
On Fri, 27 Oct 2017 12:19:02 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> as noted on IRC is one of th
objects within 24 h I am planning to commit this patch as obvious to
trunk gcc-7. Bootstrapped and regtested on x86_64-linux-gnu/f25.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-10-27 Andre Vehreschild <ve...@gcc.gnu.
f the right hand side expression is of class
>type.
>
>2017-10-26 Paul Thomas <pa...@gcc.gnu.org>
>
>PR fortran/81758
>* gfortran.dg/class_63.f90: New test.
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * ve...@gmx.de
rselves to one MPI implementation?
>
> FX
--
Andre Vehreschild * Email: vehre ad gmx dot de
rselves to one MPI implementation?
>
> FX
--
Andre Vehreschild * Email: vehre ad gmx dot de
they have a different cause.
- Andre
Am 10. März 2017 07:48:12 MEZ schrieb Christophe Lyon
<christophe.l...@linaro.org>:
>On 9 March 2017 at 09:45, Andre Vehreschild <ve...@gmx.de> wrote:
>> Hi Christophe,
>>
>> you are right, that error message does not help
It should be "yes"
- Andre
On Wed, 8 Mar 2017 23:58:10 +0100
Christophe Lyon <christophe.l...@linaro.org> wrote:
> Hi,
>
> On 5 March 2017 at 12:41, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi Jerry,
> >
> > thanks for seconding my read of t
Hi Jerry,
thanks for seconding my read of the standard and reviewing so quickly.
Committed as r245900.
Regards,
Andre
On Sat, 4 Mar 2017 15:06:25 -0800
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 03/04/2017 09:58 AM, Andre Vehreschild wrote:
> > Hi all,
> >
you please add my name and contact (Alessandro Fanfarillo
><fanfarillo@gmail.com>) below yours in the changelog?
>
>Thanks,
>Alessandro
>
>
>2017-03-04 10:58 GMT-07:00 Andre Vehreschild <ve...@gmx.de>:
>> Hi all,
>>
>> attached patch poli
;FAIL IMAGE" to stderr,
while in coarray=single mode it just quits. What do you think?
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be later).
Gruß,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-03-04 Andre Vehres
Hi Jerry, hi all,
thanks for the review. Committed as r245581.
Regards,
Andre
On Sun, 19 Feb 2017 08:58:46 -0800
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 02/19/2017 08:42 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > this time with correct PR numbe
Ping!
this time with correct PR number: 79229.
On Tue, 7 Feb 2017 08:31:22 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes the issue of 79229 (which is not a regression).
> The issue was that the code generating the checking was expectin
node*) (trans.c:1965) ==15334==by 0x9209F6:
> gfc_trans_code(gfc_code*) (trans.c:2124) ==15334==by 0x95B503:
> gfc_generate_function_code(gfc_namespace*) (trans-decl.c:6306)
> ...
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-15 Andre Vehreschild <ve..
estions on how to fix potential issues are more than welcome.
> >>>
> >>> Regards,
> >>> Alessandro
> >>>
> >>
> >> On the failed images test:
> >>
> >> program test_image_status
> >> + implicit none
> >&g
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
gcc/testsuite/ChangeLog:
2017-02-07 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79229
* gfortran.dg/class_allocate_24.f90: New test.
gcc/fortran/ChangeLog:
2017
Hi Mikael,
thanks for the fast review. Committed as r245193.
Regards,
Andre
On Sun, 5 Feb 2017 15:32:25 +0100
Mikael Morin <morin-mik...@orange.fr> wrote:
> Le 04/02/2017 à 19:43, Andre Vehreschild a écrit :
> > Hi all,
> >
> > attached patch fixes t
others have too :-( We must start running the
> testsuite on a regular basis. Unfortunately, it lacks a harness to run
> all the tests automatically.
>
> PPS I am some days away yet from recovering from my move from France
> to the UK and so would defer to you if you can come up with a fix
is gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 with
> > valgrind/sanitizer. I therefore added no additional testcase.
> >
> > Bootstraps and regtests ok on x86_64-linux/f25 and as reported in the PR on
> > 32bit-hpux. Ok for trunk (when?)?
> >
> > Regards,
>
4-linux/f25. Ok for trunk (current or
> > next, haven't monitored whether commits are still allowed)?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot
on temporary objects, i.e.,
when the source-expression is not an EXPR_VARIABLE, e.g. an EXPR_STRUCTURE or
EXPR_FUNCTION.
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre
come up with a fix.
Fix present, waiting for testsuite to pass.
- Andre
>
> On 4 February 2017 at 13:39, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi all,
> >
> > attached patch fixes the access of uninitialized data. Thanks Martin for
> > analyzing this so
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79335
* trans-decl.c (generate_coarray_sym_init): Retrieve the symbol's
attributes before using them.
diff --git a/gcc/fortran
.
Bootstraps and regtests ok on x86_64-linux/f25 and as reported in the PR on
32bit-hpux. Ok for trunk (when?)?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/78958
*
/disassociating the pointer
using a finalizer, as is IMO the intention of the Fortran standard.
Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk (current or
next, haven't monitored whether commits are still allowed)?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot
Hi all,
during the backport of pr70696 I forgot to backport the runtime part in
libgfortran/caf/single.c. This is fixed by commit r245016.
Sorry for the noise, regards,
Andre
On Sun, 29 Jan 2017 14:51:03 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
&g
1 - 100 of 429 matches
Mail list logo
