Re: PR 60414: Patch proposal

Le 21 juil. 2014 à 15:03, Andre Vehreschild ve...@gmx.de a écrit : Hi Dominique, thank you very much for your comments. I really appreciate them. ;-) Unfortunately I am contracted only for a limited number of around 6 bugs. The control on which bugs to pick is done by compiling a project

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

Le 27 sept. 2014 à 18:45, Dominique d'Humières domi...@lps.ens.fr a écrit : I think the patch for gcc.target/i386/nop-mcount.c should be --- ../_clean/gcc/testsuite/gcc.target/i386/nop-mcount.c 2014-09-26 23:29:45.0 +0200 +++ gcc/testsuite/gcc.target/i386/nop-mcount.c

Re: [Patch, Fortran] Add CO_BROADCAST

Le 29 sept. 2014 à 23:56, Dominique d'Humières domi...@lps.ens.fr a écrit : Unless there is an objection I plan to commit tomorrow the following patch with a change log: --- ../_clean/gcc/testsuite/gfortran.dg/coarray_collectives_9.f90 2014-09-25 12:14:05.0 +0200 +++ gcc

Re: [Patch, Fortran] Add CO_BROADCAST

This is what I have committed as r215715: Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 215714) +++ gcc/testsuite/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-30-09 Dominique d'Humieres

Re: [Fortran, Patch] Implement IMPLICIT NONE

This is what I have committed as r216016 Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 216014) +++ gcc/testsuite/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-10-08 Dominique d'Humieres

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

