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
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
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 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
> 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:
> 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 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
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 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
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
>
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
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
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
> 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
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.
>
>
>> -- 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: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")
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
>> 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
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
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
21 matches
Mail list logo
