It's a pity that I've made the same fixes myself. I was planing to commit
soon. :-(
On Tuesday 02 August 2011 17:34:46 Tobias Burnus wrote:
> This patch fixes dg-final cleanup-modules issues:
> * Missing cleanups
> * Wrong case: All module files are lower case
This is not actually a problem as cl
On Tuesday 02 August 2011 17:47:37 Tobias Burnus wrote:
> Simple patch: Coarrays are identified by a token; this patch passes the
> token (which is stored in the descriptor allocatable coarrays) to
> libcaf's registering function.
>
> In terms of token and allocatable coarrays: The next step is to
Hello,
On Tuesday 02 August 2011 18:08:05 Tobias Burnus wrote:
> This patch fixes two issues:
>
> a) LOCK(coarray%lock_type_comp) is also a coarray.
>
> b) The following constraint was incompletely checked for: C1302. For
> reference, I also list C1303/C1304.
[...]
>
> PS: It somehow took me
On Tuesday 02 August 2011 18:01:35 Mikael Morin wrote:
> Thanks. I'll see if I have additional fixes after updating.
Here they are.
Tobias, I would like your input on lto/pr47839_{0,1}.f90 for which you put the
cleanup directive for module pec_mod from pr47839_1.f90 in the pr47839_0.f
-fdump-tree-lim1" }
! gfortran -c -m32 -O2 -S junk.f
!
MODULE LES3D_DATA
@@ -46,5 +46,5 @@
RETURN
END
! { dg-final { scan-tree-dump-times "stride" 4 "lim1" } }
-! { dg-final { cleanup-tree-dump "lim\[1-2\]" } }
+! { dg-final { cleanup-tree-du
Hello,
On Wednesday 03 August 2011 15:47:37 Richard Guenther wrote:
> Comments? Any idea why reversing the loop would break?
Yes, the list of scalarized expressions has to be created in the same order it
is consumed. Here the scalarized expressions are array indexes to be
precomputed out of th
On Thursday 04 August 2011 13:12:04 Richard Guenther wrote:
> On Thu, 4 Aug 2011, Richard Guenther wrote:
> > On Wed, 3 Aug 2011, Mikael Morin wrote:
> > > Hello,
> > >
> > > On Wednesday 03 August 2011 15:47:37 Richard Guenther wrote:
> > > >
On Wednesday 03 August 2011 17:55:00 Tobias Burnus wrote:
> > Though variables in the general case can be components, I don't think it
> > is the case here as only named variables are involved here.
> > Does that sound right?
>
> The first part of the sentence sounds wrong: A component itself is n
On Thursday 04 August 2011 15:18:46 Tobias Burnus wrote:
> >> The problem is that
> >> diagnosing the problem can get rather difficult. For instance:
> >>
> >> type t
> >> type(lock_type) :: C
> >> end type
> >> type t2
> >> type(t), allocatable :: B
> >> end type t2
> >> type t3
> >> type(t2) ::
On Wednesday 03 August 2011 22:55:34 Tobias Burnus wrote:
> Mikael Morin wrote:
> > Patch updated.
>
> Looks good! Thanks for the further clean up!
>
Committed as revision 177415.
I also added the gfortran.dg/ directory in the ChangeLog for you previous
patch (as revisio
On Thursday 04 August 2011 22:45:34 Steve Kargl wrote:
> On Tue, Aug 02, 2011 at 05:34:46PM +0200, Tobias Burnus wrote:
> > There might be still some missing or wrong cleanups, but most remaining
> > .mod files are from gfortran.fortran-torture.
>
> Yes, you missed a few.
And you missed my two pa
On Thursday 04 August 2011 23:46:08 Steve Kargl wrote:
> On Thu, Aug 04, 2011 at 11:36:11PM +0200, Mikael Morin wrote:
> > On Thursday 04 August 2011 22:45:34 Steve Kargl wrote:
> > > On Tue, Aug 02, 2011 at 05:34:46PM +0200, Tobias Burnus wrote:
> > > > There might
OK, I played a bit myself to see what the "right way" would look like, and I
came up with the attached patch, which is complicated, and not even correct.
And indeed, it plays with allocatable and pointer stuff.
So your approach makes some sense now.
I do here some propositions for comment and er
On Thursday 04 August 2011 23:42:11 Janus Weil wrote:
> Hi all,
>
> attached is a draft patch fixing the PR in the subject line and
> extending the checks for overriding type-bound functions. It regtests
> cleanly on x86_64-unknown-linux-gnu already, but I would like to have
> some feedback.
Some
On Friday 05 August 2011 19:30:49 Janus Weil wrote:
> Hi Mikael,
>
> >> The extra
> >> argument controls whether we check variable symbols for equality or
> >> just their names. For the overriding checks it is sufficient to check
> >> for names, because the arguments of the overriding procedure ar
On Wednesday 03 August 2011 15:32:45 Rainer Orth wrote:
> This is the revised/updated version of the patch originally posted at
>
> [build] Move unwinder to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
>
> and reposted as CFT at
>
> http://gcc.gnu
On Thursday 04 August 2011 17:00:46 Tobias Burnus wrote:
> This patch fixes the result check for coarrays / variables with coarray
> subcomponents. It was working with a separate RESULT() variable - but
> not if the function name was the result variable.
>
> Build and regtested on x86-64-linux.
>
On Friday 05 August 2011 23:02:33 Thomas Koenig wrote:
> > The extra
> > argument controls whether we check variable symbols for equality or
> > just their names. For the overriding checks it is sufficient to check
> > for names, because the arguments of the overriding procedure are
> > required to
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:
> On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote:
> > I suppose it is this patch that breaks bootstrap
The culprit is indeed r177447.
>
> Adding a -I flag? I suppose that makes sense even if crtstuff is
> moved soon
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
> Can you try this instead?
It works. Thanks
Mikael
On Saturday 06 August 2011 17:39:06 Thomas Koenig wrote:
> > As Thomas mentions, certain cases are still not handled correctly
> > (e.g. A+B+C vs C+B+A, and other mathematical transformations), but I
> > hope they are sufficiently exotic (so that we can wait for bug reports
> > to roll in). In addi
On Saturday 06 August 2011 18:06:58 Janus Weil wrote:
> >> It is wrong to assume that expressions are unequal because we cannot
> >> prove they are equal, with all the limitations that we currently
> >> have. This will introduce rejects-valid bugs.
> >
> > In the PR at
> > http://gcc.gnu.org/bugz
On Saturday 06 August 2011 19:10:09 Janus Weil wrote:
> Now, if Thomas says it's fine for the other cases, too, then it seems
> we can really get away with a much simpler patch. Hope we're not
> missing anything, though ...
>
What about this case: two module variables from two different modules?
On Sunday 07 August 2011 00:21:46 Janus Weil wrote:
> Well, ok. After this amount of discussion, how about we start with the
> easy things: Here is a preparational patch (basically a subset of the
> previous one), which does not do any real changes yet, only some
> preparation and cleanup:
> * It m
'm testing it on x86_64-unknown-
freebsd8.2. OK for trunk if it passes? What about the branches? It is not a
regression, but it looks like a genuine bug.
Mikael
2011-08-12 Mikael Morin
PR fortran/50050
* gfortran.h (gfc_clear_shape, gfc_free_shape): New prototypes.
* expr.c (
in a BLOCK construct, jump to the parent namespace. */
ns = gfc_current_ns;
while (ns->proc_name && ns->proc_name->attr.flavor == FL_LABEL)
ns = ns->parent;
+ }
/* First see if the label is already in this namespace. */
lp = ns->st_label
x27;m doing a
full regression test. Is that OK?
About your two former cases, the first one looks especially tricky. For the
second one, it may be valid, but a warning would be nice IMO as one of the
labels is masked by the other. Both cases need more investigation anyway.
Mikael.
201
Hello,
Two nits below...
On Thursday 18 August 2011 00:50:29 Tobias Burnus wrote:
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2910ab5..dc619c3 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -2148,15 +2157,76 @@ endType:
[...]
> +
> +/* Check for F2008
On Thursday 18 August 2011 11:59:36 Tobias Burnus wrote:
> The patch should be rather simple and self explaining.
It is indeed with the extra context.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
Yes.
>
> I wonder how far we should backport; the program is said to work in
> 4.1.
associate (j => i)
+ goto 1
+ print *, 'Hello'
+1 end associate
+end
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (révision 177884)
+++ testsuite/ChangeLog (révision 177885)
@@ -1,3 +1,9 @@
+20
On Friday 19 August 2011 12:05:02 Janus Weil wrote:
> Ping! (Maybe I should have posted the follow-up patch in a separate
> thread to make it more visible.)
I saw it, had a quick glance, thought that Thomas would jump on it, and
forgot. Sorry.
>
> 2011/8/13 Janus Weil :
> > Hi Thomas, hi all,
>
Hello,
I'm going to commit the following (to trunk and 4.6) once the regression test
finishes.
Mikael
2011-08-19 Mikael Morin
PR fortran/50129
* parse.c (parse_where): Undo changes after emitting an error.
2011-08-19 Mikael Morin
PR fortran/
On Friday 19 August 2011 23:54:45 Janus Weil wrote:
> > I have one comment though about this:
> > +/* Compare two expressions. Return values:
> > + * +1 if e1 > e2
> > + * 0 if e1 == e2
> > + * -1 if e1 < e2
> > + * -2 if the relationship could not be determined
> > + * -3 if e1 /= e2, b
On Saturday 20 August 2011 21:29:21 Janus Weil wrote:
> >> > There is for example (currently) no special handling for operators.
> >>
> >> Well, unfortunately one cannot just return "-3" for non-matching
> >> operators. Just think of cases like A*(B+C) vs A*B+A*C.
> >
> > Ah yes. I was thinking e
On Tuesday 23 August 2011 11:48:27 Tobias Burnus wrote:
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK.
Mikael
(and then committed) as soon as possible.
Otherwise OK for 4.{4..7} ?
Mikael
PS: Sorry for the breakage, and thanks to Andrew Benson for the early report
(with a reduced testcase !). I was about to break the 4.5 branch as well
before I saw it.
2011-08-22 Mikael Morin
PR fortran/
On Tuesday 23 August 2011 14:26:59 Tobias Burnus wrote:
> The bug is a regression: An error was printed with 4.1.x but since 4.3.x
> one gets an ICE. [No idea what GCC 4.2 does.] The solution is simply:
> Returning if there is a MATCH_ERROR.
>
> See PR (esp. comment 2) for a more detailed descript
On Wednesday 24 August 2011 15:31:17 Tobias Burnus wrote:
> > Isn't there some rules about backporting? The way we do it now, it
> > looks completely arbitrary.
>
> I think it *is* arbitrary - and unavoidable so.
>
> The main idea behind regression fixing is to make sure that what once
> worked s
On Monday 22 August 2011 23:22:08 Tobias Burnus wrote:
> Dear all,
>
> this patch added token/offset support for assumed-shape coarray dummies
> (with .-fcoarray=lib).
>
> Build and regtested.
> OK for the trunk?
>
OK, thanks.
Mikael
On Saturday 27 August 2011 02:34:24 Steve Kargl wrote:
> The attached patch allows gfortran to compile the
> attached testcase. The resulting executable runs
> as expected.
>
> Short story:
>
> character(len=20) :: string = 'some text here'
> character(len=:), allocatable :: s
> n = 5
>
On Friday 26 August 2011 08:51:37 Tobias Burnus wrote:
> Allocatable coarrays are freed and deregistered via the libcaf function
> _gfortran_caf_deregister. Currently, the front end does not generate
> calls to the that function, however, this patch already implements the
> function.
>
> See http:
Hello,
the 4 follow-up patches try to refactor some common code initializing gfc_ss
structs.
Regression-tested (the 4 patches together only) on x86_64-freebsd8.2.
OK for trunk?
Mikael
trans-array.c | 181 -
trans-array.h |6 ++
tr
All the gfc_ss of type GFC_SS_FUNCTION, GFC_SS_ARRAY, GFC_SS_CONSTRUCTOR,
GFC_SS_VECTOR, ... have the same kind of initialization. Let's share it.
OK?
2011-08-30 Mikael Morin
* trans-array.h (gfc_get_array_ss): New prototype.
* trans-array.c (gfc_get_array_ss): New fun
gfc_ss structs of type GFC_SS_TEMP are not uncommon. Let's share their
initialization.
OK?
2011-08-30 Mikael Morin
* trans-array.h (gfc_get_temp_ss): New prototype.
* trans-array.c (gfc_get_temp_ss): New function.
(gfc_conv_resolve_dependencies): Re-use gfc_get_te
?
2011-08-30 Mikael Morin
* trans-array.c (gfc_trans_constant_array_constructor): Remove
superfluous initialisation of DIM field.
(gfc_trans_array_constructor): Assert that DIMEN field is properly set.
(gfc_conv_expr_descriptor): Ditto.
* trans-expr.c
value afterwards in the one case it is needed (in
gfc_walk_elemental_function_args).
OK?
2011-08-30 Mikael Morin
* trans-array.h (gfc_get_scalar_ss): New prototype.
* trans-array.c (gfc_get_scalar_ss): New function.
(gfc_walk_variable_expr, gfc_walk_op
On Wednesday 24 August 2011 10:58:19 Tobias Burnus wrote:
> On 08/24/2011 12:01 AM, Mikael Morin wrote:
> > this is an attempt to fix my recent breakage for PR50050.
> > I forgot that shape can't always be known, and thus, that for some
> > expressions, the sha
On Monday 05 September 2011 18:11:47 Tobias Burnus wrote:
> On 09/03/2011 02:49 PM, Tobias Burnus wrote:
> > This patch implements the parsing/diagnostic for "DO[,] CONCURRENT
> > for-all-header", e.g.
> >
> > do concurrent (i = 1:5)
> > A(i) = B(i)
> > end do
>
> (Side remark: do concurr
On Tuesday 06 September 2011 09:23:11 Tobias Burnus wrote:
> http://gcc.gnu.org/ml/fortran/2011-08/threads.html#00264
>
> Mikael Morin wrote:
> > the 4 follow-up patches try to refactor some common code
> > initializing gfc_ss structs.
> > Regression-tested (the 4 patch
delayed if
preferred; unfortunately, patch 14 fails without this one.
2011-09-14 Mikael Morin
* check.c (is_coarray): Remove.
(coarray_check): Use gfc_is_coarray.
diff --git a/check.c b/check.c
index 3d4f4c8..81f7b30 100644
--- a/check.c
+++ b/check.c
@@ -203,42 +203,10
Hello,
the scalarizer is there to generate loops for assignments over more than
one element. Tobias extended it at various places to support coarrays,
but this should not be necessary as coarrays in assignments either refer
to the array present on the local image or to the one on the remote image
is exactly the same).
OK?
2011-09-14 Mikael Morin
* resolve.c (compare_spec_to_ref): Move coarray ref initialization
code...
(resolve_array_ref): ... here.
diff --git a/resolve.c b/resolve.c
index b038402..4c991c8 100644
--- a/resolve.c
+++ b/resolve.c
@@ -4389,14
code based on that assumption.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_expr_descriptor): Simplify coarray
descriptor setup code.
diff --git a/trans-array.c b/trans-array.c
index 37cdeb5..88849ef 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -6140,22 +61
es (if we don't want to rewrite it
completely) that the expression's gfc_ss struct passes through the scalarizer
(in the scalar coarray case, it will do nothing but get the descriptor).
This patch changes the assertion so that zero rank loops are accepted.
OK?
2011-09-14 Mikael Morin
This removes the gfc_ss::data::temp::codimen field and the code depending on
it.
OK?
2011-09-14 Mikael Morin
* trans.h (gfc_ss): Remove data.temp.codimen field.
* trans-array.c (gfc_conv_resolve_dependencies,
gfc_conv_expr_descriptor): Don't set temp's cod
much as we want, the coarray dimen_type part
will be left untouched (and properly set).
The duplicate code in gfc_walk_variable_expr can't be removed, as it seems that
some array references are not passed through resolve_array_ref (I didn't
investigate further).
OK?
2011-09-14 Mikae
This removes the coarray code in gfc_walk_variable_expr.
See the ChangeLog for details.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_walk_variable_expr): Remove scalar coarray
handling. Don't reset array ref's corank and codimensions' types
in the
that they deserved to die. ;-)
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_section_startstride): Move code to
evaluate_bound. Use evaluate_bound.
(evaluate_bound): New function.
diff --git a/trans-array.c b/trans-array.c
index 7f44514..ee5761b 100644
--- a/trans-arr
At this point, gfc_conv_section_startstride has two callers, and for both
of them, the last argument (coarray_last) has the value false.
This patch removes the argument.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_section_startstride): Remove coarray_last
argument
This merges two identical switch cases. It didn't fit anywhere else, so here
it is, alone.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_ss_startstride): Merge two switch cases.
diff --git a/trans-array.c b/trans-array.c
index a034886..86eb6c8 100644
--- a/trans-array.c
This patch removes gfc_ss::codimen field and any code depending on it.
OK?
2011-09-14 Mikael Morin
* trans.h (gfc_ss_info): Remove codimen field.
* trans-array.c (gfc_get_array_ss): Don't set codimen field.
(gfc_trans_create_temp_array): Don't set de
d, so we can remove that one two.
To make sure that we don't add unnecessary (and possibly costly) stride
evaluation code, that is the (stride == NULL) branch is taken, we add an
assertion in gfc_conv_expr_descriptor to check that ar->stride[dim] == NULL.
Then we can remove the flag.
O
This removes the gfc_loopinfo::codimen field and the code associated with it.
OK?
2011-09-14 Mikael Morin
* trans.h (gfc_loopinfo): Remove codimen field.
* trans-array.c (gfc_set_vector_loop_bounds,
gfc_trans_scalarizing_loops, gfc_conv_loop_setup): Update loop upper
n the general function call case (cf also my comment about patch 6).
On the other hand, it was also the case for the convert_element_to_coarray_ref
function before the patch.
Note2: This patch may need some adjustments to fix PR50420.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50420
2011-09-14 M
] and loop.to[n] "by hand".
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_expr_descriptor): Add out-of-the-scalarizer
cobounds evaluation.
diff --git a/trans-array.c b/trans-array.c
index 067fe0b..b132bf6 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -
rtion in gfc_conv_section_startstride to accept
coarray dimensions.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_section_startstride): Update assertion to
also accept coarrays.
diff --git a/trans-array.c b/trans-array.c
index 7cc86ba..7f44514 100644
--- a/trans-array.c
The Changelog says it all.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_section_startstride): Factor common
array ref references.
diff --git a/trans-array.c b/trans-array.c
index 0f5f29c..7cc86ba 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -3187,12 +3187,14
This uses the just set codim (see patch 5) as argument to
gfc_get_array_type_bounds.
OK?
2011-09-14 Mikael Morin
* trans-array.c (gfc_conv_expr_descriptor): Use codim instead of
loop.codimen as argument to gfc_get_array_type_bounds.
diff --git a/trans-array.c b/trans-array.c
scalarizer, let's
calculate the corank without relying on the scalarizer.
This patch just does that.
A new want_coarray flag is introduced as sometimes we want to treat coarrays
as normal arrays, that is we want a descriptor for the local image only.
OK?
2011-09-14 Mikael
This patch was necessary on a previous version of the patchset (I was calling
gfc_get_corank on non-coarrays with e->symtree == NULL, and it was segfaulting
on the first e->symtree dereferencing). In the current version, it is optional,
but I propose it anyway as (I think) it makes some sense.
Th
assumed shape coarray
dummies. The patch does that.
However, what comes up from testing is that neither is needed.
I'm not submiting this patch for approval, I'm submitting it to understand why
it is not necessary.
How are cobounds passed to a coarray dummy?
2011-09-14 Mikael Morin
Hello,
sorry for the slow (yet faster than anyone else ;) review.
I'm a bit surprised that there is no resolve.c or iresolve.c change.
intrinsic.c may cerainly need some modification too.
Same goes for trans-intrinsic.c, but perhaps resolution time support is
sufficient in the library call case
On Monday 03 October 2011 23:02:15 Janus Weil wrote:
> Hi all,
>
> here is a patch for a rather long-standing PR. It continues my ongoing
> campaign of improving the checks for "procedure characteristics" (cf.
> F08 chapter 12.3), which are relevant for dummy procedures, procedure
> pointer assign
On Tuesday 04 October 2011 19:01:50 Janus Weil wrote:
> If you have a cute idea how to elegantly introduce warnings into this
> mechanism, I'm all ears.
I'm not sure that it qualifies as cute, but we could produce multi-line
diagnostics in the same way c++ does (for template candidates for example
accept expression with subreferences.
10..11/14: Fix corank checking
12/14: Accept coarray subreferences in simplify_cobound
13/14: Fix gfc_build_array_type
14/14: Fix gfc_build_array_ref
2011-10-06 Mikael Morin
PR fortran/50420
* gfortran.dg
a call to gfc_get_corank.
Then, in gfc_find_array_ref the coarray-specific code can be removed.
This is patch 11.
OK?
2011-10-06 Mikael Morin
PR fortran/50420
* check.c (dim_corank_check): Use gfc_get_corank to get corank.
diff --git a/check.c b/check.c
index 9b8ec21..9b1e3a9 100644
---
end, it's fine. ;-)
2011-10-06 Mikael Morin
* trans-array.h (gfc_walk_array_ref): New prototype.
* trans-array.c (gfc_walk_array_ref): New function, containing
all but the beginning of gfc_walk_variable_expr's code.
(gfc_walk_variable_expr): Use gfc_walk
span stuff this function is about, so
I wouldn't mind Paul having a look.
2011-10-06 Mikael Morin
PR fortran/50420
* trans.c (gfc_build_array_ref): If type is not an array, check that
there is nothing to do, and do nothing.
diff --git a/trans.c b/trans.c
index 764bdf
f's elements or loop
elements.
Patches 1 and 2 are preliminary changes.
OK?
2011-10-06 Mikael Morin
* trans-array.c (gfc_conv_expr_descriptor): Move ndim initialization
earlier.
diff --git a/trans-array.c b/trans-array.c
index 5144398..1db2186 100644
--- a/trans-ar
simplify_cobound, when it looks for the coarray reference, in the AR_ELEMENT
case, first checks that it is the last reference in the chain.
As it is what we are trying to avoid, this patch removes that and uses the
corank field directly.
OK?
2011-10-06 Mikael Morin
PR fortran/50420
but I wouldn't mind
a confirmation. ;-)
OK?
2011-10-06 Mikael Morin
PR fortran/50420
* trans-types.c (gfc_build_array_type): Don't force lower bound to one
in the deferred case.
diff --git a/trans-types.c b/trans-types.c
index 43f1a19..652c009 100644
--- a/tran
On Friday 30 September 2011 18:51:21 Steve Kargl wrote:
> Mikael,
>
> I've finally made it through the set of patches,
> and did not find anything that raised a red flag.
> I'll note that I did not study the issue/question
> you raised with patch 6. Tobias is probably the
> best person to offer a
On Wednesday 28 September 2011 16:28:24 Tobias Burnus wrote:
> This patch makes the GCC extension __float128 (_Complex) available in
> the C bindings via C_FLOAT128 and C_FLOAT128_COMPLEX.
>
> Additionally, I have improved the diagnostic for explicitly use
> associating -std= versioned symbols. An
As a result the -k flag has to be added to the
make command line if one wants the tests to continue after one failure.
OK for trunk?
Mikael
PS: Jakub, I CCed you as you are the author of the Makefile chunk.
2011-10-09 Mikael Morin
* Makefile.in (check-parallel-%): Don't ignore
me);
+ "argument '%s'", i + 1, s1->name);
return FAILURE;
case -2:
Index: ChangeLog
=======
--- ChangeLog (révision 179725)
+++ ChangeLog (révision 179726)
@@ -1,3 +1,8 @@
+2011-10-09 Mikael Morin
+
+ * interface.c (check_dummy_characteristics): Count dimensions starting
+ from one in diagnostic.
+
2011-10-09 Tobias Burnus
* Make-lang.in (F95_PARSER_OBJS, GFORTRAN_TRANS_DEPS): Add
===
--- ChangeLog (révision 179726)
+++ ChangeLog (révision 179727)
@@ -380,7 +380,7 @@
* symbol.c (check_conflict): Allow threadprivate attribute with
FL_PROCEDURE if proc_pointer.
-2011-08-25 Mikael Morin
+2011-08-25 Mikael Morin
PR fortran/50050
* expr.c (gfc_free_shape): Do nothing if shape is
method.
(gfc_conv_intrinsic_merge): Call it here to actually do the check.
-2008-12-15 Mikael Morin
+2008-12-15 Mikael Morin
PR fortran/38487
* dependency.c (gfc_is_data_pointer): New function.
@@ -53,7 +53,7 @@
in the pointer case.
(gfc_check_dependency): Use
On Sunday 09 October 2011 19:30:20 Richard Guenther wrote:
> We usually don't retroactively change ChangeLogs this way.
On the other hand, ChangeLogs usually don't need to be changed.
> Please refrain from making further changes like this.
OK, I will. Is there a reason for such a policy?
Mikael
On Sunday 09 October 2011 21:12:12 Jakub Jelinek wrote:
> On Sun, Oct 09, 2011 at 04:32:12PM +0200, Mikael Morin wrote:
> > currently, the testsuite return value is ignored by make. It is a little
> > annoying if one wants to check automatically for regressions as we have
&
On 08/03/2012 15:13, Tobias Burnus wrote:
> After a lengthy debugging, I finally found the issue. If I hadn't be
> concentrating that much on -fwhole-file and if I had had a closer look
> at the test case before, I hadn't wasted hours tracking this one down ...
>
> The problem is that a procedure
On 06/03/2012 21:41, Steven Bosscher wrote:
> Hi,
>
> This cleans up some remnants of the ancestors of fortran's convert.c,
> which was copied from GNAT IIRC.
>
> I would bootstrap&test this, but trunk appears to be broken for
> x86_64-linux right now (ICE in patch_jump_insn). But I can post this
On 01/03/2012 22:09, Bernhard Reutner-Fischer wrote:
> Hi,
>
> By now we have quite some leftover modules in the testsuite, again.
> Given that the previous suggestion in this thread -- to have a separate
> script in contrib -- did not trigger any reaction, let me suggest the
> patch below instead
of reallocatable variables such as derived types or
>> (scalar) character variables with deferred length.
>
> On 02/27/2012 09:59 PM, Mikael Morin wrote:
>>> In turn, the warning might be printed even if at the end no realloc
>>> code is
>>> generated or prese
On 12/04/2012 17:23, Tobias Burnus wrote:
> This patch is a kind of follow up to the other one for the same PR -
> though this one is for a separate test case, it is not a regression and
> it's about actual/formal checks.
>
> When trying to fix the rejects-valid bug, I realized that one function
>
{
- dim = get_scalarizer_dim_for_array_dim (ss, ss->dim[n]);
+ dim = get_scalarizer_dim_for_array_dim (ss, s->dim[n]);
/* For a callee allocated array express the loop bounds in terms
of the descriptor fields. */
2011-11-24 Mikael Morin
PR fortran/51250
PR fortran/4
n++)' loop.
Regression tested on x86_64-unknown-linux-gnu (with the just posted pr51250
patch). OK for trunk?
Mikael
2011-11-24 Mikael Morin
* trans-array.c (set_loop_bounds): Remove dead conditions.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 2fb2d34..
On Friday 25 November 2011 11:10:01 Janne Blomqvist wrote:
> Based on a brief inspection of the code, most if
> not all of these seeks are for a very short distance (typically peek a
> few bytes ahead in the stream, then seek back)
I'm afraid they aren't.
The moves are as follows (-: sequential, x:
On Wednesday 30 November 2011 18:32:11 Janne Blomqvist wrote:
> Hi,
>
> this patch expands a bit on the recent work done by Thomas Koenig.
> Using aermod.f90 from the polyhedron benchmark suite as a test case,
> the lseek() calls as reported by strace -c -f go roughly as
>
> - trunk before Thomas
On Wednesday 30 November 2011 23:49:58 Janne Blomqvist wrote:
> > With the updated patch, the number of lseek's when compiling
> > aermod.f90 drop to 38, which is a factor of 15 reduction compared
> > to the current trunk. And a factor of 55 compared to trunk a few days
> > ago before Thomas' p
On Saturday 03 December 2011 20:12:50 Tobias Burnus wrote:
> Another OOP-related patch: If one uses type extension, the first
> REF_COMPONENT does not necessarily refer directly to a component in the
> linked list starting at sym->ts.u.derived->components.
>
> Using simply ref->u.c.component direc
801 - 900 of 1075 matches
Mail list logo
