Re: [Patch, Fortran] CO_BROADCAST for derived types with allocatable components

before very long, something will have to be done about the > exponential code bloat that structure_alloc_comps. The more users that > there are for it the tougher it is going to get! > > On Thu, 22 Aug 2019 at 18:41, Alessandro Fanfarillo > wrote: > > > > Dear all, > >

[Patch, Fortran] CO_BROADCAST for derived types with allocatable components

b9458ff4414615263ed92d8965c93fd0a953f4a9 Author: Alessandro Fanfarillo Date: Thu Aug 22 10:50:17 2019 -0600 Co_broadcast derived types with allocatable components diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index c8d74e588dd..005646f1359 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans

Re: [PATCH, fortran] Support Fortran 2018 teams

ease.) > > Ok from RM POV. > > Jakub -- Alessandro Fanfarillo, Ph.D. Postdoctoral Researcher National Center for Atmospheric Research Mesa Lab, Boulder, CO, USA 303-497-1229

Re: [PATCH, fortran] Support Fortran 2018 teams

son wrote: >> Thanks for catching that, Steve, and for responding, Alessandro. >> >> Anything else? >> > > I've only just started to look at the patch. Unfortunately, > I know zero about teams, so need to read the patch and F2018 > standard simultaneously. >

Re: [PATCH, fortran] Support Fortran 2018 teams

return MATCH_ERROR; > > + team_just_seen = false; >stat_just_seen = false; > - if (gfc_match(" , stat = %e",) == MATCH_YES && ar->stat == NULL) > + if (gfc_match (" , team = %e", ) == MATCH_YES && ar->stat == NULL) >

Re: [PATCH, Fortran, Coarray, v1] Add support for failed images

Hi Andre, thanks for your work on the patch. I agree with you about exit(0) statement in libcaf_single. Could 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 Vehreschi

Re: [Fortran, Patch, CAF] Failed Images patch (TS 18508)

Now with the patch attached. 2017-02-13 13:35 GMT-07:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Thanks Jerry. That test case is supposed only to be compiled (it never > runs). Anyway, the attached patch has been modified according to your > suggestion. > > Patc

Re: [Fortran, Patch, CAF] Failed Images patch (TS 18508)

03:02 PM, Alessandro Fanfarillo wrote: >> >> Dear all, >> please find in attachment a new patch following the discussion at >> https://gcc.gnu.org/ml/fortran/2017-01/msg00054.html. >> >> Suggestions on how to fix potential issues are more than welcome. >> &g

[Fortran, Patch, CAF] Failed Images patch (TS 18508)

Dear all, please find in attachment a new patch following the discussion at https://gcc.gnu.org/ml/fortran/2017-01/msg00054.html. Suggestions on how to fix potential issues are more than welcome. Regards, Alessandro commit e2dad3cc56447daea85c147f08b3f58a8e70617f Author: Alessandro Fanfarillo

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

