Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Manfred Schwarb via Gcc-patches]

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, pr87460, pr92960 & pr93338
>
> The attached patch picks up those PRs involving deferred length characters
> in one guise or another. I believe that it is all pretty straightforward.
> Structure constructors with allocatable, deferred length, character array
> components just weren't implemented and so this is the biggest part of the
> patch. I found two other, non-associate PRs(106918 &  105205) that are
> fixed and there are probably more.
>
> The chunk in trans-io.cc is something of a kludge, which I will come back
> to. Some descriptors come through with a data pointer that looks as if it
> should be OK but
>
> I thought to submit this now to get it out of the way. The ratio of PRs
> fixed to the size of the patch warrants this. The next stage is going to be
> rather messy and so "I might take a little while" (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,
Manfred


BTW: I just ran my script again and found the following testsuite issues (note 
that outer-most
braces need to be space-padded):

./c-interop/removed-restrictions-1.f90:! { dg-do compile}
./c-interop/removed-restrictions-2.f90:! { dg-do compile}
./c-interop/removed-restrictions-3.f90:! { dg-do compile}
./c-interop/removed-restrictions-4.f90:! { dg-do compile}
./c-interop/tkr.f90:! { dg-do compile}
./c-interop/c407c-1.f90:! { dg-do compile}
./c-interop/deferred-character-1.f90:! { dg-do compile}
./c-interop/allocatable-optional-pointer.f90:! { dg-do compile}
./c-interop/c407a-1.f90:! { dg-do compile}
./c-interop/c407b-1.f90:! { dg-do compile}
./c-interop/c407b-2.f90:! { dg-do compile}
./c-interop/c535a-1.f90:! { dg-do compile}
./c-interop/c535a-2.f90:! { dg-do compile}
./c-interop/c535b-1.f90:! { dg-do compile}
./c-interop/c535b-2.f90:! { dg-do compile}
./c-interop/c535b-3.f90:! { dg-do compile}
./c-interop/c535c-1.f90:! { dg-do compile}
./c-interop/c535c-2.f90:! { dg-do compile}
./gomp/affinity-clause-1.f90:! { dg final { scan-tree-dump-times "#pragma omp 
task affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* 
? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) 
i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* 
6\\\]\\)"  1 "original" } }
./class_result_10.f90:! { dg-do run}
./pr103258.f90:! { dg-do compile}
./dtio_35.f90:! { dg-compile }
./pr93835.f08:! {dg-do run }
./pr59107.f90:! { dg-compile }



> Cheers
>
> Paul
>
> Fortran: Fix some of the bugs in associate [PR87477]
>
> 2023-03-28  Paul Thomas  
>
> gcc/fortran
> PR fortran/87477
> * trans-array.cc (gfc_conv_expr_descriptor): Guard string len
> expression in condition.
> (duplicate_allocatable): Make element type more explicit with
> 'eltype'.
> * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in
> 'previous' and use if end expression in substring reference is
> null.
> (gfc_conv_string_length): Use gfc_conv_expr_descriptor if
> 'expr_flat' is an array.
> (gfc_trans_alloc_subarray_assign): If this is a deferred string
> length component, store the string length in the hidden comp.
> Update the typespec length accordingly. Generate a new type
> spec for the call to gfc_duplicate-allocatable in this case.
> * trans-io.cc (gfc_trans_transfer): Scalarize transfer of
> deferred character array components.
>
>
> gcc/testsuite/
> PR fortran/92994
> * gfortran.dg/finalize_51.f90 : Update an error message.
>
> PR fortran/85686
> * gfortran.dg/pr85686.f90 : New test
>
> PR fortran/88247
> * gfortran.dg/pr88247.f90 : New test
>
> PR fortran/91941
> * gfortran.dg/pr91941.f90 : New test
>
> PR fortran/92779
> * gfortran.dg/pr92779.f90 : New test
>
> PR fortran/93339
> * gfortran.dg/pr93339.f90 : New test
>
> PR fortran/93813
> * gfortran.dg/pr93813.f90 : New test
>
> PR fortran/100948
> * gfortran.dg/pr100948.f90 : New test
>
> PR fortran/102106
> * gfortran.dg/pr102106.f90 : New test
>
> PR fortran/105205
> * gfortran.dg/pr105205.f90 : New test
>
> PR fortran/106918
> * gfortran.dg/pr106918.f90 : New test

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

[Manfred Schwarb via Gcc-patches]

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 intrinsics do explicit type conversions and should
>>>> be silenced too for -Wconversion and -Wconversion-extra.
>>>>
>>>> Adjust testcase to only use *4 and *8 real types, provide a second
>>>> testcase for *10 and *16 precisions.
>>> Two points:
>>>
>>> We should modify existing test cases only when necessary, because
>>> modification can impede a regression test.  It is better to create
>>> a new one.
>>>

I only changed the test case to use dg-require-effective-target and real(n) 
notation now.

Added a second case without real(10) and real(16), but for all targets, which
covers MIN1 and MAX1 too.


>>
>> Yes, but this was a quick-and-dirty test of mine, and I realized only 
>> afterwards
>> that Steve had used it as-is. The new testcase is more consistent and more 
>> complete.
>> Sandra got errors on targets without REAL(16) support and requested changes,
>> so I decided to split it.
>>
>> So you want me to "split" it in 3 parts?
>> - existing test as is, only for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for all targets, only single and 
>> double precision
>>
>> OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, 
>> either
>> it warns or it does not.
>
> Anything that tests both complex and REAL(16) is fine by me.  I don't
> think you need to test the combination of COMPLEX(16), both
> codepaths have been seen by that time :-)
>
> Or you can split it three ways, like you wrote above.
>
>>> While we do recognize real*4 and real*8 and so on, these are
>>> non-standard extensions, and I would like to avoid to have these
>>> with new test cases.
>>>
>>> Instead of real*8, you can use real(8) or double precision.
>>>
>>
>> Well, double precision is deprecated AFAIK.
>
> Not in Fortran 2018.
>
> Best regards
>
>   Thomas
>

2021-11-06  Manfred Schwarb  

gcc/fortran/ChangeLog:

	PR fortran/91497
	* simplify.c (simplify_min_max): Disable conversion warnings for
	MIN1 and MAX1.

