Trivial patch to fix the inversion of -fconcepts and -fno-concepts.
2014-10-18 Braden Obrzut
* gcc/c-family/c.opt (flag_concepts): The concepts option was inverted.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c1645ea..c165477 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-fa
On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka wrote:
>>
>> The virtual functions will be emitted in some modules, right? If they
>> are hot, they will be included with the auxiliary modules. Note that
>> LIPO indirect call profile will point to the comdat copy that is
>> picked by the linker in the
Hi Honza,
As David says, we will do some more experiments with the change you
suggest and speculative devirtualization, but we needed to make this
change in part to get an internal release out. One of the issues was a
recent change to cp/decl2.c to make virtual function decls needed
under flag_dev
On Sat, Oct 18, 2014 at 4:26 PM, Jan Hubicka wrote:
>> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
>> >> The difference in instrumentation runtime is huge -- as topn profiler
>> >> is pretty expensive to run.
>> >>
>> >> With FDO, it is probably better to make early inlining more aggressi
On Sat, Oct 18, 2014 at 4:26 PM, Jan Hubicka wrote:
>> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
>> >> The difference in instrumentation runtime is huge -- as topn profiler
>> >> is pretty expensive to run.
>> >>
>> >> With FDO, it is probably better to make early inlining more aggressi
> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
> >> The difference in instrumentation runtime is huge -- as topn profiler
> >> is pretty expensive to run.
> >>
> >> With FDO, it is probably better to make early inlining more aggressive
> >> in order to get more context sensitive profiling.
>
> The virtual functions will be emitted in some modules, right? If they
> are hot, they will be included with the auxiliary modules. Note that
> LIPO indirect call profile will point to the comdat copy that is
> picked by the linker in the instrumentation build, so it guarantees to
> exist.
If
On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
>> The difference in instrumentation runtime is huge -- as topn profiler
>> is pretty expensive to run.
>>
>> With FDO, it is probably better to make early inlining more aggressive
>> in order to get more context sensitive profiling.
>
> I agree
On Sat, Oct 18, 2014 at 3:23 PM, Jan Hubicka wrote:
>> Devirtualization needs more tuning to be usable internally. We have
>> seen 1.6% size increase on average, but unnoticable performance
>
> Does that happen with -fno-devirtualize-speculatively?
>
Not sure -- I will do some experiment.
>> imp
> The difference in instrumentation runtime is huge -- as topn profiler
> is pretty expensive to run.
>
> With FDO, it is probably better to make early inlining more aggressive
> in order to get more context sensitive profiling.
I agree with that, I just would like to understand where increasing
> Devirtualization needs more tuning to be usable internally. We have
> seen 1.6% size increase on average, but unnoticable performance
Does that happen with -fno-devirtualize-speculatively?
> improvement with this option on. I would rather use the size budget to
> make inliner more aggressive :)
On Thu, 10 Jul 2014, Richard Biener wrote:
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse wrote:
we currently drop clobbers on variables whose address is not taken anymore.
However, rewrite_stmt has code to replace them with an SSA_NAME with a
default definition (an uninitialized variable), an
ok.
David
On Sat, Oct 18, 2014 at 9:26 AM, Teresa Johnson wrote:
> Increasing the number of early inliner iterations from 1 to 2 enables more
> indirect calls to be promoted/inlined before instrumentation. This in turn
> reduces the instrumentation overhead, particularly for more expensive indir
The difference in instrumentation runtime is huge -- as topn profiler
is pretty expensive to run.
With FDO, it is probably better to make early inlining more aggressive
in order to get more context sensitive profiling.
David
On Sat, Oct 18, 2014 at 10:05 AM, Jan Hubicka wrote:
>> Increasing the
Devirtualization needs more tuning to be usable internally. We have
seen 1.6% size increase on average, but unnoticable performance
improvement with this option on. I would rather use the size budget to
make inliner more aggressive :)
For instrumentation build, some of our builds will reach the bu
ok.
David
On Sat, Oct 18, 2014 at 9:25 AM, Teresa Johnson wrote:
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
>
> Patch attached. Passes internal te
gcc/Changelog:
2014-10-18 Krzesimir Nowak
* diagnostic.c (diagnostic_report_from): New function. It prints
one line from include chain.
(diagnostic_report_current_module): Use the above function.
gcc/testsuite/ChangeLog:
2014-10-18 Krzesimir Nowak
* c-c++-common/cpp/pr42014.c: New.
* c-c
Hello.
This is my first patch for GCC. I already started a paperwork for
copyright assignment (sent an email to fsf-records at gnu org) -
waiting for response.
So, about this patch - it basically removes column printing from "In
file included from ..." lines, as the column information always
retu
On 18 October 2014 23:18, Ville Voutilainen wrote:
> Tested on Linux-x64.
>
> 2014-10-18 Ville Voutilainen
>
> Implement more Library Fundamentals v1 variable templates for
> type traits.
> * include/Makefile.am: Add ratio, chrono and system_error.
> * include/experimental/chron
Tested on Linux-x64.
2014-10-18 Ville Voutilainen
Implement more Library Fundamentals v1 variable templates for
type traits.
* include/Makefile.am: Add ratio, chrono and system_error.
* include/experimental/chrono: New.
* include/experimental/ratio: Likewise.
* include/
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
OK, with profile instrumentation (that you seem to try to minimize) i can see
how you get noticeably more
> Increasing the number of early inliner iterations from 1 to 2 enables more
> indirect calls to be promoted/inlined before instrumentation. This in turn
> reduces the instrumentation overhead, particularly for more expensive indirect
> call topn profiling.
How much difference you get here? One po
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
Can you refer bit more on the problem? Full devirtualization should not
increase code size, speculative d
On 18 October 2014 02:13, Joseph S. Myers wrote:
> On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote:
>
>> Can we make "possibly in some other cases" more concrete? Otherwise,
>
> Cases where something about the code is not defined by the base standard,
> but a diagnostic is not required. -pedantic
Increasing the number of early inliner iterations from 1 to 2 enables more
indirect calls to be promoted/inlined before instrumentation. This in turn
reduces the instrumentation overhead, particularly for more expensive indirect
call topn profiling.
Passes internal testing and regression tests. Ok
Disabling devirtualization reduces code size, both for instrumentation (because
many more virtual functions are kept longer and therefore instrumented) and for
normal optimization.
Patch attached. Passes internal testing and regression tests. Ok for google/4_9?
Thanks,
Teresa
--
Teresa Johnson
The attached change removes support for the hppa -mjump-in-delay
option. The option was
already overridden on PA 8000 and later hardware, and on ELF targets.
It causes problems
for debuggers and adds significant overhead for very little gain. I'm
looking at updating the
fast indirect call
On Sat, Oct 18, 2014 at 05:38:16PM +0300, Janne Blomqvist wrote:
>
> Benoit Lodej reported on the fortran list a bug in find_addr2line,
> namely that if the PATH string does not end in ":", the last PATH
> element is not tested. Rather than fixing the current implementation,
> I rewrote it in a si
Hi,
Benoit Lodej reported on the fortran list a bug in find_addr2line,
namely that if the PATH string does not end in ":", the last PATH
element is not tested. Rather than fixing the current implementation,
I rewrote it in a simpler fashion by using the strtok_r function.
Tested that it fixes the
I didn't start the paper work yet. I'll get started on it.
For the changelog entry, I didn't change anything to that function,
but mklog gives an entry for it.
I think it's because the new function is added after it and at the end
if the file.
On Sat, Oct 18, 2014 at 3:15 PM, Marc Glisse wrote:
On Sat, 18 Oct 2014, Anthony Brandon wrote:
I'm a new contributor
Welcome!
I don't yet have a copyright assignment
Did you start the paperwork?
* filename_cmp.c (filename_eq): No change.
I didn't look at the patch, but that's a confusing ChangeLog entry. Did
you change somethin
Never mind about functions.texi. I figured out how to do it.
Here is the new diff and changelog.
libiberty/ChangeLog:
2014-10-18 Anthony Brandon
* filename_cmp.c (filename_eq): No change.
(canonical_filename_eq): New function to check if file names
are the same.
* func
On Thu, 2014-10-16 at 23:42 +0200, Oleg Endo wrote:
> Hi,
>
> Attached patch fixes warnings in some of the SH test cases which are
> caused by the switch to GNU11. Committed as r216351.
>
... and another one, which I missed. Committed as r216426.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
Hello,
this time, +-* for 128 bit integer vectors. I am using an unsigned type so
the compiler knows that we expect wrapping. I don't know why Intel's
description of mullo insists that the multiplication is signed, that only
matters for the high part...
Next parts (waiting for approval for t
Hi,
The gcc.dg/attr-isr.c test case is pretty much SH specific. Thus, moved
to gcc.target/sh via svn mv, hence no patch. Committed as r216425.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
* gcc.dg/attr-isr.c: Move SH specific test to ...
* gcc.target/sh/attr-isr.c: ... here.
Hi,
As discussed in the PR, this adds two new SH built-in functions
__builtin_sh_get_fpscr __builtin_sh_set_fpscr. Tested on r216173 with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m4/-ml,-m4/-mb}"
and no new failures. Committed as r216424.
Cheers,
Oleg
gcc/ChangeLog:
PR t
Hi,
I'm a new contributor and I don't yet have a copyright assignment or
commit access.
I took the patch from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 and made some
changes.
This patch makes GCC check if any of the input files is the same as
the output file specified with -o, and if so gi
On Fri, 17 Oct 2014, Marc Glisse wrote:
Thanks. I am testing the updated patch tonight and I'll commit. I am planning
on making a branch: ^/branches/x86-intrinsics-ext if noone complains about
the name.
Committed patch attached.
--
Marc GlisseIndex: gcc/testsuite/gcc.target/i386/intrinsics_o
On Mon, 6 Oct 2014, François Dumont wrote:
* testsuite/25_algorithms/push_heap/complexity.cc: New.
This test is randomly failing in about 1% to 2% of cases.
--
Marc Glisse
39 matches
Mail list logo
