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 machine to
test them, but I suppose the default behavior is
On Linux/x86_64,
e7310e24b1c0ca67b1bb507c1330b2bf39e59e32 is the first bad commit
commit e7310e24b1c0ca67b1bb507c1330b2bf39e59e32
Author: Andrew MacLeod
Date: Tue Oct 25 16:42:41 2022 -0400
Make ranger vrp1 default.
caused
FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
This patch fixes two tests that are still failing when long double is IEEE
128-bit after the previous 2 patches for PR target/107299 have been applied.
The tests are:
gcc.target/powerpc/convert-fp-128.c
gcc.target/powerpc/pr85657-3.c
This patch is a rewrite of the patch submitted
This patch fixes the issue that GCC cannot build when the default long double
is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
during the evrp pass. Ultimately it is failing because the
This function reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
These 3 patches fix the problems with building GCC on PowerPC systems when long
double is configured to use the IEEE 128-bit format.
There are 3 patches in this patch set. The first two patches are required to
fix the basic problem. The third patch fixes some issue that were noticed
along the
> > diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> > index 7c6bfa6e..cd0282f1 100644
> > --- a/htdocs/gcc-13/changes.html
> > +++ b/htdocs/gcc-13/changes.html
> > @@ -230,6 +230,8 @@ a work-in-progress.
> >For both C and C++ the __bf16 type is supported on
> >
Hello
I have committed the following patches onto the devel/omp/gcc-12
development branch:
863579c4e30 amdgcn: Enable SIMD vectorization of math functions
bd9a6106b95 amdgcn: Add SIMD versions of math routines to libgcc
d3a2a1cc424 amdgcn: Add builtins for vector floor/floorf
a3c04a367a9
On 11/1/22 11:25, Kevin Lee wrote:
This is the updated patch of
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601824.html. Since
the riscv-selftest.cc has been added, this version of the patch adds the
logic in riscv-selftest.cc to also consider parallel insns.
The patch has been
Hi, Jose and David,
Any progress on implement debug_annotate attribute in gcc?
Thanks,
Yonghong
On 6/15/22 3:56 PM, Yonghong Song wrote:
On 6/15/22 1:57 PM, David Faust wrote:
On 6/14/22 22:53, Yonghong Song wrote:
On 6/7/22 2:43 PM, David Faust wrote:
Hello,
This patch series
-Wdangling-reference complains here:
std::vector v = ...;
std::vector::const_iterator it = v.begin();
while (it != v.end()) {
const int = *it++; // warning
}
because it sees a call to
__gnu_cxx::__normal_iterator >::operator*
which returns a reference and its argument is a
Hi,
On Tue, 24 May 2022 16:15:31 +0200
Jakub Jelinek via Fortran wrote:
> On Fri, Mar 18, 2022 at 09:26:47AM -0700, Julian Brown wrote:
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -4266,6 +4266,9 @@ cp_parser_new (cp_lexer *lexer)
> >parser->omp_declare_simd = NULL;
> >
This implements ABI-compliant lambda discriminators. Not only do we
have per-scope counters, but we also distinguish by lambda signature.
Only lambdas with the same signature will need non-zero
discriminators. As the discriminator is signature-dependent, we have
to process the lambda
The fallback implementation of floating-point std::from_chars for e.g.
float80 just calls the C library's strtod family of functions. In case
of overflow of the parsed result, the behavior of these functions is
rigidly specified:
If the correct value overflows and default rounding is in
> Yes. But it is all the same: neither signed overflow nor unsigned
> overflow (of an addition, say) can be described as the result of an
> RTL comparison.
I disagree, see for example the implementation of the addvdi4_sp3 pattern (for
which we indeed use an UNSPEC) and of the uaddvdi4_sp32
On Fri, Oct 28, 2022 at 11:55:35PM +0200, Eric Botcazou wrote:
> > You mean in CCV? That works yes, but only because (or if) the setter
> > and getter of the CC reg both use CCV (so never use any other flag at
> > the same time; CCV has an empty intersection with all other CC modes).
>
> We're
On 7/5/22 06:20, David Seifert wrote:
Hi Jeff,
thanks for merging my OBJDUMP patch. Could you please also merge the
following patch, which Jakub approved on IRC? I have tried contacting
the build system maintainers, but they are all AWOL
On 8/29/22 03:29, Rasmus Villemoes wrote:
-ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
and -fdebug-prefix-map. However, when building .S or .s files, gas is
not called with the appropriate --debug-prefix-map option when
-ffile-prefix-map is used.
While the user can
On Thu, Jan 10, 2019 at 11:20 AM Srinath Parvathaneni
wrote:
>
> Hi All,
>
> This patch implements the ACLE hint intrinsics (nop, yield, wfe, wfi,
> sev and sevl), for AArch64.
Hmm, this (and the corresponding arm patch) was never reviewed.
It might be useful to get an updated version which
On 8/17/22 06:15, Richard Purdie via Gcc-patches wrote:
Relative paths currently aren't remapped by -ffile-prefix-map and friends.
When cross compiling with separate 'source' and 'build' directories, the same
relative paths between directories may not be available on target as compared
to
On 8/17/22 06:15, Richard Purdie via Gcc-patches wrote:
Code such as:
#include __FILE__
can interact poorly with file-prefix-map options when cross compiling. In
general you're after to remap filenames for use in target context but the
local paths should be used to find include files at
On 10/28/22 01:00, Richard Biener wrote:
On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic
wrote:
Hi Jeff,
THe part I don't understand is, if you only have BASE+OFF, why does
preventing the calculation of more complex addressing modes matter? ie,
what's the point of computing the cost
On Mon, 31 Oct 2022 16:52:25 PDT (-0700), juzhe.zh...@rivai.ai wrote:
These cases actually doesn't care about -mabi, they just need 'v' in -march.
Can you tell me how to fix these testcases for "fails on targets without
ilp32d" ?
These failures are bogus failures since if you specify
None of the build_ functions in range-op handle NANs. This is by
design in order to force us to handle NANs specially, because
"x relop NAN" makes no sense. This patch fixes a handful of
op[12]_range entries that weren't handling NANs.
PR tree-optimization/107490
gcc/ChangeLog:
pushed as obvious. Testing running.
Andrew
commit 82b0345f6137b112728590d7c010dcd2cef08514
Author: Andrew MacLeod
Date: Tue Nov 1 13:18:33 2022 -0400
Make sure ssa-name is valid.
PR tree-optimization/107497
* tree-vrp.cc
This is the updated patch of
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601824.html. Since
the riscv-selftest.cc has been added, this version of the patch adds the
logic in riscv-selftest.cc to also consider parallel insns.
The patch has been tested with rv64imafdc / rv64imac /
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in template
specialization:
template struct S { };
template<> struct S { };
template<> struct S { }; // OK, not a redefinition
I'm of the mind
On 11/1/22 09:53, Tamar Christina wrote:
from the machine description.
+@cindex @code{tbranch@var{mode}4} instruction pattern @item
+@samp{tbranch@var{mode}4} Conditional branch instruction combined
+with a bit test-and-compare instruction. Operand 0 is a comparison
+operator. Operand 1
Folks. I have decided to put this aside until the next release. I
originally wanted a simple rename, and reimplementing things to align
with rtl, etc, is beyond what I want to tackle on this late.
I'll archive this away, and revisit it when we implement the
irange::known_ones mask.
Thanks for
All multiplication instructions are fully pipelined, except AVX256
instructions on Zen 1, which issue over two cycles on a 128-bit unit.
Correct the model accordingly to reduce combinatorial explosion in
automaton tables.
Top znver table sizes in insn-automata.o:
Before:
30056 r
Correct modeling of division instructions in the SIMD/FP domain for
AMD Zen architectures and avoid combinatorial explosion of automaton
tables by modeling the separate floating-point division unit and
correcting reservations to reflect reciprocal throughput of the
corresponding instructions,
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/#m36e069d43d07d768d4842a779e26b4a0915cc543
I think lujiazui.md and
On Tue, Nov 01, 2022 at 08:57:37 -0600, Tom Tromey wrote:
> > "Ben" == Ben Boeckel via Gcc-patches writes:
>
> Ben> - `-fdeps-file=` specifies the path to the file to write the format to.
>
> I don't know how this output is intended to be used, but one mistake
> made with the other
> -Original Message-
> From: Jeff Law
> Sent: Monday, October 31, 2022 9:16 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/2]middle-end: Add new tbranch optab to add support
> for bit-test-and-branch operations
>
>
> On 10/31/22
On 10/27/22 23:47, Sebastian Huber wrote:
On 28/10/2022 01:05, Palmer Dabbelt wrote:
On Thu, 27 Oct 2022 15:56:17 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 10/26/22 01:49, Sebastian Huber wrote:
The RV32A extension does not support 64-bit atomic operations. For
RTEMS, use
a 32-bit
> Do those loads still get scalarized at -O0?
Presumably not at the GIMPLE level, but possibly at the RTL level.
--
Eric Botcazou
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 1, 2022 3:05 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 8/8]AArch64: Have reload not choose to do add on the
> scalar
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 1, 2022 2:59 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 5/8]AArch64 aarch64: Make existing V2HF be usable.
>
> Tamar
Tamar Christina writes:
> Hi All,
>
> Currently we often times generate an r -> r add even if it means we need two
> reloads to perform it, i.e. in the case that the values are on the SIMD side.
>
> The pairwise operations expose these more now and so we get suboptimal
> codegen.
>
> Normally I
Tamar Christina writes:
> Hi All,
>
> The backend has an existing V2HFmode that is used by pairwise operations.
> This mode was however never made fully functional. Amongst other things it
> was
> never declared as a vector type which made it unusable from the mid-end.
>
> It's also lacking an
> "Ben" == Ben Boeckel via Gcc-patches writes:
Ben> - `-fdeps-file=` specifies the path to the file to write the format to.
I don't know how this output is intended to be used, but one mistake
made with the other dependency-tracking options was that the output file
isn't created atomically.
Tamar Christina writes:
> Hi All,
>
> This implements the new widening reduction optab in the backend.
> Instead of introducing a duplicate definition for the same thing I have
> renamed the intrinsics defintions to use the same optab.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no
Tamar Christina via Gcc-patches writes:
> Hi All,
>
> The current vector extract pattern can only extract from a vector when the
> position to extract is a multiple of the vector bitsize as a whole.
>
> That means extract something like a V2SI from a V4SI vector from position 32
> isn't possible
This will just confuse most users, the separate tarballs haven't existed
for years (as already noted elsewhere in install.texi).
OK for trunk?
-- >8 --
gcc/ChangeLog:
* doc/install.texi: Remove anachronism about separate source
tarballs.
---
gcc/doc/install.texi | 4 +---
1
This patch turns ranger on by default for the VRP1 pass.
I needed to adjust gcc.dg/pr68217.c to scan for a better range ([-INF,
-INF][0, 0]) than the original [-INF, 0] it was looking for.
This also triggers the new __builtin_unreachable code in the ranger VRP
pass, so I added a new testcase
On Mon, 31 Oct 2022 at 17:05, Jonathan Wakely wrote:
>
> On Mon, 31 Oct 2022 at 17:03, Eric Botcazou wrote:
> >
> > > I suppose we could use memcmp on the as variable itself, to inspect
> > > the actual stored padding rather than the returned copy of it.
> >
> > Yes, that's probably the only
On Tue, 1 Nov 2022, Jonathan Wakely wrote:
> On Tue, 1 Nov 2022 at 12:18, Jakub Jelinek wrote:
> >
> > On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > > > The following patch on top of
> > > > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> > > > adds
Removal of __builtin_unreachable calls were being handled in an
inconsistent way, and Im not convinced always correctly. This removes
them in the ranger VRP pass, and sets the global range appropriately.
This new approach should be consistent. After VRP runs, it uses ranger
to query all the
Ranger was not allowing the exit block to be queried for range_on_entry
or exit, for no good reason. This removes that restriction.
Interestingly, it seems that when we calculate dominance info, GCC does
not set the dominators for the EXIT_BLOCK? I worked around it by
starting with a single
irange::intersect returns true if the intersection operation changes the
value. If both ranges had nonzero bits set, intersect_nonzero_bits was
not checking to see if the operation actually changes the bits or not,
it changed the mask and returned true.
Bootstrapped on x86_64-pc-linux-gnu
Hi Richard,
Here is the immediate cleanup splitoff from the previous patch:
Simplify, refactor and improve various move immediate functions.
Allow 32-bit MOVZ/N as a valid 64-bit immediate which removes special
cases in aarch64_internal_mov_immediate. Add new constraint so the movdi
pattern
On Mon, 31 Oct 2022 at 20:33, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
We should update https://gcc.gnu.org/gcc-13/changes.html#libstdcxx again soon.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges
On Tue, 1 Nov 2022 at 09:36, Jakub Jelinek wrote:
>
> Hi!
>
> On top of the
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054886.html
> the following patch adds std::from_chars support, similarly to the
> previous
On Tue, 1 Nov 2022 at 12:18, Jakub Jelinek wrote:
>
> On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > > The following patch on top of
> > > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> > > adds std::{,b}float16_t support for std::to_chars.
> > > When
On Thu, 27 Oct 2022 at 09:00, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch on top of
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> adds std::{,b}float16_t support for std::to_chars.
> When precision is specified (or for std::bfloat16_t for hex mode even if not),
> I
On Mon, 31 Oct 2022, Jan Hubička wrote:
> Hello,
> thanks for checking the performance. The patch is OK.
Thanks, pushed the attached patch, and working on a corresponding change for
floating-point divisions.
AlexanderFrom 1962a8b22d3d3fb5b6bb5598295a4571daf8876f Mon Sep 17 00:00:00 2001
From:
On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > The following patch on top of
> > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> > adds std::{,b}float16_t support for std::to_chars.
> > When precision is specified (or for std::bfloat16_t for hex mode even if
On Wed, 19 Oct 2022 at 13:59, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds the easy part of , and
> changes for extended floats.
> In particular, for the first one only overloads where the _Float* has
> the same format as float/double/long double and for the latter two
> everything
Pushed.
Gerald
---
htdocs/readings.html | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 5622bcc3..df89bc9c 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -34,7 +34,7 @@
Pushed.
Gerald
---
htdocs/gcc-4.4/changes.html | 2 +-
htdocs/gcc-4.4/cxx0x_status.html | 116 +++
2 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/htdocs/gcc-4.4/changes.html b/htdocs/gcc-4.4/changes.html
index 748787e7..40a6f0c8 100644
---
v1 -> v2:
1. Change the code format.
2. Fix bugs in the code.
v2 -> v3:
Modifying a code implementation of an undefined behavior.
Both regression tests and spec2006 passed.
The problem mentioned in the link does not move the four immediate load
instructions out of the loop. It has been
Nearly all hrefs= on our site are https:// or http://, and that's the case
pretty much across the web. Still the protocol needs to be provided for
links to work.
Pushed.
Gerald
Web links need to be prefixed by https:// or http://.
---
htdocs/codingconventions.html | 2 +-
1 file changed, 1
Pushed.
Gerald
---
htdocs/faq.html| 2 +-
htdocs/gcc-2.95/regress.html | 2 +-
htdocs/gcc-3.1/gcj-status.html | 6 +++---
htdocs/gcc-3.3/gcj-status.html | 2 +-
htdocs/gcc-8/changes.html | 2 +-
htdocs/gcc-9/changes.html | 2 +-
6 files changed, 8 insertions(+), 8
We currently use a per-extra-scope counter to discriminate multiple
lambdas in a particular such scope. This is not ABI compliant. This
patch merely refactors the existing code to make it easier to drop in
a conformant mangling -- there's no functional change here. I rename
the
Pushed.
Gerald
---
htdocs/codingconventions.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f88ef019..f5e22983 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -737,7
Google has not been using that forever and there are indications
search engines even use it as one indication for spam sites.
Pushed.
Gerald
---
htdocs/readings.html | 1 -
1 file changed, 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 01ccd55d..5622bcc3 100644
---
Remove extraneous whitespace around heading and adjust level.
Pushed.
Gerald
---
htdocs/projects/tree-ssa/tree-browser.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/projects/tree-ssa/tree-browser.html
b/htdocs/projects/tree-ssa/tree-browser.html
index
Hi!
On top of the
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054886.html
the following patch adds std::from_chars support, similarly to the
previous std::to_chars patch through APIs that use float instead of
the 16-bit
> I have faced with "#error Timed lock primitives are not supported on
> Windows targets" and I'm not sure I understood the reason correctly.
>
> as far as I understand, the definition for
> `_GTHREAD_USE_MUTEX_TIMEDLOCK` comes from libstdc++/configure as a
> result of some test.
>
> why did I
在 2022/11/1 下午4:02, Xi Ruoyao 写道:
On Tue, 2022-11-01 at 14:19 +0800, Lulu Cheng wrote:
+;; Load immediate to the 32-63 bits of the source register.
+(define_insn_and_split "load_hi32"
+ [(set (match_operand:DI 0 "register_operand" "=r")
+ (ior:DI
+ (and:DI (match_operand:DI 1
On Mon, Oct 31, 2022 at 5:22 PM Uros Bizjak wrote:
>
> On Mon, Oct 31, 2022 at 2:10 AM liuhongt wrote:
> >
> > >You have a couple of other patterns where operand 1 is matched to
> > >produce vmovddup insn. These are *avx512f_unpcklpd512 and
> > >avx_unpcklpd256. You can also remove expander in
On Tue, 2022-11-01 at 14:19 +0800, Lulu Cheng wrote:
> +;; Load immediate to the 32-63 bits of the source register.
> +(define_insn_and_split "load_hi32"
> + [(set (match_operand:DI 0 "register_operand" "=r")
> + (ior:DI
> + (and:DI (match_operand:DI 1 "register_operand" "0")
> +
v1 -> v2:
1. Change the code format.
2. Fix bugs in the code.
Both regression tests and spec2006 passed.
The problem mentioned in the link does not move the four immediate load
instructions out of the loop. It has been optimized. Now, as in the test case,
four immediate load instructions are
73 matches
Mail list logo
