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
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.
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
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 31/12/2011 18:03, Tobias Burnus wrote:
OK for the trunk?
OK
Thanks
Mikael
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
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 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
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
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
Le 26/08/2013 16:16, Janus Weil a écrit :
I'm slightly inclined to kindly invite the user to switch to
STORAGE_SIZE+SIZE instead. Any other opinion?
Since the SIZEOF intrinsic has been around for some time in gfortran
(before STORAGE_SIZE was available), I would say we should at least
Le 07/10/2013 23:31, Tobias Burnus a écrit :
The patch is rather obvious. The question is just why was the check
there at the first place.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK. Thanks.
Mikael
On Tuesday 21 June 2011 17:08:17 Richard Guenther wrote:
The following is a patch^Whack that should handle almost all
array exprs. Well, tried on the following testcase:
subroutine foo (dst, bar, ni, nj)
integer, intent(in) :: ni, nj
double precision, intent(in) :: bar(ni, nj)
Le 11/10/2012 23:49, Janus Weil a écrit :
Hi all,
here is an OOP patch for the above PR, which has two disconnected parts:
1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
function as argument (i.e. the ICE in the bug title). This is the
trans-intrinsic part of the patch.
Le 26/11/2012 12:21, Janus Weil a écrit :
2012/11/25 Mikael Morinmikael.mo...@sfr.fr:
Le 22/10/2012 16:49, Janus Weil a écrit :
Minor update to the patch: It now also sets TREE_USED for entry
masters in order to avoid bogus warnings for procedures with ENTRY
(cf. comment 6 in the PR, which
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
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
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
On 17/09/2012 20:45, Mikael Morin wrote:
*** resolve_fl_derived0 (gfc_symbol *sym)
*** 12282,12289
--- 12558,12574
|| c-attr.proc_pointer
|| c-attr.allocatable)) == FAILURE)
return
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 for
Le 03/10/2012 18:48, Janus Weil a écrit :
Hi all,
here is a small patch for a wrong-code regression with polymorphic
allocation. The problem is that we falsely detect the allocation
variable to be a polymorphic array (although it is a scalar). For
further details see the PR, in particular
Hello,
Le 23/04/2013 09:58, Tobias Burnus a écrit :
The constraint checks for assumed-type and assumed-rank with regards to
intrinsics only worked very indirectly and, hence, was not strict
enough. That's now fixed with the attached patch - also for
NO_ARG_CHECK. For the latter, it also
Le 21/05/2013 20:05, Tobias Burnus a écrit :
That's a follow-up the just committed patch - which came too late in
some cases.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK, thanks
Mikael
Le 31/05/2013 14:28, Janus Weil a écrit :
Wouldn't it work to use the TIOCGWINSZ ioctl only if isatty() reports
that we're outputting to a terminal?
Good point. Updated patch attached, which imposes no limit if we're
not outputting to a terminal (as suggested by Mikael).
Ok for trunk, or
On 01.06.2013 14:51, Tobias Burnus wrote:
I am still not happy with changing the length of the displayed
source-code in error messages to infinity if not terminal is available.
One reason is that for long lines (e.g. generated code or long trailing
comment lines) - the output is not very
Le 01/06/2013 10:42, Janus Weil a écrit :
Ok. Unfortunately I'm not much of a autoconf hero (better to say: not
at all).
Any person using autoconf is some of a hero. ;-)
I can not test it on my system with --enable-maintainer-mode
because I get:
configure.ac:2: error: Please use exactly
Le 03/06/2013 12:22, Tobias Burnus a écrit :
* PING *
Attached is just a re-diff.
OK for the trunk?
Hello, it looks good; one question below...
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 100ec18..7521dee 100644
--- a/gcc/fortran/trans-decl.c
+++
Le 05/06/2013 14:49, Tobias Burnus a écrit :
Now with attached patch.
Tobias Burnus wrote:
I accidentally attached a slightly out-dated patch. The old patch
permitted CLASS-TYPE differences in cases where the characteristic
had to match (e.g. dummy arguments in a proc-pointer assignment). -
Le 07/06/2013 18:11, Tobias Burnus a écrit :
This patch fixes two issues:
* storage_size('aa') was rejected as constant expression - as
ts.u.cl-length == 0.
* In trans*.c, there was a fold_convert missing (- ICE). Additionally,
I have replaced the detour to generate a tree containing the
Hello,
Le 06/06/2013 10:35, Tobias Burnus a écrit :
* PING *
Attached is a rediff - including the later posted additional test case
(http://gcc.gnu.org/ml/fortran/2013-05/msg00141.html)
On May 31, 2013 18:39, Tobias Burnus wrote:
This patch adds finalization support for INTENT(out) for
Hello,
Le 03/06/2013 16:06, Tobias Burnus a écrit :
Dear all,
Due to copying the attributes, the temporary variable could get marked
as function (attr.function, attr.flavor == FL_PROCEDURE). This either
lead to leaking those attributes into the assembler file - or to cause
an error due to
Le 11/06/2013 12:00, Tobias Burnus a écrit :
Hello Mikael,
Mikael Morin wrote:
Le 03/06/2013 16:06, Tobias Burnus a écrit :
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b2e8fdc..655d3c1 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9293,8 +9293,12
Le 06/06/2013 17:10, Tobias Burnus a écrit :
The attached test case failed with an ICE for function result variables
as in that case the function decl was used.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Yes, thanks
Mikael
a runtime test as this area of the compiler
doesn't get much coverage from the test-suite.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2013-06-12 Mikael Morin mik...@gcc.gnu.org
PR fortran/49074
* trans-expr.c (gfc_conv_variable): Don't walk the reference
Hello,
Le 10/06/2013 22:40, Tobias Burnus a écrit :
My problem: I do not see where one can best handle the namelist for
modules. One possibility would be gen_namespace_die - but that would
come before the dies of all VAR_DECLs used in the namelist have been
created. And the code seems to
Le 13/06/2013 11:13, Tobias Burnus a écrit :
A rather simple patch. I wonder why we didn't get in trouble before -
the *dummy = NULL; part should affect also other optional allocatable
dummy arguments.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK; thanks.
Mikael
Le 13/06/2013 19:56, Tobias Burnus a écrit :
Mikael Morin wrote:
This fixes the problem, but shouldn't the fix be in gfc_expr_attr
instead?
I tried it - but it does not work: In many case, one actually needs a
function, e.g. for procedure pointers or for C_FUNLOC. Thus, I had to
add
Hello,
Le 16/06/2013 19:33, Tobias Burnus a écrit :
* PING *
Minor change: Jakub suggested to print no exception status with older
gfortran programs. Hence, the library now defaults to 0. (Older programs
do not pass this argument to the library.) - I also updated
gfortran.texi for that
Le 21/06/2013 17:14, Tobias Burnus a écrit :
In order to ensure that ALLOCATED(var) works, we have to allocate at
least one byte. While malloc(0) is permitted, it is system depended
whether it returns NULL or a unique non-NULL pointer.
Build and regtested on x86-64-gnu-linux.
OK for the
Le 21/06/2013 17:39, Tobias Burnus a écrit :
This patch extends the already existing end-of-scope finalization to
nonallocatables.
Note: The patch only handles finalization of unsaved local variables
whose type has a finalizer (including finalizable nonallocatable
components or finalizers
Le 28/07/2013 14:57, Thomas Koenig a écrit :
Hello world,
this patch yields an error for identical values in vector expression
subscripts. The algorithm is O(n**2) because
a) It would be impossible to detect a([i,i]) otherwise
b) This is not likely to be a performance bottleneck because
Le 06/08/2013 17:12, Janus Weil a écrit :
Hi all,
attached is a cleanup patch which concerns the gfc_code structure and
gfc_get_code function (in st.c). It basically does two things:
1) It replaces the many occurrences of XCNEW (gfc_code) in class.c
by gfc_get_code (), which internally
Le 08/08/2013 16:54, Janus Weil a écrit :
ping!
2013/8/3 Janus Weil ja...@gcc.gnu.org:
Hi all,
the attached patch plugs a memory leak of the TRANSFER intrinsic,
which can occur when transferring to CHARACTER strings. For details
see the PR.
Regtested on x86_64-unknown-linux-gnu. Ok for
Le 07/08/2013 16:02, Janus Weil a écrit :
Hi all,
here is a small regression-fix patch for a problem with procedure
pointers and the PURE attribute, for details see the PR. In essence:
gfc_compare_interfaces is asymmetric in the two interfaces it compares
(e.g. regarding the PURE
Le 07/08/2013 16:02, Janus Weil a écrit :
Hi all,
here is a small regression-fix patch for a problem with procedure
pointers and the PURE attribute, for details see the PR. In essence:
gfc_compare_interfaces is asymmetric in the two interfaces it compares
(e.g. regarding the PURE
Le 09/08/2013 19:06, Janus Weil a écrit :
thanks a lot for the review! I have committed to trunk as r201633.
Will do 4.8 and 4.7 soon (assuming your OK also applies to those ...)
Yes, of course.
Mikael
-case is fixed by the
gfc_conv_ss_startstride hunks only, but I also added the set_loop_bounds
and gfc_set_delta hunks, as these function seemed to need the same fix.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8?
Mikael
2013-08-20 Mikael Morin mik...@gcc.gnu.org
Le 19/08/2013 13:38, Janus Weil a écrit :
Hi all,
here is a small patch which does some cleanup to avoid an ICE on
invalid SELECT TYPE statements.
The first three hunks are just cosmetics, and the fourth one also
contains minor refactoring, where I pull some common code out of the
two
Le 22/08/2013 12:49, Janus Weil a écrit :
Hi,
Thus the condition should probably be
else if (selector-ts.type == BT_DERIVED) as the BT_CLASS was handled
before? OK with that change (if it works).
Good point. And yes, it works.
However, on second thought, I wonder why we need to treat
Le 14/08/2013 23:46, Thomas Koenig a écrit :
Hello world,
the attached patch enables more sophisticated bounds-checking on
array slices by using gfc_dep_difference to calculate extents.
The information may also be useful in other places of the
front end, I don't really know.
There is one
Le 22/08/2013 17:41, Janus Weil a écrit :
Hi all,
here is a wrong-code fix for type-bound assignments, which makes sure
that these are resolved to polymorphic procedure calls. This was not
always the case, because we used the wrong ordering when checking for
defined-assignment procedures
Hello,
Le 22/08/2013 15:20, Janus Weil a écrit :
Hi all,
the SIZEOF intrinsic currently returns the size according to the
*declared* type for polymorphic variables. I think this doesn't really
make much sense and it also causes ICEs when SIZEOF is called on
CLASS(*) variables (which don't
Le 22/08/2013 23:30, Mikael Morin a écrit :
Le 14/08/2013 23:46, Thomas Koenig a écrit :
Hello world,
the attached patch enables more sophisticated bounds-checking on
array slices by using gfc_dep_difference to calculate extents.
The information may also be useful in other places
Le 26/08/2013 13:22, Janus Weil a écrit :
Hi Mikael,
the SIZEOF intrinsic currently returns the size according to the
*declared* type for polymorphic variables. I think this doesn't really
make much sense and it also causes ICEs when SIZEOF is called on
CLASS(*) variables (which don't
.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
I plan to submit a variant that doesn't change the module format for the
branches (doing more parsing by hand).
Mikael
2014-01-02 Mikael Morin mik...@gcc.gnu.org
PR fortran/58007
* module.c (MOD_VERSION): Bump
Le 02/01/2014 18:40, Janus Weil a écrit :
Hi all,
I have just committed as obvious a one-line-removal patch which fixes
a wrong-code OOP regression:
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=206281
Sometimes computer programming is more witchcraft than (computer) science.
You
Le 22/12/2013 11:28, Janus Weil a écrit :
Hi all,
here is a patch for a rejects-valid problem with type-bound
procedures, which is due to the fact that the PURE attribute is being
propagated too late. (I'm not sure if this problem could show up also
with other attributes, so for now I'm
Le 09/01/2014 14:33, Janus Weil a écrit :
After noticing that the bug is actually a regression (see PR 57042):
Ok to backport to 4.7 and 4.8?
Sure!
Mikael
Le 09/01/2014 16:30, Janus Weil a écrit :
Hi all,
the attached patch started out as an ICE-on-invalid regression fix,
but after the ICE had been fixed recently by other means, it was
degraded to a mere error-recovery improvement. It removes some rather
'hackish' code that was added by
Le 04/01/2014 16:35, Janus Weil a écrit :
Hi Mikael,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by
206759)
@@ -1,3 +1,9 @@
+2014-01-18 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/58007
+ * gfortran.dg/unresolved_fixup_1.f90: New test.
+ * gfortran.dg/unresolved_fixup_2.f90: New test.
+
2014-01-18 Jakub Jelinek ja...@redhat.com
PR target/58944
@@ -19,7 +25,7 @@
2014-01-17 Jeff Law l
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will backport in a few days to 4.8 and 4.7.
I added the following hardening to the patch on the 4.8
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I
Hello, this is a fix for cases like:
program main
implicit none
intrinsic :: real
print *,(/ real(a = 1) /)
end
where `real(a = 1)' is initially parsed as a typespec, creating
a symbol for 'a' along the way. The match fails, and then it is parsed
as a constructor element and accepted that
The ChangeLog says it all.
2013-02-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/54730
* symbol.c (gfc_undo_symbols): Move code...
(restore_old_symbol): ... here as a new function.
diff --git a/symbol.c b/symbol.c
index 2c122d0..4f1752d 100644
--- a/symbol.c
+++ b
This packs symbol.c's 'changed_syms' and 'tentative_tbp' variables into a new
'gfc_change_set' structure using the vec API.
2013-02-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/54730
* Make-lang.in (F95_PARSER_OBJS): Add dependency to vec.h
* gfortran.h: Include vec.h
This is a fix for what looks like a thinko.
The other patches don't depend on it, so it can well wait for 4.9 if
that is preferred.
2013-02-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/54730
* symbol.c (restore_old_symbol): Fix thinko.
diff --git a/symbol.c b/symbol.c
index
-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/54730
* gfortran.h (struct gfc_change_set): New field 'previous'.
(gfc_new_checkpoint, gfc_drop_last_checkpoint,
gfc_restore_last_checkpoint):
New prototypes.
* symbol.c (change_set_var): Update initialization
This is the fix for the PR.
2013-02-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/54730
* array.c (gfc_match_array_constructor): Set a checkpoint before
matching
a typespec. Drop it on success, restore it otherwise.
diff --git a/array.c b/array.c
index 6787c05
Le 22/02/2013 16:23, Tobias Burnus a écrit :
Mikael Morin wrote:
Hello, this is a fix for cases like:
program main
implicit none
intrinsic :: real
print *,(/ real(a = 1) /)
end
where `real(a = 1)' is initially parsed as a typespec, creating
a symbol for 'a' along the way. The match
Hello,
as promised, here comes the patch for PR55574, where for code like:
use iso_c_binding, only : c_loc
type(C_PTR) :: f_ptr
the second statement is accepted despite c_ptr not being use-associated, as
c_loc implicitly pulls-in c_ptr.
This regression comes from Tobias' constructor patch
);
2013-03-02 Mikael Morin mik...@gcc.gnu.org
* symbol.c (gen_special_c_interop_ptr, gen_cptr_param,
generate_isocbinding_symbol): Use symbol ID explicitly.
Pass a NULL string to generate_isocbinding_symbol.
diff --git a/symbol.c b/symbol.c
index acfebc5..4e6004f 100644
gen_cptr_param uses gfc_get_ha_symbol to retrieve the c_ptr symbol.
This is not safe to symbol renaming and to symbol hiding.
This patch changes it to use get_iso_c_binding_dt, which is the function used
elsewhere.
2013-03-02 Mikael Morin mik...@gcc.gnu.org
* symbol.c (gen_cptr_param
This patch fixes gen_special_c_interop_ptr, which uses gfc_find_symtree to
retrieve
the current symbol. Again, this is not safe to renaming and hiding, so this
patch passes the symbol directly, instead of passing its name and retrieving
the symbol from it.
2013-03-02 Mikael Morin mik
changed tmp_sym-name
to name there as it made more sense to me (local name instead of real one). I'm
not completely sure that it's correct though.
2013-03-02 Mikael Morin mik...@gcc.gnu.org
PR fortran/55574
* gfortran.h (generate_isocbinding_symbol): New argument in prototype
Le 22/02/2013 16:23, Tobias Burnus a écrit :
Regarding the naming, can you use a bit more speaking names? For
instance – without claiming that the naming choice is best:
undo_changes instead of changes, emtpy_undo_change_set_var instead
of change_set_var, gfc_new_undo_checkpoint instead of
Hello,
I'm testing the attached patch which fixes the PR56477 test case.
Will commit as obvious tonight.
Mikael
2013-03-03 Mikael Morin mik...@gcc.gnu.org
PR fortran/56477
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer dereference.
2013-03-03 Mikael Morin mik
Hello,
Le 23/03/2013 10:59, Tobias Burnus a écrit :
Dear all,
initially, I only wanted to allow assumed-rank arrays with C_LOC, even if I
played with the idea to cleanup the intrinsic handling of the ISO_C_Binding
module for quite some time. But Mikael rejected a hacky version.
Did I?
Le 25/03/2013 11:11, Tobias Burnus a écrit :
Is the updated patch now okay for the trunk? (It was build and regtested
on x86-64-gnu-linux.)
OK. Many thanks.
Mikael
Le 26/03/2013 12:21, Tobias Burnus a écrit :
First, I am woefully aware that there are 7 patches which still have to
be reviewed (...), one by Mikael
If you are referring to
http://gcc.gnu.org/ml/fortran/2013-03/msg8.html
the patch is now obsolete, so we are now at only 6 patches pending.
Le 24/03/2013 22:58, Janne Blomqvist a écrit :
The attached patch takes the crude approach of first sequentially
reading the .mod file into a temporary buffer, then does the actual
parsing from that buffer.
I don't like it much, but knowing how bad module files are currently
handled, it's
Le 28/03/2013 18:48, Tobias Burnus a écrit :
Talking about dependencies, I wonder whether you would be interested
implementing the function
bool gfc_simply_noncontiguous (gfc_expr *);
or something similarly named.
It should return true, if the expression is known to be noncontiguous.
I
Le 02/04/2013 18:26, Tobias Burnus a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 99174bc..b0c831e 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3649,11 +3649,12 @@ gfc_check_sizeof (gfc_expr *arg)
/* Check whether an expression is interoperable.
Le 02/04/2013 19:19, Tobias Burnus a écrit :
{
snprintf (message, MSGLEN,
Read kind %d %s where kind %d is required for item %d,
- dtp-u.p.saved_length, type_name (dtp-u.p.saved_type), len,
+ type == BT_COMPLEX ? dtp-u.p.saved_length / 2
Le 04/04/2013 00:56, Tobias Burnus a écrit :
Am 04.04.2013 00:27, schrieb Mikael Morin:
Le 02/04/2013 19:19, Tobias Burnus a écrit :
{
snprintf (message, MSGLEN,
Read kind %d %s where kind %d is required for item %d,
- dtp-u.p.saved_length, type_name (dtp
Le 08/04/2013 10:34, Tobias Burnus a écrit :
Janne Blomqvist wrote:
On Thu, Mar 21, 2013 at 11:31 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Updated patch which in addition does the above transformations as
well.
.. and here is the actual patch (thanks Bernhard!)
Hello,
Le 12/04/2013 20:38, Janus Weil a écrit :
Unless someone has a better idea how to treat this, I will commit the
attached patch as obvious.
Not really a better idea, but it seems to me that function calls can
have trailing sub-references, so that gfc_match_varspec could be called
on
Le 13/04/2013 16:02, Janus Weil a écrit :
Hi Mikael,
So, it seems that EXPR_FUNCTION is acceptable in gfc_match_varspec.
And then, there is nothing preventing 'c(i)' in 'c(i)%encM()' from being
parsed as a function. Is this supported?
I think this is forbidden by the Fortran standard,
of
gfc_match_namespace. A syntax error is added to avoid the default
unclassifiable statement error.
Bootstrapped (with asan) and regression tested on x86_64-linux.
OK for trunk/4.8?
Mikael
2013-04-14 Mikael Morin mik...@gcc.gnu.org
PR fortran/56816
* match.c (gfc_match_select_type
Hello,
Le 14/04/2013 11:57, Thomas Koenig a écrit :
Hello world,
the attached patch completely fixes the regression,
PR 56782.
typo: it's PR 56872 everywhere.
Regression-tested. OK for trunk and 4.8?
Thomas
2013-04-14 Thomas Koenig tkoe...@gcc.gnu.org
PR
301 - 400 of 954 matches
Mail list logo
