Re: Another AIX Bootstrap failure

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

Re: Optimize type streaming

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:

Re: Optimize type streaming

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

Re: Optimize type streaming

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

[Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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

[PATCH, gfortran testsuite] Minor cleanup for the gfortran test suite, v2.

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

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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 {

Re: Strenghten assumption about dynamic type changes (placement new)

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

Re: Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

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

Re: Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

On condition that your commit the right patch :-), OK for 4.9.1 Indeed! Committed as r212329. Thanks for the review. Dominique

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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

Re: [PATCH, gfortran testsuite] Minor cleanup for the gfortran test suite, v2.

Dear Paul, OK for trunk. Thanks for the review. Committed as r212330. Dominique

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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 +++

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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

Re: [PATCH] Don't ICE with huge alignment (PR middle-end/60226)

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

Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't call

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

Re: [Ping ^ 4] [PATCH] Fix PR 61225

The patch fixes the last issue with PR 61225. Could it be reviewed? TIA Dominique

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

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

Re: [PATCH preprocessor/61389] - libcpp diagnostics shouldn't talk about ISO C99 for C++ input files

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

Re: [GSoC] generation of Gimple loops with empty bodies

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,

[Patch, Fortran] Add library support for coarray's atomic intrinsics

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

Re: [Patch, Fortran] Update atomics support for TS18508

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

Re: [GSoC] generation of Gimple loops with empty bodies

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

Re: [GSoC] generation of Gimple loops with empty bodies

I have regtested graphite.exp for gcc/g++/gfortran/libgomp without regression. So your patch seems a safe fix. Dominique

Re: [PATCH] libstdc++: add uniform on sphere distribution

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

Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery

Tobias Burnus wrote: Actually, I wonder whether that can lead to printing an error message multiple times. This already occurs, see pr44978. Dominique

Re: [Patch, Fortran] Add CO_BROADCAST

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

Re: [PING] [PATCH] Add direct support for Linux kernel __fentry__ patching

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

Re: Move tail merging pass forward

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

Re: [Fortran, Patch] Implement IMPLICIT NONE

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

[PATCH] * MAINTAINERS (Write After Approval): Add myself.

Adding myself as Write After Approval. Dominique Index: ChangeLog === --- ChangeLog (revision 208845) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-03-26 Dominique d'Humieres domi...@lps.ens.fr + + * MAINTAINERS

Re: [Patch, fortran] PR34928 - Extension: volatile common blocks

Updated patch. OK to commit? Dominique Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (revision 208846) +++ gcc/fortran/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2014-03-26 Dominique d'Humieres

Re: [Patch, fortran] PR34928 - Extension: volatile common blocks

I have a minor nit: can you add a @code{} around the second VOLATILE? What about the COMMON in variables in COMMON blocks since revision 4.3.? Dominique

[Patch] Silence test failures on darwin9

The first patch silences hundreds of harmless warnings from Xcode 3.2.x due to r205679 and of the kind warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_namelist_item: attr = AT_namelist_item form = FORM_ref4 The following three patches fix pr54083 for darwin 8 and

Re: [libjava] XFAIL sourcelocation (PR libgcj/55637)

The libjava sourcelocation output test has been FAILing on mainline for more than a year, with no sign of anything happening to resolve that. To reduce testsuite noise, I suggest to XFAIL the test. ... Would it be possible to backport the fix to 4.8? TIA, Dominique

[committed, libjava] XFAIL sourcelocation (PR libgcj/55637) backported to 4.8.3

r...@cebitec.uni-bielefeld.de (Rainer Orth) wrote: Sure, patch preapproved. Commited as r208983: 2014-04-01 Dominique d'Humieres domi...@lps.ens.fr Rainer Orth r...@cebitec.uni-bielefeld.de PR libgcj/55637 * testsuite/libjava.lang/sourcelocation.xfail:

PING [Patch] Silence test failures on darwin9

Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01477.html Results for powerpc-apple-darwin9 with the patches at http://gcc.gnu.org/ml/gcc-testresults/2014-03/msg02361.html and without them at http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg01256.html OK for trunk? OK to

Re: [committed, libjava] XFAIL sourcelocation (PR libgcj/55637) backported to 4.8.3

if you want, you could fix the ChangeLog entry in place, but don't add a new one for that change. Done, Dominique

[Patch, committed] Adjust gfortran.dg/warn_conversion_4.f90

The test gfortran.dg/warn_conversion_4.f90 has to be adjusted after r209133. Committed as obvious as r209151. Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 209150) +++ gcc/testsuite/ChangeLog

Re: RFA: Testsuite PATCH to add support for dlopen tests

