Re: [Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

Am Mi., 27. März 2019 um 23:32 Uhr schrieb Thomas Koenig : > > Am 27.03.19 um 22:54 schrieb Thomas Koenig: > > I do not think this is correct. > > ... and I missed the point that this was specifically about > initializations. > > So, OK from my side. Thanks! Great. Thanks for the reviews,

Re: [Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

Hi Thomas, > > the attached patch implements some missing constraints from Fortran > > 2008 concerning procedure pointer initialization (cf. the standard > > quote in comment #18), thus fixing two accepts-invalid and > > ICE-on-invalid problems. > > I do not think this is correct. > > F2008: > >

Re: [Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

Hi Steve, > > the attached patch implements some missing constraints from Fortran > > 2008 concerning procedure pointer initialization (cf. the standard > > quote in comment #18), thus fixing two accepts-invalid and > > ICE-on-invalid problems. > > > > It regtests cleanly on x86_64-linux-gnu. Ok

[Patch, Fortran, F08] PR 85537: Invalid memory reference at runtime when calling subroutine through procedure pointer

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index e1fdb93f3d0..372c517487f 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,9 @@ +2019-03-27 Janus Weil + + PR fortran/85537 + * expr.c (gfc_check_assign_symbol): Reject internal and dummy procedures

Re: [Patch, Fortran, F03] PR 71861: [7/8/9 Regression] ICE in write_symbol(): bad module symbol

Am Mi., 20. März 2019 um 18:26 Uhr schrieb Thomas Koenig : > > Hi Janus, > > > the attached one-line patch fixes an ICE-on-invalid regression with > > abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for > > trunk and the release branches (7 and 8)? > > OK for all. Thanks, Thomas.

[Patch, Fortran, F03] PR 71861: [7/8/9 Regression] ICE in write_symbol(): bad module symbol

--- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,9 @@ +2019-03-19 Janus Weil + + PR fortran/71861 + * symbol.c (check_conflict): ABSTRACT attribute conflicts with + INTRINSIC attribute. + 2019-03-18 Thomas Koenig PR fortran/68009 diff --git a/gcc/fortran/symbol.c b/gcc

Re: [Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

I have just committed the updated patch to trunk as r269658. If anyone thinks this should be backported to 8-branch, please let me know. Cheers, Janus Am Di., 12. März 2019 um 13:00 Uhr schrieb Janus Weil : > > Hi Steve, > > > > Technically the ICE is a regression, bu

Re: [Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

sing 'type parameter list' now. Cheers, Janus diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index a3b47ac4980..834c73fc27e 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,10 @@ +2019-03-12 Janus Weil + + PR fortran/89601 + * decl.c (gfc_match_formal_arglist

[Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

/ChangeLog @@ -1,3 +1,10 @@ +2019-03-11 Janus Weil + + PR fortran/89601 + * decl.c (gfc_match_formal_arglist): Reject empty type parameter lists. + (gfc_match_derived_decl): Mark as PDT only if type parameter list was + matched successfully. + 2019-03-11 Martin Liska * decl.c

Re: [Patch, Fortran, F08] PR 84504: procedure pointer variables cannot be initialized with functions returning pointers

Am Sa., 9. März 2019 um 18:46 Uhr schrieb Steve Kargl : > > On Sat, Mar 09, 2019 at 04:23:01PM +0100, Janus Weil wrote: > > Hi all, > > > > the attached patch is close to trivial and fixes a rejects-valid > > problem concerning procedure pointers to pointer-val

[Patch, Fortran, F08] PR 84504: procedure pointer variables cannot be initialized with functions returning pointers

..e15ef5b6996 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,9 @@ +2019-03-09 Janus Weil + + PR fortran/84504 + * expr.c (gfc_check_assign_symbol): Deal with procedure pointers to + pointer-valued functions. + 2019-03-08 Jakub Jelinek PR other/80058 diff --git a/gcc

Re: [Patch, Fortran] PR 88047: [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843

Am Di., 8. Jan. 2019 um 16:28 Uhr schrieb Steve Kargl : > > On Tue, Jan 08, 2019 at 10:11:33AM +0100, Janus Weil wrote: > > > > the attached patch is close to obvious and fixes another small > > ICE-on-invalid regression. Since there was a bit of discussion in the

[Patch, Fortran] PR 88047: [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843

a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index ba95a26e6ae..4d50f880d38 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,9 @@ +2019-01-08 Janus Weil + + PR fortran/88047 + * class.c (gfc_find_vtab): For polymorphic typespecs, the components of + the class container

Re: [Patch, Fortran] PR 88009: [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

Am Sa., 5. Jan. 2019 um 14:37 Uhr schrieb Thomas Koenig : > > Hi Janus, > > > the attached patch fixes PR 88009, an ICE-on-invalid regression caused > > by one of my earlier commits. Apart from adding some extra checks to > > avoid ICEs, it also uses the 'artificial' attribute to suppress bogus >

[Patch, Fortran] PR 88009: [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

. Regtests cleanly on x86_64-linux-gnu. Ok for trunk? Cheers, Janus 2019-01-05 Janus Weil PR fortran/88009 * class.c (gfc_find_derived_vtab): Mark the _final component as artificial. (find_intrinsic_vtab): Ditto. Also add an extra check to avoid dereferencing a null pointer

Re: [patch, fortran, committed] Another fallout from the INTENT(OUT) patch

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 >

Re: [patch, fortran, committed] Another fallout from clobbering INTENT(OUT) variables

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

Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

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 number &g

Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

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

Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

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 collisions

[Patch, Fortran, committed] PR 86484 & 84543

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=264350 Cheers, Janus

Re: [Patch, Fortran] PR 87172: [9 Regression] Spurious "Derived type 'c_funptr' at (1) has not been declared" error after r263782

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

Re: [Patch, Fortran] PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

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, >

Re: [Patch, Fortran, F03] PR 85395: private clause contained in derived type acquires spurious scope

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 Weil

[Patch, Fortran] PR 86830: [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

. 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

[Patch, Fortran, F03] PR 85395: private clause contained in derived type acquires spurious scope

/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

[Patch, Fortran] PR 87172: [9 Regression] Spurious "Derived type 'c_funptr' at (1) has not been declared" error after r263782

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 (resolve_fl_derived): If a type has

Re: [Patch, fortran] PR86328 - [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements

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

[Patch, Fortran, committed] PR 86545: ICE in transfer_expr on invalid WRITE statement

Hi all, I have just committed a small patch for an ICE-on-invalid problem: https://gcc.gnu.org/viewcvs/gcc?view=revision=263854 The patch was approved by Jerry on bugzilla and I checked that it shows no failures in the testsuite. Cheers, Janus

Re: [Patch, Fortran, F08] PR 86888: allocatable components of indirectly recursive type

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

[Patch, Fortran, F08] PR 86888: allocatable components of indirectly recursive type

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

Re: [Patch, Fortran] PR 86116: Ambiguous generic interface not recognised

oblems 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 fixes P

Re: [Patch, Fortran] PR 86116: Ambiguous generic interface not recognised

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), and

[Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement

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'

[Patch, Fortran] PR 86116: Ambiguous generic interface not recognised

('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): Remove a CLASS/TYPE check

[Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

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/45521 * gfortran.dg/interface_assignment_6.f90: New test

Re: [Patch, fortran] A first small step towards CFI descriptor implementation

Hi Paul, 2018-07-31 14:06 GMT+02:00 Paul Richard Thomas : > Daniel Celis Garza and Damian Rouson have developed a runtime library > and include file for the TS 29113 and F2018 C descriptors. > https://github.com/sourceryinstitute/ISO_Fortran_binding > > The ordering of types is different to the

Re: [Patch, fortran] PR80477 - [OOP] Polymorphic function result generates memory leak

Hi Paul, 2018-07-28 9:32 GMT+02:00 Paul Richard Thomas : > Several attempts, including mine, were made to fix this bug since it > was posted. They were all attacking the wrong place. Instead of > providing the free of the class _data as part of the call to > 'add_a_type' it should be included in

Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

2018-07-24 17:41 GMT+02:00 Janne Blomqvist : > Optimization bugs that pop up at different optimization levels are hard > enough for users to figure out Right, and they're impossible to detect if there is no way to disable the optimization, which is what this PR is about. > without the frontend

Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

2018-07-24 11:12 GMT+02:00 Dominique d'Humières : > Hi Janus, > >> gfortran currently does short-circuiting, and after my patch for PR >> 85599 warns about cases where this might remove an impure function >> call (which potentially can change results). >> >> Now, this PR (57160) is about code

Re: [Patch, fortran] PR66679 - [OOP] ICE with class(*) and transfer

Hi Paul, 2018-07-23 17:51 GMT+02:00 Paul Richard Thomas : > Ping! > On Thu, 5 Jul 2018 at 08:51, Paul Richard Thomas > wrote: >> >> The comment in the patch says it all. >> >> Bootstrapped and regtested on FC28/x86_64 - OK for trunk? I don't see anything wrong with the patch, so as far as I'm

[Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

(gfc_conv_expr_op): Use short-circuiting operators only with -ffrontend-optimize. Without that flag, make sure that both operands are evaluated. 2018-07-20 Janus Weil PR fortran/57160 * gfortran.dg/actual_pointer_function_1.f90: Fix invalid test case. Index: gcc/fortran/trans-expr.c

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-17 20:55 GMT+02:00 Fritz Reese : > On Tue, Jul 17, 2018 at 2:36 PM Janus Weil wrote: >> >> 2018-07-17 19:34 GMT+02:00 Thomas Koenig : >> > Am 17.07.2018 um 19:19 schrieb Janus Weil: > [...] >> >> I do hope that things have converged by now and th

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-17 19:34 GMT+02:00 Thomas Koenig : > Am 17.07.2018 um 19:19 schrieb Janus Weil: >> However, the test case above seems to indicate that the >> function-elimination optimization is not applied to impure functions >> anyway (which is good IMHO). > > If you sp

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-17 17:18 GMT+02:00 Fritz Reese : >> 2018-07-17 9:52 GMT+02:00 Janus Weil : >> > In other words: Does it make sense to tone down >> > -Wfunction-elimination, by only warning about impure functions? >> >> Here is an update of the patch which doe

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-17 9:52 GMT+02:00 Janus Weil : >> 2018-07-16 21:50 GMT+02:00 Thomas Koenig : >>> What I would suggest is to enable -Wfunction-eliminiation with >>> -Wextra and also use that for your new warning. >> >> Thanks for the comments. Makes sense. Updated patch

Re: [PR fortran/83184] Fix matching code for clist/old-style initializers when encountering assumed-rank declarations

Did someone actually approve this patch? Apparently it was committed as r262744 and caused the following regression: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543 Cheers, Janus 2018-06-27 23:07 GMT+02:00 Fritz Reese : > The attached patch fixes PR fortran/83184, which is actually two >

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

> 2018-07-16 21:50 GMT+02:00 Thomas Koenig : >> What I would suggest is to enable -Wfunction-eliminiation with >> -Wextra and also use that for your new warning. > > Thanks for the comments. Makes sense. Updated patch attached. Huh, after actually trying -Wfunction-elimination, I'm not so sure

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-16 21:50 GMT+02:00 Thomas Koenig : > Am 16.07.2018 um 10:06 schrieb Janus Weil: >>> >>> However, one point: I think that the warning should be under a separate >>> warning, which should then be enabled by -Wextra. >>> -Waggressiv

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi Thomas, >> I tested it on a fairly large code base and found no further false >> positives. Also it still regtests cleanly. Ok for trunk? > > > while I still disagree with this on principle, I will not stand > in the way. IIUC you disagree in the sense that you would like gfortran to have

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

large code base and found no further false positives. Also it still regtests cleanly. Ok for trunk? Cheers, Janus 2018-07-15 Thomas Koenig Janus Weil PR fortran/85599 * dump-parse-tree.c (show_attr): Add handling of implicit_pure. * gfortran.texi: Add chapter

Re: How does a target make Fortran work?

Hi Paul, Fortran problems are best discussed on fort...@gcc.gnu.org (in CC) ... 2018-07-12 21:22 GMT+02:00 Paul Koning : > I tried to rebuild for target pdp11 with fortran enabled (in the past I've > just enabled C). It builds fine but the resulting compiler crashes at > startup: > >

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Just noticed another problematic case: Calls to generic interfaces are not detected as implicitly pure, see enhanced test case in attachment. Will look into this problem on the weekend ... Cheers, Janus 2018-07-12 21:43 GMT+02:00 Janus Weil : > Hi all, > > here is a minor update of

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-12 21:53 GMT+02:00 Thomas Koenig : > Hi Janus, > >> The cleaner approach would certainly be to avoid short-circuiting of >> impure functions altogether. If we can all agree that this is a good >> idea, > > > This is a fine example of logical short-circuiting - the condition you > mention

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

, and therefore could trigger a warning. This is fixed in the current version, which still regtests cleanly (note that alloc-comp-3.f90 currently fails due to PR 86417). The test case is also enhanced to include the problematic case. Ok for trunk? Cheers, Janus 2018-07-11 23:06 GMT+02:00 Janus Weil

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

2018-07-12 16:35 GMT+02:00 Dominique d'Humières : > after the dust of the heated discussion around this PR has settled a bit, here is another attempt to implement at least some basic warnings about compiler-dependent behavior concerning the short-circuiting of logical

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi Dominique, thanks for the comments. >> after the dust of the heated discussion around this PR has settled a >> bit, here is another attempt to implement at least some basic warnings >> about compiler-dependent behavior concerning the short-circuiting of >> logical expressions. … > > IMO your

[Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

possible optimizations that might be allowed by the standard, but only about those that are actually problematic in practice and result in compiler-dependent behavior. The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk? Cheers, Janus 2018-07-11 Thomas Koenig Janus Weil

Re: Good news, bad news on the repository conversion

2018-07-09 18:35 GMT+02:00 Eric S. Raymond : > David Edelsohn : >> > The truth is we're near the bleeding edge of what conventional tools >> > and hardware can handle gracefully. Most jobs with working sets as >> > big as this one's do only comparatively dumb operations that can be >> >

Re: Good news, bad news on the repository conversion

2018-07-09 2:27 GMT+02:00 Eric S. Raymond : > There is good news bad news on the GCC repository conversion. > > The good news is that I have solved the only known remaining technical > problem in reposurgeon blocking the conversion. I've fixed the bug > that prevented execute permissions from

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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 peop

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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 subse

Re: [patch, fortran] Handling of .and. and .or. expressions

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 o

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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 >> >> &

Re: [patch, fortran] Handling of .and. and .or. expressions

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()

Re: [patch, fortran] Handling of .and. and .or. expressions

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 discuss

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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: >> >>

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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 >

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [patch, fortran] Handling of .and. and .or. expressions

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

Re: [Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

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 &am

[Patch, Fortran, F08] PR 45521: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

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

Re: [Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

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

Re: [Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

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

[Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

-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.dg/intent_decl_1.f90

Re: [Patch, Fortran] PR 85849: [F2018] warn for obsolescent features

2018-05-24 22:59 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > On Thu, May 24, 2018 at 09:57:16PM +0200, Janus Weil wrote: >> >> just because 2018 seems like a good time to do that, I continue >> plucking some of the low-hanging Fortran 2018 fruit.

Re: [PATCH] PR fortan/85779 -- Fix NULL pointer dereference

2018-05-24 2:24 GMT+02:00 Steve Kargl : > Subject says it all. OK to commit? Ok with me. Thanks, Janus > 2018-05-23 Steven G. Kargl > > PR fortran/85779 > *decl.c (gfc_match_derived_decl): Fix NULL point dereference. >

Re: [PATCH] PR fortran/85895 -- Check for valid errmsg entity

2018-05-24 1:45 GMT+02:00 Steve Kargl : > The attach patch fixes PR fortran/85895 and also addresses > a nearby issue by resolving the expressions associated with > the STAT= and ERRMSG= tags in SYNC statements. OK to commit? Looks good to me. Thanks for the

[Patch, Fortran] PR 85849: [F2018] warn for obsolescent features

=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 <ja...@gcc.gnu.org> PR f

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

2018-05-22 20:56 GMT+02:00 H.J. Lu <hjl.to...@gmail.com>: > On Mon, May 21, 2018 at 10:47 PM, Janus Weil <ja...@gcc.gnu.org> wrote: >> 2018-05-21 18:57 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: >>> On Mon, May 21, 2018 at 12:14:13PM +0200,

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

2018-05-21 18:57 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > 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 mechanica

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

2018-05-21 22:18 GMT+02:00 Janus Weil <ja...@gcc.gnu.org>: > 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

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

2018-05-21 22:16 GMT+02:00 Jakub Jelinek <ja...@redhat.com>: > 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 &quo

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

2018-05-21 21:23 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > 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

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

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

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

>> >> 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!).

  1   2   3   4   5   6   7   8   >