AINTAINERS (révision 237454)
@@ -289,7 +289,7 @@ Fortran Daniel Franke
Fortran Thomas König
Fortran Daniel Kraft
Fortran Toon Moene
-Fortran Mikael Morin
+Fortran Mikael Morin
Fortran Tobias Schlüter
Fortran Paul Thomas
Fortran Janus Weil
Le 18/10/2017 à 04:05, Steve Kargl a écrit :
On Tue, Oct 17, 2017 at 06:14:16PM -0700, Jerry DeLisle wrote:
On 10/17/2017 03:36 PM, Thomas Koenig wrote:
Hello world,
this patch fixes a regression with long compile times,
which came about due to our handling of array constructors
at compile tim
Hello,
Le 10/07/2017 à 20:43, Thomas Koenig a écrit :
Hello world,
with the bump in the libfortran version that is needed with
Paul's patch, I think we can get rid of a few functions
that we do not actually need any more.
I think we now always inline SUM and PRODUCT. We don't do so with all
oc
Hello,
Le 08/10/2017 à 15:15, Paul Richard Thomas a écrit :
I thought that the suggestion to add the original input lines was not
bad. It would be even better if -fdump-tree-original could do that.
There is -fdump-tree-original-lineno. I think it does that.
Cheers
Mikael
Le 04/02/2017 à 19:43, Andre Vehreschild a écrit :
Hi all,
attached patch fixes the issue of losing the data in the SOURCE= expression of
an ALLOCATE() when the source-expression is just a simple variable. The issue
was that internally a temporary variable was created, whose components were
free
Le 07/02/2017 à 19:46, Steve Kargl a écrit :
All,
The attach patch maps REAL128 from iso_fortran_env to
the REAL kind type with widest precision. Prior to
this patch, REAL128 is mapped to the first REAL kind
type with a matching storage size of 128 bits. On
x86_64-*-freebsd both REAL(10) and R
Le 08/02/2017 à 10:25, FX a écrit :
Hi Steve,
I see Mikael has okayed the patch, but I did not have any time to comment
prior. I wanted to note that:
- the choice was deliberate, as the standard allows us to choose which real
kind REAL128 corresponds to when there are several matching choice
Le 01/07/2016 16:58, Jakub Jelinek a écrit :
On Thu, Jun 30, 2016 at 08:06:54PM +0200, Jakub Jelinek wrote:
So, is it intentional that pushdecl / getdecls acts like a LIFO?
Though, it seems user vars are pushdecled in the reverse order of
declarations, but gfc_add_decl_to_function is called in t
Le 30/06/2016 06:05, Alessandro Fanfarillo a écrit :
Dear Mikael,
thanks for your review and for the test. The attached patch, built and
regtested for x86_64-pc-linux-gnu, addresses all the suggestions.
The next patch will change the documentation related to the caf_get
and caf_send functions a
Le 15/07/2016 à 03:26, Jerry DeLisle a écrit :
Hit send too soon and forgot to fill out the subject line. Correctly
given here.
On 07/14/2016 10:47 AM, Jerry DeLisle wrote:
This simple patch kindly provided by Marco solves the problem.
Regression tested on x86_64-Linux, Test case provided also.
Hello,
Le 16/07/2016 à 15:38, Thomas Koenig a écrit :
Hello world,
this fixes PR 71902. The recent fix for PR 71783 introduced a
performance and code size regression a string temporary was created for
the test case when it was not actually needed.
I also took the opportunity of renaming the mi
Le 17/07/2016 à 18:21, Thomas Koenig a écrit :
Hi Mikael,
Do we actually want to backport this? Technically, it is a regression,
but people are not likely to notice much.
It is not an ICE, neither a code correctness issue as far as I can see,
so I would rather not backport.
Fine with me.
Le 18/07/2016 à 22:20, Thomas Koenig a écrit :
Am 18.07.2016 um 20:58 schrieb Mikael Morin:
Unfortunately not. The original code (before I lifted out the
functionality) sometimes had GFC_DEP_ERROR at the end of the
function, which was then removed by
return fin_dep == GFC_DEP_OVERLAP
Hello,
this is mostly good in general, but is lacking tests.
Especially, tests for successfull matching, and tests for every error
you are adding in the patch (except maybe the -fcoarray= one).
Also tests that the code executes successfullly with -fcoarray=single,
and that it produces the right
Le 20/07/2016 à 11:39, Andre Vehreschild a écrit :
Hi Mikael,
+ if(st == ST_FAIL_IMAGE)
+new_st.op = EXEC_FAIL_IMAGE;
+ else
+gcc_unreachable();
You can use
gcc_assert (st == ST_FAIL_IMAGE);
foo...;
instead of
if (st == ST_FAIL_IMAGE)
foo...;
Le 08/12/2016 à 20:26, Thomas Koenig a écrit :
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be a
Le 08/12/2016 à 22:50, Thomas Koenig a écrit :
Am 08.12.2016 um 21:01 schrieb Mikael Morin:
Le 08/12/2016 à 20:26, Thomas Koenig a écrit :
Hi Andre,
Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the
Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :
Hi all, hi Dominique,
this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Mo
Hello,
Le 08/12/2016 à 23:49, Mikael Morin a écrit :
Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2e6ef2a..8173ba9 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1019,7 +1019,7
Hello,
Le 09/12/2016 à 11:55, Andre Vehreschild a écrit :
Hi Mikael,
thanks a lot for your comments. Note I also have added the reply to your latest
email here.
On Thu, 8 Dec 2016 23:49:57 +0100
Mikael Morin wrote:
diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce88
Le 11/12/2016 à 23:21, Thomas Koenig a écrit :
Hello world,
the attached patch fixes a 5/6/7 regression with -fimplicit-none.
Regression-tested. OK for all affected branches?
OK. Thanks
Mikael
Hello,
Le 30/11/2016 à 10:52, Janus Weil a écrit :
Hi all,
I have just committed a completely obvious patch for this PR. All it
does is rearrange some expressions to avoid an ICE (see attachment):
I have made a late review of it, and I think it’s not as innocent as it
seems.
With it, if the f
Le 17/12/2016 à 22:49, Janus Weil a écrit :
Hi Mikael,
I have just committed a completely obvious patch for this PR. All it
does is rearrange some expressions to avoid an ICE (see attachment):
I have made a late review of it, and I think it’s not as innocent as it
seems.
With it, if the first
Le 06/08/2015 14:00, Mikael Morin a écrit :
Let me have a look at it.
So, I've had a look at it.
This is a pandora box that I don't want to open.
So your change is OK.
However, could you clarify the comment?
Function calls returning a class object are either pointer or
allocatabl
Le 12/08/2015 13:09, Richard Biener a écrit :
On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
wrote:
On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
What kind of error does ubsan run into? That is, for which 'prec'?
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67042
Ugh. St
Le 12/08/2015 22:07, Richard Sandiford a écrit :
Jeff Law writes:
On 08/12/2015 12:32 PM, Richard Biener wrote:
On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
On 08/12/2015 11:12 AM, Richard Biener wrote:
Prec is almost never a constant and is heavily used from wide-int.
We are
Le 13/08/2015 12:56, Mikael Morin a écrit :
Still, implementation-defined behavior is a progress over undefined
behaviour.
Even if it's not set in stone, the good thing about
implementation-defined behaviour is that it's known to be non-random.
So it can be checked, either with autocon
I don't think it means anything.
What do you think, OK?
Mikael
2015-08-18 Mikael Morin
PR other/67042
* hwint.h (sext_hwi): Switch to unsigned for the left shift, and
conditionalize the whole on __GNUC__. Add fallback code
depending neither on undefined
/= -10) call abort
+end program p
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (révision 227009)
+++ gcc/testsuite/ChangeLog (révision 227010)
@@ -1,3 +1,8 @@
+2015-08-19 Mikael Morin
+
+ PR fortran/66929
Le 27/08/2015 16:54, FX a écrit :
I think it shouldn’t be too hard to get the ambiguity lifted. We already can do
it for array assignment vs. statement functions, so maybe we could get a hint
from that?
Well, for array assignments, the array is declared before, whereas for
pointer functions,
Le 03/11/2016 à 14:16, Andre Vehreschild a écrit :
@Dominique: Would you give it a go on your open patch collection? Maybe it
fixes one PR, but I am not very hopeful, because the patch is merely removing
complexity instead of doing new things.
Hello,
Since you asked:
I think the patch fixes pr
Le 11/11/2016 à 19:30, Steve Kargl a écrit :
On Fri, Nov 11, 2016 at 03:05:06PM +0100, Janus Weil wrote:
2016-11-11 14:38 GMT+01:00 Janus Weil :
[Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance
why it is necessary to nullify 'result->n.tb' on a newly-created
symtree?]
Remov
Le 06/12/2014 14:38, Manuel López-Ibáñez a écrit :
> * Tobias or other Fortran maintainers. The only test failing is
> gfortran.dg/do_iterator.f90 line 7. The old code gives an Error there,
> which the new one does not.
>
> /home/manuel/test1/pristine/gcc/testsuite/gfortran.dg/do_iterator.f90:7.9:
Hello Janus,
Le 13/01/2015 22:18, Janus Weil a écrit :
> Hi all,
>
> the attached patch fixes an ICE-on-invalid problem with
> procedure-pointer components by making sure that we continue resolving
> all components of a derived type, even after an error is thrown.
>
Does the fonction return fals
Hello Paul,
Le 18/11/2012 18:09, Paul Richard Thomas a écrit :
Dear Mikael,
Thank you for the last review of my patch for this PR. Since then, I
have had difficulty to find time for gfortran for both personal and
professional reasons.
thanks for your continued work despite that.
In a momen
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 like comment 0 is a 4.8 regression).
Still regtests cleanly. Ok?
OK with an extra test fo
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. In
Le 26/11/2012 12:21, Janus Weil a écrit :
2012/11/25 Mikael Morin:
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 like comment 0 is a
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 im
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 tr
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 re
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 exact
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
> +++ b/
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 assi
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
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(
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 du
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
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
;s; it's 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
PR fortran/49074
* trans-expr.c (gfc_conv_variable): Don't walk the refere
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
y the previous patch isn't
reachable any more in the PR49074 test-case, so I also add a test
based on the PR56136 one.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2013-06-15 Mikael Morin
PR fortran/49074
PR fortran/56136
* de
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 tha
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
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 finaliz
Le 17/07/2013 12:36, Tobias Burnus a écrit :
> Without this patch, GCC 4.3 and later segfault. As Mikael wrote:
> "gfc_restore_last_undo_checkpoint seems to take care of the cleanup, so
> we don't need to do it in gfc_match_common."
>
> Additionally, this patch ensures that the error message about
Le 16/07/2013 17:16, Tobias Burnus a écrit :
> As reported in the PR, gfortran was lacking a check for the args= for
> MIN/MAX. Those are special as they accept 'infinitely' many arguments -
> while others have a finite set.
>
> Added checks:
> - Ensure that only a1=, a2=, a3= etc. is used.
> - En
Le 17/07/2013 11:02, Tobias Burnus a écrit :
> As there is again a CPU dependence:
> - David, can you have a look at config/fpu-aix.h?
> - Eric and Gerald, can you have a look at config/fpu-sysv.h?
> - Uros, can you have a look at config/fpu-387.h?
>
> All: Does on any of the systems exists a roun
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 be
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 int
Le 08/08/2013 16:54, Janus Weil a écrit :
> ping!
>
> 2013/8/3 Janus Weil :
>> 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 t
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 attri
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 attri
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
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
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 (
ptr_id);
bar (ptr_id);
2013-03-02 Mikael Morin
* 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 1
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
* symbol.c (gen_cptr_param): Retrieve pointer
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
ith a capitalized first letter name). I also 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
PR fortran/55574
* gfortran.h (ge
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
Hello,
I'm testing the attached patch which fixes the PR56477 test case.
Will commit as obvious tonight.
Mikael
2013-03-03 Mikael Morin
PR fortran/56477
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer dereference.
2013-03-03 Mikael Morin
PR fo
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
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
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_l
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
Le 08/04/2013 10:34, Tobias Burnus a écrit :
> Janne Blomqvist wrote:
>> On Thu, Mar 21, 2013 at 11:31 PM, Janne Blomqvist
>> wrote:
>>> Updated patch which in addition does the above transformations as
>>> well.
>> .. and here is the actual patch (thanks Bernhard!)
> http://gcc.gnu.org/ml/fortran
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 t
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 st
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
PR fortran/56816
* match.c (gfc_match_select_type): Add sy
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
>
> PR fortran/56782
>
Le 13/04/2013 17:44, Mikael Morin a écrit :
> Indeed, that's invalid:
>
And then, the call to gfc_match_varspec shouldn't be there in the first
place. I'll test the following later.
Index: primary.c
===
---
Le 14/04/2013 16:21, Thomas Koenig a écrit :
> Hi Mikael,
>
>>>
>>> - (void) gfc_expr_walker (&fcn, callback_reduction, NULL);
>>
>> why remove this?
>
> Because it is not needed, as the test case _46 shows. No need
> to run this twice, it doesn't get better :-)
>
Indeed, that's right.
> gf
Le 09/04/2013 20:33, Janne Blomqvist a écrit :
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
Looks good. OK. Thanks.
> (IMHO the increase in compile time is modest enough that it's not
> worth doing the caching of uncompressed module files that I was
> previously thinking about, especi
{ scan-tree-dump-times "while" 2 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
Index: testsuite/ChangeLog
=======
--- testsuite/ChangeLog (révision 198085)
+++ testsuite/ChangeLog (révision 198086)
@@ -
Hello,
Le 21/04/2013 23:04, Janus Weil a écrit :
> Hi all,
>
> the attached patch fixes an regression with TRANSFER, which was just
> reported today. The problem was that array-valued SOURCE arguments
> were not treated correctly.
>
> To fix it properly, I had to make 'gfc_target_expr_size' beha
e)
+ end function
+end module
+
+program main
+ use ellpack
+ use bsr
+end
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (révision 206758)
+++ gcc/testsuite/ChangeLog (révision 206759)
@@ -1,3 +1,9 @@
+2014-01-18 Mik
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
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 unlu
tted the following as http://gcc.gnu.org/r207152
I made sure it worked even without bootstrap.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 207151)
+++ ChangeLog (révision 207152)
@@ -1,3 +1,9 @@
+2014-01-27 Mikael Mo
Le 01/02/2014 18:57, Paul Richard Thomas a écrit :
> Dear All,
>
> This regression was flagged by Harald and the trigger, r158683, was
> identified by HJ. Many thanks to both. It surprises me that the bug
> has lain dormant for so long.
>
> The fix is fortunately relatively simple. CHARACTER sc
t, it seems to be correct.
regression tested on x86_64-unknown-linux-gnu; OK for trunk and then
4.8/4.7?
Mikael
2014-01-26 Mikael Morin
PR fortran/57033
* primary.c (gfc_convert_to_structure_constructor): Avoid null pointer
dereference.
2014-01-26 Mikael
Le 02/02/2014 21:31, Janus Weil a écrit :
> Hi all,
>
> the attached patch fixes an OOP-related 4.7-only regression. Pretty
> much straightforward, for details see PR.
>
> Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
>
Yes, thanks.
Mikael
501 - 600 of 1075 matches
Mail list logo
