On 04.08.22 09:32, Tobias Burnus wrote:
Rather obvious fix and similar to PR106449.
OK for mainline and backporting (how far?). I would like to backport
it at least to GCC 12.
Now committed as obvious:
https://gcc.gnu.org/g:r13-1997-g8a16b9f983824b6b9a25275cd23b6bba8c98b800
I intent to backpo
Hi,
r10-631 had renamed rs6000_global_entry_point_needed_p to
rs6000_global_entry_point_prologue_needed_p. This is to
remove the stale function declaration.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.
I'll push this soon.
BR,
Kewen
-
gcc/Chang
Hi,
In function rs6000_init_builtins, there is a oversight that
in one target debugging hunk with TARGET_DEBUG_BUILTIN we
missed to handle enum bif_enable ENB_CELL. It's easy to
fix it by adding another if case. But considering the long
term maintainability, this patch updates it with the existi
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
Hi Haochen,
Thanks for the patch.
on 2022/8/8 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with three
> 64bit operands.
>
> Compared with last version, the main changes are:
> 1 The "maddld" pattern is reused for the low-part generation.
> 2
Hi Xionghu,
Thanks for the fix.
on 2022/8/8 11:42, Xionghu Luo wrote:
> The native RTL expression for vec_mrghw should be same for BE and LE as
> they are register and endian-independent. So both BE and LE need
> generate exactly same RTL with index [0 4 1 5] when expanding vec_mrghw
> with vec_
On Mon, 8 Aug 2022, 19:15 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On 08/08/22 15:19, Jonathan Wakely wrote:
> > On Mon, 8 Aug 2022 at 06:07, François Dumont via Libstdc++
> > wrote:
> >> Another version of this patch with just a new test case showing what
> >> wrong code
when evaluating a COND_EXPR, we need to evaluate both operands. With the
recent changes to floating point, we missed that we are accidentally
using the LHS range type for the operands.. that was fine when
everything was an irange... but no so any more.
This patch simply uses the right range ty
On Sat, Aug 06, 2022 at 03:58:13PM -0800, Jason Merrill wrote:
> On 8/6/22 11:13, Marek Polacek wrote:
> > In this PR, Jon suggested extending the -Wredundant-move warning
> > to warn when the user is moving a const object as in:
> >
> >struct T { };
> >
> >T f(const T& t)
> >{
> >
On Mon, 8 Aug 2022, Tom Honermann via Gcc-patches wrote:
> On 8/2/22 6:14 PM, Joseph Myers wrote:
> > On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
> >
> > > This patch corrects handling of UTF-8 character literals in preprocessing
> > > directives so that they are treated as unsigned
On Sat, Aug 06, 2022 at 04:02:13PM -0700, Jason Merrill wrote:
> On 8/4/22 11:46, Marek Polacek wrote:
> > In my previous patches I've been extending our std::move warnings,
> > but this tweak actually dials it down a little bit. As reported in
> > bug 89780, it's questionable to warn about expres
On Aug 1, 2022, "H.J. Lu" wrote:
> On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
>> > You may also need to do something like this bit for mvc10.c on ia32 PIE.
>> > Because the ifunc is called through an alias, AFAICT we don't even
>> > notice that the call target is (an alias to) an ifunc. G
On Sat, Aug 06, 2022 at 04:07:54PM -0700, Jason Merrill wrote:
> On 8/6/22 15:49, Jason Merrill wrote:
> > On 7/27/22 17:14, Marek Polacek wrote:
> > > We already have a warning that warns about pessimizing std::move
> > > in a return statement, when it prevents the NRVO:
> > >
> > > T fn()
> >
On Sat, Aug 06, 2022 at 03:29:05PM -0700, Jason Merrill wrote:
> On 7/26/22 14:31, Marek Polacek wrote:
> > On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote:
> > > On 7/26/22 15:03, Marek Polacek wrote:
> > > > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
> > > > co
Hi,
This patch fixes the ICE reported in PR d/106555.
The type that triggers the ICE never got completed by the semantic
analysis pass. Checking for size forces it to be done, or issue a
compile-time error.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32,
committed to mainline
On 08/08/22 15:19, Jonathan Wakely wrote:
On Mon, 8 Aug 2022 at 06:07, François Dumont via Libstdc++
wrote:
Another version of this patch with just a new test case showing what
wrong code was unnoticed previously by the _GLIBCXX_DEBUG mode.
On 04/08/22 22:56, François Dumont wrote:
This an ol
On Fri, 5 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> +Wcompare-distinct-pointer-types
> +C C++ Var(warn_compare_distinct_pointer_types) Warning Init(1)
> +Warn if pointers of distinct types are compared without a cast.
There's no implementation for C++ in this patch, so the option should
Hi,
So I've changed the approach from the RFC as suggested, moving the
bitfield lowering to the if-convert pass.
So to reiterate, ifcvt will lower COMPONENT_REF's with DECL_BIT_FIELD
field's to either BIT_FIELD_REF if they are reads or BIT_INSERT_EXPR if
they are writes, using loads and writ
On 8/2/22 6:14 PM, Joseph Myers wrote:
On Tue, 2 Aug 2022, Tom Honermann via Gcc-patches wrote:
This patch corrects handling of UTF-8 character literals in preprocessing
directives so that they are treated as unsigned types in char8_t enabled
C++ modes (C++17 with -fchar8_t or C++20 without -fn
On Wed, 13 Jul 2022 at 18:28, François Dumont via Libstdc++
wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
>
>Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace generation
> on _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the lib
> with:
>
>
On Mon, 8 Aug 2022 at 06:07, François Dumont via Libstdc++
wrote:
>
> Another version of this patch with just a new test case showing what
> wrong code was unnoticed previously by the _GLIBCXX_DEBUG mode.
>
> On 04/08/22 22:56, François Dumont wrote:
> > This an old patch I had prepared a long tim
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, June 8, 2022 3:50 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: [PATCH 2/2][AArch32] Fix 128-bit sequential consistency atomic
> oper
> -Original Message-
> From: Tamar Christina
> Sent: Monday, August 8, 2022 10:28 AM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH 1/2]AArch64 Fix 128-bit sequential consistency atomic
> operat
On Fri, Aug 5, 2022 at 2:59 PM Andre Vieira (lists) via Gcc-patches
wrote:
>
> This isn't really a 'PATCH' yet, it's something I was working on but had
> to put on hold. Feel free to re-use any bits or trash all of it if you'd
> like.
@@ -10264,6 +10264,44 @@ expand_expr_real_2 (sepops ops, rtx t
On Mon, Aug 8, 2022 at 11:06 AM Roger Sayle wrote:
>
>
> This patch resolves both PR tree-optimization/64992 and PR
> tree-optimization/98956 which are missed optimization enhancement
> request, for which Andrew Pinski already has a proposed solution
> (related to a fix for PR tree-optimization/98
On Mon, Aug 8, 2022 at 10:07 AM Roger Sayle wrote:
>
>
> This patch resolves PR tree-optimization/71343, a missed-optimization
> enhancement request where GCC fails to see that (a<<2)+(b<<2) == a*4+b*4.
> This requires two related (sets of) optimizations to be added to match.pd.
>
> The first is t
On Sun, Aug 7, 2022 at 9:08 PM Roger Sayle wrote:
>
>
> Following my middle-end patch for PR tree-optimization/94026, I'd promised
> Jeff Law that I'd clean up the dead-code in fold-const.cc now that these
> optimizations are handled in match.pd. Alas, I discovered things aren't
> quite that simp
Richard Earnshaw writes:
[...]
> +(define_insn "pac_nop"
> + [(set (reg:SI IP_REGNUM)
> + (unspec:SI [(reg:SI SP_REGNUM) (reg:SI LR_REGNUM)]
> + UNSPEC_PAC_NOP))]
> + "TARGET_THUMB2"
> + "pac\t%|ip, %|lr, %|sp"
> + [(set_attr "length" "2")])
>
> This pattern is missing
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Tuesday, July 12, 2022 2:46 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH 1/2]AArch64 Fix 128-bit sequential consistency atomic
> operatio
I've revisited the earlier two workarounds for dwarf2out_register_external_die
getting duplicate entries. It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SC
This patch resolves both PR tree-optimization/64992 and PR
tree-optimization/98956 which are missed optimization enhancement
request, for which Andrew Pinski already has a proposed solution
(related to a fix for PR tree-optimization/98954). Yesterday,
I proposed an alternate improved patch for PR
On Mon, Aug 1, 2022 at 5:17 AM Prathamesh Kulkarni
wrote:
>
> On Thu, 21 Jul 2022 at 12:21, Richard Biener
> wrote:
> >
> > On Wed, Jul 20, 2022 at 5:36 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 18 Jul 2022 at 11:57, Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Jul 15, 2022
This patch resolves PR tree-optimization/71343, a missed-optimization
enhancement request where GCC fails to see that (a<<2)+(b<<2) == a*4+b*4.
This requires two related (sets of) optimizations to be added to match.pd.
The first is that (X< 4*X" will always evaluate to false.
This patch has been
On Mon, Aug 8, 2022 at 5:38 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> For compound literals empty struct stores are not removed as they go down a
> different path of the gimplifier; trying to optimize the init constructor.
> This fixes the problem by not adding the gimple a
On Fri, Aug 5, 2022 at 8:36 PM Roger Sayle wrote:
>
>
> This patch moves the lowering of 128-bit V1TImode shifts and rotations by
> constant bit counts to sequences of SSE operations from the RTL expansion
> pass to the pre-reload split pass. Postponing this splitting of shifts
> and rotates enab
On Sun, Aug 7, 2022 at 7:04 PM Roger Sayle wrote:
>
>
> This is a resubmission of my patch from June to fix some forms of
> inefficient
> register allocation using an additional peephole2 in i386.md.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596064.html
>
> Since the original, a number
36 matches
Mail list logo
