Re: [patch, fortran] Fix PR 48847, bogus "unused parameter" warning

Hi Steve, You need a space after TREE_NO_WARNING. I think that the patch can be applied now given its simplicity. Committed as rev. 183916 with the space. Thanks a lot for the review! Thomas

Added test case for PR 32373, missed vectorization with equivalence

Hello world, I added the attached test case from the PR after verifying that all loops mentioned in the PR are now vectorized. The PR is now closed. 2012-02-05 Thomas König PR fortran/32373 * gfortran.dg/vect/vect-8.f90: New test case. ! PR fortran/32373 - eight of these lo

Re: Added test case for PR 32373, missed vectorization with equivalence

Hi Dominique, The test fails on powerpc-apple-darwin9 because double are not vectorized. I think the following patch is required: Thanks for noticing this! I applied this patch as obvious after regression-testing. Thomas 2012-02-06 Thomas König PR fortran/32373 *

[patch, testsuite, committed] Test case for vectorization PR 32380

Hello world, I committed the attached test case after verifying that it passes and that only real(4) variables occur (so the requiredment on vect_float should be correct.) Thomas 2012-02-08 Thomas Koenig PR fortran/32380 * gfortran.dg/vect/pr32380.f90: New test

[patch, testsuite] PR 52229, testsuite failure

Thomas Koenig PR testsuite/52229 PR fortran/32380 * gfortran.dg/vect/pr32380.f: XFAIL on PowerPC and ia-64. Index: pr32380.f === --- pr32380.f (Revision 184166) +++ pr32380.f (Arbeitskopie) @@ -259,5 +259,5

Re: [patch, testsuite] PR 52229, testsuite failure

Am 13.02.2012 21:39, schrieb Thomas Koenig: Ping? Hello world, the attached patch xfails the offencing test case on architectures which do not allow unaligned access for vecorization. OK for trunk? Any other architectures which should be XFAILed? Regression-tested on powerpc64-unknown-linux

[patch, documentation] Document -floop-flatten as experimental

Hello world, the attached patch documents -floop-flatten as unsafe (see the PR). Tested with 'make dvi', 'make info' and 'make pdf'. I'd like to get this into the 4.7 release. OK for trunk? Thomas 2012-02-27 Thomas Koenig PR tr

Re: [patch, fortran] Some more function elimination tweaks

Hi Steve, * frontend-passes.c (cfe_register_funcs): Also register character functions if their charlens are known and constant. Also register allocatable functions. 2011-05-18 Thomas Koenig * gfortran.dg/function_optimize_8.f90: New test case. OK

[patch, fortran] [4.6/4.7 Regression] Fix PR 48955

? Thomas 2011-05-22 Thomas Koenig PR fortran/48955 * gfortran.h (gfc_reverse): Change to struct with two boolean variables, forward_ok and backward_ok. * trans-expr.c (gfc_trans_assignment_1): Initialize using new gfc_reverse struct

Re: [patch, fortran] [4.6/4.7 Regression] Fix PR 48955

Dear Paul, Following some comments from Thomas, the attached is the version that I wound up with. Tell us which one you prefer and Thomas and I will do the honours. Bootstrapped and regtested on FC9/x86_64 - OK for trunk and 4.6? Your patch is does the job and is less intrusive than mine -

[patch, fortran] Fix PR 45786, operator == versus .eq. in public/private

. 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

Re: [patch, fortran] Fix PR 45786, operator == versus .eq. in public/private

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

Re: [PATCH] PR fortran/49265 -- allow for double colon in module procedure statement

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

Re: [PATCH] PR fortran/49265 -- allow for double colon in module procedure statement

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

Re: never ending output from -fdump-fortran-original on ENTRY statement

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:

Re: [Patch, Fortran] Fix -fcheck=pointer for F2008's NULL ptr to optional arguments

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!

[patch, fortran]

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

Re: [patch, fortran] Some more TRIM optimizations

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-

Re: [patch, fortran] Some more TRIM optimizations

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

