Am 02.02.2016 um 21:26 schrieb Janus Weil:
Hi all,
here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).
The only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was
Am 03.02.2016 um 19:18 schrieb Janus Weil:
Hi,
2016-02-03 10:21 GMT+01:00 Manfred Schwarb :
here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).
if (source_size < result_size)
-gfc_warn
Hi,
first, I do not have commit rights, so please somebody check and commit,
I guess this goes under the obvious and trivial rules.
There are several malformed dejagnu directives in the gcc.dg testsuite.
Below I fixed some of them following these criteria:
- fix mis-typed directives
- require tha
Am 18.05.20 um 09:35 schrieb Mark Eggleston:
> Please find attached a patch for PR39695 (this time it is attached).
>
> Commit message:
>
> Fortran : ProcPtr function results: 'ppr@' in error message PR39695
>
> The value 'ppr@' is set in the name of result symbol, the actual
> name of the symbol
Am 24.06.20 um 10:12 schrieb Mark Eggleston:
> Please find a fix for PR95829. Original patch by Steve Kargl posted to PR.
>
> Commit to master and backport?
>
> Commit message:
>
> Fortran : Bogus error with additional blanks in type(*) PR95829
>
> Checking for "* ) " instead of "*)" clears the b
Am 07.07.19 um 22:13 schrieb Thomas Koenig:
> 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
Hi,
I still see this issue on 32bit, is the plan to let
the test ISO_Fortran_binding_4.f90 be broken for the 9.0 release?
Cheers,
Manfred
Am 15.04.19 um 10:30 schrieb Dominique d'Humières:
> Hi Paul,
>
> I have found another glitch with -m32 and -O1 or -Os, but not with other
> values:
>
> % g
Dominique, thanks a lot.
I got the request to share my script, so I attached it to this mail.
Be aware that the script reports numerous false positives.
As one can expect, also gcc.dg would appreciate some love...
While cleaning up the script, I found some refinements, and another
7 glitches, see
Am 22.01.2019 um 14:21 schrieb Dominique d'Humières:
>
>
>> Le 22 janv. 2019 à 10:02, Manfred Schwarb a écrit :
>>
>> Dominique, thanks a lot.
>>
>> I got the request to share my script, so I attached it to this mail.
>> Be aware that the script
-- gcc/testsuite/ChangeLog (revision 268292)
> +++ gcc/testsuite/ChangeLog (working copy)
> @@ -1,3 +1,15 @@
> +2019-01-26 Manfred Schwarb
> +
> + * gfortran.dg/array_function_5.f90
> + * gfortran.dg/class_66.f90
> + * gfortran.dg/dec_structure_12.f9
Am 29.05.2017 um 01:16 schrieb Jerry DeLisle:
> Hi all,
>
> The problem here is that we never set the err return to LIBERROR_END in all
> cases. For the example case we are detecting the EOF condition inside the
> read_integer procedure and it gets acted on correctly at higher levels in the
> c
Am 31.05.2013 10:47, schrieb Janus Weil:
Attached is a small patch with an alternative implementation (borrowed
from ada/terminals.c). It is not portable to all systems, but at least
it does actually work on my openSUSE box. Is this something we want to
have for gfortran?
# cat >term.c <
#in
Am 31.05.2013 12:21, schrieb Janus Weil:
Hi Manfred,
Attached is a small patch with an alternative implementation (borrowed
from ada/terminals.c). It is not portable to all systems, but at least
it does actually work on my openSUSE box. Is this something we want to
have for gfortran?
# cat >
Am 31.05.2013 14:28, schrieb Janus Weil:
Wouldn't it work to use the TIOCGWINSZ ioctl only if isatty() reports
that we're outputting to a terminal?
Good point. Updated patch attached, which imposes no limit if we're
not outputting to a terminal (as suggested by Mikael).
Ok for trunk, or am I m
Am 08.03.2014 07:38, schrieb Jerry DeLisle:
The attached patch addresses the problem identified in comment #22 of the PR.
For character array internal unit reads, eat_spaces must call next_char to
advance every single character until the end of the string is reached. In the
case sited which is v
Am 08.03.2014 23:37, schrieb Manfred Schwarb:
Am 08.03.2014 07:38, schrieb Jerry DeLisle:
The attached patch addresses the problem identified in comment #22 of the PR.
For character array internal unit reads, eat_spaces must call next_char to
advance every single character until the end of the
Am 13.01.2013 21:30, schrieb Harald Anlauf:
On 01/12/13 22:02, Mikael Morin wrote:
Le 08/01/2013 22:32, Harald Anlauf a écrit :
On 12/28/12 21:49, Harald Anlauf wrote:
Hello all,
is there a default directive that is assumed when the testsuite is run?
Running an "fgrep -L" on the fortran test
Am 14.01.2013 00:10, schrieb Manfred Schwarb:
Am 13.01.2013 21:30, schrieb Harald Anlauf:
On 01/12/13 22:02, Mikael Morin wrote:
Le 08/01/2013 22:32, Harald Anlauf a écrit :
On 12/28/12 21:49, Harald Anlauf wrote:
Hello all,
is there a default directive that is assumed when the testsuite is
Attached there is a partial patch for the obvious parts, plus other
missed cases (missing options). No failures, just a few more passes
from the fixed dg-do run's.
2013-01-14 Manfred Schwarb
Harald Anlauf
* gfortran.dg/bounds_check_4.f90: Add dg-options "-fbo
Am 14.01.2013 20:49, schrieb Mike Stump:
On Jan 14, 2013, at 6:23 AM, Mikael Morin wrote:
Le 14/01/2013 00:37, Manfred Schwarb a écrit :
Am 14.01.2013 00:10, schrieb Manfred Schwarb:
There are several other oddities: d_g-final, braces have to be
separated by spaces.
Want to send a patch
Am 21.06.2012 14:15, schrieb Tobias Burnus:
On 03/03/2012 08:44 AM, FX wrote [1]:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an enhancement
request for a way to display backtraces from user code.
I wanted to come back to that patch for some while. I think it makes sense t
Hi Janne,
- If the program is privileged, we shouldn't trust path style
environment variables. The patch fixes this for TMPDIR and also for
the logic figuring out where addr2line is.
I did not test it, but if I remember right, the use of geteuid() and friends
does prevent static compilation,
Am 19.04.2012 09:25, schrieb Janne Blomqvist:
On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb wrote:
Hi Janne,
- If the program is privileged, we shouldn't trust path style
environment variables. The patch fixes this for TMPDIR and also for
the logic figuring out where addr2line is.
Hi,
in intrinsic.texi, a lot of tables wrap lines when watching the
resulting info file in a 80char terminal.
Adjust the @columnfractions items to fit screen. Some minor white space
changes are added as well to help saving space.
Signed-off-by Manfred Schwarb
[Note: I do not have commit
the error message. This error message does not appear in the testsuite
AFAIK.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/check.c.orig 2021-10-15 02:20:28.825876592 +0200
+++ gcc/gcc/fortran/check.c 2021-10-29 14:44:51.771512312 +0200
@@ -3240
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl
by
adding an error message in check.c. As far as I can see code support is still
there, though.
Remove documentation for these intrinsics.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access
Hi,
documentation for REAL intrinsic is slightly wrong. Fix it.
Patch is done on top of the column adjustment patch.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/intrinsic.texi.2 2021-10-29 15:08:38.302188947 +0200
+++ gcc/gcc/fortran/intrinsic.texi
Hi,
there were really a lot of test cases provided by Gerhard Steinmetz lately.
Although I'm not really in the position to suggest this,
I would appreciate it, if one could recognize him by adding an entry to
gfortran.texi.
As e.g. in the proposed patch. Such a patch should probably be signed-off
Am 29.10.21 um 21:44 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> in intrinsic.texi, a lot of tables wrap lines when watching the
>> resulting info file in a 80char terminal.
>>
Am 29.10.21 um 21:51 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
>> Kargl by
>> adding an error
Am 29.10.21 um 21:52 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve
>> Kargl by
>> adding an error m
Am 29.10.21 um 21:56 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> documentation for REAL intrinsic is slightly wrong. Fix it.
>> Patch is done on top of the column adjustment patch.
Am 29.10.21 um 21:58 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran:
>> Hi,
>> there were really a lot of test cases provided by Gerhard Steinmetz lately.
>> Although I'm not really in the posi
.
Regtested on Linux x86_64.
Signed-off-by Manfred Schwarb
2021-11-02 Manfred Schwarb
gcc/testsuite/ChangeLog:
PR fortran/91497
* gfortran.dg/pr91497.f90: Adjust test to only use single and
double precision. Add complex intrinsics.
--- a/gcc/testsuite/gfortran.dg/pr91497.f90
+++ b/gcc/testsuite
Am 02.11.21 um 14:26 schrieb Thomas Koenig:
> Hi Manfred,
>
>> In addition to the patches of Steve Kargl for PR 91497:
>> The MIN1 and MAX1 intrinsics do explicit type conversions and should
>> be silenced too for -Wconversion and -Wconversion-extra.
>>
>> Adjust testcase to only use *4 and *8 real
Am 02.11.21 um 19:39 schrieb Thomas Koenig:
> On 02.11.21 15:22, Manfred Schwarb wrote:
>> Am 02.11.21 um 14:26 schrieb Thomas Koenig:
>>> Hi Manfred,
>>>
>>>> In addition to the patches of Steve Kargl for PR 91497:
>>>> The MIN1 and MAX1 intrins
Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran:
> Hi All,
>
> I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
> fruit are already fixed but I have yet to check that they a really fixed
> and to close them:
> pr102106, pr102111, pr104430, pr106048, pr85510, pr874
37 matches
Mail list logo
