[Patch] PR71017 - libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

The following patch fixes errors of the kind libgcc/config/i386/cpuinfo.c:260:17: runtime error: left shift of 1 by 31 places cannot be represented in type ‘int' 2017-01-07 Dominique d'Humieres PR target/71017 * config/i386/cpuid.h: Fix undefined

Re: Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588

I have this patch in my working tree and it works as expected. > Also fixes pr78935. Confirmed. Thanks for the patch, Dominique

Re: [PATCH] PR 78534 Change character length from int to size_t

> Le 16 déc. 2016 à 19:06, Janne Blomqvist <blomqvist.ja...@gmail.com> a écrit : > > On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières > <domi...@lps.ens.fr> wrote: >> Hi Janne, >> >> I have applied your two patches and found that I had to skip the

Re: [PATCH] PR 78534 Change character length from int to size_t

Hi Janne, I have applied your two patches and found that I had to skip the patches for resolve.c and match.c due to the errors ../../p_work/gcc/fortran/resolve.c: In function 'void resolve_select_type(gfc_code*, gfc_namespace*)': ../../p_work/gcc/fortran/resolve.c:8731:58: error: format '%lld'

Re: [PATCH, Fortran, pr78672, ctp1, v2] Gfortran test suite failures with a sanitized compiler

> Jerry: trans-expr.c::gfc_conv_cst_int_power() > I have added comment to new C++ code. Would you like to add something to it? Note that the wi changes have occurred at revision r210113. > > The updated patch bootstraps and regtests fine on x86_64-linux/f23 on a > regular > and on an

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90 fail with lto1: error: two or more sections for .gnu.lto___get_PROC_names.3e3ee55b08747e7c lto1: internal compiler error: cannot read LTO decls from /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o This may

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

Dear Paul, I have found another glitch with all the patches in this thread: they transform an ICE to accept-invalid for the tests z7.f90, z8.f90, and z9.f90 in pr77414. Dominique > Le 10 nov. 2016 à 23:48, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > FA

Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components

Hi Andre, I fear the patch is causing another set of failures with -fopenmp: FAIL: libgomp.fortran/allocatable11.f90 -O0 (internal compiler error) … FAIL: libgomp.fortran/allocatable8.f90 -g -flto (test for excess errors) of the kind collect2: error: ld returned 1 exit status [Book15]

Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components

> I also have addressed the ICEs with proc_pointer components. Confirmed, the patch LGTM. Thanks, Dominique

Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.

If I compile the test with an instrumented gfortran , I get ../../work/gcc/fortran/interface.c:2948:33: runtime error: load of value 1818451807, which is not a valid value for type ‘expr_t' Dominique > Le 30 nov. 2016 à 21:06, David Edelsohn a écrit : > > Hi, Andre > >

Re: Documentation of LTIME

> Still, since we internally already have both implementations for > kind=4 and kind=8, we could as well make use of them, I guess. I let this for people understanding what to do. > If not, we definitely need to fix the documentation of LTIME, since > the current version simply does not work

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

> Le 26 nov. 2016 à 10:45, Janus Weil a écrit : > > ping! > The patch is working has expected. Note the removed block has been introduced by Daniel Franke at r126826. Dominique.

Re: Documentation of LTIME

> Le 26 nov. 2016 à 17:00, Janus Weil a écrit : > > And one last point: The description of LTIME mentions TIME8, but if I try > this: > > call ltime(time8(), values) > > I get: > > Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4 Well LTIME cannot

Re: Documentation of LTIME

> Le 26 nov. 2016 à 16:54, Janus Weil <ja...@gcc.gnu.org> a écrit : > > 2016-11-26 16:49 GMT+01:00 Dominique d'Humières <domi...@lps.ens.fr>: >> If there is no objection, I’ll commit the following patch > > Looks good to me! > > If you want, you could a

Re: Documentation of LTIME

If there is no objection, I’ll commit the following patch --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 +0100 +++ gcc/fortran/intrinsic.texi 2016-11-26 16:47:12.0 +0100 @@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne seconds @item

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

Hi Janus, > the attached patch fixes an ice-on-valid problem, simply by removing an > assert. ... I have several instances in my test suite showing that the proposed patch removes the ICE but generates wrong code: pr42359, second test, => ICE on another place pr54613, sixth and eighth tests,

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