* PING * 2016-09-21 19:03 GMT+01:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Thanks Andre. > > 2016-09-19 9:55 GMT-06:00 Andre Vehreschild <ve...@gmx.de>: >> Hi Alessandro, > >> The if in resolve.c at 8837: resolve_failed_image (... is intentiona

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

> > Regards, > Andre > > On Mon, 19 Sep 2016 08:30:12 -0700 > Alessandro Fanfarillo <fanfarillo@gmail.com> wrote: > >> * PING * >> >> On Sep 7, 2016 3:01 PM, "Alessandro Fanfarillo" <fanfarillo@gmail.com> >> w

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

gle. > Is this not possible for some reason? > > Otherwise, this is OK for trunk. > > Thanks for the patch. > > Paul > > On 4 August 2016 at 05:07, Alessandro Fanfarillo > <fanfarillo@gmail.com> wrote: >> * PING * >> >> 2016-07-21

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

> > Paul > > On 4 August 2016 at 05:07, Alessandro Fanfarillo > <fanfarillo@gmail.com> wrote: >> * PING * >> >> 2016-07-21 13:05 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: >>> Dear Mikael and all, >>> >>> in at

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

* PING * 2016-07-21 13:05 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Dear Mikael and all, > > in attachment the new patch, built and regtested on x86_64-pc-linux-gnu. > > Cheers, > Alessandro > > 2016-07-20 13:17 GMT-06:00 Mikael Morin <morin-mi

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

;>>> + 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

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

Third *PING* 2016-07-04 16:46 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > * PING * > > 2016-06-21 10:59 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: >> * PING * >> >> 2016-06-06 15:05 GMT-06:00 Alessandro Fanfarillo &

Re: [Fortran] Help with STAT= attribute in coarray reference

Thanks, committed as rev. 238007. 2016-07-04 14:41 GMT-06:00 Mikael Morin <morin-mik...@orange.fr>: > Le 30/06/2016 06:05, Alessandro Fanfarillo a écrit : >> >> Dear Mikael, >> >> thanks for your review and for the test. The attached patch, built and >

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

* PING * 2016-06-21 10:59 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > * PING * > > 2016-06-06 15:05 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: >> Dear all, >> >> please find in attachment the first patch (of n) for

Re: [Fortran] Help with STAT= attribute in coarray reference

. In the meantime, is this patch OK for trunk? 2016-06-23 14:45 GMT-06:00 Mikael <morin-mik...@orange.fr>: > Le 20/06/2016 22:01, Alessandro Fanfarillo a écrit : >> >> Hi Mikael and all, >> >> in attachment the new version of the patch. >> I'

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

* PING * 2016-06-06 15:05 GMT-06:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Dear all, > > please find in attachment the first patch (of n) for the FAILED IMAGES > capability defined in the coarray TS 18508. > The patch adds support for three new intrinsic function

[Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

the list of failed images (failed_images). The patch has been built and regtested on x86_64-pc-linux-gnu. Ok for trunk? Alessandro commit b3bca5b09f4cbcf18f2409dae2485a16a7c06498 Author: Alessandro Fanfarillo <fanfari...@ing.uniroma2.it> Date: Mon Jun 6 14:27:37 2016 -0600 First patch

Re: [Patch, Fortran] STOP issue with coarrays

h is fine for trunk and 5-branch - going on trivial, I would > say! Are you going to add the testcase? > > Thanks a lot! I am impressed that you are doing these between > celebrating your doctorate and preparing for your move :-) > > Paul > > On 27 March 2016 at 17:10, Alessan

[Patch, Fortran] STOP issue with coarrays

and gcc-5-branch? gcc/fortran/ChangeLog 2016-03-27 Alessandro Fanfarillo <fanfarillo@gmail.com> * trans-decl.c (gfc_build_builtin_function_decls): caf_stop_numeric and caf_stop_str definition. * trans-stmt.c (gfc_trans_stop): invoke external functions fo

Re: [Fortran, Patch] (Coarrays) Wrong events size

Thanks! Patch committed as revision 233779 on trunk and as revision 233780 on gcc-5-branch. 2016-02-26 19:14 GMT+01:00 Paul Richard Thomas : > Dear Alessandro, > > Seconded! I saw your ping on my phone and was going to respond. > well, now :-) > > Thanks for

Re: [Fortran, Patch] (Coarrays) Wrong events size

* PING * 2016-02-20 18:25 GMT+01:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Dear all, > > currently, the compiler doesn't pass the right size to the > registration routine of OpenCoarrays for event variables: > > size.15 = 0; > > ev.data = (void * re

[Fortran, Patch] (Coarrays) Wrong events size

ble be different from a lock variable when LIBCAF_SINGLE is used? The patch has been built and regtested on x86_64-pc-linux-gnu. Ok for trunk and gcc-5-branch? gcc/fortran/Changelog 2016-02-20 Alessandro Fanfarillo <fanfarillo@gmail.com> * trans.c (gfc_allocate_allocatable):

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

Committed on gcc-5-branch as rev. 233379. 2016-02-12 0:04 GMT+01:00 Alessandro Fanfarillo <fanfarillo@gmail.com>: > Dear all, > > in attachment the EVENT patch for gcc-5-branch directly back-ported > from the trunk. > > Built and regtested on x86_64-pc-linux-gnu. I pla

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

Dear all, in attachment the EVENT patch for gcc-5-branch directly back-ported from the trunk. Built and regtested on x86_64-pc-linux-gnu. I plan to commit this patch this evening (Feb 12th, CET). Cheers, Alessandro 2015-12-17 17:19 GMT+01:00 Alessandro Fanfarillo <fanfarillo@gmail.

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

Great! Thanks. 2015-12-17 15:57 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote: >> >> I've noticed that this patch has been applied only on trunk and not on >> the gcc-5-branch. Is it

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

his a candidate for a commit to > the 5-branch when it is re-opened? > > -- > steve > > On Wed, Dec 02, 2015 at 03:16:05PM +0100, Alessandro Fanfarillo wrote: >> *PING* >> >> 2015-11-26 17:51 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: >> &g

Re: [COMMITTED] Add myself to MAINTAINERS (Write After Approval)

