On Thu, Jul 6, 2023 at 11:46 PM wrote:
>
> > +; False dependency happens on destination register which is not really
> > +; used when moving all ones to vector register
> > +(define_split
> > + [(set (match_operand:VMOVE 0 "register_operand")
> > + (match_operand:VMOVE 1 "int_float_vector_all
On Thu, Jul 6, 2023 at 11:37 PM Maciej W. Rozycki wrote:
>
> The pr97428.c test assumes support for vectors of doubles, but some
> targets only support vectors of floats, causing this test to fail with
> such targets. Limit this test to targets that support vectors of
> doubles then.
OK.
>
On Fri, Jul 7, 2023 at 2:02 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Fri, Jul 7, 2023 at 7:31 AM liuhongt wrote:
> >
> > > Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> > > and the other emitting UNSPEC_IEEE_MIN.
> > Splitted.
> >
> > > The test involves blendv instr
On Thu, Jul 6, 2023 at 11:37 PM Maciej W. Rozycki wrote:
>
> The bb-slp-pr95839.c test assumes quad-single float vector support, but
> some targets only support pairs of floats, causing this test to fail
> with such targets. Limit this test to targets that support at least
> 128-bit vectors then,
>From 5151cf943987347edbc3707f08f0da8cd9f49f88 Mon Sep 17 00:00:00 2001
From: Rishi Raj
Date: Fri, 7 Jul 2023 10:15:57 +0530
Subject: [PATCH] lto: Fixed test(U*) used but never defined error.
This Patch fixes the error during bootstrapped build.
Signed-off-by: Rishi Raj
---
gcc/lto-object.cc
On Thu, Jul 6, 2023 at 11:36 PM Maciej W. Rozycki wrote:
>
> Similarly to checks for vectors of 32 bits and 64 bits being supported
> add one for vectors of 128 bits.
OK
> gcc/testsuite/
> * lib/target-supports.exp (check_effective_target_vect128): New
> procedure.
> ---
On Thu, Jul 6, 2023 at 8:53 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> > [...] this part [...]
>
> ... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
> (Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
> and conv
On Thu, Jul 6, 2023 at 6:18 PM Xi Ruoyao via Gcc-patches
wrote:
>
> If a bit-field is signed and it's wider than the output type, we must
> ensure the extracted result sign-extended. But this was not handled
> correctly.
>
> For example:
>
> int x : 8;
> long y : 55;
> bool z : 1;
>
>
On Fri, Jul 7, 2023 at 7:31 AM liuhongt wrote:
>
> > Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> > and the other emitting UNSPEC_IEEE_MIN.
> Splitted.
>
> > The test involves blendv instruction, which is SSE4.1, so it is
> > pointless to test it without -msse4.1. Please
On Thu, 6 Jul 2023, Jan Hubicka wrote:
> Hi,
> original scale_loop_profile was implemented to only handle very simple loops
> produced by vectorizer at that time (basically loops with only one exit and no
> subloops). It also has not been updated to new profile-count API very
> carefully.
> Since
> Am 06.07.2023 um 19:50 schrieb Richard Sandiford :
>
> Richard Biener via Gcc-patches writes:
>>> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
>>> wrote:
>>>
>>> Hi,
>>>
>>> If a loop is unrolled by n times during vectoriation, two steps are used to
>>> calculate the inducti
> Please split the above pattern into two, one emitting UNSPEC_IEEE_MAX
> and the other emitting UNSPEC_IEEE_MIN.
Splitted.
> The test involves blendv instruction, which is SSE4.1, so it is
> pointless to test it without -msse4.1. Please add -msse4.1 instead of
> -march=x86_64 and use sse4_runtime
on 2023/7/7 07:00, Peter Bergner wrote:
> On 7/6/23 5:54 PM, Peter Bergner wrote:
>> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>>> @@ -0,0 +1,153 @@
>>> +/* { dg-do run { target { powerpc*-*-* } } } */
>>
>> powerpc*-*-
Hi Carl,
Some more minor comments are inline below on top of Peter's insightful
review comments.
on 2023/7/1 08:58, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 2, Went back thru the requirements and emails. Not sure where I
> came up with the requirement for an overloaded version with doubl
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch is adding cond_len_* operations pattern for target support loop
control with length.
These patterns will be used in these following case:
1. Integer division:
void
f (int32_t *restrict a, int32_t *restrict b, int32_t *restrict c, int
Hi Jeff,
Thanks for your help.
Actually I have write access as I was added to the "contributor list". Anyway,
that's very kind of you to help committing the patch.
Thanks,
-Hao
From: Jeff Law
Sent: Friday, July 7, 2023 0:06
To: Richard Biener; Hao Liu O
Hi Carl,
on 2023/7/6 23:33, Carl Love wrote:
> GCC maintainers:
>
> Ver 4. Fixed a few typos. Redid the tests to create separate run and
> compile tests.
Thanks! This new version looks good, excepting that we need vsx_hw
for run and two nits, see below.
>
> Ver 3. Added __attribute__ ((noip
Committed, thanks Robin and Kito.
Pan
-Original Message-
From: Robin Dapp
Sent: Thursday, July 6, 2023 11:30 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; Wang,
Yanzhang ; kito.ch...@gmail.com; Robin Dapp
Subject: Re:
Stepping down as maintainer for ARC and Epiphany
* MAINTAINERS (CPU Port Maintainers): Remove myself as ARC end
epiphany maintainer.
(Write After Approval): Add myself.commit b3f20dd75e9255fc9d56d4f020972469dd671a3a
Author: Joern Rennecke
Date: Fri Jul 7 01:02:28 2023 +
On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> > On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -9894,6 +9894,8 @@ rs6000_legitimate_a
On 7/6/23 5:54 PM, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>> @@ -0,0 +1,153 @@
>> +/* { dg-do run { target { powerpc*-*-* } } } */
>
> powerpc*-*-* is the default for this test directory, so yo
Hi!
On Mon, 2023-06-19 16:29:53 +0800, Jie Mei wrote:
> There are shortened bitwise instructions in the mips16e2 ASE,
> for instance, ANDI, ORI/XORI, EXT, INS etc. .
>
> This patch adds these instrutions with corresponding tests.
[...]
Starting with this patch, I see some new warning:
[all 20
On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> rs6000, __builtin_set_fpscr_rn add retrun value
s/retrun/return/
Maybe better written as:
rs6000: Add return value to __builtin_set_fpscr_rn
> Change the return value from void to double. The return value consists of
> the FPSCR fields DR
I get the following warning which prevents gcc from bootstrapping due to
-Werror:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt.cc: In
function ‘void {anonymous}::process_chain_from_load(gimple*)’:
/home/meissner/fsf-src/work124-sfsplat/gcc/config/rs6000/rs6000-p10sfopt
The pr97428.c test assumes support for vectors of doubles, but some
targets only support vectors of floats, causing this test to fail with
such targets. Limit this test to targets that support vectors of
doubles then.
gcc/testsuite/
* gcc.dg/vect/pr97428.c: Limit to `vect_doubl
The bb-slp-pr95839.c test assumes quad-single float vector support, but
some targets only support pairs of floats, causing this test to fail
with such targets. Limit this test to targets that support at least
128-bit vectors then, and add a complementing test that can be run with
targets that
Similarly to checks for vectors of 32 bits and 64 bits being supported
add one for vectors of 128 bits.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_vect128): New
procedure.
---
gcc/testsuite/lib/target-supports.exp |6 ++
1 file changed, 6 in
Hi,
In the course of verifying an out-of-tree RISC-V target that has a vendor
extension providing hardware support for vector operations on pairs of
single floating-point values (similar to MIPS paired-single or Power SPE
vector types) I have come across a couple of tests that fail just because
Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao:
> Hi, Kees,
>
> I have updated my V1 patch with the following changes:
> A. changed the name to "counted_by"
> B. changed the argument from a string to an identifier
> C. updated the documentation and testing cases accordingly.
>
> A
On Thu, Jul 06, 2023 at 03:00:28PM +0200, Richard Biener via Gcc-patches wrote:
> > + (if (types_match (type, @1))
> > + (bit_not (bit_and @1 (convert @0)))
> > + (if (types_match (type, @0))
> > +(bit_not (bit_and (convert @1) @0))
> > +(convert (bit_not (bit_and @0 (convert @1)))
On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9894,6 +9894,8 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
>> bool reg_ok_strict)
>>
>>/*
Hi, Kees,
I have updated my V1 patch with the following changes:
A. changed the name to "counted_by"
B. changed the argument from a string to an identifier
C. updated the documentation and testing cases accordingly.
And then used this new gcc to test
https://github.com/kees/kernel-tools/blob/tru
Hi!
On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> [...] this part [...]
... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
and converted to those a number of 'htab' instances.
It doesn't really interfe
On 6/28/23 3:07 AM, Kewen.Lin wrote:
> I think the reason why we need to check common_deferred_options is at this
> time
> we can't distinguish the fixed_regs[2] is from the initialization or command
> line
> user explicit specification. But could we just update the FIXED_REGISTERS
> without
>
Richard Biener via Gcc-patches writes:
> On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> If a loop is unrolled by n times during vectoriation, two steps are used to
>> calculate the induction variable:
>> - The small step for the unrolled ith-copy: vec_1 = vec
Hi!
On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> while generating vector pairs of load & store instruction, the src address
> was treated as an altivec type and that type of address is invalid for
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, July 6, 2023 4:21 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject: Re: [PATCH] arm: Fix MVE intrinsics support with LTO (PR
> target/110268)
>
>
>
> On Wed, 5 Jul 2023 a
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct I
On 7/6/23 06:44, Richard Biener via Gcc-patches wrote:
On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
wrote:
Hi,
If a loop is unrolled by n times during vectoriation, two steps are used to
calculate the induction variable:
- The small step for the unrolled ith-copy: vec_1 = v
This patch allows 'declare mapper' mappers to be used on 'omp target
data', 'omp target enter data' and 'omp target exit data' directives.
For each of these, only explicit mappings are supported, unlike for
'omp target' directives where implicit uses of variables inside an
offload region might trig
+; False dependency happens on destination register which is not really
+; used when moving all ones to vector register
+(define_split
+ [(set (match_operand:VMOVE 0 "register_operand")
+ (match_operand:VMOVE 1 "int_float_vector_all_ones_operand"))]
+ "TARGET_AVX512F && reload_completed
+
Pushed to trunk. Backports to 11, 12 and 13 will follow.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/110574
* doc/xml/manual/configure.xml: Describe stdio_pure argument to
--enable-cstdio.
* doc/html/manual/configure.html: Regenerate.
---
libstdc++-v3/doc/html/
GCC maintainers:
Ver 4. Fixed a few typos. Redid the tests to create separate run and
compile tests.
Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some
of the scan-assembler-times checks to cover multiple similar
instructions. Change the function check macro to a macro to ge
Kewen:
On Tue, 2023-07-04 at 10:49 +0800, Kewen.Lin wrote:
>
> >
> > The tests are broken up into a seriers of files for related
> > tests. The
>
> s/seriers/series/
Fixed
>
> > new tests are runnable tests to verify the builtin argument types
> > and the
> > functional correctness of ea
Hi Pan,
thanks, I think that works for me as I'm expecting these
parts to change a bit anyway in the near future.
There is no functional change to the last revision that
Kito already OK'ed so I think you can go ahead.
Regards
Robin
On 7/6/23 00:48, Christoph Müllner wrote:
Thanks for this!
Of course I was "lucky" and ran into the issue that the patterns did not match,
because of unexpected MULT insns where ASHIFTs were expected.
But after reading enough of combiner.cc I understood that this is on purpose
(for addresses
Hi Alex,
> On 6 Jul 2023, at 15:01, Alex Coplan wrote:
>
> On 20/06/2023 15:08, Iain Sandoe wrote:
>> again, thanks for working on this and for fixing the SDK blocker.
>>
>>> On 20 Jun 2023, at 13:30, Alex Coplan wrote:
>>>
>>
>>> The patch can now survive bootstrap on Darwin (it looks like
On Wed, 5 Jul 2023 at 19:07, Kyrylo Tkachov wrote:
> Hi Christophe,
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Monday, June 26, 2023 4:03 PM
> > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> > Richard Sandiford
> > Cc: Christophe Lyon
> > Subject: [PATCH] arm: Fix M
Hi,
this patch makes loop-ch and loop unrolling to fix profile in case the loop is
known to not iterate at all (or iterate few times) while profile claims it
iterates more. While this is kind of symptomatic fix, it is best we can do
incase profile was originally esitmated incorrectly.
In the test
As per David's suggestion.
- Improved leading comment of "is_placement_new_p"
- "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
integral type and that arg 1, if any, is of pointer type.
- Changed ambiguous "int" to "int8_t" and "int64_t" in placement-new-size.C
to trigger a
No, vld/vst can't guaranteed to be atomic in this condition. Seems we
can't implement this on LoongArch for now.
On 2023/7/5 20:57, Xi Ruoyao wrote:
A question: is vld/vst guaranteed to be atomic if the accessed address
is aligned? If true we can use them to implement lock-free 128-bit
atomic l
Hi,
original scale_loop_profile was implemented to only handle very simple loops
produced by vectorizer at that time (basically loops with only one exit and no
subloops). It also has not been updated to new profile-count API very carefully.
Since I want to use it from loop peeling and unlooping, I
On Thu, Jul 6, 2023 at 3:48 PM Roger Sayle wrote:
>
> > On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle
> > wrote:
> > >
> > >
> > > Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> > > result in surprising code. Consider the example below (from PR 43644):
> > >
> > > __uint128 f
Hi,
this patch applies some TLC to update_bb_profile_for_threading. The function
resales
probabilities by:
FOR_EACH_EDGE (c, ei, bb->succs)
c->probability /= prob;
which is correct but in case prob is 0 (took all execution counts to the newly
constructed path), this leads to undefi
Hi Iain,
On 20/06/2023 15:08, Iain Sandoe wrote:
> Hi Alex
>
> again, thanks for working on this and for fixing the SDK blocker.
>
> > On 20 Jun 2023, at 13:30, Alex Coplan wrote:
> >
>
> > The patch can now survive bootstrap on Darwin (it looks like we'll need
> > to adjust some Objective-C+
Hi Jason,
On 11/05/2023 16:25, Jason Merrill wrote:
> On 5/9/23 08:07, Alex Coplan wrote:
> > This patch implements clang's __has_feature and __has_extension in GCC.
>
> Thanks!
Thanks a lot for the review, I posted a v2 patch incorporating your
feedback here:
https://gcc.gnu.org/pipermail/gcc-p
gcc/ChangeLog:
* doc/extend.texi (ARC Built-in Functions): Update documentation
with missing builtins.
---
gcc/doc/extend.texi | 55 +
1 file changed, 55 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d701b4d1
> On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle
> wrote:
> >
> >
> > Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> > result in surprising code. Consider the example below (from PR 43644):
> >
> > __uint128 foo(__uint128 x, unsigned long long y) {
> > return x+y;
> > }
> >
>
The stmt comparison function for GIMPLE_ASSIGNs for tail merging
still looks like it deals with pre-tuples IL. The following
attempts to fix this, not only comparing the first operand (sic!)
of stmts but all of them plus also compare the operation code.
Bootstrapped and tested on x86_64-unknown-l
On Wed, Jul 5, 2023 at 3:42 PM Drew Ross via Gcc-patches
wrote:
>
> Adds a simplification for (~X | Y) ^ X to be folded into ~(X & Y).
> Tested successfully on x86_64 and x86 targets.
>
> PR middle-end/109986
>
> gcc/ChangeLog:
>
> * match.pd ((~X | Y) ^ X -> ~(
On Thu, Jul 6, 2023 at 2:04 PM Roger Sayle wrote:
>
>
> Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
> result in surprising code. Consider the example below (from PR 43644):
>
> __uint128 foo(__uint128 x, unsigned long long y) {
> return x+y;
> }
>
> which currently resul
On Wed, Jul 5, 2023 at 8:44 AM Hao Liu OS via Gcc-patches
wrote:
>
> Hi,
>
> If a loop is unrolled by n times during vectoriation, two steps are used to
> calculate the induction variable:
> - The small step for the unrolled ith-copy: vec_1 = vec_iv + (VF/n * Step)
> - The large step for the w
Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
result in surprising code. Consider the example below (from PR 43644):
__uint128 foo(__uint128 x, unsigned long long y) {
return x+y;
}
which currently results in 6 consecutive movq instructions:
foo:movq%rsi, %rax
On Linux/x86_64,
e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
Author: Jan Beulich
Date: Wed Jul 5 09:49:16 2023 +0200
x86: yet more PR target/100711-like splitting
caused
FAIL: gcc.target/i386/pr100711-1.c scan-assembler
On Linux/x86_64,
2d11c99dfca3cc603dbbfafb3afc41689a68e40f is the first bad commit
commit 2d11c99dfca3cc603dbbfafb3afc41689a68e40f
Author: Jan Beulich
Date: Wed Jul 5 09:41:09 2023 +0200
x86: use VPTERNLOG also for certain andnot forms
caused
FAIL: gcc.target/i386/pr53652-1.c scan-assembl
From: Claire Dross
gcc/ada/
* gcc-interface/Make-lang.in: Add object files of specification
files.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/gcc-interface/Make-lang.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/ada/gcc-interface/Make-lang.
From: Viljar Indus
Gigi assumes that the value of range expressions is an integer literal.
Force evaluation of such expressions since static non-literal expressions
are not always evaluated to a literal form by gnat.
gcc/ada/
* sem_attr.adb (analyze_attribute.check_array_type): Replace
From: Claire Dross
The aim of this refactoring is to avoid unnecessary dependencies
between Image and Value units even though they share the same
specification functions. These functions are grouped inside ghost
packages which are then withed by Image and Value units.
gcc/ada/
* libgnat
From: Viljar Indus
gcc/ada/
* sem_util.adb (Is_Fully_Initialized_Type): Avoid recalculating
the underlying type twice.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_util.adb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/sem_u
From: Viljar Indus
The limitation of resetting the FPU mode for non 80-bit
precision was not referenced from "Creating a Stand-alone
Library to be used in a non-Ada context". Reference it the same
way it is already referenced from "Interfacing to C".
gcc/ada/
* doc/gnat_ugn/the_gnat_com
From: Viljar Indus
Find_Optional_Prim_Op can crash when the Underlying_Type is Empty.
This can happen when you are dealing with a structure type with a
private part that does not have its Full_View set yet.
gcc/ada/
* exp_util.adb (Find_Optional_Prim_Op): Stop deriving primitive
From: Yannick Moy
SPARK_Mode On can only be used on library-level entities.
Improve the error message here.
gcc/ada/
* errout.ads: Add explain code.
* sem_prag.adb (Check_Library_Level_Entity): Refine error message
and add explain code.
Tested on x86_64-pc-linux-gnu, co
From: Steve Baird
In some cases involving a discriminated protected type with an array
component that is subject to a discriminant-dependent index constraint,
where the element type of the array requires finalization and the array
type has not yet been frozen at the point of the declaration of th
On Thu, 6 Jul 2023, Tamar Christina wrote:
> > On Wed, 28 Jun 2023, Tamar Christina wrote:
> >
> > > Hi All,
> > >
> > > expand_vector_piecewise does not support VLA expansion as it has a
> > > hard assert on the type not being VLA.
> > >
> > > Instead of just failing to expand and so the call ma
The following consolidates an assert that now hits for ppc64le
with an earlier check we already do, simplifying
vect_determine_partial_vectors_and_peeling and getting rid of
its now redundant argument.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/11056
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > expand_vector_piecewise does not support VLA expansion as it has a
> > hard assert on the type not being VLA.
> >
> > Instead of just failing to expand and so the call marked unsupported we ICE.
> > This adjust it so we don't and
Many thanks to Hans-Peter Nilsson for reminding me that new RTX codes
need to be added to dwarf2out.cc's mem_loc_descriptor, and for doing
this for BITREVERSE. This patch does the same for the recently added
COPYSIGN. I'd been testing these on a target that doesn't use DWARF
(nvptx-none) and so
> -Original Message-
> From: Mo, Zewei
> Sent: Thursday, July 6, 2023 2:37 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] Initial Granite Rapids D Support
>
> Hi all,
>
> This patch is to add initial support for Granite Rapids D for GCC.
> T
In this PR we face the issue that LIM speculates a load when
hoisting it out of the loop (since it knows it cannot trap).
Unfortunately this exposes undefined behavior when the load
accesses memory with the wrong dynamic type. This later
makes PRE use that representation instead of the original
wh
On Thu, Jul 6, 2023 at 8:39 AM Hongyu Wang wrote:
>
> Hi,
>
> This is a follow-up patch for
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623525.html
> that updates document about x86 inlining rules.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * doc/extend.texi: Move x86 inlining rule
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Thursday, July 6, 2023 3:09 PM
To: Ju-Zhe Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] VECT: Fix ICE of variable stride on strie
On Thu, 6 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richi.
>
> Sorry for making mistake on LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
> with SELECT_VL loop control.
OK.
> Consider this following case:
> #define TEST_LOOP(DATA_TYPE, BITS)
82 matches
Mail list logo