Re: [patch, fortran] Some more TRIM optimizations

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

[patch, fortran] Final TRIM optimizations

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

[patch, fortran] Fix PR 49479, reshape with optional arg

? 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

Re: [patch, fortran] Fix PR 49479, reshape with optional arg

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

[patch, fortran] Always return malloc(1) for empty arrays in the library

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

Re: [patch, fortran] Always return malloc(1) for empty arrays in the library

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.

Re: [patch, fortran] Always return malloc(1) for empty arrays in the library

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-

Re: [patch, fortran] Always return malloc(1) for empty arrays in the library

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

Re: [Patch, Fortran] PR

Am 17.07.2011 20:30, schrieb Tobias Burnus: Build and regtested on x86-64-linux? If you say so :-) OK for the trunk? Actually, I am not 100% sure whether I need approval as Thomas already gave kind of an approval in the PR. Well, to remove any doubt: Yes. Thanks for the patch! Th

[patch, fortran] Fix ice-on-valid PR 48876

Hello world, the attached, rather self-explanatory patch fixes PR 48876. OK for trunk? Thomas 2011-07-30 Thomas Koenig PR fortran/48876 * expr.c (gfc_simplify_expr): If end of a string is less than zero, set it to zero. 2011-07-30 Thomas Koenig

Re: [patch, fortran] Fix ice-on-valid PR 48876