Updated gfortran.dg/fmt_en.f90 to skip some tests not supported on i?86-*-solaris2.9* and hppa*-*-hpux* (these tests assume rounding to nearest and to even on tie, AFAICT i?86-*-solaris2.9* rounds real(16) to zero and hppa*-*-hpux* rounds all kinds to zero on tie, with some exceptions I don’t

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

Thanks for the tip. What should I do now? Should I fix the ChangeLog entry and add a new one or do nothing? Dominique Le 2 avr. 2014 à 12:47, Rainer Orth r...@cebitec.uni-bielefeld.de a écrit : domi...@lps.ens.fr (Dominique Dhumieres) writes: r...@cebitec.uni-bielefeld.de (Rainer Orth)

[PATCH] PR48094: ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto, backport to 4.8

Mike, In http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094#c21 you wrote Thanks for the report and the fix guys. I'd be fine with back port, if someone wants to develop and test it. The patch is identical to r202593 and has been tested on x86_64-apple-darwin13. Is it still OK? Dominique

Re: [PATCH] PR48094: ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto, backport to 4.7

The patch is r202593 adjusted for 4.7 and has been tested on x86_64-apple-darwin13. OK? Dominique ChangeLog CL_48094a Description: Binary data Patch patch-48094b Description: Binary data

[PATCH, fortran-dev] Fix regexps

I’ll commit this afternoon the following patch to the fortran-dev branch unless someone objects. Dominique 2014-05-24 Dominique d'Humieres domi...@lps.ens.fr * gfortran.dg/assign_10.f90 * gfortran.dg/assumed_rank_12.f90: Likewise. * gfortran.dg/coarray_12.f90:

Re: [PATCH] Don't bootstrap libcc1

Le 1 nov. 2014 à 10:43, Jakub Jelinek ja...@redhat.com a écrit : So you don't have libstdc++.a in /opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs ? Jakub Indeed I have it: [Book15] gcc/build_w% lf -l x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a

Re: [PATCH] Don't bootstrap libcc1

I am still unable to bootstrap darwin14 without revision r216964 reverted. Executing the simplified command /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ -L/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -o .libs/libcc1.0.so .libs/findcomp.o -static-libstdc++

Re: [PATCH] Don't bootstrap libcc1

Le 8 nov. 2014 à 22:55, Jack Howarth howarth.at@gmail.com a écrit : Iain, Any idea why this isn't failing universally? On all of the machines tested here with 'make bootstrap', the linkage of libcc1.so finds the necessary libstdc++ from the set of flags...

Re: fix gfcov regression

As said in PR63182, the attached patch fixes bootstrap without regression. Any reason why it has not yet been committed? Dominique Le 3 sept. 2014 à 15:15, Nathan Sidwell nat...@acm.org a écrit : On 09/03/14 04:06, Dominique Dhumieres wrote: I've committed the patch now. It (r214840)

Re: [PATCH] remove duplicated lines in gcc/fortran/resolve.c

Le 21 sept. 2014 à 10:44, FX fxcoud...@gmail.com a écrit : AFAICT the lines 11200-11222 in gcc/fortran/resolve.c are a copy of the lines 11176-11198. The duplicates were introduced by revision 126468, an unrelated patch, after the original commit of the code as 126466. It looks like a

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Le 22 sept. 2014 à 20:50, Dominique d'Humières domi...@lps.ens.fr a écrit : So, I’m wondering if the x86 maintainers want me to review and approve a patch, or if they want to. I was assuming they wanted to. Mike, From the information available, I think the only acceptable patch

[patch] Cleaning after the gfortran test suite

This patch extend the cleaning proposed in http://gcc.gnu.org/ml/fortran/2013-10/msg00083.html to opened files. The patch is mostly obvious except for gfortran.dg/open_negative_unit_1.f90 for which I assumed that the second OPEN closes the file foo.txt without deleting it (and that it is the

[Patch, libgfortran] PR59771, PR59774, and PR59836 Bugs in FORMATs Fw.0, Gw.0, and Gw.d

The attached patch fixes these bugs and adds the tests. See the PRs for = the rationale of the changes. Regression tested on x86_64-apple-darwin13 and powerpc-apple-darwin9. OK for trunk, 4.8.3, and 4.7.4 (after testing)? Regards, Dominique CL Description: Binary data patch-59774t

Re: [Patch, libgfortran] PR59771, PR59774, and PR59836 Bugs in FORMATs Fw.0, Gw.0, and Gw.d

Yes OK, and I will commit for you. Thanks Jerry. While trying to back port the patch, I have found a leftover of my previous attempts: if (ft != FMT_F before == 0 w 0 d == 0 p == 0) should be if (ft != FMT_F w 0 d == 0 p == 0) The second change was needed for 4.7 (still one

Re: [GSoC] Elimination of CLooG library installation dependency

I see two regressions after r214069 on x86_64-apple-darwin13 for both -m32 and -m64: (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect vectorized 2 loops 1 before I saw [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect

Re: [PATCH, Fortran] PR fortran/60414 fix ICE was: PR 60414: Patch proposal

Le 3 déc. 2014 à 18:08, Andre Vehreschild ve...@gmx.de a écrit : Hi, 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. Not really true, I do have objections, but I won’t fight for them. I

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

Bootstrap just finished with the patch. Thanks, Dominique Le 5 déc. 2014 à 23:47, Jakub Jelinek ja...@redhat.com a écrit : On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too,

Re: [RFC, PATCH, fortran] PR fortran/60255 Deferred character length

Dear Paul, The problem for oo.f90 is pr 55901. I am updating my working tree with Andre’s patch. Cheers, Dominique Le 8 déc. 2014 à 21:20, Paul Richard Thomas paul.richard.tho...@gmail.com a écrit : Dear Andre, s/furure/future/ :-) Why are you using a double underscore in

Re: [RFC, PATCH, fortran] PR fortran/60255 Deferred character length

Dear Andre, The patch causes an ICE for the test gfortran.dg/unlimited_polymorphic_1.f03: f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:236 f951: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program f951) Abort Reduced test

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

This was for x86_64-apple-darwin14. The patch also works for x86_64-apple-darwin10. Dominique Le 6 déc. 2014 à 01:49, Dominique d'Humières domi...@lps.ens.fr a écrit : Bootstrap just finished with the patch. Thanks, Dominique

Re: [RFC, PATCH, fortran] PR fortran/60255 Deferred character length

Hi Andre, I have posted my results with your patch (and those for pr63851) at https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02408.html. I don’t see any problem with unlimited_polymorphic_2.f90. However the character lengths are now wrong (they are 0) with your old patch for pr60289 at

Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length

For the record, compiling the tests in pr61337 with the patch applied on top of r219099 gives ICEs: use array_list 1 internal compiler error: in gfc_advance_chain, at fortran/trans.c:58 Since this replaces some wrong-code generation by some ICEs, I don’t think this should delay the fix of

Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length

. In the attached version this is fixed now. Bootstraps and regtests ok on x86_64-linux-gnu. Regards, Andre On Mon, 29 Dec 2014 16:32:27 +0100 Dominique d'Humières domi...@lps.ens.fr wrote: For the record, compiling the tests in pr61337 with the patch applied on top of r219099 gives

Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules

From a quick test, with the patch I still see the error with -m32 /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc8Yz3Jr.s:18:non-relocatable subtraction expression, __F.caf_token__global_coarrays_MOD_b minus L1$pb /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc8Yz3Jr.s:18:symbol:

Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules

Le 3 janv. 2015 à 23:30, Tobias Burnus bur...@net-b.de a écrit : Dominique d'Humières wrote: From a quick test, with the patch I still see the error with -m32 It helps if one actually adds the decl. The following (still untested) should help. I also marked the token as nonaliasing

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).

Le 20 janv. 2015 à 11:59, Iain Sandoe i...@codesourcery.com a écrit : On 20 Jan 2015, at 10:53, Arnaud Charlet wrote: Any news on when this might hit trunk? - it is a bootstrap issue (although on older targets). Right, and you have local patches/a work around. I have been on

Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

Le 15 janv. 2015 à 12:37, Janus Weil ja...@gcc.gnu.org a écrit : 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

Re: [Patch, fortran] PR64952 - Missing temporary in assignment from elemental function

Dear Paul, The patch works as advertised! I have two remarks: (1) AFAIU there is no need for a temporary for PROGRAM Main INTEGER :: i, index(5) = (/ (i, i = 1,5) /) REAL :: tmp(5), array(5) = (/ (i+0.0, i = 1,5) /) tmp = Fred(index,array) array = tmp PRINT *, array

Re: [Patch, fortran] PR64952 - Missing temporary in assignment from elemental function

Dear Paul, Le 11 févr. 2015 à 17:57, Paul Richard Thomas paul.richard.tho...@gmail.com a écrit : Dear Dominique, The patch works as advertised! I have two remarks: Of course it does :-) ;-) (1) AFAIU there is no need for a temporary for Indeed not. I cannot see how that can be

