Hi Tobias,
Thomas Koenig wrote:
This patch takes the approach that any array bound which
contains a dummy variable which is not INTENT(IN) may be
changed by the user, and that we cannot be assured that
it will not be changed.
How about sym-attr.flavor == FL_PARAMETER? I am not sure
is sensible should
be using INTENT(IN) for array bounds, anyway :-)
So, here is the patch. Regression-tested.
OK for all affected branches?
Thomas
2015-01-20 Thomas Koenig tkoe...@netcologne.de
PR fortran/57023
* dependency.c (callback_dummy_intent_not_int): New function
Am 30.12.2014 um 01:25 schrieb Thomas Koenig:
Hello world,
this patch fixes the long-standing bug. A missing temporary
causes an invalid read in realloc_on_assign_5.f03 which
only becomes noticable when setting MALLOC_CHECK_ or when
using valgrind. The bug has three duplicates
Am 05.01.2015 um 19:55 schrieb H.J. Lu:
On Linux/x86, I got
../../src-trunk/gcc/fortran/frontend-passes.c: In function ‘int
realloc_string_callback(gfc_code**, int*, void*)’:
../../src-trunk/gcc/fortran/frontend-passes.c:152:38: error:
‘gfc_discard_nops’ was not declared in this scope
I have committed the test case from PR 65563 as obvious, since
the bug appears to have been fixed some time ago.
2015-03-29 Thomas Koenig tkoe...@gcc.gnu.org
PR libgfortran/65563
* gfortran.dg/open_errors_2.f90: New test.
Regards
Thomas
! { dg-do run }
! { dg-shouldfail
into it?
2015-04-19 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR.
(gfc_array_spec): Add resolved flag.
(gfc_intrinsic_sym): Add vararg.
* intrinsic.h (gfc_check_fe_runtime_error): Add prototype
covered.
Regression-tested. OK for trunk?
2015-04-25 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* simplify.c (simplify_bound): Get constant lower bounds
from array spec for assumed shape arrays.
2015-04-25 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran
Hi Mikael,
Looks good.
In general, it is better to restrict changes to existing test cases to
the necessary minimum that they still pass, and add new code to new
test cases. This makes regressions easier to track.
So, OK with that change.
Thomas
Am 27.04.2015 um 13:17 schrieb Mikael Morin:
Hello,
while reviewing Thomas' bound simplification patch, I noticed that the
{l,u}bound simplification code wasn't handling array subcomponents.
Fixed by the attached patch, regression tested. OK for trunk?
Hi Mikael,
the patch is OK. Thanks!
Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* simplify.c (simplify_bound): Get constant lower bounds of one
from array spec for assumed and explicit shape shape arrays if
the lower bounds are indeed one.
2015-04-25 Thomas Koenig tkoe...@gcc.gnu.org
Hello world,
here is a slight correction: This patch includes the change to
the test case.
Regards
Thomas
Index: fortran/simplify.c
===
--- fortran/simplify.c (Revision 222431)
+++ fortran/simplify.c (Arbeitskopie)
@@
Hi Mikael,
thanks for the review. I have committed the following, which took
your remarks into account (plus an additional test case, as obvious).
Regards
Thomas
2015-05-06 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* gfortran.h (gfc_isym_id): Add
obviously do no harm), but anyway: OK for
trunk?
Regards
Thomas
2015-05-10 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66041
PR fortran/37131
* gfortran.h (gfc_array_spec): Add field resolved.
* array.c (gfc_resolve_array_spec): Resolve array spec
2015-05-03 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* gfortran.dg/bound_9.f90: Add pointer assignment.
Hello world,
this is an update of the matmul inline patch. The only difference to
the last version is that it has the ubound simplification taken out.
Any further comments? OK for trunk?
Thomas
2015-05-05 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
made in the callers.
This is independant from the rest, so it can be made later as a follow-up.
Done (all in once).
I have attached the new patch (in which I also restructured the test),
plus the test cases.
OK for trunk?
Thomas
2015-05-08 Thomas Koenig tkoe...@gcc.gnu.org
Hi Mikael,
thanks for the review.
Here is what I committed.
Regards
Thomas
2015-05-10 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66041
* frontend-passes.c (scalarized_expr): Set correct dimension and
shape for the expression to be passed to lbound. Remove
Hello world,
this patch fixes the regression in PR 66041, plus one more case
that came up when I looked at this.
OK for trunk?
Regards, Thomas
2015-05-08 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66041
* frontend-passes.c (scalarized_expr): Clear as-start, as-end
Hi Mikael,
To be honest, both patches look fragile to me. Yours because it leaves
gfc_current_ns to its value, leaving the door open to other problems.
Mine, well, because it's playing with a global variable, with the
possible side-effects this could have.
However, without a better idea,
Hello world,
this patch fixes a regression from the inline matmul patch by
not inlining a case that is not yet handled, namely vector
subscripts.
Regression-tested. OK for trunk?
Regards
Thomas
2015-05-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66111
Hello world,
this (rather obvious) patch fixes array declarations in deeply nested
BLOCKs.
Regression-tested. OK for trunk?
Thomas
2015-05-16 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66113
* expr.c (is_parent_of_current_ns): New function
Hello world,
this patch extends the inline matmul functionality to conjugate
complex numbers.
Regression-tested. OK for trunk?
Regards
Thomas
2015-05-17 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66176
* frontend-passes.c (check_conjg_variable): New function
Hi Mikael,
Still to do: Bounds checking (a rather big one),
... as you do a front-end to front-end transformation, you get bounds
checking for free, don't you?
Only partially.
What the patch does is
integer i,j,k
c = 0
do j=0, size(b,2)-1
do k=0, size(a, 2)-1
OK, here is a new version.
There is now an option for setting a maximum on the array size,
which takes its default from the BLAS limit (if specified).
Currently, only setting the maximum size to zero as a way of
disabling the unrolling is supported. I have done this in a
few test cases.
The
Hello world,
here is the newest version of the matmul patch. This also honors
the -finline-matmul-limit= option, either at compile-time or at
run-time.
Question: What to do about run-time bounds checking? I am leaning
towards making an intrinsic subroutine which can not be called
by the user,
Thomas Koenig tkoe...@gcc.gnu.org
* frontend-passes.c (create_var): Add optional argument
vname as part of the name. Split off block creation into
(insert_block): New function.
(cfe_expr_0): Use fcn as part of tempoary name.
(optimize_namesapce): Call
Hi Dominique,
IMO the inlining of MATMUL should be restricted to small matrices (less than
4x4, 9x9
or 16x16 depending of your field!-)
The problem with the library function we have is that it is quite
general; it can deal with all the complexity of assumed-shape array
arguments. Inlining
Hi Jerry,
I am curious about what performance gain results from this? I can see
saving a library call to our runtime libraries. Do you have some timing
results?
The speedup can be quite drastic for small matrices which can be
completely unrolled by -O3:
b1.f90:
program main
use b2
Hi Dominique,
which means that -fexternal-blas should disable the inlining.
It is not surprising that a higly tuned BLAS library is better than
a simple inlining for large matrices.
I did some tests by adjusting n; it seems the inline version is
faster for n=22, which is not too bad.
However, I think the patch is useful as it is now, and can go
into trunk.
So: OK for trunk?
Thomas
2015-04-19 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR.
(gfc_array_spec): Add resolved flag
Hello world,
I have committed the two test cases below as obviously
correct after testing.
They stress bounds checking on matmul by having an argument
whose size cannot be predicted at compile-time.
Regards
Thomas
2015-05-17 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran
Am 01.06.2015 um 22:10 schrieb Steve Kargl:
c) Warn for
print *,3.1415926535 with -Wconversion-extra
and don't warn for
print *,3.141592653589_4
This would be my first choice. If a user actually specifies
a suffix, I assume that the user has given some thought
to the
to install the gcc 5 branch...)
There would be an alternative, in principle, to put the BLOCK around
the FORALL, but frankly, I don't think it is worth spending the
effort and complicating the code.
Regards
Thomas
2015-06-11 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/66385
Hello world,
the attached patch fixes the PR by adding a charlen to the
function expression of adjustl and adjustr. Committed
as obvious after regression-testing.
Regards
Thomas
2015-06-04 Thomas Koenig tkoe...@netcologne.de
PR fortran/58749
* iresolve.c
*ping*
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00966.html
Hello world,
the attached patch emits a warning for constant integer division.
While correct according to the standard, I cannot really think
of a legitimate reason why people would want to write 3/5 where
they could have
Hi Andre,
please find attached an updated version of the patch. This patch simplifies
some cases and ensures more straight line code. Furthermore was a bug in the
interfacing routine for the _vptr-_copy() routine removed, where not the
third
and fourth arguments translated to be passed be
{-\pi \leq \omega \leq \pi}.
+@math{-\pi \omega \leq \pi}.
@item @emph{Example}:
@smallexample
2015-06-14 Thomas Koenig tkoe...@gcc.gnu.org
* intrinsic.texi: Change \leq to in descrition of imaginary
part in argument to log.
Hello world,
the attached patch emits a warning for constant integer division.
While correct according to the standard, I cannot really think
of a legitimate reason why people would want to write 3/5 where
they could have written 0 , so my preference would be to put
this under -Wconversion (like
do so if the consensus is that this is better. It
might also be possible to invent another name for this option,
and maybe enable this with -Wsurprising.
Regression-tested. Comments? OK for trunk?
Thomas
2015-05-31 Thomas Koenig tkoe...@netcologne.de
PR fortran/47359
Hi Steve,
The second part catches the case when the user supplies more
digits than appropriate for the number. More often than not,
this is a KIND error.
Does the above issue warnings for
real(knd), parameter :: pi = 3.1415926535897932384626433832795029_knd
module foomod
Am 01.06.2015 um 15:40 schrieb Steve Kargl:
On Mon, Jun 01, 2015 at 08:34:24AM +0200, Thomas Koenig wrote:
What would be the peferred alternative?
Is it possible to detect the _knd suffix?
Yes, this is possible.
If so, no
warning is my preference as it is never incorrect to
specify more
Hi Andre,
Because this patch is obvious I plan to commit it tomorrow if no one objects?!
The patch itself is obviously OK.
About the test case: In general, it is better not to change existing
test cases unless absolutely necessary (e.g. adjust an error message).
This makes it easier to track
Hi Andre,
just a couple of remarks.
You are adding significant new code to an existing
test case, allocate_with_source_3.f90. As discussed
previously, it would be better to put the new code
into an extra test case.
The following test case segfaults with your patch
with an invalid free:
module
Hi Steve,
The attached patch avoid the dereference of a NULL pointer,
and thereby avoids an ICE. Regression tested on trunk.
OK to commit?
OK.
Thanks for the patch!
Thomas
Hello world,
I just committed the following patch to the WWW docs.
An error was reported by Gerald's script, but that seems to
have been spurious. At least, there was no error on
revalidation.
Regards
Thomas
2015-07-01 Thomas Koenig tkoe...@netcologne.de
* gcc-6
Am 18.05.2015 um 00:05 schrieb Thomas Koenig:
this patch extends the inline matmul functionality to conjugate
complex numbers.
Regression-tested. OK for trunk?
OK (with the trivial change in the follow-up e-mail)?
I'd like to start extending this to TRANSPOSE(CONJG(A)) :-)
Thomas
Hi Mikael,
There is little that is specific to conjg (any elemental function would
work roughly the same), but anyway, the patch is OK.
Conjg has the advantage that it is an extremely cheap function -
essentially zero cost.
For an arbitrary elemental function, we would have to think about
Hi Mikael,
However, it introduces regressions on matmul_bounds_{2,4,5}.
It seems the incorrect extent runtime errors are completely optimized
away (even at -O0).
Any ideas?
This is seriously wierd. It seems that the call to gfortran_error is
really optimized away, because the middle-end
Am 21.07.2015 um 19:26 schrieb Mikael Morin:
Le 20/07/2015 23:55, Thomas Koenig a écrit :
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
a-name = %VAL;
c-resolved_sym = gfc_get_intrinsic_sub_symbol
Hi Steve,
When an specification statement in a BLOCK construct has a
PARAMETER attribute, gfortran currently discards the entity.
This patch marks PARAMETER entity if in a BLOCK. I'm not
complete convince that this is the right fix, but it does
allow the testcase to compile and run. Built and
Am 29.10.2015 um 19:35 schrieb Steve Kargl:
The patch for PR fortran/36192 that I committed here:
https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg02160.html
cured an ICE for a testcase that was reduced from the
originally submitted mutilated Fortran code. The
original code could in fact invoke
Hi Dominique,
(1) Why is this block reached when compiling with -ffrontend-optimize, but not
with -fno-frontend-optimize (Thomas)?
The problem here is that gfc_variable_attr is called (indirectly)
during optimize_assignment. In this case, this causes the ICE
because of the existing error
Hi Jerry,
Attached patch eliminate this problem by reverting a portion of the previous
patch to pr65089.
Regression tested on x86_64-Linux. I will add test case from the PR.
OK for trunk and then back port to 5x?
Both.
Thanks a lot for the patch!
Thomas
Hi Andre,
for bug pr69011 I like to propose the attached patch. The patch fixes
the ICE and furthermore makes sure, that for this case of referencing a
polymorphic object the correct vtype is selected. Previously the
declared vtype of the source=-expression was taken for the object(s) to
Hi Jakub,
We ICE at -O0 while compiling the testcase below, because we don't reset
two vars that are reset in all other places in frontend-passes.c when
starting to process an unrelated statement. Without this,
we can emit some statement into a preexisting block that can be elsewhere
in the
Am 21.07.2016 um 20:00 schrieb H.J. Lu:
On Tue, Jul 19, 2016 at 2:27 PM, Thomas Koenig <tkoe...@netcologne.de> wrote:
Here is the pacth the way I committed it.
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961
As usual for SPEC errors: Please provide a test case.
R
positives).
It also checks for the presence of a substring on the RHS
expression, because the problem cannot happen if there is
no RHS substring.
Regression-tested on trunk.
OK for trunk? Also OK for a backport?
Regards
Thomas
2016-08-14 Thomas Koenig <tkoe...@gcc.gnu.org>
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.
+case GFC_DEP_FORWARD:
+
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;
That is very strange, there is an assert just a
Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref. Handle case
if identical is true and two array element references differ.
(gfc_dep_resovler): Move most of the code to dep_ref.
(dep_ref): New fu
for trunk?
Do we actually want to backport this? Technically, it is a regression,
but people are not likely to notice much.
Regards
Thomas
2016-07-16 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref. Handl
Thomas
2016-07-09 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71783
* frontend-passes.c (create_var): Always allocate a charlen
for character variables.
2016-07-09 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71783
*
Am 07.08.2016 um 13:52 schrieb Andre Vehreschild:
Hi Andre,
attached patch fixes the ICE caused by a zero-sized string. Assigning
that string to a temporary variable obviously did not work out. The
patch fixes this by checking for zero-sized strings in SOURCE= and not
producing the code to
Hi Andre,
the patch is OK.
Ping.
Regards
Thomas
Hello world,
I have committed the attached patch as obvious and simple
after regression-testing. This fixes a regression.
Will commit to the other affected branches shortly.
Regards
Thomas
2016-07-22 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71795
* fr
) in the typespec were
not output to the dump of the Fortran AST, I have also added this.
I will backport to 6 and 5 in a few days.
Regards
Thomas
2016-08-15 Thomas Koenig <tkoe...@gcc.gnu.org>
* frontend-passes.c (create_var): Set ts.deferred for
deferred-length cha
Hi Fritz,
Still waiting on a review for this patch. Comments/concerns from all
are welcome.
The patch looks fine to me.
OK for trunk, and thanks for the patch!
Regards
Thomas
@Gerald: Will a gcc-7/changes.html file be generated? If so, we should
document this new flag (and
ses actual performance
issues.
Regards
Thomas
2016-08-18 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/71902
* frontend-passes.c (realloc_string_callback): Check for deferred
on the expression instead for allocatable on the symbol. Name
temporary
Hi Lipeng,
Sure, as your comments, in the patch V6, I added 3 test cases with
OpenMP to test different cases in concurrency respectively:
1. find and create unit very frequently to stress read lock and write lock.
2. only access the unit which exist in cache to stress read lock.
3. access the
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
Hi Rimvydas,
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Thanks for your work on this!
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
Hello world,
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK for trunk?
Thomas
2014-03-12 Thomas Koenig
simplification and run-time
execution.
OK for trunk?
Thomas
2014-03-12 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/59604
* gfortran.h (gfc_convert_mpz_to_signed): Add prototype.
* arith.c (gfc_int2int): Convert number to signed if
arithmetic
Hi Tobias,
Am 12.04.2014 21:33, schrieb Thomas Koenig:
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK
Hello world,
this contains a straightforward fix for the regression by
not trying to do combine array constructors inside
association lists.
Regression-tested. OK for all affected open branches?
Thomas
2014-05-10 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/60834
Hello world,
the attached patch fixes PR 60522, a regresseion where temporary
variables were incorrectly introduced in a BLOCK within a WHERE
statement.
Regression-tested on x86_64-unknown-linux-gnu.
OK for trunk and the other open branches?
Thomas
2014-04-16 Thomas Koenig tkoe
Hello world,
the attached patch fixes the regression (after some thought
of what might still be optimized, which isn't much :-)
Regression-tested. OK for trunk?
Thomas
2014-04-25 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/60522
* frontend-passes.c (cfe_code): Do
Hi Tobias,
first, thanks Trevor for the first round of review!
Also thanks from my side!
I still see:
- expr_count = 0;
+ expr_array.truncate (0);
Is there is a reason for not using release() here?
No, changed in the committed version.
Regards
Thomas
Am 02.09.2014 17:32, schrieb Tobias Burnus:
Marek Polacek wrote:
This patch fixes the last two spots where -Wlogical-not-parentheses
warns. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270#c3
if you want more info about the changes.
Bootstrapped/regtested on x86_64-linux, ok for
Hi Joost,
A somewhat trivial patch to cleanup whitespace issues in comments: sed s/\.
\*\//\. \*\//g
Tested with a recompile only.
Ok for trunk ?
OK. (Obvious, really).
Thomas
Hello world,
the attached patch fixes a regression introduced with the recent
checking for DO loop variables when they are used with a generic
subroutine where the generic name matches one of the actual names.
Regression-tested. OK for trunk?
Thomas
2012-12-08 Thomas Koenig tkoe
Am 08.12.2012 17:39, schrieb Janus Weil:
Hi Thomas,
the attached patch fixes a regression introduced with the recent
checking for DO loop variables when they are used with a generic
subroutine where the generic name matches one of the actual names.
Regression-tested. OK for trunk?
A few
Hi Janus,
2012/12/8 Thomas Koenig tkoe...@netcologne.de:
Because undeclared is not declared, the resolution doesn't happen,
and resolved_sym is NULL. This is OK because an error has been
raised about this anyway;
good, if it only happens when an error has been raised, I think your
patch
Hello world,
the attached patch fixes the regression and regtests cleanly.
No test case because I could not find anything portable
to create a FIFO in the testsuite.
OK for trunk and 4.7?
Thomas
2012-12-15 Thomas Koenig tkoe...@gcc.gnu.org
PR libfortran/30162
* io
Ping?
Thomas
Hi Janus,
Oops, right. Here is the correct one.
Regards
Thomas
wrong patch attached? It contains a hunk in frontend-passes.c, which
seems totally unrelated ...
Cheers,
Janus
2012/12/15 Thomas Koenig tkoe...@netcologne.de:
Hello world,
the attached patch
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
Thomas
2013-01-01 Thomas Koenig tkoe...@gcc.gnu.org
Am 06.01.2013 12:45, schrieb Janus Weil:
Since it's not a regression, it does not necessarily need to be
backported. However, the sort of wrong-code behavior seen in comment
#24 is severe enough that it might justify backporting. I leave that
up to you.
FWITW, I think it should be backported
Ping?
http://gcc.gnu.org/ml/fortran/2013-01/msg0.html
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
Ping**2?
This was submitted before the review, so I think it should still be OK.
Ping?
http://gcc.gnu.org/ml/fortran/2013-01/msg0.html
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
,2) - b(i,2)) acc,
abs(a(i,3) - b(i,3)) acc, lo(i,:)])) cycle
c = c + i
end do
into the test case.
Updated test case and patch attached.
OK for trunk?
Thomas
2013-01-13 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/55806
* frontend
Am 14.01.2013 14:29, schrieb Mikael Morin:
Le 13/01/2013 23:14, Thomas Koenig a écrit :
OK for trunk?
OK with the changes suggested above. Thanks.
Committed as rev. 195179 with your changes.
Thanks a lot for the thorough review!
Thomas
?
Thomas
2013-01-20 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/55919
* add_path_to_list: Copy path to temporary and strip
trailing directory separators before calling stat().
2013-01-20 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/55919
Hi Steve,
The patch looks OK to me. As this is a Windows,
hopefully someone will confirm that the patch
fixes the Windows issue before you commit.
Thanks!
Committed as rev. 195348 after Brad's confirmation that the
patch works on Windows. One more regression down, 24 to go.
Thomas
Hi Janne,
PING**2
this is OK. Thanks a lot for the work you put into this!
Thomas
Hello world,
the attached patch fixes the regression regarding freeing
namespaces twice.
The test cases where also run unter valgrind without
producing errors.
Regression-tested. OK for trunk?
Thomas
2013-01-27 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/56054
Of course, that should be PR 50627 in the ChangeLog.
Am 27.01.2013 21:16, schrieb Mikael Morin:
Or maybe wait for the fix for comment #4?
I would rather commit the fixes now, just on general principles.
If any regression should occur, it would be easier to pinpoint
the reason.
Thomas
Hi Paul,
This patch is sufficiently straightforward that the ChangeLog entry
describes it completely. The fix for both bugs lay in the
nullification of the allocatable components of the newly (re)allocated
array.
I think this fix is OK for trunk, for the reasons you mentioned. I also
think
Hi Janus,
Or maybe wait for the fix for comment #4?
Rather not (technically it's a separate issue, I guess).
While the patch is rather large, I think it is OK.
One request: Could you add a comment to gfc_sym_get_dummy_args
explaining what the function does and under which conditions
1 - 100 of 1351 matches
Mail list logo
