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
gets
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
regression test in
progress. OK?
Mikael
2012-09-16 Mikael Morin mik...@gcc.gnu.org
* symbol.c (gfc_undo_symbols): Correctly undo namelists.
2012-09-16 Mikael Morin mik...@gcc.gnu.org
* gfortran.dg/namelist_75.f90: New test.
Index: symbol.c
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
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 implies
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 PR
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 mik...@gcc.gnu.org
PR fortran/54208
* simplify.c (simplify_bound_dim): Resolve array spec before
proceeding with simplification.
2012-09-07
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 been
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 does
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
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 for its
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 about refs,
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 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 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
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. One has:
if
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 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
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
)
+++ 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)
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
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
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 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.
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
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
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
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
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
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 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
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 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
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 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 descriptors
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-18
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
fsym-attr.flavor != FL_PROCEDURE)
|| (fsym-attr.proc_pointer
Now about:
Mikael Morin wrote:
What about naming the flag in_actual_arg and moving the
inquiry_argument condition to the error condition?
That doesn't work as it is not only valid as inquiry
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/testsuite/gfortran.dg
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 keep the
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 problem is that
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 are
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. (Coarray
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 same.
A
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 it is slightly cleaner
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 plain
On 14/07/2012 15:45, Steven Bosscher wrote:
On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus bur...@net-b.de wrote:
Steven Bosscher wrote:
On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus bur...@net-b.de wrote:
On 07/07/2012 11:28 PM, Steven Bosscher wrote:
I must say, I am surprised that
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:
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 I
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
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
initializing the
temporary.
Regression tested on x86_64-unknown-freebsd9.0.
OK for trunk/4.7?
Mikael
2012-07-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/53732
* trans-array.c (gfc_add_loop_ss_code): Disable self recursive calls
handling nested loop(s
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
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
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 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 bootstraptest this, but trunk appears to be broken for
x86_64-linux right now (ICE in patch_jump_insn). But I can post this
for
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.
Hello,
On Monday 13 February 2012 23:38:57 Paul Richard Thomas wrote:
Mikael,
This is OK for trunk with one proviso; could you move
is_class_container_ref to gfc_is_class_container_ref in class.c?
Thanks for the patch
I have a small hardware issue (overheating) preventing me from
On Tuesday 21 February 2012 16:55:09 Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the 4.8 trunk?
OK.
Mikael
PS: I think that, in general, we should _accept_ statements on MATCH_ERROR to
avoid issues of this kind.
On Saturday 18 February 2012 14:33:09 Tobias Burnus wrote:
The patch consists of two parts:
* The pointer check in gfc_check_vardef_context didn't honour
polymorphic variables
* Passing a TYPE to a CLASS is not allowed if CLASS is a pointer or
allocatable as the actual argument cannot
Hello,
On Tuesday 14 February 2012 12:42:21 Tobias Burnus wrote:
Fortunately, -O0 is often sufficient to remove the reallocation code.
I guess you mean -O1 here...
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
in gfc_conv_procedure_call. We
need to make sure to save the value of se-ss, as gfc_conv_tmp_array_ref
or gfc_conv_expr_reference will advance it to the next in the chain.
Otherwise nothing special.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-12 Mikael Morin mik...@gcc.gnu.org
function to check the type without impacting the testsuite.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-12 Mikael Morin mik...@gcc.gnu.org
* trans-expr.c (is_class_container_ref): New function.
(gfc_conv_procedure_call): Add a _data component
on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-07 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_get_proc_ifc_for_expr): New function.
(gfc_walk_elemental_function_args): Move code to
gfc_get_proc_ifc_for_expr and call it.
diff --git a/trans-array.c
for trunk?
Mikael
2012-02-02 Mikael Morin mik...@gcc.gnu.org
PR fortran/41587
PR fortran/46356
PR fortran/51754
PR fortran/50981
* class.c (insert_component_ref, class_data_ref_missing,
gfc_fix_class_refs): New functions.
* gfortran.h
On 31.01.2012 23:22, Tobias Burnus wrote:
Dear all,
I have no idea about the scalarizer, but the attached patch fixes the
test case and somehow adding an array ref to a scalar looks odd to me ...
??
The condition is about an array without array ref, isn't it?
We can't access the array part of
On 31.01.2012 23:41, Tobias Burnus wrote:
Tobias Burnus wrote:
Unfortunately, it turns out that the check does not handle inheritance
well. At least I would expect that the attached test case is valid
(and it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7.
Actually, I
On 18.01.2012 10:12, Tobias Burnus wrote:
Dear Janne,
the attached patch changes the binding labels that are needed for
bind(C) symbols to be heap allocated rather than, as currently, being
fixed size arrays of size 127 (or 64 in module.c!?).
wonder whether it would have been smarter to
the struct in the first place, as it is unused.
I'm currently regtesting the following patch. The testcase is the same
as your. OK for 4.7/4.6?
2012-01-09 Mikael Morin mik...@gcc.gnu.org
* trans-array.c (gfc_walk_elemental_function_args):
Skip over NULL() actual arguments
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 it is slightly cleaner
On Monday 02 January 2012 12:20:36 Tobias Burnus wrote:
Hello Mikael,
Mikael Morin wrote:
Regression tested on x86_64-unknown-linux-gnu. OK for 4.7/4.6/4.5[/4.4] ?
OK - thanks for the comprehensive patch explanation and for the patch
itself.
+ else
On 31/12/2011 18:03, Tobias Burnus wrote:
OK for the trunk?
OK
Thanks
Mikael
for 4.7/4.6/4.5[/4.4] ?
Mikael.
PS: Greetings for the new year.
2011-12-29 Mikael Morin mik...@gcc.gnu.org
* trans-expr.c (gfc_conv_expr): Move address taking...
(gfc_conv_expr_reference): ... here.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index
On Wednesday 07 December 2011 17:45:52 Tobias Burnus wrote:
This fixes a -frealloc-lhs regression where the RHS is handled by a
conversion function whose argument has component refs.
Build and regtested on x86-64-linux.
OK for the trunk and 4.7?
Tobias
OK.
Mikael
On Wednesday 07 December 2011 14:54:36 Tobias Burnus wrote:
* ping * ?
On 12/04/2011 06:46 PM, Tobias Burnus wrote:
Hi all,
as Dominique has found, Fortran 2008 allows the BOZ edit descriptors
now also with REAL and COMPLEX arguments. (See PR for quotes from the
standard.)
On Friday 02 December 2011 22:01:19 Tobias Burnus wrote:
Found via Reinhold Bader's test suite: If a component is public, it
remains public even if the extended type has PRIVATE.
Build and regtested on x86-64-linux.
OK for the trunk?
OK.
Mikael
On Wednesday 07 December 2011 14:53:20 Tobias Burnus wrote:
** PING **
On 11/29/2011 07:35 PM, Tobias Burnus wrote:
gfortran had an ICE when trying to insert a check whether the
character length between actual and dummy argument matches. This check
is pointless for deferred-length
801 - 900 of 1084 matches
Mail list logo