Re: [COMMITTED] Merge libffi with upstream

I have filed pr64855. Dominique Le 29 janv. 2015 à 10:10, Iain Sandoe i...@codesourcery.com a écrit : On 28 Jan 2015, at 18:16, Richard Henderson wrote: On 01/28/2015 10:10 AM, Dominique d'Humières wrote: I can't think of any reason they shouldn't work. Were they not running before

Re: [COMMITTED] Merge libffi with upstream

Le 28 janv. 2015 à 19:03, Richard Henderson r...@redhat.com a écrit : On 01/28/2015 06:28 AM, Dominique Dhumieres wrote: 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

Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c

Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit : Le 9 févr. 2015 à 19:10, Tom de Vries tom_devr...@mentor.com a écrit : On 09-02-15 18:23, Dominique Dhumieres wrote: Tom, After these changes I have the following regressions on x86_64-apple-darwin1[04

Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c

Le 10 févr. 2015 à 12:42, Tom de Vries tom_devr...@mentor.com a écrit : I think we need to understand first what's going on. Sure, my patch was mainly to silence the failures on my working tree. In both test-cases, on Linux with -fpic the inlining of one function into the other is not

Re: [Patch, Fortran] Fix previous patch (was: Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules)

Dear Tobias, I have done a clean bootstrap with your patch and run make -k check-gfortran RUNTESTFLAGS=caf.exp --target_board=unix'{-m32,-m64}’ without regression. Thanks, Dominique Le 4 janv. 2015 à 19:57, Tobias Burnus bur...@net-b.de a écrit : Attached is a regtested patch, which

Re: [Patch, Fortran, PR 64787 a.o., v2] Invalid code on sourced allocation of class(*) character string

Dear Andre, This patch fixes the issues I have reported in my previous mail. In addition it allows the Metcalf’s oo.f90 to compiles and gives sensible results at run time (yes, I have noticed the patch to fix the memory leak, and it works). I have a two comments: The list of the (partially)

Re: [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array

Hi Andre, Le 24 mars 2015 à 18:06, Andre Vehreschild ve...@gmx.de a écrit : Hi all, I have worked on the comments Mikael gave me. I am now checking for class_pointer in the way he pointed out. Furthermore did I *join the two parts* of the patch into this one, because keeping both in

Re: [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array

the correct code. Bootstraps and regtests ok on x86_64-linux-gnu/F20. Comments, please! Regards, Andre On Wed, 25 Mar 2015 10:43:34 +0100 Dominique d'Humières domi...@lps.ens.fr wrote:

Re: [PATCH] fortran/65429 -- don't dereference a null pointer

See also my comment 2 in pr65429. Cheers, Dominique Le 28 mars 2015 à 01:33, Steve Kargl s...@troutmask.apl.washington.edu a écrit : On Sat, Mar 28, 2015 at 01:01:57AM +0100, Dominique Dhumieres wrote: AFAICT your test succeeds without your patch and does not test that the ICE

Re: [PATCH] fortran/65429 -- don't dereference a null pointer

Le 28 mars 2015 à 15:50, Steve Kargl s...@troutmask.apl.washington.edu a écrit : Can one do anything useful with a zero-sized array of strings where the length of a non-existent element of the array is nonzero? The only answer I can give is that the users’ imagination is unbounded!

Re: [patch, libgfortran] [4.8/4.9/5 Regression] error reading (and writing) large text files in gfortran

On x86_64-apple-darwin14 with revision r221692, for a clean 4.8 tree configured with ../4.8_clean/configure --prefix=/opt/gcc/gcc4.8c --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin I see in

Re: [Patch, fortran] PR65792 unitialized structure constructor array subcomponent

Snip Both patches have been regression tested on trunk on x86_64-linux. OK for trunk [first patch]? OK for 4.9 and 5 (after the 5.1 release) [second patch]? Mikael PS: Dominiq reported that the variant of this patch posted on the PR was also fixing PR49324. I couldn't confirm as what

Re: [PATCH, i386, Darwin RFT]: Remove reload_in_progress checks

After having fixed the typo, regtesting went without regression. Dominique Le 19 avr. 2015 à 20:35, Uros Bizjak ubiz...@gmail.com a écrit : Hello! Attached patch removes reload_in_progress checks for x86 (LRA enabled) target. AFAICS, reload_in_progress is never set during the

Re: [Patch, fortran] PR65792 unitialized structure constructor array subcomponent

I have retested a clean tree with only the patches for pr 65792 [first patch] and Andre’s one for pr59678: i.e., without any patch from pr61831, and I still see the conflict between the two patches. Dominique Le 19 avr. 2015 à 10:39, Dominique d'Humières domi...@lps.ens.fr a écrit : Snip

Re: [PATCH, i386, Darwin RFT]: Remove reload_in_progress checks

With the patch bootstrapping x86_64-apple-darwin14 was broken due to a typo: ../../work/gcc/config/i386/i386.c: In function 'void ix86_expand_move(machine_mode, rtx_def**)': ../../work/gcc/config/i386/i386.c:17296:32: error: expected ',' or ';' before ')' token ? op0 : gen_reg_rtx

Re: [patch, fortran] PR 37131

I have played a little bit with the patched gfortran. (1) gfortran.dg/coarray_lib_this_image_2.f90 is still failing FAIL: gfortran.dg/coarray_lib_this_image_2.f90 -O scan-tree-dump-times original mylbound = parm...dim\\[0\\].stride = 0 parm...dim\\[0\\].ubound = parm...dim\\[0\\].lbound

Re: [patch, fortran, RFC] First steps towards inlining matmul

The patch causes the following regressions: FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (internal compiler error) FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=lib -O2

Re: [patch, fortran, RFC] First steps towards inlining matmul

Le 6 avr. 2015 à 01:15, Dominique d'Humières domi...@lps.ens.fr a écrit : The patch causes the following regressions: FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=single -O2 -latomic (internal compiler error) … FAIL: gfortran.dg/bound_8.f90 -g -flto (test for excess errors

Re: [patch, fortran, RFC] First steps towards inlining matmul

I have done some timings (1) with the test given below, before the patch I get (last column in Gflops) [Book15] f90/bug% gfc -Ofast timing/matmul_tst_sys.f90 -framework Accelerate [Book15] f90/bug% time a.out Time, MATMUL:373.708008 373.69497100014.2815668504139435

Re: [PATCH] PR target/66749: Add -march=iamcu to optimize for IA MCU

This breaks bootstrap on x86_64-apple-darwin14: ../../work/gcc/config/i386/i386-c.c: In function 'void ix86_target_macros_internal(long long int, processor_type, processor_type, fpmath_unit, void (*)(cpp_reader*, const char*))':../../work/gcc/config/i386/i386-c.c:59:10: error: enumeration

Re: [libquadmath, patch] Add logbq() to libquadmath

The attached patch adds logbq() to libquadmath, with code lifted from glibc. AFAICT there is something missing in the patch: I do not see any compilation of math/logbq.c and indeed no trace of logbq in libquadmath. What I am missing? TIA Dominique

Re: [libquadmath, patch] Add logbq() to libquadmath

Le 5 août 2015 à 15:11, FX fxcoud...@gmail.com a écrit : AFAICT there is something missing in the patch: I do not see any compilation of math/logbq.c and indeed no trace of logbq in libquadmath. What I am missing? Maybe you didn’t regenerate the Makefile.in? Indeed I did not!-(I have

Re: Tests for libgomp based on OpenMP Examples 4.0.2

The patch replaces all FP comparisons with inequalities and epsilons in those tests for libgomp. In libgomp/testsuite/libgomp.fortran/examples-4/simd-8.f90 integer, parameter :: EPS = 0.005 should be real, parameter :: EPS = 0.005 TIA Dominique

Re: *Ping* Re: [Patch, fortran] PR61831 side-effect deallocation of variable components

See https://gcc.gnu.org/ml/gcc-bugs/2015-07/msg01789.html Dominique

Re; [Patch, fortran] PR67171 - [6 regression] sourced allocation

Dear Paul, AFAICT no patch! Dominique

Re: Re; [Patch, fortran] PR67171 - [6 regression] sourced allocation

> Le 24 oct. 2015 à 15:46, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > Dear Paul, > > AFAICT no patch! > > Dominique > If I am not mistaken, your patch fixes pr67528 also. Dominique

Re: [PATCH] PR fortran/67805 -- Check for invalid charlength

At revision r229288 compiling the following test implicit none type :: template_t integer :: type character(256) :: charset1, charset2 integer :: len1, len2 end type template_t contains subroutine match_quoted (tt, s, n, range) type(template_t), intent(in) :: tt

Re: Re; [Patch, fortran] PR67171 - [6 regression] sourced allocation

> It also fixes the ICEs in pr61829 and pr61830. I meant pr61829 and not pr61829. Dominique

Re: Re; [Patch, fortran] PR67171 - [6 regression] sourced allocation

> Le 24 oct. 2015 à 21:08, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > >> Le 24 oct. 2015 à 15:46, Dominique d'Humières <domi...@lps.ens.fr> a écrit : >> >> Dear Paul, >> >> AFAICT no patch! >> >> Dominique >>

Re: Re; [Patch, fortran] PR67171 - [6 regression] sourced allocation

> Le 25 oct. 2015 à 14:13, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > >> It also fixes the ICEs in pr61829 and pr61830. > > I meant pr61829 and not pr61829. Please read pr61819 and pr61830. Sorry for the noise. Dominique

Re: [Patch, committed] PR67933

Dear Paul, > I have added a testcase, which has been committed as revision 229452. If I compile the test with -fsanitize=address,undefined I get at run time ==72440==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00010adfee20 at pc 0x00010adf913d bp 0x7fff54e0a270 sp

Re: [Patch, committed] PR67933

> > The recent patches on trunk to gfc_trans_allocate have fixed PR67933. > > I have added a testcase, which has been committed as revision 229452. > > This test case fails at runtime on powerpc64le-linux-gnu. … This should be fixed after revision r229503. Dominique

Re: [PATCH] PR fortran/36192 -- Check for valid BT_INTEGER

1 Error: The module or main program array 'x' at (1) must have constant shape /opt/gcc/work/gcc/testsuite/gfortran.dg/pr36192.f90:7:2: x(1,:) = (/ 1.0, 0.0 /) 1 Error: Different shape for array assignment at (1) on dimension 1 (0 and 2) Dominique > Le 26 oct. 2015 à 11:15, D

[PATCH, committed] PR67826 gcc/fortran/openmp.c:1808: bad test ?

I have committed on trunk the following patch as revision r230148 (preapproved by Jakub Jelinek and tested on x86_64-apple-darwin14) Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (revision 230147) +++

Re: [v3 PATCH] LWG 2510, make the default constructors of library tag types explicit.

Revision r230175 > 2015-11-10 Ville Voutilainen > > LWG 2510, make the default constructors of library tag types > explicit. > * include/bits/mutex.h (defer_lock_t, try_lock_t, > adopt_lock_t): Add an explicit default constructor. > *

[PATCH] PR68271 [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

The following patch restore bootstrap on darwin --- ../_clean/gcc/cp/parser.h 2015-11-10 01:54:44.0 +0100 +++ gcc/cp/parser.h 2015-11-11 12:10:28.0 +0100 @@ -48,7 +48,7 @@ struct GTY (()) cp_token { /* Token flags. */ unsigned char flags; /* Identifier for the

Re: [PATCH] PR68271 [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

gcc_assert (id < 256); } cpp_register_deferred_pragma (parse_in, space, name, id, Dominique > Le 11 nov. 2015 à 14:14, Jakub Jelinek <ja...@redhat.com> a écrit : > > On Wed, Nov 11, 2015 at 02:11:38PM +0100, Dominique d'Humières wrote: >> The following patch res

Re: [PATCH] PR fortran/68283 -- remove a rogue gfc_internal_error()

Hi Steve, Although I have not strong objection to your proposed patch, I’ld prefer the following one --- ../_clean/gcc/fortran/primary.c 2015-10-18 13:07:28.0 +0200 +++ gcc/fortran/primary.c 2015-11-13 23:32:08.0 +0100 @@ -2194,7 +2194,7 @@ check_substring:

Re: [OpenACC] declare directive

> > "Would be really nice" means that you're asking us to work on and resolve > > PR68271 before installing this patch? > > Dominique has committed a quick hack for this, so it is not urgent, but > would be nice to get it resolved. If somebody from Mentor gets to that, > perfect, otherwise I (or

[PATCH] PR47266

I’ld like to close PR47266 as FIXED after the commit on trunk and 5.2.1 of the following test extracted from https://gcc.gnu.org/ml/fortran/2011-01/msg00094.html. The test succeeds on trunk and 5.2.1 (see https://gcc.gnu.org/ml/gcc-testresults/2015-11/msg00965.html in which it was included).

Re: [PATCH] New attribute to create target clones

Evgeny, I have already checked that the addition of +/* { dg-require-ifunc "" } */ fixes the failures. I’ll test your full patch later today (currently chasing regression with gfortran). Thanks, Dominique > Le 2 nov. 2015 à 15:50, Evgeny Stupachenko a écrit : > > Yes,

Re: more accurate omp in fortran

> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c Revision r229609 breaks bootstrap: ../../work/gcc/fortran/openmp.c: In function 'void resolve_omp_clauses(gfc_code*, gfc_omp_clauses*, gfc_namespace*, bool)': ../../work/gcc/fortran/openmp.c:2925:27: error: format '%L' expects argument

Re: [PATCH] New attribute to create target clones

Evgeny, On darwin I see the following failures FAIL: g++.dg/ext/mvc1.C -std=c++11 (test for excess errors) UNRESOLVED: g++.dg/ext/mvc1.C -std=c++11 compilation failed to produce executable FAIL: g++.dg/ext/mvc1.C -std=c++14 (test for excess errors) UNRESOLVED: g++.dg/ext/mvc1.C -std=c++14

[PATCH,committed] PR fortran/67982 -- add testcase

I've committed a testcase for PR fortran/67982 to trunk. Dominique Index: gcc/testsuite/gfortran.dg/warn_unused_function_3.f90 === --- gcc/testsuite/gfortran.dg/warn_unused_function_3.f90(nonexistent) +++

[PATCH] PR54224 Warn for unused internal procedures -- update testcase

Is there any objection to commit the following (see comments 21 and 22)? Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 229793) +++ gcc/testsuite/ChangeLog (working copy) @@ -1,3 +1,9 @@

Re: [PATCH] Pr fortran/68153 -- Enhance checking of RESHAPE shape arg

Steve, The error for the test program p integer, parameter :: sh(2) = [2, 2] integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], -sh) print *, a end is pr68153_2.f90:2:34: integer, parameter :: sh(2) = [2, 2] 1 Error: 'shape' argument of

Re: [Patch, fortran, 5] Bakport Andre's r222477 deep copy fix for PR67818

> Le 15 oct. 2015 à 16:59, FX a écrit : > >> In other words, >> consider youself a reviewer for patches in an area >> of the compiler that you are comfortable. > > Seconded. > > FX Agreed, Dominique

Re: Fix more of C/fortran canonical type issues

Honza, > this is a variant of patch I commited (adding the suggested predicate) This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923 Probably related pr66238 and pr66762. TIA Dominique

Re: [PATCH] Fix PR67783, quadraticness in IPA inline analysis

> It seems there was regression on fatigue/fatigue2 > http://gcc.opensuse.org/c++bench/pb11/ Fatigue > was one of reasons to intorduce the heuristics, so it may be related to the > patch :( The test in pr 64099 comment 14 now requires -fwhole-program to inline the subroutine perdida:

Re: [Patch, fortran] COMMON block error recovery: PR 67758 (second pass)

Mikael, AFAICT the patch fixes the ICE/hang without regression. Thanks, Dominique

Re: [Patch, Fortran, 66927, v2] [6 Regression] ICE in gfc_conf_procedure_call

This patch also fixes pr57117 comment 2, the original test and the test in comment 3 now give an ICE pr57117.f90:82:0: allocate(z(9), source=reshape(x, (/ 9 /))) 1 internal compiler error: Segmentation fault: 11 and pr67044. Thanks, Dominique

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

> … but I suspect gfc_reduce_init_expr() > may be useful for PARAMETER statements as well (need to > check this!). As in the following test module m implicit none type t integer :: i end type t type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /) type(t),

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

Dear Paul, Update with your latest patch. Using the following patch --- /opt/gcc/work/gcc/testsuite/gfortran.dg/deferred_character_4.f90 2015-11-14 19:28:59.0 +0100 +++ deferred_character_4_db.f90 2015-11-14 19:43:55.0 +0100 @@ -21,6 +21,16 @@ program chk_alloc_string

[PATCH] PR 65751 Bogus in error message

Is the following patch OK for trunk and 5.3? I have used the legalese found in my draft for Fortran 2015. Would it be acceptable to replace "with the BIND attribute or the SEQUENCE attribute" with "with the BIND or SEQUENCE attribute"? Dominique Index: gcc/fortran/ChangeLog

Re: [Patch, fortran] F2008 - implement pointer function assignment

Dear Paul, I have tested your patch (with the two patches in pr67429) and got the following regressions: FAIL: gfortran.dg/bind_c_usage_12.f03 -O (test for errors, line 33) FAIL: gfortran.dg/bind_c_usage_12.f03 -O (test for errors, line 51) FAIL: gfortran.dg/bind_c_usage_12.f03 -O

Re: Possible patch for pr62242 -- follow-up

Louis, A few comments: (1) your patch fixes pr62242 and, as said in a previous mail, pr62246, pr60110, and some variants of pr52332. I have updated pr52332 and marked pr62246 and pr60110 as duplicate. Could you please add PR fortran/52332 to the ChangeLog entry? (2) You need a

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

Without initialization the errors are of the kind: Error: Expression at (1) must be of INTEGER type, found * see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get the same message with initialization? Cheers, Dominique

Re: [PATCH, i386, AVX-512] Update extract_even_odd w/ AVX-512BW insns.

Kirill, The new tests fail on x86_64-apple-darwin14: FAIL: gcc.target/i386/vect-pack-trunc-1.c (test for excess errors) UNRESOLVED: gcc.target/i386/vect-pack-trunc-1.c compilation failed to produce executable FAIL: gcc.target/i386/vect-pack-trunc-2.c (test for excess errors) UNRESOLVED:

Re: Possible patch for fortran/65766

AFAICT this patch has been approved by FX at https://gcc.gnu.org/ml/fortran/2015-07/msg00168.html. Any reason to not commit it? Dominique

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

This breaks bootstrap on darwin: ../../work/gcc/config/darwin.c: In function 'bool darwin_use_anchors_for_symbol_p(const_rtx)': ../../work/gcc/config/darwin.c:3016:9: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] return

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

Revision r231571 with Jan-Benedict Glaw’s fix for trailing whitespace. Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 231570) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,13 @@ +2015-12-11 Jan-Benedict Glaw

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

