This uses the just added parent loop pointer to create an outermost_loop
function and use it throughout the scalarizer.
OK?
2011-10-19 Mikael Morin
* trans-array.c (outermost_loop): New function.
(gfc_trans_array_constructor, gfc_set_vector_loop_bounds
nt loop's gfc_loopinfo
struct is the current's parent field, same for the gfc_ss struct, and the
loop index is 0.
OK?
2011-10-19 Mikael Morin
* trans-array.c (gfc_trans_preloop_setup): Create pointers to outer
dimension's ss and loop. Use them.
diff --g
This is a collection of changes not directly related, but made necessary by
the emergence of regressions in the testsuite without them.
Combined patch not attached, as the separate patches being largely independant,
it is the concatenation of them.
Patch 54: Enable dependency checking for inli
This adds dependency checking for inline functions.
OK?
2011-10-19 Mikael Morin
* trans.h (gfc_inline_intrinsic_function_p): Move prototype...
* gfortran.h (gfc_inline_intrinsic_function_p): ... here.
* dependency.c (gfc_check_argument_var_dependency): Check
27; delta after
calling gfc_trans_create_temp_array.
Patch 55 is a preliminary patch making some functions public.
OK?
2011-10-19 Mikael Morin
* trans-array.h (gfc_free_ss, gfc_set_delta): New prototypes.
* trans-array.c (gfc_free_ss): Remove forward declaration.
Patches 58 and 59 fix the {min,max}loc and {min,max}val intrinsics which use
multiple loops. See the comments in the patches for details.
Patch 57 avoids duplicated offset calculation in the code generated.
OK?
2011-10-19 Mikael Morin
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc
between array generated
for the argument, for the function result, etc.
OK?
2011-10-19 Mikael Morin
* array.c (match_subscript): Skip whitespaces before setting locus.
* matchexp.c (match_level_1): Ditto.
diff --git a/array.c b/array.c
index 3e6b9d2..a1449fd 100644
--- a/array
Not exactly a regression, but frontend optimizations can make things worse
by forcing temporary generation.
This disables common function elimination and binary operator optimization
for inline intrinsics.
I hope I didn't miss anything else.
OK?
2011-10-19 Mikael Morin
* fro
This is the purpose of all the serie of patches: inline sum and product.
Patches 62..65, possibly don't deserve a patch of their own, they just make
the changes in gfc_conv_intrinsic_arith easier to read.
The combined diff (context, ignoring indent changes) also attached here.
Patch 62: Change co
This makes the convention that all conditions are based on arguments presence
and their rank. In the hope that it makes code easier to read.
OK?
2011-10-19 Mikael Morin
* trans-intrinsic.c (gfc_conv_intrinsic_arith): Update conditions.
diff --git a/trans-intrinsic.c b/trans
This uses named argument to make it easier to follow.
OK?
2011-10-19 Mikael Morin
* trans-intrinsic.c (gfc_conv_intrinsic_arith): Small argument handling
cleanup.
diff --git a/trans-intrinsic.c b/trans-intrinsic.c
index 342d2cb..b701502 100644
--- a/trans-intrinsic.c
+++ b
that case.
This patch changes local loop uses with a pointer loop use (which is
initialized to the local loop for now).
OK?
2011-10-19 Mikael Morin
* trans-intrinsic.c (gfc_conv_intrinsic.c): Introduce current loop
pointer. Use it.
diff --git a/trans-intrinsic.c b/trans-intrins
In the non-scalar case the gfc_se structs are initialized using the se pointer
given as argument to the function. To accomodate this, this patch changes
initialization to NULL with initialization to a pointer (initially set to
NULL for now).
The patch explains it better.
OK?
2011-10-19 Mikael
ether the mask is array or scalar. So we have to make sure
that it is at the right position in the chain generated by
walk_inline_intrinsic_arith. See the comment there.
OK?
2011-10-19 Mikael Morin
PR fortran/43829
* trans-array.c (gfc_conv_expr_descriptor): Accept the inline
On Friday 28 October 2011 15:56:36 Jack Howarth wrote:
> Mikael,
> The complete patch bootstraps current FSF gcc trunk on
> x86_64-apple-darwin11 and the resulting gfortran compiler can compile the
> Polyhedron 2005 benchmarks using...
>
> Compile Command : gfortran-fsf-4.7 -O3 -ffast-math -fu
On Tuesday 18 October 2011 16:42:45 Janne Blomqvist wrote:
> Hi,
>
> in a few places in libgfortran we have some code for handling special
> and/or non-seekable files differently. The problem is that special
> files don't all have some nice consistent behavior. E.g. wrt. seeking,
> some allow seek
On Tuesday 18 October 2011 16:51:15 Janne Blomqvist wrote:
> Hi,
>
> the attached patch introduces a new "member function" ssize in order
> to determine the size of a unit. The benefit is that with unbuffered
> IO, when getting the size of a file we can replace 3 lseek() calls
> with one fstat() c
On Tuesday 18 October 2011 17:11:24 Janne Blomqvist wrote:
> Also, I think I've found a small standards conformance bug. From F2008
> (N1830) 9.10.2.23 (page 256): "... ASIS if the connection was opened
> without changing its position." and "If the file has been repositioned
> since the connection,
On Saturday 29 October 2011 10:09:07 Janne Blomqvist wrote:
> On Sat, Oct 29, 2011 at 01:48, Mikael Morin wrote:
> > On Tuesday 18 October 2011 17:11:24 Janne Blomqvist wrote:
> >> Also, I think I've found a small standards conformance bug. From F2008
> >> (N1830)
On Saturday 29 October 2011 14:43:22 Mikael Morin wrote:
> > FWIW, it seems ifort 12.0 uses "UNDEFINED" in this case; I suppose a
> > case could be made for using the same. Comments?
>
> Let's go for UNDEFINED then.
On second thought, UNSPECIFIED is better as UNDEFINED is for another case.
On Sunday 30 October 2011 09:16:09 Paul Richard Thomas wrote:
> Dear Mikael,
>
> I intend to work my way through your patches, starting this evening.
> I'll give you feedback as I go along and will OK the whole package,
> rather than bits. Is that alright with you?
Sure.
Mikael
On Tuesday 25 October 2011 07:39:44 Thomas Koenig wrote:
> Ping ** 0.571428
>
Let's keep Jakub CC-ed for mixes of OpenMP and frontend optimizations. ;-)
There are two commented lines in the testcase. Is it expected?
Otherwise doesn't look too bad...
Mikael
> > Jakub Jelinek wrote:
> >> Though,
On Tuesday 01 November 2011 22:07:48 Paul Richard Thomas wrote:
> The only, slight worry that I have is that it is going to make Richi's
> middle end scalarization nearly impossible to use for gfortran.
> However, the enhanced capability that this patch brings makes it a
> worthy addition to gfortr
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 or
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
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
>
> 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
* gfortran.h (gfc_get_proc_ptr_comp): New prototype.
(gfc_is_proc_ptr_comp): Update prototype.
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 (*co
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-w
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 c
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 i
end
Index: ChangeLog
===
--- ChangeLog (révision 190503)
+++ ChangeLog (révision 190504)
@@ -1,3 +1,8 @@
+2012-08-18 Mikael Morin
+
+ PR fortran/39290
+ * gfortran.dg/interface_37.f90: New test.
+
2012-08-17 H.J. Lu
Gary Funck
)
+++ ChangeLog (révision 190513)
@@ -1,3 +1,7 @@
+2012-08-19 Mikael Morin
+
+ * Make-lang.in: Fix typo.
+
2012-08-17 Jakub Jelinek
* 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
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 incomple
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
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, t
ssign from 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
PR fortran/45586
* gfortran.dg/restrict_type_compat_
to assign arrays, I couldn't avoid VIEW_CONVERT_EXPR in
all cases, so I finally preferred this (simpler) patch.
OK?
2012-08-22 Mikael Morin
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
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 a6e5d99..189f597 100644
ializer callers it is made a wrapper 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
y_constructor_subarray
\ \
+---+-> 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.
infrastructure has been installed
previously, this simply sets it up properly.
OK?
2012-08-22 Mikael Morin
* 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
index f5051ff
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 (ab
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
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
On 25/08/2012 22:06, Tobias Burnus wrote:
If comp has finalizable subcomponents, it has a finalization
wrapper, which is (or should be) caught above, so this branch
is (or should be) unreachable.
>>> I probably miss something, but I don't see why this branch should
>>> be unreachable
On 26/08/2012 13:23, Dominique Dhumieres wrote:
> With the modified patch, gfortran.dg/restrict_type_compat_1.f90 fails
> for a regular test:
>
> FAIL: gfortran.dg/restrict_type_compat_1.f90 -O scan-tree-dump-times
> original "VIEW_CONVERT_EXPR" 13
>
> A manual check shows only 6 instances of
On 27/08/2012 14:14, Tobias Burnus wrote:
> On 08/26/2012 08:12 PM, Tobias Burnus wrote:
>> This patch fixes one ICE and several memory leaks. But there are more.
>>
>
> I have now committed the patch with the following additional patch
> * module.c (mio_symbol): Don't increase sym->refs f
On 27/08/2012 17:11, Tobias Burnus wrote:
>> could you add comments
>> in gfortran.h telling which pointers account for reference counting?
>> As far as I remember for symbols, there are:
>>gfc_symtree::n::sym;
>>gfc_namespace::proc_name;
>
> Well, I have still not gained a full overview a
On 27/08/2012 20:20, Rouson, Damian wrote:
> Hi Mikael,
>
> Is this patch approved?
There are a few overlooks to be fixed and the components walking code
that I would like to see shared.
Then I think it can go in. But there is no big stopper.
Mikael
On 28/08/2012 10:51, Tobias Burnus wrote:
> DECL_PURE_P was also set for elemental procedures, which is wrong if
> they are IMPURE.
>
> Additionally, we do the same checks for PURE also for
> attr.implicit_pure. I think the checks are strict enough that we can
> dare to set DECL_PURE_P also for gf
On 29/08/2012 21:53, Tobias Burnus wrote:
> Dear all,
>
> that's the revised version of patch at
> http://gcc.gnu.org/ml/fortran/2012-08/msg00095.html, taking the review
> comments into account.
>
> Reminder: This patch only generates the finalization wrapper, which is
> in the virtual table. It
On 04/09/2012 00:19, Dominique Dhumieres wrote:
> Hi Tobias,
>
> The lines 6 and 12 of gfortran.dg/coarray_poly_3.f90 need some adjustment
> along the line:
For what's worth, the testsuite change was part of patch (b) at
http://gcc.gnu.org/ml/fortran/2012-08/msg00201.html
while it should have bee
This patch adds the call in simplify_bound_dim instead.
Regression tested on x86_64-unknown-linux-gnu. OK for 4.8/4.7/4.6?
Mikael
2012-09-07 Mikael Morin
PR fortran/54208
* simplify.c (simplify_bound_dim): Resolve array spec before
proceeding with simplification.
2012-09-07 Mikael Mo
On 11/09/2012 07:54, Tobias Burnus wrote:
> This patch fixes a GCC 4.7/4.8 regression for invalid code.
>
> Build and regtested on x86-64-linux.
> OK for the trunk and 4.7?
>
Yes.
PR 53306 is also fixed by your patch according to Dominique, so don't
forget to include its testcase and to add the
On 13/09/2012 14:35, Tobias Burnus wrote:
> gfortran wrongly marks some procedures as implicit_pure which aren't
> pure. implicit_pure exists since 2011-01-08 (= GCC 4.6), but was only
> used internally (FE optimization and trans*.c to avoid temporaries).
> Since 2012-08-28, implicit_pure also impl
Argh! Paul OKed the patch already.
Here are my comments anyway.
On 15/09/2012 11:46, Tobias Burnus wrote:
> Dear all,
>
> this patch fixes some of the warning showing up for gcc/fortran at
> http://scan.coverity.com/. Coverity sells static C/C++/C#/Java code
> analyzers and offer scanning to open
sis. Will you create a patch?
>
Attached. Tested against "*namelist*" and full regression test in
progress. OK?
Mikael
2012-09-16 Mikael Morin
* symbol.c (gfc_undo_symbols): Correctly undo namelists.
2012-09-16 Mika
On 17/09/2012 09:47, Tobias Burnus wrote:
> This patch fixes some of the issues collected in the PR.
>
>
> Some remarks to the changed in the attached patch:
>
>
> - gcc_assert (*format++ == '$');
>
> That code gets executed when
> "some error message with value %d for string %s"
> ge
Hello,
On 10/09/2012 20:58, Paul Richard Thomas wrote:
> Dear All,
>
> Please find attached a new attempt at the patch for PR46897. It now
> uses temporaries to overcome the side effects that Mikael pointed out.
And here comes the next round of comments.
> Index: gcc/fortran/resolve.c
> =
On 17/09/2012 20:45, Mikael Morin wrote:
>> *** resolve_fl_derived0 (gfc_symbol *sym)
>> *** 12282,12289
>> --- 12558,12574
>> || c->attr.proc_pointer
>> ||
On 19/09/2012 20:46, Paul Richard Thomas wrote:
>>> + || comp1->attr.proc_pointer_comp
>> That one doesn't look right.
>
> Why not?
It skips any component containing a procedure pointer subcomponent.
Actually, from looking at parse.c where the flag is set, it seems that
the flag is only set fo
tedly in a new loop initializing the
temporary.
Regression tested on x86_64-unknown-freebsd9.0.
OK for trunk/4.7?
Mikael
2012-07-15 Mikael Morin
PR fortran/53732
* trans-array.c (gfc_add_loop_ss_code): Disable self recursive calls
handling nested loop(s) if the subscrip
On 02.07.2012 09:10, Tobias Burnus wrote:
For some reasons, result variables are walked twice. With
-finit-local-zero their value gets set to 0, either via an inserted
assignment or by adding a initialization (sym->value).
With -fno-automatic sym->value is also set for result variables, which
la
On 24.06.2012 17:34, Tobias Burnus wrote:
Tobias Burnus wrote:
To cleanup my local trees; I had the patch lingering there for a many
weeks. User visible, it only adds parsing support for "dimension(..)"
and a sorry message.
I have now updated the patch. Changes:
Hello,
some commen^Wbike sh
On 26.06.2012 19:12, Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
OK once the preliminary patch gets approved.
Mikael
On 05.07.2012 12:32, Dominique Dhumieres wrote:
Mikael,
After the previous fix, the test fails with
real*8 arr(4, 4, 4, 4)
1
Warning: Nonstandard type declaration REAL*8 at (1)
Replacing
real*8 arr(4, 4, 4, 4)
with
real(8) :: arr(4, 4, 4, 4)
fixes the failures (due to the compilatio
On 28/06/2012 09:34, Tobias Burnus wrote:
> This patch generates inline code for C_F_POINTER with an array argument.
> One reason is that GCC didn't handle SHAPE= arguments which were
> noncontiguous.
>
> However, the real motivation is the fortran-dev branch with the new
> array-descriptor: C_F_P
On 06/07/2012 23:13, Tobias Burnus wrote:
>> In case it's not, then everything is fine I guess, though I prefer
>> avoiding polluting the scalarizer with assumed rank stuff ;-).
>
> It still will get worse, see above. Though, I wouldn't mind if you could
> modify the scalarizer.
I don't see how
On 09/01/2012 15:45, Tobias Burnus wrote:
> On 01/09/2012 03:34 PM, Mikael Morin wrote:
>> The issue is that the code handling NULL() doesn't consume the gfc_ss
>> struct created for it. Your fix, which advances to the next one anyway
>> would work just well, but I think
Hello,
I somehow was reading this in the standard:
"An assumed-rank variable name shall not appear in a designator or
expression except as an actual
argument corresponding to a dummy argument that is assumed-rank..."
with "...except in..." instead of "...except as...".
Some of my comments were p
On 14/07/2012 15:45, Steven Bosscher wrote:
> On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus wrote:
>> Steven Bosscher wrote:
>>>
>>> On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus wrote:
On 07/07/2012 11:28 PM, Steven Bosscher wrote:
>
> I must say, I am surprised that gfortra
On 15/07/2012 13:24, Tobias Burnus wrote:
> This patch cleans up the source code and generated code ("dump") by
> changing (ubound-lbound+1) calculations to directly taking the "extent".
> Except for a faster -O0 performance and saving some cycles during code
> generation, the code should be the sa
Hello,
On 17/07/2012 16:44, Janus Weil wrote:
> Hi,
>
>> Ditto here. Though, I think you are in danger of exceeding the buffer - if
>> not here, then further down.
>
> admitted - the buffer length could clearly be a problem (in connection
> with translation).
>
>
>> Wouldn't it be simplyer to
On 17/07/2012 20:52, Tobias Burnus wrote:
> gfortran properly handles the "#line" which come from #include
> statements and look as
>
> # 1234 "include_file_name.f90" 1
>
> Here, the syntax is "# linenumber filename flags", where flags is a
> space-delimited list of the flags 1,2,3, or 4. The pro
On 17/07/2012 10:13, Tobias Burnus wrote:
> gfortran always warned for BIND(C) procedures if one used "integer",
> "integer(4)" etc. instead of "integer(c_int)". While the latter is
> surely more portable than the former, all of them are identical on
> nearly all systems. Hence, the other versions
On 17/07/2012 12:03, Tobias Burnus wrote:
> On 07/17/2012 11:42 AM, Janus Weil wrote:
>> +case GFC_STD_F2008_TS:
>> + strcat (buffer, " TS 29113:");
>> + break;
>
> That's currently correct. However, there is another post-Fortran 2008
> Technical Specification in preparation. (Coarra
ymbol * sym,
> gfc_add_expr_to_block (&se->pre, tmp);
> }
>
> - if (fsym && e->expr_type != EXPR_NULL
> + /* Wrap scalar variable in a descriptor. We need to convert
> + the address of a po
On 19/07/2012 17:55, Mikael Morin wrote:
> I'm regression testing them, and if they work and are fine to you, let's
> go with these patches.
>
They work with the following testsuite adjustment.
Mikael
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_3.f90 b/gcc/te
On 15/07/2012 08:23, Tobias Burnus wrote:
> Dear all,
>
> that's a follow up cleanup to the patch, which has just been merged.
> Most parts should be really obvious and nice, however, the offset part
> isn't. As the offset is not part of the descriptor defined at DTS
> 29113:2012's "8.2 C descript
On 18/07/2012 17:17, Tobias Burnus wrote:
> This patch was written on top of the big assumed-shape patch.* However,
> it should also work by itself.
>
> Bootstrapped and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>
> * http://gcc.gnu.org/ml/fortran/2012-07/msg00052.html
> 2012-07
On 20/07/2012 12:09, Tobias Burnus wrote:
> But if you prefer, I can now also lump all Bind(C) changes of TS29113
> together into a big patch.
>
No thanks. Patch is OK.
Mikael
I have started a regression test.
OK for trunk if it passes?
Mikael
2012-07-20 Mikael Morin
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 to the induction
var
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 e
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
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.
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
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 id
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
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
* array.c (gfc_copy_array_ref): Don't copy the offset field.
* expr.c (find_array_section): Ignore the offset field.
* trans-e
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:
>
>
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
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 no
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
* iresolve.c (resolve_
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
PR fortran/54166
* trans-array.c (set_loop_bounds): Access specinfo using spec_dim.
2012-08-02 Mikael Morin
On 02/05/2012 21:22, Janne Blomqvist wrote:
> PING #2
>
> On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
> wrote:
>> PING!
>>
>> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
>> wrote:
>>> Hi,
>>>
>>> the attached patch implements a few fixes and cleanups for the MOD and
>>> MODULO intrinsic
701 - 800 of 1075 matches
Mail list logo
