Re: [PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE

Hi Harald, P.S.: this was my first actual commit to gcc. Congratulations, and welcome to the club! Regards Thomas

[patch, fortran] Fix PR 88669, rejects-valid

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? Regards Thomas 2019-01-27 Thomas Koenig PR fortran/88669

Re: [PATCH, testsuite]: Fix gfortran.dg/coarray/event_3.f08 testcase (PR fortran/70696)

Hi Uros, OK for mainline and release branches? OK, and thanks for the patch. (I would probably have considered this one obvious). Regards Thomas

Re: [PATCH] libgfortran: Use proper gthr.h API

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

Re: [patch, fortran] Fix PR 88669, rejects-valid

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

[patch, fortran] Fix PR 88298

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

[patch, fortran] Fix part of PR 67679, spurious undefined warning

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

Re: [patch, fortran] Fix part of PR 67679, spurious undefined warning

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

[patch, fortran] Fix PR 71237

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

[patch, committed] Test case for PR 71860

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

Re: [PR fortran/89077, patch, part 2] - ICE using * as len specifier for character parameter

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

[patch, fortran] Fix part of PR 71066

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? Regards Thomas 2019-02-10 Thomas Koenig PR fortran/71066

*Ping* [patch, fortran] Fix PR 71237

Am 06.02.19 um 21:27 schrieb Thomas Koenig: Hello world, this patch fixes a 7/8/9 regression where we tried to accept invalid code, which led to an ICE later on. The patch is rather straightforward.  The reason why I could not use gfc_expr_attr is that it does not actually return the flags the

Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)

Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux (together with Richard's patch), ok for trunk? A couple of points: with this patch, we will have an algorithm that will evaluate NORM2 in a different way than before, possibly leading to regressions in some cases where we previou

Re: Ping [Fortran, Patch, pr70524, v1] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

Hi Andre, the patch is OK. Ping. Regards Thomas

Re: [Fortran, Patch, PR72698, v1] [5/6/7 Regression] ICE in lhd_incomplete_type_error, at langhooks.c:205

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 assig

[patch, Fortran] Fix PR 71902

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 PR fortran/71902

[patch, fortran, committed] Set deferred flag on typespec for temporary strings

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 * frontend-passes.c (create_var): Set ts.deferred for deferred-length character variables

Re: Ping! Re: [PATCH, Fortran] New flag -finit-derived to initialize components of derived types

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 others

Re: [patch, Fortran] Fix PR 71902

e that this causes actual performance issues. Regards Thomas 2016-08-18 Thomas Koenig PR fortran/71902 * frontend-passes.c (realloc_string_callback): Check for deferred on the expression instead for allocatable on the symbol. Name temporary variab

Re: [Patch, fotran] PR70673 - [5/6/7 Regression] ICE with module containing functions with allocatable character scalars

Hi Paul, The fix to eliminate this ICE is trivial. Trivial once you have found it, not so trivial before... Bootstrapped and regtested on FC21/x86_64 - OK for 5 to 7 branches? OK. Thanks a lot for the patch! Thomas

[patch, fortran] New take on PR 82373

. OK for trunk? Regards Thomas 2017-10-12 Thomas Koenig PR fortran/82372 * fortran/scanner.c (last_error_char): New global variable. (gfc_scanner_init_1): Set last_error_char to NULL. (gfc_gooble_whitespace): If a character not printable or not

Re: [patch, fortran] New take on PR 82373

Hi Steve, I like this patch much better than the last. It's ok with me, but you might want give 24 hours to let the world rotate before committing (ie., allow others to comment) Committed as r253768. Thanks for the review! I don't think it is worth backporting, so I'll close the bug. If som

[patch, fortran] Fix PR 79795

Hello world, the attached patch fixes a regression by turning an ICE-on-invalid into an error message (and making sure that it fits). Regression-tested on trunk. OK for all affected branches (8/7/6)? Regards Thomas 2017-10-15 Thomas Koenig PR fortran/79795

[patch, fortran] Fix PR 82567

other affected branches? Regards Thomas 2917-10-17 Thomas Koenig PR fortran/82567 * frontend-passes.c (combine_array_constructor): If an array constructor is all constants and has more elements than a small constant, don't convert a*[b,c] to [a*b,a*

Re: [patch, fortran] Fix PR 82567

Hi Jerry and Steve, Well I know 42 is the answer to the ultimate question of the universe so this must be OK. I just don't know what the question is. OK and thanks, Jerry +#define CONSTR_LEN_MAX 42 Actually, I was wondering about the choice myself. With most common hardware having fairly r

[patch, fortran] Fix PR 56342, matmul was not simplified

cases. Regression-tested. OK for trunk? Regards Thomas 2017-10-22 Thomas Koenig PR fortran/56342 * simplify.c (is_constant_array_expr): If the expression is a parameter array, call gfc_simplify_expr. 2017-10-22 Thomas Koenig PR fortran/

[patch, fortran, RFC] Interchange indices for FORALL and DO CONCURRENT if profitable

x27;t think so) or to make Graphite catch this sort of pattern (which it currently doesn't) instead? Regards Thomas 2017-10-27 Thomas Koenig * frontend-passes.c (index_interchange): New funciton, prototype. (optimize_namespace): Call index_interchange.

Re: [patch, fortran, RFC] Interchange indices for FORALL and DO CONCURRENT if profitable

Hi Steve, On Sat, Oct 28, 2017 at 12:03:58AM +0200, Thomas Koenig wrote: +/* Callback function to determine if an expression is the + corresponding variable. */ + +static int static bool Most of the functions in the patch are callback functions for gfc_code_walker or gfc_expr_walker

[patch, fortran] KIND arguments for MINLOC and MAXLOC

use kind=1 and kind=2 are not supported at the moment. This bug would be fixed together with 82660. Regression-tested. OK for trunk? Regards Thomas 2017-10-28 Thomas Koenig PR fortran/29600 * gfortran.h (gfc_check_f): Replace fm3l with fm4l. * i

Re: [patch, fortran, RFC] Interchange indices for FORALL and DO CONCURRENT if profitable

Am 28.10.2017 um 00:03 schrieb Thomas Koenig: +typepedef struct { That should have been typdef, obviously - the typo must have slipped in after testing. Regards Thomas

Re: [PATCH] fix AIX fortran builds

Hi Jim, If I add a call to gcc_unreachable after the longjmp call, then it builds on both linux and AIX.  Anyone have a better idea on how to fix this?  If I don't get any responses in a few days, I will check it in under the obvious rule, since it fixes a build failure. The patch is OK. Than

[patch, fortran] Index interchange for FORALL and DO CONCURRENT

could test the nesting of loops. Regression-tested. OK for trunk? Regards Thomas 2017-10-31 Thomas Koenig * lang.opt (ffrontend-loop-interchange): New option. * options.c (gfc_post_options): Handle it. * frontend-passes.c (gfc_run_passes): Run

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

Hi Bernhard, Regression-tested. OK for trunk? s/shoud/should/; s/acessed/accessed/; s/indces/indices/; Fixed. why are struct ind_type "n" and "num" int and not unsigned int? I tend not to use signed variables unless the special overflow semantics are required. I like Fortran, which does

Ping: [patch, fortran] KIND arguments for MINLOC and MAXLOC

Am 28.10.2017 um 23:57 schrieb Thomas Koenig: Ping? the attached patch allows KIND arguments to MINLOC and MAXLOC. There was a bit of a choice to make here. Originally, I wanted to run the calculation using index_type only and convert to another integer kind if that was required. This ran into

Re: [patch, fortran] Index interchange for FORALL and DO CONCURRENT

Am 31.10.2017 um 21:56 schrieb Bernhard Reutner-Fischer: On Tue, Oct 31, 2017 at 09:50:37PM +0100, Bernhard Reutner-Fischer wrote: On Tue, Oct 31, 2017 at 09:30:27PM +0100, Thomas Koenig wrote: Or maybe emit diagnostics into the frontend optimize dump file and scan that? If we could check

[test case, fortran, committed] Test case for PR 70330

Hi, I have just committed the test case from PR 70330 to trunk and closed the (error-recovery) PR. Regards Thomas https://gcc.gnu.org/viewcvs?rev=254406&root=gcc&view=rev

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

Hi Andre, Shouldn't that better be if ((gfc_option.allow_std & GFC_STD_F2003) > 0 I think that if ((gfc_option.allow_std & GFC_STD_F2003) would be better - the allow_std field is signed, and things could get hariy if we ever have close to 32 standards we would like to support. Hm, come

[patch, fortran] Do loop (or index) interchange for FORALL and DO CONCURRENT, take 2

Hello world, the attached patch now includes a new option to warn about a loop interchange, plus a test case using that option. Regression-tested. OK for trunk? Regards Thomas 2017-11-05 Thomas Koenig PR fortran/82471 * lang.opt (ffrontend-loop-interchange): New

Re: [patch, fortran] Do loop (or index) interchange for FORALL and DO CONCURRENT, take 2

Hi Steve, it is assumed + expensive, and that loops which access later indices (which access memory + in bigger strides) should be moved to the first loops. Looks good to me with the typo fix. Committed as r254430. Thanks for the review (and for catching the typo; my fingers appear to

*Ping* [patch, libgfortran] Use memcpy in a few more places for eoshift

Am 04.07.2017 um 00:06 schrieb Thomas Koenig: attached are a few more speedups for special eoshift cases. This time, nothing fancy, just use memcpy for copying in the contiguous case. Ping? Regards Thomas

Re: *Ping* [patch, libgfortran] Use memcpy in a few more places for eoshift

Am 08.07.2017 um 13:57 schrieb Thomas Koenig: Am 04.07.2017 um 00:06 schrieb Thomas Koenig: attached are a few more speedups for special eoshift cases. This time, nothing fancy, just use memcpy for copying in the contiguous case. Ping? Regards Thomas Some benchmarks (source

Re: *Ping* [patch, libgfortran] Use memcpy in a few more places for eoshift

Hi Paul, The patch is OK by me. Thanks for the review. Committed as rev. 250085. Thanks for working on speeding up these library functions. Does the octave version, mentioned in the clf thread, translate easily into C? I had to remind myself of how octave cell arrays function. It is certain

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Hi Paul, Please find attached what I believe is the final version of the patch. This is looking very good, this does work as advertised and has all the corner cases coverd. I also regtested this on powerpc64-unknown-linux-gnu. I took the opportunity of the delay, while the bounds issue was

[fortran, RFC] Getting rid of unneeded functions in libgfortran

Hello world, with the bump in the libfortran version that is needed with Paul's patch, I think we can get rid of a few functions that we do not actually need any more. I think we now always inline SUM and PRODUCT. We don't do so with all occurrences of ANY and ALL, but we probably could (and sho

Re: [fortran, RFC] Getting rid of unneeded functions in libgfortran

Am 10.07.2017 um 23:27 schrieb Mikael Morin: We don’t inline when the dim argument isn’t constant. As far as I know, this is a valid albeit rare use case for the library functions. You're right. We can only remove, for example, sum_i4, but have to keep ssum_i4 and msum_i4, which both take a d

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Am 11.07.2017 um 16:48 schrieb Jerry DeLisle: Somewhere in the threads on this, there was mentioned ABI breakage/change. That was me. Does it really do this? Yes. Look at this part: Index: libgfortran/libgfortran.h === *** li

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

Am 14.07.2017 um 16:11 schrieb Cesar Philippidis: This patch teaches the fortran FE to allow deferred-shape pointers to be used in OpenACC data clauses. While the spec states that arrays must be contiguous, I believe that is a run-time requirement, not a compile time. The intent behind OpenACC is

[patch, fortran] Fix another dependency check for reallocation on assignment

Hello world, in PR 66102, I found a patch by Mikael which has never been applied. After dusting it off, finding that it looks reasonable and fixes the test case in question I'd like to apply this. Regression-tested. OK for trunk? Regards Thomas 2017-07-23 Thomas K

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

Am 17.07.2017 um 00:31 schrieb Cesar Philippidis: On 07/16/2017 10:28 AM, Thomas Koenig wrote: It is possible to declare a pointer with the contiguous attribute. Is there a reason that this cannot be used in general= That's a good point. But some users don't want to modify thei

Re: [PATCH 7/6] fortran: fix pair_cmp qsort comparator

Am 21.07.2017 um 16:29 schrieb Alexander Monakov: Bootstrapped and regtested on x86-64, OK for trunk? * interface.c (pair_cmp): Fix gfc_symbol comparison. Adjust comment. OK. Thanks for the patch! Regards Thomas

[patch, libfortran] Fix PR 80365, undefined memcpy

? Regards Thomas 2017-07-23 Thomas Koenig * io/unix.c (buf_write): Return early if there is nothing to write. Index: io/unix.c === --- io/unix.c (Revision 249936) +++ io/unix.c (Arbeitskopie) @@ -582,6 +582,9

[patch, fortran, committed] Show binding label on dump

Hello world, I have just committed the attached patch as obvious and simple after testing. Regards Thomas 2017-07-24 Thomas Koenig * dump-parse-tree.c (show_symbol): Show binding label if present. Index: dump-parse-tree.c

Re: [patch, libfortran] Fix PR 80365, undefined memcpy

Hi Janne, On Sun, Jul 23, 2017 at 10:23 PM, Thomas Koenig wrote: Hello world, the attached test cases fixes a problematic invocation of memcpy where src=NULL and n=0 by simply doing nothing in the surrounding function if there is nothing to be done. No test case, because this only shows up

[patch, fortran] Fix PR 79312, find invalid typespec for empty array constructors

Hello world, the attached patch fixes the PR; patch and test case are rather self-explanatory. Regression-testing as I write this. OK for trunk if it passes? Regards Thomas 2017-07-24 Thomas König PR fortran/79312 * intrisic.c (gfc_convert_type_warn): Only set ty

Re: [patch, fortran] Fix PR 79312, find invalid typespec for empty array constructors

I wrote: Regression-testing as I write this. OK for trunk if it passes? Regression test passed. Regards Thomas

Re: [PATCh] Fix a -Wnarrowing warning in Fortran FE

Hi Jakub, I've noticed yesterday a -Wnarrowing warning in the Fortran FE that broke my build (old configure, these days we use -Wno-narrowing, so don't see that). We are storing the mask into unsigned int field, and 1 << 31 is negative. Fixed thusly, bootstrapped/regtested on x86_64-linux and i

[patch, fortran] Generate C prototypes from Fortran code

;. I have chosen to turn function pointers into old-style K&R pointers, in the hope that this is the correct thing to do. So, is this approach OK in general? Suggestions? Other ideas? OK for trunk? Regards Thomas 2017-07-28 Thomas Koenig PR fortran/45435 * lang.op

Re: [patch, fortran] Generate C prototypes from Fortran code

trunk? Regards Thomas 2017-07-28 Thomas Koenig PR fortran/45435 * lang.opt (fc-prototypes): Add option. * gfortran.h (gfc_typespec): Add interop_kind to struct. (gfc_dump_c_prototypes): Add prototype. * decl.c (gfc_match_kind_spec): Copy

*ping* [patch, fortran] Fix PR 79312, find invalid typespec for empty array constructors

Am 24.07.2017 um 23:27 schrieb Thomas Koenig: Hello world, the attached patch fixes the PR; patch and test case are rather self-explanatory. Regression-testing as I write this. OK for trunk if it passes? Regards Thomas OK? Regards Thomas

Re: [PATCH, Fortran] Correctly set -fd-lines-as-comments with -fdec

Hi Fritz, This is a simple patch. The original intent was for -fdec to set -fd-lines-as-comments by default if flag_d_lines was unspecified by the user. However, currently flag_d_lines is interrogated in set_dec_flags(), usually before its final value is determined. The attached patch fixes this

Re: [PATCH, Fortran] Support for legacy %FILL fields in STRUCTUREs

Hi Fritz, Regtests on x86_64-redhat-linux. OK for trunk? Patch looks good in principle; I really find all these DEC extensions strange, but if they are needed for old code, why not? Just one point: + gfc_error ("%s not allowed outside STRUCTURE at %C", "%FILL"); This should ha

Re: [patch, fortran] Generate C prototypes from Fortran code

HI Paul, This reminds me of project that I once started to translate fortran into C using a similar option. I gave up in the end because I found it more convenient to use a tree dump and modify the declarations by hand. In respect of your query about suggestions, how about outputting non_interop

[patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

variables were excluded. Regression-tested. OK for trunk? Regards Thomas 2017-08-02 Thomas Koenig PR fortran/60355 * resolve.c (resolve_symbol): Adjust (and reformat) comment. Perform check if a BIND(C) is declared at module level regardless of whether it

[patch, gcc doc + fortran] Make -Ofast honor -fmax-stack-var-size

Hello world, the attached patch makes -Ofast honor -fmax-stack-var-size, and adjusts the documentation in the gcc and fortran directories accordingly. This is done to alleviate PR 68829, to make it possible to run -Ofast with less stack usage. I have also taken the opportunity to make it a bit c

Re: [patch, gcc doc + fortran] Make -Ofast honor -fmax-stack-var-size

Am 04.08.2017 um 14:09 schrieb Thomas Koenig: Hello world, the attached patch This time, really attached, even with ChangeLog! Regards Thomas 2017-08-04 Thomas Koenig PR fortran/68829 * doc/invoke.texi: Document change in behvaior for -Ofast for Fortran

[patch, fortran] Fix PR 81116, missing dependency handling for allocatable character

Hello world, the attached patch fixes the PR by adding a dependency check for the case of concatenation operators. Regression-tested. OK for trunk? Regards Thomas 2017-08-07 Thomas Koenig PR fortran/81116 * frontend-passes.c (realloc_string_callback): If

*ping* [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

Am 02.08.2017 um 15:19 schrieb Thomas Koenig: the attached patch is a bit smaller than it looks, because most of it is due to reformatting a large comment. It is rather simple - checking for an incorrectly placed BIND(C) variable was sometimes not done because the test was mixed in with other

Re: *ping* [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

Hi Paul, It looks fine to me. OK for trunk. Thanks, committed. Paul PS What about PR34640 ? Your patch is OK if you bump the library version. Regards Thomas

[patch, fortran, docs] Document sequential unformatted file structure

Hello world, seems like we never got around to documenting the structure of our unformatted sequential files. Well, here is a patch for that. Regards Thomas 2017-08-12 Thomas Koenig * gfortran.texi: Document format of unformatted sequential files. Index: gfortran.texi

*ping* [patch, fortran] Fix PR 81116, missing dependency handling for allocatable character

the attached patch fixes the PR by adding a dependency check for the case of concatenation operators. Regression-tested. OK for trunk? Ping? Regards Thomas

[patch, fortran] Fix regression with inline matmul

Thomas 2017-08-26 Thomas Koenig PR fortran/81974 * frontend-passes (inline_matumul_assign): Explicity set typespec for call to CONJG. 2017-08-26 Thomas Koenig PR fortran/81974 * gfortran.dg/inline_matmul_19.f90: New test Index: fronten

Re: [patch, libgfortran] PR78387 OpenMP segfault/stack size exceeded writing to internal file

Hi Jerry, ping - I will commit if I hear no objections. OK for trunk and gcc-7. I thought Paul had already OK'd it, which is why I didn't react. Thanks a lot for the patch! Regards Thomas

[patch, fortran] Warn about suspicious assignment to contiguous pointers

2017-08-27 Thomas Koenig PR fortran/49232 * expr.c (gfc_check_pointer_assign): Warn for suspicious assignments with contiguous pointers. 2017-08-27 Thomas Koenig PR fortran/49232 * gfortran.dg/contiguous_4.f90: New test. Index: expr.c

Re: [Patch, Fortran] PR 81770: [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

Hi Janus, the attached patch fixes a bogus warning. The purpose of the warning is to detect cases where a pointer lives longer than its target. If the target itself is (1) a pointer or (2) a component of a DT pointer, we do not know about the lifetime of the target at compile time and no warning

Re: [patch, fortran] Warn about suspicious assignment to contiguous pointers

patch. Regression-tested on powerpc-linux, make dvi and make pdf also passed. OK for trunk? Regards Thomas 2017-08-27 Thomas Koenig PR fortran/49232 * expr.c (gfc_check_pointer_assign): Warn for suspicious assignments with contiguous pointrs if -Wcontig

Re: [patch, fortran] Warn about suspicious assignment to contiguous pointers

Hi Janus, I think an unconditional warning is OK in this case because - Assigning to a pointer from an obvious non-contiguous target is not useful at all, that I can see I guess you're talking about a *contiguous* pointer here, Correct. and in that case I would argue that, beyond bei

Re: [patch, fortran] Warn about suspicious assignment to contiguous pointers

Hi Janus, and in that case I would argue that, beyond being "not useful", it's even illegal, so why not throw a hard error, if we can infer at compile-time that the target is non-contiguous? Problem is, we cannot infer this from the tests done. We would also have to add a test if the array is

[patch, fortran, RFC] warn about out-of-bounds errors in DO loops

Hello world, the attached patch warns about certain cases where out-of-bound array accesses can be detected at compile time. This was inspired by an out-of-bound access in Polyhedron. A preliminary version of this patch has already found one error in the testsuite. The problem is what to warn f

Re: [patch, fortran, RFC] warn about out-of-bounds errors in DO loops

Well, here's a version which actually throws a hard error in obvious cases; the other cases are reserved for -Wextra. Turns up a few bugs in the testsuite, too. An interesting one is unconstrained_commons.f, where the code quite happily saves and stores outside a common block array with a single

[patch, fortran] Reduce stack use in blocked matmul

e "dg-do run" hack). OK for trunk? Thomas 2017-05-05 Thomas Koenig PR fortran/80602 * m4/matmul_internal.m4: 'matmul_name`: Change t1 to a VLA of the required size. * generated/matmul_c10.c: Regenerated. * generated/matmu

[patch, fortran] Create temporary variables for matmul

? Regards Thomas P.S: Next on the agenda is to better handle the left-over combinations for Matmul, and to create temporaries for dependencies and function evaluations in the arguments that we currently do not handle. 2017-05-07 Thomas Koenig PR fortran/79930 * fronten

Re: [patch, fortran] Reduce stack use in blocked matmul

Am 08.05.2017 um 18:58 schrieb Jerry DeLisle: he attached patch reduces the stack usage by the blocked version of matmul for cases where we don't need the full buffer. This should improve stack usage. OK for trunk? OK, thanks. Is this something we should consider for backporting to gcc-7?

Re: [patch, fortran] Reduce stack use in blocked matmul

Am 09.05.2017 um 12:43 schrieb Andreas Schwab: On Mai 05 2017, Thomas Koenig wrote: @@ -227,6 +226,17 @@ sinclude(`matmul_asm_'rtype_code`.m4')dnl if (m == 0 || n == 0 || k == 0) return; + /* Adjust size of t1 to what is needed. */ + index_t

[patch, libfortran] Fix PR 80687l build failure on nvptx

progress. OK for trunk if the nvptx problem is fixed and regression-tests pass? Regards Thomas 2017-05-09 Thomas Koenig PR fortran/80687 * acinclude.m4 (LIBGFOR_CHECK_VLA): New macro. * configure.ac: Use it. * config.h.in: Regenerated

Fwd: [patch, fortran] PR 80687, 80696

... forgot to copy in gcc-patches here... Weitergeleitete Nachricht Betreff: [patch, fortran] PR 80687, 80696 Datum: Tue, 9 May 2017 23:14:30 +0200 Von: Thomas Koenig An: fort...@gcc.gnu.org Hello world, it appears that using VLAs also caused the strange errors reported in

Re: [patch, fortran] Reduce stack use in blocked matmul

Hi Andreas, + index_type t1_dim; + t1_dim = (a_dim1-1) * 256 + b_dim1; + if (t1_dim > 65536) + t1_dim = 65536; + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wvla" + 'rtype_name` t1[t1_dim]; /* was [256][256] */ That does the wrong thing if b_dim1 ==

Re: [patch, fortran] Reduce stack use in blocked matmul

Am 10.05.2017 um 17:42 schrieb Thomas Koenig: If you manage to come up with a legal Fortran testcas which sets b_dim1 to 0xdeadbeef, I owe you a beer :-) ... on a 32-bit system, of course.

[patch, libfortran] Fix amount of memory allocation for matrix - vector calculation

running a few select test cases under valgrind. No test case because nothing appeared to fail. OK for trunk? Regards Thomas 2017-05-10 Thomas Koenig * m4/matmul_internal.m4: Set bystride to correct value for later calculation of buffer size. * generated

Re: [patch, libfortran] Fix amount of memory allocation for matrix - vector calculation

Am 12.05.2017 um 10:16 schrieb Janne Blomqvist: On Fri, May 12, 2017 at 1:14 AM, Thomas Koenig wrote: Hello world, the memory allocation for the buffer in the library matmul routines still has one problem: The value of 0xdeadbeef meant as poison could end up in the calculation of the size of

[patch, fortran, RFC] Inline matmul(transpose(a),b)

Hello world, the attached patch, just an RFC so far, implements inlining for matmul(transpose(a),b). This implements c = 0 do i=1, size(a,2) do j=1, size(b,2) do k=1, size(a,1) c(i,j) = c(i,j) + a(k,i) * b(k,j) end do end do end

[patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

Thomas Koenig PR fortran/66094 * frontend-passes.c (matrix_case): Add A2TB2. (inline_limit_check): Handle MATMUL(TRANSPOSE(A),B) (inline_matmul_assign): Likewise. 2017-05-17 Thomas Koenig PR fortran/66094 * gfortran.dg/inline_matmul_16.f90

Ping ** 0.8571 [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

Hi, after receiving no negative feedback on my RFC patch, I have deciced to submit the patch. The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul. Speed is a bit faster than the library version. Regression-tested. OK for trunk? Ping.

Re: [patch, fortran] Handle MATMUL(TRANSPOSE(A),B) in inline matmul

Hi Jerry, On 05/17/2017 02:41 PM, Thomas Koenig wrote: Hello world, after receiving no negative feedback on my RFC patch, I have deciced to submit the patch. The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul. Speed is a bit faster than the library version. Regression

[patch, fortran, committed] replace stdout with dumpfile in a few places

Hello world, I just committed the attached patch as obvious. Regards Thomas 2017-05-24 Thomas Koenig * dump-parse-tree.c (show_expr): Replace stdout with dumpfile for showing values. Index: dump-parse-tree.c

Fwd: [patch, libfortran] AMD-specific versions of library matmul

17 12:45:46 +0200 Von: Thomas Koenig An: fort...@gcc.gnu.org , gcc-patches Hello world, the attached patch speeds up the library version of matmul for AMD chips by selecting AVX128 instructions and, depending on which instructions are supported, either FMA3 (aka FMA) or FMA4. Jerry tested th

Re: [patch, libfortran] AMD-specific versions of library matmul

Hi Jerry, Yes, OK. Maybe test Ryzen first? Sure, I can wait for a bit :-) I just confirmed access to the Ryzen machines so I plan to get set up and test there. The gcc compile farm machines? My ssh key does not work there... I have based the choice of FMA(3) over FMA4 when both are avail

Re: [patch, libfortran] AMD-specific versions of library matmul

Hi everybody, I have committed the patch (with the corrections for the name) as rev 248472. The infrastructure is in place, so we will be able to make any fine-tuning easily. Regards Thomas

[patch, libfortran, committed] Restore bootstrap on non-x86* systems

anges. Regards Thomas 2017-05-26 Thomas Koenig PR boostrap/80889 * acinclude.m4: Also set HAVE_AVX128 on the false branch of LIBGFOR_CHECK_AVX128. * configure: Regenerated. Index: acinclu

[patch, fortran, committed] Fix size of matmul calculation for a special case

Hello world, I have just committed as obvious a patch fixing a wrong calculation for allocating the size of a return variable in inline matmul (PR 80904). I will backport to the other affected branches in the near future. Regards Thomas 2017-05-28 Thomas Koenig * frontend

<    2   3   4   5   6   7   8   9   10   11   >