> > > 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
>
On Fri, Oct 14, 2022 at 3:57 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_intel_cpu):
> Add Sierra Forest.
> * common/config/i386/i386-common.cc
> (processor_names): Add Sierra Forest.
> (processor_alias_
Hi all,
I just revised the patch according to review. The changes comparing to
previous version is mentioned below.
Ok for trunk?
BRs,
Haochen
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect cmpccxadd.
* common/config/i386/i386-common.cc
Implement C2x auto, a more restricted version of the C++ feature
(closer to GNU C __auto_type in terms of what's supported).
Since the feature is very close to GNU C __auto_type, much of the
implementation can be shared. The main differences are:
* Any prior declaration of the identifier in an o
On Wed, 02 Nov 2022 08:06:36 PDT (-0700), j...@ventanamicro.com wrote:
On 11/2/22 07:54, Manolis Tsamis wrote:
I've revisited this testcase and I think it's not possible to make it
work with the current implementation.
It's not possible to trigger shrink wrapping in this case since the
wrappin
On 11/2/22 15:50, Bernhard Reutner-Fischer via Gcc-patches wrote:
On 2 November 2022 15:45:39 CET, Tamar Christina via Gcc-patches
wrote:
Hi All,
This patch adds initial support for early break vectorization in GCC.
The support is added for any target that implements a vector cbranch optab.
On 2022-09-23 09:02, Jakub Jelinek wrote:
Oh, so can addr_object_size be simplified to use get_base_address too?
You can try. As you can see in get_base_address, that function
handles something that the above doesn't (looking through some MEM_REFs too).
I went down this rabbithole and it ac
On Wed, 02 Nov 2022 15:20:57 PDT (-0700), philipp.toms...@vrull.eu wrote:
On Wed, 2 Nov 2022 at 23:06, Palmer Dabbelt wrote:
On Wed, 02 Nov 2022 05:52:34 PDT (-0700), jia...@iscas.ac.cn wrote:
> This patch just add name support contain in profiles.
> Set the extension version as 0.1.
Or maybe
On Wed, 2 Nov 2022 at 23:06, Palmer Dabbelt wrote:
>
> On Wed, 02 Nov 2022 05:52:34 PDT (-0700), jia...@iscas.ac.cn wrote:
> > This patch just add name support contain in profiles.
> > Set the extension version as 0.1.
>
> Or maybe v0.8, as they're in the v0.8 profile spec? I doubt it really
> ma
On Wed, 02 Nov 2022 05:52:34 PDT (-0700), jia...@iscas.ac.cn wrote:
This patch just add name support contain in profiles.
Set the extension version as 0.1.
Or maybe v0.8, as they're in the v0.8 profile spec? I doubt it really
matters, though. Either way we'll need a -mprofile-spec-version (o
On 2 November 2022 15:45:39 CET, Tamar Christina via Gcc-patches
wrote:
>Hi All,
>
>This patch adds initial support for early break vectorization in GCC.
>The support is added for any target that implements a vector cbranch optab.
>
>Concretely the kind of loops supported are of the forms:
>
> fo
From: Andrew Pinski
Right now anyone could call tree_nonzero_bits with
either complex or vector types and this will return
the wrong thing. So just assert that nobody calls
it with this.
OK? Bootstrapped and tested with no regressions on x86_64-linux-gnu.
gcc/ChangeLog:
* fold-const.cc
From: Andrew Pinski
While looking at older unconfirmed bug reports, I noticed there was
an ubsan found issue and noticed tree_nonzero_bits was being called with
a vector type. How ubsan found it was at the end of tree_nonzero_bits,
did "return wi::shwi (-1, TYPE_PRECISION (TREE_TYPE (t)));" and
From: Andrew Pinski
Even though this PR was reported with an ubsan issue, the problem is
tree_nonzero_bits is being called with an expression which is a vector type.
This fixes three patterns I noticed which does that.
And adds a testcase for one of the patterns.
OK? Bootstrapped and tested on x
On 10/26/22 16:40, David Malcolm via Gcc-patches wrote:
Changed in v3: added include of
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604137.html
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598189.html
On Tue, 2022-07-12 at 07:48 +0100, Jonathan Wakely wrote:
On Tue, 1
On 2022-11-02 21:27, Eric Botcazou wrote:
Great! Did you check that C++ threads are enabled in your build? If
they
are, you must be able to run the attached C++ test; if they are not
(because
the MinGW64 build is configured for older versions of Windows), you
need to
configure the compiler
> I was able to successfully build gcc-trunk using the provided patch.
> moreover, I was able to successfully build all of the packages used in
> the toolchain!
> (gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses,
> readline, gdbm, tcl, tk, openssl, xz-utils, sqlite, python3, b
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declaration of S's prototype in P.
S is defined as:
void s (character(kind=1)[1:_c] & restrict c, integer(kind
Hi!
On 2022-11-02T21:22:25+0100, I wrote:
> On 2022-11-02T21:15:31+0100, I wrote:
>> On 2022-11-02T21:10:54+0100, I wrote:
>>> On 2022-11-02T21:04:56+0100, I wrote:
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/declare-allocatable-1.f90
@@ -0,0 +1,268 @@
+! Test Op
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
We don't need these 'unused' members because they're never used, and a
union with a single variant member is fine.
libstdc++-v3/ChangeLog:
* libsupc++/eh_globals.cc (constant_init::unused): Remove.
* src/c++11/system_error.cc (
Just wanted to see if there was anything else I can do to help move
this over the finish line! Thanks for all the work that you all do!
Sincerely,
Will
On Wed, Oct 19, 2022 at 8:06 PM Will Hawkins wrote:
>
> Sorry for the delay. Tested on x86-64 Linux.
>
> -->8--
>
> After consultation with Jona
Hi!
On 2022-11-02T21:15:31+0100, I wrote:
> On 2022-11-02T21:10:54+0100, I wrote:
>> On 2022-11-02T21:04:56+0100, I wrote:
>>> --- /dev/null
>>> +++ b/libgomp/testsuite/libgomp.oacc-fortran/declare-allocatable-1.f90
>>> @@ -0,0 +1,268 @@
>>> +! Test OpenACC 'declare create' with allocatable arrays
Hi!
On 2022-11-02T21:10:54+0100, I wrote:
> On 2022-11-02T21:04:56+0100, I wrote:
>> On 2017-04-05T08:23:58-0700, Cesar Philippidis
>> wrote:
>>> This patch implements the OpenACC 2.5 behavior of fortran allocate on
>>> variables marked with declare create as defined in Section 2.13.2 in the
>>>
Hi!
On 2022-11-02T21:04:56+0100, I wrote:
> On 2017-04-05T08:23:58-0700, Cesar Philippidis wrote:
>> This patch implements the OpenACC 2.5 behavior of fortran allocate on
>> variables marked with declare create as defined in Section 2.13.2 in the
>> OpenACC spec.
>
> That functionality is still m
Hi!
On 2017-04-05T08:23:58-0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 behavior of fortran allocate on
> variables marked with declare create as defined in Section 2.13.2 in the
> OpenACC spec.
That functionality is still missing in GCC master branch, however a test
ca
Applied to master (with a fixed-up commit message), thanks!
Note that the Zawrs has been approved for ratification by the RISC-V
BoD on Oct 20th.
--Philipp.
On Thu, 27 Oct 2022 at 22:51, Palmer Dabbelt wrote:
>
> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu wrote:
> > O
Extend optimization for
_1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
_5 = (signed int) _1;
_4 = _5 >= 0;
to
_1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
_5 = (signed int) _1;
if (_5 >= 0)
gcc/
PR middle-end/102566
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and): Also
Applied to gcc-wwwdocs/master. Thanks!
Philipp.
On Wed, 2 Nov 2022 at 17:12, Kito Cheng wrote:
>
> LGTM, thanks!
>
> On Wed, Nov 2, 2022 at 7:59 AM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > This patch documents the new RISC-V Zawrs support.
> >
> > Signed-off-by: Chris
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604062.html
Ok for trunk?
Kind regards,
Torbjörn
On 2022-10-20 22:48, Torbjörn SVENSSON wrote:
For systems with HAVE_DOS_BASED_FILE_SYSTEM set, only override the
pointer if the backslash pattern matches.
Output without this pat
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603878.html
Kind regards,
Torbjörn
On 2022-10-19 11:42, Torbjörn SVENSSON wrote:
Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suite the target.
With this p
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604312.html
Ok for trunk?
Kind regards,
Torbjörn
On 2022-10-25 17:15, Torbjörn SVENSSON wrote:
Without this patch, the following error is reported on Windows:
In file included from t:\build\arm-none-eabi\include\c++\11.3.1\stri
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602844.html
Ok for trunk?
Kind regards,
Torbjörn
On 2022-10-25 16:24, Torbjorn SVENSSON via Gcc-patches wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603544.html
Kind regards,
Torbjörn
On 2022-10-14
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 what this should
do so we can maintain compatibility with LLVM as well as we can.
IIUC this also allows for profiles in the arch funct
On 11/2/22 18:29, Joseph Myers wrote:
On Wed, 2 Nov 2022, Christophe Lyon via Gcc-patches wrote:
+# Sanity check: make sure we have as many dirnames as options
+if [ -n "${dirnames}" ]; then
+options_arr=($options)
This is an sh script; arrays are a bash feature. Building GCC isn't
su
On Wed, 2 Nov 2022, Christophe Lyon via Gcc-patches wrote:
> +# Sanity check: make sure we have as many dirnames as options
> +if [ -n "${dirnames}" ]; then
> +options_arr=($options)
This is an sh script; arrays are a bash feature. Building GCC isn't
supposed to need bash (or to rely on $(S
Le 31/10/2022 à 21:29, Harald Anlauf via Fortran a écrit :
Hi Mikael,
thanks a lot, your testcases broke my initial (and incorrect) patch
in multiple ways. I understand now that the right solution is much
simpler and smaller.
I've added your testcases, see attached, with a simple scan of the
d
Could you add some test cases?
---
Parsing logic is kind of too adhoc, I would prefer using something
like the following code to prevent magic pointer arithmetic like p+6:
something like this:
Table of all profile names = {"RVA20U64", riscv_profile::RVA20U64, ...}
const char *rva20u64[] = {"m"
LGTM, thanks!
On Wed, Nov 2, 2022 at 7:59 AM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This patch documents the new RISC-V Zawrs support.
>
> Signed-off-by: Christoph Müllner
> ---
> htdocs/gcc-13/changes.html | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on Windows.
Ok for trunk?
-
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:Foo' is treated as
This fixes some an issue with 'alloc:' found when working on the patch
'[Patch] OpenMP/Fortran: 'target update' with strides + DT components'
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604687.html
(BTW: This one is still pending review.)
OK for mainline?
* * *
I think the patch is
On 11/2/22 06:35, Rasmus Villemoes wrote:
On 01/11/2022 21.11, Jeff Law wrote:
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 -
On 11/2/22 07:54, Manolis Tsamis wrote:
I've revisited this testcase and I think it's not possible to make it
work with the current implementation.
It's not possible to trigger shrink wrapping in this case since the
wrapping of registers is guarded by
if (SMALL_OPERAND (offset)) { bitmap_set
On 11/2/22 08:12, Manolis Tsamis wrote:
On Wed, Oct 19, 2022 at 8:16 PM Jeff Law via Gcc-patches
wrote:
On 10/18/22 11:35, Palmer Dabbelt wrote:
I would have expected things to work fine with libcalls, perhaps with
the exception of the save/restore libcalls. So that needs deeper
investigat
On Wed, Nov 2, 2022 at 3:38 PM Philipp Tomsich wrote:
>
> On Wed, 2 Nov 2022 at 15:21, Christoph Müllner
> wrote:
> >
> >
> >
> > On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
> >>
> >> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu
> >> wrote:
> >> > On Thu, Oct
From: Christoph Müllner
This patch documents the new RISC-V Zawrs support.
Signed-off-by: Christoph Müllner
---
htdocs/gcc-13/changes.html | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 7c6bfa6e..5e6e054b 10
Hi All,
This adds an implementation for conditional branch optab for AArch64.
For 128-bit vectors we generate:
cmhiv1.4s, v1.4s, v0.4s
umaxp v1.4s, v1.4s, v1.4s
fmovx3, d1
cbnzx3, .L8
and of 64-bit vector we can omit the compression:
cmhi
On Wed, 2 Nov 2022 at 15:21, Christoph Müllner
wrote:
>
>
>
> On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
>>
>> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu wrote:
>> > On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
>> > christoph.muell...@vrull.eu> wrote
On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu
> wrote:
> > On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
> > christoph.muell...@vrull.eu> wrote:
> >
> >> From: Christoph Muellner
> >>
> >> This patch adds sup
On Wed, Oct 19, 2022 at 8:16 PM Jeff Law via Gcc-patches
wrote:
>
>
> On 10/18/22 11:35, Palmer Dabbelt wrote:
> >
> >> I would have expected things to work fine with libcalls, perhaps with
> >> the exception of the save/restore libcalls. So that needs deeper
> >> investigation.
> >
> > The save/
On Tue, Oct 18, 2022 at 8:35 PM Palmer Dabbelt wrote:
>
> On Tue, 18 Oct 2022 08:57:37 PDT (-0700), j...@ventanamicro.com wrote:
> >
> > Just a couple more comments in-line.
> >
> > On 10/18/22 09:18, Manolis Tsamis wrote:
> >>
> +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
>
IIUC such variables should be declared inline to avoid potential ODR
violations since they're otherwise considered to be distinct (internal
linkage) entities across TUs.
The changes inside the regex_constants and execution namespace seem to
be unimplemented parts of P0607R0; the rest of the change
On 9/27/22 15:00, Mikael Morin wrote:
Hello,
Le 16/09/2022 à 15:26, Aldy Hernandez via Gcc-patches a écrit :
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d759fcf178c..55a216efd8b 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -617,21 +602,24 @@ frange::contains_p (t
When a list of dirnames is provided to genmultilib, its length is
expected to match the number of options. If this is not the case, the
build fails later for reasons not obviously related to this mistake.
This patch adds a sanity check to help diagnose such cases.
Tested by adding an option to t-
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Hui Xie pointed out that we don't need a dummy member in the union,
because all constructors always initialize either _M_val or _M_unex.
We still need the _M_void member of the expected
specialization, because the constructor has to initialize
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The warning is wrong here, the qualifier serves a purpose and is not
ignored (c.f. PR c++/107492).
libstdc++-v3/ChangeLog:
* include/std/variant (__variant::_Multi_array::__untag_result):
Use pragma to suppress warning.
---
li
Add two new function to handle profile input,
"parse_profile" will check if a input into -march is
legal, if it is then "handle_profile" will check the
profile's type[I/M/A], year[20/22] and mode[U/S/M],
set different extensions combine, just deal mandatory
part currently.
gcc/ChangeLog:
Supports RISC-V profiles[1] in -march option, add minimal extension name
supports.
Default input set the profile is before other formal extensions.
Test with -march=RV[I/M/A]2[0/2][U/M/S][64/32]+otherextensions.
[1]https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc
jiawei (2):
This patch just add name support contain in profiles.
Set the extension version as 0.1.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New extensions.
* config/riscv/riscv-opts.h (MASK_ZICCAMOA): New mask.
(MASK_ZICCIF): Ditto.
(MASK_ZICCLSM): Ditto.
On Wed, Nov 2, 2022 at 1:45 PM Robin Dapp wrote:
>
> > IIRC, I was trying to "fix" modeless operand by giving it a mode, but
> > since it made no difference for x86, I later dropped the patch.
> > However, operand with a known mode is preferred, so if it works for
> > you, just include my patch in
> IIRC, I was trying to "fix" modeless operand by giving it a mode, but
> since it made no difference for x86, I later dropped the patch.
> However, operand with a known mode is preferred, so if it works for
> you, just include my patch in your submission. My patch is somehow
> trivial if we want o
On Wed, Nov 2, 2022 at 1:12 PM Robin Dapp wrote:
>
> Hi,
>
> > With the patch my local changes to make better use of vec_set work
> > nicely even though I haven't done a full bootstrap yet. Were there
> > other issues with the patch or can it still be applied?
>
> I performed a bootstrap as well
On 01/11/2022 21.11, Jeff Law wrote:
>
> 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
>> -
On Wed, Nov 02, 2022 at 12:20:11PM +, Julian Brown wrote:
> > But we can't forbid lambdas inside of the map clause expressions,
> > they are certainly valid in OpenMP, and IMNSHO shouldn't disallow
> > statement expressions, people might not even know they use a
> > statement expression, they c
On Wed, 2 Nov 2022 12:58:37 +0100
Jakub Jelinek via Fortran wrote:
> On Tue, Nov 01, 2022 at 09:50:38PM +, Julian Brown wrote:
> > > I think we should figure out when we should temporarily disable
> > > parser->omp_array_section_p = false;
> > > and restore it afterwards to a saved value.
Hi,
> With the patch my local changes to make better use of vec_set work
> nicely even though I haven't done a full bootstrap yet. Were there
> other issues with the patch or can it still be applied?
I performed a bootstrap as well as a regtest with -march=z16 on s390.
There is no new fallout.
hi Eric, Jonathan,
I was able to successfully build gcc-trunk using the provided patch.
moreover, I was able to successfully build all of the packages used in
the toolchain!
(gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses,
readline, gdbm, tcl, tk, openssl, xz-utils, sql
Hi!
Thanks for working on this!
On Tue, Nov 01, 2022 at 09:50:38PM +, Julian Brown wrote:
> > I think we should figure out when we should temporarily disable
> > parser->omp_array_section_p = false;
> > and restore it afterwards to a saved value. E.g.
> > cp_parser_lambda_expression seems
Hi Tobias!
On 2022-09-29T14:45:03+, Tobias Burnus via Gcc-cvs
wrote:
> https://gcc.gnu.org/g:c455181c13a7b00ee09777287bcf0c8b9de9d1fe
>
> commit c455181c13a7b00ee09777287bcf0c8b9de9d1fe
> Merge: d21bfef9867 85adc2ec2b0
> Author: Tobias Burnus
> Date: Thu Sep 29 16:37:52 2022 +0200
>
>
On Tue, 1 Nov 2022 at 21:30, Patrick Palka via Libstdc++
wrote:
>
> 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 spec
On Wed, 2 Nov 2022 at 09:39, Jakub Jelinek wrote:
>
> Hi!
>
> Jon pointed out that we have TODO: _Bfloat16 in .
> Right now _S_fp_fmt() returns _Binary16 for _Float16, __fp16 as well
> as __bf16 and it actually works because we don't have a special handling
> of _Binary16. So, either we could jus
On Wed, Nov 2, 2022 at 10:55 AM Tamar Christina wrote:
>
> Hi Aldy,
>
> I'm trying to use Ranger to determine if a range of an expression is a single
> bit.
>
> If possible in case of a mask then also the position of the bit that's being
> checked by the mask (or the mask itself).
Just instanti
On Tue, 2022-11-01 at 13:32 -0600, Jeff Law wrote:
> 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
Code such as:
#include __FILE__
can interact poorly with the *-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 compile time. Ingoring
filename remapping for directives allows
On Wed, 2022-08-17 at 13:10 +0100, Richard Purdie via Gcc-patches
wrote:
> Avoid encoding full build paths into headers, just use the basename of the
> file.
> This aids build reproducibility where the build paths vary and source is saved
> for debugging purposes.
>
> libgcc/ChangeLog:
>
> *
Hi Aldy,
I'm trying to use Ranger to determine if a range of an expression is a single
bit.
If possible in case of a mask then also the position of the bit that's being
checked by the mask (or the mask itself).
Do you have any pointers/existing code I can look at to do this?
Kind regards,
Tam
Hi!
Jon pointed out that we have TODO: _Bfloat16 in .
Right now _S_fp_fmt() returns _Binary16 for _Float16, __fp16 as well
as __bf16 and it actually works because we don't have a special handling
of _Binary16. So, either we could just document that, but I'm a little bit
afraid if HPPA or MIPS don
> > > +@item x86-vect-unroll-min-ldst-threshold
> > > +The vectorizer will check with target information to determine
> > > +whether unroll it. This parameter is used to limit the mininum of
> > > +loads and stores in the main loop.
> > >
> > > It's odd to "limit" the minimum number of something.
On Wed, Nov 02, 2022 at 10:13:44AM +0100, Rainer Orth wrote:
> trunk bootstrap recently broke on Solaris like this:
>
> /vol/gcc/src/hg/master/local/gcc/builtins.cc:2104:8: error: pasting
> "CFN_BUILT_IN_" and "(" does not give a valid preprocessing token
> 2104 | case CFN_BUILT_IN_##MATHFN:
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 overloads in _Float128 overloads.
The powerpc64le case (with explici
trunk bootstrap recently broke on Solaris like this:
/vol/gcc/src/hg/master/local/gcc/builtins.cc:2104:8: error: pasting
"CFN_BUILT_IN_" and "(" does not give a valid preprocessing token
2104 | case CFN_BUILT_IN_##MATHFN: \
|^
/vol/gcc/src/hg/master/local/gcc/builti
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
> this patch is likely papering over it.
I'll take a deeper look into
On Wed, Nov 2, 2022 at 9:03 AM Kewen.Lin wrote:
>
> Hi,
>
> This is to fix the failure on powerpc as reported in PR106806,
> the test case requires tree ifcvt pass to perform on that loop,
> and it relies on masked_load support. The fix is to guard the
> expected scan with vect_masked_load effect
On Tue, Nov 1, 2022 at 2:20 PM Andrew MacLeod via Gcc-patches
wrote:
>
> 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
Hi,
This is to fix the failure on powerpc as reported in PR106806,
the test case requires tree ifcvt pass to perform on that loop,
and it relies on masked_load support. The fix is to guard the
expected scan with vect_masked_load effective target.
As tested on powerpc64{,le}-linux-gnu and aarch64
Hi,
As the test case in PR107412 shows, we can fold IFN .LEN_{LOAD,
STORE} into normal vector load/store if the given length is known
to be equal to the length of the whole vector. It would help to
improve overall cycles as normally the latency of vector access
with length in bytes is bigger than
85 matches
Mail list logo