richi asked for a testcase for 60731, and since we didn't already have support for tests using dlopen, I had to add it. Does this approach make sense? r209187 causes thousands of g++ test failures. AFAICT the failing tests are those with no explicit 'dg-do compile' directive which are now

Re: [patch, libgfortran] PR60128 Wrong ouput using en edit descriptor

This test, after the update on 4.8 in r209070 when the test-case was modified substantially (not really covered by the ChangeLog entry) to be identical to that on trunk, apparently takes a different route in the fortran run-time library on 4.8 compared to trunk. For 4.8, it requires more

Re: Add testcase for PR lto/60820

this is stand alone testcase for that PR. Comitted to mainline. ... The test fails on darwin with /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr60820_0.c:13:1: warning: alias definitions not supported in Mach-O; ignored TIA Dominique

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

* http://gcc.gnu.org/ml/fortran/2014-04/msg00091.html dg2final Surely this is a typo? ... I also see dg1final and dg.final. Dominique

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

This causes several failures with -m32 (see http://gcc.gnu.org/ml/gcc-regression/2014-05/msg3.html): FAIL: gfortran.dg/coarray_lib_this_image_1.f90 -O scan-tree-dump-times original bar \\(real\\(kind=4\\)\\[2\\] \\* restrict x, void \\* restrict caf_token.., integer\\(kind=8\\)

[Fortran, patch, committed] Fix PR61025

I have committed the following patch in order to fix PR61025 (preapproved at http://gcc.gnu.org/ml/fortran/2014-05/msg1.html). Dominique 2014-05-03 Dominique d'Humieres domi...@lps.ens.fr PR fortran/61025 * gfortran.dg/coarray_lib_this_image_1.f90: Adjust the dg-final

Re: [patch, libgfortran] PR52539 I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist

As posted in the PR, neither the patch in the PR nor the one in this thread fixes the test for powerpc-apple-darwin9. Cheers, Dominique

[Patch] Minor cleanup for the gfortran test suite.

If no one objects, I'll commit the following patch in a couple of days 2014-05-05 Dominique d'Humieres domi...@lps.ens.fr * gfortran.dg/list_read_12.f90: Delete the file. * gfortran.dg/gfortran.dg/vect/fast-math-real8-pr40801.f90: Cleanup module yomphy0. ---

[Patch] Minor fixes for regtesting gfortran with -flto

With the following patch, gfortran can be regtested with -flto with no failure, but pr54852 and pr60061. OK for trunk? Dominique 2014-05-05 Dominique d'Humieres domi...@lps.ens.fr * gfortran.dg/gfortran.dg/bind_c_array_params_2.f90: Adjust regexp for -flto. *

Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering

This fixes a regression introduced with 4.8, ... This caused pr61126. Dominique

Re: Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

This is the updated patch of pr58066-3.patch. ... On x86_64-apple-darwin13 I get FAIL: gcc.target/i386/pr58066.c scan-assembler-times .cfi_def_cfa_offset 16 2 Dominique

Re: [C PATCH] Make attributes accept enum values (PR c/50459)

... Tested again x86_64-linux, ok now? 2014-05-02 Marek Polacek pola...@redhat.com PR c/50459 This caused on x86_64-apple-darwin13 FAIL: c-c++-common/pr50459.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/pr50459.c -std=gnu++11 (test for excess errors) FAIL:

Re: [C PATCH] Make attributes accept enum values (PR c/50459)

Joseph, I don't think the whole test should be skipped for that issue; I think the part requiring this feature should be split out into a separate testcase, so that as much as possible is still tested on Darwin. Is the following patch --- ../_clean/gcc/testsuite/c-c++-common/pr50459.c

Re: [Committed] [PATCH,*/2] shrink wrap a function with a single loop: split live_edge

One of the two commits breaks sevral fortran tests in 32 bit mode, see https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00155.html The ICE is [Book15] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 -m32 -O

Re: [Committed] [PATCH,*/2] shrink wrap a function with a single loop: split live_edge

One of the two commits breaks several fortran tests in 32 bit mode, ... It it is not the default you need to compile the failing tests with -mtune=core2 or -mtune=corei7. Dominique

Re: [PATCH] Fix more typos in error messages

FAIL: gfortran.dg/complex_intrinsic_4.f90 -O ... Same failures also for complex_intrinsic_6.f90. Fixed with the following patch --- ../_clean/gcc/fortran/check.c 2014-05-16 23:41:02.0 +0200 +++ gcc/fortran/check.c 2014-05-17 05:05:20.0 +0200 @@ -1821,8 +1821,8 @@

[committed PATCH] Fix bad change in fortran/check.c

I have committed the following patch as obvious: Dominique Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (revision 210559) +++ gcc/fortran/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2014-05-17 Dominique

Re: [PATCH, fortran-dev] Fix regexps

* gfortran.dg/assign_10.f90 * gfortran.dg/assumed_rank_12.f90: Likewise. Likewise what? ;) * gfortran.dg/assign_10.f90: Adjust regexps. * gfortran.dg/assumed_rank_12.f90: Likewise. Mystery of copypaste;-) Dominique

