Re: [PATCH] restore -Warray-bounds for string literals (PR 83776)

On 07/13/2018 05:09 PM, Martin Sebor wrote: >>> +  /* At level 2 check also intermediate offsets.  */ >>> +  int i = 0; >>> +  if (extrema[i] < -strbounds[1] >>> +  || extrema[i = 1] > strbounds[1] + eltsize) >>> +    { >>> +  HOST_WIDE_INT tmpidx = extrema[i].to_shwi () / eltsize.to_shwi

[PATCH][debug] Fix pre_dec handling in vartrack

Hi, when compiling test-case gcc.target/i386/vartrack-1.c with -O1 -g, register bx is pushed in the prologue and popped in the epilogue: ... (insn/f 26 3 27 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) (reg:DI 3 bx)) "vartrack-1.c":10 61 {*pushdi2_rex64}

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi Janus, I tested it on a fairly large code base and found no further false positives. Also it still regtests cleanly. Ok for trunk? while I still disagree with this on principle, I will not stand in the way. However, one point: I think that the warning should be under a separate warning,

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

Hi all, here is another update of the patch. It cures the previously-mentioned problems with generic interfaces, adds some documentation (as suggested by Dominique) and slightly enhances the error message (mentioning the impurity of the function we're warning about). I tested it on a fairly

[committed] [PR target/85993] Remove dead conditional in SH target code

Per Oleg's comment in the PR, the second block is dead and should be removed... Committing to the trunk. While I'm confident this won't change anything, my tester will bootstrap sh4 & sh4eb overnight for additional verification. Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index

Re: [patch, fortran] Asynchronous I/O, take 3

Am 15.07.2018 um 19:47 schrieb Rainer Orth: Because this does not appear to work with Linux. I, like most gfortran developers, work on Linux, and I would like to catch any failure during regression-testing on my own system, if possible. huh, what doesn't work? I've just finished an

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Jerry, > On 07/15/2018 11:46 AM, Rainer Orth wrote: >> Hi Jerry, >> >>> Hmm, interesting. Which linux are you using? >> >> Fedora 27. > > Works for me. Fedora 28. Do not know for other OS's just tried Solaris 11/x86: works just as well. I could try Mac OS X 10.7, but that build would take

Re: [patch, fortran] Asynchronous I/O, take 3

On 07/15/2018 11:46 AM, Rainer Orth wrote: Hi Jerry, Hmm, interesting. Which linux are you using? Fedora 27. Rainer Works for me. Fedora 28. Do not know for other OS's Jerry

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Jerry, > Hmm, interesting. Which linux are you using? Fedora 27. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [patch, fortran] Asynchronous I/O, take 3

On 07/15/2018 10:47 AM, Rainer Orth wrote: Hi Thomas, However, I still don't understand why you insist on the hack with putting the async_io_*.f90 tests into the libgomp testsuite. Why not just make the pthread requirement explicit with { dg-require-effective-target pthread } {

Re: [patch, fortran] Asynchronous I/O, take 3

On 07/15/2018 07:21 AM, Rainer Orth wrote: Hi Thomas, I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I put the asycn_io_*.f90 tests into libgomp.fortran because, under

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Thomas, >> However, I still don't understand why you insist on the hack with >> putting the async_io_*.f90 tests into the libgomp testsuite. Why not >> just make the pthread requirement explicit with >> >> { dg-require-effective-target pthread } >> { dg-additional-options "-pthread" } >> >>

Re: [patch, fortran] Asynchronous I/O, take 3

On 07/15/2018 04:19 AM, Thomas Koenig wrote: Hi everybody, I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I put the asycn_io_*.f90 tests into libgomp.fortran because,

Re: [PATCH][testsuite/guality] Run guality tests with Og

On Fri, Jul 13, 2018 at 01:27:25PM +0200, Richard Biener wrote: > On Fri, 13 Jul 2018, Tom de Vries wrote: > > > Hi, > > > > we advertise Og as the optimization level of choice for the standard > > edit-compile-debug cycle, but do not run the guality tests for Og with the > > default torture

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Rainer, I've now regtested the patch on i386-pc-solaris2.11 and sparc-sun-solaris2.11: no regressions and the new tests all PASS. Thanks, that is good news! However, I still don't understand why you insist on the hack with putting the async_io_*.f90 tests into the libgomp testsuite. Why

Re: [patch, fortran] Asynchronous I/O, take 3

Hi Thomas, >> I am currently testing the patch at >> https://gcc.gnu.org/ml/fortran/2018-07/msg8.html >> >> so far, so good! > >> IMO the tests should go to gfortran.dg (they pass my tests). > > I put the asycn_io_*.f90 tests into libgomp.fortran because, > under Linux, gfortran.dg does not

Re: [patch, fortran] Asynchronous I/O, take 3

Hi everybody, I am currently testing the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg8.html so far, so good! IMO the tests should go to gfortran.dg (they pass my tests). I put the asycn_io_*.f90 tests into libgomp.fortran because, under Linux, gfortran.dg does not link in

Re:we can provide you printing and packaging2018/7/15 18:54:52

Hi there I can supply you paper shopping bag ,paper box ,and hangtags. Any new requirements ,let us work together, Best Regards; Abby

Re: [PATCH] x86: Tune Skylake, Cannonlake and Icelake as Haswell

On Sat, 14 Jul 2018, H.J. Lu wrote: > Like this? Yes, this looks fine. Thanks! Gerald