Hello Steve, On Sat, Jul 30, 2011 at 01:49:42PM +0200, Thomas Koenig wrote: Hello world, the attached, rather self-explanatory patch fixes PR 48876. OK for trunk? Yes. If the problem exists on 4.6, can you apply the patch to 4.6 as well. Applied to trunk and 4.6 (this was not a

Re: [Patch, libfortran] Type cleanup

Hi Janne, the attached patch does a bit of janitorial type cleanup for the library. It replaces the use of ssize_t with ptrdiff_t or index_type where appropriate; this is entirely for documentation purposes, as on all targets we support ssize_t == ptrdiff_t. ssize_t is a POSIX type used in the

Re: [Patch, Fortran] PR 48624 - fix DECL for external procedures with proc arguments

Am 16.04.2011 08:34, schrieb Tobias Burnus: Thus: OK for the trunk? OK. Thanks for the patch (which, incidentally, also fixes PR 48644). Thomas

[patch, fortran] PR 48405 - Front end expressions in DO loops

tests pass? Thomas 2011-04-18 Thomas Koenig PR fortran/48405 * frontend_passes (cfe_register_funcs): Remove workaround for DO loops. (gfc_code_walker): Make sure the pointer to the current statement doen't change when other statements are ins

Re: [Patch, fortran] Committed trivial FIXME patch

Am 19.04.2011 20:17, schrieb Janne Blomqvist: Now that Jim Meyering has remove the macro that prevented directly calling free(), and replaced gfc_free() with free(), we can fix this. Committed as obvious. Thanks Janne. I had meant to do this, but hadn't gotten a round tuit. Thomas

Re: [patch, fortran] PR 48405 - Front end expressions in DO loops

Am 19.04.2011 20:35, schrieb Thomas Koenig: Hello world, this patch fixes the enhancement PR, plus probably a few regressions. The basic problem was that the code walker got confused when *c, the pointer to the current gfc_code statement, was changed by inserting additional code. Currently

Re: [patch, fortran] PR 48405 - Front end expressions in DO loops

Hi Mikael, Regression-testing passed. Ping ** 0.25? Thomas OK. Thanks Waiting for Emacs... Sende fortran/ChangeLog Sende fortran/frontend-passes.c Sende testsuite/ChangeLog Hinzufügen testsuite/gfortran.dg/function_optimize_6.f90 Übertrage Daten

[patch, fortran] Make block names unique

Hello world, the attached patch makes block names unique, so that -fdump-fortran-original dumps are easier to read. Regression-tested. OK for trunk? Thomas 2011-04-22 Thomas Koenig * decl.c (gfc_match_end): Check that the block name starts with "

[patch, fortran] Put front-end temporaries into BLOCKs

towards eliminating redundant calls to array-valued functions whose bounds are unknown at compile time, such as the original test case for PR 22572. No test case, as this should not change anything. Regression-tested. OK for trunk? Thomas 2011-04-23 Thomas Koenig

Re: [patch, fortran] Make block names unique

Am 22.04.2011 22:07, schrieb Thomas Koenig: Hello world, the attached patch makes block names unique, so that -fdump-fortran-original dumps are easier to read. Regression-tested. OK for trunk? Thomas 2011-04-22 Thomas Koenig * decl.c (gfc_match_end): Check that the block name starts with

Re: [patch, fortran] Put front-end temporaries into BLOCKs

Am 23.04.2011 17:22, schrieb Thomas Koenig: Hello world, the attached patch puts temporary variables, and the statement they are being generated for, in their own BLOCK. This may or may not be useful for data locality, and for telling the middle end explicitly about the lifetime of the

Re: [patch, fortran] Put front-end temporaries into BLOCKs

Hi Jerry, OK and thanks for patch. Waiting for Emacs... Sende ChangeLog Sende frontend-passes.c Übertrage Daten .. Revision 172983 übertragen. Thanks for the review! Thomas

Re: [patch, fortran] Make block names unique

Hi Mikael, * decl.c (gfc_match_end): Check that the block name starts with "block@". * parse.c (gfc_build_block_ns): Make block names unique by numbering them. Ping ** 0.25? Thomas OK Waiting for Emacs... Sendingfortran/ChangeLog Sendingfortran/decl.c Sending

Re: [Patch, fortran] PR48462 - [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array + PR48746

Dear Paul, first, thanks for the patch. There is one thing it does not appear to do correctly: It should also set the dtype on the variable itself: ig25@linux-fd1f:~/Krempel/H> cat mm.f90 program main implicit none integer, parameter :: m=10, n=12, count=4 double precision :: a(m, count),

Re: [Patch, fortran] PR48462 - [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array + PR48746

Hello Paul, there's another point: The sizes are also not set correctly. ig25@linux-fd1f:~/Krempel/H> cat mm.f90 program main implicit none integer, parameter :: m=10, n=12, count=4 double precision :: a(m, count), b(count, n), c(m, n) double precision, dimension(:,:), allocatable :: tmp

Re: [gomp3.1] Allow pointers and cray pointers in firstprivate/lastprivate, handle not allocated allocatable in firstprivate

Hi Jakub, This patch includes assorted OpenMP 3.1 changes for Fortran. Haven't changed COPYIN with not allocated allocatables yet, waiting for explanation on OpenMP forum there. I'm not an OpenMP expert, but I'd say this is OK for trunk (unless somebody else speaks up, quickly :-)

[patch, fortran, committed] Fix display of BLOCK variables in Fortran dumps

ICIT 1 2 ) END BLOCK instead as being displayed as being 'from block@1'. Thomas 2011-04-30 Thomas Koenig * dump-prase-tree.c (show_code_node): Set the current namespace to the BLOCK before displaying it; restore afterwards. Index: dump-parse-tree.c =

[patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

Regression-tested. OK for trunk? Thomas 2011-05-01 Thomas Koenig PR fortran/22572 * frontend-passes.c (cfe_register_funcs): Also register functions for potential elimination if the rank is > 0, the shape is unknown and reallocate on assignm

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

Am 01.05.2011 11:49, schrieb Thomas Koenig: Hello world, after Paul's fix for allocate on assignment (thanks Paul!), here is a patch for the original test case from PR 22572, where the bounds of the function are unknown at compile time. This uses an allocatable temporary.

Re: [Patch, Fortran+gcc/doc/invoke.texi] PR48864: -Ofast implies -fno-protect parens

Hi Tobias, As the example in the PR shows, using -fno-protect parens can make a huge difference. As -fno-protect is in the spirit of -Ofast, enable it with that option. Build on x86-64-linux. OK for the trunk? OK. Out of curiosity: Why do you do gfc_option.flag_protect_parens = optimize_fas

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

Am 03.05.2011 22:12, schrieb Thomas Koenig: Am 01.05.2011 11:49, schrieb Thomas Koenig: Hello world, after Paul's fix for allocate on assignment (thanks Paul!), here is a patch for the original test case from PR 22572, where the bounds of the function are unknown at compile time. This us

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

Hi Jerry, On 05/01/2011 02:49 AM, Thomas Koenig wrote: Hello world, after Paul's fix for allocate on assignment (thanks Paul!), here is a patch for the original test case from PR 22572, where the bounds of the function are unknown at compile time. This uses an allocatable temporary. I

[patch, fortran] Some more function elimination tweaks

known at compile time - It removes introducing temporary variables for the TRANSFER function; this is better be handled by the middle-end. Regression-tested. OK for trunk? Thomas 2011-05-18 Thomas Koenig * frontend-passes.c (cfe_register_funcs): Also register

Re: [Patch, Fortran] Implement/fix cobounds for scalar coarrays on tree level

Hi Tobias, *ping* http://gcc.gnu.org/ml/fortran/2011-05/msg00123.html OK. Thanks for the patch! Thomas

[patch, fortran] Fix PR 48066

Hello world, the attached patch fixes PR 48066, a regression introduced way back when. It is pretty self-explanatory. Regression-tested. OK for trunk? Also OK for a 4.5 backport? Thomas 2011-03-12 Thomas Koenig PR libfortran/40866 * m4/ifunction.m4: If return

Re: [patch, fortran] Fix PR 48066

Hi Jerry, On 03/12/2011 02:09 PM, Thomas Koenig wrote: Hello world, the attached patch fixes PR 48066, a regression introduced way back when. It is pretty self-explanatory. Regression-tested. OK for trunk? OK and thanks for patch! Übertrage Daten

Re: [patch, fortran] Fix PR 48066

Am 13.03.2011 00:04, schrieb Mikael Morin: On Saturday 12 March 2011 23:40:32 Thomas Koenig wrote: There was a typo in the PR number (both in the testcases and in the changelogs) Corrected. Thanks! Thomas

[patch, fortran] Function call optimization

such functions have side effects, the program is illegal. OK for trunk, now that it has reopened? Thomas 2010-03-14 Thomas Koenig PR fortran/22572 * frontend_passes (expr_array): New static variable. (expr_size): Likewise. (expr_count): Likewise

Re: [patch, fortran] Function call optimization

being too restrictive on the candidates for optimization. Since this appears to be the consensus, here is an updated version of the patch which does indeed that. Regression-tested. OK for trunk? 2010-03-14 Thomas Koenig PR fortran/22572 * frontend_passes (expr_array):

Re: [patch, fortran] Function call optimization

t. Also tested with "make dvi" and "make info". OK for trunk? Thomas 2010-03-14 Thomas Koenig PR fortran/22572 * gfortran.h (gfc_option_t) : Add flag_aggressive_function_elimination. * lang.opt: Add faggressive-function-eliminati

Re: [patch, fortran] Function call optimization

nt added. I have also factored out the code with gfc_dep_compare_expression into its own function. Here is the new version of the patch. Regression-tested. OK for trunk? Thomas 2010-03-20 Thomas Koenig PR fortran/22572 * gfortran.h (gfc_option_t) : Add flag

Re: [patch, fortran] Function call optimization

Hi Mikael, Here is the new version of the patch. Regression-tested. OK for trunk? OK this time. Thank you. Sende fortran/ChangeLog Sende fortran/dependency.c Sende fortran/frontend-passes.c Sende fortran/gfortran.h Sende fortran/invoke.texi Sende

[patch, Fortran] Some more trim optimizatins

Hello world, the following patch extends the trim optimization to variables like trim(a%x). Going for trim(a(1)) led to a very strange regression, so I took that out (for now). Regression-tested. OK for trunk? Thomas 2011-03-26 Thomas Koenig PR fortran/47065

Re: [patch, Fortran] Some more trim optimizatins

Hi Tobias, Thomas Koenig wrote: the following patch extends the trim optimization to variables like trim(a%x). Regression-tested. OK for trunk? OK. Sendingfortran/ChangeLog Sendingfortran/frontend-passes.c Sendingtestsuite/ChangeLog Adding testsuite

[patch, fortran] Extend character optimization to LLE and friends

Hello world, the attached patch extends the character optimizations to the lexical comparison functions (LLE and friends). Regression-tested. OK for trunk? Thomas 2010-03-28 Thomas Koenig * frontend-passes (optimize_lexical_comparison): New function

Re: [patch, fortran] Extend character optimization to LLE and friends

Am 28.03.2011 22:07, schrieb Richard Henderson: Style nit: remove the unreachable break statements. Fixed, thanks. Any further comments? Thomas

[ patch, committed] Warn about array temporary creation in front end optimization

Hello world, I have committed the attached patch as obvious, revision 171653, after regression-testing. Thomas 2011-03-29 Thomas Koenig * frontend-passes.c (create_var): Warn about creating an array temporary if requested. 2011-03-29 Thomas Koenig

[patch, fortran] Fix PR 48352 - regression with ICE with front end optimization

s not known at compile-time anyway. Regression-tested. OK for trunk? Thomas 2011-03-31 Thomas Koenig PR fortran/48352 * frontend-passes (cfe_register_funcs): Don't register functions if they appear as iterators in DO loops. 2011-03-31 Thomas Koenig

Re: [patch, fortran] Fix PR 48352 - regression with ICE with front end optimization

Hi Jerry, Regression-tested. OK for trunk? OK. Do you plan to open a second PR for this TODO? Sendingfortran/ChangeLog Sendingfortran/frontend-passes.c Sendingtestsuite/ChangeLog Adding testsuite/gfortran.dg/function_optimize_3.f90 Transmitting file data

[patch, fortran, committed] Fix regression PR 48412

to Joost for finding the bug in the first place and for reducing that far! Thomas 2011-04-04 Thomas Koenig PR fortran/48412 * frontend-passes (cfe_expr_0): Reverse the order of going through the loops. 2011-04-04 Thomas Koenig PR fortran/48412

[patch, fortran] More control over front end optimization

in, I will also mention the new options in the changes file. OK for trunk? 2011-04-07 Thomas Koenig PR fortran/48448 * gfortran.h (gfc_option_t): Add warn_function_elimination and flag_frontend_optimize. * lang.opt (Wfunction-elimination): Add. (ffro

Re: [patch, fortran] More control over front end optimization

): Handle -Wfunction-elimination and -ffrontend-optimize. 2011-04-08 Thomas Koenig PR fortran/48448 * gfortran.dg/function_optimize_5.f90: New test. Index: gfortran.h === --- gfortran.h (Revision 172058) +++

[patch, changes, fortran, committed] Mention -ffrontend-optimize and -Wfunction-elimination

Hello world, I committed the following as obvious, after verifying with the w3c validator. RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- changes.html4 Apr 2011 07:08:12 - 1.6 +++ changes.html

Re: [Patch] Fortran: Unify gfc_get_location handling; fix expr->ts bug

Hi Tobias, This unifies the two locus to location_t conversion functions, preparing for some changes I want to do later. In principle, I had the patch this morning; however, the assert is now exercised more often than before - and it triggered rather unexpected when running the testsuite.

Re: [patch, Fortran] Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING

Hi Jerry, the attached patch implements the constants for UNSIGNED for ISO_FORTRAN_ENV and ISO_C_BINDING.  With this, the implementation of UNSIGNED for gfortran should be complete, modulo bugs, of course. OK for trunk? Looks good to go Thomas. Committed, thanks for the review! Actually, t

[patch, Fortran] Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING

Hello world, the attached patch implements the constants for UNSIGNED for ISO_FORTRAN_ENV and ISO_C_BINDING. With this, the implementation of UNSIGNED for gfortran should be complete, modulo bugs, of course. OK for trunk? Best regards Thomas gcc/fortran/ChangeLog: * dump-par

Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Am 11.10.24 um 18:00 schrieb Thomas Koenig: Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO

[patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO_C_BINDING constants. That, we do via iso-c-binding.def , whose l

Fwd: [patch, fortran] Implement maxloc and minloc for unsigned

] Implement maxloc and minloc for unsigned Datum: Fri, 4 Oct 2024 09:54:37 +0200 Von: Thomas Koenig An: fort...@gcc.gnu.org , gcc-patches Hello world, please find attached the patch for implementing MAXLOC and MINLOC for unsigned. The patch is rather lengthy, but mostly due to combinatorial

[patch, fortran] Fix UNSIGNED ICE on matchting

Hello world, I have just committed the attached patch as obvious - just recognize that an UNSIGNED is an error in a complex part. Fix an ICE with UNSIGNED in match_sym_complex_part. gcc/fortran/ChangeLog: PR fortran/117225 * primary.cc (match_sym_complex_part): An UNSIGNED in

[patch, fortran] Fix ICE with use of INT32 et al from ISO_FORTRAN_ENV

Hello world, The attached patch fixes an ICE when an UNSIGNED-specific constant is used from ISO_FORTRAN_ENV. The error message is not particularly great, it is Error: Unsigned: The symbol 'uint32', referenced at (1), is not in the selected standard but it is better than an ICE. OK for trun

Re: [patch, Fortran] Introduce unsigned versions of MASKL and MASKR

Ping **(5./7.) ? MASKR and MASKL are obvious candidates for unsigned, too; in the previous version of the doc patch, I had promised that these would take unsigned arguments in the future. What I had in mind was they could take an unsigned argument and return an unsigned result. Thinking about t

Re: [pushed] doc, fortran: Add a missing menu item.

Am 27.10.24 um 00:15 schrieb Iain Sandoe: Tested on x86_64-darwin21 and linux, with makeinfo 6.7 pushed to trunk, thanks Thanks! For the record, makeinfo 6.8 did not show this as an error. Best regards Thomas

[patch, Fortran] Introduce unsigned versions of MASKL and MASKR

Hello world, MASKR and MASKL are obvious candidates for unsigned, too; in the previous version of the doc patch, I had promised that these would take unsigned arguments in the future. What I had in mind was they could take an unsigned argument and return an unsigned result. Thinking about this a

Re: [patch, Fortran] Reject UNSIGNED for COMPLEX

Am 10.11.24 um 21:54 schrieb Harald Anlauf: Hi Thomas, the patch is basically fine. I am wondering if we should create a new helper function that is the opposite of type_check ("type_cannot_be"), so that we avoid redundant code at the source level.  It may not be worth it yet, so your choice.

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED

Am 26.10.24 um 22:10 schrieb Iain Sandoe: Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). This seems to have broken —enable-languages=all bootstrap with /src-local/gcc-master/gcc/fortran/intrinsic.texi:39: node `Intrinsic Procedures' lacks menu item for `UINT' despite being its Up target

[patch, Fortran, doc] Update descriptions for UNSIGNED

Hello world, the attached patch adds documentation for the long list of intrinsics which take UNSIGNED arguments. Checked with "make html", "make pdf" and "make info". gcc/fortran/ChangeLog: * gfortran.texi: Correct reference to make clear that UNSIGNED will not be part of F202Y

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED

Hi Steve, OK for trunk? OK, but see below. Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for the proof-reading! Best regards Thomas

[patch, Fortran] Fix -mod(unsigned, unsigned)

Hello world, during testing, I noticed that parameters of the form - mod(u1,u2) were rejected with an unknown type. The fix is straightforward, but required an adjustment to another test case. Regression-tested. OK for trunk? gcc/fortran/ChangeLog: * resolve.cc (resolve_operator): Als

[patch, fortran] Add random numbers and fix some bugs.

This patch adds random number support for UNSIGNED, plus fixes two bugs, with array I/O where the type used to be set to BT_INTEGER, and for division with the divisor being a constant. Again, depends on prevous submissions. OK for trunk? gcc/fortran/ChangeLog: * check.cc (gfc_check_ran

[patch, fortran] Implement IANY, IALL and IPARITY for unsigned

OK for trunk? This is based on the previous submissions. Again, this does not generate a new library version; rather it re-uses the signed integer version already present in the library. OK for trunk? Previous submissions (without which this will not work): https://gcc.gnu.org/pipermail/fortra

Re: [Patch, fortran] PR116733: Generic processing of assumed rank objects (f202y)

Am 23.09.24 um 11:02 schrieb Paul Richard Thomas: Hi All, The moment I saw the DIN4 proposal for "Generic processing of assumed rank objects", I thought that this was a highly intuitive and implementable proposal. I implemented a test version in June and had some correspondence with Reinhold

Re: [patch, fortran] Matmul and dot_product for unsigned

Hello Andre and everybody else? Any more comments on the matmul patch? The other ones depend on it, so I would like to commit (unless there are further questions, of course). Best regards Thomas

Fwd: [patch, fortran] Matmul and dot_product for unsigned

after that, C interop, one of the main reasons this was requested. I have also committed, right now, a fix for the failure of unsigned_25.f90 on 32-bit systems as obvious. Best regards Thomas Author: Thomas Koenig Date: Wed Sep 25 18:51:48 2024 +0200 Fix testsuite failure on 32

[patch, Fortran] FINDLOC for unsigned

.texi: Include FINDLOC in unsigned documentation. * iresolve.cc (gfc_resolve_findloc): Use INTEGER version for UNSIGNED. gcc/testsuite/ChangeLog: * gfortran.dg/unsigned_33.f90: New test.From 864071a00f886ae2115d6dfa5d286c84e67360f6 Mon Sep 17 00:00:00 2001 From: Thomas Koenig

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

Hi Mikael, Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). I have one patch series touching (inline) MINLOC and MAXLOC to post in the coming days.  Could you please keep away from them for one more week or two? Looking at the pre

[patch, Fortran] CSHIFT and EOSHIFT for unsigned

00:00:00 2001 From: Thomas Koenig Date: Thu, 26 Sep 2024 21:46:55 +0200 Subject: [PATCH] Implement CSHIFT and EOSHIFT for unsigned. gcc/fortran/ChangeLog: * check.cc (gfc_check_eoshift): Handle BT_UNSIGNED. * simplify.cc (gfc_simplify_eoshift): Likewise. * gfortran.texi: Document CSHIFT and

Re: [Ping, Fortran, Patch, PR85002, v1] Fix deep-copy of alloc. comps. in coarrays ICEing and crashing w/ lib.

Am 18.09.24 um 12:31 schrieb Andre Vehreschild: Regtested ok on x86_64-pc-linux-gnu / F39. Ok for mainline? OK. Thanks for the patch! Best regards Thomas

Re: [Fortran, Patch, PR106606, v1] Fortran: Break recursion building recursive types. [PR106606]

Hi Andre, Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Extremely minor nit: In the commit message and ChangeLog entry, Build a derived type component's type only, when it is not already being build and the component uses pointer semantics. I believe that should be "being

Re: [Patch, Fortran] Implement Unsigned for SUM and PRODUCT

Am 19.09.24 um 11:55 schrieb Andre Vehreschild: Hi Thomas, thanks for the patch. I have one proposal/question and one missing verb (IMO). Else the patch looks fine to me. Ok for trunk. diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 829ab00c665..e5ffe67 100644 ---

Re: [patch, fortran] Add random numbers and fix some bugs.

22:15 +0200 Thomas Koenig wrote: This patch adds random number support for UNSIGNED, plus fixes two bugs, with array I/O where the type used to be set to BT_INTEGER, and for division with the divisor being a constant. Again, depends on prevous submissions. OK for trunk? gcc/fortran/Chan

<    6   7   8   9   10   11   12   13   14   15   >