Hi,
this is a heads-up that configuring with --enable-maintainer-mode
currently breaks bootstrap; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
for details.
Running configure with --enable-maintainer-mode --disable-werror
allows bootstrap to proceed until the underlying issue is fixed
Hi Janus,
The cleaner approach would certainly be to avoid short-circuiting of
impure functions altogether. If we can all agree that this is a good
idea,
This is a fine example of logical short-circuiting - the condition you
mention is false, therefore the rest need not be evaluated :-)
argument spec from ".X" to ".w".
(gfc_trans_wait): Pass ID argument via reference.
2018-07-15 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* gfortran.dg/f2003_inquire_1.f03: Add write statement.
* gfortran.dg/f2003_io_1.f03: Add wait st
Hi Rainer,
I've now regtested the patch on i386-pc-solaris2.11 and
sparc-sun-solaris2.11: no regressions and the new tests all PASS.
Thanks, that is good news!
However, I still don't understand why you insist on the hack with
putting the async_io_*.f90 tests into the libgomp testsuite. Why
Am 15.07.2018 um 19:47 schrieb Rainer Orth:
Because this does not appear to work with Linux. I, like
most gfortran developers, work on Linux, and I would like to
catch any failure during regression-testing on my own system,
if possible.
huh, what doesn't work? I've just finished an x86_64-pc-li
Hi Janus,
I tested it on a fairly large code base and found no further false
positives. Also it still regtests cleanly. Ok for trunk?
while I still disagree with this on principle, I will not stand
in the way.
However, one point: I think that the warning should be under a separate
warning, wh
Am 16.07.2018 um 10:06 schrieb Janus Weil:
However, one point: I think that the warning should be under a separate
warning, which should then be enabled by -Wextra.
-Waggressive-function-elimination, could be reused for this,
or something else
I don't actually see such a flag in the manual.
Ah
Hi Kyrill,
The current implementation expands to:
mvar = a1;
if (a2 .op. mvar || isnan (mvar))
mvar = a2;
if (a3 .op. mvar || isnan (mvar))
mvar = a3;
...
return mvar;
That is, if one of the operands is a NaN it will return the other argument.
If both (all
Am 17.07.2018 um 19:19 schrieb Janus Weil:
2018-07-17 17:18 GMT+02:00 Fritz Reese :
2018-07-17 9:52 GMT+02:00 Janus Weil :
In other words: Does it make sense to tone down
-Wfunction-elimination, by only warning about impure functions?
Here is an update of the patch which does that. Regtesting
Hi Kyrill,
Because the expansion now emits straightline code rather than
conditionals and branches
it should be easier to optimise in general, so I'd expect this to be an
improvement overall.
That said, I have benchmarked it on SPEC2017 on aarch64.
If you have any benchmarks of interest to y
hours or so? If so, I would like to commit this. Otherwise, Nicolas
and I will not be able to fix this for a week or so, and it would be
best to revert the async I/O patch :-(
Regards
Thomas
2018-07-25 Thomas Koenig
* io/async.h: Test for feature macros for __gthread_cond_t and
Am 26.07.2018 um 22:54 schrieb Thomas Koenig:
Hi Ulrich,
The problem is that io/asynch.h unconditionally uses a couple of
features that are not provided by gthr-simplex, in particular
__gthread_cond_t
and
__gthread_equal / __gthread_self
According to the documentation in gthr.h, the
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 sa
However, passing a scalar instead of an array/array
element worked/works with (nearly?) all compilers. Hence, passing
a scalar is seemingly common pattern. Thus, I wonder whether we
should do something about this.
Maybe we could mention -fallow-argument-mismatch in the error message.
(Reall
Hi Tobias,
OK for the trunk and GCC 9?
As far as I can see, this looks good.
So, OK for trunk. If it later turns out that there are problems
caused by this, I suspect we will hear about them soon enough :-)
Thanks for taking this on!
Regards
Thomas
h -O2 there.
OK for trunk/9/8?
Regards
Thomas
2019-11-02 Thomas Koenig
PR fortran/92133
* trans-decl.c (gfc_get_symbol_decl): If __def_init actually
contains a value, put it into the read-only section.
Index: trans-d
Hi Steve,
OK for trunk/9/8?
OK for all three.
Thanks, committed to trunk as r277760.
I'll be AFK for a few days, so I will have to wait before
committing this to gcc-9. Given the convoluted history of
this bug, this might not be a bad thing.
> It is, as you have indicated, troublesome that
Hi,
I just committed the patch below as obvious to fix a 9/10 regression
when directly calling BLAS routines for matmul. Will backport
to gcc-9 soon.
Regards
Thomas
Commit symbol for external BLAS routine when translating MATMUL to *GEMM.
2019-11-09 Thomas Koenig
PR
Hi Janne,
Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
requirement one can still build GCC with the operating system provided
MPFR on old but still supported operating systems like SLES 12 (MPFR
3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
OK for trunk.
Can you also make
Am 11.11.19 um 22:55 schrieb Thomas König:
Regression-tested. OK for trunk?
Of course, better with a ChangeLog entry.
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping
Hi Tobias,
I am not completely happy about the introduction of yet another two
global variables, but I also do not see an easy way out. Hence: OK.
Actually, I wasn't too happy myself, but, like you, I didn't find
anything better.
I was playing around with the following test case – you might c
Hello world,
here is my first patch made from the git world. It certainly took
enough time to work out how to to this, but I think I have it
figured out now...
Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue th
Am 17.01.20 um 15:42 schrieb Steve Kargl:
Gfortran probably should not try to guess what the user
thought s/he wanted. The generic "Syntax error" would
seem to apply here. To me, foo(1)%a looks much more like
an array reference rather than a function reference.
OK, so here's a patch which doe
Am 18.01.20 um 12:44 schrieb Tobias Burnus:
function_reference_1.f90:9:8:
9 | print *, foo(1)%a ! { dg-error "Syntax error" }
| 1
Error: Syntax error in expression at (1)
The error message is not helpful at all.
Well, yes. It is no better than what we currently have for the
Hello world,
I found an ommission in primary.c which prevented issuing a
more specific error instead of "syntax error" for the case
when a function was declared in an EXTERNAL statement,
and I have now gone for the "Unexpected junk after foo"
variant.
Regression-tested. OK for trunk?
Regards
Hi Janne,
Simplify IO locking in libgfortran. The new IO implementation avoids
accessing units without locks, as seen in PR 92836. It also avoids
lock inversion (except for a corner case wrt namelist query when
reading from stdin and outputting to stdout), making it easier to
verify correctnes
Hi Tobias,
OK? – And for which branches?
OK for all branches (assuming you checked with "make pdf" and
"make dvi").
Thanks for doing this - our documentation is not always quite
up to date...
Regards
Thomas
it off on a by-file basis if they
don't want it.
OK for trunk?
Regards
Thomas
Introduce -finline-pack.
2019-12-07 Thomas Koenig
PR middle-end/91512
PR fortran/92738
* invoke.texi: Document -finline-pack.
* lang.opt: Add -finline
Koenig
PR fortran/92755
* dependency.c (gfc_dep_resolver): Move skipping of _data ref
into the loop.
2019-12-08 Thomas Koenig
PR fortran/92755
* gfortran.dg/dependency_57.f90: New test.
Index: dependency.c
12-08 Thomas Koenig
PR fortran/92764
* interface.c (gfc_procedure_use): Check for existence of derived
component before using (twice).
2018-12-08 Thomas Koenig
PR fortran/92764
* gfortran.dg/interface_44.f90: New test.
Index: interf
Hi Richard,
Just as a suggestion, maybe we'd want to extend this
to other intrinsics in future so a -fno-inline-intrinsic=pack[,...]
is more future proof? (I'd inline all intrinsics by default thus
only provide the negative form). You can avoid the extra
option parsing complexity by only litera
ough
to cure the ICE.
Regards
Thomas
2019-12-10 Thomas Koenig
PR fortran/92863
* misc.c (gfc_typename): If derived component is NULL for
derived or class, return "invalid type" or "invalid class",
respectively.
2019-12-10 T
Am 09.12.19 um 17:30 schrieb Thomas Koenig:
Maybe -finline-repack would be a better name? -finline-internal-pack?
Steve made an excellent suggestion: -finline-arg-packing .
So, OK with that change?
Regards
Thomas
Hello world,
this fixes a regression introduced by my inline repacking patch.
With the test case, it is simple and obvious enough - do not repack
an assumed rank argument (which makes no sense).
Committed as obvious and simple as r279203 after regression-testing.
2019-12-10 Thomas Koenig
Hello Harald,
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 279183)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -7154,7 +7154,9 @@ bool
gfc_check_is_contiguous (gfc_expr *array)
{
if (array->expr_type == EXP
Am 10.12.19 um 22:22 schrieb Thomas Koenig:
Steve made an excellent suggestion: -finline-arg-packing .
So, OK with that change?
In other words, is
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
OK with renaming the option to -finline-arg-packing ?
Regards
Thomas
Hi Paul,
Regtested on FC31/x86_64 - OK for 9- and 10- branches?
OK. Thanks for the patch!
Regards
Thomas
, but for this bug fix, I
left the functionality as is).
Regression-tested. OK for trunk?
Regards
Thomas
2019-12-19 Thomas Koenig
PR fortran/91541
* intrinsic.c (add_sym_4ind): New function.
(add_functions): Use it for INDEX.
(resolve_intrinsic): Also
Hi Tobias,
One has the choice between
(a) Using the location where the expression was defined (in the
scoping unit) – currently done
(i.e. replacing expr->where by expr->symtree->n.sym->where)
(b) using the location where the parameter is used, i.e. keeping
expr->where despite sim
patch. Rather than try to transport state across I
do not know how many levels of calls, I chose a global variable.
Regression-tested. OK for all affected branches?
Regards
Thomas
2019-12-20 Thomas Koenig
PR fortran/92961
* gfortran.h (gfc_seen_div0): Add declaration
Hi, I just saw this:
FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple
"(?n)#pragma omp target oacc_enter_exit_data
map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\)
map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\)
map\\(alloc:del_f_p\\.data \\[pointe
the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.
Actually, it does not fix all testcases in the PR, so some more
tweaking is still needed.
Regards
Thomas
Hi Jakub,
This patch broke:
+FAIL: compiler driver --help=fortran option(s): "^ +-.*[^:.]\$" absent from output:
" -finline-arg-packingPerform argument packing inline"
That test verifies that the help texts of all options are terminated
with dot or semicolon.
Thanks, and sorry for th
Am 20.12.19 um 22:33 schrieb Harald Anlauf:
The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message. The patch below rectifies that.
OK for trunk?
OK.
Thanks for the patch!
Regards
Thomas
for array spec and a division of zero error has been
seen, return MATCH_ERROR.
2019-12-22 Thomas Koenig
PR fortran/92961
* gfortran.dg/arith_divide_2.f90: New test.
Index: gfortran.h
===
--- gfortran.h
Hi Tobias,
Build on x86-64-gnu-linux without offloading and with nvptx offloading.
OK for the trunk?
I can't really say a lot about OpenACC, but the changes do look
reasonable.
So, OK for trunk.
Regards
Thomas
Am 22.12.19 um 16:28 schrieb Thomas Koenig:
here is an update for the fix for PR 92961, which also takes care
of the second test case in the PR (included in the first one).
The patch itself should be clear enough - make sure that there
is a MATCH_ERROR on matching an array spec which contains
Am 19.12.19 um 08:23 schrieb Thomas Koenig:
Regression-tested. OK for trunk?
Ping?
Hi Jerry,
OK for trunk?
Looks good. I also think that your approach that DEC stuff should
be checked later is good. If it passes the testsuite, that's good
enough for a commit.
Thanks for the patch!
Regards
Thomas
.
2020-01-01 Thomas Koenig
PR fortran/93113
* dependency.c (gfc_dep_resolver): Handle REF_INQUIRY in switch
for ref types.
2020-01-01 Thomas Koenig
PR fortran/93113
* gfortran.dg/dependency_58.f90: New test.
Index: dependency.c
, and
the type has not been set some other way.
Regression-tested. OK for trunk?
Regards
Thomas
Save typespec for empty array constructor.
2020-01-02 Thomas Koenig
PR fortran/65428
* array.c (empty_constructor): New variable.
(empty_ts): New var
Hi Tobias,
Build on x86-64-gnu-linux. OK for the trunk?
Looks good.
Thanks for the patch!
Regards
Thomas
Hi Tobias,
PS: I lost a bit the overview. Is there any patch pending review or
otherwise pending?
From my side, there is the patch for PR 65428,
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00040.html
Apart from that, I don't see any outstanding patches.
Regards
Thomas
Am 02.01.20 um 23:35 schrieb Thomas Koenig:
Hello world,
the attached patch fixes an ICE where an array constructor
containing an empty array constructor with a type didn't
get the type from the inner constructor.
The solution is to stash the type away in yet another variable
and only u
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
wordin
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 4b83037a..d232f
Am 08.08.24 um 11:09 schrieb Mikael Morin:
As we are not planning to remove the library implementation (-Os!),
this is also the best way to compare library to inline code.
This makes perfect sense, but why reuse the -ffrontend-optimize option?
The manual describes it as:
This option performs f
Hi Andre,
attached patch fixes a regression introduced by my previous patch on handling
_vptr's more consistently. The patch gets the _vptr only of a derived or
class type now and not of every type.
Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
OK (and looks obviou
Steve,
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
this version of the patch includes DOT_PRODUCT, MATMUL and quite
a few improvements for simplification.
Thomas,
Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
Hi Mikael,
+ gcc_assert (backexpr->expr_type == EXPR_VARIABLE);
drop it, downgrade to checking, or is it worth?
Whether it is worth it, I don't know; it's protecting the access to
backexpr->symtree a few lines down, idependently of the implementation
of maybe_absent_optional_variable.
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case for rank-1 before your patch).
The original idea was to have -ffrontend-optimize as a check if anything
went wrong wi
Ping (a little bit)?
With another weekend coming up, I would have some time to
work on incorporating any feedback, or on putting in
more intrinsics.
Best regards
Thomas
Am 06.09.24 um 20:15 schrieb Steve Kargl:
+Generally, unsigned integers are only permitted as data in intrinsics.
Does the word 'intrinsics' apply to 'intrinsic operators'
or 'intrinsic subprograms' or both? This might benefit from
a big of wordiness.
You're right, that wasn't clear at all.
Am 06.09.24 um 20:58 schrieb Steve Kargl:
Your testcases are all free source form. In fixed
form, gfortran would need to deal with 'u = 1 2 3 4 u _8'
I don't have the patch in my tree at the moment,
it isn't clear to me if the matcher for an unsigned
constant is prepared to deal with space betwe
Hello world,
like the subject says. The patch is gzipped because it is large;
it contains multiple MATMUL library implementations.
OK for trunk?
Implement MATMUL and DOT_PRODUCT for unsgigned.
gcc/fortran/ChangeLog:
* arith.cc (gfc_arith_uminus): Fix warning.
(gfc_arith_minus)
Am 09.09.24 um 09:19 schrieb Richard Biener:
Is the library implementation in any way different from the signed
one? Iff only
multiplication and addition/subtraction are involved the unsigned implementation
could implement both variants (the signed one would eventually cause
undefinedness
with r
Am 09.09.24 um 20:01 schrieb Richard Biener:
But it will require some ugly m4 hackery... I'll take a look if
I can make it work.
> I meant you shouldn’t need new library entry points for unsigned
> but simply call the signed ones (and switch the signed implementation
> to use unsigned arithmet
Hello world,
I just pushed Steve's patch for module support to trunk as obvious, as
https://gcc.gnu.org/g:2847a541c1f19b67ae84be8d0f6dc8e1f9371d16 .
Best regards
Thomas
gcc/fortran/ChangeLog:
* module.cc (bt_types): Add BT_UNSIGNED.
gcc/testsuite/ChangeLog:
* gfortra
Author: Thomas Koenig
Date: Fri Sep 13 07:47:24 2024 +0200
Fix endianness issue on unsigned_21.f90.
gcc/testsuite/ChangeLog:
PR fortran/116653
* gfortran.dg/unsigned_21.f90:
* gfortran.dg/unsigned_21_be.f90: New test.
diff --git a/gcc/testsuite
Hello world,
this implements SUM and PRODUCT for UNSIGNED. This is actually
missing from 24-116.txt, but that is due to an oversight.
This patch is on top of
https://gcc.gnu.org/pipermail/fortran/2024-September/060975.html
and uses the same method suggested by Richard: Use unsigned for the
dat
As Jerry wrote (thanks!), this was missing the attached patch.
Best regards
Thomasdiff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 829ab00c665..e5ffe67 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2788,7 +2788,7 @@ As of now, the
Hi Mikael,
> Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8?
OK for both. Thanks for the patch!
Thomas
Hello world,
the attached patch avoids checks for reallocation on assignment when
the same variable is on both sides of the assignment.
Regression-tested. OK for trunk?
Thomas
2013-08-29 Thomas Koenig
PR fortran/52243
* trans-expr.c (is_runtime_conformable): New
Hello world,
the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
within DO CONCURRENT.
Regression-tested. OK for trunk?
Regards
Thomas
2013-08-29 Thomas Koenig
PR fortran/PR56519
* gfortran.h: Declare gfc_do_concurrent_flag as extern
Hello world,
the attached patch documents the format for unformatted sequential
files and what is, and is not, supported with special files.
Tested with "make dvi" and "make info". OK for trunk?
Thomas
2013-08-30 Thomas Koenig
PR fortran/30162
.
> - Special files which are special in other ways. E.g. block special
> files tend to allow seeking, but IO must be block aligned.
Also listed as not supported; I suspect buffering could cause grief
there.
I have updated an attached patch. OK?
Thomas
2013-08-30 Thomas
Ping**0.5714 ?
> the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
> within DO CONCURRENT.
>
> Regression-tested. OK for trunk?
Hello world,
here is a rewrite, which I hope make things more clear.
Unformatted sequential files are now made up of subrecords, where
a logical record may only have one.
Regarding block devices: I don't know anybody who ever used them
from gfortran, so I tried to be as vague as possible.
Any mo
Hi Tobias,
the patch is OK, also for 4.8. Thanks a lot for fixing this.
Just a couple of nits:
- You may want to remove the output from the test case.
- The two consecutive ifs in
>
> if (left != 0B)
> {
> if (_F.DA0 != 0B) goto L.2;
> _F.DA0 = (struct paren
Hi Tobias,
> As testing showed, it didn't fix the real-world code: ForTrilinos's
> ForTrilinos_ADT_3D_Burgers_6th_Pade did still fail as it has:
>
> *_F.DA65 = matrix_diff_x (&parm.621);
>_F.DA66 = ax->epetra_rowmatrix.universal; // Deref of "ax"!
>
> Build and regtested on x86
Hi Tobias,
> * PING * http://gcc.gnu.org/ml/fortran/2013-09/msg00039.html
>
> Additionally pinging for:
> http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html
Both are OK.
Thanks a lot for the patches!
Thomas
I wrote:
the attatched patch (this time for real!) implements
-Wextra for the Fortran front end, and adds -fcompare-reals
to -Wextra.
Ping?
Hi Janus,
I'm not much of a libgfortran or I/O expert, but after all this looks
ok to me. Thanks for the patch!
Committed, thanks. What to people think about backporting to 4.7?
It is a wrong-code issue, if a rather obscure corner.
If there's no feedback within a few days, I think I'll close
Hello world,
the attached patch fixes the PR. The logic for processing
GFORTRAN_CONVERT_UNIT had been quite wrong. I have checked
that the original test case, plus a few more, no longer cause
assertion failures or memory corruption (also checked with
valgrind). No test case because it is not p
Hi Janus,
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
This looks all right to me (although I'm not really an expert :-)
OK, and thanks for the patch!
Thomas
Hello world,
the previous version of the patch has an issue that Shane pointed
out in the PR. This version should work; at least it survived
all the test cases I could come up with.
Regression-tested (again). OK for trunk? Also for 4.6 and 4.7?
Thomas
2012-10-01 Thomas König
Hello world,
the attached patch removes wrapping calls to free(a) by
if (a != NULL) for some cases. It is not complete, because
automatic deallocation of allocatable structure components
is not yet covered.
OK for trunk?
Thomas
2012-10-06 Thomas König
PR fortran/54833
I wrote:
the attached patch removes wrapping calls to free(a) by
if (a != NULL) for some cases. It is not complete, because
automatic deallocation of allocatable structure components
is not yet covered.
I accidentally posted an old version, which had a bug in
coarrays (basically was just miss
Am 01.10.2012 20:34, schrieb Thomas Koenig:
Hello world,
the previous version of the patch has an issue that Shane pointed
out in the PR. This version should work; at least it survived
all the test cases I could come up with.
Regression-tested (again). OK for trunk? Also for 4.6 and 4.7
Hi Steven,
Ping?
I would like to start committing patches so I don't have too many
of them in my tree at the same time :-)
This looks OK to me.
Committed as rev. 192158. I'll commit to 4.7 and after that to 4.6
in a few days.
Thanks a lot for the review!
Thomas
Hi Janus,
ping!
2012/10/7 Janus Weil :
Hi all,
here is a rather straightforward patch, which does 'recursive'
checking of dummy procedures.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
This is OK. Thanks for the patch!
Thomas
Here is the patch as I committed it.
Thanks a lot for your review!
Now we can start thinking if we want to add other flags to
-Wextra.
Regards
Thomas
012-10-21 Thomas Koenig
PR fortran/54465
* lang.opt (Wextra): Add.
* invoke.texi: Document that -Wc-bi
Hello world,
I have committed the attached patch as obvious after checking
with "tidy".
Best regards
Thomas
2012-10-21 Thomas Koenig
* gcc-4.8/changes.html: Document that -Wc-binding-type
is enabled by -Wall. Document that -Wcompare-reals is
Am 27.10.2012 01:41, schrieb Andreas Schwab:
Thomas Koenig writes:
Index: trans.c
===
--- trans.c (revision 192638)
+++ trans.c (working copy)
@@ -814,26 +814,23 @@ gfc_allocate_allocatable (stmtblock_t * block, tre
Hi Andreas,
Thomas Koenig writes:
PR fortran/54833
* trans.c (gfc_call_free): Do not wrap the
call to __builtin_free in check for NULL.
(gfc_deallocate_with_status): For automatic deallocation without
status for non-coarrays, don't wrap ca
Hi Tobias,
* ping *
On 16.10.2012 23:18, Tobias Burnus wrote:
In the Bessel-function algorithm, there was the useless code:
ret->base_addr = ret->base_addr;
The patch is OK. Thanks a lot!
Thomas
Hi Tobias,
* ping *
This is OK. Thanks for the patch!
Thomas
Hello world,
the attached patch, which is not in its final stage, implements some
warnings for index variables of DO loops. For the following situations,
errors/warnings are issued when an index loop variable is
passed as an actual argument:
- If the dummy argument has INTENT(OUT). I think an er
Hi Toon,
However, today I *did* run the test harness with your modification:
...
Thanks for the testing!
So, what do people think? Is the patch OK for trunk?
Regards
Thomas
Hi Jerry,
The attached patch with new test cases fixes these by replacing gcc_assert and
updating the error message depending on whether resolving an initialization
expression or not.
Regression tested on x86-64.
OK for trunk?
OK.
Thanks for the patch!
Thomas
1 - 100 of 1494 matches
Mail list logo
