Wouldn't it be better to remove the target selector and instead add:
/* { dg-require-effective-target pie } */
...
This allows the tests to be run on Darwin and fail because the code generated
does not
match the scan-assembler:
FAIL: gcc.target/i386/iinline-attr-2.c scan-assembler p2align
...
I have tested it independently of everything else,
and would like permission to commit it to mainline.
...
This caused https://gcc.gnu.org/ml/gcc-bugs/2015-05/msg00748.html
Dominique
(Not asking for review just yet, JFYI.)
This is not a review! but the patch fixes PR65742.
Dominique
Dear Evangelos,
I have posted at https://gcc.gnu.org/bugzilla/attachment.cgi?id=35240
a reformatted patch along the Mikael's comment. I have also fixed
a failure in the test (parentheses have to be escaped).
The patch fixes not only pr59016, but also
pr50259 (there are probably random ICEs?)
So, what do you think about this?
I am curious about what performance gain results from this?
I can see saving a library call to our runtime libraries.
Do you have some timing results?
Jerry
IMO the inlining of MATMUL should be restricted to small matrices (less than
4x4, 9x9
or 16x16
Do you see Fatal Error: Error count reached limit of ... in your logs?
If yes, what is the value.
Compiling the code with -fmax-errors=51, I get
Fatal Error: Error count reached limit of 51.
This fatal error disappears with -fmax-errors=52, well below the limit in the
test:
-fmax-errors=100.
please find attached a fix for the recently introduced regression when
allocating arrays with an intrinsic function for source=. ...
I confirm that the patch fixes pr65548 without regression.
Thanks,
Dominique
Steve,
AFAICT your test succeeds without your patch and does not test that the ICE
reported by FX is gone (indeed it is with your patch).
TIA
Dominique
Dear Tobias,
The test gfortran.dg/coarray/coindexed_3.f90 compiles without error,
see https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg02446.html.
TIA
Dominique
Dear Jerry,
IMO the patch is in the obvious range, but needs to document the extension and
may be
a test case.
Cheers,
Dominique
Dear Andre,
If I am not mistaken, this patch make the following test (pr57305, second
attachment):
subroutine add_element_poly(a,e)
use iso_c_binding
class(*),allocatable,intent(inout),target :: a(:)
class(*),intent(in),target :: e
class(*),allocatable,target ::
Dear Tobias,
Revision r221550 break bootstrap on platforms with recent makeinfo (mine is
5.2):
see https://gcc.gnu.org/ml/gcc-regression/2015-03/. The error is
../../work/gcc/fortran/gfortran.texi:3850: @code missing close brace
../../work/gcc/fortran/gfortran.texi:3851: misplaced }
Dear Andre,
I have bootstrapped and regtested successfully r221474 with your set of
patches. I am seeing some more fixes, but also some new ICEs and segfaults
(some of them being regressions):
(1) The patches fix pr63230.
(2) The test in pr51550 compiles, but segfaults at run time.
(3) The
Hi Eric,
Following this commit (r221088) testing dump-ada-spec-3.C with
make -k check-g++ RUNTESTFLAGS=dg.exp=other/dump-ada-spec-3.C
generates a lot of *.ads files in the gcc/testsuite/g++ directory
which are not cleaned up after completion.
Any idea about how to do the cleaning?
TIA
Dear Mikael,
I have regstrapped revision r220715 with your patch. It fixes the tests in
PR60898 without regression.
[*] I have a few failing testcases (also without the patch), namely the
following; does this ring a bell ?
FAIL: gfortran.dg/erf_3.F90
FAIL: gfortran.dg/fmt_g0_7.f08
FAIL:
Tom,
After these changes I have the following regressions on
x86_64-apple-darwin1[04]*:
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite number of SCoPs:
0 1
I can prepare and
Dear Mikael,
I have the patch in my working tree since May 2014. It works as advertised
without
any visible side effect.
Thanks,
Dominique
Dear Mikael,
Even if
use m, only: A = X
use m, only: A = X
is valid, it does not make sense to use it and it is probably a typo.
Should not gfortran emit a warning, at least with -Wall?
Cheers,
Dominique
Dear Paul,
I have tested your patch at
https://gcc.gnu.org/ml/fortran/2015-01/txtwnaoa1115V.txt
(the latest version) and I found that the test type_to_class_3.f03 is
miscompiled
(FAIL) with -flto -O0 -m64 (this does not happens with -flto -O0 -m32 or with
-Ox and
x!=0).
In addition, while the
Hi Jeff,
The tests gcc.target/i386/pr15184-[12].c fail on darwin. Grepping for movb, I
get
movb%al, (%edx)
movb%al, 1(%edx)
movb%al, 2(%edx)
movb%al, 3(%edx)
TIA
Dominique
This patch worked for me. Ok for mainline now? (r220158)
This causes 340 new tests on darwin with -m32, 255 of them failing when
executes,
see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.
Are the tests with '-DABI_NUM=*' supposed to work on darwin?
If yes, I'll open a PR; if
... FAIL: gfortran.dg/open_new_segv.f90 -O0 execution test
This is fixed with something such as
--- ../_clean/gcc/testsuite/gfortran.dg/open_new_segv.f90 2015-01-25
00:37:43.0 +0100
+++ gcc/testsuite/gfortran.dg/open_new_segv.f90 2015-01-25 10:31:40.0
+0100
@@ -1,4
Hi Janus,
Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
looks very similar to the Mikael's one for pr58023 at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
with retval replaved with success.
Was it intended?
Cheers,
Dominique
... Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. ...
Nevertheless the commit breaks bootstrap on darwin:
...
libtool: link: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
Happy New Year to all.
The test gfortran.dg/coarray/codimension_2.f90 fails on x86_64-apple-darwin14
with -m32
(see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00185.html). The error is
gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/codimension_2.f90
OK for trunk? What about the other open branches?
The patch looks good. In the test temporary array should be
replaced with array temporary.
Thanks for the patch and Merry Christmas,
Dominique
I think I've fixed them now though, and am committing the attached
patch to trunk.
This commit (or a friend of it) breaks bootstrap on darwin
duplicate symbol std::__cxx11::time_getchar, std::istreambuf_iteratorchar,
std::char_traitschar ::do_get(std::istreambuf_iteratorchar,
Here it is. Committed as r218662 to get things going again.
The same change should be done for libitm and libatomic.
TIA
Dominique
Martin,
Your test g++.dg/ipa/pr64146.C fails on darwin:
grep bind pr64146.C.051i.icf
returns nothing, so the first scan fails, while the second one succeeds.
Dominique
this patch is ready for commit now. Please apply. There have been no
objections
against doing dg-do compile only, since my last post in August.
Since I am stubborn, I have made the test 'dg-do run' and committed the patch
as revision r218422.
Thanks for the patch,
Dominique
...
Can you please test it on Darwin (or whatever other target has similar
issues with bootstrapping libcc1)?
2014-12-05 Jakub Jelinek ja...@redhat.com
...
The patch does not work for x86_64-apple-darwin14.0.0. However the following
patch does:
--- ../_clean/Makefile.in 2014-11-26
As I've tried to explain, that is IMHO wrong though.
If what you are after is the -B stuff too, then perhaps:
...
Sorry but it does not work:
true DO=all multi-do # make
make[4]: Leaving directory '/opt/gcc/build_w/libbacktrace'
make[3]: Leaving directory '/opt/gcc/build_w/libbacktrace'
Normally, with -fPIE/-fpie, GCC accesses globals that are extern to the
module using the GOT. This is two instructions, one to get the address
of the global from the GOT and the other to get the value. If it turns
out that the global gets defined in the executable at link-time, it still
Tobias Burnus wrote:
Actually, I wonder whether that can lead to printing an error message
multiple times.
This already occurs, see pr44978.
Dominique
Seems removing that makes the configure.ac change unneeded.
Bootstrapped/regtested on x86_64-linux and i686-linux (libcc1
is built after compare, by stage3 compiler), and built
with --disable-bootstrap on i686-linux (libcc1 is built by
the system compiler in that case). Ok for trunk?
This patch has now been committed.
It breaks bootstap on x86_64-apple-darwin14:
...
make[3]: Entering directory `/opt/gcc/p_build/libcc1'
make all-am
make[4]: Entering directory `/opt/gcc/p_build/libcc1'
make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by
Patch:
--- ../_clean/gcc/testsuite/gfortran.dg/implicit_4.f90 2014-10-07
00:21:56.0 +0200
+++ gcc/testsuite/gfortran.dg/implicit_4.f902014-10-07 19:09:45.0
+0200
@@ -6,7 +6,7 @@ END
SUBROUTINE a
IMPLICIT REAL(b-j)
-implicit none ! { dg-error Type IMPLICIT NONE
testcase in PR35545 shows case where profile feedback infrastructure ...
The test g++.dg/tree-prof/pr35545.C yields
UNRESOLVED: g++.dg/tree-prof/pr35545.C scan-ipa-dump-not optimized
OBJ_TYPE_REF
The following patch
--- ../_clean/gcc/testsuite/g++.dg/tree-prof/pr35545.C 2014-09-27
The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed
with the following patch:
--- ../_clean/gcc/testsuite/gfortran.dg/coarray_collectives_9.f90
2014-09-25 12:14:05.0 +0200
+++ gcc/testsuite/gfortran.dg/coarray_collectives_9.f90 2014-09-27
13:03:41.0 +0200
The new tests fail on darwin:
/opt/gcc/work/gcc/testsuite/gcc.target/i386/nop-mcount.c:1:0: error:
-mnop-mcount is not implemented for -fPIC
and gcc.target/i386/record-mcount.c fails because mcount_loc is not found in
the assembly.
TIA
Dominique
AFAICT the lines 11200-11222 in gcc/fortran/resolve.c are a copy of
the lines 11176-11198. The following patch removes the duplicated
lines. OK for the trunk?
Dominique
--- ../_clean/gcc/fortran/resolve.c 2014-09-20 13:56:57.0 +0200
+++ gcc/fortran/resolve.c 2014-09-20
On darwin I get
FAIL: gcc.target/i386/fentry-override.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry-override.c scan-assembler-not __fentry__
FAIL: gcc.target/i386/fentry.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry.c scan-assembler __fentry__
with -m32. The
Perhaps it would be safer simply to revert that hunk of the original patch
unless/until (1) and (2) above are addressed?
Given that the original patch addresses 'only' a missed-optimization
(and causes ice-on-valid), it makes sense to me.
(1) Iain already asked the questions more than two
On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers jos...@codesourcery.com wrote:
gcc/c-family:
2014-09-05 Joseph Myers jos...@codesourcery.com
* c-cppbuiltin.c (c_cpp_builtins): Also define
__LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
__LIBGCC_EH_FRAME_SECTION_NAME__,
...
I believe the above hunk in r214954 ...
... broke the build for the
following configurations in contrib/config-list.mk: ...
See pr63188 for darwin. The same patch should probably
fix the problem for hppa64-hpux* too.
Dominique
I've committed the patch now.
It (r214840) breaks bootstrap on darwin:
...
/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/bin/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/lib/ -isystem
/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/include
does this fix it?
The answer after a quick update is yes, further testing scheduled for
tonight.
Thanks,
Dominique
This patch fixes pr44735 and pr60593. Otherwise I have regstrapped the
three patches without regression.
Thanks,
Dominique
Makes sense, I've attached new patch (retested as usual).
Well, you probably did not test with -m32:
Running target unix/-m32
FAIL: c-c++-common/asan/pr62089.c -O0 output pattern test, is
=
FAIL: c-c++-common/asan/pr62089.c
So the negative version is -Wno-use-no-only? That sounds weird.
What about -Wuse-without-only?
I can also confirm that the test succeeds without the ' ! { dg-bogus has no
ONLY qualifier }'.
Dominique
As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
the testcase should check that the code generated is actually working,
not just that the ICE disappeared. ...
thus I think the test should be run, i.e., '! { dg-do compile }' should
be replaced with '! { dg-do run }' (I
the testcase should check that the code generated is actually working,
not just that the ICE disappeared.
I agree. Note that there is a test in the comment 3 of PR60255 that
can be used to check the run time behavior (and possibly check the
vtab issue).
Dominique
My knowledge of unlimited polymorphic types is limited, but I think that
this is not correct.
My knowledge of unlimited polymorphic types is even more limited,
then I cannot comment about the correctness of the patch. However
The new length of the string has to be stored somewhere. If you
Here is a failing testcase.
I was about to post the same test. The test fails with two counts:
(1) len(P) == 80,
(2) deallocate(P) fails with
a.out(882,0x7fff75e1d310) malloc: *** error for object 0x7fc801c04978:
incorrect checksum for freed object - object was probably modified after being
This patch replaces some reference members with pointers, ...
...
Tested x86_64-linux, committed to trunk.
This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/):
...
libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
LAST_UPDATED: Updated Sat Aug 2 10:33:58 CEST 2014 to revision 213515.
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin13.3.0
=== g++
Wong list!-(
Sorry,
Dominique
I've checked in a patch to save the _M_n state.
If it is r212496, did you test it?
It breaks many tests (see
https://gcc.gnu.org/ml/gcc-regression/2014-07/msg00213.html)
/opt/gcc/work/libstdc++-v3/include/ext/random.tcc: In function
'std::basic_ostream_CharT, _Traits
The test gfortran.dg/coarray_atomic_4.f90 fails in 32 bit mode:
/opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_atomic_4.f90:40.32:
call atomic_fetch_and(caf, 22_16, var, stat=stat)
1
Error: Integer kind 16 at (1) not available
Dominique
Hi Roman,
Thanks for the quick answer.
Please report back if it fixes the problem.
I have not yet done a full regtest, but a manual testing suggest that
the patch fixes the problem.
Dominique
I have regtested graphite.exp for gcc/g++/gfortran/libgomp without
regression. So your patch seems a safe fix.
Dominique
On x86_64-apple-darwin13, the test gcc.dg/graphite/isl-codegen-loop-dumping.c
gives an ICE with -m32 after r212455. The backtrace is
* thread #1: tid = 0xdac306, 0x000100523c52 cc1`fold_binary_loc(loc=0,
code=MINUS_EXPR, type=0x, op0=0x000142c09bd0,
This probably caused
/opt/gcc/work/libgomp/testsuite/libgomp.fortran/pr34020.f90:16.24:
call atomic_add(lhs, rhs)
1
Error: ATOM argument at (1) to intrinsic function atomic_add shall be an
integer of ATOMIC_INT_KIND
Dominique
Here is a preprocessor patch to make error messages show C++11
and other relevant C++ language instead of C99.
Built and tested on x86_64-linux.
This caused
FAIL: gcc.dg/cpp/macsyntx.c (test for excess errors)
FAIL: gcc.dg/cpp/macsyntx.c (test for excess errors)
FAIL: gcc.dg/cpp/macsyntx.c
Ok.
:-) I usually just expect people to check in such minor stuff once the
discussion dies down
and all the good feedback is incorporated.
Thanks for the tip. I am still learning the rules.
Cheers,
Dominique
The patch fixes the last issue with PR 61225.
Could it be reviewed?
TIA
Dominique
FWIW, x86_64-darwin *passes* the test-cases you added with the patch series.
gcc.target/i386/sibcall-1.c fails in 32 bit mode:
FAIL: gcc.target/i386/sibcall-1.c scan-assembler-not mov
Cheers,
Dominique
I just checked. It doesn't work on hppa64-hp-hpux11.11 due to following
statement:
.type myBindC, @function
So can we settle for
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++
As mentioned before, I would prefer that you change hppa*-*-hpux* to
hppa*-*-*.
Done in my tree so I won't forget. Now someone has to approve the patch!
Dominique
...
diff --git gcc/testsuite/c-c++-common/pr60226.c
gcc/testsuite/c-c++-common/pr60226.c
...
The test fails on x86_64-apple-darwin13 with
FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/c-c++-common/pr60226.c:6:7: error:
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
I am now trying to do the back port to 4.9 and I got two failures: ...
Actually I did not applied the right patch, with it the testsuite pass without
regression. Still OK for 4.9.1?
TIA
Dominique
On condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
Dave,
I guess if \[ \t\]_*myBindC worked on hppa*-*-linux*, then it would
probably work on hpux and the target condition could be removed.
Does this mean that the following patch will succeed on hppa*-*-*
without/with -flto?
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
Dear Paul,
OK for trunk.
Thanks for the review. Committed as r212330.
Dominique
On hppa, the ,%r2 uniquely identifies the call. The test passes
with -flto.
Then is the following patch OK for hppa*-*-*?
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-07-05
22:20:49.0 +0200
@@ -16,7 +16,7 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final {
I'm fixing that with the following (will commit as obvious).
Marek,
With your patch g++.dg/ipa/imm-devirt-2.C sitll fails in 32 bit mode
because the mangling is C::_ZThn16_N1C3fooEi. This is fixed by something
such as
--- ../_clean/gcc/testsuite/g++.dg/ipa/imm-devirt-2.C 2014-07-05
Is the following patch OK for trunk?
2014-07-05 Dominique d'Humieres domi...@lps.ens.fr
PR testsuite/61453
* gfortran.dg/gfortran.dg/bind_c_array_params_2.f90:
Adjust regexp for more targets.
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
On Mon, 05 May 2014, I have posted
https://gcc.gnu.org/ml/fortran/2014-05/msg00012.html.
On IRC Tobias Burnus remarked that the *.mod file in
gfortran.dg/vect/fast-math-real8-pr40801.f90
should be cleaned automatically. This is not done because the cleaning is done
in gfortran-dg-runtest and
myBindC,%r2 will work on hppa*-*-*. I don't believe preceding stuff
is needed on hppa.
Sorry, the relation with -flto has been lost in my repost of this patch.
Without something before 'myBindC', the symbol appears twice when compiled
with -flto, once in the assembly itself and once in the
Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
the addition of '-g -flto'. Is it worth pushing in this direction?
Cheers,
Dominique
Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
TIA
Dominique
FAIL: gfortran.dg/actual_array_constructor_1.f90 -g -flto (internal compiler
error)
FAIL: gfortran.dg/alloc_comp_assign_6.f90 -g -flto (internal compiler error)
FAIL:
The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
/opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
definitions not supported in Mach-O; ignored
I think they should be protected by
/* { dg-require-alias } */
Dominique
The following change in predicates.md seems to be a bit premature.
There is still the point about Darwin's PIC issue for unspec-gotpcrel.
The change is indeed incompatible with the patch in pr61387 comment 9.
And without it the failures are back!-(
Kai, what is wrong with Iain's patch in
Dear Paul,
Late thanks for the review, the patch has been committed to trunk at r211405.
OK for trunk and, I would suggest 4.9.
I am now trying to do the back port to 4.9 and I got two failures:
FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O* scan-tree-dump-times original
builtin_free 18
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin13.2.0/libstdc++-v3/src/.libs
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
I'll try your full patch later (currently bootstrapping r211698).
Thanks,
Dominique
I have bootstrapped r211707 with the full patch (among others!).
It does not. So the above is IMHO very likely completely unrelated,
perhaps Darwin specific, issue.
More likely related to the fact that I only resumed bootstrap after the change
tree t = NULL_TREE; and an update from r211700 to
How does this affect pr60732?
Dominique
(I am not RTL reviewer, so I can't approve the patch).
Is https://gcc.gnu.org/ml/gcc-regression/2014-06/ accepatble?
Dominique
Yes, these are bootstraps with non-default configurations.
Core2 is the default for darwin and bootstrap is also broken for it
without the patch.
Dominique
This explicitly tests that no bogus error message is issued
for a use statement that has an only qualifier ?
I don't see the need for '! { dg-bogus has no ONLY qualifier }'.
AFAICT there is no warning emitted for this line (unless you add -Wall)
and if some day it happens that an error/warning
This patch fixes PR61446. ...
Confirmed, it also allows to bootstrap Core* targets.
Could it be reviewed and committed ASAP?
TIA
Dominique
Dear Paul,
This was a slip up on my part. The fix is obvious - OK for trunk and 4.9?
The patch fixes the ICE. Any progress about the double temporary?
[Book15] f90/bug% gfc pr61406.f90 -Warray-temporaries
pr61406.f90:6.18:
associate (n = [cos(theta), sin(theta)])
1
Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html.
TIA
Dominique
Ok for trunk. Thanks!
Please don't rush! The behavior of -fno-signed-zeros -fno-trapping-math
implying associative math has been changed (as in reverted) between r165758
(implied associative math) and r165930 (lost associative math). AFAICT
it could be due to 165823. Investigating! I am also
I think it is really weird if a coding style warning is included in -Wall.
I fully agree. In top of that the patch looks like a blind enforcement of this
coding style.
What is the rationale of
+ SUBROUTINE S2
+ USE foo, ONLY: bar ! { dg-bogus has no ONLY qualifier }
+ END SUBROUTINE
?
Hi Joost,
Why do you want -fno-math-errno to be the default for gfortran?
AFAICT such default is not documented and the flag works
(checked on your test gfortran.dg/errnocheck_1.f90).
For -fassociative-math, the manual says
For Fortran the option is automatically enabled when both
I resend patch within new thread. ...
This patch fixes pr61377. Could it be committed ASAP?
TIA,
Dominique
Probably, alpha is not the only one that fails this assumption.
Indeed! see the thread starting at
https://gcc.gnu.org/ml/fortran/2014-05/msg00127.html
Could you test the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0
1 - 100 of 360 matches
Mail list logo
