Re: [PATCH,fortran] Handle BOZ in accordance to Fortran 2018 standard (1st batch)
(A) I see the following failures FAIL: libgomp.fortran/reduction4.f90 -O0 (test for excess errors) … FAIL: libgomp.fortran/reduction4.f90 -Os (test for excess errors) FAIL: libgomp.fortran/reduction5.f90 -O0 (test for excess errors) … FAIL: libgomp.fortran/reduction5.f90 -Os (test for excess errors) I have silenced the failures with following patch: --- ../_clean/libgomp/testsuite/libgomp.fortran/reduction4.f90 2018-03-25 18:07:25.0 +0200 +++ libgomp/testsuite/libgomp.fortran/reduction4.f902019-07-19 00:04:29.0 +0200 @@ -4,12 +4,12 @@ integer (kind = 4) :: i, ia (6), j, ja (6), k, ka (6), ta (6), n, cnt, x logical :: v - i = Z'0f' - ia = Z'f0ff0f' - j = Z'0f' - ja = Z'0f5a00' - k = Z'055aa0' - ka = Z'05a5a5' + i = int(Z'0f') + ia = int(Z'f0ff0f') + j = int(Z'0f') + ja = int(Z'0f5a00') + k = int(Z'055aa0') + ka = int(Z'05a5a5') v = .false. cnt = -1 x = not(0) @@ -22,35 +22,35 @@ n = omp_get_thread_num () if (n .eq. 0) then cnt = omp_get_num_threads () -i = Z'ff7fff' -ia(3:5) = Z'f1' -j = Z'078000' +i = int(Z'ff7fff') +ia(3:5) = int(Z'f1') +j = int(Z'078000') ja(1:3) = 1 -k = Z'78' -ka(3:6) = Z'f0f' +k = int(Z'78') +ka(3:6) = int(Z'f0f') else if (n .eq. 1) then -i = Z'77' -ia(2:5) = Z'ffafff' -j = Z'007800' +i = int(Z'77') +ia(2:5) = int(Z'ffafff') +j = int(Z'007800') ja(2:5) = 8 -k = Z'57' -ka(3:4) = Z'f0108' +k = int(Z'57') +ka(3:4) = int(Z'f0108') else -i = Z'777fff' -ia(1:2) = Z'f3' -j = Z'000780' -ja(5:6) = Z'f00' -k = Z'1000' -ka(6:6) = Z'777' +i = int(Z'777fff') +ia(1:2) = int(Z'f3') +j = int(Z'000780') +ja(5:6) = int(Z'f00') +k = int(Z'1000') +ka(6:6) = int(Z'777') end if !$omp end parallel if (v) STOP 1 if (cnt .eq. 3) then -ta = (/Z'f0ff03', Z'f0af03', Z'f0af01', Z'f0af01', Z'f0af01', Z'f0ff0f'/) -if (i .ne. Z'777f07' .or. any (ia .ne. ta)) STOP 2 -ta = (/Z'f5a01', Z'f5a09', Z'f5a09', Z'f5a08', Z'f5f08', Z'f5f00'/) -if (j .ne. Z'fff80' .or. any (ja .ne. ta)) STOP 3 -ta = (/Z'5a5a5', Z'5a5a5', Z'aaba2', Z'aaba2', Z'5', Z'5addd'/) -if (k .ne. Z'54a8f' .or. any (ka .ne. ta)) STOP 4 +ta = (/int(Z'f0ff03'), int(Z'f0af03'), int(Z'f0af01'), int(Z'f0af01'), int(Z'f0af01'), int(Z'f0ff0f')/) +if (i .ne. int(Z'777f07') .or. any (ia .ne. ta)) STOP 2 +ta = (/int(Z'f5a01'), int(Z'f5a09'), int(Z'f5a09'), int(Z'f5a08'), int(Z'f5f08'), int(Z'f5f00')/) +if (j .ne. int(Z'fff80') .or. any (ja .ne. ta)) STOP 3 +ta = (/int(Z'5a5a5'), int(Z'5a5a5'), int(Z'aaba2'), int(Z'aaba2'), int(Z'5'), int(Z'5addd')/) +if (k .ne. int(Z'54a8f') .or. any (ka .ne. ta)) STOP 4 end if end --- ../_clean/libgomp/testsuite/libgomp.fortran/reduction5.f90 2018-03-25 18:07:24.0 +0200 +++ libgomp/testsuite/libgomp.fortran/reduction5.f902019-07-18 23:56:59.0 +0200 @@ -10,7 +10,7 @@ contains subroutine test1 use reduction5, bitwise_or => ior integer :: n -n = Z'f' +n = int(Z'f') !$omp parallel sections num_threads (3) reduction (bitwise_or: n) n = ior (n, Z'20') !$omp section @@ -18,7 +18,7 @@ contains !$omp section n = bitwise_or (n, Z'2000') !$omp end parallel sections -if (n .ne. Z'243f') STOP 1 +if (n .ne. int(Z'243f')) STOP 1 end subroutine subroutine test2 use reduction5, min => max, max => min (B) The points mentioned in https://gcc.gnu.org/ml/fortran/2017-10/msg00037.html have been fixed, except the points (3) and (6) which still give an ICE. I understand that the coddles are invalid, but IMO they should give an error along the line "BOZ literal at %L outside a DATA statement and outside INT/REAL/DBLE/CMPLX » I have more comments for a second batch Dominique
Re: C++ PATCH for c++/83820 - excessive attribute arguments not detected
On darwin* I see
FAIL: g++.dg/cpp0x/gen-attrs-67.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-67.C -std=c++17 (test for excess errors)
This is caused by the additional error
/opt/gcc/_clean/gcc/testsuite/g++.dg/cpp0x/gen-attrs-67.C:11:34: error:
constructor priorities are not supported
11 | [[gnu::constructor(101)]] int f7();
and it is fixed by the following patch
--- ../_clean/gcc/testsuite/g++.dg/cpp0x/gen-attrs-67.C 2019-06-17
20:33:15.0 +0200
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-67.C 2019-06-20 18:13:13.0
+0200
@@ -8,4 +8,4 @@
[[nodiscard()]] int f4(); // { dg-error ".nodiscard. attribute does not take
any arguments" }
[[gnu::noinline()]] int f5(); // { dg-error ".noinline. attribute does not
take any arguments" }
[[gnu::constructor]] int f6();
-[[gnu::constructor(101)]] int f7();
+[[gnu::constructor(101)]] int f7(); // { dg-error "constructor priorities are
not supported" { target *-*-darwin* } }
Is it OK to commit it to trunk?
TIA
Dominique
Re: [PATCH] PR fortran/69398 -- Duplicate dimensions and CLASS
Hi Steve, Patch missing? TIA Dominique
Re: [PATCH] Strip target_clones in copy attribute (PR lto/90500).
> Le 21 mai 2019 à 11:48, Martin Liška a écrit :
>
> On 5/21/19 11:41 AM, Dominique d'Humières wrote:
>> Hi Martin,
>>
>> /* { dg-require-ifunc } */
>>
>> should be
>>
>> /* { dg-require-ifunc ""} */
>>
>> and the same for pr90500-2.c (see
>> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01152.html)
>>
>> TIA
>>
>> Dominique
>>
>
> Hi.
>
> Thanks, should I fix it for all:
>
> gcc/testsuite/gcc.target/i386/pr84723-1.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr84723-2.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr84723-3.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr84723-4.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr84723-5.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr90500-1.c:/* { dg-require-ifunc } */
> gcc/testsuite/gcc.target/i386/pr90500-2.c:/* { dg-require-ifunc } */
IMO Jakub’s advice is needed for the gcc/testsuite/gcc.target/i386/pr84723-*
tests: they pass on darwin.
>
> ?
Re: [PATCH] Strip target_clones in copy attribute (PR lto/90500).
Hi Martin,
/* { dg-require-ifunc } */
should be
/* { dg-require-ifunc ""} */
and the same for pr90500-2.c (see
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01152.html)
TIA
Dominique
dg-require-ifunc syntax
AFAICT the syntax for dg-require-ifunc seems to be
/* { dg-require-ifunc "" } */
with two sets of exceptions:
(1) gcc.target/i386/pr90500-*.c
which explains
FAIL: gcc.target/i386/pr90500-1.c (test for errors, line 6)
FAIL: gcc.target/i386/pr90500-1.c (test for warnings, line 6)
FAIL: gcc.target/i386/pr90500-1.c (test for excess errors)
FAIL: gcc.target/i386/pr90500-2.c (test for errors, line 6)
FAIL: gcc.target/i386/pr90500-2.c (test for warnings, line 6)
FAIL: gcc.target/i386/pr90500-2.c (test for excess errors)
and is fixed with the trivial patch
--- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-1.c 2019-05-16
17:34:09.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr90500-1.c 2019-05-18 14:28:12.0
+0200
@@ -1,6 +1,6 @@
/* PR middle-end/84723 */
/* { dg-do compile } */
-/* { dg-require-ifunc } */
+/* { dg-require-ifunc "" } */
__attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
__typeof(__tanh) tanhf64 __attribute__((alias("__tanh")))/* { dg-error "clones
for .target_clones. attribute cannot be created" } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-2.c 2019-05-16
17:34:09.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr90500-2.c 2019-05-18 14:28:25.0
+0200
@@ -1,6 +1,6 @@
/* PR middle-end/84723 */
/* { dg-do compile } */
-/* { dg-require-ifunc } */
+/* { dg-require-ifunc "" } */
__attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
__typeof(__tanh) tanhf64
__attribute__((alias("__tanh"),target_clones("arch=haswell", "default"))); /* {
dg-error "clones for .target_clones. attribute cannot be created" } */
(2) gcc.target/i386/pr84723-*.c
which succeed on darwin. What is the suitable fix for that?
(a) Fix the dg-require-ifunc as above?
(b) Remove the line?
TIA
Dominique
Re: [Patch, fortran] PR90498 - [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)
Hi Paul, s:PR fortran/90948:PR fortran/90498:g TIA Dominique
Re: [patch, fortran] Inline argument packing
> Le 11 mai 2019 à 15:49, Thomas Koenig a écrit : > > Hi Dominique, > >> How ever adding the new tests is a real PITA!-( >> Could you improve the naming scheme for them > > What should be the preferrred naming scheme for a > test that is split? I'm open to suggestions (but also, > the naming convention should not matter once the test > cases are committed). Well, when the naming I use for testing does not correspond to the one committed I have to clean the mess!-( You have attachments for typebound_assignment_5a.f90 and typebound_assignment_6a.f90 It would be nice to have similar attachments for the other splits. Also I can guess the names for the new tests, but it would help to have them in the same order as in the mail. (I think you should really use the +N option for the diff). Dominique > > Regards > > Thomas
Re: [patch, fortran] Inline argument packing
Hi Thomas, I confirm that the new patch fixes the ICE. How ever adding the new tests is a real PITA!-( Could you improve the naming scheme for them TIA Dominique
Re: [PATCH] PR fortran/90166 -- Add check for module prefix
Hi Steve, > Ping. AFAICT this has been committed as revision r270495. Cheers, Dominique
Re: [Patch, fortran] ISO_Fortran_binding PRs 90093, 90352 & 90355
Hi Paul, With your patch, I see FAIL: gfortran.dg/iso_c_binding_char_1.f90 -O (test for errors, line 8) FAIL: gfortran.dg/iso_c_binding_char_1.f90 -O (test for errors, line 9) FAIL: gfortran.dg/iso_c_binding_char_1.f90 -O (test for excess errors) This is due to a bad location of the errors: /opt/gcc/work/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90:7:16: 7 | subroutine bar(c,d) BIND(C) |1 Error: Character argument 'c' at (1) must be length 1 because procedure 'bar' is BIND(C) /opt/gcc/work/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90:7:18: 7 | subroutine bar(c,d) BIND(C) | 1 Error: Character argument 'd' at (1) must be length 1 because procedure 'bar' is BIND(C) TIA Dominique
Re: [PATCH] Silent -Wformat-truncation warnings in date_and_time.c.
Martin, With your patch I still see ../../../work/libgfortran/intrinsics/date_and_time.c:168:33: warning: '%03d' directive output may be truncated writing between 3 and 8 bytes into a region of size between 0 and 4 [-Wformat-truncation=] TIA Dominique
Re: [PATCH][stage1] Prefer to use strlen call instead of inline expansion (PR target/88809).
Done as revision r270843. Dominique > Le 3 mai 2019 à 11:06, Martin Liška a écrit : > > Feel free to install the patch please. > > Martin
Re: [PATCH][stage1] Prefer to use strlen call instead of inline expansion (PR target/88809).
Hi Martin
On Tue, Apr 30, 2019 at 10:00:07AM -0600, Jeff Law wrote:
> > 2019-04-23 Martin Liska
> >
> > PR target/88809
> > * config/i386/i386.c (ix86_expand_strlen): Use strlen call.
> > With -minline-all-stringops use inline expansion using 4B loop.
> > * doc/invoke.texi: Document the change of
> > -minline-all-stringops.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2019-04-23 Martin Liska
> >
> > PR target/88809
> > * gcc.target/i386/pr88809.c: New test.
> > * gcc.target/i386/pr88809-2.c: New test.
> OK for the trunk.
The tests fail on darwin
FAIL: gcc.target/i386/pr88809-2.c scan-assembler call[ \\t]strlen
FAIL: gcc.target/i386/pr88809.c scan-assembler call[ \\t]strlen
This is fixed with the following patch
--- ../_clean/gcc/testsuite/gcc.target/i386/pr88809.c 2019-05-02
10:16:16.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr88809.c 2019-05-03 10:11:37.0
+0200
@@ -6,4 +6,4 @@ unsigned int foo (const char *ptr)
return __builtin_strlen (ptr);
}
-/* { dg-final { scan-assembler "call\[ \t\]strlen" } } */
+/* { dg-final { scan-assembler "call\[ \t\]_?strlen" } } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr88809-2.c 2019-05-02
10:16:16.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr88809-2.c 2019-05-03 11:00:28.0
+0200
@@ -6,4 +6,4 @@ unsigned int foo (const char *ptr)
return __builtin_strlen (ptr);
}
-/* { dg-final { scan-assembler "call\[ \t\]strlen" } } */
+/* { dg-final { scan-assembler "(jmp|call)\[ \t\]_?strlen" } } */
(the ‘call’ is replaced with a ‘amp’ when using -m32).
TIA
Dominique
Re: [patch, fortran] Fix PR 61968
Hi Thomas, > … > This also clears the ICE for my inline packing patch which > was reported by Dominique. > … Not for me, I still get % gfc pr61968.f90 -c -O3 pr61968.f90:32:0: 32 | call test_lib (a, int (sizeof (a), kind=c_size_t)) | internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:1265 TIA Dominique
Re: PING [RFA patch, Fortran] PR60144 - Misleading error message when missing "then" after "if" and "else if"
If there is no objection, I’ll commit the patch to trunk tonight. Dominique > Le 27 mars 2019 à 19:48, Thomas Koenig a écrit : > > Hi Dominique, > >> Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html > > I think the patch is OK. I think the patch is probably appropriate for > stage 1 once that reopens. > > Regards > > Thomas
Re: [patch, fortran] Inline packing for array temporaries
Hi Thomas,
> (Dominique, could you tell us again what the magic incantation for
> 32-bit mode is?)
I use:
time make -k -j8 check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'" > &
check-*.log &
Dominique
Re: [PATCH] PR fortran/90166 -- check F2018:C1547
> Le 21 avr. 2019 à 18:02, Steve Kargl a
> écrit :
>
> On Sat, Apr 20, 2019 at 09:51:11PM +0200, Dominique d'Humières wrote:
>> OK I missed the previous error. However I am still puzzled by (2):
>>
>> +
>> +found outside of a module
>>
>
> Why are you puzzled? Did you read the patch?
I read
Index: gcc/testsuite/gfortran.dg/submodule_22.f08
===
--- gcc/testsuite/gfortran.dg/submodule_22.f08 (revision 270181)
+++ gcc/testsuite/gfortran.dg/submodule_22.f08 (working copy)
@@ -40,8 +40,10 @@ end
submodule (mtop:submod:subsubmod) subsubsubmod ! { dg-error "Syntax error in
SUBMODULE statement" }
contains
- module subroutine sub3
-r = 2.0
-s = 2.0
- end subroutine sub3
+ module subroutine sub3 ! { dg-error "found outside of a module" }
+r = 2.0 ! { dg-error "Unexpected assignment" }
+s = 2.0 ! { dg-error "Unexpected assignment" }
+ end subroutine sub3 ! { dg-error "Expecting END PROGRAM statement" }
end
+
+found outside of a module
^ I cannot relate this to any dejagnu command
Dominique
> The
> entire error message is
>
> + gfc_error ("MODULE prefix at %C found outside of a module, "
> +"submodule, or interface");
>
> In
>
> program foo
> contains
> module subroutine foo
> end subroutine foo
> end program foo
>
> The "MODULE prefix" attached to "subroutine foo" is
> found outside of a module, a submodule, or interface.
>
> --
> Steve
Re: [PATCH] PR fortran/90166 -- check F2018:C1547
OK I missed the previous error. However I am still puzzled by (2):
+
+found outside of a module
Dominique
> Le 20 avr. 2019 à 21:18, Steve Kargl a
> écrit :
>
> On Sat, Apr 20, 2019 at 09:57:34AM -0700, Steve Kargl wrote:
>> On Sat, Apr 20, 2019 at 05:38:34PM +0200, Dominique d'Humières wrote:
>>>
>>> The changes in gfortran.dg/submodule_22.f08 look weird:
>>> (1) is the error in the CONTAINS of a SUBMODULE invalid?
>>> From
>>>
>>> * decl.c (in_module_or_interface): New function to check that the
>>> current state is in a module, submodule, or interface.
>>>
>>> it should not, should it?
>>>
>>> (2) left over?
>>> +
>>> +found outside of a module
>>>
>>
>> It's a sequence of run-on errors. The first statement in
>> the original code is rejected with a syntax error. When
>> that happenrs gfc_current_state() is not COMP_MODULE,
>> COMP_SUBMODULE, or COMP_INTERFENCE. The next line has
>> the MODULE prefix, and the new check finds that it
>> occurs outside of MODULE, SUBMODULE, and INTERFERENCE,
>> so a new error occurs. The remaining errors are then
>> found to be bogus assignments. My conclusion, if the
>> first error is fixed, then the run-on errors don't
>> happen.
>>
>> If you rather fix the problems with '! dg-options "-fmax-errors=1"'
>> I'm fine with that.
>>
>
> Just to follow up. If you use a debugger, one finds
>
> (gdb) b decl.c:6130
> (gdb) c
> Continuing.
> /safe/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/submodule_22.f08:41:23:
>
> 41 | submodule (mtop:submod:subsubmod) subsubsubmod ! { dg-error "Syntax
> error in SUBMODULE statement" }
> | 1
> Error: Syntax error in SUBMODULE statement at (1)
>
> This is the original error. Note it is a syntax error. gfortran
> does nothing with this statement
>
> (gdb) c
>
> we reach the point where the new error will be issued.
>
> (gdb) p gfc_state_stack->state
> $2 = COMP_CONTAINS
>
> This is the CONTAINS in the submodule.
>
> (gdb) p gfc_state_stack->previous->state
> $3 = COMP_PROGRAM
>
> This state fine here, because the syntax rejects the submodule
> statement. So, the code looks like (from memory...)
>
> [program main implicitly included here]
> contains
> module subroutine foo
> x = 2
> y = 3
> end submodule
>
> The module prefix cannot appear in the subroutine statement. The
> new error rejects it. So, now you have 2 assignments in after a
> contains statement. The program now looks like
>
> contains
> x = 2
> y = 3
> end submodule
>
> Well, you cannot do an assignment, so two additional error messages
> are emitted. So, now we come to a program of the form
>
>
> [program main implicitly included here]
> end submodule
>
> gfortran is expecting an END [PROGRAM] statement.
>
> Is this clear or do you want me to withdrawal the patch?
>
> --
> Steve
Re: [PATCH] PR fortran/90166 -- check F2018:C1547
Hi Steve, The changes in gfortran.dg/submodule_22.f08 look weird: (1) is the error in the CONTAINS of a SUBMODULE invalid? From * decl.c (in_module_or_interface): New function to check that the current state is in a module, submodule, or interface. it should not, should it? (2) left over? + +found outside of a module TIA Dominique
Re: Fix false -Wodr warnings
> Le 16 avr. 2019 à 15:07, Jakub Jelinek a écrit :
>
> On Tue, Apr 16, 2019 at 02:51:14PM +0200, Jan Hubicka wrote:
>>> Hi Jan,
>>>
>>> The test causes
>>>
>>> WARNING: lto.exp does not support dg-do
>>> WARNING: lto.exp does not support dg-options in primary source file
>>>
>>> This is fixed by the following patch
>>>
>>> --- ../_clean/gcc/testsuite/g++.dg/lto/pr89358_0.C 2019-04-15
>>> 00:04:48.0 +0200
>>> +++ gcc/testsuite/g++.dg/lto/pr89358_0.C2019-04-16 13:13:14.0
>>> +0200
>>> @@ -1,5 +1,5 @@
>>> -/* { dg-do link } */
>>> -/* { dg-options "-std=c++17" } */
>>> +/* { dg-lto-do link } */
>>> +/* { dg-lto-options "-std=c++17" } */
>>
>> Thanks, this changle is OK.
>> Honza
Committed as revision r270390
Dominique
Re: Fix false -Wodr warnings
Hi Jan,
The test causes
WARNING: lto.exp does not support dg-do
WARNING: lto.exp does not support dg-options in primary source file
This is fixed by the following patch
--- ../_clean/gcc/testsuite/g++.dg/lto/pr89358_0.C 2019-04-15
00:04:48.0 +0200
+++ gcc/testsuite/g++.dg/lto/pr89358_0.C2019-04-16 13:13:14.0
+0200
@@ -1,5 +1,5 @@
-/* { dg-do link } */
-/* { dg-options "-std=c++17" } */
+/* { dg-lto-do link } */
+/* { dg-lto-options "-std=c++17" } */
#include
extern void test();
--- ../_clean/gcc/testsuite/g++.dg/lto/pr89358_1.C 2019-04-15
00:04:48.0 +0200
+++ gcc/testsuite/g++.dg/lto/pr89358_1.C2019-04-16 13:14:44.0
+0200
@@ -1,4 +1,3 @@
-/* { dg-options "-std=c++14" } */
#include
void test()
TIA
Dominique
Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.
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
[PATCH committed] [Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
Author: dominiq
Date: Mon Apr 15 07:56:43 2019
New Revision: 270360
URL: https://gcc.gnu.org/viewcvs?rev=270360=gcc=rev
Log:
2019-04-15 Dominique d'Humieres
PR tree-optimization/90020
* gcc.dg/torture/pr90020.c: Add linker options for darwin.
--- trunk/gcc/testsuite/gcc.dg/torture/pr90020.c2019/04/15 07:39:20
270359
+++ trunk/gcc/testsuite/gcc.dg/torture/pr90020.c2019/04/15 07:56:43
270360
@@ -1,5 +1,7 @@
/* { dg-do run } */
/* { dg-require-weak "" } */
+/* { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target
*-*-darwin* } } */
+/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } }
*/
void __attribute__((noinline,noclone))
check (int i)
Dominique
Re: [patch] PR 79842 - i18n: subword translation in "Can't use the same %smodule"
Committed as revision r270338.
Dominique
> Le 11 avr. 2019 à 11:54, Dominique d'Humières a écrit :
>
> Hi all,
>
> I am planning to commit the following patch
>
> --- ../_clean/gcc/fortran/module.c2019-03-21 20:46:46.0 +0100
> +++ gcc/fortran/module.c 2019-04-11 10:28:37.0 +0200
> @@ -7144,8 +7144,12 @@ gfc_use_module (gfc_use_list *module)
> for (p = gfc_state_stack; p; p = p->previous)
> if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
>&& strcmp (p->sym->name, module_name) == 0)
> - gfc_fatal_error ("Cannot USE the same %smodule we're building",
> -p->state == COMP_SUBMODULE ? "sub" : "");
> + {
> + if (p->state == COMP_SUBMODULE)
> + gfc_fatal_error ("Cannot USE a submodule that is currently built");
> + else
> + gfc_fatal_error ("Cannot USE a module that is currently built");
> + }
>
> init_pi_tree ();
> init_true_name_tree ();
>
> While testing it I did not find any coverage of these errors in the test
> suite.
>
> TIA
>
> Dominique
>
Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.
With the following code module cdesc interface function cdesc_f08(buf, expected) result (res) BIND(C, name="cdesc_c") USE, INTRINSIC :: ISO_C_BINDING implicit none INTEGER(C_INT) :: res type(*), dimension(..), INTENT(INOUT) :: buf type(c_ptr),INTENT(IN) :: expected end function cdesc_f08 end interface end module program cdesc_test USE, INTRINSIC :: ISO_C_BINDING use cdesc implicit none integer(c_int), target :: a0, a1(10), a2(10,10), a3(10,10,10) if (cdesc_f08(a0, C_LOC(a0)) .ne. 1) stop 1 if (cdesc_f08(a1, C_LOC(a1(1))) .ne. 1) stop 2 if (cdesc_f08(a2, C_LOC(a2(1,1))) .ne. 1) stop 3 if (cdesc_f08(a3, C_LOC(a3(1,1,1))) .ne. 1) stop 4 end program The test ISO_Fortran_binding_9.f90 executes without failure for both -m32 and -m64. Dominique > Le 10 avr. 2019 à 00:42, Paul Richard Thomas > a écrit : > > Many thanks, sir! I will look into it. > > Paul
[patch] PR 79842 - i18n: subword translation in "Can't use the same %smodule"
Hi all,
I am planning to commit the following patch
--- ../_clean/gcc/fortran/module.c 2019-03-21 20:46:46.0 +0100
+++ gcc/fortran/module.c2019-04-11 10:28:37.0 +0200
@@ -7144,8 +7144,12 @@ gfc_use_module (gfc_use_list *module)
for (p = gfc_state_stack; p; p = p->previous)
if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
&& strcmp (p->sym->name, module_name) == 0)
- gfc_fatal_error ("Cannot USE the same %smodule we're building",
- p->state == COMP_SUBMODULE ? "sub" : "");
+ {
+ if (p->state == COMP_SUBMODULE)
+ gfc_fatal_error ("Cannot USE a submodule that is currently built");
+ else
+ gfc_fatal_error ("Cannot USE a module that is currently built");
+ }
init_pi_tree ();
init_true_name_tree ();
While testing it I did not find any coverage of these errors in the test suite.
TIA
Dominique
Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.
Hi Paul, With your patch the test gfortran.dg/ISO_Fortran_binding_9.f90 fails in the 32 bit mode, due to the errors /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_9.f90:24:6: Error: Type mismatch in argument 'expected' at (1); passed INTEGER(4) to INTEGER(8) /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_9.f90:25:6: Error: Type mismatch in argument 'expected' at (1); passed INTEGER(4) to INTEGER(8) /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_9.f90:26:6: Error: Type mismatch in argument 'expected' at (1); passed INTEGER(4) to INTEGER(8) /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_9.f90:27:6: Error: Type mismatch in argument 'expected' at (1); passed INTEGER(4) to INTEGER(8) Note that LOC is a gnu extension. The patch also fixes pr89846 for -m64, but not for -m32 % gfc pr89846.c pr89846.f90 -m32 % a.out FAIL 2: FAIL 4: % gfc pr89846.c pr89846.f90 % a.out OK OK TIA Dominique
Re: [Patch fortran] PR 68567 - ICE on using wrong defined arrays (different cases/messages)
Thanks for the quick answer. Committed as revision r270137. Dominique > Le 3 avr. 2019 à 21:15, Steve Kargl a > écrit : > > On Wed, Apr 03, 2019 at 05:01:42PM +0200, Dominique d'Humières wrote: >> Hi Steve, >> >> Do you agree with the following packaging of your patch for pr68567? >> > > I honestly don't remember why I did not submit the patch to the list. > If it fixes the bug and regression tests cleanly, then I won't object > to committing the patch. > > -- > Steve
[committed] [Patch, fortran] PR 89375 fortran/expr.c:4723:5: warning: logical ‘or’ of equal expressions [-Wlogical-op]
Committed as obvious at revision r270115: 2019-04-03 Dominique d'Humieres PR fortran/89375 * expr.c (comp_pointer): Remove redundant condition. Dominique
[Patch fortran] PR 68567 - ICE on using wrong defined arrays (different cases/messages)
Hi Steve,
Do you agree with the following packaging of your patch for pr68567?
2019-04-03 Steven G. Kargl
PR fortran/68567
* expr.c (gfc_reduce_init_expr): Add extra check to avoid dereferencing
a null
pointer.
2019-04-03 Dominique d'Humieres
PR fortran/68567
* gfortran.dg/parameter_array_error_1.f90: New test.
--- ../_clean/gcc/fortran/expr.c2019-04-03 11:00:55.0 +0200
+++ gcc/fortran/expr.c 2019-04-02 20:55:20.0 +0200
@@ -3003,7 +3003,7 @@ gfc_reduce_init_expr (gfc_expr *expr)
t = gfc_check_init_expr (expr);
gfc_init_expr_flag = false;
- if (!t)
+ if (!t || !expr)
return false;
if (expr->expr_type == EXPR_ARRAY)
! { dg-do compile }
! PR68567
! Contributed by Gerhard Steinmetz
!
program p
integer, parameter :: a(:) = [2, 1] ! { dg-error "cannot be automatic or of
deferred shape" }
end
Tested on darwin for more than two years.
TIA
Dominique
Re: [Patch, fortran] PR87127 - External function not recognised from within an associate block
Hi Paul, With your patch the error for the test gfortran.dg/pr88376.f90 is changed from Error: 'n' at (1) is not a function to Error: Specification function 'n' at (1) must be PURE TIA Dominique
Re: [Patch, fortran] PR89841 - improper descriptor information passed to C
Hi Paul, > While I was about it, I committed the fix for PR89841 with the fix for > PR89842. The latter is even safer than the former. This also fixes PR89844. Thanks, Dominique
PING [RFA patch, Fortran] PR60144 - Misleading error message when missing "then" after "if" and "else if"
PING! Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html TIA Dominique
[RFA patch, Fortran] PR60144 - Misleading error message when missing "then" after "if" and "else if"
With the proposed patch
2 | if (.TRUE.)
| 1
Error: Cannot assign to a named constant at (1)
3 | else if (.FALSE.)
| 1
Error: Unexpected junk after ELSE statement at (1)
is changed to
2 | if (.TRUE.)
| 1
Error: Syntax error in IF-clause after (1)
3 | else if (.FALSE.)
| 1
Error: Missing THEN in ELSE IF statement after (1)
The first change is done by removing the block
/* The gfc_match_assignment() above may have returned a MATCH_NO
…
return MATCH_ERROR;
}
This block has been introduced at revision r116570 to handle assignment to a
named constant as in the test
simpleif_2.f90, but this is now handled elsewhere.
The second change is done by some more parsing of the ELSE IF statement.
While at these changes, I have also made the error
3 | if (.FALSE. then c="!"
|1
Error: Missing ')' in statement at or before (1)
to be less surprising
3 | if (.FALSE. then c="!"
| 1
Error: Missing ')' in statement at or before (1)
Also
7 | if a=b !
|1
Error: Unclassifiable statement at (1)
changed to
7 | if a=b !
| 1
Error: Missing '(' in IF-expression at (1)
which avoids the error to be deleted if it appears after other ones.
Bootstrapped and tested on darwin. Is it OK for trunk?
TIA
Dominique
2019-03-17 Dominique d'Humieres
PR fortran/60144
* match.c (gfc_match_parens): Change the location for missing ')'.
(gfc_match_if): Detect a missing '('. Remove the spurious named
constant error. Change the wording of some errors.
(gfc_match_else): Change the wording of an error.
(gfc_match_elseif): Detect a missing '('. Improve the matching
process to get a better syntax analysis.
2019-03-17 Dominique d'Humieres
PR fortran/60144
* gfortran.dg/block_name_2.f90: Adjust dg-error.
* gfortran.dg/dec_type_print_3.f90.f90: Likewise
* gfortran.dg/pr60144.f90: New test.
patch-60144
Description: Binary data
Re: [patch, fortran] Fix PR 88008, ICE on invalid
Hi Thomas,
The patch looks good to me, with one nit:
+ gfc_error ("Error in component call at %L",
and
call x%z%g() ! { dg-error "Error in typebound call" }
doesn’t look right.
Thanks for the patch.
Dominique
Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target
> Le 13 mars 2019 à 13:39, Harald Anlauf a écrit : > > Hi Thomas, > > I am not so convinced that "plain english" messages are the way to go, > even if they appear better readable at first sight, if conciseness is > lost. Well, "Syntax error" is concise, but not really helpful! > The main reason is that there three variants of the messages, > depending on context. One of them refers to expecting either a > bounds-specification-list or a bounds-remapping-list. > > Do you prefer sth. like > > "All lower bounds and all or none of the upper bounds must be specified" This is what I expect for p(:,:)=>a and I won’t complain if "use the later for bound remapping" is added when the target is a rank 1 array. For mat(2, 6) => arr I would prefer the above error rather than "Expected bounds specification ». For p(1:,1:)=>a where a is a rank 1 target, I’ll go with "all the upper bounds must be specified for bound remapping" > or > > "Either all or none of the upper bounds must be specified at (1)" This is what I expect for p(1:3,1:)=>a with the same remark as above about bound remapping. > (which we currently print in another context where it is wrong), > > while other compilers print: > > E.g. Crayftn: > > p(1 ,2:3) => t >^ > ftn-1768 crayftn: ERROR SUB, File = ptr-remap.f90, Line = 3, Column = 5 > Invalid bounds-spec-list or bounds-remapping-list for this pointer > assignment. > > E.g. Intel: > > ptr-remap.f90(3): error #8524: The syntax of this data pointer assignment is > incorrect: either 'bound spec' or 'bound remapping' is expected in this > context. [1] > p(1 ,2:3) => t > ^ > > Pointer remapping belongs IMHO to the 'more advanced’ features Agreed > and requires > some technical insight to get it right, which is why I think the related > error messages should be more technical and concise. Here I disagree, the error message should try to tell the user what is wrong without requiring any access to the standard. > > I'll think for another day or two. > > Thanks, > Harald These defines should probably be swapped +#define BOUNDS_SPEC_LIST "list of %" +#define BOUNDS_REMAPPING_LIST "list of %" to match > R1035 bounds-spec is lower-bound-expr : > R1036 bounds-remapping is lower-bound-expr : upper-bound-exp Dominique
Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target
Hi Harald, The patch looks good to me (although I did not test it), however I don’t like the standard legalese in the error messages. IMO R1035 bounds-spec is lower-bound-expr : R1036 bounds-remapping is lower-bound-expr : upper-bound-exp should be rephrased in plain English. Thanks for the work. Dominique
Re: [patch, fortran] Fix PR 66089, ICE (plus wrong code) in dependency handling
Hi Thomas, > Anything else? … Yes, the tests gfortran.dg/assumed_type_2.f90 and gfortran.dg/no_arg_check_2.f90 fail: FAIL: gfortran.dg/assumed_type_2.f90 -O scan-tree-dump-times original "sub_array_assumed (D" 3 (found 4 times) FAIL: gfortran.dg/assumed_type_2.f90 -O scan-tree-dump-times original "sub_array_assumed ((struct t1.0:. .) array_class_t1_ptr._data.data);" 1 (found 0 times) FAIL: gfortran.dg/no_arg_check_2.f90 -O scan-tree-dump-times original "sub_array_assumed (D" 3 (found 4 times) FAIL: gfortran.dg/no_arg_check_2.f90 -O scan-tree-dump-times original "sub_array_assumed ((struct t1.0:. .) array_class_t1_ptr._data.data);" 1 (found 0 times) TIA Dominique
Re: [PR fortran/89492, patch] - [9 Regression] Endless compilation of an invalid TRANSFER after r269177
Hi Harald, > Rev. 269177 uncovered a latent issue in TRANSFER when the MOLD argument > had storage size 0, resulting in an infinite loop. The attached patch > rejects illegal cases and handles the case where storage size of both > SOURCE and MOLD are 0. It also verifies proper simplification for > some cases, some of which were not always properly handled before. LGTM. Thanks for the quick fix. Dominique PS: Don’t forget to close the PRs you have fixed.
[committed fortran] New test for PR89282 - Garbage arithmetics results in fortran with -O3 and overloaded operators
New test committed as r269190. Dominique
Re: [patch, fortran] Fix PR 89174, segfault on allocate with MOLD
Hi Thomas,
I see a double space in
! { dg-do run }
Is this intended? If yes, it should probably be documented, otherwise it should
be fixed.
TIA
Dominique
[PATCH committed Fortran] PR89274 - Inconsistent list directed output of INTEGER(16)
Committed as revision r269187. Dominique
Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor
Hi! Please hold on! With the patch, compiling the test from 34202 program bug4a implicit none type bug4 ! Intentionally left empty end type bug4 type compound integer a type(bug4) b type(bug4) c integer d type(bug4) e end type compound type(bug4) t type(compound) c type(bug4), parameter :: f = bug4() type(compound), parameter :: g = compound(1,f,bug4(),4,f) type other real x(0) end type other c = compound(1,t,t,4,t) write(*,*) c write(*,*) g%d write(*,*) size(transfer(1,[bug4()])) write(*,*) size(transfer(1,[''])) write(*,*) size(transfer(1,[other()])) write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) end program bug4a start something weird after emitting the error % time gfcp pr34202.f90 pr34202.f90:27:54: 27 |write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) | 1 Error: Function 'size' requires an argument list at (1) ^C0.003u 0.005s 0:12.66 0.0%0+0k 0+0io 0pf+0w TIA Dominique
[New test fortran, committed] PR 52789 gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
New test committed as obvious at revision r268656. Dominique
Re: [PATCH fortran] PR 81344 - Can't disable -ffpe-trap (or not documented)
Committed as revision r268480 after approval by Jerry on IRC. Cheers, Dominique
[PATCH fortran] PR 81344 - Can't disable -ffpe-trap (or not documented)
Hi!
I am planning to commit the following patch (with a suitable ChangeLog entry)
--- ../_clean/gcc/fortran/invoke.texi 2019-01-30 16:54:38.0 +0100
+++ gcc/fortran/invoke.texi 2019-02-01 11:52:01.0 +0100
@@ -1203,6 +1203,12 @@ The first three exceptions (@samp{invali
has provisions for dealing with these exceptions, enabling traps for
these three exceptions is probably a good idea.
+If the option is used more than once in the command line, the lists will
+be joined: '@code{ffpe-trap=}@var{list1} @code{ffpe-trap=}@var{list2}'
+is equivalent to @code{ffpe-trap=}@var{list1,list2}.
+
+Note that once enabled an exception cannot be disabled (no negative form).
+
Many, if not most, floating point operations incur loss of precision
due to rounding, and hence the @code{ffpe-trap=inexact} is likely to
be uninteresting in practice.
@@ -1218,6 +1224,9 @@ of the following exceptions: @samp{inval
@samp{underflow}, @samp{inexact} and @samp{denormal}. (See
@option{-ffpe-trap} for a description of the exceptions.)
+If the option is used more than once in the command line, only the
+last one will be used.
+
By default, a summary for all exceptions but @samp{inexact} is shown.
@item -fno-backtrace
then to close the PR as WONTFIX. Is it OK?
TIA
Dominique
Re: [Patch, fortran] PR88685 - [8/9 regression] pointer class array argument indexing
Hi Paul, Are you sure about the && in + && ref->u.c.component->ts.type != BT_DERIVED)) should not it be ||? TIA Dominique
Re: [PATCH, fortran] PR 52884 - double precision constants promoted to 16 byte by -fdefault-real-8
No objection, so committed as revision r268396 with the ChangeLog
2019-01-30 Dominique d'Humieres Le 27 janv. 2019 à 15:19, Dominique d'Humières a écrit :
>
> Hi,
>
> The following patch is an update of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884#c3,
> I am planning to commit with a suitable ChangeLog if there is no objection.
> Tested on darwin.
>
> TIA
>
> Dominique
>
> --- ../_clean/gcc/fortran/invoke.texi 2019-01-19 22:48:32.0 +0100
> +++ gcc/fortran/invoke.texi 2019-01-27 15:06:11.0 +0100
> @@ -416,36 +416,45 @@ kind declaration.
>
> @item -fdefault-real-8
> @opindex @code{fdefault-real-8}
> -Set the default real type to an 8 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 8 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-8}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike @option{-freal-4-real-8},
> +@code{fdefault-real-8} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-real-10
> @opindex @code{fdefault-real-10}
> -Set the default real type to a 10 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-10},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 10 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-10}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike
> @option{-freal-4-real-10},
> +@code{fdefault-real-10} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-real-16
> @opindex @code{fdefault-real-16}
> -Set the default real type to a 16 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 16 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-16}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike
> @option{-freal-4-real-16},
> +@code{fdefault-real-16} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-double-8
> @opindex @code{fdefault-double-8}
> -Set the @code{DOUBLE PRECISION} type to an 8 byte wide type. Do nothing if
> this
> -is already the default. If @option{-fdefault-real-8} is given,
> -@code{DOUBLE PRECISION} would instead be promoted to 16 bytes if possible,
> and
> -@option{-fdefault-double-8} can be used to prevent this. The kind of real
> -constants like @code{1.d0} will not be changed by @option{-fdefault-real-8}
> -though, so also @option{-fdefault-double-8} does not affect it.
> +Set the @code{DOUBLE PRECISION} type and double real constants
> +like @code{1.d0} to an 8 byte wide type. Do nothing if this
> +is already the default. This option prevents @option{-fdefault-real-8},
> +@option{-fdefault-real-10}, and @option{-fdefault-real-16},
> +from promoting @code{DOUBLE PRECISION} and double real constants like
> +@code{1.d0} to 16 bytes.
>
> @item -finteger-4-integer-8
> @opindex @code{finteger-4-integer-8}
>
Re: testsuite dg-directives glitches
> Le 28 janv. 2019 à 14:54, Manfred Schwarb a écrit :
>
> 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 »
Committed as r268393
>
> and in the GCC-8 branch I found
> ./newunit_5.f90.f90:1:! { dg-do run )
Fixed and renamed to newunit_5.f90 at r268389.
Thanks, Dominique
>
> Thanks,
> Manfred
[PATCH, fortran] PR 52884 - double precision constants promoted to 16 byte by -fdefault-real-8
Hi,
The following patch is an update of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884#c3,
I am planning to commit with a suitable ChangeLog if there is no objection.
Tested on darwin.
TIA
Dominique
--- ../_clean/gcc/fortran/invoke.texi 2019-01-19 22:48:32.0 +0100
+++ gcc/fortran/invoke.texi 2019-01-27 15:06:11.0 +0100
@@ -416,36 +416,45 @@ kind declaration.
@item -fdefault-real-8
@opindex @code{fdefault-real-8}
-Set the default real type to an 8 byte wide type. This option also affects
-the kind of non-double real constants like @code{1.0}, and does promote
-the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
-@code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
-it does not promote variables with explicit kind declaration.
+Set the default real type to an 8 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}. This option promotes
+the default width of @code{DOUBLE PRECISION} and double real constants
+like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
+is given along with @code{fdefault-real-8}, @code{DOUBLE PRECISION}
+and double real constants are not promoted. Unlike @option{-freal-4-real-8},
+@code{fdefault-real-8} does not promote variables with explicit kind
+declarations.
@item -fdefault-real-10
@opindex @code{fdefault-real-10}
-Set the default real type to a 10 byte wide type. This option also affects
-the kind of non-double real constants like @code{1.0}, and does promote
-the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
-@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-10},
-it does not promote variables with explicit kind declaration.
+Set the default real type to an 10 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}. This option promotes
+the default width of @code{DOUBLE PRECISION} and double real constants
+like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
+is given along with @code{fdefault-real-10}, @code{DOUBLE PRECISION}
+and double real constants are not promoted. Unlike @option{-freal-4-real-10},
+@code{fdefault-real-10} does not promote variables with explicit kind
+declarations.
@item -fdefault-real-16
@opindex @code{fdefault-real-16}
-Set the default real type to a 16 byte wide type. This option also affects
-the kind of non-double real constants like @code{1.0}, and does promote
-the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
-@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
-it does not promote variables with explicit kind declaration.
+Set the default real type to an 16 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}. This option promotes
+the default width of @code{DOUBLE PRECISION} and double real constants
+like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
+is given along with @code{fdefault-real-16}, @code{DOUBLE PRECISION}
+and double real constants are not promoted. Unlike @option{-freal-4-real-16},
+@code{fdefault-real-16} does not promote variables with explicit kind
+declarations.
@item -fdefault-double-8
@opindex @code{fdefault-double-8}
-Set the @code{DOUBLE PRECISION} type to an 8 byte wide type. Do nothing if
this
-is already the default. If @option{-fdefault-real-8} is given,
-@code{DOUBLE PRECISION} would instead be promoted to 16 bytes if possible, and
-@option{-fdefault-double-8} can be used to prevent this. The kind of real
-constants like @code{1.d0} will not be changed by @option{-fdefault-real-8}
-though, so also @option{-fdefault-double-8} does not affect it.
+Set the @code{DOUBLE PRECISION} type and double real constants
+like @code{1.d0} to an 8 byte wide type. Do nothing if this
+is already the default. This option prevents @option{-fdefault-real-8},
+@option{-fdefault-real-10}, and @option{-fdefault-real-16},
+from promoting @code{DOUBLE PRECISION} and double real constants like
+@code{1.d0} to 16 bytes.
@item -finteger-4-integer-8
@opindex @code{finteger-4-integer-8}
Fix for gcc-7-branch/gcc/testsuite/gfortran.dg/pr51434.f90
Committed as obvious at revision r268295
2019-01-26 Dominique d'Humieres
PR fortran/85579
* gfortran.dg/pr51434.f90: Fix the TRANSFER argument.
--- ../7_clean/gcc/testsuite/gfortran.dg/pr51434.f902018-03-10
01:18:34.0 +0100
+++ gcc/testsuite/gfortran.dg/pr51434.f90 2019-01-26 16:18:32.0
+0100
@@ -6,7 +6,7 @@ module foo
character(len=1), parameter :: s(n) = 'a'
type :: a
integer :: m = n
- character(len=1):: t(n) = transfer('abcde ', s)
+ character(len=1):: t(n) = transfer('abcde', s)
end type a
end module foo
Dominique
Re: testsuite dg-directives glitches
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?
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.f90 2019-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.f90 2019-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.f90 2019-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.f90 2019-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.f90 2019-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.f032019-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.f 2017-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*-*-* } }
C { dg-options "-mcpu=power7 -O3 -w -ffast-math -funroll-loops" }
SUBROUTINE MAKTABS(IW,SOME,LBOX1,LBOX2,LBOX3,NSPACE,NA,NB,
*LBST,X,
diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f90
gcc/testsuite/gfortran.dg/pr78259.f90
--- ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f902017-04-21
16:03:34.0 +0200
+++ gcc/testsuite/gfortran.dg/pr78259.f90 2019-01-25 12:31:01.0
+0100
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "-fdec-structure" }
!
! PR fortran/78259
--- ../7_clean/gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f 2017-04-21
16:03:30.0 +0200
+++ gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f 2019-01-25
12:28:37.0 +0100
@@ -1,7 +1,7 @@
C Test program for common block debugging. G. Helffrich 11 July 2004.
C {
Re: [PATCH] libgcc2.c: Correct DI/TI -> SF/DF conversions
The test gcc.dg/torture/fp-int-convert-timode-3.c fails on darwin: the results are -0x1p+127 -0x1p+127 TIA Dominique
Re: [patch, fortran] Move some array packing to front end
Hi Thomas, With your patch I see FAIL: gfortran.dg/internal_pack_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test with -m32. gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/internal_pack_4.f90 -O3 -funroll-loops -ftracer -m32 is enough to trigger the miscomputation. The changes in the test suite are quite messy and I hope I did not miss any test (you should do "diff -N …" for the new tests). Do you have test showing a speed-up? I agree with Richard that this patch should be held until the next stage 1. Thanks for this work. Dominique
Re: testsuite dg-directives glitches
I have committed the following patch to the gcc-8-branch as r268158 after a
regtest.
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 268156)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,23 @@
+2019-01-22 Manfred Schwarb
+
+ * gfortran.dg/array_function_5.f90: : Fix a dg directive.
+ * gfortran.dg/class_66.f90: Likewise.
+ * gfortran.dg/dec_structure_12.f90: Likewise.
+ * gfortran.dg/dec_structure_14.f90: Likewise.
+ * gfortran.dg/dec_structure_15.f90: Likewise.
+ * gfortran.dg/dtio_31.f03: Likewise.
+ * gfortran.dg/dtio_32.f03: Likewise.
+ * gfortran.dg/extends_11.f03: Likewise.
+ * gfortran.dg/integer_plus.f90: Likewise.
+ * gfortran.dg/matmul_const.f90: Likewise.
+ * gfortran.dg/namelist_96.f90: Likewise.
+ * gfortran.dg/pdt_25.f03: Likewise.
+ * gfortran.dg/pdt_28.f03: Likewise.
+ * gfortran.dg/pr58968.f: Likewise.
+ * gfortran.dg/pr78259.f90: Likewise.
+ * gfortran.dg/debug/pr35154-stabs.f: Likewise.
+ * gfortran.dg/vect/vect-2.f90: Likewise.
+
2019-01-22 Uroš Bizjak
PR target/88938
Index: gcc/testsuite/gfortran.dg/array_function_5.f90
===
--- gcc/testsuite/gfortran.dg/array_function_5.f90 (revision 268156)
+++ gcc/testsuite/gfortran.dg/array_function_5.f90 (working copy)
@@ -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
Index: gcc/testsuite/gfortran.dg/class_66.f90
===
--- gcc/testsuite/gfortran.dg/class_66.f90 (revision 268156)
+++ gcc/testsuite/gfortran.dg/class_66.f90 (working copy)
@@ -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.
Index: gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f
===
--- gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f (revision 268156)
+++ gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f (working copy)
@@ -1,7 +1,7 @@
C Test program for common block debugging. G. Helffrich 11 July 2004.
C { dg-do compile }
C { dg-skip-if "No stabs" { aarch64*-*-* mmix-*-* alpha*-*-* hppa*64*-*-*
ia64-*-* *-*-vxworks* } }
-C { dg-skip-if "No stabs" {*-*-* } { "*" } { "-gstabs" } }
+C { dg-skip-if "No stabs" { *-*-* } { "*" } { "-gstabs" } }
common i,j
common /label/l,m
i = 1
Index: gcc/testsuite/gfortran.dg/dec_structure_12.f90
===
--- gcc/testsuite/gfortran.dg/dec_structure_12.f90 (revision 268156)
+++ gcc/testsuite/gfortran.dg/dec_structure_12.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "-fdec-structure" }
!
! Test a regression where multiple anonymous structures failed to
Index: gcc/testsuite/gfortran.dg/dec_structure_14.f90
===
--- gcc/testsuite/gfortran.dg/dec_structure_14.f90 (revision 268156)
+++ gcc/testsuite/gfortran.dg/dec_structure_14.f90 (working copy)
@@ -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
Index: gcc/testsuite/gfortran.dg/dec_structure_15.f90
===
--- gcc/testsuite/gfortran.dg/dec_structure_15.f90 (revision 268156)
+++ gcc/testsuite/gfortran.dg/dec_structure_15.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do "compile" }
+! { dg-do compile }
! { dg-options "" }
!
! PR fortran/77584
Index: gcc/testsuite/gfortran.dg/dtio_31.f03
===
--- gcc/testsuite/gfortran.dg/dtio_31.f03 (revision 268156)
+++ gcc/testsuite/gfortran.dg/dtio_31.f03 (working copy)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options="-w" }
+! { dg-options "-w" }
! PR fortran/79383
! Contributed by Walt Brainerd
module dollar_mod
Index: gcc/testsuite/gfortran.dg/dtio_32.f03
===
--- gcc/testsuite/gfortran.dg/dtio_32.f03 (revision 268156)
+++ gcc/testsuite/gfortran.dg/dtio_32.f03 (working copy)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options="-w" }
+! { dg-options "-w" }
! PR fortran/79383
! Contributed by Walt Brainerd
module dollar_mod
Index: gcc/testsuite/gfortran.dg/extends_11.f03
===
--- gcc/testsuite/gfortran.dg/extends_11.f03(revision 268156)
+++
Re: testsuite dg-directives glitches
> 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. > > 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. 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
Hi Manfred, > could someone please check and commit? Tested and committed as obvious at r268125. Thanks for the patch. Dominique
Re: [Patch, Fortran] PR 37835 -fno-automatic does not work for derived types with default initalizer
Thanks for the review, committed as r268098. Dominique > Le 19 janv. 2019 à 16:50, Thomas Koenig a écrit : > > Hi Dominique, > >> The patch for gcc/fortran/resolve.c is the modernized version of Paul’s >> patch in comment 4. >> It causes some regressions due to "Duplicate SAVE » warnings. >> They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is >> used as documented >> in the change for gcc/fortran/invoke.texi. >> Is it OK for trunk? > > I assume you did a regression test. OK if this has passed. I have never submitted a patch without regtesting it! > > Thanks for the patch! > > Regards > > Thomas
[Patch, Fortran] PR 37835 -fno-automatic does not work for derived types with default initalizer
Hi all! The patch for gcc/fortran/resolve.c is the modernized version of Paul’s patch in comment 4. It causes some regressions due to "Duplicate SAVE » warnings. They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is used as documented in the change for gcc/fortran/invoke.texi. Is it OK for trunk? TIA Dominique 2019-01-18 Dominique d'Humieres PR fortran/37835 * resolve.c (resolve_types): Add !flag_automatic. * symbol.c (gfc_add_save): Silence warnings. 2019-01-18 Dominique d'Humieres PR fortran/37835 * gfortran.dg/no-automatic.f90: New test. patch-37835 Description: Binary data
Re: [PATCH] restore CFString handling in attribute format (PR 88638)
Hi Martin, The patch on top of r267591 fixes pr88638 without regression. Note FAIL: c-c++-common/attributes-4.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attributes-4.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attributes-4.c -std=gnu++98 (test for excess errors) Thanks for the fix. Dominique
Re: [Committed] Fix the gcc.dg/plugin/plugindir*.c tests for darwin
> Committed on trunk as obvious Committed as revision r267599. Patch attached. Dominique patch-plug Description: Binary data
[Committed] Fix the gcc.dg/plugin/plugindir*.c tests for darwin
Committed on trunk as obvious * gcc.dg/plugin/plugindir1.c: Adjust dg-prune-output for Darwin. * gcc.dg/plugin/plugindir2.c: Likewise. * gcc.dg/plugin/plugindir3.c: Likewise. * gcc.dg/plugin/plugindir4.c: Likewise. Dominique
[PATCH] PR60563 - FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*
Is the following patch OK for trunk and the release branches?
2019-01-04 Dominique d'Humieres
* g++.dg/ext/sync-4.C: Add dg-xfail-run-if for darwin.
--- ../_clean/gcc/testsuite/g++.dg/ext/sync-4.C 2015-04-30 23:36:40.0
+0200
+++ gcc/testsuite/g++.dg/ext/sync-4.C 2019-01-03 20:28:29.0 +0100
@@ -1,4 +1,6 @@
/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* } } */
+/* FIXME The following additional option should be removed after the fix for
radr://19802258.
+/* { dg-xfail-run-if "PR60563 radr://19802258" { *-*-darwin* } } */
/* { dg-require-effective-target sync_long_long_runtime } */
/* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
/* { dg-additional-options "-march=pentium" { target { { i?86-*-* x86_64-*-* }
&& ia32 } } } */
TIA
Dominique
Re: [patch, fortran] Fix PR 88658, wrong type for MAX1 and friends type when simplifying
Hi Thomas, Your patch LGTM (and works as expected). Thanks for the quick fix and happy new year, Dominique
Re: [patch, fortran] Handle missing optional MASK for intrinsics
Hi Thomas, Another glitch: the following test (reduced from gfortran.dg/optional_absent_4.f90) module z implicit none contains subroutine findloc_4 (input, val, res, mask) logical, intent(in), optional :: mask(:,:) integer, intent(in) :: input(:,:) integer, dimension(:), intent(out) :: res integer, intent(in) :: val integer :: n = 1 res = findloc(input, val, dim=n) end subroutine findloc_4 end module z program main use z implicit none integer :: i2(2,3) = reshape([1,2,4,8,16,32], [2,3]) integer, dimension(3) :: res3 res3 = -2 call findloc_4 (i2, 4, res3) end program main gives at runtime a.out(77719,0x10335e5c0) malloc: Incorrect checksum for freed object 0x7fb131403d50: probably modified after being freed. Corrupt value: 0x0 a.out(77719,0x10335e5c0) malloc: *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. TIA, Dominique
Re: [patch, fortran] Handle missing optional MASK for intrinsics
Hi Thomas, There are some duplicate STOPs (6 and 10) in the test gfortran.dg/optional_absent_4.f90. Thanks for the patch, Dominique
[committed][darwin] Fix FAIL: g++.dg/abi/key2.C -std=gnu++* (test for excess errors)
The test g++.dg/abi/key2.C fails on darwin for trunk and the gcc8 branch due
the warning
/opt/gcc/_clean/gcc/testsuite/g++.dg/abi/key2.C: In function 'int sub()':
/opt/gcc/_clean/gcc/testsuite/g++.dg/abi/key2.C:17:2: warning: no return
statement in function returning non-void [-Wreturn-type]
17 | {}
This is fixed by the following patch:
--- ../_clean/gcc/testsuite/g++.dg/abi/key2.C 2016-11-27 16:57:37.0
+0100
+++ gcc/testsuite/g++.dg/abi/key2.C 2018-12-28 14:49:09.0 +0100
@@ -14,4 +14,4 @@ class f
} c;
inline void f::g() {}
int sub(void)
-{}
+{return 0;}
Committed as obvious on trunk and the gcc8 branch.
Dominique
v2 [PATCH] Fixes for PR68356, PR81210, and PR81693
New patch for taking into account the comments in https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01003.html 2018-12-29 Dominique d'Humieres PR tree-optimization/68356 PR target/81210 PR target/81693 * gcc.dg/torture/pr68264.c: Skip on darwin. * gcc.dg/torture/pr68037-1.c: Likewise. * gcc.dg/torture/pr68037-2.c: Likewise. * gcc.dg/torture/pr68037-3.c: Likewise. * gcc.dg/torture/pr25967-1.c: Likewise. * gcc.dg/torture/pr25967-2.c: Likewise. OK to commit to trunk and the gcc-8 branch? Dominique patch-68356b Description: Binary data
Re: [PATCH] PR fortran/81984 -- Placate the sanitizer
Hi Steve, The patch looks good to me (and works as expected). Thanks, Dominique
Re: [PATCH] PR fortran/81027 -- Issue error for assumed-shape array
Hi Steve,
The test gfortran.dg/pr81027.f90 succeeds without the patch. Would not it be
better to replace
{ dg-error "is not permitted in an" }
with something such as
{ dg-error "Assumed-shape array" }
?
Otherwise the patch works as expected.
Thank for the fix.
Dominique
Re: [PATCH] PR fortran/81509 and fortran/45513
Hi Steve, The 'call abort’ in the test gfortran.dg/pr81509_1.f90 should be replaced with ‘stop n’. Thanks for the patch. Dominique
Re: Implementation of F2018:18.4 C descriptors and ISO_Fortran_binding.h
Hi Paul, Your patch did not apply smoothly on my working tree: patching file gcc/configure Reversed (or previously applied) patch detected! Assume -R? [n] … patching file gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 Hunk #1 FAILED at 5. 1 out of 2 hunks FAILED -- saving rejects to file gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90.rej … patching file libgfortran/Makefile.am Hunk #3 FAILED at 780. Hunk #4 FAILED at 1019. 2 out of 4 hunks FAILED -- saving rejects to file libgfortran/Makefile.am.rej patching file libgfortran/Makefile.in Hunk #3 FAILED at 765. Hunk #4 FAILED at 1337. Hunk #5 FAILED at 1536. 3 out of 7 hunks FAILED -- saving rejects to file libgfortran/Makefile.in.rej … I ignored the failed hunks in libgfortran/Makefile.am and the corresponding ones in libgfortran/Makefile.in and applied manually the hunk #3. The I did not have any problem to do the update. Then the test gfortran.dg/ISO_Fortran_binding_1.c failed for the 32 bit mode: /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90:142:8: 142 | if (c_allocate (x, lower, upper) .ne. 0) stop 10 |1 Error: Type mismatch in argument 'lower' at (1); passed INTEGER(4) to INTEGER(8) Cheers, Dominique
Typos in [Committed] PR fortran/88138 -- can't initialize a derived type
Hi Steve, I think that in decl.c ‘derive’ should be ‘derived’ (twice) and there should be no ’s’ after the dg-error in pr88138.f90. Thanks for the fix. Dominique
Re: [PATCH] PR fortran 88116,88467 -- Catch array constructor errors
Hi Steve, The patch works as expected. Is "Can\’t " instead of "Can’t " really necessary? Thanks for the patch, Dominique
Re: [PING^3] Re: [PATCH 1/3] Support instrumenting returns of instrumented functions
Hi Andi, % gcc9 -S -pg -mfentry -minstrument-return=call -mrecord-return /opt/gcc/work/gcc/testsuite/gcc.target/i386/returninst1.c -m32 cc1: sorry, unimplemented: -mfentry isn't supported for 32-bit in combination with -fpic The tests should be protected. TIA Dominique
Re: [patch, libgfortran] PR88052 - Format contravening f2008 constraint C1002 permitted
Hi Jerry, > OK for trunk? Could you give me some time to post some comments in bugzilla? TIA Dominique
Re: [PATCH][GCC] Make DR_TARGET_ALIGNMENT compile time variable
Revision r266072 breaks bootstrap on darwin: In file included from ../../work/gcc/coretypes.h:430, from ../../work/gcc/tree-vect-data-refs.c:24: ../../work/gcc/poly-int.h: In instantiation of 'typename if_nonpoly::type maybe_lt(const Ca&, const poly_int_pod&) [with unsigned int N = 1; Ca = int; Cb = long long unsigned int; typename if_nonpoly::type = bool]': ../../work/gcc/tree-vect-data-refs.c:6338:13: required from here ../../work/gcc/poly-int.h:1384:12: error: comparison of integer expressions of different signedness: 'const int' and 'const long long unsigned int' [-Werror=sign-compare] 1384 | return a < b.coeffs[0]; | ~~^~~ cc1plus: all warnings being treated as errors TIA Dominique
Re: [committed 0/4] (Partial) OpenMP 5.0 support for GCC 9
Hi Jakub, Bootstrapping r265942 on darwin failed with In file included from /Applications/Xcode-6.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/stdio.h:490, from ../../../work/libgomp/affinity-fmt.c:28: ../../../work/libgomp/affinity-fmt.c: In function 'gomp_display_affinity': ../../../work/libgomp/affinity-fmt.c:369:17: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' -Werror=format=] 369 | sprintf (buf, "0x%x", (uintptr_t) handle); | ^~ ~~ | | | long unsigned int ../../../work/libgomp/affinity-fmt.c:369:21: note: format string is defined here 369 | sprintf (buf, "0x%x", (uintptr_t) handle); |~^ | | | unsigned int |%lx cc1: all warnings being treated as errors I have managed to bootstrap with the following hack: --- ../_clean/libgomp/affinity-fmt.c2018-11-08 19:03:37.0 +0100 +++ libgomp/affinity-fmt.c 2018-11-09 01:00:16.0 +0100 @@ -362,11 +362,11 @@ gomp_display_affinity (char *buffer, siz char buf[3 * (sizeof (handle) + sizeof (int)) + 4]; if (sizeof (handle) == sizeof (long)) - sprintf (buf, "0x%lx", (long) handle); + sprintf (buf, "0x%lx", (long) (uintptr_t) handle); else if (sizeof (handle) == sizeof (long long)) - sprintf (buf, "0x%llx", (long long) handle); + sprintf (buf, "0x%llx", (long long) (uintptr_t) handle); else - sprintf (buf, "0x%x", (int) handle); + sprintf (buf, "0x%x", (int) (uintptr_t) handle); gomp_display_num (buffer, size, , zero, right, sz, buf); break; } which is certainly wrong, but allowed me to bootstrap. TIA Dominique PS I can file a PR if necessary.
Re: [patch, fortran] Implement FINDLOC
> Le 22 oct. 2018 à 23:00, Thomas Koenig a écrit : > > Hi Dominique, > >> With your patch, compiling the following test >> program logtest3 >>implicit none >>logical :: x = .true. >>integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, & >> back=x) >> end program logtest3 >> gives an ICE > > I sometimes wonder where you get all these test cases from… This is a reduction of a James van Buskirk's test at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/GpaACNKn0Ds > > Anyway, the attached patch fixes this, It now gives the error 4 |integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, & |1 Error: transformational intrinsic 'findloc' at (1) is not permitted in an initialization expression However a similar test program logtest3 implicit none integer, parameter :: A1 = 2 logical, parameter :: L1 = transfer(A1,.FALSE.) integer, parameter :: I_FINDLOC_MASK(1) = findloc([1,1],1, & mask=[L1,.TRUE.]) print *, A1, L1, I_FINDLOC_MASK(1) end program logtest3 compiles and gives ' 2 F 2’ at run time. Also I see several transformational intrinsic accepted as initialization expressions. The following test program logtest3 implicit none ! ! ! *** Everything depends on this parameter ***! integer, parameter :: A1 = 2 logical :: L L = transfer(A1,L) call sub(L) end program logtest3 subroutine sub(x) implicit none logical x integer a(1) character(*), parameter :: strings(2) = ['.TRUE. ','.FALSE.'] a = findloc([1,1],1,mask=[x,.TRUE.]) write(*,'(a)') 'Value by FINDLOC(MASK): '// & trim(strings(a(1))) a = findloc([1,1],1,back=x) write(*,'(a)') 'Value by FINDLOC(BACK): '// & trim(strings(3-a(1))) end subroutine sub does not link: 8 |L = transfer(A1,L) | 1 Warning: Assigning value other than 0 or 1 to LOGICAL has undefined result at (1) Undefined symbols for architecture x86_64: "__gfortran_findloc0_i4", referenced from: _sub_ in ccnoLKfH.o "__gfortran_mfindloc0_i4", referenced from: _sub_ in ccnoLKfH.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Finally the line before the end of findloc_6.f90 should be if (findloc(ch,"CC ",dim=1,mask=false) /= 0) stop 23 TIA Dominique > plus the print *, instead > of test for return values, plus the whitespace issues mentioned > by Bernhard. Patch gzipped this time to let it go through to > gcc-patches. > > OK for trunk? > > Regards > > Thomas >
Re: [patch, fortran] Implement FINDLOC
Hi Thomas, With your patch, compiling the following test program logtest3 implicit none logical :: x = .true. integer, parameter :: I_FINDLOC_BACK(1) = findloc([1,1],1, & back=x) end program logtest3 gives an ICE gfc: internal compiler error: Segmentation fault: 11 signal terminated program f951 I see some kind of "infinite" recursion … frame #899971: 0x000100037e44 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_init_expr_arguments(e=0x00014c34bd80) at expr.c:2374 frame #899972: 0x000100037e24 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_conversion(e=0x00014c34bd80) frame #899973: 0x000100037e1d f951`gfc_check_init_expr(e=0x00014c34bd80) frame #899974: 0x000100037e44 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_init_expr_arguments(e=0x00014c34bc40) at expr.c:2374 frame #899975: 0x000100037e24 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_conversion(e=0x00014c34bc40) frame #899976: 0x000100037e1d f951`gfc_check_init_expr(e=0x00014c34bc40) frame #899977: 0x000100037e44 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_init_expr_arguments(e=0x00014c34bb00) at expr.c:2374 frame #899978: 0x000100037e24 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_conversion(e=0x00014c34bb00) frame #899979: 0x000100037e1d f951`gfc_check_init_expr(e=0x00014c34bb00) frame #899980: 0x000100037e44 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_init_expr_arguments(e=0x00014c34b9c0) at expr.c:2374 frame #899981: 0x000100037e24 f951`gfc_check_init_expr(gfc_expr*) [inlined] check_conversion(e=0x00014c34b9c0) frame #899982: 0x000100037e1d f951`gfc_check_init_expr(e=0x00014c34b9c0) Also in gfortran.dg/findloc_4.f90 should not the lines print *,findloc(a,value=1.5,dim=2,back=.true.) print *,findloc(a,value=1,dim=1,mask=lo) converted to tests? Thanks for working on the implementation of FINDLOC. Dominique
Re: [Patc, fortran] PR85603 - ICE with character array substring assignment
Reduced test
! { dg-do compile }
MODULE TN4
IMPLICIT NONE
PRIVATE
INTEGER,PARAMETER::SH4=KIND('a')
TYPE,PUBLIC::TOP
CHARACTER(:,KIND=SH4),ALLOCATABLE::ROR
CHARACTER(:,KIND=SH4),ALLOCATABLE::VI8
CONTAINS
PROCEDURE,NON_OVERRIDABLE::SB=>TPX
END TYPE TOP
CONTAINS
SUBROUTINE TPX(TP6,PP4,BA3)
CLASS(TOP),INTENT(INOUT)::TP6
INTEGER,INTENT(IN)::PP4
TYPE(TOP),INTENT(OUT)::BA3
BA3%ROR=TP6%ROR(PP4:)
BA3%VI8=TP6%ROR(PP4:)
TP6%ROR=TP6%ROR(:PP4-1)
TP6%VI8=TP6%ROR(:PP4-1)
END SUBROUTINE TPX
END MODULE TN4
! https://groups.google.com/forum/#!topic/comp.lang.fortran/nV3TlRlVKBc
TIA
Dominique
> Le 19 oct. 2018 à 23:39, Dominique d'Humières a écrit :
>
> Hi Paul,
>
> I get a regression with your patch:
>
> obfuscated_tn4.f90:300:0:
>
> 300 | TP6%ROR=TP6%ROR(:PP4-1)
> |
> internal compiler error: in gfc_trans_deferred_vars, at
> fortran/trans-decl.c:4754
>
>
> I’ll try to reduce the test.
>
> Dominique
>
Re: [Patc, fortran] PR85603 - ICE with character array substring assignment
Hi Paul, I get a regression with your patch: obfuscated_tn4.f90:300:0: 300 | TP6%ROR=TP6%ROR(:PP4-1) | internal compiler error: in gfc_trans_deferred_vars, at fortran/trans-decl.c:4754 I’ll try to reduce the test. Dominique
Re: [Patch, fortran] PR87566 - ICE with class(*) and select
Hi Paul, The ICEs for the following PRs 58906, a variant of 77385, 80260, and 82077, have been fixed between revision r264941 + patches and r265126 + same patches + this patch + patch for pr56386. Cheers, Dominique
Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul
> Le 14 oct. 2018 à 00:43, Tobias Burnus a écrit :
>
> Hi Dominique,
>
> Dominique d'Humières wrote:
>> UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
>> optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
>>
>> ! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+
>> __var_2_do\]" 1 "optimized" } }
>>
>> Shouldn’t -fdump-tree-original be -fdump-tree-optimized?
>
> As it is a front-end optimization (which is explicitly enabled),
> -fdump-tree-original should work (and avoids issues with further later
> optimizations).
>
> What do you get on your system? Seemingly something else than I do. Can you
> look for the gamma5 line in your dump?
>
> Tobias
Then
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "optimized" } }
should be
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "original" } }
isn’t it?
see https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg01721.html for non darwin
log.
Dominique
Re: [Patch, Fortran] PR87597 - fix off-by-one issue with inline matmul
Hi Tobias,
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O0 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O1 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O2 scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -O3 -g scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90 -Os scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
IMO this comes from
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
…
! { dg-final { scan-tree-dump-times "gamma5\[__var_1_do \\* 4 \\+ __var_2_do\]"
1 "optimized" } }
Shouldn’t -fdump-tree-original be -fdump-tree-optimized?
TIA
Dominique
Re: [Patch, fortran] PR87151 - allocating array of character
Hi Paul, Your patch works as expected. It also fixes the ICEs for the tests in pr80931 (and the test accidentally attached to pr83196). Thanks for the patch. Dominique
Re: [Patch, fortran] PR65677 - Incomplete assignment on deferred-length character variable
Hi Paul, First your patch has been committed with wrong entry: 65667 instead of 65677. Second, I suspect it is responsible of the following ICE: % gfc pr72755.f90 -fno-range-check pr72755.f90:1485:0: 1485 | this%buffer = transfer( c(start:iend), this%buffer ) | internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2257 and % gfc pr64125_db.f90 pr64125_db.f90:20:0: 20 | left%chars = transfer( right, left%chars ) | internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2257 for module test type t_string private character(len=:), allocatable :: chars end type t_string contains pure subroutine string_assign_from_array( left, right ) ! The target string type(t_string), intent(out) :: left ! The source string character, dimension(:), intent(in) :: right ! Copy memory allocate( character(len=size(right)) :: left%chars ) left%chars = transfer( right, left%chars ) end subroutine string_assign_from_array end module test Cheers, Dominique
Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs
> Is se->string_length guaranteed to be of type gfc_array_index_type_here? > If so, why? And if not, maybe a fold_convert is in order? I don’t know if this related, but if I build gfortran with the patches for PRs 70752 and 72709, 70149, and 65677 with --enable-checking=yes, compiling the test in pr82617 gives an ICE: pr82617.f90:68:0: 68 | items(i_item) = str(i0:i1-1) | internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in get_array_span, at fortran/trans.c:301 Cheers, Dominique
Re: [Patch, fortran] PR80477 - [OOP] Polymorphic function result generates memory leak
Hi! > great that you managed to solve this one! The patch looks very good to > me, but I'm afraid two details may be missing: > > 1) If the type has allocatable components, those need to be freed first. > … PR86481? Cheers Dominique
Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize
Hi Janus, > gfortran currently does short-circuiting, and after my patch for PR > 85599 warns about cases where this might remove an impure function > call (which potentially can change results). > > Now, this PR (57160) is about code which relies on the > short-circuiting behavior. Since short-circuiting is not guaranteed by > the standard, such code is invalid. Generating a warning or an error > at compile-time is a bit harder here, though, since there are multiple > variations of such a situation, e.g.: > * ASSOCIATED(p) .AND. p%T > * ALLOCATED(a) .AND. a%T > * i * … > Aren’t you confusing portability with validity? The above codes are indeed invalid without short-circuit evaluation, but I did not find anything in the standard saying such codes are invalid with short-circuit evaluation. > The suggestion in the PR was to do short-circuiting only with > optimization flags, but inhibit it with -O0, so that the faulty code > will run into a segfault (or runtime error) at least when > optimizations are disabled, and the problem can be identified. This PR has nothing to do with optimization and I think it is a very bad idea to (ab)use any optimization option. Please leave the default behavior (and test) as they are now. If you want non short-circuit evaluation, introduce an option for it. Note that the warning introduce for pr85599 should be disabled for non short-circuit evaluations. TIA Dominique
Re: [patch, fortran] Asynchronous I/O, take 3
> Le 15 juil. 2018 à 21:35, Rainer Orth a écrit > : > > Hi Jerry, > >> On 07/15/2018 11:46 AM, Rainer Orth wrote: >>> Hi Jerry, >>> Hmm, interesting. Which linux are you using? >>> >>> Fedora 27. >> >> Works for me. Fedora 28. Do not know for other OS's > > just tried Solaris 11/x86: works just as well. I could try Mac OS X > 10.7, but that build would take quite a while… Works on OSX. Dominique > > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions
> Le 12 juil. 2018 à 16:12, Janus Weil a écrit : > > Hi Dominique, > > thanks for the comments. > >>> after the dust of the heated discussion around this PR has settled a >>> bit, here is another attempt to implement at least some basic warnings >>> about compiler-dependent behavior concerning the short-circuiting of >>> logical expressions. … >> >> IMO your patch is missing the only point I agree with you on this issue, >> i.e., > > So you don't agree that it's a good idea to warn about non-portable code? Wel, as you might guess I don’t like warnings in general: too much false positives and missed targets (see recent bootstrap breakage). > >> the short-circuit evaluation and the related portability issues should be >> documented. > > I fully agree. Documentation never hurts. Do you have a suggestion > where this should go? There does not seem to be a particular chapter > in the manual that deals with portability across compilers (probably > because one usually assumes that sticking to the Fortran standard is > sufficient for achieving portability). The best match might be the > chapter on compiler characteristics: > > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/Compiler-Characteristics.html Why not? Anyway if your patch is accepted, the doc for -Wextra has to be updated accordingly. > >> With your patch what happens if check() is an external function? > > Haven't tried, but I guess you would get a warning, since the compiler > cannot tell whether 'check' is pure (unless you have an explicit > interface block that contains the PURE attribute). Much ado about nothing? > >> Your patch is focusing on pr85599 and ignore pr57160. > > Well, yes. PR 57160 is somewhat related, but orthogonal. It concerns > essentially the same issue, namely short-circuiting with logical > expressions, but proposes a different solution (making > short-circuiting depend on the -ffrontend-optimize flag). I wouldn't > say that's unreasonable, but independent of that I might still want to > know that my code is not portable, thus a warning makes sense in any > case (IMHO). > > >> What to do with >> >> if(x>0 .and. sort(x)<10.0*log(x)) … >> >> which is not portable to compilers computing the two expressions? > > That's one of the typical cases that the patch should be able to > handle. If 'sort' is impure, this should trigger a warning with the > patch. If it is pure, it doesn't matter whether the rhs of the .and. > operator is executed (since there are no side effects). Or am I > missing something? I meant ‘sqrt’ (changed behind my back by the stupid spell-checker). > > Cheers, > Janus > > > 2018-07-12 13:16 GMT+02:00 Dominique d'Humières : >> Hi Janus, >> >>> after the dust of the heated discussion around this PR has settled a >>> bit, here is another attempt to implement at least some basic warnings >>> about compiler-dependent behavior concerning the short-circuiting of >>> logical expressions. … >> >> IMO your patch is missing the only point I agree with you on this issue, >> i.e., >> the short-circuit evaluation and the related portability issues should be >> documented. >> >> With your patch what happens if check() is an external function? >> >> Your patch is focusing on pr85599 and ignore pr57160. >> >> What to do with >> >> if(x>0 .and. sort(x)<10.0*log(x)) … >> >> which is not portable to compilers computing the two expressions? >> >> Cheers, >> >> Dominique >>
Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions
Hi Janus, > after the dust of the heated discussion around this PR has settled a > bit, here is another attempt to implement at least some basic warnings > about compiler-dependent behavior concerning the short-circuiting of > logical expressions. … IMO your patch is missing the only point I agree with you on this issue, i.e., the short-circuit evaluation and the related portability issues should be documented. With your patch what happens if check() is an external function? Your patch is focusing on pr85599 and ignore pr57160. What to do with if(x>0 .and. sort(x)<10.0*log(x)) … which is not portable to compilers computing the two expressions? Cheers, Dominique
Re: [patch, fortran] Asynchronous I/O, take 3
I have done a full regression testing with the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg4.html + Rainer’s patch at https://gcc.gnu.org/ml/fortran/2018-07/msg7.html I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I think there is a spurious STOP in libgomp.fortran/async_io_1.f90 and the last STOP 1 should be STOP 7, as in: --- libgomp/testsuite/libgomp.fortran/async_io_1.f902018-07-03 12:26:41.0 +0200 +++ gcc/testsuite/gfortran.dg/asynchronous_6.f902018-07-05 12:57:35.0 +0200 @@ -21,7 +21,6 @@ program main write (10,'(A)', asynchronous=yes) 'asdf' write (10,*, asynchronous=yes) cc close (10) - stop open (20, file='a.dat', asynchronous=yes) read (20, *, asynchronous=yes) i, j read (20, *, asynchronous=yes) k, l @@ -42,6 +41,6 @@ program main open(20, file='c.dat', asynchronous=yes) read(20, *, asynchronous=yes) res wait (20) - if (any(res /= is)) stop 1 + if (any(res /= is)) stop 7 close (20,status="delete") end program Thanks for the hard work! Dominique
Re: [PATCH] Fix PR86321
The patch fixes PR86321 without regression. Thanks, Dominique
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
>>> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
> This seems to be a bug in the test suite. It tries to find out whether an id
> is pending that is never initialized.
>
>>> FAIL: gfortran.dg/f2003_io_1.f03 -O*
>
> And another bug in the test suite. This time the wait after the read is
> missing.
Do you have any fix for them ?
> asynchronous_7.f90 is a test for an error, but dg-shouldfail is not working
> in libgomp. Dominique is looking into this.
I have this in my working tree
! { dg-do run }
program main
integer :: i
open (10,file="tst.dat")
write (10,'(A4)') 'asdf'
close(10)
i = 234
open(10,file="tst.dat", asynchronous="yes")
read (10,'(I4)',asynchronous="yes") i
wait(10)
end program main
! { dg-output "Fortran runtime error: Bad value during integer read" }
! { dg-final { remote_file build delete "tst.dat" } }
>
>> Besides, I see
>> +FAIL: libgomp.fortran/asynchronous_6.f90 -O1 execution test
>> STOP 2
>> 32-bit i386 only.
>
> I have trouble replicating this bug even with -m32. Could you get some more
> debugging info for the test on your machine?
I have copied the asynchronous tests from libgomp.fortran to gfortran.dg and
ran both
make -k check-gfortran RUNTESTFLAGS="dg.exp=asynchronous_*
--target_board=unix'{-m32,-m64}’"
in gcc and
make -k check RUNTESTFLAGS="fortran.exp=asynchronous_*.f90
--target_board=unix'{-m32,-m64}’"
in x86_64-apple-darwin17.6.0/libgomp/testsuite 10 times and I see ~10 failures
in each cases (mostly STOP 2, but also STOP 4). I some cases I had to kill the
process.
Note that these tests should probably protected by something such as
! { dg-require-effective-target pthread }
or
! { dg-require-effective-target tls }
Dominique
Re: [PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error
Committed as r261387. Thanks, Dominique > Le 10 juin 2018 à 14:25, Thomas Koenig a écrit : > > Hi Dominique, > >> Is the following patch OK for the trunk? >> TIA >> Dominique >> 2018-06-10 Dominique d'Humieres >> PR fortran/79854 >> * trans-const.c: Remove include "diagnostic-core.h" >> (gfc_conv_constant_to_tree): Replace fatal_error with >> gcc_unreachable. > > OK. Thanks! > > Thomas
[PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error
Is the following patch OK for the trunk? TIA Dominique 2018-06-10 Dominique d'Humieres PR fortran/79854 * trans-const.c: Remove include "diagnostic-core.h" (gfc_conv_constant_to_tree): Replace fatal_error with gcc_unreachable. --- ../_clean/gcc/fortran/trans-const.c 2018-02-23 15:17:14.0 +0100 +++ gcc/fortran/trans-const.c 2018-06-07 15:49:38.0 +0200 @@ -26,7 +26,6 @@ along with GCC; see the file COPYING3. #include "tree.h" #include "gfortran.h" #include "trans.h" -#include "diagnostic-core.h" /* For fatal_error. */ #include "fold-const.h" #include "stor-layout.h" #include "realmpfr.h" @@ -368,9 +367,7 @@ gfc_conv_constant_to_tree (gfc_expr * ex expr->representation.string); default: - fatal_error (input_location, - "gfc_conv_constant_to_tree(): invalid type: %s", - gfc_typename (>ts)); + gcc_unreachable (); } }
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
Hi Nicolas,
I have applied your patch on top of revision r261130 on x86_64-apple-darwin17
(SSD with APFS file system).
The only remaining failure on my own tests is for the test (pr35840)
write(10,*, asynchronous="Y"//"E"//trim("S "))
end
giving at run time
At line 1 of file pr35840.f90 (unit = 10, file = 'fort.10')
Fortran runtime error: ASYNCHRONOUS transfer without ASYHCRONOUS='YES' in OPEN
I also see two regressions
FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
only with -m32 and -O1 (STOP 5), and
FAIL: gfortran.dg/f2003_io_1.f03 -O*
with both -m32 and -m64 (STOP 1).
The is also typos for the added tests
s/libgfomp/libgomp/
Why do the tests start at asynchronous_6.f90?
"Treat asynchronous variables the same as volatile, for now." could probably
simplified as
"Treat asynchronous variables as volatile, for now."
I also wonder if
+wrap_scalar_transfer (dtp, BT_INTEGER, p, kind, kind, 1);
is correct without a cast to size_t for the last two arguments (and for the
last argument in other instances). Note that I am C challenged, so forgive the
question if it is stupid.
Thanks for the nice work.
Dominique