Re: [PATCH, fortran-dev] Fix regexps

Please do commit the patch ... Done as r210890 and r210891. How many regressions are we down to now? 4(5) mvbits_7(8).f90, old ones caused by some changes by Tobias a long time ago. pr48636.f90 vect/vect-gems.f90 vect/fast-math-vect-8.f90 missed optimization due to your last changes.

PING [Patch] Minor fixes for regtesting gfortran with -flto

Ping! https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00219.html Dominique

[PATCH, commited] [4.7 Regression] Needless realloc with array constructor.

Committed as r210893 and 210894 (approved by Paul Thomas on IRC). Dominique 2014-05-24 Dominique d'Humieres domi...@lps.ens.fr Backport r195492 and r195815 2013-01-27 Paul Thomas pa...@gcc.gnu.org PR fortran/55789 PR fortran/56047 * gfortran.h : Add

Re: [patch, libgfortran] [4.9/4.10 Regression] Erroneous end of file with internal read

Dear Jerry, I have regstrapped r210889 with your patch without regression. I have also run the NIST suite without failure. Thanks for the patch, Dominique

Re: [Patch] Minor fixes for regtesting gfortran with -flto

FAIL: gfortran.dg/bind_c_array_params_2.f90 -O scan-assembler-times call[^\n\r]*myBindC 1 Sorry for that! Which target? and what is the pattern? Dominique

Re: [Patch] Minor fixes for regtesting gfortran with -flto

