Hi,
On 25 January 2019 12:44:30 CET, Sebastian Huber
wrote:
libgfortran/
* io/async.c (init_adv_cond): Use
__GTHREAD_COND_INIT_FUNCTION().
LGTM.
Please CC the FORTRAN list for FORTRAN patches.
thanks,
---
libgfortran/io/async.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Am 27.01.19 um 14:18 schrieb Thomas Koenig:
Hello world,
the attached, rather straightforward patch fixes a rejects-valid error
by fixing up the contiguous attribute for a class, and by using the
correct attributes.
Regression-tested. OK for trunk?
PING ** (4./7.)?
Regards
Thomas
branches?
Regards
Thomas
2019-02-02 Thomas Koenig
PR fortran/88298
* arith.c (gfc_int2int): Do not warn if src->do_not_warn is set.
* gfortran.h (gfc_expr): Add flag do_not_warn.
* intrinsic.c (gfc_convert_type_warn): Set expr->do_not_w
I get this part committed, I intend to resolve 67679 as a duplicate
of 66459.
Regression-tested. OK for trunk?
Regards
Thomas
2019-02-03 Thomas Koenig
PR fortran/67679
* trans-array.c (gfc_array_allocate): For setting the bounds on
the new array, add a
Hi Steve,
On Sun, Feb 03, 2019 at 05:20:34PM +0100, Thomas Koenig wrote:
+ if (allocatable)
+{
+ not_prev_allocated = gfc_create_var (logical_type_node,
+ "not_prev_allocated");
Can't remember semantics of gfc_c
attributes;
for example, an expression containing a pointer attribute is
shown as having the target attribute, for reasons I cannot
fathom.
Regression-tested. OK for trunk and other open branches?
Regards
Thomas
2019-02-06 Thomas Koenig
PR fortran/71237
* expr.c
there as well).
Regards
Thomas
2019-02-06 Thomas Koenig
PR fortran/71860
* gfortran.dg/null_10.f90: New test.
! { dg-do compile }
! PR 71860 - this used to ICE
! Original test case by Gerhard Steinmetz
program p
class(*), pointer :: z
z => null(z)
end
Hi Harald,
OK for trunk? And for backports to 8/7?
I played around with your patch and found a few problems with
ICEs, but these were all pre-existing as far as I could determine;
I have submitted PR89266 for what I discovered.
I a bit concerned about the case of like a(i:i-2) returning nega
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
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 +2
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 dec
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 ano
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
PR libgfortran/65563
* gfortran.dg/open_errors_2.f90: New test.
Regards
Thomas
! { dg-do run }
! { dg-shouldfail "runtime
Thomas
2015-04-05 Thomas Koenig
* 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.
(o
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
im
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 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.
Regardi
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 bug
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
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, a
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
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR.
(gfc_array_spec): Add resolved flag
=
>> --- fortran/options.c(Revision 18)
>> +++ fortran/options.c(Arbeitskopie)
>> @@ -378,6 +378,11 @@ gfc_post_options (const char **pfilename)
>>if (!flag_automatic)
>> flag_max_stack_var_siz
covered.
Regression-tested. OK for trunk?
2015-04-25 Thomas Koenig
PR fortran/37131
* simplify.c (simplify_bound): Get constant lower bounds
from array spec for assumed shape arrays.
2015-04-25 Thomas Koenig
PR fortran/37131
* gfortran.dg
lower bounds, so it is
OK for the time being to (slightly) pessimize this case.
So... here is the new patch. OK for trunk?
Thomas
2015-04-25 Thomas Koenig
PR fortran/37131
* simplify.c (simplify_bound): Get constant lower bounds of one
from array spec for a
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)
@@ -344
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. Tha
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-&
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":
modul
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
PR fortran/47359
* arith.c (eval_intrinsic_op
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 foo
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 inco
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
PR fortran/66385
* fro
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
PR fortran/58749
* iresolve.c (gfc_resolve_adjustl): If
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
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
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 i
same as @var{X}.
If @var{X} is @code{COMPLEX}, the imaginary part @math{\omega} is in
the range
-@math{-\pi \leq \omega \leq \pi}.
+@math{-\pi < \omega \leq \pi}.
@item @emph{Example}:
@smallexample
2015-06-14 Thomas Koenig
* intrinsic.texi: Change \leq to < in descrition of imaginary
part in argument to log.
*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 ha
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
* gcc-6/changes.html: Doc
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
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 con
all abort
2015-05-03 Thomas Koenig
PR fortran/37131
* gfortran.dg/bound_9.f90: Add pointer assignment.
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
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
PR fortran/37131
* gfortran.h (gfc_isym_id
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
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR
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
PR fortran/66041
* frontend-passes.c (scalarized_expr): Clear as->start, as->end
copies 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
PR fortran/
Hi Mikael,
thanks for the review.
Here is what I committed.
Regards
Thomas
2015-05-10 Thomas Koenig
PR fortran/66041
* frontend-passes.c (scalarized_expr): Set correct dimension and
shape for the expression to be passed to lbound. Remove trailing
vious (since it
fixes the problem and can obviously do no harm), but anyway: OK for
trunk?
Regards
Thomas
2015-05-10 Thomas Koenig
PR fortran/66041
PR fortran/37131
* gfortran.h (gfc_array_spec): Add field resolved.
* array.c (gfc_resolve_array_spec):
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
PR fortran/66111
* frontend-passes.c
Hello world,
this (rather obvious) patch fixes array declarations in deeply nested
BLOCKs.
Regression-tested. OK for trunk?
Thomas
2015-05-16 Thomas Koenig
PR fortran/66113
* expr.c (is_parent_of_current_ns): New function.
(check_restricted): Use it
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
PR fortran/37131
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
PR fortran/66176
* frontend-passes.c (check_conjg_variable): New function
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
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
cr
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
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
t; result for compile-time simplification and run-time
> execution.
>
> OK for trunk?
>
> Thomas
>
> 2014-03-12 Thomas Koenig
>
> PR fortran/59604
> * gfortran.h (gfc_convert_mpz_to_signed): Add prototype.
> * arith.c (gfc_int2i
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 simplif
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
PR fortran/60834
* frontend-passes.c
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
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
PR fortran/60522
* frontend-passes.c (cfe_code): Do not walk sub
about substrings. However, I think this is OK for fixing
a wrong-code bug.
I would downgrade the PR to an enhancement request after commiting this
fix, and look at fixing the substring handling.
OK for trunk? What about the other open branches?
Thomas
2014-12-25 Thomas Koenig
ntend
pass to fix this up.
I would definitely like to see this bug fixed for 5.0. If anybody
has a better idea on how to tackle this in a timely manner, please
let me know.
Otherwise, OK for trunk? What about the other branches?
Regression-tested.
2014-12-29 Thomas Koenig
PR for
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 t
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
ho 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
PR fortran/57023
* dependency.c (callback_dummy_intent_not_int): New fun
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 the regression by converting the arguments
to dot_product to the proper types.
Regression-tested on x86_64-unknown-linux-gnu.
OK for all affected branches (trunk, 4.9 and 4.8)?
Thomas
2014-08-10 Thomas Koenig
PR fortran/61999
Hello world,
the attached patch fixes the regression by making sure we never
try to create a temporary variable from a temporary variable,
which happened in the wrong order.
Regression-tested. OK for trunk and 4.9?
2014-08-19 Thomas Koenig
PR fortran/62106
* gfortran.h
Hello world,
I committed the attached patch as obvious to trunk after regression
testing. It fixes the regression in the test case by adding
a NULL check to a pointer. Will commit to 4.9 soon.
Regards
Thomas
2014-08-15 Thomas Koenig
PR fortran/62142
* trans-expr.c
d. OK for trunk?
Regards
Thomas
2014-08-17 Thomas Koenig
PR fortran/60661
* frontend-passes.c (optimize_forall_header): Add prototype,
new function.
(optimize_code): Call optimize_forall_header.
(concurrent_iterator_check): New function.
?
Regards
Thomas
2014-08-21 Thomas Koenig
PR fortran/62214
* frontend-passes.c (optimize_binop_array_assignment):
Do not try to optimize the array assignment for string
concatenation.
2014-08-21 Thomas Koenig
PR fortran/62214
'm not an experienced C++ programmer, so I would appreciate a quick
look at what I did.
Regression-tested. No test case because there is no new
functionality.
OK for trunk? Any other comments?
Thomas
2014-08-24 Thomas Koenig
* frontend_passes (expr_array): Replace by v
equire vectors, so I think it makes sense to have a consistent
style, in a single file at least :-)
Therefore: OK for trunk?
Thomas
2014-08-24 Thomas Koenig
* frontend_passes (expr_array): Replace by vec template.
(expr_size): Remove.
(expr_coun
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,
.
Regression-tested on trunk. OK for trunk and 4.6? What about 4.5?
Thomas
2011-05-29 Thomas Koenig
PR fortran/45786
* interface.c (gfc_equivalent_op): New function.
(gfc_check_interface): Use gfc_equivalent_op instead
of switch statement
Hi Steve,
On Sun, May 29, 2011 at 04:08:54PM +0200, Thomas Koenig wrote:
Regression-tested on trunk. OK for trunk and 4.6? What about 4.5?
OK for trunk and 4.6. If it applies cleanly to 4.5 and
passes regression testing, then you can also commit to
4.5 at your discretion.
Committed
Hi Steve,
it seems that, with your patch,
interface foo
module procedure::bar
end interface
is rejected, as is
interface foo
module procuedure:: bar
end interface
Is this the way it is supposed to be?
Thomas
Hi Steve,
Oh phew. Good catch. I wasn't dealing with
the possible white space issues. Here's an
updated patch and testcase.
OK for trunk. Could you also add the test case a second time,
without -std=f95, to make sure it keeps passing?
Thanks for the patch!
Thomas
right assignment,
but you might want to consider obtaining one just the same.
Thanks for working on this!
Thomas
2011-06-05 Andreas Schmidt
Thomas Koenig
* dump-parse-tree.c (show_symbol): Don't dump namespace
for ENTRY to avoid infinite recursion.
Index:
Hi Tobias,
The NULL pointer check (-fcheck=pointer) was wrong for Fortran 2008: It
is now allowed to pass a null pointer (or not associated allocatables)
to optional arguments to denote absent arguments.
Build and regtested on x86-64-linux.
OK for the trunk?
OK. Thanks for the patch!
Hello world,
the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?
Thomas
2011-05-06 Thomas König
* frontend-passes.c (optimize_assignment): Follow chains
of concatenation operators to the en
I wrote:
Hello world,
the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?
Thomas
This time with the test case corrected (cleanup of the *.original file)
and a more meaningful Subject line.
OK?
Thomas
2011-
I wrote:
Hello world,
the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?
Thomas
This time with the test case corrected (cleanup of the *.original file)
and a more meaningful Subject line.
OK?
Ping ** 0.5714
Fu
Hi Jerry,
Ping ** 0.5714
Full patch can be found at
http://gcc.gnu.org/ml/fortran/2011-06/msg00053.html
OK and thanks for patch.
Sendingfortran/ChangeLog
Sendingfortran/frontend-passes.c
Sendingtestsuite/ChangeLog
Adding testsuite/gfortran.dg/trim_optimize
2011-06-13 Thomas Koenig
* frontend-passes.c (remove_trim): New function.
(optimize_assignment): Use it.
(optimize_comparison): Likewise. Return correct status
for previous change.
2011-06-13 Thomas Koenig
* gfortran.dg/trim_optimize_8.f90: New
?
Thomas
2011-06-27 Thomas Koenig
PR fortran/49479
* m4/reshape.m4: If source allocation is smaller than one, set it
to one.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c16.c
Hi Jerry,
On 06/27/2011 03:18 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes PR 49479, a regression for 4.7 and 4.6. Test
case was supplied by Joost, the approach to the patch was suggested by
Tobias in comment#4 of the PR. The patch certainly looks safe enough.
Regression
t.
No test cases, as they haven't been found yet :-)
I also noticed two places where we had a memory leak (in eoshift1 and
eoshift3), which I also fixed.
Regression-tested. OK for trunk and, after a few days, for 4.6?
Thomas
2011-06-28 Thomas Koenig
* m4/in_pack.m4 (internal_pa
Hi Janne,
I'd prefer to add the zero check to runtime/memory.c
(internal_malloc_size), i.e. change
if (size == 0)
return NULL;
to
if (size == 0)
size = 1;
Good point. I have done so in the attached patch, plus removed
all special cases for checking for zero size.
Regression-tested.
Am 01.07.2011 14:34, schrieb Janne Blomqvist:
On Thu, Jun 30, 2011 at 21:09, Thomas Koenig wrote:
Good point. I have done so in the attached patch
Seems you forgot to attach it.. ;)
Oops, I hadn't realized your crystal ball was broken :-)
Is this better?
Thomas
2011-
Hi Janne,
Since size_t is unsigned, just test (size == 0). Otherwise Ok. Thanks
for the patch.
OK.
Übertrage Daten ...
Revision 175880 übertragen.
Thanks for the review!
Thomas
=1:2)
tmp = f(i)
a(i) = tmp
end forall
did the Wrong Thing. Oh well...
Regression-tested. OK for tunk?
Thomas
2011-10-09 Thomas Koenig
PR fortran/50564
* frontend-passes (forall_level): New variable.
(cfe_register_funcs): Don't register functions
geLog
===
--- fortran/ChangeLog (revision 179768)
+++ fortran/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2011-10-10 Thomas Koenig
+
+ PR fortran/50564
+ * frontend-passes (forall_level): New variable.
+ (cfe_register_funcs): Don't register functions if we
+ are within a f
Hello world,
here is a fix for PR 50690, pretty self-explanatory. Regression-tested.
OK for trunk?
Thomas
2011-10-15 Thomas Koenig
PR fortran/50690
* frontend-passes.c (omp_level): New variable.
(create_var): If we are within an OMP block, put
Am 15.10.2011 13:36, schrieb Jakub Jelinek:
This looks wrong. Threadprivate variables aren't completely cheap,
much better would be an automatic variable instead.
As Fortran FE IL doesn't have block local variables, I guess you want
to create the var at function scope and add a private(that_tem
301 - 400 of 1274 matches
Mail list logo