> +/* { dg-lto-options { { -flto -O2 -Werror -Wl,--defsym,__fread_chk=0x1234 } > } } */ This won’t work on darwin: ld: unknown option: --defsym collect2: error: ld returned 1 exit status TIA Dominique

Re: [PATCH committed] Bug 66680 - [5 Regression] ICE with openmp, a loop and a type bound procedure

> Le 7 janv. 2016 à 19:02, H.J. Lu <hjl.to...@gmail.com> a écrit : > > On Thu, Jan 7, 2016 at 9:59 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Thu, Jan 7, 2016 at 5:30 AM, Dominique d'Humières <domi...@lps.ens.fr> >> wrote: >>> I have commi

Re: [Patch, fortran] [6 Regression] ICE: in gfc_get_descriptor_dimension, at fortran/trans-array.c:268

Dear Paul, > This is a rather trivial patch... going on 'obvious' in fact. However, > I must confess to not being entirely sure why the problem is > occurring. Deferred arrays are emanating from the finalizer that are > being presented as ARRAY_TYPES rather than descriptors. What ever is > the

Re: [Patch, libgfortran] PR68987 [5/6 Regression] double free or corruption in _gfortran_st_write_done

Jerry, Do you remember why you have added the block you want to delete? Is there a way to do a test similar to if (!(dtp->common.flags & IOPARM_HAS_IOSTAT)) when using ERR? Thanks for the patch. Dominique

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

Hi Steve, Compiling the attached code after revision r230710 gives the ICE f951: internal compiler error: in gfc_simplify_cshift, at fortran/simplify.c:1823 while it compiled before. TIA Dominique mhd.f90 Description: Binary data

  1   2   3   4   5   >