Le 23/05/2015 01:04, Manuel López-Ibáñez a écrit :
> PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01511.html
>
> This only needs approval from Fortran maintainers.
>
I approved: https://gcc.gnu.org/ml/fortran/2015-05/msg00135.html
But it seems I replied to the fortran list only.
Mikael
-05-23 Mikael Morin
PR fortran/66257
* resolve.c (resolve_actual_arglist): Don't throw an error
if the argument with procedure pointer component is not a variable.
2015-05-23 Mikael Morin
PR fortran/66257
* typebound_call_27.f90: New file.
diff --git a/gcc/fortran/resolve.c
Le 25/05/2015 09:30, Paul Richard Thomas a écrit :
> Dear All,
>
> Lets see if I can get it right this time :-)
>
> Note that I have changed the name of the temporary variable in
> trans_allocate from 'atmp' to 'expr3' so that it is not confused with
> array temporaries.
I agree with Andre willin
hello Andre,
Le 25/05/2015 12:24, Andre Vehreschild a écrit :
> Hi Paul,
>
> I am not quite happy with the naming of the temporary variable. When I
> initially set the prefix to "atmp" this was because the variable would be an
> array most of the time and because of the number appended to it shou
Le 19/05/2015 12:26, Andre Vehreschild a écrit :
> Hi all,
>
> update based on latest 65548 (v5) patch and current trunk. Description and
> issue addressed unchanged (see cite below).
>
> Bootstrapped and regtested on x86_64-linux-gnu/f21.
>
> Any volunteers to review? The initial version dates
Le 27/05/2015 16:07, Andre Vehreschild a écrit :
> Hi Paul, hi Mikael,
>
> about renaming the identifier emitted: I would like to keep it short.
> Remember,
> there is always a number attached to it, which makes it unique. Furthermore
> does "alloc_source_tmp" sound unnecessarily long to me. It t
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 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
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 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
Le 14/01/2015 19:30, Janus Weil a écrit :
> Hi Mikael,
>
>>> 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 false
Le 15/01/2015 12:37, Janus Weil a écrit :
>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>> looks very similar to the Mikael's one for pr58023 at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
>> with retval replaved with success.
>>
>> Was it intended?
>
> Nope
Le 15/01/2015 14:25, Mikael Morin a écrit :
> Le 15/01/2015 12:37, Janus Weil a écrit :
>>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>>> looks very similar to the Mikael's one for pr58023 at
>>> https://gcc.gnu.org/bugzilla/atta
Le 29/07/2015 17:08, Paul Richard Thomas a écrit :
Dear All,
On 24 July 2015 at 10:08, Damian Rouson wrote:
I love this idea and had similar thoughts as well.
:D
Sent from my iPhone
On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
wrote:
Dear Mikael,
It had crossed my mind also that a
Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
Dear Mikael,
Thanks for your green light!
I have been mulling over the trans-decl part of the patch and having
been wondering if it is necessary.
You mean marking entities as public? Or setting the hidden visibility
attribute? Or both?
I th
Hello,
this renames the expr4 field of gfc_code to the more descriptive
ext.lock.acquired_lock.
Regression tested on x86_64-unkown-linux-gnu. OK for trunk?
Mikael
2015-08-05 Mikael Morin
* gfortran.h (struct gfc_code): Move expr4 field to
ext.lock.acquired_lock
Le 05/08/2015 21:24, Steve Kargl a écrit :
On Wed, Aug 05, 2015 at 08:54:21PM +0200, Mikael Morin wrote:
+/* LOCK/UNLOCK statements */
+struct
+{
+ gfc_expr *acquired_lock;
+}
+lock;
Just curious. Why add a struct with a single member?
I would have thought s/expr4
Le 19/04/2015 16:54, Mikael Morin a écrit :
Hello,
while working on pr65792, I noticed that gfc_trans_scalar_assign's
l_is_temp and dealloc flags are used only once, and at the same place.
This patch merges them together.
The calls are changed from
gfc_trans_scalar_assign (..
Le 25/07/2015 20:33, Mikael Morin a écrit :
Le 21/07/2015 23:10, Paul Richard Thomas a écrit :
On 21 July 2015 at 14:53, Mikael Morin wrote:
Hello,
The fix for PR61831 committed recently [1] introduced/uncovered a NULLL
pointer dereference with iso_varying_string, because a generic symbol
Le 29/07/2015 20:35, Mikael Morin a écrit :
Hello,
I'm unburrying the patch from the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00439.html
I provide the patch in two flavors read-only (without whitespace
changes) and write-only (with them).
This has been test
Le 21/07/2015 13:52, Mikael Morin a écrit :
Hello,
this is a followup to the bug report/patch at:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01062.html
It's a fortran quite unimportant bug, so I bet nobody cares.
However, the bug could have been detected when the co_reduce suppor
Hello,
this avoids an error found with bootstrap-ubsan.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-08-05 Mikael Morin
* hwint.h (sext_hwi): Rewrite without undefined behaviour on
negative SRC.
diff --git a/gcc/hwint.h b/gcc/hwint.h
index
Le 06/08/2015 12:53, Andre Vehreschild a écrit :
Dear all,
the attached patch fixes a regression introduced by my patches for the
F2008-style allocate(). In this case a function returning an array of BT_CLASS
objects can not be conv'ed using conv_expr_descriptor, but needs to be
conv_expr_refere
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,
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 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
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
(loop)->pre. The test-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
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
>
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
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
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 procedur
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 d
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 m
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 (whic
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
Hello,
Le 04/10/2012 00:06, Janus Weil a écrit :
> Hi all,
>
> the attached patch implements an F08 feature, which allows to
> distinguish two specific procedures in a generic interface, based on
> the POINTER and ALLOCATABLE attribute of their arguments.
>
> In addition to this, the patch fixes
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)
>
on x86_64-unknown-freebsd8.2. OK for trunk? Should I
backport to the branches?
Mikael
2011-07-07 Mikael Morin
gcc/fortran
PR fortran/49648
* resolve.c (resolve_symbol): Force resolution of function result's
array specification.
gcc/testsuite
PR fortran/49648
* gfortran.dg/result_in_spec
On Thursday 07 July 2011 07:35:07 Tobias Burnus wrote:
> diff --git a/libgfortran/caf/mpi.c b/libgfortran/caf/mpi.c
> index 83f39f6..2d4af6b 100644
> --- a/libgfortran/caf/mpi.c
> +++ b/libgfortran/caf/mpi.c
> @@ -103,10 +110,19 @@ _gfortran_caf_register (ptrdiff_t size, caf_register_t
type,
>
On Saturday 09 July 2011 20:59:08 Tobias Burnus wrote:
> The regression seems to be a side effect of the -fwhole-file effort.
>
> The BT_UNKNOWN of the second argument of SIGNAL(NUMBER,HANDLER) triggers
> an ICE in trans-types.c, when generating the decl for the external
> function "signal" (or ra
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 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
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
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
Le 23/12/2012 15:29, Tobias Burnus a écrit :
Please ignore that patch. I found a much simpler way, which is a tiny
patch and actually also works for the commented part of the test case of
the previous patch (i.e. the missed-optimization bit).
Namely, I now simply only tag all the symbols which a
we want it on the branches as well?
Mikael
2013-01-03 Steven G. Kargl
Mikael Morin
* class.c (gfc_fix_class_refs): Adapt ts initialization for the case
e->symtree == NULL.
* trans-expr.c (gfc_conv_function_expr): Init sym earlier. Use it.
diff --
Hello,
Le 04/01/2013 00:23, Tobias Burnus a écrit :
NULL with MOLD should be rejected as (default) initialization
expression. From F2008:
R506 null-init is function-reference
C512 (R506) The function-reference shall be a reference to the intrinsic
function NULL with no arguments.
"null-init" o
501 - 600 of 1039 matches
Mail list logo
