le and submodule 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/gala
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.
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
> &
raised 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.carnegiesci
;
> 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 "paren
> 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
.gnu.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/fortr
ed it sufficiently 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
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
it 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
> > pat
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
submodule 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
*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?
>
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/galactic
> 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 \
>
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:7848054c68bad6e2aa40cb59f77cc99bd8
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
*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, 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, af
e best attentions. Could
> > 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
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 files which import
> > small
> > numbers of s
if (!only_flag && st)
> >
> > 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 signif
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 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
?
-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
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:
> > >> As
ssignment): 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
>
18 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:
> > >> As suggested by Janus, PR87103 is
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
==
--- gcc/fortran/ChangeLog (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.
+
2
();
> >
> > 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
mport one,
> >>> a unique-name symtree is found by read_cleanup. */
> >>>
> >>> st = find_symtree_for_symbol (gfc_current_ns->sym_root, sym);
> >>> if (st != NULL)
> >>>
> >>>
Then some external NULL shape 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.
T
very important in general - if
compatibility can be maintained without stifling progress 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 si
36 matches
Mail list logo