2016-11-26 17:37 GMT+01:00 Dominique d'Humières :
>
>> Le 26 nov. 2016 à 10:45, Janus Weil a écrit :
>>
>> ping!
>>
> The patch is working has expected. Note the removed block has been introduced
> by Daniel Franke at r126826.
Right, thanks for the referen
>> If not, we definitely need to fix the documentation of LTIME, since
>> the current version simply does not work with TIME8(), unless one uses
>> -fdefault-integer-8 (which is not mentioned in the docu).
>
> What about the attached patch
Yes, looks good to me. Ok to commit!
One minor nit (optio
Tobias Burnus
PR fortran/58175
* resolve.c (gfc_resolve_finalizers): Properly detect scalar finalizers.
2016-11-28 Janus Weil
PR fortran/58175
* gfortran.dg/finalize_30.f90: New test case.
Index: gcc/fortran/resolve.c
Committed as r242960.
2016-11-28 14:36 GMT+01:00 Janus Weil :
> Hi all,
>
> the attached patch was posted on bugzilla by Tobias three years ago,
> but left unattended since then. It is simple, works well (fixing a
> bogus warning) and regtests cleanly on x86_64-linux-gnu.
>
&
Hi all,
here is a rather straightforward patch for an ice-on-invalid
regression. Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-29 Janus Weil
PR fortran/78573
* decl.c (build_struct): On error, return directly and do not build
class symbol.
2016-11
2016-11-29 23:21 GMT+01:00 Steve Kargl :
> On Tue, Nov 29, 2016 at 10:58:35PM +0100, Janus Weil wrote:
>>
>> here is a rather straightforward patch for an ice-on-invalid
>> regression. Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>
> Yes.
Thanks, Ste
Hi all,
I have just committed a completely obvious patch for this PR. All it
does is rearrange some expressions to avoid an ICE (see attachment):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=243005
Cheers,
Janus
Index: gcc/fortran/interface.c
===
Hi all,
I have just committed to trunk another obvious one-line fix for an
ICE-on-invalid regression:
https://gcc.gnu.org/viewcvs?rev=243020&root=gcc&view=rev
I plan to backport this to the gcc-6 branch within a week or so.
Cheers,
Janus
Index: gcc/fortran/primary.c
Hi Andre,
after your commit I see several warnings when compiling libgfortran
(see below). Could you please fix those (if possible)?
Thanks,
Janus
/home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c: In function
‘_gfortran_caf_is_present’:
/home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:29
Hi,
> on IRC:
> 15:28:22 dominiq: vehre: add /* FALLTHROUGH */
>
> Done and committed as obvious as r243023.
thanks. However, I still see these two:
>> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c: In function
>> > ‘_gfortran_caf_get_by_ref’:
>> > /home/jweil/gcc/gcc7/trunk/libgfortra
86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-12-02 Janus Weil
PR fortran/43207
* primary.c (gfc_match_varspec): Reject nonpolymorphic references to
abstract types.
2016-12-02 Janus Weil
PR fortran/43207
* gfortran.dg/abstract_type_9.f90: New test case.
Index: gcc/fo
Hi all,
another simple fix for a rather old PR. This one adds a new check, in
order to provide better error messages than just "Unclassifiable
statement".
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-12-02 Janus Weil
PR fortran/42188
*
Hi Steve,
2016-12-02 2:33 GMT+01:00 Steve Kargl :
> The attached patch fixes an ICE, a nearby whitespace issue, and
> removed the ATTRIBUTE_UNUSED tag. THe change has passed regression
> testing on x86_64-*-freebsd. Ok to commit?
huh, I don't really understand why the argument of RANK is detect
2016-12-02 17:30 GMT+01:00 Steve Kargl :
> On Fri, Dec 02, 2016 at 04:47:19PM +0100, Janus Weil wrote:
>> Hi Steve,
>>
>> 2016-12-02 2:33 GMT+01:00 Steve Kargl :
>> > The attached patch fixes an ICE, a nearby whitespace issue, and
>> > removed the ATTRI
2016-12-02 18:13 GMT+01:00 Steve Kargl :
>> >> > The attached patch fixes an ICE, a nearby whitespace issue, and
>> >> > removed the ATTRIBUTE_UNUSED tag. THe change has passed regression
>> >> > testing on x86_64-*-freebsd. Ok to commit?
>> >>
>> >> huh, I don't really understand why the argumen
2016-12-02 19:06 GMT+01:00 Janus Weil :
> 2016-12-02 18:13 GMT+01:00 Steve Kargl :
>>> >> > The attached patch fixes an ICE, a nearby whitespace issue, and
>>> >> > removed the ATTRIBUTE_UNUSED tag. THe change has passed regression
>>>
double-ping!
2016-11-26 10:45 GMT+01:00 Janus Weil :
> ping!
>
>
> 2016-11-19 10:12 GMT+01:00 Janus Weil :
>> Hi all,
>>
>>> I previously assumed that the test case for this PR would be legal,
>>> but by now I think that's wrong. The test case shoul
I have just committed as obvious a minor addition here:
https://gcc.gnu.org/viewcvs?rev=243218&root=gcc&view=rev
It deals with an extended test case that was only reported after the
initial fix.
Cheers,
Janus
2016-11-29 15:16 GMT+01:00 Janus Weil :
> Committed as r242960.
>
&g
2016-12-03 18:01 GMT+01:00 Steve Kargl :
> On Fri, Dec 02, 2016 at 04:24:20PM +0100, Janus Weil wrote:
>>
>> another simple fix for a rather old PR. This one adds a new check, in
>> order to provide better error messages than just "Unclassifiable
>> statement&qu
2016-12-03 18:03 GMT+01:00 Steve Kargl :
> On Fri, Dec 02, 2016 at 02:37:24PM +0100, Janus Weil wrote:
>>
>> the attached patch fixes the PR in the subject line by introducing a
>> new check to reject invalid code. It's a slight update of an old patch
>> that I post
?
Cheers,
Janus
2016-12-05 Janus Weil
PR fortran/78674
* gfortran.h (gfc_convert_chartype): Remove prototype.
* expr.c (gfc_check_assign): Remove special case for character types.
* intrinsic.c (gfc_convert_type_warn): Treat also character types.
(gfc_convert_chartype): Remove
hat have a finalizer. However it triggered also on pointer components
with a finalizer. Fixing this makes the ICE go away.
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-12-08 Janus Weil
PR fortran/61767
* class.c (has_finalizer_component): Fix this f
think?
thanks for the comment. Indeed it can not hurt to extend it into a
runtime test. New version attached (according to your suggestions). Ok
with this?
Cheers,
Janus
> On Thu, 8 Dec 2016 13:56:29 +0100
> Janus Weil wrote:
>
>> Hi all,
>>
>> the attached patch fixes
Hi Andre,
> yes, that was what I had in mind for the testcase. Now it looks ok to me.
thanks for reviewing, committed as r243483.
Cheers,
Janus
> On Thu, 8 Dec 2016 16:41:23 +0100
> Janus Weil wrote:
>
>> Hi Andre,
>>
>> > so when I interpret the testc
Hi Andre,
> the attached patch corrects reporting of "Sorry, unimplemented yet" for
> allocatable and pointer components in polymorphic objects (BT_CLASS) thus
> fixing two ICEs reported in the PR.
>
> The next chunk fixes an ICE when the declaration containing the token
> information is of type P
Hi guys,
> there is already an ABI change. DTIO needed it.
maybe it would be a good idea to document this in places like:
* https://gcc.gnu.org/wiki/GFortran/News
* https://gcc.gnu.org/gcc-7/changes.html
On the first page there are "Compatibility notices" for several
earlier versions which menti
ion at: https://gcc.gnu.org/ml/fortran/2016-11/msg00243.html
Any comments, please!?!
Cheers,
Janus
2016-12-03 8:05 GMT+01:00 Janus Weil :
> double-ping!
>
>
> 2016-11-26 10:45 GMT+01:00 Janus Weil :
>> ping!
>>
>>
>> 2016-11-19 10:12 GMT+01:00 Janus Weil :
>
2016-12-12 18:37 GMT+01:00 Paul Richard Thomas :
> Hi Janus,
>
> The patch is good - OK for trunk.
Thanks, Paul. Committed as r243580.
Cheers,
Janus
> On 12 December 2016 at 16:52, Janus Weil wrote:
>> Hi all,
>>
>> I hate to ping this patch once more, bu
Hi Paul,
> The original testcase appears here as dtio_19.f90. I gather that some
> vendors accept this, while fort does not. IMHO ifort is correct here
> since there is no specific DTIO procedure present.
to be honest, I kind of disagree with ifort here (wouldn't be the
first time ;) ...
dtio_19
Hi Paul, hi all,
2016-12-12 21:04 GMT+01:00 Janus Weil :
> As commented several times in bugzilla, my feeling is that the
> solution for this PR would be to utilize the vtable machinery, in
> order to generate a truly polymorphic call to the DTIO procedure.
in order to elaborate what
d to the PR in
the subject line, but instead fixes a testsuite failure seen with a
sanitized compiler? That wasn't mentioned anywhere and sadly I forgot
to bring my crystal ball ...
Cheers,
Janus
> On Mon, 12 Dec 2016 13:37:43 +0100
> Janus Weil wrote:
>
>> Hi Andre,
&
that category) ;P
> Many thanks for finding the right path.
Thanks for your help on the way, and of course thanks to Damian for
triggering this whole discussion in the first place.
Cheers,
Janus
> On 13 December 2016 at 10:23, Janus Weil wrote:
>> 2016-12-13 10:58 GMT+01:00 Jan
he test runs ok.
>
> Bootstrapped and regtested on x86_64-linux/f23. Ok for trunk?
yes, good for trunk then.
Cheers,
Janus
> On Tue, 13 Dec 2016 12:11:50 +0100
> Janus Weil wrote:
>
>> Hi Andre,
>>
>> > all the sanitizer issues I fixed occur during compiling the
Hi all,
here is a straightforward cleanup patch that makes a few functions
return a bool instead of an int. Regtests cleanly on x86_64-linux-gnu.
Ok for trunk?
Cheers,
Janus
2016-12-13 Janus Weil
PR fortran/78798
* gfortran.h (gfc_is_constant_expr, gfc_is_formal_arg
2016-12-13 19:19 GMT+01:00 Janne Blomqvist :
> On Tue, Dec 13, 2016 at 8:13 PM, Janus Weil wrote:
>> Hi all,
>>
>> here is a straightforward cleanup patch that makes a few functions
>> return a bool instead of an int. Regtests cleanly on x86_64-linux-gnu.
>> Ok f
Hi all,
the attached patch deals with error recovery only and fixes an
ICE-on-invalid problem.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-12-15 Janus Weil
PR fortran/78800
* interface.c (compare_allocatable): Avoid additional errors on bad
class
2016-12-15 14:30 GMT+01:00 Andre Vehreschild :
> Looks good to me.
Thanks, Andre. Committed to trunk as r243691.
Cheers,
Janus
> On Thu, 15 Dec 2016 14:18:28 +0100
> Janus Weil wrote:
>
>> Hi all,
>>
>> the attached patch deals with error recovery only and fixe
2016-12-13 19:55 GMT+01:00 Janus Weil :
> 2016-12-13 19:19 GMT+01:00 Janne Blomqvist :
>> On Tue, Dec 13, 2016 at 8:13 PM, Janus Weil wrote:
>>> Hi all,
>>>
>>> here is a straightforward cleanup patch that makes a few functions
>>> return a bool instea
2016-12-15 21:41 GMT+01:00 Steve Kargl :
> On Thu, Dec 15, 2016 at 08:38:47PM +0100, Janus Weil wrote:
>> 2016-12-13 19:55 GMT+01:00 Janus Weil :
>> > 2016-12-13 19:19 GMT+01:00 Janne Blomqvist :
>> >> On Tue, Dec 13, 2016 at 8:13 PM, Janus Weil wrote:
>>
Hi Mikael,
>> I have just committed a completely obvious patch for this PR. All it
>> does is rearrange some expressions to avoid an ICE (see attachment):
>>
> I have made a late review of it, and I think it’s not as innocent as it
> seems.
> With it, if the first element’s formal is not properly
2016-12-17 22:49 GMT+01:00 Janus Weil :
> Hi Mikael,
>
>>> I have just committed a completely obvious patch for this PR. All it
>>> does is rearrange some expressions to avoid an ICE (see attachment):
>>>
>> I have made a late review of it, and I think it’s
2016-12-18 11:18 GMT+01:00 Mikael Morin :
> Le 17/12/2016 à 22:49, Janus Weil a écrit :
>>
>> Hi Mikael,
>>
>>>> I have just committed a completely obvious patch for this PR. All it
>>>> does is rearrange some expressions to avoid an ICE (see attachme
2016-12-18 11:25 GMT+01:00 Janus Weil :
> 2016-12-18 11:18 GMT+01:00 Mikael Morin :
>> Le 17/12/2016 à 22:49, Janus Weil a écrit :
>>>
>>> Hi Mikael,
>>>
>>>>> I have just committed a completely obvious patch for this PR. All it
>>&g
Hi all,
the attached patch fixes an ICE on a valid DTIO example, which is in
fact a regression of one of my recent patches. See bugzilla for
details.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-12-18 Janus Weil
PR fortran/78848
* trans-io.c
?
Cheers,
Janus
> On 18 December 2016 at 13:12, Janus Weil wrote:
>> Hi all,
>>
>> the attached patch fixes an ICE on a valid DTIO example, which is in
>> fact a regression of one of my recent patches. See bugzilla for
>> details.
>>
>> Regtests cle
6-11-26 21:45 GMT+01:00 Janus Weil :
>>> If not, we definitely need to fix the documentation of LTIME, since
>>> the current version simply does not work with TIME8(), unless one uses
>>> -fdefault-integer-8 (which is not mentioned in the docu).
>>
>> What a
Hi Andre,
> attached is a patch to fix the incorrect computation of memory needed in a
> polymorphic assignment. Formerly the memory required could not be determined
> and therefore one byte was allocated. This is fixed now, by retrieving the
> size needed from the _vptr->size.
>
> Bootstraps and
11-05 Janus Weil
Manuel Lopez-Ibanez
PR fortran/69495
* invoke.texi: Mention -Wpedantic as an alias of -pedantic.
* check.c (gfc_check_transfer): Mention responsible flag in warning
message.
* frontend-passes.c (do_warn_function_elimination): Ditto.
* reso
a bit of time for gfortran hacking in the coming weeks, but
I cannot promise anything
Cheers,
Janus
> On 5 November 2016 at 10:15, Janus Weil wrote:
>> Hi all,
>>
>> here is a patch that I had submitted already in February (see
>> https://gcc.gnu.
>> The patch is OK for trunk.
>
> thanks a lot. Will commit soon.
Committed as r241870. Thanks again.
Cheers,
Janus
>> On 5 November 2016 at 10:15, Janus Weil wrote:
>>> Hi all,
>>>
>>> here is a patch that I had submitted already in February (s
Hi guys,
>> I will set aside the patch and wait for the release of 6.2 unless there
>> is demand for it to be applied now. I am somewhat nervous about doing
>> this, however, since it is a rather radical change to select type and
>> has been in trunk for less than two weeks.
>
> This is the usual
Hi all,
here is a simple patch for the accepts-invalid problem of PR77596.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-08 Janus Weil
PR fortran/77596
* expr.c (gfc_check_pointer_assign): Add special check for procedure-
pointer component with
2016-11-08 15:51 GMT+01:00 Steve Kargl :
> On Tue, Nov 08, 2016 at 11:02:26AM +0100, Janus Weil wrote:
>>
>> here is a simple patch for the accepts-invalid problem of PR77596.
>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>
> Yes.
Thanks! Committed as
Hi all,
I have just committed as obvious a small patch for an ice-on-invalid problem:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241979
Cheers,
Janus
Hi all,
I have committed to trunk another obvious patch to fix an ICE on invalid code:
https://gcc.gnu.org/viewcvs?rev=241993&root=gcc&view=rev
Cheers,
Janus
his is not to treat you badly, but to ensure a
> certain quality of gfortran. When a diff is attached I look at it, but I will
> not open the link, not when I am only on a mobile.
>
> Thank you in advance,
> Andre
>
> On Wed, 9 Nov 2016 10:35:10 +0100
> Janus Weil wr
Hi all,
I just committed a close-to-obvious fix for PR60777 (ok'd by Steve in
the PR), see attachment:
https://gcc.gnu.org/viewcvs?rev=242009&root=gcc&view=rev
Cheers,
Janus
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Rev
Hi all,
I have committed yet another obvious ice-on-invalid fix:
https://gcc.gnu.org/viewcvs?rev=242020&root=gcc&view=rev
Cheers,
Janus
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (Revision 241993)
+++ gcc/for
in the
attachment are working as expected. Anything else?
Cheers,
Janus
> On Wed, 9 Nov 2016 21:42:15 +0100
> Janus Weil wrote:
>
>> Hi all,
>>
>> I have committed yet another obvious ice-on-invalid fix:
>>
>> https://gcc.gnu.org/viewcvs?rev=242020&
Hi Andre,
> sorry, when I stepped on your toes. That was not my intention.
well, I kind of got the impression that me committing 'obvious'
patches was somehow getting in conflict with _your_ toes (though I
don't quite understand why). I care as much about the quality of
gfortran as you do, trust
gfc_get_tbp_symtree: Can anyone tell me by chance
why it is necessary to nullify 'result->n.tb' on a newly-created
symtree?]
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-11 Janus Weil
PR fortran/77501
* decl.c (gfc_match_decl_ty
2016-11-11 14:38 GMT+01:00 Janus Weil :
> [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance
> why it is necessary to nullify 'result->n.tb' on a newly-created
> symtree?]
Removing the corresponding line does not do any harm to the testsuite,
as I just
2016-11-11 19:21 GMT+01:00 Steve Kargl :
> On Fri, Nov 11, 2016 at 02:38:25PM +0100, Janus Weil wrote:
>>
>> 2016-11-11 Janus Weil
>>
>> PR fortran/77501
>> * decl.c (gfc_match_decl_type_spec): Use gfc_get_tbp_symtree,
>> fix indentation
-11-12 Janus Weil
PR fortran/66366
* resolve.c (resolve_component): Move check for C437
to ...
* decl.c (build_struct): ... here. Fix indentation.
2016-11-12 Janus Weil
PR fortran/66366
* gfortran.dg/class_60.f90: New test.
Index: gcc/fortran/decl.c
2016-11-12 20:15 GMT+01:00 Mikael Morin :
[Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance
why it is necessary to nullify 'result->n.tb' on a newly-created
symtree?]
>>>
>>>
>>> Removing the corresponding line does not do any harm to the testsuite,
>>> as I just ve
2016-11-13 0:57 GMT+01:00 Steve Kargl :
> On Sat, Nov 12, 2016 at 09:13:26PM +0100, Janus Weil wrote:
>>
>> this patch fixes an ICE on invalid code involving class component
>> declarations. The ICE is avoided by moving forward the error check
>> from resolution
Hi all,
I have just committed an obvious fix for a rejects-valid problem,
where a procedure named 'end' was not properly flagged as a procedure:
https://gcc.gnu.org/viewcvs?rev=242352&root=gcc&view=rev
Cheers,
Janus
Index: gcc/fortran/decl.c
==
Hi Steve,
> The attach patch allows a procedure with a class result to
> be an actual argument to subprogram where the dummy argument
> expected to be a class. OK to commit?
that patch actually does not look quite right to me. Does it survive a regtest?
I think one should rather check why the c
2016-11-14 9:56 GMT+01:00 Janus Weil :
> Hi Steve,
>
>> The attach patch allows a procedure with a class result to
>> be an actual argument to subprogram where the dummy argument
>> expected to be a class. OK to commit?
>
> that patch actually does not look quite
> After looking into this a little bit more, I found that the culprit
> seems to be 'resolve_procedure_interface', which does not properly
> copy the 'class_ok' attribute. I propose the attached patch to fix
> this (regtesting right now) ...
The regtest finished successfully. Is that patch ok for
2016-11-14 16:10 GMT+01:00 Steve Kargl :
> On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote:
>> > After looking into this a little bit more, I found that the culprit
>> > seems to be 'resolve_procedure_interface', which does not properly
>> > copy
compile-time, thus causing wrong code.
The patch fixes the simplification function and also the corresponding
test case (which unfortunately was wrong as well) and regtests
cleanly. Ok for trunk and the release branches?
Cheers,
Janus
2016-11-15 Janus Weil
PR fortran/66227
Hi Andre,
> attached patch fixes the issue raised. The issue here was, that a copy of the
> base class was generated and its address passed to the _vptr->copy()-method,
> which then accessed memory, that was not present in the copy being an object
> of
> the base class. The patch fixes this by ma
2016-11-12 21:21 GMT+01:00 Janus Weil :
>>>> Index: gcc/fortran/class.c
>>>> ===
>>>> --- gcc/fortran/class.c(Revision 242066)
>>>> +++ gcc/fortran/class.c(Arbeitskopie
Hi all,
the attached patch fixes an ice-on-valid problem, simply by removing
an assert. The generated code works as expected and the patch regtests
cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-18 Janus Weil
PR fortran/78392
* trans-array.c
Hi Dominique,
>> the attached patch fixes an ice-on-valid problem, simply by removing an
>> assert. ...
>
> I have several instances in my test suite showing that the proposed patch
> removes the ICE but generates wrong code:
>
> pr42359, second test, => ICE on another place
> pr54613, sixth and
rrectly rejects the original test case as well as one of the cases
mentioned by Dominique. Ok for trunk?
Cheers,
Janus
2016-11-19 Janus Weil
PR fortran/78392
* expr.c (gfc_is_constant_expr): Specification functions are not
compile-time constants. Update documentation (add refere
Hi Andre,
> When checking the shortened example in comment #3 one gets a segfault, because
> v6 is not allocated explicitly. The initial example made sure, that v6 was
> allocated.
sorry, I guess that's my fault. I blindly removed the allocate
statement when looking for a reduced test case for th
might be a good idea as well. Ok?
Cheers,
Janus
2016-11-22 Janus Weil
PR fortran/78443
* class.c (add_proc_comp): Add a vtype component for non-overridable
procedures that are overriding.
2016-11-22 Janus Weil
PR fortran/78443
* gfortran.dg/typebound_proc_35.f90: New
Hi Thomas,
>> the attached patch runs through gfortran's AST to check for missing
>> location information.
one small comment: Is it necessary to introduce the extra CHECK_LOCUS
macro? Couldn't you just use CHECKING_P alone? In your patch
CHECK_LOCUS is basically just replicating CHECKING_P.
And:
2016-11-22 16:16 GMT+01:00 Steve Kargl :
>> here is a patch for a wrong-code problem with non_overridable
>> type-bound procedures. For details see the PR. Regtests cleanly. Ok
>> for trunk?
>
> OK.
Thanks, Steve. Committed as r242703.
>> Since the patch is very simple and it fixes wrong code wh
Hi Steve,
> The patch and ChangeLog shuod be sufficient to explain the change.
> Regression tested on x86_64-*-freebsd. OK to commit?
the patch itself looks good.
For the test case, I'd prefer a somewhat more meaningful name (e.g.
char_component_initializer_3.f90 or similar) and a mention of th
Hi Steve,
> Regression tested on x86_64-*-freebsd. OK to commit?
the patch is certainly ok.
Just my usual request for a meaningful test-case name: This one could
be class_result_4.f90. (I don't want to be pedantic about this, but in
a growing testsuite of 4000+ files, I really think it makes se
). It adds some diagnostics
for the PURE attribute.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-13 Janus Weil
PR fortran/63674
* resolve.c (pure_function): Treat procedure-pointer components.
(check_pure_function): Ne
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> s/'%s'/%qs/g
> nowadays.
Good point, thank you. Updated patch attached.
I guess I still new formal approval by someone with reviewer status ...
Cheers,
Janus
Index: gcc/fortran/resolve.c
=
2014-12-14 12:00 GMT+01:00 FX :
>> Good point, thank you. Updated patch attached.
>> I guess I still new formal approval by someone with reviewer status …
>
> OK
Thanks, committed as r218717.
Cheers,
Janus
2014-12-15 7:34 GMT+01:00 Tobias Burnus :
> Can you change "non-pure" to "impure"? That would better match the Fortran
> naming, where "impure" is the default unless "pure" or "elemental" is used.
> (It was added to permit "impure elemental" procedures.)
Yes, sure. I have committed this change as
heers,
Janus
2014-12-15 Janus Weil
PR fortran/63727
* resolve.c (resolve_actual_arglist): Check for elemental procedure
pointer components.
2014-12-15 Janus Weil
PR fortran/63727
* gfortran.dg/coarray_collectives_14.f90: Address FIXME item.
Index: gcc/fortran/reso
2014-12-15 14:49 GMT+01:00 Tobias Burnus :
> Janus Weil wrote:
>> here is another small diagnostic enhancement for procedure pointer
>> components. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Looks good to me. Thanks for the patch!
Thanks for the review. Committe
he generic call has to be resolved to a
specific one first).
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? And
for 4.8/4.9 after some time?
Cheers,
Janus
2014-12-15 Janus Weil
PR fortran/64244
* resolve.c (resolve_typebound_call): New argument to pass out t
2014-12-16 7:58 GMT+01:00 Tobias Burnus :
> Hi Janus, hi all,
>
> Janus Weil wrote:
>>
>> here is a regression fix for a problem with the NON_OVERRIDABLE
>> attribute. For non-overridable type-bound procedures we do not have to
>> generate a call to the vtabl
Hi all,
I have just committed as obvious a one-line fix for an ICE-on-valid
problem with procedure pointer components:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218834
Cheers,
Janus
efore their _def_init
is NULL and we simply failed to check for that condition. That's what
the patch does. It regtests cleanly on x86_64-unknown-linux-gnu.
Ok for trunk?
Cheers,
Janus
2014-12-19 Janus Weil
PR fortran/64209
* trans-expr.c (gfc_trans_class_array_init_assign)
2014-12-19 14:48 GMT+01:00 Tobias Burnus :
> As you write yourself, the issue can only occur for CLASS(*). Hence,
> please apply this only for UNLIMITED_POLY() to avoid unneccessary code side
> increase and performance decrease.
Good point, thanks for reviewing. An updated patch is attached. Will
Committed as r218968.
Cheers,
Janus
2014-12-19 18:24 GMT+01:00 Janus Weil :
> 2014-12-19 14:48 GMT+01:00 Tobias Burnus :
>> As you write yourself, the issue can only occur for CLASS(*). Hence,
>> please apply this only for UNLIMITED_POLY() to avoid unneccessary code side
jects such code.
In fact the patch uncovered a good number of cases in the testsuite,
which are invalid in this respect. I fixed all of them by making the
encompassing procedure impure. After that the patch regtests cleanly.
Ok for trunk?
Cheers,
Janus
2014-12-19 Janus Weil
PR fortran/
Hi all,
here is a small patch which enhances the diagnostics for the intrinsic
KIND function. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-22 Janus Weil
PR fortran/63363
* check.c (gfc_check_kind): Reject polymorphic and non-data arguments.
2014-12
>> here is a small patch which enhances the diagnostics for the intrinsic
>> KIND function. Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> OK.
Thanks, committed as r219027.
Cheers,
Janus
2014-12-18 0:14 GMT+01:00 Tobias Burnus :
> As testing by Alessandro revealed, vector subscripts weren't properly
> handled.
>
> This patch fixes the compiler side (or at least those issues I found). In
> particular, for expressions ("get") it wrongly passed a NULL pointer,
> additionally, I used t
Hi all,
here is a small patch for an F08 extension: Allocatable components
don't have to be specified in structure constructors any more.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-27 Janus Weil
PR fortran/60357
* array.c (check_constr
301 - 400 of 781 matches
Mail list logo
