On Wed, Nov 24, 2021 at 7:25 AM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with
> -mf16c. So added define_insn extendhfsf2 and truncsfhf2 for target_f16c.
> And cleared before conversion, updated movhi_internal and
>
On Tue, Nov 23, 2021 at 4:20 PM Martin Liška wrote:
>
> On 11/23/21 14:58, Richard Biener wrote:
> > On Mon, Nov 22, 2021 at 4:07 PM Martin Liška wrote:
> >>
> >> On 11/19/21 11:00, Richard Biener wrote:
> >>> On Tue, Nov 16, 2021 at 3:40 PM Martin Liška wrote:
>
> On 11/11/21 08:15,
On Wed, Nov 24, 2021 at 6:15 AM Xionghu Luo wrote:
>
> Gentle ping and is this patch still suitable for stage 3? Thanks.
It's on my list to look at, yes. I'm worried about accuracy of profile counts
though which is why I keep pushing it back - I see the various profile count
fixes are still
On Tue, Nov 23, 2021 at 6:27 PM Eric Gallager wrote:
>
> On Fri, Nov 19, 2021 at 8:14 AM Eric Gallager wrote:
> >
> > On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer wrote:
> > >
> > > Cool, thank you!
> > >
> > > Please feel free to commit patches like this without asking for
> > > approval
>-Original Message-
>From: Kong, Lingling
>Sent: Wednesday, November 24, 2021 2:25 PM
>To: Liu, Hongtao ; gcc-patches@gcc.gnu.org
>Cc: Kong, Lingling
>Subject: RE: [PATCH] i386: vcvtph2ps and vcvtps2ph should be used to convert
>_Float16 to SFmode with -mf16c [PR 102811]
>
>Hi,
>
Hi,
vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with
-mf16c. So added define_insn extendhfsf2 and truncsfhf2 for target_f16c.
And cleared before conversion, updated movhi_internal and
ix86_can_change_mode_class.
OK for master?
gcc/ChangeLog:
PR target/102811
Gentle ping and is this patch still suitable for stage 3? Thanks.
[PATCH v7 2/2] Don't move cold code out of loop by checking bb count
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583911.html
On 2021/11/10 11:08, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/11/4 21:00,
Gentle ping, thanks.
[PATCH v3] Fix loop split incorrect count and probability
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583626.html
On 2021/11/8 14:09, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/10/27 15:44, Jan Hubicka wrote:
>>> On Wed, 27 Oct 2021, Jan Hubicka wrote:
On 2021/11/23 17:50, Jan Hubicka wrote:
>> On Tue, Nov 23, 2021 at 6:52 AM Xionghu Luo wrote:
>>>
>>> r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
>>> profile-estimate when predict_extra_loop_exits, outer loop's exit edge
>>> is marked as inner loop's extra loop exit
On 11/23/21 17:06, Marek Polacek wrote:
On Tue, Nov 23, 2021 at 02:42:12PM -0500, Jason Merrill wrote:
On 11/22/21 17:17, Marek Polacek wrote:
Here the problem is that we aren't detecting a NSDMI in C++98:
struct A {
void *x = NULL;
};
because maybe_warn_cpp0x uses input_location and
On Linux/x86_64,
30ba058f77eedfaf7a0582f5d42aff949710bce4 is the first bad commit
commit 30ba058f77eedfaf7a0582f5d42aff949710bce4
Author: Martin Sebor
Date: Tue Nov 23 15:30:29 2021 -0700
Implement -Winfinite-recursion [PR88232].
caused
FAIL: c-c++-common/attr-retain-5.c -std=gnu++14
On 10/14/21 04:26, Jakub Jelinek wrote:
Hi!
The following patch implements the C++23 Multidimensional subscript operator
P2128R6 paper.
As C++20 and older only allow a single expression in between []s (albeit
for C++20 with a deprecation warning if it is a comma expression) and even
in C++23
[Changing to Jim's new address]
On Mon, 22 Nov 2021 00:19:08 PST (-0800), s...@isrc.iscas.ac.cn wrote:
From: SiYu Wu
This patch add gcc backend support for RISC-V Scalar Cryptography
Extension (k-ext), including machine description, builtins defines and
testcases for each k-ext's subset.
A
const qualification was also missing in the free functions for
wait/wait_explicit/notify_one/notify_all. Revised patch attached.
On Tue, Nov 9, 2021 at 11:40 AM Jonathan Wakely wrote:
> On Tue, 9 Nov 2021 at 18:09, Thomas Rodgers wrote:
>
>> Revised patch attached.
>>
>
> OK for trunk and
On Fri, Nov 19, 2021 at 8:14 AM Eric Gallager wrote:
>
> On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer wrote:
> >
> > Cool, thank you!
> >
> > Please feel free to commit patches like this without asking for
> > approval (though I'm happy to review and approve).
> >
> > Gerald
> >
>
> OK thanks;
On Tue, 23 Nov 2021, Daniil Stas via Gcc-patches wrote:
> On Mon, 22 Nov 2021 20:35:03 +
> Joseph Myers wrote:
>
> > On Sun, 21 Nov 2021, Daniil Stas via Gcc-patches wrote:
> >
> > > This option is enabled by default when -Wformat option is enabled. A
> > > user can specify
On 11/23/21 12:59 PM, Jason Merrill wrote:
On 11/22/21 18:21, Marek Polacek wrote:
On Mon, Nov 22, 2021 at 04:00:56PM -0700, Martin Sebor via Gcc-patches
wrote:
While going through old -Waddress bug reports to close after
the recent improvements to the warning I came across PR 96507
that
On Tue, Nov 23, 2021 at 02:42:12PM -0500, Jason Merrill wrote:
> On 11/22/21 17:17, Marek Polacek wrote:
> > Here the problem is that we aren't detecting a NSDMI in C++98:
> >
> > struct A {
> >void *x = NULL;
> > };
> >
> > because maybe_warn_cpp0x uses input_location and that happens to
This patch updates the C++ DR table. Several older DRs are now in the
standard, and we have a few new ones.
Pushed.
---
htdocs/projects/cxx-dr-status.html | 232 -
1 file changed, 158 insertions(+), 74 deletions(-)
diff --git a/htdocs/projects/cxx-dr-status.html
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103086
* testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr
with non-empty pointer and non-empty deleter.
---
.../testsuite/libstdc++-prettyprinters/cxx11.cc | 11 +++
1
Tested x86_64-linux, pushed to trunk.
This allows tests to be skipped if the std::allocator implementation is
not __gnu_cxx::new_allocator.
The 20_util/allocator/overaligned.cc test requires either C++17 or
new_allocator, otherwise we can't guarantee to return overaligned
memory.
On 11/22/21 6:32 PM, Jeff Law wrote:
On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:
Patch 1 in the series detects a small subset of uses of pointers
made indeterminate by calls to deallocation functions like free
or C++ operator delete. To control the conditions the warnings
are
Le 23/11/2021 à 21:46, Harald Anlauf via Fortran a écrit :
Dear all,
in simplify_bound we did hit an assert when trying to simplify
LBOUND/UBOUND for arrays with allocatable or pointer attribute.
We cannot do that. Terminate simplification in that situation.
Regtested on x86_64-pc-linux-gnu.
Dear all,
in simplify_bound we did hit an assert when trying to simplify
LBOUND/UBOUND for arrays with allocatable or pointer attribute.
We cannot do that. Terminate simplification in that situation.
Regtested on x86_64-pc-linux-gnu. OK for mainline/affected branches?
Thanks,
Harald
From
On 10/29/21 11:24, Jakub Jelinek wrote:
On Tue, Oct 26, 2021 at 04:58:11PM -0400, Jason Merrill wrote:
I'm afraid I don't have a good idea where to move that diagnostic to though,
it would need to be done somewhere where we are certain we aren't in a
subexpression of immediate invocation.
On 11/23/2021 1:34 PM, Christophe Lyon wrote:
On Tue, Nov 23, 2021 at 4:41 PM Jeff Law via Gcc-patches
wrote:
On 11/23/2021 8:26 AM, Christophe LYON via Gcc-patches wrote:
> Hi!
>
> On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote:
>>
>>
>> On 11/22/2021
On Tue, Nov 23, 2021 at 09:34:04PM +0100, Christophe Lyon via Gcc-patches wrote:
> > > This patch breaks the build when the host compiler is gcc-4.8.5,
> > > because __has_cpp_attribute is not defined.
> > Sigh. I'd like to move to a more recent prereq if we could.
> >
>
> I don't know why we
On Tue, Nov 23, 2021 at 4:41 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 11/23/2021 8:26 AM, Christophe LYON via Gcc-patches wrote:
> > Hi!
> >
> > On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote:
> >>
> >>
> >> On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches
On 11/23/2021 1:08 PM, Navid Rahimi wrote:
In gimple your primary goal should be to reduce the number of
expressions that are evaluated. This patch does the opposite.
That is actually a really good point in my opinion. I am hesitant about this
patch and wanted to hear gcc-patch opinion
> In gimple your primary goal should be to reduce the number of
> expressions that are evaluated. This patch does the opposite.
That is actually a really good point in my opinion. I am hesitant about this
patch and wanted to hear gcc-patch opinion about this. Doing something like
this in IR
On 11/23/2021 12:55 PM, Navid Rahimi wrote:
Did you test Ada with this patch as that is where the "odd" boolean
types show up?
No I haven't tested Ada yet. Since it is work in progress still [WIP]. Quick
question, to prevent applying this optimization to those odd Boolean types in
Ada,
On 11/23/2021 12:42 PM, Navid Rahimi wrote:
In case of x86_64. This is the code:
src_1(bool, bool):
cmp dil, sil
setbal
ret
tgt_1(bool, bool):
xor edi, 1
mov eax, edi
and eax, esi
ret
Lets look at the
On 11/22/21 18:21, Marek Polacek wrote:
On Mon, Nov 22, 2021 at 04:00:56PM -0700, Martin Sebor via Gcc-patches wrote:
While going through old -Waddress bug reports to close after
the recent improvements to the warning I came across PR 96507
that points out that member references aren't handled.
> Did you test Ada with this patch as that is where the "odd" boolean
> types show up?
No I haven't tested Ada yet. Since it is work in progress still [WIP]. Quick
question, to prevent applying this optimization to those odd Boolean types in
Ada, there should be a check to check whether it is
On 11/19/21 12:40, Iain Sandoe wrote:
On 18 Nov 2021, at 23:42, Iain Sandoe wrote:
On 18 Nov 2021, at 22:13, Jason Merrill via Gcc-patches
wrote:
On 11/5/21 11:46, Iain Sandoe wrote:
The way in which a C++20 coroutine is specified discards any value
tree aw_r = TREE_VEC_ELT
On 11/19/21 14:25, Patrick Palka wrote:
As described in detail in the PR, in C++20 implicitly capturing 'this'
via the '=' capture default is deprecated, but in C++17 explicitly
capturing 'this' alongside a '=' capture default is ill-formed. This
means it's impossible to write a C++17 lambda
On 11/19/21 16:57, Marek Polacek wrote:
This fixes a bogus -Wuninitialized warning: there's nothing to initialize
in empty classes, so don't add them into our uninitialized set.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
PR c++/19808
gcc/cp/ChangeLog:
In case of x86_64. This is the code:
src_1(bool, bool):
cmp dil, sil
setbal
ret
tgt_1(bool, bool):
xor edi, 1
mov eax, edi
and eax, esi
ret
Lets look at the latency of the src_1:
cmp: latency of 1: (page 663, table
On 11/22/21 17:17, Marek Polacek wrote:
Here the problem is that we aren't detecting a NSDMI in C++98:
struct A {
void *x = NULL;
};
because maybe_warn_cpp0x uses input_location and that happens to point
to NULL which comes from a system header. Jakub suggested changing the
location to the
Committed as r12-5477.
On Tue, 2021-11-23 at 23:39 +0800, Xi Ruoyao via Gcc-patches wrote:
> [v2: format fix]
>
> Some distro may ship dangling symlinks in include directories, triggers
> the access failure. Skip it and continue to next header instead of
> being to panic.
>
> Restore to old
On Tue, Nov 23, 2021 at 11:15 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 11/23/2021 11:34 AM, Navid Rahimi via Gcc-patches wrote:
> > Hi GCC community,
> >
> > I wanted you take a quick look at this patch to solve this bug [1]. This is
> > the code example for the optimization [2] which does
While reviewing some other changes I noticed that this test talks
about 'sf' being static, but it wasn't actually marked as such.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Waddress-5.C: Make sf static.
---
I've reviewed all the C++ patches that have gone into GCC 12, and
documented the ones that seemed most interesting/relevant to our
users.
Additionally, I've also added links to the proposals/PRs/git commits
so that it's easier to find out more.
I've also updated our C++ DR table.
Validates,
On 11/23/2021 11:34 AM, Navid Rahimi via Gcc-patches wrote:
Hi GCC community,
I wanted you take a quick look at this patch to solve this bug [1]. This is the
code example for the optimization [2] which does include a link to proof of
each different optimization.
I think it should be
Hi!
Paul Clarke pointed out to me that I had wrongly used a compile-time check
instead of a run-time check in this executable test. This patch fixes
that. I also fixed a typo in a string that caught my eye.
Tested on powerpc64le-linux-gnu, committed as obvious.
Thanks!
Bill
2021-11-23 Bill
On 11/11/2021 2:46 PM, Martin Sebor via Gcc-patches wrote:
Attached is a v2 of the solution I posted earlier this week
with a few tweaks made after a more careful consideration of
the problem and possible false negatives and positives.
1) It avoids warning for [apparently infinitely
On 11/10/2021 9:41 AM, Maciej W. Rozycki wrote:
It's actually hunk #2 that fixes this specific ICE. The other two are
just a consequence: #3 just being a commutative variant of the same case
and #1 from observing that the rtx may now have changed if an ASHIFT too.
Are we getting into
Hi!
When a built-in function required by an overloaded function name is not
currently enabled, the diagnostic message is not as clear as it should be.
Saying that one built-in "requires" another is somewhat misleading. It is
better to explicitly state that the overloaded builtin is implemented
Hi GCC community,
I wanted you take a quick look at this patch to solve this bug [1]. This is the
code example for the optimization [2] which does include a link to proof of
each different optimization.
I think it should be possible to use simpler approach than what Andrew has used
here [3].
On 11/16/2021 10:20 PM, liuhongt via Gcc-patches wrote:
r12-5102-gfb161782545224f5 improves integer bit test on
__atomic_fetch_[or|and]_* returns only for nop_convert, .i.e.
transfrom
mask_5 = 1 << bit_4(D);
mask.0_1 = (unsigned int) mask_5;
_2 = __atomic_fetch_or_4 (a_7(D),
* Jakub Jelinek:
> On Wed, Nov 03, 2021 at 05:28:48PM +0100, Florian Weimer wrote:
>> @@ -383,12 +376,34 @@ _Unwind_IteratePhdrCallback (struct dl_phdr_info
>> *info, size_t size, void *ptr)
>> # endif
>> #endif
>>
>> - _Unwind_Ptr dbase = unw_eh_callback_data_dbase (data);
>> + return 1;
This is the second patch in the series.
Ranger uses its own API to recursively satisfy dependencies. When
range_of_stmt is called on _1482 = _1154 + _1177; it picks up the
ranges of _1154 and _1177 from it's cache. If those statements have not
been seen yet, it recursively calls
This is the first of 2 patches which will reduce the depth of the call
chain in ranger.
This patch simply splits the functionality of the routine
get_non_stale_global_range() from a single boolean return to a boolean
return and a bool reference.
This routine queries the global cache for a
On 17/11/2021 10:40, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
>
>> However the code is somewhat complex and I would like to have some feedback
>> if gcc will be willing to accept this change (I assume it would require
>> this code merge on glibc beforehand).
>
> There's a
On 11/23/21 16:20, Martin Liška wrote:
Sure, so for e.g. case 1 ... 5 we would need to create a new unswitch_predicate
with 1 <= index && index <= 5 tree predicate (and the corresponding irange
range).
Later once we unswitch on it, we should use a special unreachable_flag that will
be used for
On Tue, Nov 23, 2021 at 09:30:30PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 21:22, Jakub Jelinek wrote:
> > Evaluating __bdos in both passes is undesirable, certainly for the same
> > SSA_NAME, but even for different SSA_NAMEs, if everything is done in a
> > single pass it can easily share
On Tue, Nov 23, 2021 at 09:08:35PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 21:06, Siddhesh Poyarekar wrote:
> > On 11/23/21 20:42, Jakub Jelinek wrote:
> > > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> > > > (object_sizes_execute): Don't insert min/max for
On 11/23/2021 2:31 AM, Xi Ruoyao wrote:
On Mon, 2021-11-22 at 17:37 -0700, Jeff Law wrote:
On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
Some distro may ship dangling symlinks in include directories,
triggers
the access failure. Skip it and continue to next header instead of
On 11/23/21 21:22, Jakub Jelinek wrote:
Evaluating __bdos in both passes is undesirable, certainly for the same
SSA_NAME, but even for different SSA_NAMEs, if everything is done in a
single pass it can easily share temporaries (object sizes for SSA_NAMEs it
uses), while if some __bdos is
On Tue, Nov 23, 2021 at 09:06:49PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 20:42, Jakub Jelinek wrote:
> > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> > > (object_sizes_execute): Don't insert min/max for dynamic sizes.
> >
> > I'm worried about this.
> > I'd say
On 23/11/2021 14:16, Richard Earnshaw wrote:
>
>
> On 23/11/2021 09:37, Murray Steele wrote:
>> On 18/11/2021 15:45, Richard Earnshaw wrote:
>>
>>>
>>> This is mostly OK, but can't we reduce the number of tests somewhat? For
>>> example, I think you can merge type_redef_13.c and type_redef_14.c
[v2: format fix]
Some distro may ship dangling symlinks in include directories, triggers
the access failure. Skip it and continue to next header instead of
being to panic.
Restore to old behavior before r12-5234 but without resurrecting the
problematic getcwd() call, by using the environment
On 11/23/2021 8:26 AM, Christophe LYON via Gcc-patches wrote:
Hi!
On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote:
On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches wrote:
Let's hide [[likely]] behind a macro, to suppress warnings if the
compiler doesn't support it.
On 11/23/21 21:06, Siddhesh Poyarekar wrote:
On 11/23/21 20:42, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
(object_sizes_execute): Don't insert min/max for dynamic sizes.
I'm worried about this.
I'd say what we might want to do is in the
On Tue, Nov 23, 2021 at 04:26:19PM +0100, Christophe LYON via Gcc-patches wrote:
> Hi!
>
> On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote:
> >
> >
> > On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches wrote:
> > > Let's hide [[likely]] behind a macro, to suppress warnings if the
> > >
On 11/23/21 20:42, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
(object_sizes_execute): Don't insert min/max for dynamic sizes.
I'm worried about this.
I'd say what we might want to do is in the early pass for __bdos
compute actually __bos
Hi,
Modref tree template stores its own copy of param_moderf_max_bases, *_max_refs
and *_max_accesses values. This was done before we had per-function limits and
even back then it was bit dubious, so this patch removes it.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
Honza
Hi!
On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote:
On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches wrote:
Let's hide [[likely]] behind a macro, to suppress warnings if the
compiler doesn't support it.
Co-authored-by: Jonathan Wakely
Bootstrapped/regtested on
Adding ML back in. ☹
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, November 23, 2021 3:17 PM
> To: Tamar Christina
> Cc: Richard Earnshaw ; nd ;
> Richard Sandiford ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: RE: [PATCH]AArch64 Optimize right shift rounding
On 11/23/21 14:58, Richard Biener wrote:
On Mon, Nov 22, 2021 at 4:07 PM Martin Liška wrote:
On 11/19/21 11:00, Richard Biener wrote:
On Tue, Nov 16, 2021 at 3:40 PM Martin Liška wrote:
On 11/11/21 08:15, Richard Biener wrote:
So I'd try to do no functional change first, improving the
On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> (object_sizes_execute): Don't insert min/max for dynamic sizes.
I'm worried about this.
I'd say what we might want to do is in the early pass for __bdos
compute actually __bos (i.e. the static one) and add
On Tue, Nov 23, 2021 at 07:14:04PM +0530, Siddhesh Poyarekar wrote:
> > This feels way too risky to me. I think making some code do something
> > different between (x & OST_DYNAMIC) == 0 and == 1 is just fine,
> > it doesn't have to share everything. After all, for __bdos we actually
> > emit
On 23/11/2021 09:37, Murray Steele wrote:
On 18/11/2021 15:45, Richard Earnshaw wrote:
This is mostly OK, but can't we reduce the number of tests somewhat? For
example, I think you can merge type_redef_13.c and type_redef_14.c by writing
/* { dg-do compile } */
/* {
On Tue, Nov 23, 2021 at 07:23:01PM +0530, Siddhesh Poyarekar wrote:
> > What's the advantage of another argument and then merging it with
> > object_size_type over just passing object_size_type which will have
> > all the bits in?
>
> I kept the size bits as an internal detail, I can define them
On Mon, Nov 22, 2021 at 4:07 PM Martin Liška wrote:
>
> On 11/19/21 11:00, Richard Biener wrote:
> > On Tue, Nov 16, 2021 at 3:40 PM Martin Liška wrote:
> >>
> >> On 11/11/21 08:15, Richard Biener wrote:
> >>> So I'd try to do no functional change first, improving the costing and
> >>> setting
On 11/23/21 18:11, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:31AM +0530, Siddhesh Poyarekar wrote:
Recognize the __builtin_dynamic_object_size builtin and add paths in the
object size path to deal with it, but treat it like
__builtin_object_size for now. Also add tests to provide the
On 11/23/21 17:37, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:30AM +0530, Siddhesh Poyarekar wrote:
Use SSA names as placeholders self-referencing variables to generate
expressions for object sizes and then reduce those size expressions
to constants instead of repeatedly walking through
On 11/23/21 6:51 PM, Szabolcs Nagy wrote:
The 11/23/2021 16:32, Dan Li wrote:
On 11/3/21 8:00 PM, Szabolcs Nagy wrote:
i assume exception handling info has to change for scs to
work (to pop the shadow stack when transferring control),
so either scs must require -fno-exceptions or the eh
On 11/23/21 17:28, Jakub Jelinek wrote:
On Mon, Nov 22, 2021 at 01:32:22PM +0100, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 22, 2021 at 06:01:08PM +0530, Siddhesh Poyarekar wrote:
On 11/22/21 17:30, Siddhesh Poyarekar wrote:
So I've got patch 10/10, which handles dynamic (and
Tested powerpc64le-linux, pushed to trunk. Backports needed too.
includes , and since C++17 that
includes . If std::allocator is defined in terms of
__gnu_cxx::bitmap_allocator then you get a circular reference and
bootstrap fails when compiling src/c++17/*.cc.
libstdc++-v3/ChangeLog:
On Thu, Nov 18, 2021 at 4:18 PM Roger Sayle wrote:
>
>
> Hi Richard,
> Many thanks for the patch review.
>
> On Tue, Nov 16, 2021 at 12:38 Richard Biener wrote:
> > On Mon, Nov 15, 2021 at 2:04 PM Roger Sayle
> > wrote:
> > >
> > > This patch tidies up the code that GCC generates for simple
On Wed, Nov 10, 2021 at 12:31:31AM +0530, Siddhesh Poyarekar wrote:
> Recognize the __builtin_dynamic_object_size builtin and add paths in the
> object size path to deal with it, but treat it like
> __builtin_object_size for now. Also add tests to provide the same
> testing coverage for the new
On Wed, Nov 10, 2021 at 12:31:30AM +0530, Siddhesh Poyarekar wrote:
> Use SSA names as placeholders self-referencing variables to generate
> expressions for object sizes and then reduce those size expressions
> to constants instead of repeatedly walking through statements.
>
> This change also
On Mon, Nov 22, 2021 at 01:32:22PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 22, 2021 at 06:01:08PM +0530, Siddhesh Poyarekar wrote:
> > On 11/22/21 17:30, Siddhesh Poyarekar wrote:
> > > So I've got patch 10/10, which handles dynamic (and consequently
> > > negative) offsets. It
Le 22/11/2021 à 21:30, Bernhard Reutner-Fischer a écrit :
I'm just wondering loud if it would be more convenient to have a
unsigned hidden_arg:1 bit in let's say gfc_actual_arglist that denotes
if the argument should be const eval'ed and used before, and, most
importantly not passed to the
The 11/23/2021 16:32, Dan Li wrote:
> On 11/3/21 8:00 PM, Szabolcs Nagy wrote:
> > i assume exception handling info has to change for scs to
> > work (to pop the shadow stack when transferring control),
> > so either scs must require -fno-exceptions or the eh info
> > changes must be implemented.
This properly uses lambda_int instead of truncating the direction
vector to int which leads to false unexpected negative values.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-11-23 Richard Biener
PR tree-optimization/103361
* gimple-loop-jam.c
On Tue, 23 Nov 2021, Jakub Jelinek wrote:
> Hi!
>
> This struct copy_body_data's hook is always NULL since merge
> of the tuples branch, before that it has been shortly used by the C++
> FE during ctor/dtor cloning to chain the remapped blocks, but only
> very shortly, before
Hi!
This struct copy_body_data's hook is always NULL since merge
of the tuples branch, before that it has been shortly used by the C++
FE during ctor/dtor cloning to chain the remapped blocks, but only
very shortly, before transform_lang_insert_block was a bool and
the call to insert_block was
Hi!
We were using unshare_expr and walk_tree_without_duplicate replacement
of the placeholder vars. The OMP_CLAUSE_REDUCTION_{INIT,MERGE} can contain
other trees that need to be duplicated though, e.g. BLOCKs referenced in
BIND_EXPR(s), or local VAR_DECLs. This patch uses the inliner code to
> On Tue, Nov 23, 2021 at 6:52 AM Xionghu Luo wrote:
> >
> > r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
> > profile-estimate when predict_extra_loop_exits, outer loop's exit edge
> > is marked as inner loop's extra loop exit and set with incorrect
> > prediction, then
On Tue, Nov 23, 2021 at 8:26 AM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> testcase modref-dse-4.c and modref-dse-5.c fails on some targets because they
> depend on store merging. What really happens is that without store merging
> we produce for kill_me combined write that is ao_ref with
On Tue, Nov 23, 2021 at 6:52 AM Xionghu Luo wrote:
>
> r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
> profile-estimate when predict_extra_loop_exits, outer loop's exit edge
> is marked as inner loop's extra loop exit and set with incorrect
> prediction, then a hot inner
On 18/11/2021 15:45, Richard Earnshaw wrote:
>
> This is mostly OK, but can't we reduce the number of tests somewhat? For
> example, I think you can merge type_redef_13.c and type_redef_14.c by writing
>
> /* { dg-do compile } */
> /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> /* {
On Tue, Nov 23, 2021 at 6:30 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> This is a new version of the patch to fix PR 102216.
> Instead of doing the canonicalization inside forwprop, Richi
> mentioned we should do it inside fold_stmt_1 and that is what
> this patch does.
>
>
On Mon, 2021-11-22 at 17:37 -0700, Jeff Law wrote:
>
>
> On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
> > Some distro may ship dangling symlinks in include directories,
> > triggers
> > the access failure. Skip it and continue to next header instead of
> > being to panic.
> >
> >
On Mon, 22 Nov 2021 20:35:03 +
Joseph Myers wrote:
> On Sun, 21 Nov 2021, Daniil Stas via Gcc-patches wrote:
>
> > This option is enabled by default when -Wformat option is enabled. A
> > user can specify -Wno-format-int-precision to disable emitting
> > warnings when passing an argument of
Thanks for your review. Committed as r12-5463.
On 22/11/2021 上午 10:56, David Edelsohn wrote:
> On Wed, Nov 17, 2021 at 3:28 AM HAO CHEN GUI wrote:
>> Hi,
>>
>> The patch optimized for vec_reve builtin on rs6000. For V2DI and V2DF, it
>> is implemented by xxswapd on all targets. For V16QI,
Hi Szabolcs,
First of all, apologies for my late reply (since I just had a new baby,
I'm quite busy recently and also because I'm not familiar with C++
exception handling, it takes me some time to learn this part).
On 11/3/21 8:00 PM, Szabolcs Nagy wrote:
The 11/03/2021 00:24, Dan Li wrote:
99 matches
Mail list logo