FAIL: gfortran.dg/char_result_16.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/char_result_16.f90 -g -flto (test for excess errors) The ICE is for both -m32 and -m64 (module_procedure_3_db_1.f90 is the test posted in my last mail) % gfc module_procedure_3_db_1.f90 -flto

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

> Le 9 nov. 2016 à 20:09, Paul Richard Thomas a > écrit : > > Dear Dominique, > > I am deeply embarrassed. This is the consequence of an additional > condition added at the last minute. No reason to be embarrassed;-) > The attached removes it and makes sure

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

Sorry for the bad news, but while gfortran regtests with regression with the patch I still get a link error with the original test: % gfc pr44265.f90 Undefined symbols for architecture x86_64: "___fruits_MOD_names", referenced from: _MAIN__ in ccyeNqa1.o ld: symbol(s) not found for

Re: Possible patch for fortran/55086

> The problem was that forall could handle substring expressions, > but not if it had to create a temporary array. I did my best > to fix this. I left a couple of TODO comments in the code. Well, I don’t understand why the test needs a temporary for forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)

Re: [Patch, fortran] PR69834 - Collision in derived type hashes

> Dear All, > > I was intending to backport this patch to 6-branch. However, I see > that this is closed to all but regressions and documentation at > present. > > The patch applies cleanly, except for two small chunks in resolve.c > which were easily inserted by hand, and bootstraps and regtests

Re: [patch, fortran] Fix PR 69544

gfortran regtested without regression with the patch --- ../_clean/gcc/fortran/match.c 2016-11-01 17:24:32.0 +0100 +++ gcc/fortran/match.c 2016-11-01 16:21:31.0 +0100 @@ -6219,6 +6219,7 @@ match_simple_where (void) c->next = XCNEW (gfc_code); *c->next = new_st; +

Re: [patch, fortran] Fix PR 69544

Hi Thomas, > the attached, rather simple, patch, fixes a regression where > the locus was not set, leading to an ICE on a warning. Looking for the occurrences of gfc_clear_new_st in fortran/match.c, I have found it in the following procs: gfc_match_if match_simple_forall gfc_match_forall

Re: [patch, fortran] PR45516 - [F08] allocatable components of recursive type

Dear Paul, The patch works as expected. The following test now compiles but segfault at run time: program test_move_alloc type :: linked_list type(linked_list), allocatable :: link integer :: value end type linked_list type(linked_list) :: test test % value = 1

Re: [PATCH] PR fortran/78033 -- This was a REAL pain

> Le 22 oct. 2016 à 16:42, Steve Kargl <s...@troutmask.apl.washington.edu> a > écrit : > > On Sat, Oct 22, 2016 at 02:22:47PM +0200, Dominique d'Humières wrote: >> See comments in pr78033. What are the plans to handle pr54730? >> > > Not sure what yo

Re: [PATCH] PR fortran/78033 -- This was a REAL pain

See comments in pr78033. What are the plans to handle pr54730? Dominique

Re: [Patch, fortran] PR69834 - Collision in derived type hashes

hat the core of the patch is OK and that it is the clean-up > element that is failing to apply. > > Best regards > > Paul > > > On 22 October 2016 at 01:04, Dominique d'Humières <domi...@lps.ens.fr> wrote: >> Dear Paul, >> >> If I did not do any mistake,

Fwd: [Patch, fortran] PR69834 - Collision in derived type hashes

> Début du message réexpédié : > > De: Dominique d'Humières <domi...@lps.ens.fr> > Objet: Rép : [Patch, fortran] PR69834 - Collision in derived type hashes > Date: 22 octobre 2016 à 01:04:21 UTC+2 > À: Paul Richard Thomas <paul.richard.tho...@gmail.com> > Cc

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

