(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
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
Hi Steve,
Patch missing?
TIA
Dominique
> 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
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
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:
Hi Paul,
s:PR fortran/90948:PR fortran/90498:g
TIA
Dominique
> 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
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
Hi Steve,
> Ping.
AFAICT this has been committed as revision r270495.
Cheers,
Dominique
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
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
Done as revision r270843.
Dominique
> Le 3 mai 2019 à 11:06, Martin Liška a écrit :
>
> Feel free to install the patch please.
>
> Martin
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:
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
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
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
> 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
>>
>
&
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, Do
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)
> 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
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
+++
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
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.
---
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
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) ::
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 =
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)
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
Committed as obvious at revision r270115:
2019-04-03 Dominique d'Humieres
PR fortran/89375
* expr.c (comp_pointer): Remove redundant condition.
Dominique
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
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
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!
Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html
TIA
Dominique
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.)
|
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
> 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
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
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
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
New test committed as r269190.
Dominique
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
Committed as revision r269187.
Dominique
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)
New test committed as obvious at revision r268656.
Dominique
Committed as revision r268480 after approval by Jerry on IRC.
Cheers,
Dominique
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
Hi Paul,
Are you sure about the && in
+ && ref->u.c.component->ts.type != BT_DERIVED))
should not it be ||?
TIA
Dominique
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
> 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
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
+++
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
+++
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
The test gcc.dg/torture/fp-int-convert-timode-3.c fails on darwin: the results
are
-0x1p+127
-0x1p+127
TIA
Dominique
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
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)
@@
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
>>
>>
>
>
Hi Manfred,
> could someone please check and commit?
Tested and committed as obvious at r268125.
Thanks for the patch.
Dominique
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.
>>
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
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
> Committed on trunk as obvious
Committed as revision r267599. Patch attached.
Dominique
patch-plug
Description: Binary data
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
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
Hi Thomas,
Your patch LGTM (and works as expected).
Thanks for the quick fix and happy new year,
Dominique
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(:),
Hi Thomas,
There are some duplicate STOPs (6 and 10) in the test
gfortran.dg/optional_absent_4.f90.
Thanks for the patch,
Dominique
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]
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.
*
Hi Steve,
The patch looks good to me (and works as expected).
Thanks,
Dominique
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
Hi Steve,
The 'call abort’ in the test gfortran.dg/pr81509_1.f90 should be replaced with
‘stop n’.
Thanks for the patch.
Dominique
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
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
Hi Steve,
The patch works as expected.
Is "Can\’t " instead of "Can’t " really necessary?
Thanks for the patch,
Dominique
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
Hi Jerry,
> OK for trunk?
Could you give me some time to post some comments in bugzilla?
TIA
Dominique
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
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:
> 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
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
pic/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 compil
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
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
> 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
>>
>
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:
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
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:
> 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
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
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
> 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
>>
>> 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.
> o
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
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 patch fixes PR86321 without regression.
Thanks,
Dominique
>>> 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
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
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
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
1 - 100 of 415 matches
Mail list logo
