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
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
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 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-&
ch as obvious and simple,
r271630.
Regards
Thomas
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-types.c (get_formal_from_actual_arglist): Set rank
and lower bound for assumed size arguments.
Index: trans-ty
o see how performance is with
this version).
OK for trunk?
Regards
Thomas
2019-05-29 Thomas Koenig
PR fortran/90539
* gfortran.h (gfc_has_dimen_vector_ref): Add prototype.
* trans.h (gfc_conv_subref_array_arg): Add argument check_conti
Hi Jakub,
As I said earlier in the PR, I don't like -fbroken-callers option much,
as the option name doesn't hint what it is doing at all.
The following patch renames the option and makes it into a 3 state option,
with the default being a middle-ground, where it avoids the tail calls in
functio
quot;.
OK for trunk?
Regards
Thomas
2019-05-30 Thomas Koenig
* gfc-internals.texi (Translating to GENERIC): New chapter.
Index: gfc-internals.texi
===
--- gfc-internals.texi (Revision 271629)
+++ gfc-internals
Hi Steve,
Thomas, with the above fixes, I think this a great
addition to manual. OK to commit.
Committed with your fixes (sometimes I think my fingers
are going blind :-) as r271786.
Best regards
Thomas
call foo(a,b,size(a))
end subroutine bar
end module y
Test case is only for the first part - making one for the second
part would have been a bit too much.
Regression-tested. OK for trunk?
Regards
Thomas
2019-06-02 Thomas Koenig
PR fortran/90539
* trans-expr.c
ion of the
patch was done by Tomáš Trnka (thanks!).
I will also backport, since this is a 7/8/9/10 regression.
Regards
Thomas
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90744
* trans-types.c (get_formal_from_actual_arglist): Unset typespec
flags whi
Hi Paul,
I cannot see anything wrong with the optimized code and valgrind gives
a clean bill of health on x86_64.
We need help of somebody with access to an arm/aarch64 device.
I'm currently running a bootstrap on an aarch64 machine. These
are not known to be the fastest of machines, but it
Hi,
I just committed the attached patch as obvious ans simple. No impact
on user code, just to make internal debugging easier.
Regards
Thomas
2019-06-16 Thomas Koenig
* dump_parse_tree (debug): Add verison for formal arglist.
Do not crash when a gfc_expr is NULL
Am 20.06.19 um 11:07 schrieb Martin Liška:
On the contrary, decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error
Sogenerating object files on one system and trying to read them
on another system which does not happen to have a particular
li
.
Regards
Thomas
2019-06-20 Thomas Koenig
PR fortran/90937
* trans-types.c (get_formal_from_actual_arglist): Get symbol from
current namespace so it will be freed later. If symbol is of type
character, get an empty character length.
2019-06-20 Thomas Koenig
Hi Martin,
LTO bytecode is not supposed to be a distributable format.
One of my dreams is to make libgfortran LTO-clean. There is
a lot of performance to be gained both in I/O (where a huge
number of special cases could be shortcut by LTO, because
hardly any program uses them all) and in arra
Hi Steve,
PR fortran/88139
* dump-parse-tree.c (write_proc): Alternate return.
I dissent with this patch. The introduced error is meaningless and, as
mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree
is not directly the issue. The code should be rejected in
Hello world,
the attached patch fixes the wrong-code regression by changing the
way synchronous writes are handled on files using asynchronous I/O:
The are now handled synchronously.
This also means that two places where a wait instruction was
issued in such a case are no longer needed.
I tried
- see PR 41453.
Regards
Thomas
2018-12-16 Thomas Koenig
PF fortran/88364
* trans-expr.c (gfc_conv_expr_reference): Do not add clobber if
the expression contains a reference.
2018-12-16 Thomas Koenig
PR fortran/88364
* intent_out_13.f90
Thomas Koenig
PR fortran/85544
* frontend-passes.c (optimize_power): Remove.
(optimize_op): Remove call to optimize_power.
* trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer,
(2|4|8|16) ** integer and (-1) ** integer.
2018-12-16 Thomas Koenig
Hi Steve,
The attach patch shuffles lines around to eliminate 80
lines of #ifdef...#endif; thereby making the file more
readable. Tested on i586-*-freebsd and x86_64-*-freebsd.
Patch is a pre-requisite to fixing issues and adding
missing functionality. OK to commit?
2018-12-18 Steven G. Karg
Hi Steve,
No, I'm adding the missing functions to the INTERFACE.
Ah, I see. What I missed was that the function is actually translated
to something else.
So, OK for trunk, and thanks for the patch!
Regards
Thomas
Ping?
the PR pointed out an old regression because the front-end optimization
pass was substituting 2**n with ishift(1,n), where n was an array.
Simply removing the optimization for that case would have been easy,
but also introduced a performance regression.
So, for this, I moved the optimiza
Hi Steve,
The attached patch addresses an issue submitted by Neil
Carlson. He and I have an exchange in the PR's audit
trail hashing out the validity of his code example. I
also asked on the J3 mailing about the his code. It seems
that language of the Fortran standard may have been
misinterpr
truncated strings in constructors.
Regression-tested. OK for trunk?
Regards
Thomas
2019-01-01 Thomas Koenig
PR fortran/82743
* primary.c (gfc_convert_to_structure_constructor): If a character
in a constructor is too long, add a warning with
-Wcharacter
Hi Steve,
Due to the nuances of issuing error messages with ieee_selected_real_kind
when used in an initialization expression, it became painfully obvious
that gfortran will often issue an "Unclassifiable statement" error
as a run-on error. I tried to make the "Unclassifiable ..." error a
fatal
.
Regression-tested. OK for trunk?
Regards
Thomas
2019-01-02 Thomas Koenig
PR fortran/88658
* gfortran.h: Add macro gfc_real_4_kind
* simplify.c (simplify_min_max): Special case for the types of
AMAX0, AMIN0, MAX1 and MIN1, which actually change the types of
Hell world,
somebody fixed PR 48543 for us, so I have committed the
attached test case as obvious and closed the PR. Thanks
to however did this!
Regards
Thomas
2019-01-02 Thomas Koenig
PR fortran/48543
* gfortran.dg/const_chararacter_merge.f90: New test.
! { dg-do
Hi Jakub,
In any case, IMHO the test should be removed or XFAILed for now.
thanks for your explanations. I have removed the test case.
Regards
Thomas
Am 03.01.19 um 23:18 schrieb Jakub Jelinek:
On Thu, Jan 03, 2019 at 01:36:30PM +0100, Thomas Koenig wrote:
Hi Jakub,
In any case, IMHO the test should be removed or XFAILed for now.
thanks for your explanations. I have removed the test case.
You've actually removed a different tes
Hi Steve,
thanks for taking this on!
Maybe it would be better to put the checking and argument reordering
into its own routine (something like gfc_check_minloc_maxloc in
check.c) so all three arguments would be present, with an
expression possibly containing NULL, for the later routines.
This co
Hi Janus,
the attached patch fixes PR 88009, an ICE-on-invalid regression caused
by one of my earlier commits. Apart from adding some extra checks to
avoid ICEs, it also uses the 'artificial' attribute to suppress bogus
errors (see comment #3) and does some minor cleanup in
resolve_fl_variable.
Am 02.01.19 um 15:31 schrieb Thomas Koenig:
Hello world,
the attached patch fixes the PR, a regression introduced by r265649,
by special-casing those intrinsics of the min/max family which
need to be special-cased.
This is actually something that had been fixed before (PR 14377),
but at the
also use the gfc_is_not_contiguous to reject
obvious errors when assigning to contiguous pointers or
arguments.
Regression-tested on x86_64-pc-linux-gnu. OK for trunk?
Regards
Thomas
2019-01-06 Thomas Koenig
Harald Anlauf
Tobias Burnus
PR fortran/45424
, I checked for the names of the variables which used to
be introduced by the matmul inlining code.
Regression-tested. OK for trunk?
Regards
Thomas
2019-07-25 Thomas Koenig
PR fortran/65819
* dependency.h (gfc_dep_resovler): Add optional argument identical
Hi Steve,
-int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *);
+int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool identical =
false);
This is changing the prototype. I would expect to see
int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool);
Usig C++'s optio
Hi Steve,
Ah, I don't speak C++, and didn't know one could corrupt a
C prototype in this manner. A quick glance of gfortran.h
indeed shows a few more occurences of "bool xxx = false".
I suppose the patch is then OK.
I don't use many C++ features, but I use this one because I feel
it should re
.
OK for trunk?
Regards
Thomas
2019-07-28 Thomas Koenig
PR fortran/90813
* dump-parse-tree.c (show_global_symbol): New function.
(gfc_dump_global_symbols): New function.
* gfortran.h (gfc_traverse_gsymbol): Add prototype.
(gfc_dump_
Hi Paul,
That is very well done. Thanks for picking it up and running with it.
OK on both the fix and the dumping of the gsymbols.
Committed, thanks.
You might consider back porting both this patch and my fix for the
original bug to 9-branch.
Both patches apply cleanly together on gcc-9 (w
Hi Steve,
The attach patch has been regression tested on x86_64-*-freebsd.
There were no regression.
The patch prevents an ICE when checking for aliasing and the
actual arguments are the real and imaginary parts of a complex
entity. See the testcase for more information.
OK to commit to both
Hi Steve,
OK to commit?
OK with
%s/rational/relational/g
and with Mark's nit.
Thanks a lot for going down that road. I like the approach of
-fallow-invalid-boz to downgrade the error to a warning, which
then cannot be turned off.
Regards
Thomas
-tested. OK for trunk? I also think that this is something
that could be safely backported to gcc-9.
2019-08-12 Thomas Koenig
PR fortran/91424
* frontend-passes.c (do_subscript): Do not warn for an
expression a second time. Do not warn about a zero-trip loop
Hi Steve,
Ok. If it regression cleanly on gcc9, go ahead an commit there as well.
Committed to both (after doing a regression test on gcc 9 and also
waiting for gcc-testresults containing the revision).
Thanks for the review!
branches.
Regards
Thomas
2013-08-13 Thomas Koenig
PR fortran/90563
* frontend-passes.c (insert_index): Suppress errors while
simplifying the resulting expression.
2013-08-13 Thomas Koenig
PR fortran/90563
* gfortran.dg/do_subsript_5.f90
19-08-15 Thomas Koenig
PR fortran/91443
* frontend-passes.c (check_externals_expr): New function.
(check_externals_code): New function.
(gfc_check_externals): New function.
* gfortran.h (debug): Add prototypes for gfc_symbol * and
gfc
Hi Janne,
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
project?
This is a single pass over the code, so O(N) for the code size.
The lookup
I wrote:
Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom at one time. And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you
Am 20.08.19 um 22:32 schrieb Thomas König:
here is the next installment of checking for mismatched calls,
this time for mismatching CALLs.
The reorganization of the code also means that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519 (a rejects-valid
regression) is fixed by this patch.
So,
"make pdf".
OK for trunk?
Regads
Thomas
2019-08-25 Thomas Koenig
PR fortran/91390
PR fortran/91473
* frontend-passes.c (gfc_check_externals): Make
gfc_errors_to_warnings conditional on -fallow-argument-mismatch.
* invoke.texi: Docum
ranches.
After this, I think we can close PR 91556. Regression-tested. OK for
trunk?
2019-09-13 Thomas Koenig
PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead
Hello world,
the attached patch fixes an ICE on invalid, where the fact that
the step in do i = 1, 3, .1 is actually zero slipped through.
Regression-tested. OK for all affected branches (trunk, 9 and 8)?
Regards
Thomas
2019-09-15 Thomas Koenig
PR fortran/91550
Hi Steve,
s/previusly/previously
Fixed, committed. Thanks for the review!
Do you it gfortran should skip the front-end optimization pass
if error(s) have already been reported? On entry ito this pass,
you could test for the error count and simply return.
I thought about this for doing thi
Hi David,
I think technically I can self-approve this, but I'm not a
day-to-day user of fortran; does this look sane?
Very much so, I also find this more readable.
I'd wait another day or so for comitting this, so that other people
with different aesthetic sense can also chime in if they want
Hi Tobias,
Build and regtested on x86-64-linux.
OK for the trunk and - after a grace time - for GCC 6, 7 and 8?
Thanks for taking this on so quickly! I don't think that this will
result in any missed optimizations.
Ok.
Thomas
Hi Paul,
Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
Looks good. Thanks!
Regards
Thomas
Hi Paul,
2018-10-18 Paul Thomas
PR fortran/85603
* frontend-passes.c (get_len_call): New function to generate a
call to intrinsic LEN.
(create_var): Use this to make length expressions for variable
rhs string lengths.
Clean up some white space issues.
2018-10-
Hi,
again rejected due to being overly large...
The whole message can be found at
https://gcc.gnu.org/ml/fortran/2018-10/msg00102.html
Weitergeleitete Nachricht
Betreff: [patch, fortran] Implement FINDLOC
Datum: Sun, 21 Oct 2018 19:36:35 +0200
Von: Thomas Koenig
An: fort
Hi Dominique,
With your patch, compiling the following test
program logtest3
implicit none
logical :: x = .true.
integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, &
back=x)
end program logtest3
gives an ICE
I sometimes wonder where you get all these test cases fro
Am 23.10.18 um 18:16 schrieb Dominique d'Humières:
Anyway, the attached patch fixes this,
It now gives the error
4 |integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, &
|1
Error: transformational intrinsic 'findloc' at (1)
confusing error message. This tries to make sure
people don't mistake this for their own error.
Committed as obvious, r265559. No test case because... well, this
is not supposed to happen in the first place.
Regards
Thomas
2018-10-27 Thomas Koenig
PR fortran/
Am 23.10.18 um 23:02 schrieb Thomas Koenig:
So, I think this should be clear for trunk now. I will supply
the documentation later.
Ping ** 0.571428 ?
Hi Paul,
The patch is ready to go. Please correct the following tiny nits:
I have corrected those.
s/Check that en expression/Check that an expression/
s/Set this if resolution has already happened and it could be
harmful/Set this if resolution has already happened. It could be
harmful/
Hi Paul,
inq would be easier to understand and unambiguous imho.
Why? inquiry_type seems fine to me.
I think Bernhard means the name of the member, i.
I think it makes sense to leave as it is - gfc_ref is a
struct that occurs a lot in complicated expressions, and the other
members are one
-tested. OK for trunk?
Regards
Thomas
2018-10-30 Thomas Koenig
PR fortran/85896
* simplify.c (simplify_min_max): Do not convert the type of the
return expression.
2018-10-30 Thomas Koenig
PR fortran/85896
* gfortran.dg/min_max_type.f90: New test
Am 31.10.18 um 04:26 schrieb Joseph Myers:
This patch (diffs to generated files omitted below) updates GCC to use
autoconf 2.69 and automake 1.15.1.
I think this should fix PR 82856. Maybe you could confirm that this
restores automake functionality with perl 5.6.26, and mention the PR
in the C
Hi,
I just committed the test case below so the bug can be closed.
The error message is less than ideal, but at least it is something.
Maybe I'll file a separate PR about translating error messages about
artificial variables to user's variables.
Regards
Thomas
2018-10-
Hi,
a gentle reminder: Patches which touch gcc/fortran or libgfortran need
to be discussed on the fortran mailing list and approved by a reviewer.
There have been a couple of commits recently where this wasn't followed,
please remember to do so in the future.
Regards
Thomasa
Hello world,
I just adjusted the error message for BIND(C) functions which
return strings of length > 1. I just used the suggestion from
the PR. Committed as obvious and simple (although I managed
to use up three revisions to do it right :-)
Regards
Thomas
2018-11-01 Thomas Koe
additional call to determine length of the substring.
No test case because the failure was only exposed by an instrumented
compiler.
Regression-tested. OK for trunk?
Regards
Thomas
2018-11-01 Thomas Koenig
PR fortran/87782
* frontend-passes.c (constant_string_length): If
Please remove the trailing whitespace (after "length 1").
Done (r265732).
2018-11-02 Thomas Koenig
PR fortran/46020
* decl.c (verify_bind_c_sym): Remove unnecessary space
in error message.
Ind
Hi Jerry!
Hi all,
The attached patch adds code in read_sf_internal to handle early
termination of reads in the presence of comma's. This is to support
legacy codes which are not standard conforming as far as we can tell.
The additions are executed only if -std=legacy is given at compile tim
Hi Janne,
1) It's KISS
2) I can't find anything in the code that would lead to endless
recursive invocation of the error printing functions.
So, Ok for trunk?
With async I/O, I think the possibilities of hitting
concurrent errors have increased, so I'd still prefer the
solution with wrappi
Hello world,
the attached patch fixes both ICEs in the PR by adding some tests.
It was necessary to shuffle around a bit of code, plus to make sure that
double error reporting did not become too bad.
Regression-tested. OK for trunk?
Regards
Thomas
2018-11-11 Thomas Koenig
Hi,
the attached patch fixes both ICEs in the PR by adding some tests.
It was necessary to shuffle around a bit of code, plus to make sure that
double error reporting did not become too bad.
Regression-tested. OK for trunk?
Ping?
Regards
Thomas
Hi Paul1
OK for trunk.
Thanks for working on it.
Committed as r266248.
Thanks for the review!
Regards
Thomas
Hello world,
using the combined superpowers of Captain Obvious and Lieutenant Simple,
I have committed the attached patch, which fixes a regression, as
r266251, after regression-testing. I will backport to 8 and 7 in the
next few days.
Regards
Thomas
2018-11-18 Thomas Koenig
Hi Jakub,
I'd like to ping this patch, ok for trunk?
OK. Thanks for the patch!
Before 9.0 is released, we should also document the flag
(and the extension it supports) in the manual, and note it
in changes.html and on the Wiki. Would you also do that?
Regards
Thomas
Hi Janne,
PING!
OK.
Thanks for the patch!
Regards
Thomas
Hi Jakub,
Before 9.0 is released, we should also document the flag
(and the extension it supports) in the manual, and note it
in changes.html and on the Wiki. Would you also do that?
Like this? Ok for trunk/wwwdocs?
OK for trunk (and I don't think you need my OK for wwwdocs, but
you have it
Hi Martin,
he header file will be install by glibc (glibc-devel package).
Why actually glibc-devel? Needing glibc-devel for fast compilation
of Fortran seems to be counter-intuitive. Maybe glibc would be better.
Regards
Thomas
Am 27.11.18 um 17:22 schrieb Steve Ellcey:
Why wouldn't clang (flang) want to use the same mechanism as
GCC/gfortran? I know there is some interest/work going on here for
flang and we would like a consistent way to use pre-includes to define
SIMD vector functions in both gfortran and flang. I t
Hello world,
the attached patch sets the I/O block size for unformatted files to
2**17 and makes this, and the block size for formatted files,
adjustable via environment variables.
The main reason is that -fconvert=big-endian was quite slow on
some HPC systems. A bigger buffer should eliminate t
OK, so here is a new version.
I think the discussion has shown that enlaring the buffer makes sense,
and that the buffer size for unformatted seems to be too bad.
I've reversed the names of the environment variables according to
Behnard's suggestion.
So, OK for trunk?
Also, what should we do a
... of course, better with the actual patch.
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 273183)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -611,6 +611,8 @@ Malformed environment variables are si
Hi Steve,
On Sun, Jul 14, 2019 at 12:07:58PM +0200, Thomas Koenig wrote:
OK, so here is a new version.
I think the discussion has shown that enlaring the buffer makes sense,
and that the buffer size for unformatted seems to be too bad.
I've reversed the names of the environment vari
Am 10.02.19 um 12:13 schrieb Thomas Koenig:
Hello world,
this patch fixes the coarray part of PR 71066 - handling of data
statements for coarrays. The PR itself is marked as a 7/8/9
regression.
Regression-tested. OK for trunk and for backporting?
Ping?
Regards
Thomas
Hi Jakub,
I checked the patch together with Richard's (by which I assume you
mean https://gcc.gnu.org/bugzilla/attachment.cgi?id=45052 ), and
thinks looked good.
So, the Fortran part of this is OK.
However, we should really also do power-of-two scaling
for the runtime method.
Also, we seem to
Hi Steve,
On Sat, Feb 16, 2019 at 05:23:58PM +0100, Thomas Koenig wrote:
Also, we seem to have a lot of issues with IEEE flags
when calculating NORM2, this would also need to be
addressed.
Which IEEE flags and are you referring using the
Fortran modules or -ffpe-trap?
I checked out the
or b) somehow generating
a wrong decl, but we are already doing this as of this moment,
so things can not really be made much worse, and a lot better.
So, ok for trunk and for backport (with some time in between)
once gcc-8 has re-opened?
Regards
Thomas
2019-02-17 Thomas Koenig
401 - 500 of 1504 matches
Mail list logo