Sorry about that. Committed revision 231657 Index: ChangeLog === --- ChangeLog(revision 231656) +++ ChangeLog(working copy) @@ -1,4 +1,4 @@ -2015-12-15 Alessandro Fanfarillo <fanfarillo@gmail.com> +2015

[COMMITTED] Add myself to MAINTAINERS (Write After Approval)

<ans...@thphy.uni-duesseldorf.de> Doug Evans<d...@google.com> Chris Fairles<cfair...@gcc.gnu.org> +Alessandro Fanfarillo<fanfarillo@gmail.com> Changpeng Fang<chang

Re: [Fortran, Patch} Fix ICE for coarray Critical inside module procedure

Committed as revision 231649 on trunk and as revision 231650 on gcc-5-branch. Thanks. 2015-12-14 20:02 GMT+01:00 Tobias Burnus <bur...@net-b.de>: > Dear Alessandro, > > Alessandro Fanfarillo wrote: >> >> the compiler returns an ICE when a coarray critical section

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

2015-12-09 23:16 GMT+01:00 Tobias Burnus : > Thanks. Committed as r231476. Thanks. > > Do we need to do anything about GCC 5 or is this only a GCC 6 issue? > Yes, the patch should be applied to GCC 5 too. > That can be changed: Simply fill out the form and list me (burnus (at]

[Fortran, Patch} Fix ICE for coarray Critical inside module procedure

() fixed the issue. The latter solution is proposed in the attached patch. Built and regtested on x86_64-pc-linux-gnu Cheers Alessandro PS: This patch should be also included in GCC 5. 2015-12-10 Alessandro Fanfarillo <fanfarillo@gmail.com> * resolve.c (resolve_critical): Comm

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

Done. I have permission for contributing but I don't have write permission on the repository. 2015-12-09 8:23 GMT+01:00 Tobias Burnus <bur...@net-b.de>: > Alessandro Fanfarillo wrote: >> >> in attachment the new patch. I also checked the behavior with >> move_alloc:

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

? 2015-12-08 11:01 GMT+01:00 Tobias Burnus <tobias.bur...@physik.fu-berlin.de>: > Dear Alessandro, dear all, > > On Mon, Dec 07, 2015 at 03:48:17PM +0100, Alessandro Fanfarillo wrote: >> Your patch fixes the issues. In attachment patch, test case and changelog. > > Re

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

org/ml/fortran/2015-04/msg00062.html > It should work as -fcoarray=lib -lcaf_single "dg-do run" test. > > Tobias commit 69e650945454491bbaf81513a1eed10b5b6b0f45 Author: Alessandro Fanfarillo <fanfari...@ing.uniroma2.it> Date: Mon Dec 7 15:46:10 2015 +0100 Introduc

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

Hi, 2015-12-07 8:20 GMT+01:00 Tobias Burnus : > Always - or only with optimization? > Only with optimization. > I wonder whether using > > __asm__ __volatile__ ("":::"memory"); > > would be sufficient as it has a way lower overhead than > __sync_synchronize(). > > > That would

[Fortran, Patch] Memory sync after coarray image control statements and assignment

the __sync_synchronize() after get/put and sync statements fix all the problems reported by Deepak. I do the same also for locks, critical and events. Suggestions are warmly welcome. commit 75c93d3085116748115c8f69ad5ad58f4ad9369c Author: Alessandro Fanfarillo <fanfari...@ing.uniroma2.it> Date:

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

5 at 03:16:05PM +0100, Alessandro Fanfarillo wrote: >> *PING* >> >> 2015-11-26 17:51 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: >> > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo wrote: >> >> Dear all, >> >>

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

*PING* 2015-11-26 17:51 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo wrote: >> Dear all, >> >> in attachment the previous patch compatible with the current trunk. >> The patch als

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

Hi all, in attachment the patch for tests and missing functions in libcaf_single (needed by the test suite). Built and regtested on x86_64-pc-linux-gnu. 2015-11-26 17:51 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro F

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

type(event_type) :: EV > type(lock_type) :: LK > end type1 > type t2 > type(t1) :: a(5) > end type t2 > type t3 > type(t2) :: b(8) > end type t3 > > type(t3), save :: caf(3)[*] > > For those, I need to call _gfortran_caf_register for > caf(:)%b(:)%a(:)%ev and

Re: [Fortran, Patch] Passing function pointer to co_reduce

Thanks a lot! 2015-07-17 15:50 GMT+02:00 Mikael Morin mikael.mo...@sfr.fr: Le 17/07/2015 11:02, Mikael Morin a écrit : Le 16/07/2015 16:34, Damian Rouson a écrit : Alternatively, if it’s easy, please feel free to add the directives and commit. Never mind, I'll take care of it all. This

[Fortran, Patch] Passing function pointer to co_reduce

simple_reduction is the pure function that has to be used by co_reduce. The attached patch seems to fix the issue, any comments? Regards Alessandro PS: I also attach the test case commit a12b6ce6993df109c81a32d5684b4b9f41f69ea4 Author: Alessandro Fanfarillo fanfari...@ing.uniroma2.it Date: Mon

Re: [PATCH, Fortran] Sync memory action delegated to OpenCoarrays

Totally fine with me. Thanks. 2015-03-10 0:20 GMT-07:00 Tobias Burnus bur...@net-b.de: Hi Alessandro, Alessandro Fanfarillo wrote: Thanks for the quick response. Patch built and regtested on x86_64-unknown-linux-gnu. Actually, I also was about to send a reworked patch myself - see

Re: [PATCH, Fortran] Sync memory action delegated to OpenCoarrays

to change the patch for -fcoarray=single. 2015-03-06 11:20 GMT-08:00 Tobias Burnus bur...@net-b.de: Dear Alessandro, Alessandro Fanfarillo wrote: so far a sync memory statement is translated into a local __sync_synchronize (). The attached draft patch delegates the action for sync memory

[PATCH, Fortran] Sync memory action delegated to OpenCoarrays

? Best regards Alessandro commit fdb560e3f548fe60edf26717b8de6bb92f3fd555 Author: Alessandro Fanfarillo fanfarillo@gmail.com Date: Fri Mar 6 10:25:56 2015 -0800 Sync memory is translated into an invokation to _gfortran_caf_sync_memory() diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran

Re: [Patch, Fortran] Add CO_BROADCAST

Hi, I'm implementing the co_broadcast on libcafmpi right now. 2014-09-25 8:08 GMT+02:00 Tobias Burnus bur...@net-b.de: Hi Paul, Paul Richard Thomas wrote: In the check.c error messages, you use 'A argument'. Should you not use 'SOURCE argument', following CO BROADCAST (SOURCE, SOURCE IMAGE

Re: [PATCH, Fortran] Wrong invocation of caf_atomic_op

Alessandro! Tobias On 15.09.2014 23:29, Tobias Burnus wrote: On 15.09.2014 22:23, Alessandro Fanfarillo wrote: In attachment a test case which fails with the current gcc-trunk version but works when the patch is applied. coarray_35.f90 is my attempt to write a gcc test case. The problem

Re: [PATCH, Fortran] Wrong invocation of caf_atomic_op

New patch after the update. Cheers 2014-09-09 0:30 GMT-06:00 Tobias Burnus bur...@net-b.de: Alessandro Fanfarillo wrote: This email follows the previous without subject (sorry about that). I think I'd prefer the following patch, which avoids a temporary if none is required. value

Re: [PATCH, Fortran] Wrong invocation of caf_atomic_op

(run test + fdump-tree-original?). @@ -8398,3 +8398,3 @@ conv_intrinsic_atomic_op (gfc_code *code) - if (TREE_TYPE (TREE_TYPE (atom)) != TREE_TYPE (TREE_TYPE (value))) + if (!POINTER_TYPE_P (TREE_TYPE (value))) 2014-09-15 Alessandro Fanfarillo fanfarillo@gmail.com Tobias

[PATCH, Fortran]

Dear all, the following code produces a wrong invocation to libcaf for caf_atomic_op (atomic_add): program atomic use iso_fortran_env implicit none integer :: me integer(atomic_int_kind) :: atom[*] me = this_image() call atomic_define(atom[1],0) sync all call ATOMIC_ADD (atom[1], me) if(me ==

Re: [PATCH, Fortran]

Thanks, your suggestion fixes the problem. I just noticed that I missed the subject description; I'll send the new patch in a different email. 2014-09-08 15:50 GMT-06:00 Tobias Burnus bur...@net-b.de: Alessandro Fanfarillo wrote: the following code produces a wrong invocation to libcaf

[PATCH, Fortran] Wrong invocation of caf_atomic_op

call ATOMIC_ADD (atom[1], me) if(me == 1) call atomic_ref(me,atom[1]) sync all write(*,*) me end program Ok for trunk? 2014-09-08 Alessandro Fanfarillo fanfarillo@gmail.com Tobias Burnus bur...@net-b.de * trans-intrinsic.c (conv_intrinsic_atomic_op): Check

Re: [Patch, Fortran] -fcoarray=lib - support CRITICAL, prepare for locking support

Hello, I was implementing lock/unlock on the library side when I found a possible problem in the patch: if (is_lock_type == GFC_CAF_CRITICAL) +reg_type = sym-attr.artificial ? GFC_CAF_CRITICAL : GFC_CAF_LOCK_STATIC; + else +reg_type = GFC_CAF_COARRAY_STATIC; the if statement cannot be

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

Dear Tobias, there are some problems with the final-wrapper-v2.diff patch; I get the following error final2.f90:71.15: end module test 1 Internal Error at (1): gfc_code2string(): Bad code for every test case that I use; in attachment final2.f90. Regards Alessandro 2012/8/19

Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

that pointers do what they are supposed to do, although it is rather trivial. Cheers Paul -- Dott. Alessandro Fanfarillo Verificatore Ellisse Cell: 339/2428012 Email: alessandro.fanfari...@gmail.com

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

Dear all, in attachment the new draft which also supports the polymorphic deallocation via INTENT(OUT). Tomorrow I'll try to realize a draft for the deallocation at the end of the scope. Regards 2012/6/12 Alessandro Fanfarillo fanfarillo@gmail.com: I don't know if there's already a PR

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

I don't know if there's already a PR but I get an ICE compiling this with a non-patched version. If x is not an array everything goes ok. 2012/6/11 Tobias Burnus bur...@net-b.de: On 06/11/2012 11:24 AM, Alessandro Fanfarillo wrote: gfortran.dg/coarray/poly_run_3.f90 That one fails because I

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

: in build_int_cst_wide, at tree.c:1219 deallocate (taa, tpa, caa, cpa) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. 2012/6/10 Tobias Burnus bur...@net-b.de: Alessandro Fanfarillo wrote: with the priceless support

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

2012 12:15, Alessandro Fanfarillo fanfarillo@gmail.com wrote: Right, the problem is that the _free component is missing. Just as the _copy component, _free should be present for *every* vtype, no matter if there are allocatable components or not. If the _free component is not needed, it should

Re: [Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant

Hi all, in attachment the patch which includes the review comments provided by Tobias. The patch is bootstrapped and tested on x86_64-unknown-linux-gnu. Regards. Alessandro 2012/5/20 Tobias Burnus bur...@net-b.de: Hi Alessandro, Alessandro Fanfarillo wrote: in attachment there's a patch

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

Right, the problem is that the _free component is missing. Just as the _copy component, _free should be present for *every* vtype, no matter if there are allocatable components or not. If the _free component is not needed, it should be initialized to EXPR_NULL. With an empty _free function

Re: [Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant

Thank you Tobias, I thought that Change name in gfc_check_init_expr was sufficient. 2012/6/3 Tobias Burnus bur...@net-b.de: Hi Alessandro, hi all, Alessandro Fanfarillo wrote: in attachment the patch which includes the review comments provided by Tobias. Thanks for the patch, which I

[Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

Dear all, I have realized a draft patch for the PR 46321, currently it works only with the explicit DEALLOCATE. Running the regression tests it doesn't pass the following: - gfortran.dg/class_19.f03 (too much __builtin_free) - gfortran.dg/auto_dealloc_2.f90 (too much __builtin_free) -

Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation

Hi Janus, Sorry, I don't understand the last sentence. Why should it call some __free... instead of doit? And why is that test case even affected by your patch (you said it would only work with explicit DEALLOCATE, which does not appear in that test case)? Yes, it is as I said... In

Re: [Fortran, patch] PR 52158 - Regression on character function with gfortran 4.7

2012/5/13 Tobias Burnus bur...@net-b.de: Committed as Rev. 187436. Thanks for the patch and congratulation to your first GCC contribution! Thank you for your priceless support! Alessandro

[Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant

Hi All, in attachment there's a patch for PR 48831, it also includes a new test case suggested by Tobias Burnus. The patch is bootstrapped and tested on x86_64-unknown-linux-gnu. Regards. Alessandro Fanfarillo patch.diff Description: Binary data

Re: [Fortran, patch] PR 52158 - Regression on character function with gfortran 4.7

. gcc version 4.8.0 20120512 (experimental). Have a nice weekend. Alessandro. 2012/5/7 Tobias Burnus bur...@net-b.de: Hello, On 05/06/2012 09:37 PM, Alessandro Fanfarillo wrote: The patch is bootstrapped and tested on x86_64-unknown-linux-gnu - gcc version 4.8.0 20120506 (experimental

[Fortran, patch] PR 52158 - Regression on character function with gfortran 4.7

. gcc/fortran/ChangeLog 2012-05-06 Alessandro Fanfarillo fanfarillo@gmail.com Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR fortran/52158 * resolve.c