Could you try --- ../_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_array_params_2.f90 2014-05-25 18:52:16.0 +0200 @@ -16,7 +16,7 @@ integer :: aa(4,4) call test(aa) end -! { dg-final {

Re: [Patch] Minor fixes for regtesting gfortran with -flto

Could you try --- ../_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_array_params_2.f90 2014-05-25 18:52:16.0 +0200 @@ -16,7 +16,7 @@ integer :: aa(4,4) call test(aa) end

Re: [Patch] Minor fixes for regtesting gfortran with -flto

grep _myBindC bind_c_array_params_2.s Empty. And grep myBindC bind_c_array_params_2.s ? Dominique

Re: [Patch] Minor fixes for regtesting gfortran with -flto

bl myBindC jsr myBindC bl myBindC Is this for the same target, or for 3 different ones? which one(s)? Does the following patch fixes the problem? --- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-05-24 16:17:53.0 +0200 +++

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10. ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope libgfortran/configure defines HAVE_STRNLEN on targets supporting it. The same revision also breaks the test g++.dg/tls/diag-1.C

[PATCH] Fix regexp in gfortran.dg/bind_c_array_params_2.f90

The following patch adjust the regexp in gfortran.dg/bind_c_array_params_2.f90. Tested on powerpc-apple-darwin9* and x86_64-apple-darwin*, and by Andreas Schwab on unspecified targets (see https://gcc.gnu.org/ml/fortran/2014-05/msg00137.html). OK for trunk? Dominique 2014-05-26 Dominique

[PATCH, committed] PR61319 The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

Patch approved by Jakub in the PR thread. Dominique 2014-05-27 Dominique d'Humieres domi...@lps.ens.fr PR testsuite/61319 * c-c++-common/ubsan/float-cast-overflow-1.c: Make the sign of -nan optional. * c-c++-common/ubsan/float-cast-overflow-2.c: Likewise.

[PATCH] PR 41936 Memory leakage with allocatables and user-defined operators

This patch fixes a memory leakage with allocatables and user-defined operators. It is basically Mikael's patch adjusted in order to take into account Tobias' comments. The patch fixes the memory leak in the test gfortran.dg/class_array_15.f03 and I have added a check for it. In the PR I asked

Re: [Patch] Minor fixes for regtesting gfortran with -flto

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

Re: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

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

Re: [patch i386]: Fix sibcall failures caused by allowing constant memories

I resend patch within new thread. ... This patch fixes pr61377. Could it be committed ASAP? TIA, Dominique

Re: [PATCH, Fortran] PR61234: -Wuse-no-only

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 ?

Re: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

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

Re: [Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression

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

Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html. TIA Dominique

Re: [PATCH, Fortran] PR61234: -Wuse-no-only

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

Re: [PATCH, PR61446] Fix mode for register copy in REE pass

This patch fixes PR61446. ... Confirmed, it also allows to bootstrap Core* targets. Could it be reviewed and committed ASAP? TIA Dominique

Re: [PATCH, PR61446] Fix mode for register copy in REE pass

(I am not RTL reviewer, so I can't approve the patch). Is https://gcc.gnu.org/ml/gcc-regression/2014-06/ accepatble? Dominique

Re: [PATCH, PR61446] Fix mode for register copy in REE pass

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

Re: PATCH to change -fabi-version default to 0

How does this affect pr60732? Dominique

Re: Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

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

Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC (second try)

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

Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC (second try)

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

Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC (second try)

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

Re: [PATCH, i386]: Fix recently added sibcall insns and peephole2 patterns

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

Re: PR59723: fix LTO + fortran namelist ICEs

Richard, With your patch at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00144.html I get multiple ICEs when testing with check-gfortran RUNTESTFLAGS=--target_board=unix'{-m32/-flto,-m64/-flto}' They are of the kind lto1: internal compiler error: in mentions_vars_p, at lto/lto.c:972 Note that

Re: PR59723: fix LTO + fortran namelist ICEs

With the petches (an a minor fix in gcc/lto/lto.c) the remaining failures are FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler (DW_AT_name: label|label[^\n]*[^\n]*DW_AT_name) FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 scan-assembler (DW_AT_name:

Re: [C,C++] integer constants in attribute arguments

The test g++.dg/cpp0x/constexpr-attribute2.C fails on darwin with FAIL: g++.dg/cpp0x/constexpr-attribute2.C (test for excess errors) Excess errors: /opt/gcc/_clean/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:9:40: error: 'init_priority' attribute is not supported on this platform

Re: [C,C++] integer constants in attribute arguments

I'll give it a day (it can easily be changed again later). IMO it would be better (more general) to use a dg-require-effective-target with the corresponding test(s) in target-supports-dg.exp. Dominique

[Patch, fortran] PR34928 - Extension: volatile common blocks

Is the following patch OK? Dominique 2014-02-08 Dominique d'Humieres domi...@lps.ens.fr PR fortran/34928 * fortran/gfortran.texi: Document Volatile COMMON as not suppoerted. --- ../_clean/gcc/fortran/gfortran.texi 2014-01-04 15:51:42.0 +0100 +++

Re: [Patch, fortran] PR34928 - Extension: volatile common blocks

I can't remember. Do you have commit privilege? No. If not, why? Probably because I did not asked for it explicitly. I have only hinted a couple time that I have the FSF papers signed. I'll do the changes. Thanks for the quick review, Dominique

Re: [committed] Fix #pragma omp simd with local address taken variables (PR c/59984)

Jakub, The test gcc.dg/vect/pr59984.c fails on targets using an as that does not support avx instructions (e.g., darwin). TIA Dominique

Re: [PATCH, fortran/52879] RANDOM_SEED revisited

Steve, First, it is needed to remove the line mpz_t put_size, get_size; in gcc/fortran/check.c, otherwise compiling the file with -Werror (default) fails. Second, the patch breaks the interface of RANDOM_SEED(GET/PUT...) as shown for gfortran.dg/random_seed_1.f90 and the original test in

Re: C++ PATCH for c++/55877 (names for linkage purposes)

The test g++.dg/abi/anon2.C introduced at r208157 causes: UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[ \\t]_?_ZN2N11D1C3fn1ENS0_1BE UNRESOLVED: g++.dg/abi/anon2.C -std=c++98 scan-assembler .weak(_definition)?[ \\t]_?_ZN2N11D1C3fn2ES1_ UNRESOLVED:

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

Revision 208312 causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Also compiling the test gcc.dg/lto/pr55113 with -m32 gives an ICE FAIL: gcc.dg/lto/pr55113 c_lto_pr55113_0.o assemble, -flto -fshort-double -O0 (internal compiler error) internal compiler error: in layout_type, at

Re: [Patch, Fortran] PRs 60283/60543: Fix two wrong-code bugs related for implicit pure

Tobias, However, after I wrote that, I saw that there is a dg-* which permits to check the .mod file for a string. Are you sure it works now the *.mod files are gzipped? AFAICT it does not. The following test MODULE generalFunctions USE, INTRINSIC :: ISO_FORTRAN_ENV IMPLICIT NONE INTEGER,

Re: [Patch, Fortran] PRs 60283/60543: Fix two wrong-code bugs related for implicit pure

Tobias, succeeds with your patch, but without it. was supposed to be succeeds with your patch, but not without it. I also understand what happened when the test was split in two files: If the module file is compiled with the patched compiler, then the test succeed with ot without the patch.

  1   2   3   4   >