[Patch, committed] gfortran.dg/pr68078.f90: Avoid increasing RLIMIT_AS

The test did fail when the virtual memory already had a hard limit != unlimited. Committed as r12-57-gfaf7d413a3f3337be1a3ac5cdf33e0e3b87b426e Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thom

testsuite/substr_{9,10}.f90: Move to gfortran.dg/

The test was added in r11-6687-gbdd1b1f55529da00b867ef05a53a08fbfc3d1c2e (PR93340) but placed into the wrong directly. Fixed by moving to gfortran.dg/ in commit r12-68-gac456fd981db6b0c2f7ee1ab0d17d36087a74dc2 after confirming that the tests work. Tobias - Mentor Graphics (Deuts

[Patch, fortran] PR fortran/82376 - Duplicate function call using -fcheck=pointer

Hi All! Proposed patch to: PR82376 - Duplicate function call using -fcheck=pointer Patch tested only on x86_64-pc-linux-gnu. Evaluate function result and then pass a pointer, instead of a reference to the function itself, thus avoiding multiple evaluations of the function. Thank you very mu

Re: Fix Fortran rounding issues, PR fortran/96983.

On Wed, Apr 21, 2021 at 10:10:07AM +0200, Tobias Burnus wrote: > On 20.04.21 08:58, Richard Biener via Fortran wrote: > >On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran > > wrote: > Is there any reason to not only send the email to fortran@ _and_ > gcc-patches@ but sending it to 13 Fo

Re: Fix Fortran rounding issues, PR fortran/96983.

On April 22, 2021 9:09:28 PM GMT+02:00, Michael Meissner wrote: >On Wed, Apr 21, 2021 at 10:10:07AM +0200, Tobias Burnus wrote: >> On 20.04.21 08:58, Richard Biener via Fortran wrote: >> >On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran >> > wrote: >> Is there any reason to not only

[Patch] PR fortran/100218 - target of pointer from evaluation of function-reference

Dear Fortranners, while analyzing a different PR (PR100154), Tobias pointed out that the target of a pointer from the evaluation of function-reference is allowed to be used in a variable definition context and thus as an actual argument to a function or subroutine. This seems to be a more general

[Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Dear Fortranners, we need to check the arguments to the affected GNU intrinsic extensions properly, and - as pointed out in the PR by Tobias - we need to allow function references that have a data pointer result. Also the argument names of the character arguments of the subroutine versions needed

[Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Now with the correct patch attached ... Sorry for the confusion! --- Dear Fortranners, we need to check the arguments to the affected GNU intrinsic extensions properly, and - as pointed out in the PR by Tobias - we need to allow function references that have a data pointer result. Also the arg