(cross talk between
> associate and select type, in particular).
>
> Regtests OK - good for mainline?
>
Paul, you have some "dg-do-run" and "dg-do-compile" statements in your
testcases,
could you change them into their single-minus-sign variants?
Cheers,
Manf
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
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.
>>
>> A
.
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 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 position
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 adjustmen
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: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: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.
>&g
-off my
someone of
the inner circle and not by me ;-)
Cheers,
Manfred
--- gcc/gcc/fortran/gfortran.texi.orig 2021-05-31 03:23:30.069163688 +0200
+++ gcc/gcc/fortran/gfortran.texi 2021-10-29 15:21:39.309279615 +0200
@@ -5888,6 +5888,7 @@ GNU Fortran project:
@item Dominique d'Humi@`eres
@item Kate
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,
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
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,7 +3240,7
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
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
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
that the outermost braces are space padded
- fix imbalanced braces
Several of these changes are no-ops, as nonsensical directives act as "dg-do
compile",
but they should be fixed nevertheless, IMO.
Cheers,
Manfred
diff --git a/gcc/testsuite/gcc.dg/20050121-1.c b/gcc/testsuite/gcc.dg/20
iting to an USB stick or similar? I guess
for flash based devices anything below 64k will slow down operation.
Computers like Raspberry Pi and the like often have flash based storage,
and it is not extremely unrealistic to run fortran programs on them.
Cheers.
Manfred
>
> As this is a change in
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
Am 26.01.2019 um 16:14 schrieb Dominique d'Humières:
> I have committed the following patch to the gcc-7-branch as r268294 after a
> regtest.
> Manfred, could you please check with your script that I did not miss
> some test in the gcc-7 and gcc-8 branches?
In the
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 repor
, see attachment.
could you take care of these as well?
Cheers, Manfred
Am 21.01.2019 um 22:47 schrieb Dominique d'Humières:
> Hi Manfred,
>
>> could someone please check and commit?
>
> Tested and committed as obvious at r268125.
>
> Thanks for the patch.
>
>
On 2/7/2018 4:15 PM, Jonathan Wakely wrote:
On 7 February 2018 at 15:07, Manfred <mx2...@gmail.com> wrote:
On 02/07/2018 02:44 PM, Simon Marchi wrote:
[...]
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think w
es with the same debug identifier.
Regarding 3), I think that after 1) and 2) are set up, GDB should be
able to find the correct type definition (using the most appropriate
design choice).
Hope this helps,
Manfred
[1] According to the findings of Simon, this appears to be the case with
cla
On 2/4/2018 6:01 AM, Simon Marchi wrote:
On 2018-02-03 13:35, Manfred wrote:
n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
...
It looks that for non-type template arguments the template type
equivalence is
new behavior seems to be independent of the m setting,
just bump the constant m by a factor 10 or 100. So you are sure no big iron
can pass this test without your patch being applied.
Thanks a bunch!
Manfred
> OK for trunk?
>
> Regards,
>
> Jerry
>
> 2017-05-28 Jerry
(OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly "
+"undefined result: source size %ld < result size %ld",
+>where, (long) source_size, (long) result_size);
Breaking apart of these strings will probably hamper translation.
Cheers,
Manfred
Am 03.02.2016 um 19:18 schrieb Janus Weil:
Hi,
2016-02-03 10:21 GMT+01:00 Manfred Schwarb <manfre...@gmx.ch>:
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 < re
the user will still
need to do manual LEN_TRIM's when reading larger strings to get
optimal performance...
Thanks,
Manfred
The speedup is accomplished by simply skipping over spaces without calling
next_read, then backing up one character and letting the existing execution path
proceed, preserving
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
this trimming code?
cheers,
Manfred
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
missing anything else? (Testing welcome ...)
needs #include unistd.h for isatty(), perhaps.
Otherwise looks sane at first glance.
Cheers,
Manfred
Cheers,
Janus
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 manfre...@gmx.ch
Harald Anlauf anl...@gmx.de
* gfortran.dg/bounds_check_4.f90: Add
Am 14.01.2013 20:49, schrieb Mike Stump:
On Jan 14, 2013, at 6:23 AM, Mikael Morin mikael.mo...@sfr.fr 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
} } } } }
warning-directive-2.F90:! { dg-message some warnings being treated as errors {target
*-*-*} 0 }
cheers,
Manfred
find gfortran.dg -name *.[fF]90 -o -name *.[fF] | \
xargs fgrep -w -L 'dg-do' | \
xargs head -1 -v
and manual inspection of the resulting output results in:
- Typos
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
.
Name: simply show_backtrace ?
This would be a self-explaining name, the odd QQ in
tracebackqq is just this, odd.
And why call it traceback when it is actually a backtrace ;-)
Cheers,
Manfred
Am 19.04.2012 09:25, schrieb Janne Blomqvist:
On Thu, Apr 19, 2012 at 01:45, Manfred Schwarbmanfre...@gmx.ch 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
?
If this security feature would prevent use of static programs, it would
not be worth it, I think.
Cheers,
Manfred
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
gcc/fortran ChangeLog:
2012-04-19 Janne Blomqvistj...@gcc.gnu.org
* gfortran.texi (GFORTRAN_TMPDIR): Rename to TMPDIR, explain
with Bugzilla.
Please email me directly if you wish.
Manfred
==
Description of presumed bug:
When a temporary is passed as a reference parameter, the copy constructor of
the source object type is apparently invoked without reason. This is
evidenced by a no matching
-dumpmachine I get this
x86_64-redhat-linux
Does anyone have any idea of how I can configure to fix this error or is
there something else I need to fix here? Any replies would be appreciated.
HTH, cheers.
l8er
manfred
Hi there,
On Mon, 19 May 2008, 15:59:16 +0200, FX wrote:
[...]
Any comments? Is it OK to commit as is?
this may sound like nit-picking, but the length of a string cannot be
negative, so, I'd rather make the new parameter `len' an unsigned int
or even size_t.
HTH, cheers.
l8er
manfred
evaluates to true,
control flow jumps out of the function, hence the following 'if' is
totally correct (unless someone #define's return to something else...),
or do the GCC/FSF codings conventions require this to be 'else if'?
Diego.
Cheers.
l8er
manfred
absolutely no idea why apparently nobody else is seeing this,
though.
The patch below fixes it for me. OK to check in?
Cheers.
l8er
manfred
boehm-gc/ChangeLog:
2007-11-13 Manfred Hollstein [EMAIL PROTECTED]
* Makefile.ac (LTCOMPILE): Add missing --tag=CC argument;
wrap line to fit
to
proceed further?
Should I post the code of this function here on the list (~300 LOC)?
Thanks,
Manfred
=33638
I first hoped to get help to narrow things a bit further, as my
problem is really a bit strange, so I decided to first write an email.
I simply assigned it now to the middle-end, but of course it could
also be a gfortran issue.
Thanks,
Manfred
--
Ist Ihr Browser Vista-kompatibel? Jetzt die
On Wed, Oct 03, 2007 at 12:24:27PM +0200, Manfred Schwarb wrote:
I'm in a loss where to search for the real cause. Has anybody a hint
how to proceed further?
Sounds like weird-but-somewhat-determinist behaviour you can get when
you do out-of-bounds access on the stack or this kind
| I'd encourage you to work up a solid proposal for ISO/ANSI and
| propose it there.
Being a newbie, I'd appreciate contact/site details for submissions to the
ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]).
I will be happy to draft and submit a proposal, including a hopefully
and initialisation code). This will introduce problems when linking code
generated by different versions of the compiler.
Manfred von Willich
function before main and check again. If you look at the other symbols
generated by GCC, you will see that it also creates a globally visible
symbol for main.
Thanks,
Inder
HTH, cheers.
l8er
manfred
,
then do a gmake bootstrap. The only exception to this process
is when I'm making small changes to gfortran files where I know
a gmake bubblestrap will not run into problems.
I suspect the commit that broken gfortran is
2005-07-22 Manfred Hollstein [EMAIL PROTECTED
53 matches
Mail list logo
