On Mon, Dec 17, 2012 at 10:44:59PM -0800, Teresa Johnson wrote:
>Index: tree-ssa-loop-ivcanon.c
>===
>--- tree-ssa-loop-ivcanon.c(revision 194516)
>+++ tree-ssa-loop-ivcanon.c(working copy)
>@@ -639,22 +639,24 @@ unloop_loops (
Current GCC thumb1 has an annoying problem that always assuming far branch.
So it forces to save lr, even when unnecessarily. The most extreme case
complained by partner is:
// compiled with "-mthumb -mcpu=cortex-m0 -Os".
void foo() { for (;;); }
=>
foo:
push{lr} // Crazy!!!
.L2:
Dear Paul,
Apparently you have forgotten to commit the update for
same_type_as_1.f03.
Dominique
The following patch updates the Fortran part of the GCC 4.8 release
notes at http://gcc.gnu.org/gcc-4.8/changes.html#fortran
It adds quips for
- CLASS(*)
- The new BACKTRACE intrinsic
- A compatibility notice
I would like if someone could comment on the latter. I think it is time
to explicitly
On Wed, Dec 19, 2012 at 10:14:26PM -0800, Teresa Johnson wrote:
> Merged this pair into an #elif, but left the outer one (from the IN_LIBGCOV
> check) since it looks clearer.
>
> New patch:
>
> 2012-12-19 Teresa Johnson
> Jakub Jelinek
>
> PR gcov-profile/55734
> * gcov-
Ping?
Thomas
Hi Janus,
Oops, right. Here is the correct one.
Regards
Thomas
wrong patch attached? It contains a hunk in frontend-passes.c, which
seems totally unrelated ...
Cheers,
Janus
2012/12/15 Thomas Koenig :
Hello world,
the attached patch fixes the regression and
We checked, no significant gains or losses.
-Original Message-
From: H.J. Lu [mailto:hjl.to...@gmail.com]
Sent: Friday, December 14, 2012 1:03 AM
To: Jan Hubicka
Cc: Jakub Jelinek; Xinliang David Li; GCC Patches; Teresa Johnson;
Melik-adamyan, Areg
Subject: Re: [PATCH i386]: Enable push
The following fixes a fixup for loops when merging two basic-blocks.
We didn't handle merging two loop headers well which the following
patch addresses.
LTO bootstrapped (which was broken before this patch) and tested
on x86_64-unknown-linux-gnu, applied.
Richard.
2012-12-20 Richard Biener
On Thu, Dec 20, 2012 at 1:43 PM, Richard Biener wrote:
> --- 724,746
>
> cfg_hooks->merge_blocks (a, b);
>
> if (current_loops != NULL)
> {
> ! /* If the block we merge into is a loop header do nothing unless ...
> */
> ! if (a->loop_father->header == a)
> ! {
On Thu, 20 Dec 2012, Steven Bosscher wrote:
> On Thu, Dec 20, 2012 at 1:43 PM, Richard Biener wrote:
> > --- 724,746
> >
> > cfg_hooks->merge_blocks (a, b);
> >
> > if (current_loops != NULL)
> > {
> > ! /* If the block we merge into is a loop header do nothing unless
> >
Dear Tobias,
Could you note that class(*) is complete up to the restriction to
fixed length character values only?
Thanks
Paul
On 20 December 2012 10:55, Tobias Burnus wrote:
> The following patch updates the Fortran part of the GCC 4.8 release notes at
> http://gcc.gnu.org/gcc-4.8/changes.htm
In the PR we perform expression replacement of an FP operation
across a builtin call that sets the FP control register. This
patch restricts replacement across calls further, from allowing
all builtins to only allowing those without side-effects.
Allowing replacement over calls at all was to not
On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote:
> In the PR we perform expression replacement of an FP operation
> across a builtin call that sets the FP control register. This
> patch restricts replacement across calls further, from allowing
> all builtins to only allowing those w
On Thu, 20 Dec 2012, Jakub Jelinek wrote:
> On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote:
> > In the PR we perform expression replacement of an FP operation
> > across a builtin call that sets the FP control register. This
> > patch restricts replacement across calls further, fr
On Thu, 20 Dec 2012, Richard Biener wrote:
> On Thu, 20 Dec 2012, Jakub Jelinek wrote:
>
> > On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote:
> > > In the PR we perform expression replacement of an FP operation
> > > across a builtin call that sets the FP control register. This
>
On Thu, Dec 20, 2012 at 4:13 AM, Melik-adamyan, Areg
wrote:
> We checked, no significant gains or losses.
>
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, December 14, 2012 1:03 AM
> To: Jan Hubicka
> Cc: Jakub Jelinek; Xinliang David Li; GCC Patches; Te
On Thu, 20 Dec 2012, Richard Biener wrote:
> On Thu, 20 Dec 2012, Jakub Jelinek wrote:
>
> > On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote:
> > > In the PR we perform expression replacement of an FP operation
> > > across a builtin call that sets the FP control register. This
>
PR libstdc++/55741
* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Check for Sleep.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/c++11/thread.cc (__sleep_for): Use Sleep if available.
Tested by Kai (thanks), committed to trunk.
commit 1149c65a98
> Hi Areg,
>
> Did you mean inlined memcpy/memset are as fast as
> the ones in libc.so on both ia32 and Intel64?
I would be interested in output of the stringop script.
>
> Please keep in mind that memcpy/memset in libc.a
> may not be optimized. You must not use -static for
> linking.
In my se
> > Hi Areg,
> >
> > Did you mean inlined memcpy/memset are as fast as
> > the ones in libc.so on both ia32 and Intel64?
>
> I would be interested in output of the stringop script.
Also as far as I can remember, none of spec2k6 benchmarks is really stringop
bound. On Spec2k GCC was quite bound
On Thu, 20 Dec 2012, Richard Biener wrote:
> On Thu, 20 Dec 2012, Richard Biener wrote:
>
> > On Thu, 20 Dec 2012, Jakub Jelinek wrote:
> >
> > > On Thu, Dec 20, 2012 at 02:51:55PM +0100, Richard Biener wrote:
> > > > In the PR we perform expression replacement of an FP operation
> > > > across
On Thu, Dec 20, 2012 at 7:06 AM, Jan Hubicka wrote:
>> > Hi Areg,
>> >
>> > Did you mean inlined memcpy/memset are as fast as
>> > the ones in libc.so on both ia32 and Intel64?
>>
>> I would be interested in output of the stringop script.
>
> Also as far as I can remember, none of spec2k6 benchmar
Dear Paul,
Paul Richard Thomas wrote:
Could you note that class(*) is complete up to the restriction to fixed length
character values only?
Done. See http://gcc.gnu.org/gcc-4.8/changes.html#fortran and
http://gcc.gnu.org/wiki/GFortran#GCC4.8
I admit that the BACKTRACE announcement is sligh
Hi!
On Sat, 10 Nov 2012 10:32:07 -0800, Andrew Pinski
wrote:
> 2012-11-10 Andrew Pinski
>
> PR bootstrap/55202
> * configure.ac: Set PLUGIN_LD_SUFFIX to just "ld" if it was "ld-new"
> or "collect-ld".
> * configure: Regenerate.
> Index: configure.ac
> ===
2012-12-20 Paulo Matos
PR tree-optimization/55761
* tree-tailcall.c (process_assignment): Use build_int_cst only for
integral types,
for every other type that managed to pass all conditions use
fold_build1.
pr55761.patch
Description: pr55761.patch
On Thu, Dec 20, 2012 at 5:06 PM, Paulo Matos wrote:
> 2012-12-20 Paulo Matos
>
> PR tree-optimization/55761
> * tree-tailcall.c (process_assignment): Use build_int_cst only for
> integral types,
> for every other type that managed to pass all conditions use
> fold_build1
> On Wed, Dec 19, 2012 at 4:29 PM, Andrew Pinski wrote:
> >
> > On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote:
> > > Hi,
> > >
> > > This patch adds the supprot of atomic update the profile counters.
> > > Tested with google internal benchmarks and fdo kernel build.
> >
> > I think you should u
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 20 December 2012 16:13
> To: Paulo Matos
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Fix PR55761
>
> On Thu, Dec 20, 2012 at 5:06 PM, Paulo Matos wrote:
> > 2012-12-20 Paulo Matos
> >
> > PR
On Thu, Dec 20, 2012 at 8:20 AM, Jan Hubicka wrote:
>> On Wed, Dec 19, 2012 at 4:29 PM, Andrew Pinski wrote:
>> >
>> > On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote:
>> > > Hi,
>> > >
>> > > This patch adds the supprot of atomic update the profile counters.
>> > > Tested with google internal b
Hi!
As the following testcase shows, the !is_gimple_min_lval code would for bit
fields want to take address of those bitfields and dereference it, which of
course leads to ICEs.
As discussed with Richard on IRC, this code is not needed at all since
PR48814 fix, so there is no need to teach it abo
> I admit that the BACKTRACE announcement is slightly premature, but I assume
> that Janus will commit the patch very soon.
yes, it's only a matter of a few hours now ;)
Cheers,
Janus
On Thu, Dec 20, 2012 at 1:21 AM, Bernhard Reutner-Fischer
wrote:
Thanks for your comments. Responses inlined below, and new patch include below.
> On Mon, Dec 17, 2012 at 10:44:59PM -0800, Teresa Johnson wrote:
>>Index: tree-ssa-loop-ivcanon.c
>>==
Jakub Jelinek wrote:
>Hi!
>
>As the following testcase shows, the !is_gimple_min_lval code would for
>bit
>fields want to take address of those bitfields and dereference it,
>which of
>course leads to ICEs.
>
>As discussed with Richard on IRC, this code is not needed at all since
>PR48814 fix, so
Currently, GCC uses generic ARMv7-A tuning for Cortex-A7.
This patch adds an initial pipeline description for Cortex-A7. Details:
* integer/vfp is based on the pipeline description for Cortex-A5,
* models dual issue in limited circumstances using simple_alu_imm and
simple_alu_shift type attribute (
This was seen with the libgo installation [1], but from my point of view can
happen when the install target is called with -j >1, libtool seems to fall back
to the system libraries if the library in the install location is not available
(which is always the case if you install into an empty dir set
On Thu, Dec 20, 2012 at 10:22 AM, Matthias Klose wrote:
> This was seen with the libgo installation [1], but from my point of view can
> happen when the install target is called with -j >1, libtool seems to fall
> back
> to the system libraries if the library in the install location is not
> ava
Am 20.12.2012 20:11, schrieb Ian Lance Taylor:
> On Thu, Dec 20, 2012 at 10:22 AM, Matthias Klose wrote:
>> This was seen with the libgo installation [1], but from my point of view can
>> happen when the install target is called with -j >1, libtool seems to fall
>> back
>> to the system libraries
On Wed, Dec 19, 2012 at 5:22 PM, Rong Xu wrote:
> On Wed, Dec 19, 2012 at 5:04 PM, wrote:
>> The change in gcov-io.h is from a different patch.
>
> sorry. here is the patch for gcov-io.h:
>
> Index: gcov-io.h
> ===
> --- gcov-io.h
Attached is a new patch, which expands the documentation according to
your proposal, and uses the name BACKTRACE. I hope that both Janne and
Tobias can agree with this naming decision ...
>>>
>>> Looks fine from my side.
>>
>> Great, thanks. Janne?
>
> Yes, Ok for trunk.
Thanks agai
we have this patch primarily for getting valid profile counts. we
observe that for some high-threaded programs, we are getting poor
counter due to data racing of counter update (like counter value is
only 15% of what it supposed to be for a 10-thread program).
In general, enabling atomic updates s
On Thu, Dec 20, 2012 at 11:35 AM, Rong Xu wrote:
> we have this patch primarily for getting valid profile counts. we
> observe that for some high-threaded programs, we are getting poor
> counter due to data racing of counter update (like counter value is
> only 15% of what it supposed to be for a
It depends on the value distribution .
David
On Thu, Dec 20, 2012 at 11:30 AM, Rong Xu wrote:
> On Wed, Dec 19, 2012 at 5:22 PM, Rong Xu wrote:
>> On Wed, Dec 19, 2012 at 5:04 PM, wrote:
>>> The change in gcov-io.h is from a different patch.
>>
>> sorry. here is the patch for gcov-io.h:
>>
>
This patch started when I noticed that it's not possibly to construct
a shared_ptr from unique_ptr, then I discovered we don't
use D::pointer if it exists, and there were a number of other
non-conformance issues with our std::unique_ptr. I ended up
fixing them by implementing Geoffrey's proposed r
that's right. but there is no way to predict the pattern.
what I meant was as far as it does not introduce major slow-down in
dumping profile, I'd like to use the simpler version.
what do you think?
-Rong
On Thu, Dec 20, 2012 at 11:54 AM, Xinliang David Li wrote:
> It depends on the value distr
Am 20.12.2012 19:22, schrieb Matthias Klose:
This was seen with the libgo installation [1], but from my point of view can
happen when the install target is called with -j >1, libtool seems to fall back
to the system libraries if the library in the install location is not available
(which is alway
Paul Richard Thomas wrote:
Thanks to Tobias for coming up so quickly with class(*) bugs!
That was simple: I could mine Reinhold Bader's collection. Only the
ICE-on-invalid part of the test case is mine. Please credit him in/for
the test case.
Bootstrapped and regtested on FC17/x86_64 - OK
PING.
On Fri, 2 Nov 2012, Gerald Pfeifer wrote:
> Rainer (or others),
>
> the FAQ entry below seems obsolete to me (dates back more than a
> decade). Shall we remove it, or is there something else we still
> should document (in addition to gcc/doc/install.texi)?
>
> Gerald
>
> Index: faq.html
Revision 193063 brought in calls to fraiseexcept() into libquadmath,
which caused a build regression on Fedora 16 (BLAG 160k actually) x86_64
while building an i686-linux-gnu native toolchain.
The problem is that glibc has an extern inline definition of
fraiseexcept that is introduced by including
libmudflap emits a global initializer that registers memory ranges for
global data symbols. However, even if IPA decides not to emit a symbol
because it's unused, we'd still emit registration sequences for them in
some cases, which, in the PR testcase, would result in TOC references to
the undefin
Hi,
This patch adds support of atomic update of profiles counters. The goal is to
improve
the poor counter values for highly thread programs.
The atomic update is under a new option -fprofile-gen-atomic=
N=0: default, no atomic update
N=1: atomic update edge counters.
N=2: atomic update some of
Ahmad has helped doing some atom performance testing (ChromeOS
benchmarks) with this patch. In summary, there is no statistically
significant regression seen. There is one improvement of about +1.9%
(v8 benchmark) which looks real.
David
On Wed, Dec 12, 2012 at 9:24 AM, Xinliang David Li wrote:
On Fri, Aug 31, 2012 at 10:58:51AM -0700, Steve Ellcey wrote:
> Here is my patch to fix the bootstrap comparision failure (PR 54128) on
> MIPS. The reason for the comparision failure was a difference in
> register usage and I tracked it down to build_insn_chain which checked
> all instructions fo
52 matches
Mail list logo
