On October 26, 2019 6:35:43 AM GMT+02:00, Alexandre Oliva
wrote:
>This was first submitted many years ago
>https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
>
>The command line option -fcallgraph-info is added and makes the
>compiler generate another output file (xxx.ci) for each compilati
Ping...
On 10/18/19 3:19 PM, Bernd Edlinger wrote:
> Ping...
>
> for the c++ FE and testsuite changes in the updated patch
> here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00916.html
>
>
> Thanks
> Bernd.
>
>
>
>
> On 10/12/19 8:10 PM, Bernd Edlinger wrote:
>> On 10/11/19 6:31 PM, Jaso
Hi, Richi,
On Oct 26, 2019, Richard Biener wrote:
> How does it relate to the LTO-dump utility we have now which can in
> theory provide a more complete view?
Erhm... Not at all, AFAICT. The only vague resemblance I see is in the
presence of the word "callgraph" in the description of what bot
Georg-Johann Lay wrote:
> Wilco Dijkstra schrieb:
>> GCC currently defaults to -fcommon. As discussed in the PR, this is an
>> ancient
>> C feature which is not conforming with the latest C standards. On many
>> targets
>> this means global variable accesses have a codesize and performance pe
On Sat, Oct 26, 2019 at 12:21:15PM +0100, Iain Sandoe wrote:
> Georg-Johann Lay wrote:
> > Wilco Dijkstra schrieb:
> >> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> >> ancient
> >> C feature which is not conforming with the latest C standards. On many
> >> targets
>
> BTW: Please also note that there is no need to use or operand
> mode override in scalar insn templates for intel asm dialect when
> operand already has a scalar mode.
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01868.html
This patch is to remove redundant when operand already has a scalar mo
Richard Biener writes:
> We have to check each operand for being in a pattern, not just the
> first when avoiding build from scalars (we could possibly handle
> the special case of some of them being the pattern stmt root, but
> that would be a followup improvement).
>
> Bootstrap & regtest runnin
When we have -fstack-limit-symbol with sysv we can end up with a non-
existing instruction (you cannot add an immediate to register 0). Fix
this by using register 11 instead. It might be used for something else
already though, so save and restore its value around this. In
optimizing compiles the
On Sat, Oct 26, 2019 at 3:27 PM Hongtao Liu wrote:
>
> > BTW: Please also note that there is no need to use or operand
> > mode override in scalar insn templates for intel asm dialect when
> > operand already has a scalar mode.
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01868.html
>
> This p
On 10/25/19 9:47 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global variable accesses have a codesize and performance penalty.
> This
On 10/25/19 11:39 AM, Craig Blackmore wrote:
> This patch aims to allow more load/store instructions to be compressed by
> replacing a load/store of 'base register + large offset' with a new load/store
> of 'new base + small offset'. If the new base gets stored in a compressed
> register, then the
On 10/25/19 3:10 AM, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2019-10-25 Martin Liska
>
> * ggc-common.c: Move Leak to the first column.
OK
jeff
On 10/25/19 7:21 AM, Martin Liška wrote:
> Hi.
>
> And there's one more integer overflow fix.
>
> Martin
>
>
> 0001-Fix-unsigned-type-overflow-in-memory-report.patch
>
> From 35c22704dc705508672f19b09e6d1b94bd956535 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 25 Oct 2019 15:09:
On 10/25/19 3:32 AM, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2019-10-25 Martin Liska
>
> * cgraphunit.c (symbol_table::compile): Pass
> title as dump_memory_report argument.
> * toplev.c (dump_memory_report): New argument.
> (finalize): Pass new argument.
> *
On 10/25/19 6:24 AM, Jozef Lawrynowicz wrote:
> Where possible, it is always desirable to use 430 format instructions when
> compiling for the 430X ISA and the large memory model. 430 instructions have
> reduced code size and faster execution time.
>
> This patch recognizes a couple of new pattern
As far as I can tell, this is a 6-regression as well - ***sigh***
The patch is fundamentally very simple. Symbols that were marked with
the fn_result_spec flag that really were module parameters were having
the wrong name mangling applied to them. The rest of the patch is a
tidy up.
Regtested on
On Sat, Oct 26, 2019 at 07:39:55PM +0100, Paul Richard Thomas wrote:
> As far as I can tell, this is a 6-regression as well - ***sigh***
>
> The patch is fundamentally very simple. Symbols that were marked with
> the fn_result_spec flag that really were module parameters were having
> the wrong na
On Sat, 2019-10-26 at 12:21 -0600, Jeff Law wrote:
> On 10/25/19 11:39 AM, Craig Blackmore wrote:
> > This patch aims to allow more load/store instructions to be
> > compressed by
> > replacing a load/store of 'base register + large offset' with a new
> > load/store
> > of 'new base + small offset'
On 10/23/19 3:07 PM, Tobias Burnus wrote:
With the trunk, there are three issues:
(a) With bind(C), the callee side handles deallocation with intent(out).
This should produce the code:
if (cfi.0 != 0B)
{
__builtin_free (cfi.0);
cfi.0 = 0B;
}
This fails as cfi.0
Hi Steve,
Thanks for the heads up. I'll get on to it right away.
Regards
Paul
On Sat, 26 Oct 2019 at 20:04, Steve Kargl
wrote:
>
> On Sat, Oct 26, 2019 at 07:39:55PM +0100, Paul Richard Thomas wrote:
> > As far as I can tell, this is a 6-regression as well - ***sigh***
> >
> > The patch is fun
I don't know enough to say whether the legitimize_address hook is
sufficient for the intended purpose, but I am sure that RISC-V's
concerns are not unique: other GCC targets have to cope with
offset-size constraints that are coupled to register-allocation
constraints.
On Sat, Oct 26, 2019 at 11:2
On 10/26/19 1:10 PM, Oleg Endo wrote:
> On Sat, 2019-10-26 at 12:21 -0600, Jeff Law wrote:
>> On 10/25/19 11:39 AM, Craig Blackmore wrote:
>>> This patch aims to allow more load/store instructions to be
>>> compressed by
>>> replacing a load/store of 'base register + large offset' with a new
>>> lo
On 10/26/19 1:33 PM, Andrew Waterman wrote:
> I don't know enough to say whether the legitimize_address hook is
> sufficient for the intended purpose, but I am sure that RISC-V's
> concerns are not unique: other GCC targets have to cope with
> offset-size constraints that are coupled to register-al
Committed to trunk.
Dave
--
2019-10-26 John David Anglin
* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.
Index: config/abi/post/hppa-linux-gnu/baseline_symbols.txt
===
--- config/abi/post/hppa-linux-gnu/
On 04.10.19 19:04, Jeff Law wrote:
On 9/30/19 12:47 PM, Andreas Tobler wrote:
On 30.09.19 20:37, Kamil Rytarowski wrote:
On 30.09.2019 19:47, Jakub Jelinek wrote:
On Mon, Sep 30, 2019 at 07:41:00PM +0200, Andreas Tobler wrote:
--- fprintf-2.c (revision 276292)
+++ fprintf-2.c (working c
Turns out we have three instances of the same link in our libstdc++
documentation -- do we really need all of those?
In any case, I went ahead and applied this straightforward update.
Gerald
2019-10-26 Gerald Pfeifer
* doc/xml/manual/codecvt.xml: Switch pubs.opengroup.org to https.
Hi,
when ipa-icf produces wrapper/alias it needs to also update summaries to
represent the new function body. W/o this propagation across new
wrappers does not work.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
* ipa-icf.c (sem_function::merge): Update function summaries.
On 25/10/2019 16:47, Wilco Dijkstra wrote:
GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards.
The PR references C99/C11 6.9p5, but that is not a constraint. Any
violation merely renders the behaviour of
On Sat, 2019-10-26 at 14:04 -0600, Jeff Law wrote:
> On 10/26/19 1:33 PM, Andrew Waterman wrote:
> > I don't know enough to say whether the legitimize_address hook is
> > sufficient for the intended purpose, but I am sure that RISC-V's
> > concerns are not unique: other GCC targets have to cope wit
29 matches
Mail list logo
