Hello, thanks for your contribution.
here are some comments about the patch:
Le 21/07/2014 15:03, Andre Vehreschild a écrit :
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c33936b..cb01a13 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
Changelogs are
to Tobias for identifying the problem.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 208912)
+++ ChangeLog (révision 208913)
@@ -1,5 +1,11 @@
-2014-04-27 Thomas Koenig tkoe...@gcc.gnu.org
+2014-03-28 Mikael Morin mik
Le 02/04/2014 22:29, Paul Richard Thomas a écrit :
Dear All,
This fix, of itself, is quite obvious. The offset was being set to
zero for array segments, rather than that required for unity valued
lvalues.
I think that the fix could be used to clean up:
Hello,
Le 06/04/2014 18:05, Tobias Burnus a écrit :
Bernhard Reutner-Fischer wrote:
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
+bool has_final2 = false;
+if (!gfc_resolve_finalizers (c-ts.u.derived, has_final))
+ return false; /* Error. */
+
Le 06/04/2014 19:46, Tobias Burnus a écrit :
Mikael Morin wrote:
Le 06/04/2014 18:05, Tobias Burnus a écrit :
It is supposed to propagate the information whether any of the
components (c) has a derived type. However, I made a typo: It
should be has_final2 instead of has_final
Le 06/04/2014 20:30, Tobias Burnus a écrit :
Mikael Morin wrote:
Argh. great. What about the use_assoc thing? Why is that needed?
Frankly, I don't know. In terms of the code, the problem is that
attr.use_assoc is zero and, hence, the compiler generates a call to some
external version which
it worked even without bootstrap.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 207151)
+++ ChangeLog (révision 207152)
@@ -1,3 +1,9 @@
+2014-01-27 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/58007
+ * module.c (skip_list
Le 01/02/2014 18:57, Paul Richard Thomas a écrit :
Dear All,
This regression was flagged by Harald and the trigger, r158683, was
identified by HJ. Many thanks to both. It surprises me that the bug
has lain dormant for so long.
The fix is fortunately relatively simple. CHARACTER scalars
, it seems to be correct.
regression tested on x86_64-unknown-linux-gnu; OK for trunk and then
4.8/4.7?
Mikael
2014-01-26 Mikael Morin mik...@gcc.gnu.org
PR fortran/57033
* primary.c (gfc_convert_to_structure_constructor): Avoid null pointer
dereference.
2014-01-26 Mikael
Le 02/02/2014 21:31, Janus Weil a écrit :
Hi all,
the attached patch fixes an OOP-related 4.7-only regression. Pretty
much straightforward, for details see PR.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
Yes, thanks.
Mikael
Le 06/02/2014 11:43, Janus Weil a écrit :
Hi all,
attached is a small patch which fixes an ICE-on-invalid regression
with finalization. In the PR, Dominique objected to the patch, but I
think it's the correct thing to do after all. The line that I'm
removing was added in a patch authored by
Le 06/02/2014 23:40, Janus Weil a écrit :
Hi Mikael,
thanks for your comments ...
attached is a small patch which fixes an ICE-on-invalid regression
with finalization. In the PR, Dominique objected to the patch, but I
think it's the correct thing to do after all. The line that I'm
Le 07/02/2014 21:42, Mikael Morin a écrit :
maybe add gcc_assert to
make it clear that fini-proc_tree should be set at this point.
Or better: a comment ;-)
Le 07/02/2014 19:18, Paul Richard Thomas a écrit :
Dear All,
I propose to add the attached to the testsuite. It is the testcase
from PR60066, which was fixed by the patch for PR59066.
OK for trunk, 4.8 and 4.7?
Yes, sure.
Mikael.
Le 08/02/2014 18:48, Paul Richard Thomas a écrit :
Dear All,
This is another corner of a corner case that is not a regression but
fixes a wrong-code-on-valid.
At present, an actual argument of an elemental procedure with the
VALUE attribute is not passed by value. The fix is obvious.
the gfc_intrinsic_argument_list_length function
like it's done for other intrinsics.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8/4.7?
Mikael
2014-02-14 Mikael Morin mik...@gcc.gnu.org
PR fortran/59599
* trans-intrinsic.c (gfc_conv_intrinsic_ichar): Calculate
Le 15/02/2014 11:04, Richard Biener a écrit :
On Fri, 14 Feb 2014, Mikael Morin wrote:
Hello,
this bug is not a regression, but the patch shouldn't wreck the compiler
too much on the other hand.
The problem is a wrong number of arguments while generating code for the
ichar intrinsic
Le 19/02/2014 16:51, Janus Weil a écrit :
The patch was not applying cleanly any more, so here is a re-diffed
version for current trunk. It works nicely on the included test case
as well as the one provided by Walter Spector in comment 12 of the PR.
Since, also in the current state,
===
--- gcc/testsuite/ChangeLog (révision 208248)
+++ gcc/testsuite/ChangeLog (révision 208249)
@@ -1,3 +1,8 @@
+2014-03-01 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/60341
+ * gfortran.dg/str_comp_optimize_1.f90: New test.
+
2014-03-01 Oleg Endo olege
Le 01/03/2014 16:58, Janus Weil a écrit :
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c (revision 207896)
+++ gcc/fortran/trans-stmt.c (working copy)
@@ -5028,6 +5028,11 @@ gfc_trans_allocate (gfc_code *
, I have filled the matrices one element at a
time in the testcase.
2014-03-09 Mikael Morin mik...@gcc.gnu.org
PR fortran/60392
* trans-array.c (gfc_conv_array_parameter): Don't reuse the descriptor
if it has transposed dimensions.
2014-03-09 Mikael Morin mik...@gcc.gnu.org
PR fortran
Hello,
Le 09/03/2014 13:59, jimmie.da...@l-3com.com a écrit :
The code would only remove a variable from a common block if it was just
defined in the previous statement. The PR showed a case where a pre-existing
variable was put in the common block. When it was not removed, the common
Le 09/03/2014 20:47, jimmie.da...@l-3com.com a écrit :
Comments from Mikael:
#1. Please merge the two ifs; it seems they have exactly the same scope
after the patch.
#2. This comment applies to the TOUPPER thing below...
.. so it should be put here. Also the indentation is wrong.
Le 11/03/2014 10:25, Janus Weil a écrit :
Regression-tested on x86_64-unknown-linux-gnu.
This is not a regression as far as I know, but quite a severe
wrong-code, albeit limited to the corner case of transpose and
assumed shape and contiguous. OK for trunk/4.8/4.7 anyway ?
I would say it's
Hello,
Le 10/03/2014 03:15, jimmie.da...@l-3com.com a écrit :
Index: gcc/gcc/fortran/symbol.c
===
--- gcc/gcc/fortran/symbol.c (revision 208437)
+++ gcc/gcc/fortran/symbol.c (working copy)
@@ -3069,56 +3069,56 @@
Le 16/03/2014 11:41, Thomas Koenig a écrit :
Hello world,
the attached patch fixes PR 60522, a regresseion where temporary
variables were incorrectly introduced in a BLOCK within a WHERE
statement.
Regression-tested on x86_64-unknown-linux-gnu.
OK for trunk and the other open
Le 23/12/2012 15:29, Tobias Burnus a écrit :
Please ignore that patch. I found a much simpler way, which is a tiny
patch and actually also works for the commented part of the test case of
the previous patch (i.e. the missed-optimization bit).
Namely, I now simply only tag all the symbols which
...@gcc.gnu.org
Mikael Morin mik...@gcc.gnu.org
* class.c (gfc_fix_class_refs): Adapt ts initialization for the case
e-symtree == NULL.
* trans-expr.c (gfc_conv_function_expr): Init sym earlier. Use it.
diff --git a/class.c b/class.c
index 8a8a54a..8b00a2c 100644
Hello,
Le 04/01/2013 00:23, Tobias Burnus a écrit :
NULL with MOLD should be rejected as (default) initialization
expression. From F2008:
R506 null-init is function-reference
C512 (R506) The function-reference shall be a reference to the intrinsic
function NULL with no arguments.
null-init
?
4.6?
Mikael
2013-01-05 Mikael Morin mik...@gcc.gnu.org
PR fortran/42769
PR fortran/45836
PR fortran/45900
* module.c (read_module): Don't reuse local symtree if the associated
symbol isn't exactly the one wanted. Don't reuse local symtree
Le 06/01/2013 13:06, Thomas Koenig a écrit :
Am 06.01.2013 12:45, schrieb Janus Weil:
I think your patch is indeed ok for trunk.
Thanks, applied as revision 194949.
4.7?
4.6?
Since it's not a regression, it does not necessarily need to be
backported. However, the sort of wrong-code behavior
Hello,
Le 04/01/2013 13:51, Tobias Burnus a écrit :
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 2610784..146154e 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3291,22 +3291,21 @@ gfc_check_assign (gfc_expr *lvalue, gfc_expr *rvalue,
int conform)
gfc_try
condition in check_for_ambiguous.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2013-01-08 Mikael Morin mik...@gcc.gnu.org
PR fortran/47203
* module.c (check_for_ambiguous): Get the current program unit using
gfc_current_ns.
diff --git a/module.c b
Le 09/01/2013 17:22, Tobias Burnus a écrit :
However, I still believe that we should do something -std=gnu.
Hm, reject?
One can't declare a procedure with one type on one side, and another
different type on the other side and expect things to work.
We don't support passing integer as real, or
Tobias Burnus bur...@net-b.de
Mikael Morin mik...@gcc.gnu.org
PR fortran/53537
* symbol.c (gfc_find_sym_tree): Don't look for the symbol outside an
interface block.
(gfc_get_ha_symtree): Let gfc_find_sym_tree lookup the parent namespace
Le 10/01/2013 20:39, Janus Weil a écrit :
Ping! (What do we do with this little bugger?)
@Paul: Was your comment 19 in the PR meant as an OK for my patch
(submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
or was it just a general agreement with the previous comments?
FWIW,
Le 07/01/2013 16:07, Tobias Burnus a écrit :
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index e05b935..0e0a71d 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -845,6 +845,7 @@ gfc_handle_option (size_t scode, const char *arg, int value,
break;
case
Le 01/01/2013 21:18, Thomas Koenig a écrit :
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
A few comments below.
Le 11/01/2013 21:31, Janus Weil a écrit :
Thanks for your review (which I read as an OK for all branches,
right?).
Well, from my point of view it is OK, but I was actually hoping Tobias
would ack it himself.
Le 13/01/2013 23:14, Thomas Koenig a écrit :
Hi Mikael,
thanks a lot for your comments!
+ actual_arglist-expr = gfc_copy_expr (e); +
actual_arglist-next = gfc_get_actual_arglist ();
Another one is needed. I get a segmentation fault with SUM.
Fixed by using gfc_build_intrisic_call.
Nice.
Le 13/01/2013 21:30, Harald Anlauf a écrit :
On 01/12/13 22:02, Mikael Morin wrote:
Le 08/01/2013 22:32, Harald Anlauf a écrit :
On 12/28/12 21:49, Harald Anlauf wrote:
Hello all,
is there a default directive that is assumed when the testsuite is run?
Running an fgrep -L on the fortran
Le 14/01/2013 00:37, Manfred Schwarb a écrit :
Am 14.01.2013 00:10, schrieb Manfred Schwarb:
There are several other oddities: d_g-final, braces have to be
separated by spaces.
Want to send a patch?
Not sure about the double braces in lto, I guess they act simply as
single braces.
I
Le 14/01/2013 23:16, Harald Anlauf a écrit :
Attached there is a partial patch for the obvious parts, plus other
missed cases (missing options). No failures, just a few more passes
from the fixed dg-do run's.
Thanks, applied as revision 195217.
Mikael
Hi Janus,
Le 27/01/2013 19:49, Janus Weil a écrit :
subroutine sub (arg)
procedure(sub) :: arg
end subroutine
You forgot to precise that this case (which is basically comment #4 in
the PR) is *not* fixed by the patch, as it fails later on at translation
stage.
I have made up my
.
The second fix makes the recursion through resolve_symbol, so that the
flag just added triggers and PR54195 is fixed.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2013-02-03 Mikael Morin mik...@gcc.gnu.org
PR fortran/54107
PR fortran/54195
Le 04/02/2013 09:37, Janus Weil a écrit :
- In PR54107(comment 26), the procedure result is a procedure pointer
whose interface is the procedure itself, which leads to an infinite
recursion during resolution.
- In PR54195, a type's type bound procedures are resolved twice, leading
to a symbol
Le 04/02/2013 14:02, Mikael Morin a écrit :
The fix, as discussed in PR54195, adds a flag to mark a symbol as
resolved.
Why not add this flag directly to gfc_symbol instead of
symbol_attribute? It seems we do not need the attribute for components
(or do we?).
Hum, indeed. symbol_attribute
-gnu. OK for trunk?
2013-02-07 Mikael Morin mik...@gcc.gnu.org
PR fortran/54107
* trans-types.c (gfc_get_function_type): Change a NULL backend_decl
to error_mark_node on entry. Detect recursive types. Build a variadic
procedure type if the type is recursive
===
--- testsuite/ChangeLog (révision 195889)
+++ testsuite/ChangeLog (révision 195890)
@@ -1,3 +1,8 @@
+2013-02-08 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/54107
+ * gfortran.dg/recursive_interface_2.f90: New test.
+
2013-02-08 Jakub Jelinek ja
Le 13/02/2013 09:32, Gopalasubramanian, Ganesh a écrit :
+liSupport for new AMD family 16h processors (Jaguar core) is now
available
+ through code-march=btver2/code and code-mtune=btver2/code
options./li
s/btver2/bdver2/ ?
Le 13/02/2013 14:00, Richard Biener a écrit :
Of course not. Next they'll add blver ...
Sorry
Le 14/02/2013 15:50, Tobias Burnus a écrit :
additionally, I tested and found
out that matrix-scalar/scalar-matrix was mishandled.
Indeed, thanks.
Build and regtested on x86-64-gnu-linux.
OK for the trunk and the 4.6 and 4.7 branches?
OK. (obvious actually)
Mikael
On Saturday 19 March 2011 19:59:56 Thomas Koenig wrote:
Am 19.03.2011 00:23, schrieb Tobias Burnus:
I have not followed the discussion nor have I fully read the patch, but
what's the reason for allowing ELEMENTAL functions?
Here's an updated version of the patch, which removes the
Here is the new version of the patch. Regression-tested. OK for trunk?
OK this time.
Thank you.
Mikael
Hello,
On Thursday 07 April 2011 21:50:46 Daniel Kraft wrote:
Ok. Just my opinion (as non-native-speaker), though:
+@item -ffrontend-optimize
+@opindex @code{frontend-optimize}
+@cindex Front-end optimization
+This option performs front-end optimization, based on the Fortran parse
+tree.
On Tuesday 05 April 2011 19:44:29 Tobias Burnus wrote:
This patch adds multi-image support to UCOBOUND. In the -fcoarray=single
case, the last dimension is just LCOARRAY (coarray, dim=corank).
However, if there are multiple images, one has for corank-1 coarrays:
lcobound(coarray) +
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
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 assignments,
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
to
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 mikael.mo...@sfr.fr
PR fortran/50420
* gfortran.dg
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 mikael.mo...@sfr.fr
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
. ;-)
2011-10-06 Mikael Morin mikael.mo...@sfr.fr
* 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_array_ref
stuff this function is about, so
I wouldn't mind Paul having a look.
2011-10-06 Mikael Morin mikael.mo...@sfr.fr
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
elements.
Patches 1 and 2 are preliminary changes.
OK?
2011-10-06 Mikael Morin mikael.mo...@sfr.fr
* 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-array.c
+++ b
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 mikael.mo...@sfr.fr
wouldn't mind
a confirmation. ;-)
OK?
2011-10-06 Mikael Morin mikael.mo...@sfr.fr
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
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 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 mikael.mo...@sfr.fr
* Makefile.in (check-parallel-%): Don't
)
+++ ChangeLog (révision 179726)
@@ -1,3 +1,8 @@
+2011-10-09 Mikael Morin mikael.mo...@sfr.fr
+
+ * interface.c (check_dummy_characteristics): Count dimensions starting
+ from one in diagnostic.
+
2011-10-09 Tobias Burnus bur...@net-b.de
* 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 mikael.mo...@gcc.gnu.org
+2011-08-25 Mikael Morin mik...@gcc.gnu.org
PR fortran/50050
method.
(gfc_conv_intrinsic_merge): Call it here to actually do the check.
-2008-12-15 Mikael Morin mikael.mo...@tele2.fr
+2008-12-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/38487
* dependency.c (gfc_is_data_pointer): New function.
@@ -53,7 +53,7 @@
in the pointer case
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
to parse the testsuite
On Sunday 09 October 2011 18:25:25 Tobias Burnus wrote:
On 07.10.2011 16:38, Mikael Morin wrote:
The full patchset has passed the fortran testsuite successfully.
OK for trunk?
OK for the whole patch set. Thanks for finding and fixing the issue!
Committed as follows.
I committed 8 and 9
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_preloop_setup): Move array reference
initialisation earlier. Factor subsequent array references.
diff --git a/trans-array.c b/trans-array.c
index 3472804..4b21476 100644
--- a/trans-array.c
+++ b/trans-array.c
This is a 6 steps program to update gfc_trans_preloop_setup.
gfc_trans_preloop_setup appeared completely rewritten. These step by step
patches show that it is not the case.
Combined patch attached here.
OK?
diff --git a/trans-array.c b/trans-array.c
index
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_preloop_setup): Remove redundant assertion.
Special case outermost loop.
diff --git a/trans-array.c b/trans-array.c
index e3134f5..f5e30ae 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -2867,7 +2867,10
This is for consistency. As dim == dimen-1 means we are in the outermost loop,
we should check against the loop dimension, not the array dimension.
An assertion is added to check that it is in fact the same.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_preloop_setup): Move common code...
(add_array_offset): ...into that new function.
diff --git a/trans-array.c b/trans-array.c
index 476978e..f615e4e 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -2830,6
As the first line of context shows, if the first condition is false, the second
is false too. Thus, the first condition is useless.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (get_array_ref_dim): Remove redundant condition.
diff --git a/trans-array.c b/trans-array.c
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_preloop_setup): Assertify one condition.
diff --git a/trans-array.c b/trans-array.c
index 5500ec4..8359af2 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -2885,8 +2885,7 @@ gfc_trans_preloop_setup (gfc_loopinfo
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_conv_ss_startstride): Access array bounds along
array dimensions instead of loop dimensions.
diff --git a/trans-array.c b/trans-array.c
index 8359af2..f4d8a85 100644
--- a/trans-array.c
+++ b/trans-array.c
?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_walk_array_ref): Skip coarray dimensions.
diff --git a/trans-array.c b/trans-array.c
index f615e4e..83fa7b6 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -7637,7 +7637,7 @@ gfc_walk_array_ref (gfc_ss * ss, gfc_expr * expr
content, so that we can update gfc_ss_info without caring about aliasing
problems.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_conv_loop_setup): Also skip temporary arrays.
diff --git a/trans-array.c b/trans-array.c
index f4d8a85..cfbe909 100644
--- a/trans-array.c
We should not be writing to gfc_ss_terminator.
It is working without this patch because gfc_ss_terminator's next pointer is
NULL, so the loop stops just after it, and because we are writing zero to
gfc_ss_terminator, but it is already all zeros anyway.
OK?
2011-10-19 Mikael Morin mik
This is another preliminary change, to update function interfaces requiring
it, so that afterwards structures can be changed internally without impacting
function interfaces.
The main reason for these changes is that gfc_ss_info's dim and dimen fields
are to be moved to struct gfc_ss. Thus
their gfc_ prefix along the way.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_array_bound_check,
trans_array_bound_check): Rename the former to the latter.
Replace descriptor argument with ss argument. Get descriptor from ss
This is a follow-up to the previous patch. It symplifies name obtention
so that later we can change structs with less pain. :-)
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_trans_array_bound_check): Use ss argument
to get name.
diff --git a/trans-array.c b
gfc_trans_create_temp_array uses dimensions heavily, and dimensions are to be
moved from gfc_ss_info to gfc_ss. To have them still available in
gfc_trans_create_temp_array, the gfc_ss_info argument should be a gfc_ss.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.h
Same as previous patch, gfc_set_vector_loop_bounds uses dimensions, and thus
needs a gfc_ss struct as argument.
gfc_ prefix removed along the way.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_set_vector_loop_bounds, set_vector_loop_bounds):
Rename
Same as previous patch, get_array_ref_dim uses dimensions and thus needs
a gfc_ss struct as argument.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (get_array_ref_dim): Change argument type and name.
Obtain previous argument from the new argument in the body
Same as previous patch, dim_ok uses dimensions and needs a gfc_ss struct as
argument.
The name is changed to the more descriptive transposed_dims and the logic
is inverted (dim_ok = !transposed_dims).
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (dim_ok
This renames gfc_ss_info to gfc_array_info.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss_info, struct gfc_array_info):
Rename the former to the latter.
* trans-array.c (gfc_get_array_ss, gfc_trans_allocate_array_storage
to GFC_SS_SECTION) made useless by the apperance of the very same initialization
earlier in gfc_get_temp_ss.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_array_info): Move dim and dimen fields...
(struct gfc_ss): ... here. Remove gfc_ss::data::temp::dimen field
This moves shape field from gfc_ss to gfc_array_info.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss, struct gfc_array_info): Move shape field
from the former struct to the latter.
* trans-array.c (gfc_conv_ss_startstride, gfc_conv_loop_setup
This moves type field from gfc_ss to a new gfc_ss_info struct.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss_info): New struct.
(gfc_get_ss_info): New macro.
(struct gfc_ss): Move type field to struct gfc_ss_info.
Add an info field
This moves string_length field from gfc_ss to gfc_ss_info.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss, struct gfc_ss_info): Move field
string_length from the former struct to the latter.
* trans-array.c
(gfc_get_temp_ss
This moves data::scalar field from gfc_ss to gfc_ss_info.
The expr subfield is renamed to value, as it is not the expression really,
it is a reference to a variable containing the pre-calculated value.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss, struct
This moves data::temp field from gfc_ss to gfc_ss_info.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss, struct gfc_ss_info): Move member struct
gfc_ss::data::temp into gfc_ss_info::data.
* trans-array.c (gfc_get_temp_ss, gfc_conv_loop_setup
This moves data::info field from gfc_ss to gfc_ss_info.
The name is changed to array, as it is for all the non-scalar and non-temp
cases, thus all the array cases.
OK?
2011-10-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (struct gfc_ss, struct gfc_ss_info): Move field
gfc_ss
1 - 100 of 951 matches
Mail list logo
