I intend to commit the attached patch on Saturday.
2018-12-02 Steven G. Kargl
PR fortran/87922
* io.c (gfc_match_open): ASYNCHRONOUS must be scalar.
PR fortran/87945
* decl.c (var_element): Inquiry parameter cannot be a data object.
(match_data_constant
Hi Janus,
could you also patches, which you commit as obvious to the mailing lists?
Regarding the last patch, the GNU style puts a line break after the ")" in:
+ if (!sym) return NULL;
+
Tobias
commit 12c8610481cc199a6019cd41d07dbdf8906032d0
Author: janus
Date: Thu Sep 15 17:48:27 2011 +00
On Wed, Dec 5, 2018 at 12:00 AM Steve Kargl
wrote:
>
> I intend to commit the attached patch on Saturday.
Thanks for the work. I assume the patch bootstraps and passes regression tests?
RE:
> PR fortran/88228
> * expr.c (check_null, check_elemental): Work around -fdec and
>
On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote:
> On Wed, Dec 5, 2018 at 12:00 AM Steve Kargl
> wrote:
> >
> > I intend to commit the attached patch on Saturday.
>
> Thanks for the work. I assume the patch bootstraps and passes
> regression tests?
The patch passed regression testing
Hi Steve,
PR fortran/88139
* dump-parse-tree.c (write_proc): Alternate return.
I dissent with this patch. The introduced error is meaningless and, as
mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree
is not directly the issue. The code should be rejected in
On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl
wrote:
>
> On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote:
[...]
> > RE:
> > > PR fortran/88228
> > > * expr.c (check_null, check_elemental): Work around -fdec and
> > > initialization with logical operators operating
On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote:
> Hi Steve,
>
> >>> PR fortran/88139
> >>> * dump-parse-tree.c (write_proc): Alternate return.
> >> I dissent with this patch. The introduced error is meaningless and, as
> >> mentioned by comment #3 in the PR, avoiding
On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote:
> On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl
> wrote:
> >
> > On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote:
> [...]
> > > RE:
> > > > PR fortran/88228
> > > > * expr.c (check_null, check_elemental): Work ar
On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote:
> >>> PR fortran/88139
> >>> * dump-parse-tree.c (write_proc): Alternate return.
> >> I dissent with this patch. The introduced error is meaningless and, as
> >> mentioned by comment #3 in the PR, avoiding the ICE in dum
On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote:
> On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl
> >
> > > RE:
> > > >PR fortran/88139
> > > >* dump-parse-tree.c (write_proc): Alternate return.
> > > I dissent with this patch. The introduced error is meaningless and, as
> >
On Thu, Dec 06, 2018 at 05:21:32PM -0800, Steve Kargl wrote:
>
> Here's an alternative patch that would reject a subroutine
> with an alternate return dummy argument with the bind(c)
> attributes. I'm still trying to determine if the code
> should be legal. The c.l.f thread I started isn't help
Hi Tobias,
> could you also patches, which you commit as obvious to the mailing lists?
yes, I usually do this, but this time I just forgot. Sorry.
> Regarding the last patch, the GNU style puts a line break after the ")" in:
>
> + if (!sym) return NULL;
> +
In principle I'm aware of the GNU c
>> Regarding the last patch, the GNU style puts a line break after the ")" in:
>>
>> + if (!sym) return NULL;
>> +
>
> In principle I'm aware of the GNU coding style, but apparently I
> didn't pay enough attention. Sorry again. I'll fix it ...
Fixed with r178928.
Cheers,
Janus
The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are
fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
fortran/69867 fortran/69962 fortran/70006 fortran/71067 fortran/71730
On 09/28/2016 12:12 PM, Steve Kargl wrote:
The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are
fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
fortran/69867 fortran/69962
PRs 50540 and 50404 each contain a short patch, written by Steve. Both patches
are straightforward:
-- 50404: refuse to have a CLOSE statement without a UNIT (F2008's C908 "A
file-unit-number shall be specified in a close-spec-list")
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
-- 50
On Wed, Nov 09, 2011 at 12:13:10AM +0100, FX wrote:
> PRs 50540 and 50404 each contain a short patch, written by Steve.
> Both patches are straightforward:
>
> -- 50404: refuse to have a CLOSE statement without a UNIT
> (F2008's C908 "A file-unit-number shall be specified in a
> close-spec-list")
>> -- 50404: refuse to have a CLOSE statement without a UNIT
>> (F2008's C908 "A file-unit-number shall be specified in a
>> close-spec-list") (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
>
> jerry already approved this one.
And I committed it as rev. , with a slight modification to add a
On Wed, Nov 09, 2011 at 12:57:29AM +0100, FX wrote:
> >> -- 50404: refuse to have a CLOSE statement without a UNIT
> >> (F2008's C908 "A file-unit-number shall be specified in a
> >> close-spec-list") (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
> >
> > jerry already approved this one.
>
>
> Although I suspect you've been lurking in the background,
> welcome back to the land of gfortran hacking. Your first
> screw up is free, additional screw ups require you to
> fix your screw up and fix an additional bug as your reward.
Attached patch committed as revision 181200.
FX
convert
Hi Tobias,
PS: I lost a bit the overview. Is there any patch pending review or
otherwise pending?
From my side, there is the patch for PR 65428,
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00040.html
Apart from that, I don't see any outstanding patches.
Regards
Thomas
21 matches
Mail list logo