--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5087,6 +5087,7 @@ min_max_choose (gfc_expr *arg, gfc_expr
 static gfc_expr *
 simplify_min_max (gfc_expr *expr, int sign)
 {
+  int tmp1, tmp2;
   gfc_actual_arglist *arg, *last, *extremum;
   gfc_expr *tmp, *ret;
   const char *fname;
@@ -5131,7 +5132,16 @@ simplify_min_max (gfc_expr *expr, int si
   if ((tmp->ts.type != BT_INTEGER || tmp->ts.kind != gfc_integer_4_kind)
   && (strcmp (fname, "min1") == 0 || strcmp (fname, "max1") == 0))
 {
+  /* Explicit conversion, turn off -Wconversion and -Wconversion-extra
+ warnings.  */
+  tmp1 = warn_conversion;
+  tmp2 = warn_conversion_extra;
+  warn_conversion = warn_conversion_extra = 0;
+
   ret = gfc_convert_constant (tmp, BT_INTEGER, gfc_integer_4_kind);
+
+  warn_conversion = tmp1;
+  warn_conversion_extra = tmp2;
 }
   else if ((tmp->ts.type != BT_REAL || tmp->ts.kind != gfc_real_4_kind)
 	   && (strcmp (fname, "amin0") == 0 || strcmp (fname, "amax0") == 0))
2021-11-06  Manfred Schwarb  

gcc/testsuite/ChangeLog:

	PR fortran/91497
	* gfortran.dg/pr91497.f90: Adjust test to use
	dg-require-effective-target directive.
	* gfortran.dg/pr91497_2.f90: New test to cover all targets.
	Cover MAX1 and MIN1 intrinsics.

--- a/gcc/testsuite/gfortran.dg/pr91497.f90
+++ b/gcc/testsuite/gfortran.dg/pr91497.f90
@@ -1,4 +1,6 @@
-! { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+! { dg-do compile }
+! { dg-require-effective-target fortran_real_10 }
+! { dg-require-effective-target fortran_real_16 }
 ! { dg-options "-Wall" }
 ! Code contributed by Manfred Schwarb 
 ! PR fortran/91497
@@ -8,13 +10,13 @@
 !
 program foo

-  real*4 a,aa
-  real*8 b,bb
-  real*10 c,cc
-  real*16 d
-  integer*2 e,ee
-  integer*4 f,ff
-  integer*8 g,gg
+  real(4) a,aa
+  real(8) b,bb
+  real(10) c,cc
+  real(16) d
+  integer(2) e,ee
+  integer(4) f,ff
+  integer(8) g,gg
   PARAMETER(a=3.1415927_4)
   PARAMETER(b=3.1415927_8)
   PARAMETER(c=3.1415927_10)
@@ -36,11 +38,10 @@ program foo
   aa=CEILING(b)
   aa=CEILING(c)
   aa=CEILING(d)
-  !---unknown but documented type conversions:
+  !---DEC spec

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

[Manfred Schwarb via Gcc-patches]

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 types, provide a second
>> testcase for *10 and *16 precisions.
> Two points:
>
> We should modify existing test cases only when necessary, because
> modification can impede a regression test.  It is better to create
> a new one.
>

Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards
that Steve had used it as-is. The new testcase is more consistent and more 
complete.
Sandra got errors on targets without REAL(16) support and requested changes,
so I decided to split it.

So you want me to "split" it in 3 parts?
- existing test as is, only for targets with REAL(16) support
- additional tests incl. complex intrinsics for targets with REAL(16) support
- additional tests incl. complex intrinsics for all targets, only single and 
double precision

OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, 
either
it warns or it does not.

> While we do recognize real*4 and real*8 and so on, these are
> non-standard extensions, and I would like to avoid to have these
> with new test cases.
>
> Instead of real*8, you can use real(8) or double precision.
>

Well, double precision is deprecated AFAIK.

> OK with these changes to the test cases.
>
> Thanks for the patch!
>
> Best regards
>
> Thomas

[PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

[Manfred Schwarb via Gcc-patches]

Hi,

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 types, provide a second
testcase for *10 and *16 precisions.

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/gfortran.dg/pr91497.f90
@@ -1,4 +1,4 @@
-! { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+! { dg-do compile }
 ! { dg-options "-Wall" }
 ! Code contributed by Manfred Schwarb 
 ! PR fortran/91497
@@ -8,120 +8,120 @@
 !
 program foo

-  real*4 a,aa
-  real*8 b,bb
-  real*10 c,cc
-  real*16 d
-  integer*2 e,ee
-  integer*4 f,ff
-  integer*8 g,gg
+  real*4 a, aa
+  real*8 b, bb
+  integer*2 e, ee
+  integer*4 f, ff
+  integer*8 g, gg
+  complex(4) ww
+  complex(8) xx
   PARAMETER(a=3.1415927_4)
   PARAMETER(b=3.1415927_8)
-  PARAMETER(c=3.1415927_10)
-  PARAMETER(d=3.1415927_16)
   PARAMETER(e=123_2)
   PARAMETER(f=123_4)
   PARAMETER(g=123_8)

-  aa=REAL(b)
-  aa=REAL(c)
-  aa=REAL(d)
+  aa=REAL(b)! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
   aa=REAL(e)
   aa=REAL(f)
   aa=REAL(g)
+  aa=REAL(b, kind=4)   ! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
+  bb=REAL(a, kind=8)
+
   aa=FLOAT(f)
-  aa=FLOOR(b)
-  aa=FLOOR(c)
-  aa=FLOOR(d)
-  aa=CEILING(b)
-  aa=CEILING(c)
-  aa=CEILING(d)
-  !---unknown but documented type conversions:
-  !!aa=FLOATI(e)
-  !!aa=FLOATJ(f)
-  !!aa=FLOATK(g)
-  !---documentation is wrong for sngl:
-  aa=SNGL(c)
-  aa=SNGL(d)
-  bb=REAL(c, kind=8)
-  bb=REAL(d, kind=8)
-  bb=DBLE(c)
-  bb=DBLE(d)
   bb=DFLOAT(g)
-  bb=FLOOR(c)
-  bb=FLOOR(d)
-  bb=CEILING(c)
-  bb=CEILING(d)
-  cc=REAL(d, kind=10)
-  cc=FLOOR(d)
-  cc=CEILING(d)
-
-  aa=AINT(b)
-  aa=ANINT(b)
-  aa=AINT(c)
-  aa=ANINT(c)
-  aa=AINT(d)
-  aa=ANINT(d)
+  aa=SNGL(b)! was: Change of value in conversion from 'REAL(8)' to 'REAL(4)'
+  aa=AINT(a)
+  bb=AINT(b)
+  aa=AINT(b, kind=4)
   bb=DINT(b)
+  aa=ANINT(a)
+  bb=ANINT(b)
+  aa=ANINT(b, kind=4)
   bb=DNINT(b)
-
-  ee=INT(a, kind=2)
-  ee=NINT(a, kind=2)
-  ee=INT(b, kind=2)
-  ee=NINT(b, kind=2)
-  ee=INT(c, kind=2)
-  ee=NINT(c, kind=2)
-  ee=INT(d, kind=2)
-  ee=NINT(d, kind=2)
+  !---DEC type conversions (-fdec):
+  !!aa=FLOATI(e)
+  !!aa=FLOATJ(f)
+  !!aa=FLOATK(g)
+  aa=AMAX0(f, f)
+  aa=AMIN0(f, f)
+  aa=AMAX0(g, g)
+  aa=AMIN0(g, g)
+
+  ee=INT(a)
+  ee=INT(a, kind=2)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(2)'
+  ee=INT(b, kind=2)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(2)'
   ee=INT(f, kind=2)
   ee=INT(g, kind=2)
+  ff=INT(b)
+  ff=INT(a, kind=4)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+  ff=INT(b, kind=4)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(4)'
+  ff=INT(f, kind=4)
+  ff=INT(g, kind=4)
+  gg=INT(a)
+  gg=INT(a, kind=8)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(8)'
+  gg=INT(b, kind=8)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(8)'
+  gg=INT(f, kind=8)
+  gg=INT(g, kind=8)
+
   ee=IFIX(a)
+  ff=IFIX(a)
+  gg=IFIX(a)
   ee=IDINT(b)
-  ee=IDNINT(b)
-  ee=INT2(a)
-  ee=INT2(b)
-  ee=INT2(c)
-  ee=INT2(d)
+  ff=IDINT(b)
+  gg=IDINT(b)
+  ee=INT2(a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(2)'
+  ee=INT2(b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(2)'
   ee=INT2(f)
   ee=INT2(g)
+  gg=INT8(a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(8)'
+  gg=INT8(b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(8)'
+  gg=INT8(f)
+  gg=INT8(g)
+
+  ff=FLOOR(b)
+  ee=FLOOR(b, kind=2)
+  ff=FLOOR(b, kind=4)
+  gg=FLOOR(b, kind=8)
+  ff=CEILING(b)
+  ee=CEILING(b, kind=2)
+  ff=CEILING(b, kind=4)
+  gg=CEILING(b, kind=8)
+  ff=MAX1(a, a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+  ff=MIN1(a, a)! was: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)'
+  gg=MAX1(b, b)! was: Change of value in conversion from 'REAL(8)' to 'INTEGER(4)'
+  gg=MIN1(b, b)! was: Change of value in conversion from 'REAL(8)' to 

Re: [PATCH] Fortran: recognize Gerhard Steinmetz

[Manfred Schwarb via Gcc-patches]

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 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 my 
>> someone of
>> the inner circle and not by me ;-)
>
> well, this is sth. close to obvious to everybody. ;-)
> Anyway, a ChangeLog entry would be nice.

I would feel more comfortable if such a patch would origin from somebody else, 
not from me, actually.

>
> Harald
>
>> Cheers,
>> Manfred
>>
>
>

Re: [PATCH] Fortran: Correct documentation for REAL intrinsic

[Manfred Schwarb via Gcc-patches]

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.
>
> the patch looks fine, but it would help a lot to have a ChangeLog entry.

Sorry, forgot the changelog entry, I added it to the patch now.

>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb 
>>
>>
>> [Note: I do not have commit access]
>>
>
>

2021-10-30  Manfred Schwarb  

gcc/fortran/ChangeLog:

	* intrinsic.texi (REAL): Fix entries in Specific names table.

--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -12251,12 +12255,12 @@ end program test_real
 @item @emph{Specific names}:
 @multitable @columnfractions .20 .23 .20 .33
 @headitem Name @tab Argument   @tab Return type @tab Standard
-@item @code{FLOAT(A)}  @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension
+@item @code{FLOAT(A)}  @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab Fortran 77 and later
 @item @code{DFLOAT(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(8)}  @tab GNU extension
-@item @code{FLOATI(A)} @tab @code{INTEGER(2)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{FLOATJ(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{FLOATK(A)} @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{SNGL(A)}   @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension
+@item @code{FLOATI(A)} @tab @code{INTEGER(2)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{FLOATJ(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{FLOATK(A)} @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{SNGL(A)}   @tab @code{REAL(8)} @tab @code{REAL(4)}  @tab Fortran 77 and later
 @end multitable

Re: [PATCH] Fortran: Remove documentation for SHORT and LONG intrinics

[Manfred Schwarb via Gcc-patches]

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 message in check.c.  As far as I can see code support is 
>> still there, though.
>>
>> Remove documentation for these intrinsics.
>
> could you please provide a formatted patch that applies using git apply?
> And a ChangeLog entry?

Sorry, forgot the changelog entry, I added it to the patch now.

>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb 
>>
>>
>> [Note: I do not have commit access]
>>
>
>

2021-10-30  Manfred Schwarb  

gcc/fortran/ChangeLog:

	* intrinsic.texi: Remove entries for SHORT and LONG intrinsics.

--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -221,7 +221,6 @@ Some basic guidelines for editing this d
 * @code{LOG10}: LOG10, Base 10 logarithm function
 * @code{LOG_GAMMA}: LOG_GAMMA, Logarithm of the Gamma function
 * @code{LOGICAL}:   LOGICAL,   Convert to logical type
-* @code{LONG}:  LONG,  Convert to integer type
 * @code{LSHIFT}:LSHIFT,Left shift bits
 * @code{LSTAT}: LSTAT, Get file status
 * @code{LTIME}: LTIME, Convert time to local time info
@@ -8372,7 +8371,6 @@ end program
 @node INT2
 @section @code{INT2} --- Convert to 16-bit integer type
 @fnindex INT2
-@fnindex SHORT
 @cindex conversion, to integer

 @table @asis
@@ -8381,8 +8379,6 @@ Convert to a @code{KIND=2} integer type.
 standard @code{INT} intrinsic with an optional argument of
 @code{KIND=2}, and is only included for backwards compatibility.

-The @code{SHORT} intrinsic is equivalent to @code{INT2}.
-
 @item @emph{Standard}:
 GNU extension

@@ -8403,8 +8399,7 @@ The return value is a @code{INTEGER(2)}

 @item @emph{See also}:
 @ref{INT}, @gol
-@ref{INT8}, @gol
-@ref{LONG}
+@ref{INT8}
 @end table


@@ -8440,8 +8435,7 @@ The return value is a @code{INTEGER(8)}

 @item @emph{See also}:
 @ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{LONG}
+@ref{INT2}
 @end table


@@ -9848,44 +9842,6 @@ kind corresponding to @var{KIND}, or of
 @end table


-
-@node LONG
-@section @code{LONG} --- Convert to integer type
-@fnindex LONG
-@cindex conversion, to integer
-
-@table @asis
-@item @emph{Description}:
-Convert to a @code{KIND=4} integer type, which is the same size as a C
-@code{long} integer.  This is equivalent to the standard @code{INT}
-intrinsic with an optional argument of @code{KIND=4}, and is only
-included for backwards compatibility.
-
-@item @emph{Standard}:
-GNU extension
-
-@item @emph{Class}:
-Elemental function
-
-@item @emph{Syntax}:
-@code{RESULT = LONG(A)}
-
-@item @emph{Arguments}:
-@multitable @columnfractions .15 .70
-@item @var{A}@tab Shall be of type @code{INTEGER},
-@code{REAL}, or @code{COMPLEX}.
-@end multitable
-
-@item @emph{Return value}:
-The return value is a @code{INTEGER(4)} variable.
-
-@item @emph{See also}:
-@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{INT8}
-@end table
-
-

 @node LSHIFT
 @section @code{LSHIFT} --- Left shift bits

Re: [PATCH] Fortran: adjust error message for SHORT and LONG intrinsics

[Manfred Schwarb via Gcc-patches]

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 message in check.c.  However, the error message
>>Error: 'long' intrinsic subprogram at (1) has been deprecated
>> is misleading, as support has been disabled by this patch.
>>
>> Adjust the error message. This error message does not appear in the 
>> testsuite AFAIK.
>
> the patch looks fine.  A testcase checking the error message is missing,
> as well as a ChangeLog entry.

Sorry, forgot the changelog entry, I added it to the patch now.
Testcase was missing already before, but I added a trivial test to the patch 
for completeness.

>
> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb 
>>
>>
>> [Note: I do not have commit access]
>>
>
>

2021-10-30  Manfred Schwarb  

gcc/fortran/ChangeLog:

	* check.c (gfc_check_intconv): Change error message.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intrinsic_short-long.f90: New test.

--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3240,7 +3240,7 @@ gfc_check_intconv (gfc_expr *x)
   if (strcmp (gfc_current_intrinsic, "short") == 0
   || strcmp (gfc_current_intrinsic, "long") == 0)
 {
-  gfc_error ("%qs intrinsic subprogram at %L has been deprecated.  "
+  gfc_error ("%qs intrinsic subprogram at %L has been removed.  "
 		 "Use INT intrinsic subprogram.", gfc_current_intrinsic,
 		 >where);
   return false;
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intrinsic_short-long.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! Checking for removal of SHORT and LONG intrinsics.
+!
+  real,parameter :: a=3.1415927
+  integer :: i
+
+  i=SHORT(a) ! { dg-error "has been removed" }
+  i=LONG(a)  ! { dg-error "has been removed" }
+
+  end

Re: [PATCH] Fortran: adjust column sizes in intrinsic.texi

[Manfred Schwarb via Gcc-patches]

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.
>>
>> Adjust the @columnfractions items to fit screen. Some minor white space
>> changes are added as well to help saving space.
>
> the patch looks fine.  However, could you please provide a properly
> formatted patch that applies using git patch and a ChangeLog entry?
>

Sorry, forgot the changelog entry, I added it to the patch now.

> Thanks,
> Harald
>
>> Signed-off-by Manfred Schwarb 
>>
>>
>> [Note: I do not have commit access]
>>
>
>

2021-10-30  Manfred Schwarb  

gcc/fortran/ChangeLog:

	* intrinsic.texi: Adjust @columnfractions commands to improve
	appearance for narrow 80 character terminals.

--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -461,7 +461,7 @@ end program test_abs
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument@tab Return type   @tab Standard
 @item @code{ABS(A)}   @tab @code{REAL(4) A}@tab @code{REAL(4)}@tab Fortran 77 and later
 @item @code{CABS(A)}  @tab @code{COMPLEX(4) A} @tab @code{REAL(4)}@tab Fortran 77 and later
@@ -626,7 +626,7 @@ end program test_acos
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type @tab Standard
 @item @code{ACOS(X)}  @tab @code{REAL(4) X} @tab @code{REAL(4)}  @tab Fortran 77 and later
 @item @code{DACOS(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}  @tab Fortran 77 and later
@@ -685,7 +685,7 @@ end program test_acosd
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type @tab Standard
 @item @code{ACOSD(X)}  @tab @code{REAL(4) X} @tab @code{REAL(4)}  @tab GNU extension
 @item @code{DACOSD(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}  @tab GNU extension
@@ -741,7 +741,7 @@ END PROGRAM
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name @tab Argument  @tab Return type   @tab Standard
 @item @code{DACOSH(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab GNU extension
 @end multitable
@@ -890,7 +890,7 @@ end program test_aimag
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name   @tab Argument@tab Return type @tab Standard
 @item @code{AIMAG(Z)}@tab @code{COMPLEX Z}@tab @code{REAL} @tab Fortran 77 and later
 @item @code{DIMAG(Z)}@tab @code{COMPLEX(8) Z} @tab @code{REAL(8)}  @tab GNU extension
@@ -950,7 +950,7 @@ end program test_aint
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name   @tab Argument @tab Return type  @tab Standard
 @item @code{AINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab Fortran 77 and later
 @item @code{DINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)}   @tab Fortran 77 and later
@@ -1230,7 +1230,7 @@ end program test_anint
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type  @tab Standard
 @item @code{ANINT(A)}  @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab Fortran 77 and later
 @item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)}   @tab Fortran 77 and later
@@ -1346,7 +1346,7 @@ end program test_asin
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument  @tab Return type   @tab Standard
 @item @code{ASIN(X)}  @tab @code{REAL(4) X}  @tab @code{REAL(4)}@tab Fortran 77 and later
 @item @code{DASIN(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab Fortran 77 and later
@@ -1405,7 +1405,7 @@ end program test_asind
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument  @tab Return type   @tab Standard
 @item @code{ASIND(X)}  @tab @code{REAL(4) X}  @tab @code{REAL(4)}@tab GNU extension
 @item @code{DASIND(

[PATCH] Fortran: recognize Gerhard Steinmetz

[Manfred Schwarb via Gcc-patches]

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 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 Hedstrom
 @item Erik Schnetter
+@item Gerhard Steinmetz
 @item Joost VandeVondele
 @end itemize

[PATCH] Fortran: Correct documentation for REAL intrinsic

[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.

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	2021-10-29 15:14:57.111458299 +0200
@@ -12251,12 +12255,12 @@ end program test_real
 @item @emph{Specific names}:
 @multitable @columnfractions .20 .23 .20 .33
 @headitem Name @tab Argument   @tab Return type @tab Standard
-@item @code{FLOAT(A)}  @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension
+@item @code{FLOAT(A)}  @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab Fortran 77 and later
 @item @code{DFLOAT(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(8)}  @tab GNU extension
-@item @code{FLOATI(A)} @tab @code{INTEGER(2)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{FLOATJ(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{FLOATK(A)} @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension
-@item @code{SNGL(A)}   @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension
+@item @code{FLOATI(A)} @tab @code{INTEGER(2)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{FLOATJ(A)} @tab @code{INTEGER(4)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{FLOATK(A)} @tab @code{INTEGER(8)}  @tab @code{REAL(4)}  @tab GNU extension (-fdec)
+@item @code{SNGL(A)}   @tab @code{REAL(8)} @tab @code{REAL(4)}  @tab Fortran 77 and later
 @end multitable

[PATCH] Fortran: Remove documentation for SHORT and LONG intrinics

[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 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]
--- gcc/gcc/fortran/intrinsic.texi.1	2021-10-29 14:24:46.102169856 +0200
+++ gcc/gcc/fortran/intrinsic.texi.2	2021-10-29 15:08:38.302188947 +0200
@@ -221,7 +221,6 @@ Some basic guidelines for editing this d
 * @code{LOG10}: LOG10, Base 10 logarithm function
 * @code{LOG_GAMMA}: LOG_GAMMA, Logarithm of the Gamma function
 * @code{LOGICAL}:   LOGICAL,   Convert to logical type
-* @code{LONG}:  LONG,  Convert to integer type
 * @code{LSHIFT}:LSHIFT,Left shift bits
 * @code{LSTAT}: LSTAT, Get file status
 * @code{LTIME}: LTIME, Convert time to local time info
@@ -8372,7 +8371,6 @@ end program
 @node INT2
 @section @code{INT2} --- Convert to 16-bit integer type
 @fnindex INT2
-@fnindex SHORT
 @cindex conversion, to integer

 @table @asis
@@ -8381,8 +8379,6 @@ Convert to a @code{KIND=2} integer type.
 standard @code{INT} intrinsic with an optional argument of
 @code{KIND=2}, and is only included for backwards compatibility.

-The @code{SHORT} intrinsic is equivalent to @code{INT2}.
-
 @item @emph{Standard}:
 GNU extension

@@ -8403,8 +8399,7 @@ The return value is a @code{INTEGER(2)}

 @item @emph{See also}:
 @ref{INT}, @gol
-@ref{INT8}, @gol
-@ref{LONG}
+@ref{INT8}
 @end table


@@ -8440,8 +8435,7 @@ The return value is a @code{INTEGER(8)}

 @item @emph{See also}:
 @ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{LONG}
+@ref{INT2}
 @end table


@@ -9848,44 +9842,6 @@ kind corresponding to @var{KIND}, or of
 @end table


-
-@node LONG
-@section @code{LONG} --- Convert to integer type
-@fnindex LONG
-@cindex conversion, to integer
-
-@table @asis
-@item @emph{Description}:
-Convert to a @code{KIND=4} integer type, which is the same size as a C
-@code{long} integer.  This is equivalent to the standard @code{INT}
-intrinsic with an optional argument of @code{KIND=4}, and is only
-included for backwards compatibility.
-
-@item @emph{Standard}:
-GNU extension
-
-@item @emph{Class}:
-Elemental function
-
-@item @emph{Syntax}:
-@code{RESULT = LONG(A)}
-
-@item @emph{Arguments}:
-@multitable @columnfractions .15 .70
-@item @var{A}@tab Shall be of type @code{INTEGER},
-@code{REAL}, or @code{COMPLEX}.
-@end multitable
-
-@item @emph{Return value}:
-The return value is a @code{INTEGER(4)} variable.
-
-@item @emph{See also}:
-@ref{INT}, @gol
-@ref{INT2}, @gol
-@ref{INT8}
-@end table
-
-

 @node LSHIFT
 @section @code{LSHIFT} --- Left shift bits

[PATCH] Fortran: adjust error message for SHORT and LONG intrinsics

[Manfred Schwarb via Gcc-patches]

Hi,

on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve 
Kargl by
adding an error message in check.c.  However, the error message
  Error: 'long' intrinsic subprogram at (1) has been deprecated
is misleading, as support has been disabled by this patch.

Adjust 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,7 +3240,7 @@ gfc_check_intconv (gfc_expr *x)
   if (strcmp (gfc_current_intrinsic, "short") == 0
   || strcmp (gfc_current_intrinsic, "long") == 0)
 {
-  gfc_error ("%qs intrinsic subprogram at %L has been deprecated.  "
+  gfc_error ("%qs intrinsic subprogram at %L has been removed.  "
 		 "Use INT intrinsic subprogram.", gfc_current_intrinsic,
 		 >where);
   return false;

[PATCH] Fortran: adjust column sizes in intrinsic.texi

[Manfred Schwarb via Gcc-patches]

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 access]
--- gcc/gcc/fortran/intrinsic.texi.orig	2021-09-18 03:19:23.645913785 +0200
+++ gcc/gcc/fortran/intrinsic.texi.1	2021-10-29 14:24:46.102169856 +0200
@@ -461,7 +461,7 @@ end program test_abs
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument@tab Return type   @tab Standard
 @item @code{ABS(A)}   @tab @code{REAL(4) A}@tab @code{REAL(4)}@tab Fortran 77 and later
 @item @code{CABS(A)}  @tab @code{COMPLEX(4) A} @tab @code{REAL(4)}@tab Fortran 77 and later
@@ -626,7 +626,7 @@ end program test_acos
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type @tab Standard
 @item @code{ACOS(X)}  @tab @code{REAL(4) X} @tab @code{REAL(4)}  @tab Fortran 77 and later
 @item @code{DACOS(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}  @tab Fortran 77 and later
@@ -685,7 +685,7 @@ end program test_acosd
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type @tab Standard
 @item @code{ACOSD(X)}  @tab @code{REAL(4) X} @tab @code{REAL(4)}  @tab GNU extension
 @item @code{DACOSD(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}  @tab GNU extension
@@ -741,7 +741,7 @@ END PROGRAM
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name @tab Argument  @tab Return type   @tab Standard
 @item @code{DACOSH(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab GNU extension
 @end multitable
@@ -890,7 +890,7 @@ end program test_aimag
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name   @tab Argument@tab Return type @tab Standard
 @item @code{AIMAG(Z)}@tab @code{COMPLEX Z}@tab @code{REAL} @tab Fortran 77 and later
 @item @code{DIMAG(Z)}@tab @code{COMPLEX(8) Z} @tab @code{REAL(8)}  @tab GNU extension
@@ -950,7 +950,7 @@ end program test_aint
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name   @tab Argument @tab Return type  @tab Standard
 @item @code{AINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab Fortran 77 and later
 @item @code{DINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)}   @tab Fortran 77 and later
@@ -1230,7 +1230,7 @@ end program test_anint
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument @tab Return type  @tab Standard
 @item @code{ANINT(A)}  @tab @code{REAL(4) A} @tab @code{REAL(4)}   @tab Fortran 77 and later
 @item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)}   @tab Fortran 77 and later
@@ -1346,7 +1346,7 @@ end program test_asin
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument  @tab Return type   @tab Standard
 @item @code{ASIN(X)}  @tab @code{REAL(4) X}  @tab @code{REAL(4)}@tab Fortran 77 and later
 @item @code{DASIN(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab Fortran 77 and later
@@ -1405,7 +1405,7 @@ end program test_asind
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name@tab Argument  @tab Return type   @tab Standard
 @item @code{ASIND(X)}  @tab @code{REAL(4) X}  @tab @code{REAL(4)}@tab GNU extension
 @item @code{DASIND(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab GNU extension
@@ -1461,7 +1461,7 @@ END PROGRAM
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable @columnfractions .20 .23 .20 .33
 @headitem Name @tab Argument  @tab Return type   @tab Standard
 @item @code{DASINH(X)} @tab @code{REAL(8) X}  @tab @code{REAL(8)}@tab GNU extension.
 @end multitable
@@ -1597,7 +1597,7 @@ end program test_atan
 @end smallexample

 @item @emph{Specific names}:
-@multitable @columnfractions .20 .20 .20 .25
+@multitable

Re: [PATCH] Fortran : Bogus error with additional blanks in type(*) PR95829

[Manfred Schwarb]

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 bogus error.
>
> 2020-06-24  Steven G. Kargl  
>
> gcc/fortran/
>
>     PR fortran/95829
>     * decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead
>     of "*)".
>
> 2020-06-24  Mark Eggleston 
>
> gcc/testsuite/
>
>     PR fortran/95829
>     * gfortran.dg/pr95829.f90: New test.
>

@@ -0,0 +1,14 @@
+! {dg-do compile }
+!
+! Declaration of b used to be a bogus failure.

{ dg-do compile }

with surrounding spaces, otherwise this dg-directive will not be recognized.

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

[Manfred Schwarb]

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 is in the procedure name symbol pointed
> to by the result symbol's namespace (ns). When reporting errors for
> symbols that have the proc_pointer attribute check whether the
> result attribute is set and set the name accordingly.
>
> 2020-05-18  Mark Eggleston 
>
> gcc/fortran/
>
>     PR fortran/39695
>     * resolve.c (resolve_fl_procedure): Set name depending on
>     whether the result attribute is set.  For PROCEDURE/RESULT
>     conflict use the name in sym->ns->proc_name->name.
>     * symbol.c (gfc_add_type): Add check for function and result
>     attributes use sym->ns->proc_name->name if both are set.
>     Where the symbol cannot have a type use the name in
>     sym->ns->proc_name->name.
>
> 2020-05-18  Mark Eggleston 
>
> gcc/testsuite/
>
>     PR fortran/39695
>     * gfortran.dg/pr39695_1.f90: New test.
>     * gfortran.dg/pr39695_2.f90: New test.
>     * gfortran.dg/pr39695_3.f90: New test.
>     * gfortran.dg/pr39695_4.f90: New test.
>
> Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and gcc-10.
>
> OK to to commit and backport?
>


--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr39695_1.f90
@@ -0,0 +1,8 @@
+! { dg-compile }
+!
etc. etc.

It should read { dg-do compile }

gcc.dg testsuite glitches

[Manfred Schwarb]

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 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/20050121-1.c
index 3fe299a6dc..e7bfdafeb5 100644
--- a/gcc/testsuite/gcc.dg/20050121-1.c
+++ b/gcc/testsuite/gcc.dg/20050121-1.c
@@ -1,6 +1,6 @@
 /* I accidentally broke this while developing a patch for PR 13000,
and didn't notice since the testsuite didn't catch it -- ian  */
-/* { dg-do-compile } */
+/* { dg-do compile } */

 void foo()
 {
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr93382.c b/gcc/testsuite/gcc.dg/analyzer/pr93382.c
index dae32f5a2b..bd11e10611 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr93382.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr93382.c
@@ -14,7 +14,7 @@ ql (void)
   int n1[1];

   fread (n1, sizeof (n1[0]), 1, fp); /* { dg-message "'n1' gets an unchecked value here" } */
-  idx = n1[0]; /* { dg-message "'idx' has an unchecked value here (from 'n1')" */
+  idx = n1[0]; /* { dg-message "'idx' has an unchecked value here (from 'n1')" } */
 }

 int arr[10];
diff --git a/gcc/testsuite/gcc.dg/autopar/pr68460.c b/gcc/testsuite/gcc.dg/autopar/pr68460.c
index 0c00065afb..74f852d68a 100644
--- a/gcc/testsuite/gcc.dg/autopar/pr68460.c
+++ b/gcc/testsuite/gcc.dg/autopar/pr68460.c
@@ -1,4 +1,4 @@
-/* { dg-do "compile" } */
+/* { dg-do compile } */
 /* { dg-options "-O -ftree-parallelize-loops=2 -ftree-vectorize -fno-tree-ch -fno-tree-dominator-opts" } */

 void abort (void);
diff --git a/gcc/testsuite/gcc.dg/c90-fordecl-1.c b/gcc/testsuite/gcc.dg/c90-fordecl-1.c
index 46ba16abbc..6a8e061fb4 100644
--- a/gcc/testsuite/gcc.dg/c90-fordecl-1.c
+++ b/gcc/testsuite/gcc.dg/c90-fordecl-1.c
@@ -9,6 +9,6 @@ foo (void)
   int j = 0;
   for (int i = 1; i <= 10; i++) /* { dg-bogus "warning" "warning in place of error" } */
 /* { dg-error "'for' loop initial declarations are only allowed in C99 or C11 mode" "declaration in for loop" { target *-*-* } .-1 } */
-/* { dg-message "note: use option '-std=c99', '-std=gnu99', '-std=c11' or '-std=gnu11' to compile your code" "note" { target *-*-* } .-2 }} */
+/* { dg-message "note: use option '-std=c99', '-std=gnu99', '-std=c11' or '-std=gnu11' to compile your code" "note" { target *-*-* } .-2 } */
 j += i;
 }
diff --git a/gcc/testsuite/gcc.dg/cpp/trad/funlike-5.c b/gcc/testsuite/gcc.dg/cpp/trad/funlike-5.c
index f60a6ea786..b5481bd3a0 100644
--- a/gcc/testsuite/gcc.dg/cpp/trad/funlike-5.c
+++ b/gcc/testsuite/gcc.dg/cpp/trad/funlike-5.c
@@ -1,7 +1,7 @@
 /* Test function like macro. */
 /* Contributed by Devang Patel  */

-/* {do-do preprocess } */
+/* { dg-do preprocess } */
 /* { dg-options "-traditional-cpp -E -dD" } */
 int __srget (char *);
 #define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c b/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c
index 951380f125..3e27461222 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-dfp.c
@@ -1,6 +1,6 @@
 /* Verify the DWARF encoding of C99 decimal floating point types.  */

-/* { dg-do compile */
+/* { dg-do compile } */
 /* { dg-require-effective-target dfp } */
 /* { dg-options "-O0 -gdwarf -dA" } */
 /* { dg-final { scan-assembler "0x10.*DW_AT_encoding" } } */
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-float.c b/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-float.c
index a028d1484a..f4883842b8 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-float.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-float.c
@@ -1,6 +1,6 @@
 /* Verify the DWARF encoding of C99 floating point types.  */

-/* { dg-do compile */
+/* { dg-do compile } */
 /* { dg-options "-O0 -gdwarf -dA" } */
 /* { dg-final { scan-assembler "0x4.*DW_AT_encoding" } } */
 /* { dg-final { scan-assembler "0x4.*DW_AT_byte_size" } } */
diff --git a/gcc/testsuite/gcc.dg/lto/pr52634_0.c b/gcc/testsuite/gcc.dg/lto/pr52634_0.c
index 5e14ad9a73..7731abf4bc 100644
--- a/gcc/testsuite/gcc.dg/lto/pr52634_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr52634_0.c
@@ -1,7 +1,7 @@
 /* { dg-require-weak "" } */
 /* { dg-require-alias "" } */
 /* { dg-lto-do link } */
-/* { dg-lto-options {{-flto -r -flto-partition=1to1}} */
+/* { dg-lto-options {-flto -r -flto-partition=1to1} } */
 /* { dg-extra-ld-options "-flinker-output=nolto-rel" } */
 extern int cfliteValueCallBacks;
 void baz (int *);
diff --git a/gcc/testsuite/gcc.dg/pr32069.c b/gcc/testsuite/gcc.dg/pr32069.c
index 2ec37c675e..87a3f187e1 100644
--- a/gcc/testsuite/gcc.dg/pr32069.c
+++ 

Re: [patch, libfortran] Adjust block size for libgfortran for unformatted reads

[Manfred Schwarb]

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 on
> some HPC systems. A bigger buffer should eliminate that.  Also,
> People who use unformatted files are likely to write large amounts
> of data, so this seems like a good fit.  Finally, some benchmarking
> showed that 131072 seemed like a good value to use. Thanks to Jerry
> for support.
>
> I didn't change the value for formatted files because, frankly, we are
> using a lot of CPU for converting numbers there, so any gain
> negligible (unless somebody comes up with a benchmark which says
> otherwise).

formatted write: Did you try writing 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 behavior / new feature, I don't think that
> backporting is indicated, but if somebody feels otherwise, please
> speak up.
>
> Regression-tested. OK for trunk?
>
> Regards
>
> Thomas
>
> 2019-07-07  Thomas König  
>
> PR libfortran/91030
> * gfortran.texi (GFORTRAN_BUFFER_SIZE_FORMATTED): Document
> (GFORTRAN_BUFFER_SIZE_FORMATTED): Likewise.
>
> 2019-07-07  Thomas König  
>
> PR libfortran/91030
> * io/unix.c (BUFFER_SIZE): Delete.
> (BUFFER_SIZE_FORMATTED_DEFAULT): New variable.
> (BUFFER_SIZE_UNFORMATTED_DEFAULT): New variable.
> (unix_stream): Add buffer_size.
> (buf_read): Use s->buffer_size instead of BUFFER_SIZE.
> (buf_write): Likewise.
> (buf_init): Add argument unformatted.  Handle block sizes
> for unformatted vs. formatted, using defaults if provided.
> (fd_to_stream): Add argument unformatted in call to buf_init.
> * libgfortran.h (options_t): Add buffer_size_formatted and
> buffer_size_unformatted.
> * runtime/environ.c (variable_table): Add
> GFORTRAN_BUFFER_SIZE_UNFORMATTED and GFORTRAN_BUFFER_SIZE_FORMATTED.
>

Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

[Manfred Schwarb]

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:
>
> % gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90 
> -m32 -O
> % ./a.out
>  FAIL
> Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
> STOP 1
>
> This looks tricky: if I add a line
>
>   print *, x
>
> before
>
>   if (any (abs (x - [1.,20.,3.,40.,5.,60.]) > 1.e-6)) stop 2
>
> the test succeeds!-(
>
> Also you don’t want pr89844 to be solved, don’t you?
>
> TIA
>
> Dominique
>
>
>> Le 11 avr. 2019 à 16:44, Paul Richard Thomas  
>> a écrit :
>>
>> Hi Dominique,
>>
>> Yes indeed - I used int(kind(loc(res))) to achieve the same effect.
>>
>> I am looking for but failing to find a similar problem for PR89846.
>> Tomorrow I turn my attention to an incorrect cast in the compiler.
>>
>> Regards
>>
>> Paul
>
>

Re: testsuite dg-directives glitches

[Manfred Schwarb]

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 GCC-7 branch, there is
./pr68318_1.f90:2:! { dg-options "-O0"

and in the GCC-8 branch I found
./newunit_5.f90.f90:1:! { dg-do run )


Thanks,
Manfred


> TIA
> 
> Dominique
> Index: gcc/testsuite/ChangeLog
> ===
> --- 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.f90
> + * gfortran.dg/dec_structure_14.f90
> + * gfortran.dg/dec_structure_15.f90
> + * gfortran.dg/extends_11.f03
> + * gfortran.dg/pr58968.f
> + * gfortran.dg/pr78259.f90
> + * gfortran.dg/debug/pr35154-stabs.f
> +
>  2019-01-24  Uroš Bizjak  
>  
>   PR target/88998
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90 
> gcc/testsuite/gfortran.dg/array_function_5.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90 2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/array_function_5.f902019-01-25 
> 12:27:40.0 +0100
> @@ -1,4 +1,4 @@
> -! {  dg-do run }
> +! { dg-do run }
>  ! PR41278 internal compiler error related to matmul and transpose
>  ! Test case prepared by Jerry DeLisle  
>  ! Original test case by Chris 
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90 
> gcc/testsuite/gfortran.dg/class_66.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90 2017-12-07 
> 12:49:38.0 +0100
> +++ gcc/testsuite/gfortran.dg/class_66.f902019-01-25 12:28:06.0 
> +0100
> @@ -1,4 +1,4 @@
> -! { dg- do run }
> +! { dg-do run }
>  !
>  ! Test the fix for PR78641 in which an ICE occured on assignment
>  ! of a class array constructor to a derived type array.
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90 
> gcc/testsuite/gfortran.dg/dec_structure_12.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90 2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_12.f902019-01-25 
> 12:28:58.0 +0100
> @@ -1,4 +1,4 @@
> -! { dg-do "compile" }
> +! { dg-do compile }
>  ! { dg-options "-fdec-structure" }
>  !
>  ! Test a regression where multiple anonymous structures failed to
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90 
> gcc/testsuite/gfortran.dg/dec_structure_14.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90 2017-04-21 
> 16:03:32.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_14.f902019-01-25 
> 12:29:10.0 +0100
> @@ -1,4 +1,4 @@
> -  ! { dg-do "compile" }
> +  ! { dg-do compile }
>! { dg-options "-fdec-structure" }
>!
>! Test that structures inside a common block do not require the
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90 
> gcc/testsuite/gfortran.dg/dec_structure_15.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90 2017-04-21 
> 16:03:29.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_15.f902019-01-25 
> 12:29:23.0 +0100
> @@ -1,4 +1,4 @@
> -! { dg-do "compile" }
> +! { dg-do compile }
>  ! { dg-options "" }
>  !
>  ! PR fortran/77584
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03 
> gcc/testsuite/gfortran.dg/extends_11.f03
> --- ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03   2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/extends_11.f03  2019-01-25 12:29:59.0 
> +0100
> @@ -37,4 +37,4 @@
>recruit%service%education%person%ss = 9
>  end
>  
> -! { dg-final { scan-tree-dump-times " 
> +recruit\\.service\\.education\\.person\\.ss =" 8 "original"} }
> +! { dg-final { scan-tree-dump-times " 
> +recruit\\.service\\.education\\.person\\.ss =" 8 "original" } }
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f 
> gcc/testsuite/gfortran.dg/pr58968.f
> --- ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/pr58968.f   2019-01-25 12:30:29.0 
> +0100
> @@ -1,5 +1,5 @@
>  C PR rtl-optimization/58968.f
> -C { dg-do compile { target powerpc*-*-*} }
> +C { dg-do compile { target powerpc*-*-* }

Re: testsuite dg-directives glitches

[Manfred Schwarb]

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 reports numerous false positives.
>> As one can expect, also gcc.dg would appreciate some love…
> 
> I had a quick look at the script and noticed that the paths are hard-coded.
> Assuming the script is going to contrib/, would it be possible to replace 
> them with
> relative ones? Some comments to explain how to use it would also be nice.
> 
> Note that I have no idea if this script requires a copyright assignment.
> 

I do not have an assignment, and frankly, I do not intend to get one.
But I could donate this code to someone, if this helps.
My expectation was that one has to edit the script anyway to adapt it to
different test-suites or to fiddle with filtering. I guess this script is
very far from perfect.

>>
>> While cleaning up the script, I found some refinements, and another
>> 7 glitches, see attachment.
>>
>> could you take care of these as well?
> 
> Done at r268148 after removing a missed double spaces in 
> gfortran.dg/spread_simplify_1.f90 
> and renaming  gfortran.dg.orig/newunit_5.f90.f90 to 
> gfortran.dg.orig/newunit_5.f90.
> 

I guess "dg-do  run" was on purpose, this is an ugly hack to execute the test 
only once
and not iterate over the full set of options. This is often done on 
heavy-weight tests
to save execution time.

> Thanks,
> 
> Dominique
> 
>>
>> 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.
>>>
>>> Dominique
>>>
>>>
>>
>> 
> 
> 

Re: testsuite dg-directives glitches

[Manfred Schwarb]

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 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.
> 
> Dominique
> 
> 



testsuite-test.sh
Description: application/shellscript
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/array_function_5.f90 gcc/gcc/testsuite/gfortran.dg/array_function_5.f90
--- gcc/gcc/testsuite/gfortran.dg.orig/array_function_5.f90	2018-02-18 01:31:19.141695840 +0100
+++ gcc/gcc/testsuite/gfortran.dg/array_function_5.f90	2019-01-22 09:28:17.522611302 +0100
@@ -1,4 +1,4 @@
-! {  dg-do run }
+! { dg-do run }
 ! PR41278 internal compiler error related to matmul and transpose
 ! Test case prepared by Jerry DeLisle  
 ! Original test case by Chris 
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/block_16.f08 gcc/gcc/testsuite/gfortran.dg/block_16.f08
--- gcc/gcc/testsuite/gfortran.dg.orig/block_16.f08	2018-07-05 03:11:55.672355270 +0200
+++ gcc/gcc/testsuite/gfortran.dg/block_16.f08	2019-01-22 09:29:52.680915714 +0100
@@ -1,4 +1,4 @@
-! { dg-do compile )
+! { dg-do compile }
 ! PR82009  [F08] ICE with block construct
 MODULE sparse_matrix_csx_benchmark_utils
   IMPLICIT NONE
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/dec_structure_14.f90 gcc/gcc/testsuite/gfortran.dg/dec_structure_14.f90
--- gcc/gcc/testsuite/gfortran.dg.orig/dec_structure_14.f90	2016-09-15 02:30:28.726544585 +0200
+++ gcc/gcc/testsuite/gfortran.dg/dec_structure_14.f90	2019-01-22 09:27:26.013363823 +0100
@@ -1,4 +1,4 @@
-  ! { dg-do "compile" }
+  ! { dg-do compile }
   ! { dg-options "-fdec-structure" }
   !
   ! Test that structures inside a common block do not require the
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/namelist_96.f90 gcc/gcc/testsuite/gfortran.dg/namelist_96.f90
--- gcc/gcc/testsuite/gfortran.dg.orig/namelist_96.f90	2019-01-14 02:24:20.416290721 +0100
+++ gcc/gcc/testsuite/gfortran.dg/namelist_96.f90	2019-01-22 09:28:49.147377175 +0100
@@ -1,4 +1,4 @@
-! ( dg-do run }
+! { dg-do run }
 program pr88776
   implicit none
   character(*), parameter :: file = "pr88776.dat"
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/newunit_5.f90.f90 gcc/gcc/testsuite/gfortran.dg/newunit_5.f90.f90
--- gcc/gcc/testsuite/gfortran.dg.orig/newunit_5.f90.f90	2018-02-18 01:31:19.177696525 +0100
+++ gcc/gcc/testsuite/gfortran.dg/newunit_5.f90.f90	2019-01-22 09:29:24.252227293 +0100
@@ -1,4 +1,4 @@
-! { dg-do run )
+! { dg-do run }
 ! PR83525 Combination of newunit and internal unit was failing.
 program main
   integer :: funit
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/pdt_28.f03 gcc/gcc/testsuite/gfortran.dg/pdt_28.f03
--- gcc/gcc/testsuite/gfortran.dg.orig/pdt_28.f03	2018-02-18 01:30:44.149030094 +0100
+++ gcc/gcc/testsuite/gfortran.dg/pdt_28.f03	2019-01-22 09:29:07.251815605 +0100
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! ( dg-options "-fbounds-check" }
+! { dg-options "-fbounds-check" }
 !
 ! Test the fix for PR83731, where the following failed on the check for the
 ! value of the parameter 'k'.
diff -Nupr gcc/gcc/testsuite/gfortran.dg.orig/spread_simplify_1.f90 gcc/gcc/testsuite/gfortran.dg/spread_simplify_1.f90
--- gcc/gcc/testsuite/gfortran.dg.orig/spread_simplify_1.f90	2019-01-10 01:31:01.867896509 +0100
+++ gcc/gcc/testsuite/gfortran.dg/spread_simplify_1.f90	2019-01-22 09:27:58.450149402 +0100
@@ -1,4 +1,4 @@
-! { dg-do  run  }
+! { dg-do  run }
 ! PR 68426 - simplification used to fail.
   module m
 implicit none

Re: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop)

[Manfred Schwarb]

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 
> code. Consequently in the big loop over the array where we call 
> list_formatted_read_scalar, we never returned an error code so we never 
> exited the loop early.
> 
> The patch tests for the EOF first locally as before, but then returns the 
> error flags set in dtp->common.flags which are set globally in the individual 
> read procedures whene hit_eof is called.
> 
> Regression tested on x86_64. I have added a test case which will check the 
> execution time of the loop. The previous results of the REAd were correct, 
> just took a long time on large arrays.
> 

Seems to work as advertised.
With this small patch, I see a tremendous speedup for array reads.

The implied-do variant gets slightly slower (~10%), but the
array variant now takes 0.002s independent of the size of "m",
compared to some dozens of seconds without this patch!

Concerning your test case:
Your timeout of 2s is dangerously close to the timings of really fast
boxes without this patch, so I would lower this value.
I guess even on really slow ARM boxes or some-such this test case finishes
in some few tenth of seconds, at worst.

Or, as the 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 DeLisle  
> 
> PR libgfortran/35339
> * list_read.c.c (list_formatted_read_scala): Set the err return
> value to the common.flags error values.

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Manfred Schwarb]

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 not able to trigger this warning and
found no occurrence of it in the testsuite. Could someone check if the
flag that I'm using there is correct, please?

As a small extra the patch also mentions the -Wpedantic flag in the
gfortran documentation.

It regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus



   if (source_size < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: "
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (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

Re: [Patch, Fortran] PR 69495: unused-label warning does not tell which flag triggered it

[Manfred Schwarb]

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 < result_size)
-gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result:
"
-"source size %ld < result size %ld", >where,
-(long) source_size, (long) result_size);
+gfc_warning (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.


thanks for the comment, I was not aware that this is a problem (in
fact I'm rather ignorant of the translation process as a whole). I was
just trying to comply with the GNU coding standards by avoiding
overlong lines.

So, I assume the problem is that the strings are being broken
*differently* than before, right? (Obviously the were broken already
...) I guess I will just move the start of the warning message to a
new line in order to avoid this.



There are 2 things with translation, and there is a third issue:
- As you noticed, breaking things differently means translation has to be
  done again.
- Normally, each string is translated independently, and depending on the
  language there may be lack of context (e.g. adjectives get different suffixes
  depending on the noun).
- grep'ability: you got such an error message, then you want to look for the
  corresponding code and do a grep for e.g. "partly undefined result".
  GOTCHA!

So IMHO strings should be left intact, irrespective of some arbitrary 80 char 
limits.
Other projects, e.g. the linux kernel, do deliberately violate the 80 char limit
if it is needed, and do not always break strings. I do not know how it is 
handled
in the GCC project, but I guess common sense is always a good recipe.

Of course it is no problem to split at natural boundaries, e.g. at ":", ";" or 
"."
characters.

Cheers,
Manfred



Btw, if anyone notices any further cases where the flag is missing in
the warning message, please let me know. (I haven't searched through
the whole gfortran code for more such cases and I'm not planning on
doing so, but I'll be happy to include further cases in the patch if
pointed out to me ...)

Also I guess I should mention Manuel and Dominique in the Changelog
(for their supportive comments in the PR).

Cheers,
Janus

Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance

[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 string is reached.  In the
case sited which is very contrived, this amounts to about 10 calls to 
next_char.

For clarity, this test case:

   character buffer(1)*10
   integer i,j

   j = 1234
   write(buffer(1),'(i4)') j

   DO j=1,
!write(*,*) buffer(1)(1:4)
 read(buffer,*) i
!write(*,*) i
   ENDDO
   end

Without the patch takes about 25 seconds to run.

With the patch this takes about 2.8 seconds.


This is great.

However, this is still 10 times slower than the LEN_TRIM variant:
character buffer(1)*10
integer i,j
 
j = 1234

write(buffer(1),'(i4)') j
 
DO j=1,

 !write(*,*) buffer(1)(1:4)
  read(buffer(1)(1:LEN_TRIM(buffer(1))),*) i
 !write(*,*) i
ENDDO
end

which takes 0.23s on my box. So on the on hand the improvement is great,
on the other hand it is really sad, because 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 all the end of record code needed in next_char.

I also remove some unneeded error checks.

Regression tested on X86_64 gnu.  No need for a new test case since no new
functionality is added.

OK for trunk? The PR is marked as a regression, so I think this could be the
last piece and call it done.

Regards,

Jerry

2014-03-08  Jerry DeLisle  jvdeli...@gcc.gnu

PR libfortran/38199
* io/list_read.c (next_char): Delete unuseful error checks.
(eat_spaces): For character array reading, skip ahead over
spaces rather than call next_char multiple times.

Re: [patch, libfortran] [4.7/4.8/4.9 Regression] PR38199 missed optimization: I/O performance

[Manfred Schwarb]

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 string is reached.  In the
case sited which is very contrived, this amounts to about 10 calls to 
next_char.

For clarity, this test case:

   character buffer(1)*10
   integer i,j

   j = 1234
   write(buffer(1),'(i4)') j

   DO j=1,
!write(*,*) buffer(1)(1:4)
 read(buffer,*) i
!write(*,*) i
   ENDDO
   end

Without the patch takes about 25 seconds to run.

With the patch this takes about 2.8 seconds.


This is great.

However, this is still 10 times slower than the LEN_TRIM variant:
 character buffer(1)*10
 integer i,j

 j = 1234
 write(buffer(1),'(i4)') j

 DO j=1,
  !write(*,*) buffer(1)(1:4)
   read(buffer(1)(1:LEN_TRIM(buffer(1))),*) i
  !write(*,*) i
 ENDDO
 end



and also 10 times slower than the scalar variant (which was fixed by Thomas):
  character buffer*10
  integer i,j

  j = 1234
  write(buffer,'(i4)') j

  DO j=1,
!write(*,*) buffer(1:4)
read(buffer,*) i
!write(*,*) i
  ENDDO
  end




which takes 0.23s on my box. So on the on hand the improvement is great,
on the other hand it is really sad, because 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 all the end of record code needed in next_char.

I also remove some unneeded error checks.

Regression tested on X86_64 gnu.  No need for a new test case since no new
functionality is added.

OK for trunk? The PR is marked as a regression, so I think this could be the
last piece and call it done.

Regards,

Jerry

2014-03-08  Jerry DeLisle  jvdeli...@gcc.gnu

PR libfortran/38199
* io/list_read.c (next_char): Delete unuseful error checks.
(eat_spaces): For character array reading, skip ahead over
spaces rather than call next_char multiple times.

Re: [Patch, Fortran] Better error messages for type/rank checks

[Manfred Schwarb]

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 EOF
#include sys/ioctl.h
#include stdio.h

int main (void)
{
struct winsize w;
ioctl(0, TIOCGWINSZ, w);

printf (lines %d\n, w.ws_row);
printf (columns %d\n, w.ws_col);
return 0;
}
EOF

# gcc term.c -o term

# at now EOF
term  term1.txt
EOF
# cat term1.txt
lines 63152
columns 55767

# at now EOF
term  term2.txt
EOF
# cat term2.txt
lines 24448
columns 22759


So this gives meaningless, varying numbers for me when
executing in non-interactive environment.

Perhaps cutting to some sane numbers is needed?

Or, simply leave the line wrapping to the terminal and
remove all this trimming code?

cheers,
Manfred

Re: [Patch, Fortran] Better error messages for type/rank checks

[Manfred Schwarb]

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 term.c EOF
#include sys/ioctl.h
#include stdio.h

int main (void)
{
 struct winsize w;
 ioctl(0, TIOCGWINSZ, w);

 printf (lines %d\n, w.ws_row);
 printf (columns %d\n, w.ws_col);
 return 0;
}
EOF

# gcc term.c -o term

# at now EOF
term  term1.txt
EOF
# cat term1.txt
lines 63152
columns 55767

# at now EOF
term  term2.txt
EOF
# cat term2.txt
lines 24448
columns 22759


So this gives meaningless, varying numbers for me when
executing in non-interactive environment.


Huh, funny. For me it works nicely. Does this also happen if you if
gate your code by

#ifdef TIOCGWINSZ

as done in my patch?


Yes.
As stated, this happens only in non-interactive environment,
executing it in a terminal produces something sane:
# term
lines 60
columns 151


What operating system are you on?



x86_64 OpenSuse 12.1




Perhaps cutting to some sane numbers is needed?


Possibly.



Or, simply leave the line wrapping to the terminal and
remove all this trimming code?


This is what we do with the actual error messages. I think the reason
why the trimming is done for the source lines is that it is harder to
follow the locus markers (i.e. ... error at (1) ...) if the source
line is wrapped.

Cheers,
Janus

Re: [Patch, Fortran] Better error messages for type/rank checks

[Manfred Schwarb]

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 missing anything else? (Testing welcome ...)



needs #include unistd.h for isatty(), perhaps.
Otherwise looks sane at first glance.

Cheers,
Manfred


Cheers,
Janus

Re: testsuite: missing or wrong dg-* directives?

[Manfred Schwarb]

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 dg-options -fbounds-check.
 * gfortran.dg/bounds_check_5.f90: Likewise.
 * gfortran.dg/class_array_10.f03: Fix syntax of dg-directive.
 * gfortran.dg/continuation_9.f90: Likewise.
 * gfortran.dg/move_alloc_13.f90: Likewise.
 * gfortran.dg/structure_constructor_11.f90: Likewise.
 * gfortran.dg/tab_continuation.f: Likewise.
 * gfortran.dg/warning-directive-2.F90: Likewise.
 * gfortran.dg/coarray_lib_token_4.f90: Remove misspelled directive.



Harald,
thanks for doing this. I'm not able to sign the famous paperwork,
so submitting patches myself is not really productive.

Manfred



Harald

Re: testsuite: missing or wrong dg-* directives?

[Manfred Schwarb]

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.


Want to send a patch?


Not sure about the double braces in lto, I guess they act simply as
single braces.


I don't know, you may ask a testsuite maintainer, or the author.  It is 
unlikely though that the author made a typo at the opening brace _and_ at the 
closing one.


Yeah…  A quick check of the _documentation_ (a terrible thing to waste):

http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gccint/LTO-Testing.html


Sorry, I just realized that my sentence was not really clear. I was not talking
about removing superfluous braces, but about adding spaces between these double 
braces.

dejagnu seems to be very sensitive concerning missing spaces, e.g.
{ dg-do run} does silently nothing, it only works if you write it as
{ dg-do run }.


Manfred



{ dg-lto-options { { options } [{ options }] } [{ target selector }]}
This directive provides a list of one or more sets of compiler options to 
override LTO_OPTIONS. Each test will be compiled and run with each of these 
sets of options.

Re: testsuite: missing or wrong dg-* directives?

[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 run?

Running an fgrep -L on the fortran testsuite, I found several files
that are missing either dg-do compile or run.

I also found a funny typo in gomp/appendix-a/a.11.2.f90
! { do-do compile }




There are several other oddities: d_g-final, braces have to be separated by 
spaces.
Not sure about the double braces in lto, I guess they act simply as single 
braces.

class_array_10.f03:! { dg-do compile}
coarray_lib_token_4.f90:! { d_g-final { scan-tree-dump-times bar \\(parm.\[0-9\]+, 
caf_token.\[0-9\]+, \\(\\(integer\\(kind=.\\) parm.\[0-9\]+.data - \\(integer\\(kind=.\\)\\) 
x.\[0-9\]+\\) \\+ caf_offset.\[0-9\]+\\); 1 original } }
continuation_9.f90:! { dg-warning not allowed by itself in line 3  {target 
*-*-*} 0 }
continuation_9.f90:! { dg-warning not allowed by itself in line 4  {target 
*-*-*} 0 }
continuation_9.f90:! { dg-warning not allowed by itself in line 5  {target 
*-*-*} 0 }
extends_11.f03:! { dg-final { scan-tree-dump-times  
+recruit\\.service\\.education\\.person\\.ss = 8 original} }
lto/20091016-1_0.f90:! { dg-lto-options {{-flto -g -fPIC -r -nostdlib} {-O 
-flto -g -fPIC -r -nostdlib}} }
lto/20100110-1_0.f90:! { dg-lto-options {{ -O1 -flto }} }
lto/pr41521_0.f90:! { dg-lto-options {{-g -flto} {-g -O -flto}} }
lto/pr46036_0.f90:! { dg-lto-options {{ -O -flto -ftree-vectorize }} }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize 
-march=x86-64 }} { target i?86-*-* x86_64-*-* } }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize }} }
lto/pr46911_0.f:! { dg-lto-options {{ -O2 -flto -g }} }
lto/pr47839_0.f90:! { dg-lto-options {{ -g -flto }} }
move_alloc_13.f90:! { dg-do run}
structure_constructor_11.f90:! { dg-do run}
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 10 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 11 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 8 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 9 
Nonconforming tab {target *-*-*} 0 }
vect/vect-2.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
versioning. 3 vect {target { vect_no_align || { { ! vector_alignment_reachable  } 
 { ! vect_hw_misalign } } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { vect_no_align || {! vector_alignment_reachable}} } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using versioning 1 
vect { target { {! vect_no_align}  { {! vector_alignment_reachable}  {! 
vect_hw_misalign} } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 
vect { xfail { { vect_no_align } || { ! vector_alignment_reachable} } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 2 vect 
{ target { {! vect_no_align}  { {! vector_alignment_reachable}  {! vect_hw_misalign} } } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { { vect_no_align } || {! vector_alignment_reachable} } } 
} }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 
vect { xfail { { vect_no_align } || {! vector_alignment_reachable} } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 2 
vect { target { {! vector_alignment_reachable}  {! vect_hw_misalign} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { vect_no_align || {! vector_alignment_reachable} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
versioning. 1 vect { target { {! vector_alignment_reachable}  {! 
vect_hw_misalign} } } } }
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


[...]


- Possibly missing { dg-do run }


[...]

Mind sending patch and changelog to @gcc-patches ?



Here we go.  No failures, but additional passes because of the dg-do run's.  
Somebody please take care of it?

Harald


2013-01-13  Harald Anlauf anl...@gmx.de

 * gfortran.dg/aint_anint_1.f90: Add dg-do run.
 * gfortran.dg/bounds_check_4.f90: Likewise.
 * gfortran.dg/inquire_10.f90: Likewise.
 * gfortran.dg/minloc_3.f90: Likewise.
 * gfortran.dg/minlocval_3.f90: Likewise.
 

Re: testsuite: missing or wrong dg-* directives?

[Manfred Schwarb]

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 run?

Running an fgrep -L on the fortran testsuite, I found several files
that are missing either dg-do compile or run.

I also found a funny typo in gomp/appendix-a/a.11.2.f90
! { do-do compile }




There are several other oddities: d_g-final, braces have to be separated by 
spaces.
Not sure about the double braces in lto, I guess they act simply as single 
braces.




Oh, and then there is the dg-do  run hack (two spaces, see 
cray_pointers_2.f90).
I guess the other occurrences are not intended:

default_initialization_5.f90:! { dg-do  run }
io_real_boz_3.f90:! { dg-do  run }
io_real_boz_4.f90:! { dg-do  run }
io_real_boz_5.f90:! { dg-do  run }



class_array_10.f03:! { dg-do compile}
coarray_lib_token_4.f90:! { d_g-final { scan-tree-dump-times bar \\(parm.\[0-9\]+, 
caf_token.\[0-9\]+, \\(\\(integer\\(kind=.\\) parm.\[0-9\]+.data - \\(integer\\(kind=.\\)\\) 
x.\[0-9\]+\\) \\+ caf_offset.\[0-9\]+\\); 1 original } }
continuation_9.f90:! { dg-warning not allowed by itself in line 3  {target 
*-*-*} 0 }
continuation_9.f90:! { dg-warning not allowed by itself in line 4  {target 
*-*-*} 0 }
continuation_9.f90:! { dg-warning not allowed by itself in line 5  {target 
*-*-*} 0 }
extends_11.f03:! { dg-final { scan-tree-dump-times  
+recruit\\.service\\.education\\.person\\.ss = 8 original} }
lto/20091016-1_0.f90:! { dg-lto-options {{-flto -g -fPIC -r -nostdlib} {-O 
-flto -g -fPIC -r -nostdlib}} }
lto/20100110-1_0.f90:! { dg-lto-options {{ -O1 -flto }} }
lto/pr41521_0.f90:! { dg-lto-options {{-g -flto} {-g -O -flto}} }
lto/pr46036_0.f90:! { dg-lto-options {{ -O -flto -ftree-vectorize }} }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize 
-march=x86-64 }} { target i?86-*-* x86_64-*-* } }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize }} }
lto/pr46911_0.f:! { dg-lto-options {{ -O2 -flto -g }} }
lto/pr47839_0.f90:! { dg-lto-options {{ -g -flto }} }
move_alloc_13.f90:! { dg-do run}
structure_constructor_11.f90:! { dg-do run}
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 10 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 11 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 8 
Nonconforming tab {target *-*-*} 0 }
tab_continuation.f:! { dg-warning Nonconforming tab character in column 1 of line 9 
Nonconforming tab {target *-*-*} 0 }
vect/vect-2.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
versioning. 3 vect {target { vect_no_align || { { ! vector_alignment_reachable  } 
 { ! vect_hw_misalign } } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { vect_no_align || {! vector_alignment_reachable}} } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using versioning 1 
vect { target { {! vect_no_align}  { {! vector_alignment_reachable}  {! 
vect_hw_misalign} } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 
vect { xfail { { vect_no_align } || { ! vector_alignment_reachable} } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 2 vect 
{ target { {! vect_no_align}  { {! vector_alignment_reachable}  {! vect_hw_misalign} } } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { { vect_no_align } || {! vector_alignment_reachable} } } 
} }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 
vect { xfail { { vect_no_align } || {! vector_alignment_reachable} } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 2 
vect { target { {! vector_alignment_reachable}  {! vect_hw_misalign} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
peeling 1 vect { xfail { vect_no_align || {! vector_alignment_reachable} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times Alignment of access forced using 
versioning. 1 vect { target { {! vector_alignment_reachable}  {! 
vect_hw_misalign} } } } }
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


[...]


- Possibly missing { dg-do run }


[...]

Mind sending patch and changelog to @gcc-patches ?



Here we go.  No failures, but additional passes because of the dg

Re: [fortran, patch] Allow displaying backtraces from user code

[Manfred Schwarb]

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 to 
offer this feature in some why and as the PR but also a question on #gfortran 
shows, there is a need to do so.



It is definitely needed, IMHO.
In a modular program the calling path is often needed to interpret
some hiccups, and a debugger is not always suited.
Program runs are not always reproducible, and with this you can
add debugging statements into operational code.
I ended up writing a wrapper around the c-functions backtrace() and 
backtrace_symbols_fd(),
but then you have to interpret it externally with addr2line.



There are two possibilities:
a) Making _gfortran_show_backtrace accessible from the outside (via manual C 
binding from Fortran)
b) Adding a new intrinsic



I would vote for b), as it gets documented then.
It is enough useful for a wide range of programmers to deserve
an intrinsic of its own, IMHO.
And always directly available, no need of module convolutions.

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

Re: [Patch, libfortran] Fix handling of temporary files

[Manfred Schwarb]

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 addr2line is.




I did not test it, but if I remember right, the use of geteuid() and friends
does prevent static compilation, resp. static compilation does seem
to work, but it needs a matched dynamic library nonetheless,
which means if you relocate your statically linked program to another
box with differing glibc, you get runtime errors?

Or is the use of static programs already broken so it does not matter?
If this security feature would prevent use of static programs, it would
not be worth it, I think.


getuid and friends are already used in other parts of the runtime
library, so if static linking to glibc is broken it was broken before
as well.

The Glibc FAQ says:

2.22.   Even statically linked programs need some shared libraries
which is not acceptable for me.  What can I do?

{AJ} NSS (for details just type `info libc Name Service Switch') won't
work properly without shared libraries.  NSS allows using different services
(e.g. NIS, files, db, hesiod) by just changing one configuration file
(/etc/nsswitch.conf) without relinking any programs.  The only disadvantage
is that now static libraries need to access shared libraries.  This is
handled transparently by the GNU C library.


I'm not sure of the details of what happens, or under which exact
circumstances it works or not, when one runs a statically linked
program on another machine with a different glibc version.



The nasty thing is, the runtime error does not happen at program start, but
at the point of actual invocation of the *uid call. So this may come as
a real surprise for the user if such functions are seldom called in the
binary, e.g. in some error path.

And the really ugly thing is, there seems to be an incompatible break between
glibc 2.11 and 2.12 in this very NSS stuff.
I recently stumbled over https://bugs.gentoo.org/show_bug.cgi?id=332927, when
the provider decided to upgrade glibc on the server (sic!).
[ And, it was a c-program that was crashing, my static fortran programs were
still running fine ]

As traditionally a lot of fortran code is statically compiled, I just wanted
to make aware that the more of such calls are added, the more likely users will
get surprises.
I guess relocation of binaries to other boxes is not uncommon in the HPC sector,
and having a crash after some weeks of runtime due to this is not really 
funny...

Manfred

Re: [Patch, libfortran] Fix handling of temporary files

[Manfred Schwarb]

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, resp. static compilation does seem
to work, but it needs a matched dynamic library nonetheless,
which means if you relocate your statically linked program to another
box with differing glibc, you get runtime errors?

Or is the use of static programs already broken so it does not matter?
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
algorithm for choosing temp directory.


libgfortran ChangeLog:

2012-04-19  Janne Blomqvistj...@gcc.gnu.org

* config.h.in: Regenerated.
* configure: Regenerated.
* configure.ac: Add checks for getegid and __secure_getenv.
* io/unix.c (P_tmpdir): Fallback definition for macro.
(tempfile_open): New function.
(tempfile): Use secure_getenv, call tempfile_open to try each
directory in turn.
* libgfortran.h (DEFAULT_TMPDIR): Remove macro.
(secure_getenv): New macro/prototype.
* runtime/environ.c (secure_getenv): New function.
(variable_table): Rename GFORTRAN_TMPDIR to TMPDIR.
* runtime/main.c (find_addr2line): Use secure_getenv.