this lead to a regression? Sure. The alternative of
> > constantly pinging patches is to simply stop submitting
> > patches.
> >
> >
> > --
> > Steve
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
Thanks, Steve. I'll get this committed tomorrow morning.
-Andrew
On Sunday, March 1, 2020 2:42:13 PM PST Steve Kargl wrote:
> On Sun, Mar 01, 2020 at 11:33:10AM -0800, Andrew Benson wrote:
> > *ping*
>
> Andrew,
>
> The patch looks fine to me. PS: in general, after m
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
>
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
>
> module ivs
> interface l
> module procedure l_
>
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
>
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
>
> module ivs
> interface l
> module procedure l_
>
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
>
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
>
> module ivs
> interface l
> module procedure l_
>
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
>
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
>
> module ivs
> interface l
> module procedure l_
>
Thanks - that worked.
On Monday, February 10, 2020 12:18:57 PM PST Segher Boessenkool wrote:
> On Mon, Feb 10, 2020 at 10:05:48AM -0800, Andrew Benson wrote:
> > I don't think I have the ability to mark the PR as resolved. Can someone
> > do
> > that?
>
> You have an @
I don't think I have the ability to mark the PR as resolved. Can someone do
that?
On Monday, February 10, 2020 10:02:24 AM PST Andrew Benson wrote:
> This is now committed (after adding the macro as Steve suggested):
>
> https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99
; to for example
>
> + if (IN_SUBMODULE (sym))
>
> where is
>
> #define IN_SUBMODULE (x) \
>(gfc_state_stack->previous && gfc_state_stack->previous->previous \
> && gfc_state_stack->previous->previous->state == COMP_SUBMODULE \
> &
Hi Steve,
Thanks for the review. Adding a macro as you suggest seems like a very good
idea. I'll make that change tomorrow before committing this.
Thanks,
Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg
*ping*
On Friday, January 31, 2020 5:06:49 PM PST Andrew Benson wrote:
> I've attached on updated patch for PR83113. The now removes the ICE when a
> duplicate DIMENSION attribute is specified in a submodule function. The
> patch reg tests cleanly.
>
> OK to commit?
>
>
match those in
the module?
If so, I can go ahead and open a PR for this problem.
-Andrew
On Friday, January 24, 2020 10:54:24 AM PST Andrew Benson wrote:
> Below is a partial patch for PR 83113
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
>
> It simply circum
Thanks Bernhard - this is now committed:
https://gcc.gnu.org/g:004ac7b780308dc899e565b887c7def0a6e100f2
On Thursday, January 30, 2020 5:27:55 PM PST Bernhard Reutner-Fischer wrote:
> On 29 January 2020 21:19:52 CET, Andrew Benson
wrote:
> >I think this patch is still waiting to be a
this if Bernhard is ok with me doing so.
-Andrew
On Wednesday, August 28, 2019 9:00:36 PM PST Bernhard Reutner-Fischer wrote:
> On Fri, 23 Aug 2019 17:17:37 -0700
>
> Andrew Benson wrote:
> > This PR is still open - I re-tested the patch on the current trunk. The
> > patch still a
the patch,
>
> Tobias
>
> On 1/29/20 1:45 AM, Andrew Benson wrote:
> > Hi Tobias,
> >
> > On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote:
> >> Thus, I do not think it is a real problem in practice. We could be nice,
> >> howe
tly clearly though?
-Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index dcce6b8..5a959a1 100644
--- a/htdocs/gcc-10/changes.html
+
org/ml/fortran/2018-09/msg00044.html ). It would be very nice to get
one of these patches committed.
-Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
diff --git a/gcc/fortran/module.c b/gcc/fortran/mo
; On 1/28/20 5:41 PM, Andrew Benson wrote:
> >> Can you also update the comment before the #define? It currently has:
> > Thanks for the suggestion. An updated patch is attached.
>
> Thanks. LGTM now.
>
> >> PS: I wonder whether there are relevant systems which
t; Thanks,
>
> Tobias
>
> On 1/28/20 5:41 PM, Andrew Benson wrote:
> > On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote:
> >> On 1/28/20 12:41 AM, Andrew Benson wrote:
> >>> The problem occurs in set_syms_host_assoc() where the "parent1
the question (in the PR) of whether this patch
would be an ABI change. I can see that it probably would be, but don't know
for sure. If it would change the ABI is there anything else that I need to
include in the patch?
Thanks,
Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenso
On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote:
> On 1/28/20 12:41 AM, Andrew Benson wrote:
> > The problem occurs in set_syms_host_assoc() where the "parent1" and
> > "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This
> &
ubmoduleWithASignificantlyLongButStillAllowedName__
+end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__
2020-01-27 Andrew Benson
PR fortran/93473
* parse.c: Increase length of char variables to allow them to hold
a concatenated module + submodule name.
* gfortran.dg/pr93473.f90: New test.
ubmodule names.
I've attached a patch for this which includes a new test case for this PR. The
patch regression tests cleanly.
OK to commit?
-Andrew
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://github.com/galacticusorg/galacticus
diff --g
Thanks Bernhard.
On Wednesday, August 28, 2019 9:00:36 PM PDT Bernhard Reutner-Fischer wrote:
> On Fri, 23 Aug 2019 17:17:37 -0700
>
> Andrew Benson wrote:
> > This PR is still open - I re-tested the patch on the current trunk. The
> > patch still applies with some line o
:35:04 PM PDT Bernhard Reutner-Fischer
wrote:
> On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle wrote:
> > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:
> > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson
wrote:
> > >> As suggested by Janus, PR87103 is easi
pointer_assignment): Rename non_proc_pointer_assign
> as non_proc_ptr_assign. Assign to it directly, rather than call
> to above, deleted function and use gfc_expr_attr instead of
> only checking the reference chain.
>
> 2019-06-08 Paul Thomas
>
> PR fortran/90786
>
io_lparen ();
> >
> > This causes no regressions. I've attached the patch including the
> > ChangeLog - is this ok to commit?
>
> OK for trunk.
>
> Thanks a lot for the patch!
>
> Regards
>
> Thomas
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://bitbucket.org/galacticusdev/galacticus
(revision 270772)
+++ gcc/fortran/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2019-05-01 Andrew Benson
+
+ * module.c (write_module): Initialize module_column before writing
+ module to ensure line break occurs at correct column.
+
2019-04-19 Steven G. Kargl
PR fortran/90166
Index: gcc
On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer
wrote:
> On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle wrote:
> > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:
> > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson
wrote:
> > >>
?
-Andrew
On Saturday, August 25, 2018 1:50:57 PM PDT Andrew Benson wrote:
> I just opened PR for this: 87103
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103
>
> The following code causes an ICE with gfortan 9.0.0 (r263855
> > whether the symbol needs to be loaded - if that test fails then
> > find_symbol() is never called.
> >
> > This has no significant effect on compile time for files which import
> > small
> > numbers of symbols. But for cases where the number is large I find that
> > the
> > compile time can be reduced by up to 40% in the cases I've tried.
> >
> > The change passes all regression tests cleanly.
>
> The patch is OK for trunk.
>
> Thanks!
>
> Regards
>
> Thomas
--
* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html
* Galacticus: https://bitbucket.org/abensonca/galacticus
>
> > This just delays the call to find_symbol() until after the first test of
> > whether the symbol needs to be loaded - if that test fails then
> > find_symbol() is never called.
> >
> > This has no significant effect on compile time for
st of
> > whether the symbol needs to be loaded - if that test fails then
> > find_symbol() is never called.
> >
> > This has no significant effect on compile time for files which import
> > small
> > numbers of symbols. But for cases where the number is l
would need that also.
Thank you,
Andrew Benson
gt; If a symtree is not found and the module does not import one,
> >>> a unique-name symtree is found by read_cleanup. */
> >>>
> >>> st = find_symtree_for_symbol (gfc_current_ns->sym_root, sym);
> >>> if (st != NULL)
> >&g
on implementation of
new features and bug fixing then I'm all for it. My knowledge of compiler
development is far too limited to judge how difficult maintaining ABI/.mod
compatibility is in any specific situation though!
-Andrew
--
* Andrew Benson: http://www.tapir.caltech.edu/~abenson
checks are redundant and can be
removed. I added some asserts in the cases there was no check before, so
that the code is strictly equivalent.
That patch works for me - both for the test case and for the full library that
I was attempting to compile.
Thanks,
Andrew.
--
* Andrew Benson: http
37 matches
Mail list logo