Forget it! It seems that I did not apply the patch!-( Sorry for the noise. Dominique > Le 16 oct. 2016 à 18:42, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > Dear Jerry, > >> The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call >>

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

Dear Jerry, > The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call abort’. > This seems consistent with your comment I have not been clear enough: I have to replace 64 with 16 even with your patch. Dominique

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

Dear Jerry, The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call abort’. This seems consistent with your comment > The language seems a little obscure. I think the first sentence means > don't expect inquire to use a UDDTIO procedure and the second sentence > says when you use

Re: [PATCH, libfortran] PR 48587 Newunit allocator

With the patch, the following code integer :: i, j i = -10 write(unit=i,fmt=*, iostat=j) 10 print *, j end fails at run time with Assertion failed: (ind >= 0 && ind < newunit_size), function newunit_free, file ../../../work/libgfortran/io/unit.c, line 966. Without the patch the output is

Re: Possible patch for fortran/57910

imes are quite fragile, but at least they are portable from a target to another one. I hope it helps. Dominique > > Louis > > > On Thu, 06 Oct 2016 10:04:36 -0700 Dominique d'Humières > <domi...@lps.ens.fr> wrote >> Dear Louis, >> >>> P

Re: Possible patch for fortran/57910

Dear Louis, > PR fortran/57910 > * trans-expr.c (gfc_add_interface_mapping): Don't try to > dereference call-by-value scalar argument. > > The patch seems to work without breaking other tests. From the patch, I think the PR number is wrong and should be 69955. The test fails on darwin with At

Re: [Patch, libgfortran] Inquire internal unit within child dtio procedure

Dear Jerry, > Committed as trivial. Many things are trivial unless noted otherwise! The patch causes the following failures: FAIL: gfortran.dg/inquire_13.f90 -O0 execution test FAIL: gfortran.dg/inquire_15.f90 -O0 execution test FAIL: gfortran.dg/inquire_6.f90 -O0 execution test FAIL:

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

The new patch works on darwin without new regression. Thanks, Dominique > Le 4 oct. 2016 à 15:58, Pierre-Marie de Rodat <dero...@adacore.com> a écrit : > > Hello, > > Thank you very much for you help, Dominique! > > On 09/29/2016 03:16 PM, Dominique d'Humières

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

I have bootstrapped revision r240599 with the patch https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01315.html without any problem. However compiling the following Fortran tests FAIL: gfortran.dg/binding_label_tests_16.f03 -g (internal compiler error) FAIL: gfortran.dg/module_commons_3.f90

Re: [PATCH] DWARF: remove pessimistic DWARF version checks for imported entities

> Le 28 sept. 2016 à 17:44, Jason Merrill a écrit : > > On Thu, Aug 18, 2016 at 5:33 AM, Pierre-Marie de Rodat > wrote: >> A check in dwarf2out_imported_module_or_decl prevents valid strict >> DWARF2 constructs such as DW_TAG_imported_declaration from

Re: [PATCH] Refactor section/label init for early LTO debug

> this patch introduced many pch assembly comparison failures on Solaris > (both sparc and x86, 32 and 64-bit, /bin/as only), like Something on darwin. TIA Dominique

[PR77719] Fix ICE in pp_string, at pretty-print.c:955

Hi, Two possibilities: (a) pass -w in the dg-options (b) replace INTEGER, PARAMETER :: dp=8 with INTEGER, PARAMETER :: dp=8, spdim=42 (or any number you like!-). Dominique

Re: [accaf, fortran, 4/4] Allocatable components support in derived typed coarrays

Really fixed by revision r240467. Sorry for the noise. Dominique > Le 24 sept. 2016 à 17:14, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > Done as revision r240463. > >> Le 24 sept. 2016 à 16:32, Andre Vehreschild <ve...@gmx.de> a écrit : >> &

Re: [accaf, fortran, 4/4] Allocatable components support in derived typed coarrays

Done as revision r240463. > Le 24 sept. 2016 à 16:32, Andre Vehreschild a écrit : > > Hi Dominique, > > Yes of course. It makes sense to have the param a 4byte entity on 32 bit > systems. Please commit. I am on a mobile only currently and can't do so > before tomorrow

Re: [accaf, fortran, 4/4] Allocatable components support in derived typed coarrays

Hi Andre, It seems that the committed test gfortran.dg/coarray_lib_comm_1.f90 is not right. I have to apply the patch --- ../_clean/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 2016-09-23 12:45:56.0 +0200 +++ gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f902016-09-24

Re: Fortran, committed: segfault with allocate and stat for derived types with default initialization (pr 68078)

> Fixed in revision 240219. The test fails on x86_64-apple-darwin15 (at least): FAIL: gfortran.dg/pr68078.f90 -O0 output pattern test FAIL: gfortran.dg/pr68078.f90 -O1 output pattern test FAIL: gfortran.dg/pr68078.f90 -O2 output pattern test FAIL: gfortran.dg/pr68078.f90 -O3

Re: [PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

The same should apply to g++.dg/debug/dwarf2/template-params-12g.C: --- ../_clean/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C 2016-08-12 09:59:34.0 +0200 +++ gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C 2016-08-30 11:36:48.0 +0200 @@ -1,4 +1,4 @@ -//

Re: [Fortran, Patch, PR72832, v1] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

Hi Andre, The patch works as expected. As said on IRC, IMO the dejagnu directives in gfortran.dg/allocate_with_source_23.f03 +! { dg-do run { xfail *-*-* } } +! { dg-options "-fcheck=bounds" } should be replaced with +! { dg-do run } +! { dg-options "-fcheck=bounds" } +! { dg-shouldfail "Array

Re: [PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

Preliminary tests show that the patch fixes the issue. Thanks, Dominique > Le 29 août 2016 à 21:41, Jakub Jelinek a écrit : > > Hi! > > This testcase expects to find DWARF extensions, but those are disabled by > default on darwin/vxworks because broken tools there don't

Re: [committed] Re: Bug in DEC UNION/STRUCT patch

I think pr77327 is also yours!-( Dominique > Le 23 août 2016 à 21:46, Fritz Reese <fritzore...@gmail.com> a écrit : > > On Tue, Aug 23, 2016 at 12:22 PM, Dominique d'Humières > <domi...@lps.ens.fr> wrote: >>> This above is pretty clearly a typo. The attach

Re: [committed] Re: Bug in DEC UNION/STRUCT patch

> This above is pretty clearly a typo. The attached patch committed as > obvious r239706. Could you please provide a test failing before r239706 and succeeding after it? TIA Dominique

Re: [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

Dear Jerry, > Dominiq, please test on your system. It does work on darwin! Thanks for the quick fix. Dominique

Re: [PATCH] Fix PR77286

This patch causes: FAIL: gfortran.dg/vect/pr69466.f90 -O (internal compiler error) FAIL: gfortran.dg/vect/pr69466.f90 -O (test for excess errors) with -m32. [Book15] f90/bug% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/vect/pr69466.f90 -O2 -ftree-vectorize -m32 -march=core-avx2

Re: [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

> > It is related to pr30617. When I compile the dtio testcases with > -lpthread, they hang as you say (as does the testcase of pr30617). > > Blast! Both Jerry and I are using Fedora. Do I gather that the use of > threads is not the default there? > > Cheers > >

Re: [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

Dear Paul, I have tried the patch, but all the tests hang at run time (expect dtio_10.f90). This is on x86_64-apple-darwin15. Could it be related to pr30617? Cheers, Dominique

Re: [Fortran, Patch, pr70524, v1] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

The patch works as advertised. It would be nice to have it reviewed and committed. TIA Dominique

Re: [patch, fortran] PR66310 Problems with intrinsic repeat for large number of copies

> Le 18 juil. 2016 à 02:02, Jerry DeLisle a écrit : > > Please test this revised patch. See my comments in the PR. > > I think we should commit this one. > > Jerry Jerry, As said on IRC I think the limit should be documented and a TODO comment added to

Re: [patch, fortran] PR66310 Problems with intrinsic repeat for large number of copies

> > 2016-07-11 Jerry DeLisle > > > > PR fortran/66310 > > * simplify.c (gfc_simplify_repeat): Set max repeat to huge - 1 to allow > > one byte for null terminating the resulting string constant. > > OK, thanks Please hold on. I still see several problem with

[PATCH gfortran] PR 60751 - Extra comma in WRITE statement not diagnosed

The attached patch fixes pr60751 by allowing extra comma in WRITE statement for std=legacy only, tested on x86_64-apple-darwin15. Is it OK for trunk, and the gcc-5 and 6 branches? TIA Dominique patch-60751b Description: Binary data

Re: GCC 5.4 Release Candidate available from gcc.gnu.org

Richard, > … If all goes well I'd like to release GCC 5.4 at the beginning of next > week. Would it be possible to apply the following patch --- ../5.4.0-RC/gcc/testsuite/c-c++-common/asan/sanity-check-pure-c-1.c 2012-12-13 00:04:22.0 +0100 +++

Re: [PATCH] Requre nonpic target on some PR target/70155 tests

> Some PR target/70155 tests check for nonexistence of the *movdi_internal > pattern. Since PIC leads to the *movdi_internal pattern, skip those > tests if PIC is used. > > Tested on x86-64. OK for trunk? I cannot approve the patch, but I confirm that the tests fail on darwin. TIA, Dominique

Re: Cilk Plus testsuite needs massive cleanup (PR testsuite/70595)

Any reason why the dg-additional-options "*-lcilkrts" have been removed? AFAICT they are needed for darwin. TIA Dominique

[PATCH, committed] Fortran cleanup-submodules

I have committed the following as obvious at revision r235367. Is it OK to back port it to the gcc-6 branch? Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 235364) +++ gcc/testsuite/ChangeLog

[committed, Fortran] PR67039 and PR58000 minor documentation changes

I have committed the following patches to trunk after Jerry’s approval on bugzilla. Is it OK to back port them to the gcc-5 branch? Dominique Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (revision 234935) +++

Re: [PATCH withdrawn] PR47040 - Make error message for empty array constructor more helpful/correct, closed as INVALID

Patch withdrawn, PR47040 closed as INVALID. Dominique

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

> > It is valid syntax because of > > "An empty sequence forms a zero-sized rank-one array." > > It seems that J3 saw the error in their ways as (/ /) is clearly > an empty array constructor, and fixed the possibility of creating > a typeless zero-sized, rank-one array. This is exactly the

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

> (/ /) is valid Fortran 95 syntax > ... > > program foo > call bar((/ /)) > end program foo > > % gfc -c -std=f95 foo.f90 > foo.f90:2:17: > >call bar((/ /)) > 1 > Error: Empty array constructor at (1) is not allowed > > The above error is correct. Well the two

[committed] PR70592 New test gfortran.dg/deferred_character_16.f90

As asked by Paul Richard Thomas on IRC I have committed the following patch to trunk. I’ll commit it to the gcc-5 branch tomorrow. Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 234849) +++

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

>>> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote: >>>> Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it >>>> be back ported to the gcc-5 branch? >>> >>> No and No. > Le 7 avr. 2016 à

[committed] Fix [Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c

I have committed the following patch for PR70573 (preapproved by Jakub Jelinek in bugzilla) Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 234847) +++ gcc/testsuite/ChangeLog (working

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

Could you please elaborate. Dominique > Le 7 avr. 2016 à 07:48, Steve Kargl <s...@troutmask.apl.washington.edu> a > écrit : > > On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote: >> Is the following patch OK (regtested on x86_64-apple-darwin15)? Shou

[PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be back ported to the gcc-5 branch? TIA Dominique Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (revision 234788) +++

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

-O0 scan-tree-dump-not original "c.caf.x = 0B" > Is only the removal of the file implicit? Yes, > I will add the option to be on the safe side. Thanks, Dominique > > - Andre > > Am 3. April 2016 22:57:48 MESZ, schrieb "Dominique d'Humières" > <

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

Andre, Does not the test gfortran.dg/coarray_allocate_6.f08 require a -fdump-tree-original in the dg-options list? Thanks for the patch, Dominique

Re: [patch, fortran] PR68566 ICE on using unusable array in reshape

> Le 2 avr. 2016 à 11:44, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > Hi Jerry, > >> ... >> I will add an additional test case for the original posted problem in the PR. >> Two existing tests get exercised, changing the error message. Finding the

Re: [patch, fortran] PR68566 ICE on using unusable array in reshape

Hi Jerry, > ... > I will add an additional test case for the original posted problem in the PR. > Two existing tests get exercised, changing the error message. Finding the > problems earlier in the matchers I think is the right way to go. I am curious > if > the old checks ever get triggered (I

Re: [Patch] PR 70235 - [4.9/5/6 Regression] Incorrect output with PF format

Thanks for the quick review. Committed on trunk as revision r234600. I’ll wait a week for gcc-5 and gcc-4.9. Dominique > Le 30 mars 2016 à 22:38, Jerry DeLisle <jvdeli...@charter.net> a écrit : > > On 03/30/2016 01:18 PM, Dominique d'Humières wrote: >> Is the followi

[Patch] PR 70235 - [4.9/5/6 Regression] Incorrect output with PF format

Is the following patch OK for trunk and the gcc-4.9 and gcc-5 branches after some delay (bootstrapped and regtested on x86_64-apple-darwin15)? TIA Dominique Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog

Re: C++ PATCH for c++/70353 (core issue 1962)

> Le 28 mars 2016 à 15:11, Jason Merrill <ja...@redhat.com> a écrit : > > On 03/28/2016 09:02 AM, Dominique d'Humières wrote: >> >>> Le 28 mars 2016 à 14:55, Jason Merrill <ja...@redhat.com> a écrit : >>> >>> OK, thanks. >>>

Re: C++ PATCH for c++/70353 (core issue 1962)

> Le 28 mars 2016 à 14:55, Jason Merrill a écrit : > > OK, thanks. > > Jason Does it mean that I should commit the patch? Dominique

Re: [Patch, Fortran, pr70397, gcc-5, v1] [5/6 Regression] ice while allocating ultimate polymorphic

Andre, In order to apply the patch on a recent trunk @@ -1070,7 +1089,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems, bool unlimited) if (unlimited) { if (from_class_base != NULL_TREE) - from_len = gfc_class_len_get (from_class_base); + from_len =

Re: C++ PATCH for c++/70353 (core issue 1962)

Hi Jason, The following tests for g++.dg/ext/fnname5.C fail on darwin FAIL: g++.dg/ext/fnname5.C -std=c++11 scan-assembler .string\\t"foo" FAIL: g++.dg/ext/fnname5.C -std=c++11 scan-assembler .string\\t"void A::foo(int)" FAIL: g++.dg/ext/fnname5.C -std=c++14 scan-assembler

RFA [Patch] PR 45076 - [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use

AFAICT pr45076 is fixed on the gcc-4.9, gcc-5 branches, and trunk. I have borrowed the machinery in g++.dg/tree-prof/tree-prof.exp for the attached patch and tested it on the three branches. Is it OK as such or is there a better way to do the testing? TIA Dominique patch-45076 Description:

Re: [PATCH] Add -funconstrained-commons to work around PR/69368 (and others) in SPEC2006

Alan, The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It needs some regexp capturing mycommon.x[j_1] = _5; as in " mycommon\.x\[.?_[0-9]+\] = _[0-9]+;" TIA Dominique

Re: bug report : gfortran E edit descriptor

> I have an trouble in E edit descriptor of gfortran. > This is a example. > (source file: test.f95) >program test >implicit none >real a,b >a=135.0 >b=1737.5 >write(*,*)a,b >write(*,'(e9.3,a,f7.1)')a,' ',b >

Re: [Patch, fortran] PR68241 - [meta-bug] Deferred-length character

Dear Paul, As you said on IRC the patch needs -l to apply. After that the gcc-5 branch bootstrapped and regtested without any problem. Thanks, Dominique > Le 7 mars 2016 à 11:22, Paul Richard Thomas a > écrit : > > Dear All, > > I had promised to get the

Re: [PATCH] 69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align, with small alignment

The test gcc.dg/builtins-68.c fails on x86_64-apple-darwin15: FAIL: gcc.dg/builtins-68.c (test for errors, line 79) FAIL: gcc.dg/builtins-68.c (test for excess errors) Excess errors: /opt/gcc/work/gcc/testsuite/gcc.dg/builtins-68.c:107:40: warning: large integer implicitly truncated to unsigned

Re: [Fortran,4.9/5/6 Regression]ICE for Fortran files when specifying a file instead of an include directory

Hi Jerry, > Let me no if any objections. The test gfortran.dg/include_6.f90 should be updated: before the patch f951: Warning: 'gfortran.log' is not a directory after f951: Fatal Error: 'gfortran.log' is not a directory Thanks, Dominique

Re: [patch, libgfortran] PR69456 Namelist value with trailing sign is ignored without error

Hi Jerry, The patch works as advertised without regression. Just one nit, I am puzzled by the comment in the line of gfortran.dg/namelist_89.f90 +write(99,*) " c1=(1-,1+1)" ! Treated as 1e-1?! Should not it be +write(99,*) " c1=(1-,1+1)" ! Should give error on item number 5 or something

Re: New tests for PRs 52531 and 57365

Committed on trunk as revision r233588. Dominique > Le 15 févr. 2016 à 14:53, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > PRs 52531 and 57365 are fixed on trunk and gcc5 branch. Unless someone > objects I am planing to add the following tests in the coming

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

With the patch I get an ICE when compiling gfortran.dg/allocate_error_5.f90 (lldb) target create "/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951" Current executable set to '/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951' (x86_64). (lldb) run

Re: [6 Regession] Usage of unitialized pointer io/list_read.c (

With the following reduced test program test implicit none integer :: i, j, k, ios integer, parameter :: big = 600 character(kind=4,len=big) :: str1, str2 do i=1,big, 10 do j = 0, 9 k = i + j str2(k:k) = char(65+j) end do end do open(15, status='scratch',

Re: [6 Regession] Usage of unitialized pointer io/list_read.c (

Hi Jerry, > Thanks for review. Committed to trunk r233436. The test gfortran.dg/read_bang4.f90 fails on x86_64-apple-darwin15: a.out(15552,0x7fff7b2e3000) malloc: *** error for object 0x7fb472804c00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug

Re: [Patch, fortran, pr67451, v1] [5/6 Regression] ICE with sourced allocation from coarray

> Hi all, > > unfortunately was my last patch for pr67451 not perfect and introduced > regressions occurring on s390(x) and with the sanitizer. These were > caused, because when taking the array specs from the source=-expression > also its attributes, like coarray state and so on where taken

Re: [PATCH, PR67709 ] Don't call call_cgraph_insertion_hooks in simd_clone_create

The patch fixes the PR on x86_64-apple-darwin15. > OK for stage1 trunk? What it the reason to delay the fix for a couple of months? Thanks for working on the issue. Dominique

Re: [Committed] New test for PR 66707 - Endless compilation on wrong usage of common

Done as r233009 Thanks for the review, Dominique > Le 30 janv. 2016 à 16:45, Paul Richard Thomas > a écrit : > > Hi Dominique, > > Thanks for doing this. Yes, it's OK for 5-branch as well. > > Cheers > > Paul

[Committed] New test for PR 66707 - Endless compilation on wrong usage of common

AFAICT PR 66707 has been fixed/ prevented/hidden by revision r226732. I have committed the following as obvious Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 233007) +++ gcc/testsuite/ChangeLog

[PATCH] PR 68283 [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

Dear all, Is the following patch OK for trunk and the gcc5 branch? see the thread starting at https://gcc.gnu.org/ml/fortran/2015-11/msg00057.html and https://gcc.gnu.org/ml/fortran/2015-11/msg00072.html. Dominique Index: gcc/fortran/ChangeLog

Re: [patch] libstdc++/69386 Ensure C++ language linkage in cmath and cstdlib

Jonathan, > PR libstdc++/69386 > * include/c_global/ccomplex: Ensure C++ language linkage. > * include/c_global/cmath: Likewise. > * include/c_global/cstdlib: Likewise. > * include/c_global/ctgmath: Likewise. > * testsuite/17_intro/headers/c++2011/linkage.cc: New. The test

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

+0100, Torvald Riegel wrote: >> On Sat, 2016-01-16 at 10:57 +0100, Dominique d'Humières wrote: >>> > Addressed these, fixed a problem with using GLIBCXX_WEAK_DEFINITION >>> > (which is only set on Darwin despite the generic-sounding name -- so >>> > just

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

> Le 21 janv. 2016 à 16:25, Torvald Riegel <trie...@redhat.com> a écrit : > > On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote: >> Torvald, >> >> Now that I can bootstrap on darwin, I have found the following failure for >> libitm.c++/l

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

> Le 21 janv. 2016 à 18:15, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > > >> Le 21 janv. 2016 à 16:25, Torvald Riegel <trie...@redhat.com> a écrit : >> >> On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote: >>> Torvald, >

<    1   2   3   4   5   >