Hi David.
> Change several places in the eBPF backend dealing with overloaded
> built-in functions to consistently use the enum bpf_builtins type,
> rather than variously using integer constants or booleans. The result is
> eaiser to read and extend.
>
> Tested on bpf-unknown-none, no known regr
> On 8 Nov 2022, at 07:36, Sam James wrote:
>
>
>
>> On 8 Nov 2022, at 07:34, Eric Botcazou wrote:
>>
>>> I build GCC regularly from the weekly snapshots
>>> and so the decompression time adds up.
>>
>> But is very largely dwarfed by the build time of the compiler, isn't it?
>>
>
> It
> On 8 Nov 2022, at 07:33, Xi Ruoyao wrote:
>
> On Tue, 2022-11-08 at 07:14 +, Sam James via Gcc-patches wrote:
>> 1. This should speed up decompression for folks, as parallel xz
>>creates a different archive which can be decompressed in parallel.
>>
>>Note that this different meth
> On 8 Nov 2022, at 07:34, Eric Botcazou wrote:
>
>> I build GCC regularly from the weekly snapshots
>> and so the decompression time adds up.
>
> But is very largely dwarfed by the build time of the compiler, isn't it?
>
It is. It's no big deal if the patch isn't accepted, it's just ver
>I build GCC regularly from the weekly snapshots
>and so the decompression time adds up.
But is very largely dwarfed by the build time of the compiler, isn't it?
--
Eric Botcazou
On Tue, 2022-11-08 at 07:14 +, Sam James via Gcc-patches wrote:
> 1. This should speed up decompression for folks, as parallel xz
> creates a different archive which can be decompressed in parallel.
>
> Note that this different method is enabled by default in a new
> xz release coming
1. This should speed up decompression for folks, as parallel xz
creates a different archive which can be decompressed in parallel.
Note that this different method is enabled by default in a new
xz release coming shortly anyway (>= 5.3.3_alpha1).
I build GCC regularly from the weekly s
The patch in
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599755.html was
corrupted. I am resending the cleaner version as patch v2. Thank you!
gcc/ChangeLog:
Michael Collison
* config/riscv/iterators.md (RINT): Additional iterators.
(rint_pattern): Additional
Richard Biener writes:
> On Tue, 1 Nov 2022, Jiufu Guo wrote:
>
>> Segher Boessenkool writes:
>>
>> > On Mon, Oct 31, 2022 at 04:13:38PM -0600, Jeff Law wrote:
>> >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
>> >> >We know that for struct variable assignment, memory copy may be used.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/authors.xml: Update the blurb listing my doc
contributions.
---
libstdc++-v3/doc/xml/authors.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/doc/xml/authors.xml b/libstdc++-v3/do
PDF output checked on Fedora 36. Pushed to trunk.
-- >8 --
This fixes a spurious comma before the list of authors in the PDF
version of the libstdc++ manual.
Also fix the commented-out examples which should show not
.
libstdc++-v3/ChangeLog:
* doc/xml/authors.xml: Remove empty author
I'd like to "ping" the C frontend parts of this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604739.html
FWIW I've just posted the socket patch that I referred to, here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605281.html
which depends on this patch.
Thanks
Da
On Mon, Nov 7, 2022 at 10:25 PM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Nov 2, 2022 at 4:37 AM Hongyu Wang wrote:
> >
> > Hi, this is the updated patch of
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604345.html,
> > which uses targetm.loop_unroll_adjust as gate to enable
This patch generalizes the analyzer's file descriptor state machine
so that it tracks the states of sockets.
It adds two new warnings relating to misuses of socket APIs:
* -Wanalyzer-fd-phase-mismatch (e.g. calling 'accept' on a socket
before calling 'listen' on it)
* -Wanalyzer-fd-type-mismatch (
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3770-g3d2d04cda493fb.
gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc
(region_model::impl_call_errno_location): New.
* region-model-manager.cc
(region_model_manager::region_mo
Tweak analyzer handling of strchr, so that we show the
when 'strchr' returns non-NULL
message for that execution path.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3768-g55e042407ef307.
gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (region
This makes some followup code much cleaner.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3769-gbe9fdbda1cbcd6.
gcc/analyzer/ChangeLog:
* call-info.cc (success_call_info::get_desc): Delete.
(failed_call_info::get_desc): Likewise.
(su
Hi Hongtao,
I backported this patch to gcc-12 release.
gcc/ChangeLog:
* config/i386/driver-i386.cc (host_detect_local_cpu):
Move sapphirerapids out of AVX512_VP2INTERSECT.
* config/i386/i386.h: Remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS
* doc/invoke.tex
Hi,
After prologue and epilogue generation, the judgement on whether
one memory access onto stack frame may trap or not could change,
since we get more exact stack information by now.
As PR90259 shows, some memory access becomes impossible to trap
any more after prologue and epilogue generation,
> On Sun, Nov 6, 2022 at 2:00 PM Kong, Lingling via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> > Hi
> >
> > The patch is to add flag -mprefer-remote-atomic to control whether to
> generate raoint insn for atomic operations.
> > Ok for trunk?
>
> Please note TARGET_AVOID_MFENCE tuning flag, int
> Kevin: Looks like this got corrupted, possibly from copy/paste into
> gmail. I resurrect it, but there's a floating-point test failure in
> gfortran. Looks like it predates this, but I'm trying to bisect it to
> at least have a root cause before just ignoring it. I've got this
> floating aroun
I've committed this further fix for a syntax error as obvious.
libstdc++: Fix syntax error in old-glibc case in floating_from_chars.cc
[PR107562]
PR libstdc++/107562
* src/c++17/floating_from_chars.cc (from_chars_impl): Fix syntax
error.
diff --git a/libstdc++-v3/src/c++
Memory attribute auto detection will check operand 2 for type sselog,
and check operand 1 for type sselog1. For below 2 insns, there's no
operand 2. Change type to sselog1.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/107540
* c
During VRP block walk, global ranges are "finalized" during the walk.
The statement will never be revisited, so the global becomes unchanging.
we add inferred ranges when operands of a statement imply further value
restrictions. The most common of these is a de-reference of a pointer
implies
On 10/27/22 13:16, Ben Boeckel wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 18 ++
libcpp/internal.h | 2 ++
3 fi
On 10/27/22 13:16, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/libcpp/ChangeLog b/l
On 11/3/22 11:06, Torbjorn SVENSSON wrote:
On 2022-11-03 15:17, Nathan Sidwell wrote:
On 10/28/22 05:15, Torbjörn SVENSSON wrote:
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A
On 10/28/22 10:42, Marek Polacek wrote:
Two things here:
1) when we're pointing out that std::move on a constant object is
redundant, don't say "in return statement" when we aren't in a
return statement;
2) suppress the warning when the std::move call was dependent, because
removing
On Mon, 7 Nov 2022 at 22:49, Jason Merrill wrote:
>
> On 11/7/22 12:04, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 21:56, Jonathan Wakely wrote:
> >>
> >> On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote:
> >>>
> >>> Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the
Change several places in the eBPF backend dealing with overloaded
built-in functions to consistently use the enum bpf_builtins type,
rather than variously using integer constants or booleans. The result is
eaiser to read and extend.
Tested on bpf-unknown-none, no known regressions.
OK to push?
Th
On 11/7/22 12:04, Jonathan Wakely wrote:
On Mon, 7 Nov 2022 at 21:56, Jonathan Wakely wrote:
On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the library
test failure?
-- >8 --
This paper is resolving the problem of well
On Linux/x86_64,
3bff15c1c9fb3eb0bb042717e072476ec2d6d88c is the first bad commit
commit 3bff15c1c9fb3eb0bb042717e072476ec2d6d88c
Author: Aldy Hernandez
Date: Mon Nov 7 08:40:12 2022 +0100
[range-op] Restrict division by power of 2 optimization to positive numbers.
caused
FAIL: gcc.dg/tr
Commit 068baae1864 "bpf: add preserve_field_info builtin" factored out
some repeated code to a new function maybe_make_core_relo (), but missed
using it in one place. Clean that up.
Regtested on bpf-unknown-none, pushed as obvious.
gcc/
* config/bpf/bpf.cc (handle_attr_preserve): Use may
On Mon, 7 Nov 2022 at 19:13, Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 05:48:42PM +, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 16:11, Joseph Myers wrote:
> > >
> > > On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> > >
> > > > APIs. So that one can build gcc against o
On Thu, 03 Nov 2022 15:23:28 PDT (-0700), j...@ventanamicro.com wrote:
On 11/2/22 18:26, Palmer Dabbelt wrote:
I also tried to remove that restriction but it looks like it can't
work because we can't create
pseudo-registers during shrink wrapping and shrink wrapping can't
work either.
I beli
On Mon, 7 Nov 2022 at 21:56, Jonathan Wakely wrote:
>
> On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote:
> >
> > Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the
> > library
> > test failure?
> >
> > -- >8 --
> >
> > This paper is resolving the problem of well-formed C++1
On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the
> library
> test failure?
>
> -- >8 --
>
> This paper is resolving the problem of well-formed C++17 code becoming
> ambiguous in C++20 due to asymmetrical operator== being
Dear all,
Am 04.11.22 um 10:53 schrieb Mikael Morin:
Le 03/11/2022 à 23:03, Harald Anlauf a écrit :
I've spent some time not only staring at create_function_arglist,
but trying several variations handling the declared hidden parms,
and applying the necessary adjustments to gfc_get_function_type
Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the library
test failure?
-- >8 --
This paper is resolving the problem of well-formed C++17 code becoming
ambiguous in C++20 due to asymmetrical operator== being compared with itself
in reverse. I had previously implemented a ti
On 2022-11-07 04:46, Max Filippov wrote:
gcc/
* ira-color.cc (update_costs_from_allocno): Check that allocno
is in the consideration_allocno_bitmap before dereferencing
ALLOCNO_COLOR_DATA (allocno).
---
This fixes the invalid memory access, but I'm not sure if that's
suf
On Mon, Nov 7, 2022 at 8:59 PM Aldy Hernandez wrote:
>
> For unsigned numbers, multiplication by X, where X is a power of 2 is
> [0,0][X,+INF].
>
> This patch causes a regression to g++.dg/pr71488.C where
> -Wstringop-overflow gets the same IL as before, but better ranges
> cause it to issue a bog
On Mon, Oct 24, 2022 at 11:28 PM Richard Biener
wrote:
>
> On Mon, Oct 24, 2022 at 10:02 PM H.J. Lu wrote:
> >
> > On Mon, Oct 24, 2022 at 12:12 AM Richard Biener
> > wrote:
> > >
> > > On Fri, Oct 21, 2022 at 6:18 PM H.J. Lu wrote:
> > > >
> > > > On Fri, Oct 21, 2022 at 2:33 AM Richard Biener
For unsigned numbers, multiplication by X, where X is a power of 2 is
[0,0][X,+INF].
This patch causes a regression to g++.dg/pr71488.C where
-Wstringop-overflow gets the same IL as before, but better ranges
cause it to issue a bogus warning. I will create a PR with some
notes.
No discernible ch
On Mon, Nov 07, 2022 at 05:48:42PM +, Jonathan Wakely wrote:
> On Mon, 7 Nov 2022 at 16:11, Joseph Myers wrote:
> >
> > On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> >
> > > APIs. So that one can build gcc against older glibc and then compile
> > > user programs on newer glibc, t
On Thu, 03 Nov 2022 12:11:31 PDT (-0700), christoph.muell...@vrull.eu wrote:
On Wed, Nov 2, 2022 at 7:12 PM Palmer Dabbelt wrote:
On Wed, 02 Nov 2022 10:19:15 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> Could you add some test cases?
Also documentation, and ideally some sort of spec for wha
The docs say we take ISA strings, but that's never really been the case:
at a bare minimum we've required lower case strings, but there's
generally been some subtle differences as well in things like version
handling and such. We talked about removing the lower case requirement
in the last GNU too
I found some additional cases when working on the demangler. May as
well check their mangling. Since I managed to confuse myself.
nathan
--
Nathan SidwellFrom 51d567d4d15e78b42d2ca83f229c98fff2aec9fa Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 7 Nov 2022 11:08:21 -0500
Subject: [
On Mon, 7 Nov 2022, Jonathan Wakely wrote:
> This seems to "fix" it (not sure if it's right though):
>
> #ifndef _GLIBCXX_HAVE_FLOAT128_MATH
> extern "C" _Float128 __strtof128(const char*, char**)
> __attribute__((__weak__));
> #endif
> extern "C" _Float128 __strtof128(const char*, char**)
> __
On Mon, 7 Nov 2022 at 16:11, Joseph Myers wrote:
>
> On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
>
> > APIs. So that one can build gcc against older glibc and then compile
> > user programs on newer glibc, the patch uses weak references unless
> > gcc is compiled against glibc 2.26+.
On Thu, 27 Oct 2022 at 19:48, Patrick Palka via Libstdc++
wrote:
>
> On Thu, 27 Oct 2022, Patrick Palka wrote:
>
> > This also implements the proposed resolutions of the tentatively ready
> > LWG issues 3760 and 3761.
> >
> > I'm not sure how/if we should implement the recommended practice of:
> >
On Thu, 6 Oct 2022 at 20:03, Charles-Francois Natali via Libstdc++
wrote:
>
> `basic_filebuf::xsputn` would bypass the buffer when passed a chunk of
> size 1024 and above, seemingly as an optimisation.
>
> This can have a significant performance impact if the overhead of a
> `write` syscall is non
> Eric, can you push the approved fix for this issue (look for a message
> from Richard P day or two back, approved by Richi)? I'm dealing with a
> medical issue and heading offline again momentarily.
Sure, done.
--
Eric Botcazou
Ping x3.
On 2022/10/31 10:18 PM, Chung-Lin Tang wrote:
> Ping x2.
>
> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote:
>> Ping.
>>
>> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote:
>>> Hi Tom,
>>> I had a patch submitted earlier, where I reported that the current way of
>>> implementin
On 11/7/22 01:01, Eric Botcazou via Gcc-patches wrote:
I can send the obvious patch to make it work as before and ignore the
NULL which fixes this. I'm not sure if it should really be passing NULL
around in the first place or not which is why I'm sharing the backtrace.
Thanks for the investiga
On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> APIs. So that one can build gcc against older glibc and then compile
> user programs on newer glibc, the patch uses weak references unless
> gcc is compiled against glibc 2.26+. strfromf128 unfortunately can't
This support for older gli
Ping patch:
| Date: Tue, 1 Nov 2022 22:44:01 -0400
| Subject: [PATCH 3/3] Update float 128-bit conversions, PR target/107299.
| Message-ID:
This patch fixes some issues with IEEE 128-bit long doubles once the previous 2
patches have been applied.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massa
Ping patch:
| Date: Tue, 1 Nov 2022 22:42:30 -0400
| Subject: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299
| Message-ID:
This patch is needed to build GCC on Fedora 36 which has switched the long
double default to be IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Aye
On Fri, Nov 4, 2022 at 8:14 PM Jakub Jelinek wrote:
>
> On Mon, Oct 17, 2022 at 08:21:01AM +0200, Aldy Hernandez wrote:
> > +// Set VALUE to its next real value, or INF if the operation overflows.
> > +
> > +inline void
> > +frange_nextafter (enum machine_mode mode,
> > + REAL_VALUE_
Ping patch:
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
This patch is needed to build GCC on Fedora 36 where the default for long
double is now IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer,
Fair enough.
How's this?
Tested on x86-64 Linux. LAPACK regression testing as well.
On Mon, Nov 7, 2022 at 1:56 PM Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 01:48:28PM +0100, Aldy Hernandez wrote:
> > On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Nov 07, 2022
image.aspx
Description: Binary data
On Mon, 7 Nov 2022, Andre Vieira (lists) wrote:
>
> On 07/11/2022 11:05, Richard Biener wrote:
> > On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> >
> >> Sorry for the delay, just been reminded I still had this patch outstanding
> >> from last stage 1. Hopefully since it has been mostly reviewe
This allows loop unswitching to unswitch outer loops conditions are
invariant in. We restrict ourselves to unswitch conditions in innermost
loops and will only unswitch loop nests that do not contain any sibling loops.
To simplify the implementation the loop nest unswitched is the deepest all
unsw
On Wed, Nov 2, 2022 at 4:37 AM Hongyu Wang wrote:
>
> Hi, this is the updated patch of
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604345.html,
> which uses targetm.loop_unroll_adjust as gate to enable small loop unroll.
>
> This patch does not change rs6000/s390 since I don't have ma
On 07/11/2022 11:05, Richard Biener wrote:
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully since it has been mostly reviewed it could go in
for this stage 1?
I addressed the comments and g
On Thu, 27 Oct 2022, Patrick Palka wrote:
> On Thu, 27 Oct 2022, Patrick Palka wrote:
>
> > This also implements the proposed resolutions of the tentatively ready
> > LWG issues 3760 and 3761.
> >
> > I'm not sure how/if we should implement the recommended practice of:
> >
> > difference_type
Ping.
On Fri, Oct 28, 2022 at 04:42:33PM -0400, Marek Polacek via Gcc-patches wrote:
> Two things here:
>
> 1) when we're pointing out that std::move on a constant object is
>redundant, don't say "in return statement" when we aren't in a
>return statement;
> 2) suppress the warning when t
On Sat, 5 Nov 2022, Philipp Tomsich wrote:
> Alexander,
>
> I had missed your comment until now.
Please make sure to read replies from Jeff and Palmer as well (their responses
went to gcc-patches with empty Cc list):
https://inbox.sourceware.org/gcc-patches/ba895f78-7f47-0f4-5bfe-e21893c4...@
On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
>
> 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > It would be a lot nicer if playback::context met the C++ Lockable
> > requirements, and playback::context::compile () could just take a
> > scoped lock on *this:
> >
> >
>
> Yeah yeah that makes a lot of sen
> This was introduced with the fix and backports of PR103530 on
> x86_64-linux-gnux32 with older glibc versions (checked with 2.31), where
> dladdr is still in the libdl.so library, and not included in libc.so as in
> newer glibc versions.
> Linking of libgnat.so fails with
>
> [...]
> /usr/x86_64
On 11/7/22 14:09, Gaius Mulley wrote:
>
> Hi Martin,
>
> here is the revised patch having applied all previous recommendations:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603436.html
Hi.
>
> Is this ok now? Thanks for the improvement suggestions (argparse
> results in few
On Wed, 2 Nov 2022 at 09:26, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds std::{to,from}_chars support for std::float128_t
> on glibc 2.26+ for {i?86,x86_64,ia64,powerpc64le}-linux.
> When long double is already IEEE quad, previous changes already handle
> it by using long double over
image.aspx
Description: Binary data
On Mon, 7 Nov 2022 at 08:19, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch updates from fast_float trunk. That way
> it grabs two of the 4 LOCAL_PATCHES, some smaller tweaks, to_extended
> cleanups and most importantly fix for the incorrect rounding case,
> PR107468 aka https://github.com/
On Wed, Nov 2, 2022 at 9:40 AM Dimitrije Milosevic
wrote:
>
> Hi Jeff,
>
> > This is exactly what I was trying to get to. If the addressing mode
> > isn't supported, then we shouldn't be picking it as a candidate. If it
> > is, then we've probably got a problem somewhere else in this code and
>
在 2022-11-07 20:57, Jonathan Wakely 写道:
It would be a lot nicer if playback::context met the C++ Lockable
requirements, and playback::context::compile () could just take a
scoped lock on *this:
Yeah yeah that makes a lot of sense. Would you please just commit that? I don't have write access t
On Mon, 31 Oct 2022, Tamar Christina wrote:
> Hi All,
>
> Here's a respin addressing review comments.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * match.pd: Add bitfield and sh
On Mon, 31 Oct 2022, Tamar Christina wrote:
> Hi All,
>
> This adds a new optab and IFNs for REDUC_PLUS_WIDEN where the resulting
> scalar reduction has twice the precision of the input elements.
>
> At some point in a later patch I will also teach the vectorizer to recognize
> this builtin once
On Mon, 31 Oct 2022, Tamar Christina wrote:
> > > This moves the pattern detection to match.pd instead.
> >
> > where's the other copy and is it possible to remove it with this patch?
> >
>
> It looks like it's spread over various passes. Starting with forwardprop.
Can you be more specific? I
Hi Martin,
here is the revised patch having applied all previous recommendations:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603436.html
Is this ok now? Thanks for the improvement suggestions (argparse
results in fewer lines of code :-)
regards,
Gaius
--8<--8<-
Avoid moving pure/const calls that may return twice in tree-ssa-sink:
properly redirecting the associated abnormal edge is non-trivial.
gcc/ChangeLog:
PR tree-optimization/107505
* tree-ssa-sink.cc (statement_sink_location): Additionally
reject ECF_RETURNS_TWICE calls.
gc
On Mon, 7 Nov 2022 at 06:51, LIU Hao via Gcc wrote:
>
> 在 2022-11-07 12:37, Andrew Pinski 写道:
> >
> > The original code which used pthread was added in GCC 5 way before GCC
> > moved to being written in C++11 which was only in the last 3 years.
> > pthread_* functions were the best choice at the t
On Fri, Oct 28, 2022 at 3:39 PM Dimitrije Milosevic
wrote:
>
> Hi Richard,
>
> > It's n_invs + 2 * n_cands?
>
> Correct, n_invs + 2 * n_cands, my apologies.
>
> > The comment says we want to prefer eliminating IVs over invariants. Your
> > patch
> > undoes that by weighting invariants the same s
On Mon, Nov 07, 2022 at 01:48:28PM +0100, Aldy Hernandez wrote:
> On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
> >
> > On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> > > Let me see if I understand you correctly...
> > >
> > > real_isdenormal is always returning false for
On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> > Let me see if I understand you correctly...
> >
> > real_isdenormal is always returning false for our uses in frange? So
> > instead of using real_isdenormal in flush_denorm
On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> Let me see if I understand you correctly...
>
> real_isdenormal is always returning false for our uses in frange? So
> instead of using real_isdenormal in flush_denormals_to_zero, perhaps
> we should be using:
>
> REAL_EXP (r) < R
On Fri, Nov 4, 2022 at 8:53 PM Jakub Jelinek wrote:
>
> On Fri, Nov 04, 2022 at 08:14:23PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > One thing that is clear is that real_isdenormal is never true for these
> > (but then a question is if flush_denormals_to_zero actually works).
>
> So, after s
> -Original Message-
> From: Richard Biener
> Sent: Monday, November 7, 2022 11:23 AM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-
> patc...@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/8]middle-end: Recognize scalar reductions from
> bitfields and array_refs
>
> On Mon, 7 Nov 2022, Tam
The problem here is that we are transforming a division by a power of
2 into a right shift, and using this to shift the maybe nonzero bits.
This gives the wrong result when the number being divided is negative.
In the testcase we are dividing this by 8:
[irange] int [-256, -255] NONZERO 0
On Tue, 1 Nov 2022, Alexander Monakov wrote:
> Hi,
>
> I'm sending followup fixes for combinatorial explosion of znver scheduling
> automaton tables as described in the earlier thread:
>
> https://inbox.sourceware.org/gcc-patches/23c795d6-403c-5927-e610-f0f1215f5...@ispras.ru/T/#m36e069d43d07d
On Mon, 7 Nov 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, November 7, 2022 10:18 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; gcc-
> > patc...@gcc.gnu.org; nd
> > Subject: RE: [PATCH 1/8]middle-end: Recognize scalar reductions fr
On Thu, 3 Nov 2022, Andre Vieira (lists) wrote:
> Hi,
>
> With Tamar's patch
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604880.html) enabling
> the vectorization of early-breaks, I'd like to allow bitfield lowering in such
> loops, which requires the relaxation of allowing multipl
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> Sorry for the delay, just been reminded I still had this patch outstanding
> from last stage 1. Hopefully since it has been mostly reviewed it could go in
> for this stage 1?
>
> I addressed the comments and gave the slp-part of vectorizable_call
> -Original Message-
> From: Richard Biener
> Sent: Monday, November 7, 2022 10:18 AM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-
> patc...@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/8]middle-end: Recognize scalar reductions from
> bitfields and array_refs
>
> On Mon, 7 Nov 2022, Tam
On Mon, Nov 07, 2022 at 10:31:21AM +, Richard Biener wrote:
> On Mon, 7 Nov 2022, Jakub Jelinek wrote:
>
> > On Mon, Nov 07, 2022 at 10:02:11AM +0100, Richard Biener wrote:
> > > The following adds a fold_builtins pass at -O0, keying off some
> > > unwanted optimization and setting pointer ali
On Mon, 7 Nov 2022, Jakub Jelinek wrote:
> On Mon, Nov 07, 2022 at 10:02:11AM +0100, Richard Biener wrote:
> > The following adds a fold_builtins pass at -O0, keying off some
> > unwanted optimization and setting pointer alignment of the result
> > of __builtin_assume_alignment before removing the
On Mon, 7 Nov 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Saturday, November 5, 2022 11:33 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
> > Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions fro
> index 9778e776cf2..adb1e351e15 100644
> --- a/gcc/tree-ssa-ccp.cc
> +++ b/gcc/tree-ssa-ccp.cc
> @@ -4197,6 +4197,7 @@ const pass_data pass_data_fold_builtins =
>TODO_update_ssa, /* todo_flags_finish */
> };
>
> +template
> class pass_fold_builtins : public gimple_opt_pass
> {
> public:
gcc/
* ira-color.cc (update_costs_from_allocno): Check that allocno
is in the consideration_allocno_bitmap before dereferencing
ALLOCNO_COLOR_DATA (allocno).
---
This fixes the invalid memory access, but I'm not sure if that's
sufficient and there's no remaining higher level
gcc/testsuite/ChangeLog:
* gcc.target/i386/sse-22.c: Fix typo in pragma GCC target.
Pushing as obvious.
Thanks,
Lingling
---
gcc/testsuite/gcc.target/i386/sse-22.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/sse-22.c
b/gcc/testsui
1 - 100 of 141 matches
Mail list logo
