are good points you're making. I extended the test case
accordingly and committed the whole thing as r219098. Thanks for the
review!
> PS happy New Year!
Same to you and everyone else on this mailing list!
Cheers,
Janus
> On 27 December 2014 at 18:35, Janus Weil wrote:
>>
Hi all,
here is a patch to improve diagnostics for dummy procedures. Regtested
on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-29 Janus Weil
PR fortran/60507
* interface.c (is_procptr_result): New function to check if an
expression is a procedure-pointer
Hi Andre,
> Now, the patch was not intended to solve 61337. Although I have looked into
> the
> pseudo code generated for 61337, I couldn't figure easily what is going on
> there. In my impression, this is something from incorrectly computed bounds to
> an integer(8),pointer integer(4),pointer mi
Hi Tobias,
> It often happens that one wants to debug PURE procedures but as I/O is not
> permitted, this can be difficult. F2008's IMPURE ELEMENTAL helps a bit not
> completely.
>
> Fortran 2015 adds another aid – not I/O which is intrinsically impure – but
> at least ERROR STOP is now permitted.
(early) ping!
2014-12-29 13:50 GMT+01:00 Janus Weil :
> Hi all,
>
> here is a patch to improve diagnostics for dummy procedures. Regtested
> on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Cheers,
> Janus
>
>
>
> 2014-12-29 Janus Weil
>
>
2014-12-31 19:13 GMT+01:00 Tobias Burnus :
>> here is a patch to improve diagnostics for dummy procedures. Regtested
>> on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Looks good to me. Thanks for the patch!
Thanks, committed as r219141.
Cheers,
Janus
>> 2014-12-29 Ja
mponent is located and fetch the corresponding constructor
component.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-02 Janus Weil
PR fortran/57562
* expr.c (find_component_ref): Deal with extended types.
2015-01-02 Janus Weil
PR fortran/57562
* g
Hi Tobias,
> Looking through the stashed patches, I realized a pending (unsubmitted)
> patch, showing that both a test case for CO_REDUCE was missing and that
> libcaf_single didn't include co_reduce.
>
> This patch adds them.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
looks
2015-01-02 17:02 GMT+01:00 Tobias Burnus :
> + int ext = dt->attr.extension;
> + while (ext>0 && gfc_find_component (dt->components->ts.u.derived,
> pick->name,
> + true, true))
> +{
> + dt = dt->components->ts.u.derived;
> + c = gfc_constructor_first (c->expr->value.constructo
Committed as r219144.
Cheers,
Janus
2015-01-02 17:13 GMT+01:00 Janus Weil :
> 2015-01-02 17:02 GMT+01:00 Tobias Burnus :
>> + int ext = dt->attr.extension;
>> + while (ext>0 && gfc_find_component (dt->components->ts.u.derived,
>> pick->name,
>&g
2015-01-02 17:24 GMT+01:00 Tobias Burnus :
>>> Looking through the stashed patches, I realized a pending (unsubmitted)
>>> patch, showing that both a test case for CO_REDUCE was missing and that
>>> libcaf_single didn't include co_reduce.
>>>
>>> This patch adds them.
>>>
>>> Build and regtested on
?
Cheers,
Janus
2015-01-03 Janus Weil
PR fortran/63552
* primary.c (gfc_match_varspec): Handle type-bound procedures as actual
argument to dummy procedure.
2015-01-03 Janus Weil
PR fortran/63552
* gfortran.dg/typebound_proc_34.f90: New.
Index: gcc/fortran/primary.c
Hi Andre,
>> 1) There are still two TODO markers in the patch. It might be a good
>> idea to take care of them before committing the patch. In particular
>> for the first one (adding the initializer in gfc_build_class_symbol)
>> it would be good to understand where those problems come from.
>
> I
Hi Andre,
>> >> For the
>> >> second one (in gfc_conv_expr), I don't directly see how it's related
>> >> to deferred char-len. Why is this change needed?
>> >
>> > That change is needed, because in some rare case where an associated
>> > variable in a "select type ()" is used, then the type and f9
, according to the usual rules.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-06 Janus Weil
PR fortran/64508
* interface.c (compare_parameter): Interface check for
procedure-pointer component as actual argument.
2015-01-06 Janus Weil
PR
Ping! (I think this patch is pretty straightforward ...)
Cheers,
Janus
2015-01-06 16:19 GMT+01:00 Janus Weil :
> Hi all,
>
> here is a patch which adds an interface check for procedure pointer
> components as acual arguments. Such a check is there already for
> ordinary
x86_64-unknown-linux-gnu. Ok for trunk? 4.9/4.8?
Cheers,
Janus
2015-01-11 Janus Weil
PR fortran/63733
* interface.c (gfc_extend_expr): Look for type-bound operators before
non-typebound ones.
2015-01-11 Janus Weil
PR fortran/63733
* gfortran.dg/typebound_operator_20.f90
Committed as r219431. Thanks for the review!
Cheers,
Janus
2015-01-11 16:16 GMT+01:00 Paul Richard Thomas :
> Dear Janus,
>
> As you say, the patch is pretty straightforward :-) OK for trunk.
>
> Thanks for the patch
>
> Paul
>
> On 11 January 2015 at 11:21, Jan
Hi all,
I have just committed as obvious a small patch for an ICE-on-invalid
problem with procedure-pointer components:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=219439
Cheers,
Janus
> Well done for sorting that out. OK for trunk.
Thanks, Paul. Committed as r219440.
What about the branches?
Cheers,
Janus
> On 11 January 2015 at 14:38, Janus Weil wrote:
>> Hi all,
>>
>> this patch fixes a wrong-code regression related to operators, by
>>
pdate the branches. We
> usually, propose delaying a bit but I am not convinced that this is
> effective for this kind of bug fix - usually, further problems take a
> long time to emerge. Thus, I would recommend that you get on with it.
>
> Thanks
>
> Paul
>
> On 11 Janu
Hi all,
the attached patch fixes an ICE-on-invalid problem with
procedure-pointer components by making sure that we continue resolving
all components of a derived type, even after an error is thrown.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2015-01-13 Janus Weil
Hi Mikael,
>> the attached patch fixes an ICE-on-invalid problem with
>> procedure-pointer components by making sure that we continue resolving
>> all components of a derived type, even after an error is thrown.
>>
> Does the fonction return false as before, whenever an error has been
> issued? I
target-memory.c part and the first test case to the
4.7 branch. Ok?
Cheers,
Janus
2012-11-05 Janus Weil
PR fortran/54917
* target-memory.c (gfc_target_expr_size,gfc_target_interpret_expr):
Handle BT_CLASS.
* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Add support for
Hi,
>> the attached patch implements support for polymorphic arguments to
>> TRANSFER. For details and discussion see the PR.
>>
>> Btw, as part of the PR is a regression in 4.7 and trunk, I would like
>> to backport the target-memory.c part and the first test case to the
>> 4.7 branch. Ok?
>
>
>
Hi all,
I have just committed an obvious patch for a recent OOP regression:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193568
Thanks to Damian for reporting ...
Cheers,
Janus
any comments, in
absence of which I will commit the patch to trunk by the end of this
week.
It was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7?
Cheers,
Janus
2012-11-19 Janus Weil
PR fortran/55352
* trans-decl.c (generate_local_decl): Don't warn for expli
> Thanks for the patch - it's OK for trunk and 4.7.
Thanks, Paul.
Committed to trunk as r193711. I will apply it to the 4.7 branch soon.
Cheers,
Janus
> On 19 November 2012 21:39, Janus Weil wrote:
>> Hi all,
>>
>> here is another contribution in trying
Hi Thomas,
> the attached patch fixes a 4.6/4.7/4.8 rejects-valid regression.
> OK for trunk?
looks good to me. Thanks for the patch. Ok for trunk and also for the
4.6/4.7 branches ...
Cheers,
Janus
> 2012-11-24 Thomas Koenig
>
> PR fortran/55314
> * resolve.c (resolve_all
2012/11/25 Mikael Morin :
> Le 11/10/2012 23:49, Janus Weil a écrit :
>
>> Hi all,
>>
>> here is an OOP patch for the above PR, which has two disconnected parts:
>>
>> 1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
>> function as argu
2012/11/25 Mikael Morin :
> Le 22/10/2012 16:49, Janus Weil a écrit :
>
>> Minor update to the patch: It now also sets TREE_USED for entry
>> masters in order to avoid bogus warnings for procedures with ENTRY
>> (cf. comment 6 in the PR, which like comment 0 is a 4.8
2012/11/27 Tobias Burnus :
> The problem is that the symbol gets the host-associated flag as soon as it
> is host associated even in the host's namespace. Solution: Test additionally
> whether they have been declared in the same namespace.
>
> (I wonder whether there is a case where the host-associ
Hi Tobias,
> effectively, this patch doesn't do anything. Except, it updates the –
> deactivated – finalization wrapper.
>
>
> Note: This patch does not include any code to actually call the finalization
> wrapper. Nor is the modified code ever called in gfortran. However, that
> patch paves the r
Hi,
>> one thing that I do not like about your patch is the modification of
>> "gfc_find_derived_vtab": You create two versions of it, one of which creates
>> the vtab if it does not exist, while the other version does not do this.
>> [...] can you explain to me why this would be necessary?
>
>
>
2012/11/30 Janus Weil :
> Hi,
>
>>> one thing that I do not like about your patch is the modification of
>>> "gfc_find_derived_vtab": You create two versions of it, one of which creates
>>> the vtab if it does not exist, while the other version does not d
_CLOCK yet). Ok for trunk?
Btw, does it make sense to also add an int2 version? If yes, which
resolution? Note that most other compilers seem to have an int2
version of SYSTEM_CLOCK ...
Cheers,
Janus
2012-12-01 Janus Weil
PR fortran/55548
* gfortran.map (GFORTRAN
Hi Janne,
thanks for your feedback ...
>> here is a straightforward patch for the intrinsic procedure
>> SYSTEM_CLOCK. It does two things:
>> 1) It reduces the resolution of the int8 version from 1 nanosecond to
>> 1 microsecond (COUNT_RATE = 100).
>> 2) It adds an int16 version with nanosec
improvement of the
SYSTEM_CLOCK behavior?
Cheers,
Janus
2012/12/1 Janus Weil :
> Hi all,
>
> here is a straightforward patch for the intrinsic procedure
> SYSTEM_CLOCK. It does two things:
> 1) It reduces the resolution of the int8 version from 1 nanosecond to
> 1 micro
>> Needing to link with librt in order to access clock_gettime is an
>> unfortunate wart in glibc, but other C libraries exist out there
>> (heck, given the success of Android, glibc is certainly a minority
>> even if you limit yourself to Linux), and of those that provide
>> clock_gettime, most ha
else has objections, together with a documentation
> patch and a ChangeLog entry, this is Ok for trunk.
thanks, Janne. Here is an updated patch with docu and ChangeLog. I
will wait another day before committing, in order to allow for further
comments.
Cheers,
Janus
2012-12-02 Janus Weil
Hi Tobias,
>> In my version of the patch I introduced a routine 'gfc_is_finalizable' to
>> perform this decision.
>
>
> Okay. How about the following patch? It's the same without the renaming.
>
> Build an regtested on x86-64-linux.*
> OK for the trunk?
Yes, looks ok to me. Thanks for the patch!
comments.
Committed as r194105.
Cheers,
Janus
> 2012-12-02 Janus Weil
>
> PR fortran/55548
> * intrinsics/system_clock.c (gf_gettime_mono): Add argument 'tck',
> which returns the clock resolution.
> (system_clock_4): Get resolution from gf_gettime_mo
Hi Thomas,
> the attached patch fixes a regression introduced with the recent
> checking for DO loop variables when they are used with a generic
> subroutine where the generic name matches one of the actual names.
>
> Regression-tested. OK for trunk?
A few questions about that patch:
- f =
Hi Tobias,
> The patch below is part of my FINAL patch. The NULL -> NULL_TREE change is
> obvious.
certainly ok.
> The expr to al->expr change is to pass a BT_CLASS instead of a
> BT_DERIVED. And the NULL to gfc_lval_expr_from_sym change allows to access
> var->_vtab->_final for a BT_CLASS defe
Btw, one nit about your ChangeLog:
2012-12-05 Tobias Burnus
* trans-array.c (gfc_deallocate_scalar_with_status): Use
NULL_TREE in the call to gfc_deallocate_scalar_with_status.
* trans-decl.c (gfc_trans_deferred_vars): Pass symbol.
* trans-stmt.c (gfc_trans_deallocate): Pass po
2012/12/4 Tobias Burnus :
> We freed the renamed symbol for intrinsic modules too early, if they
> actually exist on the disk as the name is used in trans*.c. (For "file"
> modules, the data is later freed with the namespace by calling
> gfc_free_use_stmts.)
>
> Build and regtested on x86-64-gnu-li
2012/12/8 Thomas Koenig :
> Am 08.12.2012 17:39, schrieb Janus Weil:
>
>> Hi Thomas,
>>
>>> the attached patch fixes a regression introduced with the recent
>>> checking for DO loop variables when they are used with a generic
>>> subroutine where the
rateful for
comments. In particular: Does it fix all the problems on AIX? (For
more open questions, see below.)
Cheers,
Janus
> On Thu, Oct 4, 2012 at 5:04 PM, Janus Weil wrote:
>>
>> unfortunately my previous patch regressed on the proc_ptr_result test
>> cases (due to
>> Here is a re-diffed version of my previous patch. I'd be grateful for
>> comments. In particular: Does it fix all the problems on AIX? (For
>> more open questions, see below.)
>
> IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
> i.e. anything that won't be TREE_STATIC.
; On 09.04.2012 18:31 Janus Weil wrote:
>>
>> Hi all,
>>
>> here is a simple patch for a problem recently reported by Andrew
>> Benson: Procedure pointers inside a module don't receive the proper
>> name mangling, which can lead to name collisions (as the te
2013/5/5 Jerry DeLisle :
> On 05/04/2013 06:30 PM, Steve Kargl wrote:
>> On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>>>
>>> CASE_SEPARATORS:/* Not a repeat count. */
>>> case EOF:
>>> +case '!':
>>
>> if (c == '!')
>> gfc_warning("GNU Fortra
Hi Tobias,
> GCC 4.7 added some additional checks for type-bound procedure overriding.
> However, doing so it weakened the check whether the nonpass argument has the
> same type.
>
> While for normal arguments, passing the parent type to an extended type is
> fine, for overriding the type (of nonp
Hi,
>> However, I'm not sure if the place where you do it is the most
>> preferable: I think it should rather go inside of
>> check_dummy_characteristics (since any check for the dummy
>> characteristics should include the 'strict' type check, and not only a
>> check of type compatibility, cf. F08
>>> However, I'm not sure if the place where you do it is the most
>>> preferable: I think it should rather go inside of
>>> check_dummy_characteristics (since any check for the dummy
>>> characteristics should include the 'strict' type check, and not only a
>>> check of type compatibility, cf. F08
>> in principle I think your idea to tighten up the type check by
>> symmetrizing it is ok.
>
> I actually kind of copied it from the proc-pointer assignment check, which
> does the same.
Btw, I think you refer to this piece of code in expr.c
(gfc_check_pointer_assign), right?
if (!gfc_com
Sorry for taking so long to come back to this (I was traveling all of
last week) ...
>> Ok, so: How about the attached patch as a simple & backportable fix for
>> the regression? (Ok for trunk/4.8/4.7?)
>
> I think that part is okay - but as you mentioned TYPE(*) in your last email:
> That doesn'
>> Anyway, anything in this direction is probably a non-regression and
>> should rather be handled as a follow-up. Is the current patch
>> (http://gcc.gnu.org/ml/fortran/2013-05/msg00045.html) ok for
>> trunk/4.8/4.7?
>
> OK.
Thanks. Committed to trunk as r199375. Will do 4.8 and 4.7 soon.
> Sti
>> A rather simple patch found while testing the draft finalization patch.
>>
>> For a "class(...), allocatable, intent(out)" dummy argument, the actual
>> argument has to be deallocated. That worked for scalar polymorphic vars, but
>> not for polymorphic arrays.
>
>
> Actually, it turned out to be
Hi Tobias,
> the attached patch now enables the *parsing* of "FINAL ::" - however, *no*
> finalization will be done. Adding FINALIZATION will be deferred to several
> follow-up patches.
>
> Build on x86-64-gnu-linux.
> OK for the trunk?
yes, ok from my side. It's definitely time to get the finali
Hi Tobias,
> Small re-diff - but essentially unchanged.
>
> (I made a thinko when adding a _final call to
> gfc_trans_class_array_init_assign: Not in all contexts the _final should be
> called, only for INTENT(OUT). Thus, I remove the _final call and deferred it
> to the actual finalization call.
Hi all,
I have just committed as obvious a small ICE-on-invalid fix:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199445
Cheers,
Janus
UMNS
(the corresponding code was borrowed from gcc/opts.c). Further, I
moved the function to error.c (which is the only place where it is
used), made it static and renamed it.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-05-30 Janus Weil
PR fortran/57
idea to use $COLUMNS (which is, e.g. set by the shell
> under Unix); however, if the variable is not available, I think one should
> keep the value 80.
>
>
>> 2013-05-30 Janus Weil
>>
>> PR fortran/57217
>> * gfortran. h (gfc_terminal_width): Remove protot
Hi,
>> In addition to this, the patch contains a part which concerns the
>> function 'gfc_terminal_width': Currently this returns a fixed value of
>> 80, which means that all source lines are trimmed to 80 characters in
>> the error messages. I increased this default value to 132 (in order to
>> a
>> Currently, ALLOCATE ignores the typespec for arrays. Such that:
>>ALLOCATE (t2 :: var(5))
>> will allocate as much memory as the base type requires instead of using as
>> much as "t2" does.
>>
>>
>> I explicitly exclude characters as it otherwise will fail for
>> allocate_with_typespec_1.f90
Hi Manfred,
>> Attached is a small patch with an alternative implementation (borrowed
>> from ada/terminals.c). It is not portable to all systems, but at least
>> it does actually work on my openSUSE box. Is this something we want to
>> have for gfortran?
>>
>
> # cat >term.c < #include
> #includ
> Wouldn't it work to use the TIOCGWINSZ ioctl only if isatty() reports
> that we're outputting to a terminal?
Good point. Updated patch attached, which imposes no limit if we're
not outputting to a terminal (as suggested by Mikael).
Ok for trunk, or am I missing anything else? (Testing welcome .
>>> Wouldn't it work to use the TIOCGWINSZ ioctl only if isatty() reports
>>> that we're outputting to a terminal?
>>
>>
>> Good point. Updated patch attached, which imposes no limit if we're
>> not outputting to a terminal (as suggested by Mikael).
>>
>> Ok for trunk, or am I missing anything else
>> Index: gcc/fortran/error.c
>> ===
>> --- gcc/fortran/error.c (revision 199530)
>> +++ gcc/fortran/error.c (working copy)
>> @@ -30,6 +30,13 @@ along with GCC; see the file COPYING3. If not see
>> #include "flags.h"
>>
>> Ok. Unfortunately I'm not much of a autoconf hero (better to say: not
>> at all).
> Any person using autoconf is some of a hero. ;-)
Totally ...
>> I can not test it on my system with --enable-maintainer-mode
>> because I get:
>>
>> configure.ac:2: error: Please use exactly Autoconf 2.64 inst
Hi all,
here is a straightforward patch for an ICE-on-invalid problem, which
basically adds some checks for 'class_ok'.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-07-24 Janus Weil
PR fortran/57639
* interface.c (compare_parameter): Check fo
2013/7/24 Steve Kargl :
> On Wed, Jul 24, 2013 at 11:53:09PM +0200, Janus Weil wrote:
>> Hi all,
>>
>> here is a straightforward patch for an ICE-on-invalid problem, which
>> basically adds some checks for 'class_ok'.
>>
>> Regtested on x86_64-un
trunk?
Cheers,
Janus
2013-07-25 Janus Weil
PR fortran/57966
* resolve.c (resolve_typebound_function): Make sure the declared type,
including it's type-bound procedures, is resolved before resolving the
actual type-bound call.
2013-07-25 Janus Weil
PR for
2013/7/25 Tobias Burnus :
> Janus Weil wrote:
>>
>> here is a small patch for a rejects-valid OOP problem, where a
>> type-bound call was resolved before the base type and its bindings.
>> I'm adding a call to resolve_fl_derived, in order to make sure that
>>
2013/7/25 Tobias Burnus :
> Janus Weil wrote:
>>
>> 2013/7/25 Tobias Burnus :
>>
>>> Looks fine to me. (If I tracked the PR correctly, it only solves the
>>> original problem but not yet the one of comment 5, does it?)
>>
>> No, this one should
Committed as r201254.
Cheers,
Janus
2013/7/25 Janus Weil :
> 2013/7/25 Tobias Burnus :
>> Janus Weil wrote:
>>>
>>> 2013/7/25 Tobias Burnus :
>>>
>>>> Looks fine to me. (If I tracked the PR correctly, it only solves the
>>>>
Hi Tobias,
> This patch is a follow up to the resolve part, which permits TYPE=>CLASS.
> That approved patch is at
> http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html (I didn't want to
> commit it without this trans*.c patch.)
>
> The attached patch adds support for:
>TYPE => CLASS
> additi
nd version.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-07-26 Janus Weil
PR fortran/57306
* trans-decl.c (gfc_get_symbol_decl): Treat class pointers.
* trans-expr.c (gfc_conv_initializer): Ditto.
2013-07-26 Janus Weil
PR fortran/57306
* g
Hi,
>>> OK for the trunk?
>>
>> yes, the patch looks basically ok to me. Just one thing I did not
>> quite understand:
>>
>> + /* It can happen that the LHS has BT_DERIVED but it is in reality
>> + a polymorphic variable. */
>>
>> How exactly can it happen that a polymorphic variable is
Hi all,
I have just committed an obvious minus-two-line patch to re-enable an
error message for CLASS arrays (after a successful regtest):
http://gcc.gnu.org/viewcvs?rev=201284&root=gcc&view=rev
Cheers,
Janus
> I think that Janus's OK of the 27th was already enough :-)
>
> The tweaks that you have made since make it look much cleaner. So,
> once more - OK for trunk.
Agreed. Sorry for the late reply,
Janus
> On 27 July 2013 21:51, Tobias Burnus wrote:
>> Tobias Burnus wrote:
>>>
>>> Giving up on t
Hi Tobias,
>> here is a fix for class pointer initialization.
>
> I think the patch looks reasonable.
well, it may appear so ...
> Additionally, the CLASS are wrongly initialized: You only set "_data"
> (indirectly as it is the first field/component of the class) but you do not
> set the _vptr
2013/7/29 Janus Weil :
> Hi Tobias,
>
>>> here is a fix for class pointer initialization.
>>
>> I think the patch looks reasonable.
>
> well, it may appear so ...
>
>
>> Additionally, the CLASS are wrongly initialized: You only set "_data"
&
>> The attached new version should do the right thing now. At least it
>> shows the correct dump for the original test case as well as yours. It
>> is currently being regtested.
>
> unfortunately it shows a couple of runtime problems with type-bound operators:
>
> FAIL: gfortran.dg/class_defined_op
2013/7/30 Janus Weil :
>>> The attached new version should do the right thing now. At least it
>>> shows the correct dump for the original test case as well as yours. It
>>> is currently being regtested.
>>
>> unfortunately it shows a couple of runtime
ping!
2013/7/30 Janus Weil :
>> The attached update fixes it, and thus should hopefully be
>> regression-free. It also renames 'gfc_class_null_initializer' to
>> 'gfc_class_initializer', since it now also does other initializations
>> beside EXPR_NULL
Hi all,
the attached patch plugs a memory leak of the TRANSFER intrinsic,
which can occur when transferring to CHARACTER strings. For details
see the PR.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
Cheers,
Janus
2013-08-03 Janus Weil
PR fortran/58058
* trans
elow.
>
> Well, the test case does not check whether it works. You either need to
> check the dump - or you need to use dg-do run.
Good point. The intention was to use dg-do run, of course.
Anyway, thanks for the review. Is it ok to commit the patch as is and
defer the tr
>> Looking at gfc_class_initializer, I have the impression that it does not
>> handle initialization of unlimited polymorphic variables/components. I don't
>> know whether initialization is permitted, but my feeling is that the
>> following should work:
>>
>> type t
>> class(*), pointer :: x
>> e
Hi,
> Sorry for the belated review.
>
> + bool ptr = sym->attr.pointer || sym->attr.allocatable
> +|| (sym->ts.type == BT_CLASS
> +&& CLASS_DATA (sym)->attr.class_pointer);
>
>
> That looks quite imbalanced. Why do you not take care of
> CLASS_DATA(sym)->at
>> Sorry for the belated review.
>>
>> + bool ptr = sym->attr.pointer || sym->attr.allocatable
>> +|| (sym->ts.type == BT_CLASS
>> +&& CLASS_DATA (sym)->attr.class_pointer);
>>
>>
>> That looks quite imbalanced. Why do you not take care of
>> CLASS_DATA(sym)
Hi Thomas,
> the rather self-explanatory patch implements the -Wzerotrip
> option. The positive form is not really useful, because
> the option is on by default (so the default behavior is
> not changed).
>
> The negative form of the option, -Wno-zerotrip, suppresses the
> warning. I have also a
Hi all,
attached is a cleanup patch which concerns the gfc_code structure and
gfc_get_code function (in st.c). It basically does two things:
1) It replaces the many occurrences of "XCNEW (gfc_code)" in class.c
by "gfc_get_code ()", which internally sets the locus and saves us
from doing it manual
twice with exchanged arguments.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-08-07 Janus Weil
PR fortran/58099
* expr.c (gfc_check_pointer_assign): Remove second call to
'gfc_compare_interfaces' with swapped arguments.
* i
ping!
2013/8/3 Janus Weil :
> Hi all,
>
> the attached patch plugs a memory leak of the TRANSFER intrinsic,
> which can occur when transferring to CHARACTER strings. For details
> see the PR.
>
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
>
> Cheer
Hi Mikael,
>>> the attached patch plugs a memory leak of the TRANSFER intrinsic,
>>> which can occur when transferring to CHARACTER strings. For details
>>> see the PR.
>>>
>>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
>>>
> Looks good, yes.
> Thanks.
thanks a lot for the revie
2013/8/9 Mikael Morin :
> Le 06/08/2013 17:12, Janus Weil a écrit :
>> Hi all,
>>
>> attached is a cleanup patch which concerns the gfc_code structure and
>> gfc_get_code function (in st.c). It basically does two things:
>>
>> 1) It replaces the many occur
2013/8/11 Thomas Koenig :
> Hi Janus,
>
>> So: Ok for trunk from my side.
>>
>> However, I would prefer to disable the warning by default, but include
>> it in -Wall.
>
> Here's a patch to do just that.
>
> Regression-tested (hence the changes to the existing test cases :-)
>
> OK for trunk?
Looks
Hi Mikael,
>> here is a small regression-fix patch for a problem with procedure
>> pointers and the PURE attribute, for details see the PR. In essence:
>> gfc_compare_interfaces is asymmetric in the two interfaces it compares
>> (e.g. regarding the PURE attribute), and we must not symmetrize it by
Janus Weil
PR fortran/46271
* openmp.c (resolve_omp_clauses): Bugfix for procedure pointers.
2013-08-18 Janus Weil
PR fortran/46271
* gfortran.dg/gomp/proc_ptr_1.f90: New.
pr46271.diff
Description: Binary data
proc_ptr_1.f90
Description: Binary data
401 - 500 of 781 matches
Mail list logo
