[committed] hppa: Fix conflict between -pg and -mlong-call options

The attached patch fixes an oversight in hppa_profile_hook. We need to mark the SYMBOL_REF for _mcount as a function label. When the -mlong-call option is used, the call to _mcount is converted to an indirect call. In that case, we need the function pointer to point to a procedure label

Re: [PATCH] Character length cleanup for Coarray Fortran library

On Sat, Feb 10, 2018 at 9:34 PM, Damian Rouson wrote: > > I’ll try applying the patch and testing it. As such, I'm sure that will fail as the patch changes the coarray API and thus needs corresponding changes on the OpenCoarrays side as well. > I have about a 50%

Re: [PATCH] Character length cleanup for Coarray Fortran library

  I’ll try applying the patch and testing it.  I have about a 50% success rate with getting patches to apply cleanly.  Is this available on an svn or git branch that I can just checkout rather than attempting to apply the patch?  I find that process to be much more reliable.  Going forward,

Re: [PATCH] POPCOUNT folding optimizations

On 02/09/2018 05:42 AM, Roger Sayle wrote: > > The following patch implements a number of __builtin_popcount related > optimizations. > (i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to > x!=0. > (ii) popcount(x&1) can be simplified to x&1, and for unsigned x, >

Re: [LVU] use asm .loc and get gas to compute views on the side

On Sat, Feb 10, 2018 at 09:26:47AM -0700, Jeff Law wrote: > > I think it makes sense to disable them by default if gas doesn't support > > them with that ability to override the auto detection by a configure > > switch (get the GCC generated ones). The patch looks too heavy for this > > stage and

Re: [Patch, fortran] PR 56691 - [OOP] Allocatable array: wrong offset when passing to CLASS dummy

Hi All, Committed as revision 257550. In the course of testing this patch, Dominique found some problems that turned out to be due to revision r257065. These latter were encapsulated in PR84155, which was fixed 257356. However, Richi pointed me in the direction of a much cleaner fix to this PR

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/10/2018 05:34 AM, Alexandre Oliva wrote: > Hi, Joseph, > > On Feb 9, 2018, Joseph Myers wrote: > >> sh4 is: >> during RTL pass: final >> In file included from strtof_l.c:45: >> strtod_l.c: In function 'strtof_l_internal': >> strtod_l.c:1769:1: internal

Re: [PATCH] Fix handling of arguments in statement functions

On Sat, Feb 10, 2018 at 09:46:57AM -0800, Steve Kargl wrote: > > PR fortran/35299 > * gfortran.dg/statement_function_3.f: New test. This patch should be credited to FX. I've added 2018-02-10 Francois-Xavier Coudert to the ChangeLog entry. -- Steve

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

On Sat, Feb 10, 2018 at 12:29:42PM +0100, Richard Biener wrote: > On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek > wrote: > >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote: > >> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek >

[PATCH] Fix handling of arguments in statement functions

All, The attach patch address 3 issues with statement functions. First, a dummy argument in a statement function declarations acquires only its type and type parameters from the containing scope. All attributes should be ignores. The first fix for PR fortran/84276 disables a check for the

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On 02/10/2018 06:04 AM, Alexandre Oliva wrote: > On Feb 10, 2018, Jeff Law wrote: > >> So given what I've seen in the ARM port, I don't think we can generally >> assume any insn advances the PC. > > Ugh. Thanks, I'll adjust the patch to not count call insns, I guess. > >

Re: [LVU] use asm .loc and get gas to compute views on the side

On 02/10/2018 06:34 AM, Richard Biener wrote: > On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva > wrote: >> I was shocked when you, richi, reported huge debug info growth after >> the >> LVU and IEPM patches went in. At first, I suspected IEPM, due to >> possibly

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

On February 10, 2018 3:26:46 PM GMT+01:00, Jakub Jelinek wrote: >On Sat, Feb 10, 2018 at 12:29:42PM +0100, Richard Biener wrote: >> On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek > wrote: >> >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener

Re: [LVU] use asm .loc and get gas to compute views on the side

On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva wrote: >I was shocked when you, richi, reported huge debug info growth after >the >LVU and IEPM patches went in. At first, I suspected IEPM, due to >possibly keeping more lexical blocks around, but my investigation

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Feb 10, 2018, Jeff Law wrote: > So given what I've seen in the ARM port, I don't think we can generally > assume any insn advances the PC. Ugh. Thanks, I'll adjust the patch to not count call insns, I guess. Maybe what we should have is some target hook that, instead of

[LVU] use asm .loc and get gas to compute views on the side

I was shocked when you, richi, reported huge debug info growth after the LVU and IEPM patches went in. At first, I suspected IEPM, due to possibly keeping more lexical blocks around, but my investigation showed a lot of the growth was actually due to switching from asm-generated line number

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

Hi, Joseph, On Feb 9, 2018, Joseph Myers wrote: > sh4 is: > during RTL pass: final > In file included from strtof_l.c:45: > strtod_l.c: In function 'strtof_l_internal': > strtod_l.c:1769:1: internal compiler error: Segmentation fault > } > ^ > 0xb98e3f

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

On Sat, Feb 10, 2018 at 12:37:38AM +0100, Jakub Jelinek wrote: > Hi! > > Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization > breaks some package (Marek should know which), as it has 7ulp error. > Generally one should be prepared for some errors with -ffast-math. I reduced it

Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

Hi Janus, As Steve said, welcome back! I hope that you will post the news of this fix and the correction of the testcases on clf. Talking of which, have you posted the problems that others have found as PRs? It was one of my long deferred tasks to make a start on validating the testsuite and to

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek wrote: >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote: >> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek > wrote: >> >Hi! >> > >> >Apparently the new pow(C,x) ->

[committed] Fix shrink-wrapping memory leak (PR rtl-optimization/84308)

Hi! We are leaking the todo vector in spread_components, fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2018-02-10 Jakub Jelinek PR rtl-optimization/84308 * shrink-wrap.c (spread_components): Release todo

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote: > On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek > wrote: > >Hi! > > > >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization > >breaks some package (Marek should know which), as it has 7ulp