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
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 present with -O1.
Can it be caused by the frontend not going in the realloc-lhs
functions in
some cases? Especially, it seems
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
was
On 02/05/2012 21:22, Janne Blomqvist wrote:
PING #2
On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
PING!
On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
the attached patch implements a few fixes and cleanups for
started a regression test.
OK for trunk if it passes?
Mikael
2012-07-20 Mikael Morin mik...@gcc.gnu.org
PR fortran/44354
* resolve.c (sought_symbol): New variable.
(expr_is_sought_symbol_ref, find_symbol_in_expr): New functions.
(gfc_resolve_iterator): Check for references
On 20/07/2012 20:16, Mikael Morin wrote:
I have started a regression test.
OK for trunk if it passes?
Unfortunately, it fails with errors like:
/home/mik/gcc4x/src/gcc/testsuite/gfortran.dg/char_pack_1.f90:55.10:
do i = i + 1, nv
1
Warning: AC-IMPLIED-DO initial expression
On 20/07/2012 22:03, Mikael Morin wrote:
On 20/07/2012 20:16, Mikael Morin wrote:
I have started a regression test.
OK for trunk if it passes?
Unfortunately, it fails with errors like:
/home/mik/gcc4x/src/gcc/testsuite/gfortran.dg/char_pack_1.f90:55.10:
do i = i + 1, nv
1
On 20/07/2012 12:19, Tobias Burnus wrote:
Mikael: I wouldn't mind if you could have a look at the scalarizer - you
seem to have an idea how one can implement it with minimal effort/code
cluttering.
This is exaggerated. I just said that the scalarizer can't generate a
variable number of loops.
I
On 23/07/2012 07:58, Tobias Burnus wrote:
Mikael Morin wrote:
Here is another attempt.
I moved the diagnostic code from gfc_resolve_iterator to
resolve_array_list, so that it doesn't trigger for do loops.
Regression test in progress. OK?
The patch looks OK:
Though, I wonder why you only
On 25/07/2012 23:23, Tobias Burnus wrote:
Tobias Burnus wrote:
The following issue was found by Alessandro. (It got triggered by a
larger test case, which is required for a larger patch by Alessandro,
which is not yet finished.)
Accessing the lower[-1] is probably not the best idea …
Build
On 21/07/2012 13:08, Tobias Burnus wrote:
Only failing are:
lbound(x) / ubound(x) / shape(x)
Here is a draft for those.
Lightly tested with print *, ...
Mikael
Index: trans-array.c
===
--- trans-array.c (révision 189883)
+++
On 26/07/2012 16:53, Mikael Morin wrote:
On 21/07/2012 13:08, Tobias Burnus wrote:
Only failing are:
lbound(x) / ubound(x) / shape(x)
Here is a draft for those.
Lightly tested with print *, ...
Better with the tests.
$ ./test1
1 1
3 8
The offset field is never set; this patch removes it.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2012-07-27 Mikael Morin mik...@gcc.gnu.org
* array.c (gfc_copy_array_ref): Don't copy the offset field.
* expr.c (find_array_section): Ignore the offset field.
* trans
On 26/07/2012 17:32, Tobias Burnus wrote:
On 07/26/2012 05:12 PM, Mikael Morin wrote:
On 26/07/2012 16:53, Mikael Morin wrote:
Here is a draft for those. Lightly tested with print *, ...
Looks rather nice. The output for test1 is also good:
integer :: a(1:3,-2:5)
gives
lbound(arg
On 26/07/2012 16:01, Tobias Burnus wrote:
TS29113 allows also non interoperable procedures with
c_funloc/c_f_procpointer; hence, this patch allows them with -std=f2008ts:
The function C F PROCPOINTER from the intrinsic module ISO C BINDING
has the restriction in ISO/IEC 1539-1:2010 that CPTR
On 01/08/2012 12:00, Tobias Burnus wrote:
On 07/27/2012 07:26 PM, Mikael Morin wrote:
do you have a test case exhibiting the problem? It seems fine to me.
Your second test case was too convoluted for me - and as I wasn't at
home, I couldn't test it. I now believe that your patch is okay; I
the shape was incorrectly set to -1 at resolution time for those intrinsics.
This patch disables it.
Also disabled is the attempt to simplify shape in the assumed rank case.
{l,u}bound didn't need this; it was already done.
2012-08-02 Mikael Morin mik...@gcc.gnu.org
* iresolve.c
Hello,
here is the fix for the regression I have introduced with my assumed
rank bounds patch.
Will test and commit as obvious.
Mikael
2012-08-02 Mikael Morin mik...@gcc.gnu.org
PR fortran/54166
* trans-array.c (set_loop_bounds): Access specinfo using spec_dim.
2012-08-02
On 09/08/2012 11:12, Tobias Burnus wrote:
This patch makes the warning for internal procedures whose name is the
same as the one of an intrinsic clearer. Initially, I though that one
shouldn't warn for internal procedures, but others disagree. In any
case, the warning text is better than
On 08/08/2012 19:12, Tobias Burnus wrote:
With this patch, I think the only unimplemented obsolescence warning is for
(8) Fixed form source -- see B.2.7.
For the latter, I would like to see a possibility to silence that
warning, given that there is substantial code around, which is in fixed
On 12/08/2012 10:56, Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the trunk?
OK.
2012-08-11 Tobias Burnus bur...@net-b.de
PR fortran/54221
* vect/vect-gems.f90: Don't mark module vars as PRIVATE as
they appear (ninitialized on the RHS.
by a call to (the new function)
gfc_get_proc_ptr_comp.
This is optional: I can adjust the patch depending on it (patch 4) to do
it the old way if it's preferred.
OK?
2012-08-13 Mikael Morin mik...@gcc.gnu.org
* gfortran.h (gfc_get_proc_ptr_comp): New prototype.
(gfc_is_proc_ptr_comp): Update
Hello Paul,
I think there are a couple of bugs not triggered by the single component
types in the test. See below.
On 13/08/2012 15:37, Paul Richard Thomas wrote:
+
+ /* Go through the code chain eliminating all but calls to
+ typebound procedures. Since we have been through
+
On 14/08/2012 07:03, Paul Richard Thomas wrote:
However, if we do it before, we also overwrite components to be assigned
with a typebound call, and this can have some side effects as the LHS's
argument can be INTENT(INOUT).
This might be so but it is what the standard dictates should
On 14/08/2012 07:03, Paul Richard Thomas wrote:
... but I have the feeling that this makes (*code) unreachable and that
that's wrong. Shouldn't it be root-next = *code; ?
No. That caused the regression that I mentioned. (*code) is
resolved, at entry. resolve_code steps on to (*code)-next.
On 14/08/2012 11:33, Tobias Burnus wrote:
Thus, I removed ST_LABEL_ENDDO_TARGET, use =type and added a comment,
but I didn't do the verify_st_order change.
Build and regested on x86-64-linux.
OK for the trunk?
OK, apart for:
* gfortran.dg/data_constraints_1.f90: Update dg-warning.
On 14/08/2012 11:33, Tobias Burnus wrote:
This patch adds a -Wconversion warning (enabled also by -Wall) for
CMPLX(real, real)
if the real arguments have a higher kind number/precision as the
default-kind of complex/real. I think most of the time, this precision
loss is unintended; it can
On 17/08/2012 23:32, Tobias Schlüter wrote:
Following up on myself:
On 2012-08-16 14:59, Tobias Schlüter wrote:
A place where C++ inheritance is a trivial improvement is the red-black
tree used for storing various objects (gfc_symtree, gfc_gsymbol,
gfc_st_label, I think). This is
===
--- ChangeLog (révision 190503)
+++ ChangeLog (révision 190504)
@@ -1,3 +1,8 @@
+2012-08-18 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/39290
+ * gfortran.dg/interface_37.f90: New test.
+
2012-08-17 H.J. Lu hongjiu...@intel.com
Gary Funck g
)
+++ ChangeLog (révision 190513)
@@ -1,3 +1,7 @@
+2012-08-19 Mikael Morin mik...@gcc.gnu.org
+
+ * Make-lang.in: Fix typo.
+
2012-08-17 Jakub Jelinek ja...@redhat.com
* cp-tree.def (SIZEOF_EXPR): Move to c-common.def.
On 18/08/2012 19:25, Tobias Schlüter wrote:
I thought I could work around this problem without introducing a
constructor by:
1) using 0 instead of -1 as value for this fake label (which is also
not a valid value for a label, so it can't collide
2) setting ST_LABEL_FORMAT = 0
and then
3)
Hello,
On 22/08/2012 07:56, Tobias Burnus wrote:
Committed as Rev. 190586 after successful regtesting.
That's the version I also had attached to
http://gcc.gnu.org/ml/fortran/2012-08/msg00118.html; as written there:
I have one minor comment about it. See below.
The patch is incomplete,
On 22/08/2012 19:19, Tobias Burnus wrote:
Dear all,
first, a question to Mikael (and others knowing the scalarizer): How to
properly fix the following:
implicit none
REAL qss(3)
REAL, ALLOCATABLE :: qj(:,:)
INTEGER :: qcount
qss(:)=qj(:,qcount)
end
For that one calls
On 23/08/2012 22:13, Tobias Burnus wrote:
Tobias Burnus wrote:
I am now down to a single kind of failure: pointer_remapping_*.f08
fails. One has code like:
ptr(1:5, 1:2) = arr
The question is how to solve that one. If one removes the AR_FULL and
sets lse.descriptor_only, the test cases
array constructors.
[5/5]: Use the target information to assign a scalar structure to an array.
More details in the follow-up mails.
Regression tested on amd64-linux. OK for trunk?
Mikael
2012-08-18 Mikael Morin mik...@gcc.gnu.org
PR fortran/45586
* gfortran.dg
arrays, I couldn't avoid VIEW_CONVERT_EXPR in
all cases, so I finally preferred this (simpler) patch.
OK?
2012-08-22 Mikael Morin mik...@gcc.gnu.org
PR fortran/45586
* trans-expr.c (gfc_trans_scalar_assign): Wrap in a VIEW_CONVERT_EXPR
node if the types don't match
This patch comes from Richi. Self explanatory.
OK?
2012-08-22 Richard Guenther rguent...@suse.de
PR fortran/45586
* trans-expr.c (gfc_nonrestricted_type): Make the non-restrict type
distinct from the original type.
diff --git a/trans-types.c b/trans-types.c
index
around
the function with the restricted argument.
I didn't do the same for gfc_conv_array_initializer as it has a single caller,
so the interface change is harmless/non-invasive. As I had to update the
declaration I moved it from gfortran.h to trans-array.h by the way.
OK?
2012-08-22 Mikael Morin
\ \
+---+- gfc_trans_array_ctor_element
\
+- gfc_conv_expr [propagate restricted]
gfc_trans_array_ctor_element is changed to use gfc_trans_scalar_assign, which
is able to handle incompatible types thanks to patch number 1.
OK?
2012-08-22 Mikael Morin mik
the infrastructure has been installed
previously, this simply sets it up properly.
OK?
2012-08-22 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_add_loop_ss_code): Use RESTRICTED field.
* trans-expr.c (gfc_trans_assignment): Set RESTRICTED field.
diff --git a/trans-array.c b/trans-array.c
On 19/08/2012 19:50, Tobias Burnus wrote:
Dear all,
attached is a slightly updated patch:
* Call finalizers of nonallocatable, nonpointer components
* Generate FINAL wrapper for abstract types which have a finalizer. (The
allocatable components are deallocated in the first type (abstract
On 25/08/2012 17:21, Tobias Burnus wrote:
(And nonallocatble, nonpointer
components do not exist.)
I missed that indeed.
What if only comp's subcomponents are finalizable, the finalization
wrapper should still be called, shouldn't it?
Well, that's handled in the else branch. There, I walk
On 25/08/2012 20:00, Dominique Dhumieres wrote:
Dear Mikael,
Your set of patches works as defined, i.e., it fixes pr45586 without
regression on the test suite. However, If the test suite is run with
-flto, there are still some failures depending on the way gcc is
configured.
Thanks for
201 - 300 of 975 matches
Mail list logo
