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 error.
> >Generall
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 vector.
--- gcc/sh
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) -> exp(log(C)*x) if C > 0 optimization
>> >breaks so
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
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 from
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 crash_signal
> /scratch/jmy
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 sectio
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 vowing
for ATTR_leng
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
>showed
>a lot of the
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 wrote:
>> >> On February 10, 2018 12:
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 keeping more lexical
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.
>
> Maybe what we should h
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 INTENT
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
> > wrote:
> >> >Hi!
> >> >
> >> >
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
20170425 https://www.youtube.
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 compiler error: Segmentation fau
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 and
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
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,
> popcount(x>>3
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, ple
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% success rate with getting patch
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
which
22 matches
Mail list logo
