, however, is that
I prevent gfc_build_class_symbol from being called if no type symbol
is available.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2013-08-19 Janus Weil
PR fortran/58185
* match.c (copy_ts_from_selector_to_associate): Don't build
Committed as r201835 ...
2013/8/18 Janus Weil :
> Hi all,
>
> here is a pretty-much-trivial patch for a problem with OpenMP and
> procedure pointers (proc-ptrs to functions are working, but not
> subroutines).
>
> Regtested on x86_64-unknown-linux-gnu. Will commit as obv
Hi Tobias,
> The issue is a regression which exists since GCC 4.4. The fix is rather
> obvious (see also PR).
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk and the two maintained branches, 4.6 and 4.7?
yes, looks good to me (pretty much obvious).
It seems the 4.8 release is qui
vious draft patches in
the PR and simultaneously fixes both comment 0 and 1. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-03-20 Janus Weil
PR fortran/56500
* symbol.c (gfc_set_default_type): Build class container for
IMPLICIT CLASS.
2013-03-20 Janus
Ping!
(I hope I didn't "anti-advertise" this patch too much ;)
2013/3/20 Janus Weil :
> Hi all,
>
> here is a simple patch which fixes some problems with IMPLICT
> CLASS(...) statements. Actually that's not a feature I would seriously
> recommend anyone to u
>> Ping!
>>
>> (I hope I didn't "anti-advertise" this patch too much ;)
>>
>>
>> 2013/3/20 Janus Weil :
>>>
>>> Hi all,
>>>
>>> here is a simple patch which fixes some problems with IMPLICT
>>> CLASS(.
nux-gnu. Ok for trunk?
Cheers,
Janus
2013-04-01 Janus Weil
PR fortran/56284
PR fortran/40881
* decl.c (gfc_match_formal_arglist): Warn about alternate-return
arguments.
* interface.c (check_dummy_characteristics): Return if symbols are NULL.
2013-04-01 Janus Weil
P
gt;> patch).
>
> Or it is not unreachable but leads to double-diagnostic which is not better,
> either.
Right.
>> The patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> OK with the -std= change. (Please run "make
> RUNTESTFLAGS="dg.exp=..f90&quo
RUNTESTFLAGS="dg.exp=..f90" prior committal to check whether it indeed
>> works with -std=gnu.)
>
> All of them still work with std=gnu.
I have just committed the patch as 197389.
Will take care of removing the double diagnostics next. Also I just
noticed that there still seem to
were removed by my editor.)
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-04-03 Janus Weil
PR fortran/40881
* match.c (gfc_match_return): Remove standard notification.
* primary.c (gfc_match_actual_arglist): Add standard notification.
2013-04-03 Janus
>> As my editor shows, that file uses DOS line endings (\r\n) in some lines and
>> UNIX ones (\n) in others. In principle, I am for keeping such files to test
>> the parser.
>
> If one keeps them, please put them into a file that tests for that feature
> exclusively, as we often find turds, oops
2013/4/7 Tobias Burnus :
> A rather obvious patch after one realizes that order= doesn't affect shape=.
Right.
> Build & regtested on x86-64-gnu-linux.
> OK for the trunk?
Yes, thanks for the patch!
Cheers,
Janus
diagnostics for these).
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-04-07 Janus Weil
PR fortran/56261
* interface.c (gfc_procedure_use): Error on polymorphic actual arguments
passed to implicit interface.
* resolve.c (resolve_global_procedure): Don&#
>> It is nontrivial to detect this in every case (e.g. passing a TYPE
>> actual to a CLASS formal arg), but at least we can easily detect it if
>> a polymorphic *actual* argument is involved (which means that the
>> corresponding formal arg must also be polymorphic).
>
>
> Sorry, I cannot follow he
2013/4/7 Tobias Burnus :
>>> Thus, the only place where the check can be is for:
>>>
>>>f => ff
>>>
>>> In your example, the explicit interface of "ff" is known thus it should
>>> be
>>> testable at resolution time of the proc-pointer assignment.
>>
>> Right. However, strictly speaking, the poi
>> One leftover problem: The patch currently fails on the auto_char_len_4
>> test case, which is not being rejected any more. Actually I'm not
>> fully convinced that the dg-errors there are correct: If the EXTERNAL
>> statements in auto_char_len_{1,2} do not trigger an "explicit
>> interface requi
>> Ok, here is an updated patch, which does the discussed checking for
>> procedure pointer assignments. For this I have introduced a new
>> function 'gfc_explicit_interface_required', which checks all the items
>> in F08:12.4.2.2 and is loosely based on the present checks in
>> 'resolve_global_pro
> [Btw, I also thought about doing a full "gfc_compare_interfaces" in
> "resolve_global_procedure", but that would probably be too strict.]
Comment to self: It's certainly more strict, but I think this is a
good thing. I just tried it and in fact it catches a number of cases
in the testsuite, whic
2013/4/11 Tobias Burnus :
> Am 11.04.2013 16:23, schrieb Janus Weil:
>
>>> [Btw, I also thought about doing a full "gfc_compare_interfaces" in
>>> "resolve_global_procedure", but that would probably be too strict.]
>>
>> Comment to self: I
Hi Tobias,
> An unallocated polymorphic variable has the declared type; however, for
> static (SAVE) variables, the current code didn't set the value.
>
> (That the end of scope deallocation/_gfortran_caf_deregister is gone for
> coarrays (declared in the main program) was a side effect. The
> syn
>>> Thus, I think one should be strict about the requires-explicit-interface
>>> diagnostic (= new code, using F90+), but for interface mismatch (= could
>>> be
>>> old Fortran 66 code), it should be either disabled or - as currently -
>>> just
>>> be a warning.
>>
>> How about enabling it by defa
2013/4/12 Tobias Burnus :
> Am 12.04.2013 00:05, schrieb Janus Weil:
>
>> Just one minor nit:
>>
>> + if (sym->ts.type == BT_CLASS && TREE_STATIC (sym->backend_decl)
>> + && CLASS_DATA (sym)->attr.allocatable)
>>
>> I&
2013/4/12 Tobias Burnus :
> Am 12.04.2013 00:17, schrieb Janus Weil:
>
>>> Hmm, I think I'd prefer to have for the arguments only a warning with
>>> -std=gnu - except for the function result value, which should always be
>>> an
>>> error. And also the
eLog that I will commit later today.
Cheers,
Janus
2013-04-12 Janus Weil
PR fortran/56261
* gfortran.h (gfc_explicit_interface_required): New prototype.
* expr.c (gfc_check_pointer_assign): Check if an explicit interface is
required in a proc-ptr assignment.
* inte
> Allocatable scalar coarrays use an error descriptor...
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Ok (looks pretty much obvious).
Thanks,
Janus
e has a better idea how to treat this, I will commit the
attached patch as obvious.
Cheers,
Janus
2013-04-12 Janus Weil
PR fortran/56266
* primary.c (gfc_match_varspec): Turn gcc_assert into MATCH_ERROR.
2013-04-12 Janus Weil
PR fortran/56261
* gfortran.dg/typebound_proc_28
Hi all,
here is another trivial ICE-on-invalid fix that I will commit later
today (as obvious & regtested on x86_64-unknown-linux-gnu).
Cheers,
Janus
2013-04-13 Janus Weil
PR fortran/55959
* expr.c (gfc_simplify_expr): Branch is not unreachable.
2013-04-13 Janus Weil
Hi Tilo,
> I would like to backport the fix for PR51825 I posted here
>
> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html
>
> to the 4.8 branch.
well, the usual gfortran policy is to only do backports of regression
fixes. In exceptional cases, also non-regression fixes can be
backported (
Hi Mikael,
>> Unless someone has a better idea how to treat this, I will commit the
>> attached patch as obvious.
>>
> Not really a better idea, but it seems to me that function calls can
> have trailing sub-references, so that gfc_match_varspec could be called
> on them.
>
> gfc_match_rvalue has:
>> Indeed, that's invalid:
>>
> And then, the call to gfc_match_varspec shouldn't be there in the first
> place. I'll test the following later.
It seems like the parts you're removing have essentially been there
since day zero. Would be interesting to know if (and where) your patch
fails.
Cheers
Hi Mikael,
>> And then, the call to gfc_match_varspec shouldn't be there in the first
>> place. I'll test the following later.
>
> It seems like the parts you're removing have essentially been there
> since day zero. Would be interesting to know if (and where) your patch
> fails.
actually I just
Hi all,
here is patch for a recent regression with procedure pointers.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2013-04-17 Janus Weil
PR fortran/56814
* interface.c (check_result_characteristics): Get result from interface
if present.
2013-04
iew my C_LOC patch at
> http://gcc.gnu.org/ml/fortran/2013-04/msg00073.html ?
Will try to have a look soon ...
Cheers,
Janus
>> 2013-04-17 Janus Weil
>>
>> PR fortran/56814
>> * interface.c (check_result_characteristics): Get result from
>> interfa
Hi Tobias,
> Fortran 2008 supports C_LOC(array); if the argument is not simply
> contiguous, the current code adds a call to __gfortran_intrinsic_pack.
>
> The pack call shouldn't be there. Fortran 2008 demands that the actual
> argument is contiguous and intrinsic_pack copy creates a copy if the
>> What I don't quite understand is:
>> @@ -6317,8 +6317,13 @@ conv_isocbinding_function (gfc_se *se, gfc_expr
>> *expr)
>> {
>> if (arg->expr->rank == 0)
>> gfc_conv_expr_reference (se, arg->expr);
>> - else
>> + else if (gfc_is_simply_contiguous (arg->expr, false))
>
>>> Well, it does: As it doesn't know whether the array is contiguous or not
>>> - it packs the array. That's what one usually wants. However, for C_LOC one
>>> knows that the array is contiguous - the user promises this to the compiler
>>> - and, hence, no packing is needed.
>>
>> Ok, I see. Then
lightly modified (and now more consistent) behavior of
'gfc_target_expr_size'.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk? 4.7/4.8?
Cheers,
Janus
2013-04-21 Janus Weil
PR fortran/57022
* check.c (gfc_calculate_transfer_sizes): Fix for array-valued SOURCE
expression
Hi Mikael,
> Two comments below:
>
>> Index: gcc/fortran/check.c
>> ===
>> --- gcc/fortran/check.c (revision 198108)
>> +++ gcc/fortran/check.c (working copy)
>> @@ -4456,7 +4455,7 @@ gfc_calculate_transfer_sizes (gfc_exp
attached. One more regtest, then commit ...
Thanks to everyone for the careful reviews!
Cheers,
Janus
2013-04-22 Janus Weil
PR fortran/53685
PR fortran/57022
* check.c (gfc_calculate_transfer_sizes): Fix for array-valued SOURCE
expressions.
* simplify.c (gfc_simplify_
2013/4/22 Tobias Burnus :
> Am 22.04.2013 20:00, schrieb Janus Weil:
>>>
>>> >Side remark and just for completeness, there is also rank == -1 for
>>> >assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
>>> >shouldn't reach
Hi Paul,
> This is a straightforward patch that is completely described in the
> ChangeLog entry. I am surprised that this could be a 4.8 regression
> since, as far as I am aware, SELECT_TYPE was not capable of handling
> array selectors before... Nonetheless, it flagged it up for me :-)
well, ac
>> Did you bootstrap & test the 4.7 backport?
>>
> Yes, works like a charm here.
I also see the build problem (configuring with
"--enable-languages=c,fortran --disable-bootstrap").
>> Looks like you committed C++ code there, in module.c:
>> ...
>> 3867 static void
>> 3868 skip_list (int ne
Hi all,
the attached patch fixes an OOP-related 4.7-only regression. Pretty
much straightforward, for details see PR.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
Cheers,
Janus
2014-02-02 Janus Weil
PR fortran/59941
* expr.c (replace_comp): Check for isym to avoid ICE
>> the attached patch fixes an OOP-related 4.7-only regression. Pretty
>> much straightforward, for details see PR.
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
>>
> Yes, thanks.
Thanks, Mikael. Committed as r207417.
Cheers,
Janus
s added to work around some other problem in the finalization
implementation, and there is no evidence it's actually needed.
The patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-06 Janus Weil
PR fortran/58470
* resolve.c (resolve_fl_de
Hi Mikael,
thanks for your comments ...
>> attached is a small patch which fixes an ICE-on-invalid regression
>> with finalization. In the PR, Dominique objected to the patch, but I
>> think it's the correct thing to do after all. The line that I'm
>> removing was added in a patch authored by Tob
> But after all I think that the patch should not hurt. After giving it
> some second thoughts, the only alternative I could see is this:
>
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c(revision 207485)
> +++ gcc
Hi Mikael,
thanks for your suggestions and the approval of the patch.
>> maybe add gcc_assert to
>> make it clear that fini->proc_tree should be set at this point.
> Or better: a comment ;-)
I'm going for the gcc_assert *plus* a comment ;)
The thusly updated patch in the attachment regtests cle
2014-02-08 22:47 GMT+01:00 Steve Kargl :
> On Sat, Feb 08, 2014 at 10:28:24PM +0100, Dominique Dhumieres wrote:
>> > I can't remember. Do you have commit privilege?
>>
>> No.
>>
>> > If not, why?
>>
>> Probably because I did not asked for it explicitly.
>> I have only hinted a couple time that I h
Hi all,
here is a small patch for a ICE-on-valid regression. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
Cheers,
Janus
2014-02-16 Janus Weil
PR fortran/55907
* resolve.c (build_default_init_expr): Don't initialize character
variable if -fno-automatic is
> This is OK for trunk, 4.8 and 4.7.
Thanks, Paul. Committed to trunk as r207823. Will do the backports soon.
Cheers,
Janus
> On 16 February 2014 23:11, Janus Weil wrote:
>> Hi all,
>>
>> here is a small patch for a ICE-on-valid regression. Regtested on
>> x8
Hi all,
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2014-02-17 Janus Weil
PR fortran/60231
* resolve.c (check_generic_tbp_ambi
2014-02-17 21:36 GMT+01:00 Tobias Burnus :
> Janus Weil wrote:
>>
>> attached is a patch for an ICE-on-invalid problem with generics: We
>> simply don't check if any dummy args are present.
>
> There is something odd with your test case - and possibly with the pa
2014-02-18 7:56 GMT+01:00 Tobias Burnus :
>
> Am 17.02.2014 21:51, schrieb Janus Weil:
>
>> 2014-02-17 21:36 GMT+01:00 Tobias Burnus :
>>>
>>> Janus Weil wrote:
>>>>
>>>> attached is a patch for an ICE-on-invalid problem with generics:
Hi Tobias,
> This patch fixes an ICE on valid error - and a missed diagnostic.
>
> Wording from the standard F2008, Corr2:
>
> C729 (R742) A shall be the name of a module or dummy
> procedure, a specific intrinsic function listed in 13.6 and not marked with
> a bullet ($\bullet$), a procedure poi
corresponding procedure-pointer component in the vtab.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-19 Janus Weil
PR fortran/60232
* expr.c (gfc_get_variable_expr): Don't add REF_ARRAY for dimensionful
functions, which are used as proc
Hi,
>> The problem is this: When using a dimensionful function as an
>> EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
>> we wrongly add a REF_ARRAY, because we are tricked to believe that the
>> expression is dimensionful
>
>> The patch was regtested on x86_64-unknown-linux
Hi all,
the patch below has been posted a long time ago, but was never
actually committed (although it seems close to being finished).
Could it still be considered for trunk? I think it is a rather popular
feature, which would be helpful for many users ...
Cheers,
Janus
2013-03-19 22:17 GMT+0
l cases, I think it cannot hurt to add more cases that
work for 4.9 (even if still not all possible cases work).
Please let me know what you think ...
Cheers,
Janus
2014-02-19 16:16 GMT+01:00 Janus Weil :
> Hi all,
>
> the patch below has been posted a long time ago, but was never
&
Hi Tobias,
> A rather simple patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
the patch looks pretty much trivial, int the sense that you just
hard-wire the expected values for the std* units as a special case. I
wonder why the 'inquire_read' and 'inquire_write' functions d
Hi,
>> > Build and regtested on x86-64-gnu-linux.
>> > OK for the trunk?
>>
>> the patch looks pretty much trivial, int the sense that you just
>> hard-wire the expected values for the std* units as a special case. I
>> wonder why the 'inquire_read' and 'inquire_write' functions don't
>> actually
I think Paul at some point already started preparations for a
trans-class.c). However, this is a major effort and clearly can not be
tackled before the next stage 1.
Anyway, the patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-20 Janus Weil
2014-02-21 8:25 GMT+01:00 Tobias Burnus :
> Hi Janus,
>
> Janus Weil wrote:
>>
>> What the patch does is to defer the building of the vtabs to a later
>> stage. Previously this was done only for some rare cases, now we do it
>> basically for all vtabs. This is n
Hi Mikael, hi all,
2014-02-22 16:38 GMT+01:00 Mikael Morin :
> Le 19/02/2014 16:51, Janus Weil a écrit :
>> The patch was not applying cleanly any more, so here is a re-diffed
>> version for current trunk. It works nicely on the included test case
>> as well as the one provi
Hi Mikael,
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
> I'm asking for one more minor change, namely:
>
>> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> return false;
>> }
>>
>> + /* Add the hidden deferred length field. */
>> +
s, please let me know.
Also Tobias already told me privately that his "mixed feeling" were
not strong enough to oppose against committing the patch. So right now
the only thing standing between the patch and trunk seems to be you ;)
Cheers,
Janus
> On Mar 5, 2014 2:53 PM, "J
Hi,
> In that case, go for it! I am on vacation in Tenerife right now and have
> very limited access.
wow, in that case I guess you better enjoy your holidays ;)
> Please commit the patch to trunk.
Will do!
Thanks,
Janus
> On Mar 6, 2014 9:59 PM, "Janus Weil"
>> Please commit the patch to trunk.
>
> Will do!
I have just committed the patch as r208386, thereby implementing
deferred-length character components on 4.9 trunk. One big plea to the
users: Please test this as soon as possible!
Cheers,
Janus
>> On Mar 6, 2014 9:59 PM, &
2014-03-08 8:38 GMT+01:00 Tobias Burnus :
> An update the gfortran.texi's F2003/F2008 status.
>
> OK for the trunk?
Sounds good. Ok!
Cheers,
Janus
Hi Mikael,
> here is a fix for a wrong code issue, where we pass a descriptor with
> broken bounds when the actual argument is a transposed array and the
> dummy an assumed shape dummy.
> The bug comes from the interaction of the transpose optimization,
> which creates a descriptor with transposed
modified behavior.
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Cheers,
Janus
2014-03-14 Janus Weil
PR fortran/55207
* decl.c (match_attr_spec): Variables in the main program implicitly
get the SAVE attribute in Fortran 2008.
2014-03-14
>> Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
>> next stage1?
>
> Looks good to me - and simple enough for the 4.9 trunk.
Thanks, committed as r208590.
Cheers,
Janus
Hi Tobias,
> this patch fixes a problem with the conversion of scalars to descriptors.
> There one assigns the address of the scalar to the base_address field of the
> descriptor. The ICE occurred when the RHS (the scalar) wasn't a pointer.
looks good to me. Ok for trunk!
> It does not fully so
Ok, so here is a new patch, updated according to the suggestions of
David and Jakub. This now only touches the dotted variables, which are
responsible for the AIX trouble. Whether the same prefixing should
also be applied in other cases, we can still decide later.
> The remaining question is if th
2012/12/11 Jakub Jelinek :
> On Tue, Dec 11, 2012 at 12:16:33PM +0100, Janus Weil wrote:
>> Ok, so here is a new patch, updated according to the suggestions of
>> David and Jakub. This now only touches the dotted variables, which are
>> responsible for the AIX trouble. Wheth
ABORT gives a backtrace recently).
Ok for trunk?
Cheers,
Janus
2012-12-14 Janus Weil
PR fortran/36044
* gfortran.h (gfc_isym_id): Add GFC_ISYM_SHOW_BACKTRACE.
* intrinsic.c (add_subroutines): Add "show_backtrace".
* intrinsic.texi (SHOW_BACKTRACE): Document SHOW
Btw: Forgot to mention that it regtests cleanly and the docu parts
were tested with make pdf.
Cheers,
Janus
2012/12/14 Janus Weil :
> Hi all,
>
> here is another attempt to make gfortran support user-requested backtraces.
>
> A patch in this direction was already proposed by F
Hi Thomas,
wrong patch attached? It contains a hunk in frontend-passes.c, which
seems totally unrelated ...
Cheers,
Janus
2012/12/15 Thomas Koenig :
> Hello world,
>
> the attached patch fixes the regression and regtests cleanly.
> No test case because I could not find anything portable
> to c
Hi Janne,
>> here is another attempt to make gfortran support user-requested backtraces.
>>
>> [...]
>>
>> Ok for trunk?
>
> Some comments.
thanks for your comments ...
> - I'd prefer to reverse the name, e.g. BACKTRACE_{SHOW,PRINT,SPLURGE},
> to make it more "discoverable" when browsing the ma
Hi,
>> So, in principle I'm fine with all your BACKTRACE_* variants (except
>> for _splurge, maybe ;)
>>
>> Or, why not just (plain and simple) "BACKTRACE"?
>
> The name is the same as backtrace() in glibc, but otherwise, sure why
> not. _show/_print might be preferable in the sense that they conv
Hi all,
here is a patch for a pretty bad wrong-code regression, which affects
all maintained releases of gfortran. For discussion see bugzilla.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.6, 4.7 and trunk?
Cheers,
Janus
2012-12-15 Janus Weil
PR fortran/55072
* trans-array.c
Hi Tobias,
>> here is a patch for a pretty bad wrong-code regression, which affects
>> all maintained releases of gfortran. For discussion see bugzilla.
>>
>> 2012-12-15 Janus Weil
>> PR fortran/55072
>> * trans-array.c (gfc_conv_array_parameter):
>>So, in principle I'm fine with all your BACKTRACE_* variants (except
>>for _splurge, maybe;)
>>
>>Or, why not just (plain and simple) "BACKTRACE"?
>>>
>>> >The name is the same as backtrace() in glibc, but otherwise, sure why
>>> >not. _show/_print might be preferable in the s
Hi,
first off: Some more words on the naming issue. I actually still
prefer the most simple and straightforward variant (i.e. BACKTRACE,
which can easily be found and does not sound 'clumsy') ...
Or, why not just (plain and simple) "BACKTRACE"?
>>>
>>> The name is the same as backtrace() in
>> Attached is a new patch, which expands the documentation according to
>> your proposal, and uses the name BACKTRACE. I hope that both Janne and
>> Tobias can agree with this naming decision ...
>
> Looks fine from my side.
Great, thanks. Janne?
> Can you also add a quip to
> http://gcc.gnu.or
> I admit that the BACKTRACE announcement is slightly premature, but I assume
> that Janus will commit the patch very soon.
yes, it's only a matter of a few hours now ;)
Cheers,
Janus
Attached is a new patch, which expands the documentation according to
your proposal, and uses the name BACKTRACE. I hope that both Janne and
Tobias can agree with this naming decision ...
>>>
>>> Looks fine from my side.
>>
>> Great, thanks. Janne?
>
> Yes, Ok for trunk.
Thanks agai
. Ok for trunk?
Cheers,
Janus
2012-12-28 Janus Weil
PR fortran/55692
* check.c (gfc_check_associated): Remove a "gcc_assert (0)".
2012-12-28 Janus Weil
PR fortran/55692
* gfortran.dg/associated_7.f90: New.
pr55692.diff
Description: Binary data
associ
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Thanks, Tobias. Committed as r194744.
Cheers,
Janus
>> 2012-12-28 Janus Weil
>>
>> PR fortran/55692
>> * check.c (gfc_check_associated): Remove a "gcc_assert (0)".
>>
>> 2012-
Hi Mikael,
> here is a fix for PR42769, where a type bound call was resolved statically
> into a normal procedure call, but using the local procedure (with the same
> name) instead of the original (and correct) one.
> It turned out to not be OOP specific, and be a pure module loading problem
> in
Ping! (What do we do with this little bugger?)
@Paul: Was your comment 19 in the PR meant as an OK for my patch
(submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
or was it just a general agreement with the previous comments?
Cheers,
Janus
2012/12/16 Janus Weil :
>
Hi Mikael,
>> Ping! (What do we do with this little bugger?)
>>
>> @Paul: Was your comment 19 in the PR meant as an OK for my patch
>> (submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
>> or was it just a general agreement with the previous comments?
>>
> FWIW, I regard the pa
> OK by me for trunk, followed by 4.6 and 4.7.
Thanks, Paul. Committed to trunk as r195125. Will do the branches soon.
Cheers,
Janus
> On 11 January 2013 21:51, Mikael Morin wrote:
>> Le 11/01/2013 21:31, Janus Weil a écrit :
>>
>>> Thanks for your review (wh
Hi Paul,
> It is something of an exaggeration to say that this PR is a regession,
> although it is true that gcc-4.7 gives error messages for the testcase
> in the correct places. In fact, these messages disappear if IMPLICIT
> INTEGER (a) at the start of the testcase.
>
> The fix ensures that th
?
Cheers,
Janus
2013-01-16 Janus Weil
PR fortran/55983
* class.c (find_typebound_proc_uop): Check for f2k_derived instead of
asserting it.
2013-01-16 Janus Weil
PR fortran/55983
* gfortran.dg/class_55.f90: New.
pr55983.diff
Description: Binary data
class_55.f90
> As you say, this is close to being obvious - OK for trunk and for 4.7.
Thanks, guys. Committed to trunk as 195251. Will do 4.7 soon ...
Cheers,
Janus
> On 16 January 2013 15:08, Janus Weil wrote:
>> Hi all,
>>
>> here is a close-to-obvious patch for an ICE-o
for 4.8? Or should it wait for 4.9?
Cheers,
Janus
2013-01-18 Janus Weil
PR fortran/46952
* resolve.c (resolve_call): Do not check deferred procedures for
recursiveness.
2013-01-18 Janus Weil
PR fortran/46952
* gfortran.dg/typebound_deferred_1.f90: New.
pr46952_v2
Hi Jakub,
> Fortran OOP is still to be considered completely unsupported in OpenMP,
> but this patch just attempts to fix this because it was easy to do so.
> The select_type_temporary vars are artificial (created by the compiler,
> not user vars), we shouldn't emit them into debug info, nor they
class arrays are allowed).
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7?
Cheers,
Janus
2013-01-23 Janus Weil
PR fortran/56081
* resolve.c (resolve_select): Add argument 'select_type', reject
non-scalar expressions.
(resolve_select_type,resolve_code)
2013/1/23 Steve Kargl :
> On Wed, Jan 23, 2013 at 09:18:45PM +0100, Janus Weil wrote:
>>
>> here is a regression fix for an ICE-on-invalid bug with SELECT CASE.
>> The check to reject non-scalar selectors had been present in 4.6, but
>> was apparently removed when CL
501 - 600 of 781 matches
Mail list logo
