> 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 p2alig
> ...
> 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?)
pr56
> > 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 1
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.
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
> 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
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 :: tmp(:
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 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 }
../../work/g
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 origi
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
Domini
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 an
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 +1
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/
-B
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
/opt/gcc/work/gcc/testsuite/gfort
> 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_get > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, tm*, c
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
> Here it is. Committed as r218662 to get things going again.
The same change should be done for libitm and libatomic.
TIA
Dominique
> 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'
ma
> ...
> Can you please test it on Darwin (or whatever other target has similar
> issues with bootstrapping libcc1)?
>
> 2014-12-05 Jakub Jelinek
> ...
The patch does not work for x86_64-apple-darwin14.0.0. However the following
patch does:
--- ../_clean/Makefile.in 2014-11-26 23:09:14.0
> 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
> 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
`libcc1.la'
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 stat
> 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
15:01:
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
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
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 14:01:42
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 error
> > 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 tha
...
> 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
On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers wrote:
>
> gcc/c-family:
> 2014-09-05 Joseph Myers
>
> * c-cppbuiltin.c (c_cpp_builtins): Also define
> __LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
> __LIBGCC_EH_FRAME_SECTION_NAME__, __LIBGCC_JCR_SECTION_NAME__,
> __LIB
> does this fix it?
The answer after a quick update is yes, further testing scheduled for
tonight.
Thanks,
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
This patch fixes pr44735 and pr60593. Otherwise I have regstrapped the
three patches without regression.
Thanks,
Dominique
> 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
> 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 -
> 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
f
> 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
> 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
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 ha
> 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++
-L/
Wong list!-(
Sorry,
Dominique
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++ tests
> 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>&
__gnu_cxx::operator<
I have regtested graphite.exp for gcc/g++/gfortran/libgomp without
regression. So your patch seems a safe fix.
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
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
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
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,
op1=0x000142c1b048
> 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
> 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
The patch fixes the last issue with PR 61225.
Could it be reviewed?
TIA
Dominique
> 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
> ...
> 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: alig
> 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
> 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
+++ gcc/testsuite/gfortran.dg/bind_c_ar
Dear Paul,
> OK for trunk.
Thanks for the review. Committed as r212330.
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
> On condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
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
> 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
23:22:5
> 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 {
> "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
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 not
Is the following patch OK for trunk?
2014-07-05 Dominique d'Humieres
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
2014-05-24 16:17:53.
> 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
> 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
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: gfortran.dg/allo
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 com
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 t
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
> 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
-B/opt/gcc/build_w/prev-x86
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
How does this affect pr60732?
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
> (I am not RTL reviewer, so I can't approve the patch).
Is https://gcc.gnu.org/ml/gcc-regression/2014-06/ accepatble?
Dominique
> This patch fixes PR61446. ...
Confirmed, it also allows to bootstrap Core* targets.
Could it be reviewed and committed ASAP?
TIA
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/warni
Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html.
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
Warni
> 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 loo
> 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
?
> I resend patch within new thread. ...
This patch fixes pr61377. Could it be committed ASAP?
TIA,
Dominique
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 -fno-signed-ze
> 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 +020
1 - 100 of 377 matches
Mail list logo
