Hi Mikael,
> this patch fixes PR58007, where the compiler was not able to relate a
> component pointer to any loaded derived type symbol.
> The problem came from an optimization avoiding loading again a symbol
> which had already been loaded, skipping by the way the association of
> component poin
59589), and I'd love to
see others join me and Mikael in the regbashing game ... ;)
Cheers,
Janus
> On 3 January 2014 10:29, Janus Weil wrote:
>> In addition this patch fixes PR 59662.
>>
>> Also: Ping!
>>
>> Cheers,
>> Janus
>>
>>
&
encapsulate the code
necessary to detect finalizable components into a function, which is
then used in two different places. This makes the code less
error-prone and more readable.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-01-06 Janus Weil
PR fortran/59589
Hi all,
I just committed an 'obvious' patch for a ICE-on-invalid regression on trunk:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206429
Cheers,
Janus
Ping!
The patch is also ok with me. Regarding the wording I'd vote for
Tobias' suggestion "NULL() intrinsic not permitted in data-transfer
statement", but I'm also ok with the other variants.
Paul, please commit.
Cheers,
Janus
2013/12/1 Tobias Burnus :
> Paul Richard Thomas wrote:
>>
>> This
After noticing that the bug is actually a regression (see PR 57042):
Ok to backport to 4.7 and 4.8?
Cheers,
Janus
2013/12/29 Janus Weil :
> Hi all,
>
> I have just committed an obvious patch for a segfault with
> -fdump-fortran-original (plus a small documentation fix):
>
>
cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-01-09 Janus Weil
PR fortran/58026
* decl.c (gfc_match_data_decl): Improve error recovery.
2014-01-09 Janus Weil
PR fortran/58026
* gfortran.dg/alloc_comp_basics_6.f90: New.
Index: gcc/fort
2014/1/11 Mikael Morin :
> Le 09/01/2014 14:33, Janus Weil a écrit :
>> After noticing that the bug is actually a regression (see PR 57042):
>> Ok to backport to 4.7 and 4.8?
>>
> Sure!
Thanks. Committed to 4.8 as r206556. Will do 4.7 soon.
Cheers,
Janus
Hi,
>>> this patch fixes PR58007, where the compiler was not able to relate a
>>> component pointer to any loaded derived type symbol.
>>> The problem came from an optimization avoiding loading again a symbol
>>> which had already been loaded, skipping by the way the association of
>>> component p
2014/1/11 Mikael Morin :
>
>
> Le 09/01/2014 16:30, Janus Weil a écrit :
>> Hi all,
>>
>> the attached patch started out as an ICE-on-invalid regression fix,
>> but after the ICE had been fixed recently by other means, it was
>> degraded to a mere error-recov
erfaces'.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-08-04 Janus Weil
PR fortran/45521
* interface.c (gfc_compare_interfaces): Apply additional
distinguishability criteria of F08 to operator interfaces.
2018-08-04 Janus Weil
PR fortran/
ssignments
('compare_type_characteristics'). The latter calls the former, but
includes an additional check that must not be done when checking
generics.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-08-05 Janus Weil
PR fortran/86116
* interface.c (compare_type): Remov
Hi all,
this simple patch improves some of the diagnostics for invalid
ASSOCIATE statements:
https://github.com/janusw/gcc/commit/2f484479c741abddc8ac473cb0c1b9010397e006
In particular it gives a more precise locus and improved wording,
which is achieved basically by splitting a 'gfc_match' into
ping!
Am So., 5. Aug. 2018 um 15:23 Uhr schrieb Janus Weil :
>
> Hi all,
>
> the attached patch fixes PR 86116 by splitting up the function
> 'compare_type' into two variants: One that is used for checking
> generic interfaces and operators (keeping the old name)
le problems on trunk ...
Cheers,
Janus
> On Tue, Aug 14, 2018 at 4:12 AM Janus Weil wrote:
> >
> > ping!
> >
> >
> > Am So., 5. Aug. 2018 um 15:23 Uhr schrieb Janus Weil :
> > >
> > > Hi all,
> > >
> > > the attached patch fi
@@
+2018-08-21 Janus Weil
+
+ PR fortran/86888
+ * decl.c (gfc_match_data_decl): Allow allocatable components of
+ indirectly recursive type.
+ * resolve.c (resolve_component): Remove two errors messages ...
+ (resolve_fl_derived): ... and replace them by a new one.
+
2018-08-16 Nathan Sidwell
Am Mi., 22. Aug. 2018 um 15:44 Uhr schrieb Paul Richard Thomas
:
>
> > the attached patch fixes the PR in the subject line in a rather
> > straightforward fashion. Pointer components of indirectly recursive
> > type are working already, as well as allocatable components of
> > directly recursive ty
Hi all,
I have just committed a small patch for an ICE-on-invalid problem:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263854
The patch was approved by Jerry on bugzilla and I checked that it
shows no failures in the testsuite.
Cheers,
Janus
Hi Paul,
> The attached patch fixes PR86328 and PR86760. The regression was
> caused by my commit r252949.
>
> The parts of the patch that fix the PRs are in trans.c and
> trans-array.c. The problem was caused by fixing the expressions that
> would provide the 'span' in gfc_build_array_ref, since
sts cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c386a649583..8dad9d35eaf 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,10 @@
+2018-09-03 Janus Weil
+
+ PR fortran/87172
+ * resolve.c (res
-bound procedure call into a
PPC call internally, the patch also cures memory leaks with TBPs.]
It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2017-06-15 Janus Weil
PR fortran/70983
* trans-expr.c (gfc_conv_procedure_call): Deallocate the result of
scalar
2017-06-15 15:33 GMT+02:00 Thomas Koenig :
> Hi Janus,
>
>> It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>
>
> OK.
>
> Thanks for the patch!
Thanks, Thomas! Committed as r249227.
Cheers,
Janus
2017-06-16 11:11 GMT+02:00 Christophe Lyon :
> Hi,
>
> On 15 June 2017 at 23:18, Janus Weil wrote:
>> 2017-06-15 15:33 GMT+02:00 Thomas Koenig :
>>> Hi Janus,
>>>
>>>> It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>>
>>
Hi all,
here is a close-to-trivial patch for an ICE-on-invalid problem. It
regtests cleanly.
Ok for trunk? (If there are no objections, I'd like to commit this in
the coming days.)
Cheers,
Janus
2017-11-11 Janus Weil
PR fortran/82932
* resolve.c (update_compcall_arglist): Im
2017-11-11 19:01 GMT+01:00 Steve Kargl :
> On Sat, Nov 11, 2017 at 01:01:59PM +0100, Janus Weil wrote:
>>
>> here is a close-to-trivial patch for an ICE-on-invalid problem. It
>> regtests cleanly.
>>
>> Ok for trunk? (If there are no objections, I'd lik
Hi guys,
I see this new test case failing on x86_64-linux-gnu:
FAIL: gfortran.dg/pr78240.f90 -O (test for excess errors)
$ gfortran-8 pr78240.f90
pr78240.f90:11:12:
integer x(n)/1/ ! { dg-error "Nonconstant array" }
1
Error: Variable ‘n’ cannot appear in the expression
2017-11-14 23:21 GMT+01:00 Fritz Reese :
> On Tue, Nov 14, 2017 at 4:58 PM, Janus Weil wrote:
>> Hi guys,
>>
>> I see this new test case failing on x86_64-linux-gnu:
>>
>> FAIL: gfortran.dg/pr78240.f90 -O (test for excess errors)
>>
>>
>
Hi Jakub,
thanks a lot for fixing this. Since it's a regression and the fix is
so trivial, I hope you're willing to backport it to the 6 and 7
branches as well? (If not, I can also take care of that.)
Cheers,
Janus
2017-11-24 22:42 GMT+01:00 Jakub Jelinek :
> Hi!
>
> gfc_trans_omp_array_reduct
-09 Janus Weil
PR fortran/85088
* decl.c (match_attr_spec): Synchronize the DECL_* enum values with the
INTENT_* values from the enum 'sym_intent'. Call 'match_intent_spec'
and remove a TODO note.
2018-06-09 Janus Weil
PR fortran/85088
* gfortran.
Hi Thomas,
> I like what the patch does. However, I have one concern.
>
>> * decl.c (match_attr_spec): Synchronize the DECL_* enum values with
>> the
>> INTENT_* values from the enum 'sym_intent'.
>
>
> This part
>
> + { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN,
> +DECL
2018-06-10 9:02 GMT+02:00 Janus Weil :
> Hi Thomas,
>
>> I like what the patch does. However, I have one concern.
>>
>>> * decl.c (match_attr_spec): Synchronize the DECL_* enum values with
>>> the
>>> INTENT_* values f
ated previously.
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-06-11 Janus Weil
PR fortran/45521
* interface.c (compare_ptr_alloc): New function.
(compare_ptr_alloc): Call it.
2018-06-11 Janus Weil
PR fortran/45521
* gfortra
2018-06-11 19:49 GMT+02:00 Steve Kargl :
> On Mon, Jun 11, 2018 at 05:05:17PM +0200, Janus Weil wrote:
>>
>> the attached patch fixes two remaining problems with the resolution of
>> generic functions with POINTER and ALLOCATABLE arguments in F08
>> (coments 16 & 17
Hi Thomas,
>the attached patch introduces the following changes:
thanks a lot for working on this!
>If a logical .and. or .or. expression contains a reference to a
>function
>which is impure and which also does not behave like a pure function
>(i.e. does not have the implicit_pure attribute s
Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist
:
>> There is already quite some discussion in the PRs, especially 85599,
>> where not all people were of the same opinion. Let us see where the
>> discussion here leads us.
>
>IMHO it's a mistake that the standard refuses to specify the ev
Am 13. Juni 2018 22:39:38 MESZ schrieb Thomas Koenig :
>>> If a logical .and. or .or. expression contains a reference to a
>>> function
>>> which is impure and which also does not behave like a pure function
>>> (i.e. does not have the implicit_pure attribute set), it emits a
>>> warning with -W
Am 14. Juni 2018 11:41:03 MESZ schrieb Janne Blomqvist
:
>On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil
>wrote:
>
>>
>> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>>
>> >Either
>> >
&
Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist
:
>> >> >Either
>> >> >
>> >> >a) short-circuiting in left-to-right order
>> >> >
>> >> >or
>> >> >
>> >> >b) must evaluate all the arguments in left-to-right order
>> >> >
>> >> >My preference would be for a) as that is what most languages
Am 15. Juni 2018 11:22:44 MESZ schrieb Janus Weil :
>>>>but
>>> >> >even b) would be better than leaving it undefined.
>>> >>
>>> >> Agreed.
>>> >>
>>> >> In my opinion the best strategy for gfortran in t
Am 15. Juni 2018 19:10:01 MESZ schrieb Thomas Koenig :
>Am 14.06.2018 um 10:38 schrieb Janus Weil:
>>> Also, there are AFAIU other similar weirdness with impure functions.
>>> The
>>> standard allows a compiler to optimize
>>>
>>> y = f(x) + f(x
Am 15. Juni 2018 19:49:42 MESZ schrieb Janne Blomqvist
:
>On Fri, Jun 15, 2018 at 12:22 PM, Janus Weil wrote:
>
>> Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>> In Fortran, it still feels like functions as such are se
Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
:
>> But at least for pure functions, this optimization looks Ok.
>>
>
>Why is everyone fixated on PURE vs IMPURE functions?
Simply because it makes a difference in this context!
That the Fortran standard does not acknowledge this fact is mo
Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>>
>>
>> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
>:
>> >> But at least for pure functions, this optimization looks Ok.
>> &g
Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>>
>>
>> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
>:
>> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>> >>
Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig :
>Hi Janus,
>
>> I happen to hold the opinion that optimizing out a call to a pure
>> function may be reasonable if it does not influence the result of an
>> expression, but optimizing out an effectively impure function (i.e.
>one
>> with
Hi Thomas, hi all,
I'm back from holidays and have more time to deal with this now ...
2018-06-17 0:38 GMT+02:00 Janus Weil :
>
> Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig :
>>In my patch, I have tried to do all three things at the same time, and
>>after this di
2018-06-26 23:16 GMT+02:00 Jakub Jelinek :
> On Tue, Jun 26, 2018 at 11:12:40PM +0200, Thomas Koenig wrote:
>> Hi Janus,
>>
>> with your patch, we would only warn about
>>
>> var .and. func()
>>
>> and not about
>>
>> func() .and. var.
>>
>> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
2018-06-27 8:15 GMT+02:00 Jakub Jelinek :
> On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
>> >> with your patch, we would only warn about
>> >>
>> >> var .and. func()
>> >>
>> >> and not about
>> >>
>&g
2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
> On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> > and have some non-default aggressive
>> > optimization option that would optimize away in the FE impure function
>> > calls
>>
>> IMHO an
2018-06-27 10:09 GMT+02:00 Janne Blomqvist :
> On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil wrote:
>>
>> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
>> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> >> > and have some non-default aggressive
2018-06-27 15:43 GMT+02:00 N.M. Maclaren :
> On Jun 27 2018, Janus Weil wrote:
>>
>>
>> It is very unfortunate, and it means that the Fortran standard simply
>> does not provide a measure for "more correct" here. (My common-sense
>> drop-in notion of c
2018-06-27 23:47 GMT+02:00 Steve Kargl :
> On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
>> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
>> >
>> > And we are not going to change Fortran semantics. And I also oppose
>> > defining our own subset of
Hi Thomas,
> if we add a warning, we should add it both for
>
> if (flag .and. func())
>
> and for
>
> if (func() .and. flag)
>
> because the standard also allows reversing the test (which my
> original test did).
well, I really don't want to warn for hypothetical problems. Since we
currently do
2018-06-28 13:05 GMT+02:00 N.M. Maclaren :
> On Jun 28 2018, Janus Weil wrote:
>>
>>
>>> if we add a warning, we should add it both for
>>>
>>> if (flag .and. func())
>>> and for
>>> if (func() .and. flag)
>>>
>>> becau
2018-06-28 16:41 GMT+02:00 Steve Kargl :
>> > Technically, the standard says an operand need not be evaluate,
>> > but you've asked people not to cite the Standard. I've also
>> > pointed you to F2018 Note 10.28 where it very clearly says that
>> > a function need not be evaluated with example nea
2018-06-28 18:22 GMT+02:00 Steve Kargl :
> On Thu, Jun 28, 2018 at 05:52:43PM +0200, Janus Weil wrote:
>> 2018-06-28 16:41 GMT+02:00 Steve Kargl :
>> >> > Technically, the standard says an operand need not be evaluate,
>> >> > but you've asked
2018-06-29 9:28 GMT+02:00 Jakub Jelinek :
> On Thu, Jun 28, 2018 at 07:36:56PM -0700, Steve Kargl wrote:
>> === gfortran Summary ===
>>
>> # of expected passes47558
>> # of unexpected failures6
>> # of expected failures 104
>> # of unsupported tests
(revision 257207)
+++ gcc/testsuite/gfortran.dg/pr68318_1.f90(working copy)
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options "-O0"
+! { dg-options "-O0" }
! PR fortran/68318
! Original code submitted by Gerhard Steinmetz
!
Cheers,
Janus
2018-01-30 Janus Weil
available. The corresponding
pass-arg checks for TBPs are ok.]
The patch also fixes an invalid test case (which was detected thanks
to Neil Carlson). It regtests cleanly on x86_64-linux-gnu. Ok for
trunk?
Cheers,
Janus
2018-02-09 Janus Weil
PR fortran/84273
* resolve.c
Hi guys,
2018-02-10 12:46 GMT+01:00 Paul Richard Thomas :
> As Steve said, welcome back!
thanks for the warm welcome :)
> I hope that you will post the news of this fix and the correction of
> the testcases on clf. Talking of which, have you posted the problems
> that others have found as PRs?
Dear release managers,
2018-02-10 0:21 GMT+01:00 Steve Kargl :
> On Fri, Feb 09, 2018 at 06:13:34PM +0100, Janus Weil wrote:
>>
>> the attached patch fixes some checking code for PASS arguments in
>> procedure-pointer components, which does not properly account for the
2018-02-12 8:22 GMT+01:00 Richard Biener :
>> 2018-02-10 0:21 GMT+01:00 Steve Kargl :
>> > On Fri, Feb 09, 2018 at 06:13:34PM +0100, Janus Weil wrote:
>> >>
>> >> the attached patch fixes some checking code for PASS arguments in
>> >> procedure-
, so I hope this one will also
still be suitable for trunk (if not, I hope the release managers, in
CC, will stop me).
It does regtest cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-02-13 Janus Weil
PR fortran/84313
* symbol.c (check_conflict): Reject procedure pointers
2018-02-13 20:55 GMT+01:00 Richard Biener :
> On February 13, 2018 8:14:33 PM GMT+01:00, Steve Kargl
> wrote:
>>On Tue, Feb 13, 2018 at 07:24:35PM +0100, Janus Weil wrote:
>>>
>>> As my last submission, this fixes fallout from
>>>
>>https
2018-02-14 12:47 GMT+01:00 Jakub Jelinek :
> On Wed, Feb 14, 2018 at 12:30:14PM +0100, Jakub Jelinek wrote:
>> On Tue, Feb 13, 2018 at 07:24:35PM +0100, Janus Weil wrote:
>> > as the subject line says, the attached patch rejects procedure
>> > pointers in COMMON blocks
>>> Adding ! { dg-additional-options "-std=f2003" }
>>> doesn't work, because the test uses
>>> call abort
>
> I actually think we should get rid of such extensions in the
> testsuite, where possible. This particular one is used all over the
> place, but could be easily replaces by something like
Hi all,
here is another small patch that fixes two invalid test cases in the
test suite and also fixes the check that was supposed to reject these
cases (but failed).
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-02-14 Janus Weil
PR fortran/84385
* match.c
2018-02-14 22:16 GMT+01:00 Steve Kargl :
> On Wed, Feb 14, 2018 at 10:10:09PM +0100, Janus Weil wrote:
>>
>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>
> Looks okay to me with two question below.
>
2018-02-14 22:30 GMT+01:00 Janus Weil :
> 2018-02-14 22:16 GMT+01:00 Steve Kargl :
>> On Wed, Feb 14, 2018 at 10:10:09PM +0100, Janus Weil wrote:
>>>
>>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>>
>>
>> Looks okay to me with two q
Hi Thomas,
apparently your commit only includes the ChangeLog addition, but not
the new test case itself. I guess you missed an "svn add"? :)
Cheers,
Janus
2018-02-15 19:47 GMT+01:00 Thomas Koenig :
> Hi,
>
> I just committed the test case below as obvious, after testing.
> Just to make sure th
2018-02-15 20:53 GMT+01:00 Thomas Koenig :
> Hi Janus,
>
>> apparently your commit only includes the ChangeLog addition, but not
>> the new test case itself. I guess you missed an "svn add"? :)
>
>
> Actually, I messed up the ChangeLog entry in r257702 and corrected that
> one in r257703 :-)
>
> Th
Hi all,
attached is another simple patch for an accepts-invalid problem (this
time concerning DTIO), also curing an invalid test case.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-02-15 Janus Weil
PR fortran/84409
* interface.c (check_dtio_arg_TKR_intent
2018-02-15 21:16 GMT+01:00 Steve Kargl :
> On Thu, Feb 15, 2018 at 09:03:55PM +0100, Janus Weil wrote:
>>
>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>
> Looks good to me with a question below.
Thanks for the feedback, Steve.
>&g
2018-02-15 22:03 GMT+01:00 Steve Kargl :
> On Thu, Feb 15, 2018 at 09:55:58PM +0100, Janus Weil wrote:
>> 2018-02-15 21:16 GMT+01:00 Steve Kargl :
>> >
>> > If the above is a numbered constraint in the Standard,
>> > can you add a comment of the form /* F03:C1
2018-02-16 0:37 GMT+01:00 Steve Kargl :
> On Fri, Feb 16, 2018 at 12:25:11AM +0100, Thomas Koenig wrote:
>> I wrote:
>>
>> > OK for trunk?
>>
>> Following a remark by Steve, here is an additional test case which
>> checks if abort actually works. I'll add that to the patch
>> when it is committed.
Hi Thomas,
>> as a result of this, you should be able to remove the vast majority of
>> -fall-intrinsics extra options. Please do that as well.
>
>
> Done, in r257782.
Regarding "-fall-intrinsics": Your commit has greatly reduced its
usage, but I still see a few cases that you left in, although t
2018-02-18 1:38 GMT+01:00 Thomas Koenig :
> Hi Janus,
>
>> Regarding "-fall-intrinsics": Your commit has greatly reduced its
>> usage, but I still see a few cases that you left in, although the flag
>> does not really seem to be required.
>>
>> Is there a reason why did not treat these?
>
> I was s
/gcc/fortran/ChangeLog
index 7cfb94ee115..11adc5d13d5 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2018-09-09 Janus Weil
+
+ PR fortran/85395
+ * decl.c (match_binding_attributes): Use correct default accessibility
+ for procedure pointer components.
+
2018-09-03
. Ok for trunk and gcc-8-branch?
Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 7cfb94ee115..7e2d6445237 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2018-09-09 Janus Weil
+
+ PR fortran/86830
+ * expr.c (gfc_is_simply_contiguous
Am Mo., 10. Sep. 2018 um 08:55 Uhr schrieb Paul Richard Thomas
:
>
> Hi Janus,
>
> That's OK for trunk and, I would suggest 8-branch.
Thanks, Paul. Committed to trunk as r264196. Will backport to 8-branch
in a week or so.
Cheers,
Janus
> On 9 September 2018 at 17:31, Janus
Am Mo., 10. Sep. 2018 um 08:54 Uhr schrieb Paul Richard Thomas
:
>
> Hi Janus,
>
> That's fine - OK for both branches.
Committed to trunk as r264201. Will do 8-branch soon.
Thanks for the review,
Janus
> On 9 September 2018 at 21:34, Janus Weil wrote:
> > Hi all,
ping!
Am Mo., 3. Sep. 2018 um 21:19 Uhr schrieb Janus Weil :
>
> Hi all,
>
> attached is a simple patch that fixes a regression which was
> introduced by one of my recent commits (spotted by Dominique).
>
> My first impulse to fix the spurious error was to check for the
&g
Hi all,
I have just committed as obvious a small patch that fixes two very
related PRs concerning polymorphic assignments, by making sure that
the relevant vtabs (including copy procedures) are generated:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=264350
Cheers,
Janus
Am Mo., 17. Sep. 2018 um 10:59 Uhr schrieb Bernhard Reutner-Fischer
:
>
> On Tue, 9 Nov 2010 at 11:41, Janus Weil wrote:
> >
> > >> Ok, so it seems to me that using two leading underscores is really the
> > >> best option, since it's safe against colli
Am Mo., 17. Sep. 2018 um 21:21 Uhr schrieb Janus Weil :
>
> Instead, for the sake of gfortran, how about a macro like this?
>
> #define gfc_str_startswith(str, pref) \
> (strncmp ((str), (pref), strlen (pref)) == 0)
>
> (In fact I just noticed that something like this alre
Am Mi., 19. Sep. 2018 um 16:50 Uhr schrieb Bernhard Reutner-Fischer
:
>
> On Mon, 17 Sep 2018 at 22:25, Janus Weil wrote:
>
> > The regtest was successful. I don't think the off-by-two error for the
> > vtab/vtype comparisons is a big problem in practice, since the numb
Hi Thomas,
I'm seeing some more fallout from your intent(out) patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401
Cheers,
Janus
Am So., 23. Sep. 2018 um 22:23 Uhr schrieb Thomas König :
>
> Hello world,
>
> committed as obvious after regression-testing. Instead of spending
> a lot of wor
Am Mo., 24. Sep. 2018 um 19:16 Uhr schrieb Thomas Koenig
:
>
> Hello world,
>
> another obvious and simple one-line fix for fallout from the INTENT(OUT)
> clobber patch. Committed as r264539, after regression-testing.
>
> It seems our testsuite is not testing as many combinations in the
> language
patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-05-20 Janus Weil
PR fortran/85841
* match.c (match_arithmetic_if, gfc_match_if): Reject arithmetic if
in Fortran 2018.
(gfc_match_stopcode): Adjust checks for standard version.
* options.c (set_de
ns covered
by this flag are now part of F2018 (and pretty much the main part!).
Any opinions on this?
Cheers,
Janus
2018-05-20 Janus Weil
PR fortran/85841
* error.c (notify_std_msg): New function.
(gfc_notify_std): Adjust such that it can handle combinations of
GFC_STD_* flags
Hi Steve,
thanks for your comments!
>> The patch still regtests cleanly. Ok for trunk?
>
> Patch looks good to me. The only thing that worries me is
> whether the patch will cause the SPEC benchmark to throw
> an error or warning that it did not before. As I don't have
> SPEC benchmark and it c
2018-05-21 0:19 GMT+02:00 Steve Kargl :
> On Sun, May 20, 2018 at 09:44:47PM +0200, Janus Weil wrote:
>>
>> >> The patch still regtests cleanly. Ok for trunk?
>> >
>> > Patch looks good to me. The only thing that worries me is
>> > whether the patc
>> >> Btw, with the arrival of the F2018 standard, I wonder whether it
>> >> actually makes sense to keep the option -std=f2008ts, or to remove it
>> >> in favor of -std=f2018, since the two Technical Specifications covered
>> >> by this flag are now part of F2018 (and pretty much the main part!).
Hi Steve,
> The attached patch fixes a few testcases that were missed
> in the original patch. Do you have these already in an
> updated patch, or would you like me to commit my patch?
I saw the message just now and had no time to react yet. Please feel
free to commit your patch.
Thanks,
Janus
2018-05-21 21:23 GMT+02:00 Steve Kargl :
> On Mon, May 21, 2018 at 12:10:01PM -0700, Steve Kargl wrote:
>> On Mon, May 21, 2018 at 09:06:40PM +0200, Janus Weil wrote:
>> > Hi Steve,
>> >
>> > > The attached patch fixes a few testcases that were missed
>
2018-05-21 22:16 GMT+02:00 Jakub Jelinek :
> On Mon, May 21, 2018 at 01:06:21PM -0700, Steve Kargl wrote:
>> On Mon, May 21, 2018 at 09:39:29PM +0200, Janus Weil wrote:
>> >
>> > Regarding the libgomp.fortran cases: Those are not included in "make
>> > che
2018-05-21 22:18 GMT+02:00 Janus Weil :
> I'll take care of fixing the remaining libgomp failures.
Should be done with r260487. Please let me know if you observe any
additional problems.
Cheers,
Janus
2018-05-21 18:57 GMT+02:00 Steve Kargl :
> On Mon, May 21, 2018 at 12:14:13PM +0200, Janus Weil wrote:
>>
>> So, here is the promised follow-up patch. It mostly removes
>> GFC_STD_F2008_TS and replaces it by GFC_STD_F2018 in a mechanical
>> manner. Plus, it fixes t
2018-05-22 20:56 GMT+02:00 H.J. Lu :
> On Mon, May 21, 2018 at 10:47 PM, Janus Weil wrote:
>> 2018-05-21 18:57 GMT+02:00 Steve Kargl :
>>> On Mon, May 21, 2018 at 12:14:13PM +0200, Janus Weil wrote:
>>>>
>>>> So, here is the promised follow-up patch. I
=f2018, but not with gfortran's default -std=gnu.
They currently have zero impact on the gfortran test suite, so I'm
adding a new test case to check for their existence.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2018-05-24 Janus Weil
PR fortran/85839
101 - 200 of 781 matches
Mail list logo
