The code is dead and can be removed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* genautomata.cc (create_composed_state): Remove dead code.
* graphite-poly.cc (print_pdrs): Likewise.
* lto-w
The patch is pre-approved by Honza.
Cheers,
Martin
gcc/ChangeLog:
* value-prof.cc (stream_out_histogram_value): Remove sanity
checking.
---
gcc/value-prof.cc | 12
1 file changed, 12 deletions(-)
diff --git a/gcc/value-prof.cc b/gcc/value-prof.cc
index c240a186336.
On 5/5/22 12:52, Alexander Monakov wrote:
> Feels a bit weird to ask, but before entertaining such an API extension,
> can we step back and understand the v3 variant of get_symbols? It is not
> documented, and from what little I saw I did not get the "motivation" for
> its existence (what it is doi
The patch unifies names used for profiling.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
* tree-profile.cc (gimple_gen_ic_profiler): Prefix names with
PROF_*.
(gimple_gen_time_profiler): Likewise.
---
gcc/tree-prof
On 5/5/22 14:51, Pedro Alves wrote:
> On 2022-05-05 13:41, Martin Liška wrote:
>> On 5/5/22 14:29, Richard Biener wrote:
>>> Can we then use static_assert (...) instead and remove the
>>> macro?
>>
>> Oh yes, we can ;)
>>
>>> Do we have C co
On 5/5/22 14:58, Iain Buclaw wrote:
> This D front-end change doesn't look right to me, besides the slight
Hello.
Sorry, I've re-read the patch and fixed some places where the macro usage
was wrong.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
MartinFrom 8d9630e411321c
On 5/5/22 17:31, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 09:06:45AM -0400, Marek Polacek via Gcc-patches wrote:
>> On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote:
>>> Some parts of the compiler already define:
>>> #define likely(cond)
On 5/5/22 15:49, Jan Hubicka wrote:
> Hi,
>> The patch simplifies usage of the profile_{count,probability} types.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>
> The reason I intentionally did not add * and / to the original API was
> t
On 5/5/22 14:24, Richard Biener wrote:
> Hmm, but we support C++11 host compilers that are not GCC but
> may claim to be, with GCC_VERSION 4.2.x for example. Are we sure
> all those liars implement what we guard with the version checks?
Do you know about any real example of such a liars?
Why shou
On 5/5/22 18:21, H.J. Lu wrote:
> On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>>
>> On 5/5/22 01:07, H.J. Lu wrote:
>>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>>>>
>>>> Hello.
>>>>
>>>> I'm going to
On 5/5/22 20:35, Andrew Pinski wrote:
> GCC_VERSION will be 0 if GCC is not being used.
> So you need to audit these better really.
Ah, I see. So it basically means all the non-GCC conditional
code needs to remain and I can replace
#if GCC_VERSION >= X_Y_Z with #ifdef __GNUC__
Am I correct?
Marti
On 5/6/22 08:19, Richard Biener wrote:
> But I would have been fine with LIKELY as well.
Ok, so let's go with this version.
I'm going to install the patch.
Martin
On 5/5/22 15:08, Richard Biener wrote:
> On Thu, May 5, 2022 at 2:41 PM Martin Liška wrote:
>>
>> On 5/5/22 14:29, Richard Biener wrote:
>>> Can we then use static_assert (...) instead and remove the
>>> macro?
>>
>> Oh yes, we can ;)
>>
&g
Do not allow strange option format:
-msmall-data-limit= 11.
For -output-pch we need to use Separate syntax as lang spec
rules automatically append a space.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR target/105355
gcc/
Hi.
The header files limits.h are syslimits.h are not a product of fix-includes,
so let's install it to a proper include location.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* Makefile.in: Install limits.h
Right now, fixinclude takes about 11 seconds on my machine, where
it reads 130MB of header files.
The number of fixed headers is negligible without any significant
change.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
fixincludes/Ch
CCing mold's author.
On 5/6/22 16:46, Alexander Monakov wrote:
>
>
> On Thu, 5 May 2022, Martin Liška wrote:
>
>> On 5/5/22 12:52, Alexander Monakov wrote:
>>> Feels a bit weird to ask, but before entertaining such an API extension,
>>> can we s
On 5/9/22 12:21, Arnaud Charlet wrote:
> So I don't see how your patch can work, can you clarify?
Sorry for that, fixed in the updated version.
Cheers,
MartinFrom 5ad8fe059d3419446647eadf8785c768b647d15b Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 13 Jan 2022 18:46:26 +0100
Subject: [
On 5/5/22 14:27, Richard Biener wrote:
> You'd have to ask the sourceware side as well (binutils), but for sure
> either the
Yes, I've asked and they proved that.
> guarding #if should be removed or the #else path should contain an #error.
All right, I'm going to install the version w/o #if.
Ma
On 5/9/22 13:58, Richard Biener wrote:
> The patch would have been a lot smaller if you kept it Joined only?
Yes, but the langspec rules append a space for some reason:
$ ./xgcc -B. /tmp/1.h -ox.h.pch --save-temps --verbose
...
./cc1 -fpreprocessed x.h.pch-1.i ... --output-pch= x.h.pch
Martin
On 5/9/22 14:26, Richard Biener wrote:
> On Mon, May 9, 2022 at 2:16 PM Martin Liška wrote:
>>
>> On 5/9/22 13:58, Richard Biener wrote:
>>> The patch would have been a lot smaller if you kept it Joined only?
>>
>> Yes, but the langspec rules append a spac
Hi.
As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
Let's removed its usafe in libiberty.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/ChangeLog:
* hashtab.h (HTAB_EMPTY_ENTRY): Use void
Similarly in GCC itself. I've built all FEs with the patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ada/ChangeLog:
* gcc-interface/decl.cc (compare_field_bitpos): Use void *
instead PTR.
* gcc-inter
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
@Alan: Are you fine with the change from binutils/gdb perspective?
Thanks,
Martin
include/ChangeLog:
* ansidecl.h (PTR): Remove.
(const): Likewise.
(volatile): Likewise.
(signed): Likewise.
--
gcov_info::n_functions type is initialized by generated
code in build_info_type:
/* n_functions */
field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
get_gcov_unsigned_t ());
It uses gcov_unsigned_t, but the struct definition in libgcov.h uses
unsigned type. That br
On 5/9/22 09:37, Jakub Jelinek via Gcc-patches wrote:
> On Mon, May 09, 2022 at 01:02:07PM +0530, Siddhesh Poyarekar wrote:
>> On 07/02/2022 17:37, Jakub Jelinek wrote:
>>> On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote:
Use __builtin_dynamic_object_size to get object sizes
On 5/10/22 11:55, Andreas Schwab wrote:
> The header line should probably be changed since it's no longer about
> ANSI or traditional C.
>
Sure, updated in v2.
MartinFrom 9359921cd29f9ec4f7536f49160ad54b74e0214a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 10 May 2022 09:47:08 +0200
S
On 5/10/22 15:50, Eric Gallager wrote:
> Hi, please preserve existing style when possible when making this
> replacement; ISTR there are some tools (like for generating
> libiberty's documentation) that depend on the return type being on a
> separate line... If all of the relevant Makefile targets
On 5/10/22 16:09, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> @Alan: Are you fine with the change from binutils/gdb perspective?
>
> I'm fine if th
Pushed as obvious.
Martin
libiberty/ChangeLog:
* random.c: Remove 'define PTR'.
---
libiberty/random.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libiberty/random.c b/libiberty/random.c
index be8819dd6b8..cd0b7399e73 100644
--- a/libiberty/random.c
+++ b/libiberty/random.c
@@
On 5/10/22 16:20, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:
>
>> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
>
>> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>>else if (htab->free_with_arg_f != NULL)
&
On 5/9/22 14:03, Richard Biener wrote:
> On Thu, May 5, 2022 at 4:30 PM Martin Liška wrote:
>>
>> On 5/5/22 14:58, Iain Buclaw wrote:
>>> This D front-end change doesn't look right to me, besides the slight
>>
>> Hello.
>>
>> Sorry, I'
On 5/2/22 09:57, Martin Liška wrote:
> On 3/31/22 09:01, Martin Liška wrote:
>> @Jakub: May I install it once stage1 opens?
>
> May I please ping this?
>
> Thanks,
> Martin
>
>>
>> Cheers,
>> Martin
>>
>> On 1/3/22 12:43, Martin Liška
On 1/13/22 12:00, Tomas Kalibera wrote:
> On 1/13/22 10:40 AM, Martin Liška wrote:
>
> [...]
>> Apart from that, I support the patch (I cannot approve it). Note we're now
>> approaching
>> stage4 and this is definitelly a stage1 material (opens after GCC 12.1.0
On 5/11/22 10:27, Uros Bizjak wrote:
> On Wed, May 11, 2022 at 10:19 AM Martin Liška wrote:
>>
>> On 5/2/22 09:57, Martin Liška wrote:
>>> On 3/31/22 09:01, Martin Liška wrote:
>>>> @Jakub: May I install it once stage1 opens?
>>>
>>&
On 5/9/22 23:14, Joseph Myers wrote:
> If you add a new configure option, it should be documented in
> install.texi.
>
Both comments fixed in the v2.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
MartinFrom 58d431568d6b6163dd9cdc920239f17
On 5/11/22 13:00, Rainer Orth wrote:
> Hi Martin,
>
>> On 5/9/22 23:14, Joseph Myers wrote:
>>> If you add a new configure option, it should be documented in
>>> install.texi.
>>>
>>
>> Both comments fixed in the v2.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
Ready to be installed?
Thanks,
Martin
PR other/105527
gcc/ChangeLog:
* doc/install.texi: Document the configure option --with-zstd.
---
gcc/doc/install.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 10bfceffceb..1d
On 5/11/22 13:31, Rainer Orth wrote:
> Hi Martin,
>
Subject: [PATCH] configure: add --disable-fix-includes
>>>
>>> As I've mentioned before, I believe, the command is called fixincludes
>>> in current gcc docs, and the option should reflect that, not introduce a
>>> name used nowhere else.
>>
On 5/11/22 13:50, Richard Biener wrote:
> Should that use @option{}? --with-gmp etc. just refer to
> @option{--with-gmp-include} without PATH/*, so please drop that here, too.
Sure, adjusted and pushed.
Martin
In case where we have 2 equally good candidates like
-ftrivial-auto-var-init=
-Wtrivial-auto-var-init
for -ftrivial-auto-var-init, we should take the candidate that
has a difference in trailing sign symbol.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be instal
On 5/11/22 14:48, Andreas Schwab wrote:
> On Mai 11 2022, Martin Liška wrote:
>
>> @Joseph: Can you please help me why --disable-$foo disables building $foo
>> folder during the build?
>
> # Handle --disable- generically.
> for dir in $configdirs $build_configd
On 5/11/22 20:49, David Malcolm wrote:
> On Wed, 2022-05-11 at 16:49 +0200, Martin Liška wrote:
>> In case where we have 2 equally good candidates like
>> -ftrivial-auto-var-init=
>> -Wtrivial-auto-var-init
>>
>> for -ftrivial-auto-var-init, we should take the cand
Fixes:
opts-global.cc:75:15: runtime error: store to address 0x0bc9be70 with
insufficient space for an object of type 'char'
which happens when mask == 0, len == 0 and we allocate zero elements.
Eventually, result[0] is called which triggers the UBSAN.
It's newly discovered after the Siddhesh
It's the warning I see every time I build GCC:
In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
from /home/marxin/Programming/gcc/gcc/expmed.cc:26:
In function ‘poly_uint16 mode_to_bytes(machine_mode)’,
inlined from ‘typename if_nonpoly::type
GET_MODE_S
On 5/11/22 10:17, Martin Liška wrote:
> On 5/9/22 14:03, Richard Biener wrote:
>> On Thu, May 5, 2022 at 4:30 PM Martin Liška wrote:
>>>
>>> On 5/5/22 14:58, Iain Buclaw wrote:
>>>> This D front-end change doesn't look right to me, besides the slight
&g
On 5/12/22 09:00, Richard Biener via Gcc-patches wrote:
> On Wed, May 11, 2022 at 5:10 PM Bruno Haible wrote:
>>
>> The patch that was so far added for documenting --with-zstd is pretty
>> minimal:
>> - it refers to undocumented options --with-zstd-include and
>> --with-zstd-lib;
>> - it s
On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
>>
>> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
>> is useful if bugs are discovered in old versions that you by definition
>> cannot
>> fix but can apply workarounds to. Note the actual compiler used might still
>
n
> ("GCC 12.1").
I've implemented first version of the patch, please take a look.
Note there's a bit name collision of api_version with:
/* The version of the API specification. */
enum ld_plugin_api_version
{
LD_PLUGIN_API_VERSION = 1
};
@Rui: Am I correct that you
On 5/16/22 17:16, Alexander Monakov wrote:
> On Mon, 16 May 2022, Martin Liška wrote:
>
>> I've implemented first version of the patch, please take a look.
>
> I'll comment on the patch, feel free to inform me when I should back off
> with forcing my opinion
On 5/16/22 12:32, Richard Biener wrote:
> It only seems to happen with your host compiler though? The set of
Yes, happens with just released 12.1 as host compiler:
g++ -fcf-protection -fno-PIE -c -g -O2 -DIN_GCC -fPIC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno
On 5/17/22 21:03, Tobias Burnus wrote:
> This patch broke offloading – fixed by reverting the patch for
> {gcn,nvptx}/mkoffload.cc – and committed as obvious. Changing a C-code
> generating string without telling the then called C compiler about the
> macro won't fly. See attachment for
> r13-569-
Similarly to cgraph_nodes, it may happen that body_removed is set
during merging of symbols.
PR ipa/105600
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* ipa-icf.cc (sem_item_optimizer::filter_remove
On 5/16/22 10:56, Richard Sandiford wrote:
> Martin Liška writes:
>> It's the warning I see every time I build GCC:
>>
>> In file included from /home/marxin/Programming/gcc/gcc/coretypes.h:478,
>> from /home/marxin/Programming/gcc/gcc/expmed.cc
On 5/19/22 17:02, Jan Hubicka wrote:
>> Similarly to cgraph_nodes, it may happen that body_removed is set
>> during merging of symbols.
>>
>> PR ipa/105600
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>> gcc/C
On 5/23/22 09:56, Iain Buclaw wrote:
> Excerpts from Martin Liška's message of Mai 11, 2022 10:17 am:
>> On 5/9/22 14:03, Richard Biener wrote:
>>> On Thu, May 5, 2022 at 4:30 PM Martin Liška wrote:
>>>>
>>>> On 5/5/22 14:58, Iain Buclaw wrote:
>
On 5/23/22 21:28, David Malcolm via Gcc-patches wrote:
> gcc/ChangeLog:
> * ipa-cp.cc: Add "final" and "override" to call_summary_base vfunc
> implementations, removing redundant "virtual" as appropriate.
> * ipa-fnsummary.h: Likewise.
> * ipa-modref.cc: Likewise.
> *
PING^1
On 5/12/22 09:10, Martin Liška wrote:
> On 5/11/22 20:49, David Malcolm wrote:
>> On Wed, 2022-05-11 at 16:49 +0200, Martin Liška wrote:
>>> In case where we have 2 equally good candidates like
>>> -ftrivial-auto-var-init=
>>> -Wtrivial-auto-var-init
>
PING^1
On 5/5/22 09:55, Martin Liška wrote:
> On 5/4/22 21:38, Iain Sandoe wrote:
>>
>>
>>> On 4 May 2022, at 20:14, Martin Liška wrote:
>>>
>>> Right now, when a \$x escape sequence occures, the
>>> next character after $x is skipped, which is
On 5/16/22 11:27, Martin Liška wrote:
> On 5/12/22 09:00, Richard Biener via Gcc-patches wrote:
>> On Wed, May 11, 2022 at 5:10 PM Bruno Haible wrote:
>>>
>>> The patch that was so far added for documenting --with-zstd is pretty
>>> minimal:
>>> -
PING^1
On 5/5/22 20:15, Martin Liška wrote:
> On 5/5/22 15:49, Jan Hubicka wrote:
>> Hi,
>>> The patch simplifies usage of the profile_{count,probability} types.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
And link it from changes.html.
---
htdocs/gcc-13/changes.html| 2 --
htdocs/gcc-13/porting_to.html | 28
2 files changed, 28 insertions(+), 2 deletions(-)
create mode 100644 htdocs/gcc-13/porting_to.html
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/ch
On 5/20/22 14:42, Alexandre Oliva wrote:
> On May 11, 2022, Martin Liška wrote:
>
>> Ready to be installed?
>
> Hmm... I don't like that --disable-fixincludes would still configure,
> build and even install fixincludes. This would be surprising, given
> that
On 5/9/22 11:02, Martin Liška wrote:
> |Ready to be installed?|
This patch should be replaced with:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595495.html
Martin
Ready to be installed?
Thanks,
Martin
---
htdocs/gcc-13/changes.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 6c5b2a37..f7f6866d 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -47,6 +47,9 @@
On 5/24/22 16:33, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Tue, 24 May 2022, Martin Liška wrote:
>> +AddressSanitizer defaults to
>> detect_stack_use_after_return=1 on Linux target.
>
> did you mean targets, or really just target?
>
> (And Linux or G
On 10/21/19 5:32 PM, Qing Zhao wrote:
> Please let me know whether this patch is reasonable or not.
The patch is fine. Please add PR entry to the ChangeLog and
install the patch.
Thanks,
Martin
The patch fixes a cppcheck where we have potentially
uninitialized struct field.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-10-23 Martin Liska
PR middle-end/81669
* fibonacci_heap.h (fibona
On 9/2/19 10:56 AM, Martin Liška wrote:
> Hi.
>
> There are 2 more patches that I've just tested.
>
> Martin
Hi.
There are 2 more patches that I've just tested.
Martin
>From e1299829fce26b60105e09e2c6e60d8b998a566b Mon Sep 17 00:00:00 2001
From: jakub
Date: Fri
On 10/23/19 10:02 PM, Jan Hubicka wrote:
>> Hi,
>> this patch orders symbols where we copy sections to match the order
>> of files in the command line. This optimizes streaming process since we
>> are not opening and closing files randomly and also we read them more
>> sequentially. This saves so
Hello.
There are 2 more places that need to be handled similarly
to not do out of bounds access.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From b6698f326fa4625aca6b2fa65824f5aed8b331df Mon Sep 17 00:00:00 2001
From: Martin Liska
omparison diff in the code handling shadow-stack cleanup
> during exception unwinding.
>
> I just thought I'd answer these questions below to see if there's
> anything I extra could to do to make reviewing easier.
I welcome that approach.
>
> On 23/09/19 09:02, Martin Li
Hello.
For the symbol/call summary we don't expect that it will be streamed
for PCH purpose. So that, I would like to mark all gt_pch_nx functions
with gcc_unreachable.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2
Hi.
I'm fixing one obvious issue in dump_tree_statistics.
I'm going to install the patch.
Martin
gcc/ChangeLog:
2019-10-25 Martin Liska
* tree.c (dump_tree_statistics): Use sorted index 'j' and not 'i'.
---
gcc/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Hi.
And there's one more integer overflow fix.
Martin
>From 35c22704dc705508672f19b09e6d1b94bd956535 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 25 Oct 2019 15:09:32 +0200
Subject: [PATCH] Fix unsigned type overflow in memory report.
gcc/ChangeLog:
2019-10-25 Martin Liska
* ggc
On 9/29/19 11:05 PM, Jeff Law wrote:
> On 9/11/19 1:09 PM, Richard Sandiford wrote:
>> cselib_invalidate_regno is a no-op if REG_VALUES (i) is null,
>> so we can check that first. Then, if we know what mode the register
>> currently has, we can check whether it's clobbered in that mode.
>>
>> Usin
Hi.
The patch is about {symbol,edge}_summary simplification
where ::release function is removed. Instead of it, one
should use either delete operand (for heap summaries),
or explicitly call destructor and ggc_free.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to b
On 10/22/19 1:09 PM, Martin Liška wrote:
> @Honza: PING^1
>
> On 9/18/19 12:14 PM, Martin Liška wrote:
>> On 9/11/19 1:38 PM, Martin Liška wrote:
>>> The inline_clone manipulation happens in cgraph_node::find_replacement where
>>> we manipulate the clone_of.
On 8/9/19 2:51 PM, Martin Liška wrote:
> On 8/9/19 2:13 PM, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 9 Aug 2019, Richard Biener wrote:
>>
>>> Of course I'm still afraid that the other code exists for a reason
>>> (tuning/hack/whatever...).
&
Hi.
There's updated version that puts back vec_free to destructors.
It's necessary to properly release memory.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
From 8faffc371e5cc3610f18ff1e65f7f14af397233a Mon Sep 17 00:00:00 2001
From:
Hi.
The pass passes memory allocation location to underlying
hash_map (and vec).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-10-29 Martin Liska
* symbol-summary.h (function_summary): Pass memory lo
On 10/29/19 3:24 PM, Jan Hubicka wrote:
>> gcc/cgraph.c | 14 ++
>> gcc/cgraphclones.c | 5 +
>> gcc/ipa-fnsummary.c | 2 +-
>> gcc/ipa-hsa.c| 2 +-
>> gcc/ipa-icf.c| 2 +-
Hi.
After a discussion with Honza, he recommended to install the patch set
(which should be completely approved) without the last missing piece:
[PATCH 2/9] operand_equal_p: add support for FIELD_DECL
He's going to write a function that will compare two access paths.
I've retested the whole patch
Hi.
There's a small code refactoring.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
From dc92c8c3e31887b23ef419bc60e3c1607d0e9e53 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 30 Oct 2019 12:50:51 +0100
Subject: [PATCH] Com
On 10/30/19 11:23 PM, Jeff Law wrote:
> On 10/30/19 4:06 PM, Joseph Myers wrote:
>> On Wed, 30 Oct 2019, Joseph Myers wrote:
>>
>>> This appears to have broken the build for Arm.
>>
>> And probably bfin and c6x as well, based on grep, but my bot only covers
>> glibc targets so doesn't test those.
On 10/31/19 2:01 PM, Martin Liška wrote:
> Hi.
>
> Based on the discussion with Honza and Richard I'm sending a proposal
> for conversion of param machinery into the existing option machinery.
> Our motivation for the change is to provide per function param values,
> simil
On 10/31/19 2:16 PM, Martin Liška wrote:
> On 10/31/19 2:01 PM, Martin Liška wrote:
>> Hi.
>>
>> Based on the discussion with Honza and Richard I'm sending a proposal
>> for conversion of param machinery into the existing option machinery.
>> Our motiv
Hi.
This is one another dead code removal.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-10-31 Martin Liska
* ipa-icf-gimple.c (func_checker::compare_tree_ssa_label): Remove.
* ipa-i
Hi.
operand_equal_p can properly handle situation where we have a CONSTRUCTOR
where indices are NULL:
if (!operand_equal_p (c0->value, c1->value, flags)
/* In GIMPLE the indexes can be either NULL or matching i.
Double check this so we won't ge
On 11/1/19 10:51 PM, Jeff Law wrote:
On 10/31/19 10:01 AM, Martin Liška wrote:
Hi.
operand_equal_p can properly handle situation where we have a CONSTRUCTOR
where indices are NULL:
if (!operand_equal_p (c0->value, c1->value, flags)
/* In GIMPLE the index
On 11/4/19 3:12 PM, Jan Hubicka wrote:
Martin, do you know why this flag was introduced?
Hi.
The flag is used in IPA CP:
call_summary
class edge_clone_summary
{
...
cgraph_edge *prev_clone;
cgraph_edge *next_clone;
}
Apparently, IPA CP links all clones in one linked link. If you disabl
On 11/4/19 4:24 PM, Jeff Law wrote:
On 11/4/19 6:36 AM, Richard Biener wrote:
On Mon, Nov 4, 2019 at 2:35 PM Richard Biener
wrote:
On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote:
On 11/1/19 10:51 PM, Jeff Law wrote:
On 10/31/19 10:01 AM, Martin Liška wrote:
Hi.
operand_equal_p can
Hi.
The patch installed as r277614 is not exactly 1:1 to the previous
revision, but I forgot to remove hashing of FIELD_DECL. The tree type
is not handled in operand_equal_p.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install it as obvious.
Thanks,
Marti
On 11/4/19 8:09 PM, Jan Hubicka wrote:
On 11/4/19 3:12 PM, Jan Hubicka wrote:
Martin, do you know why this flag was introduced?
Hi.
The flag is used in IPA CP:
call_summary
class edge_clone_summary
{
...
cgraph_edge *prev_clone;
cgraph_edge *next_clone;
}
I see, so it is there to c
On 11/5/19 11:36 AM, Jan Hubicka wrote:
Hi,
this patch adds object allocators to manage IPA summaries. This reduces
malloc overhead and fragmentation. I now get peak memory use 7.5GB instead
of 10GB for firefox WPA because reduced fragmentation leads to less COWs after
forks.
That sounds promi
On 11/5/19 11:45 AM, Martin Liška wrote:
Please rename allocator to m_allocator.
You were faster and installed that patch.
Thus I'm sending the adjustment.
Martin
>From 6edd5d8c4afb0451aaaf05ba857435219b31814d Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 5 Nov 2019 11:50:
On 11/5/19 12:01 PM, Jan Hubicka wrote:
On 11/5/19 11:36 AM, Jan Hubicka wrote:
Hi,
this patch adds object allocators to manage IPA summaries. This reduces
malloc overhead and fragmentation. I now get peak memory use 7.5GB instead
of 10GB for firefox WPA because reduced fragmentation leads to l
Hi.
It's a small refactoring patch that I've just tested.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-11-05 Martin Liska
* symbol-summary.h: Use ggc_delete.
---
gcc/symbol-summary.h | 10
On 11/5/19 1:23 PM, Jakub Jelinek wrote:
On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote:
libsanitizer/ChangeLog:
2019-11-05 Martin Liska
* all source files: Merge from upstream r375507.
---
libsanitizer/BlocksRuntime/Block.h| 59 +
libsanitizer/Blocks
On 11/5/19 3:48 PM, Jan Hubicka wrote:
stringpool.c:63 (alloc_node)47M: 2.3%0 :
0.0%0 : 0.0%0 : 0.0% 1217k
ipa-prop.c:4480 (ipa_read_edge_info)51M: 2.4%0 :
0.0% 260k: 0.0% 404k: 0.3% 531k
701 - 800 of 5360 matches
Mail list logo
