The test used vect_perm_short for the vectorized scanning but
vect_perm3_short for whether that's done with SLP. We're now
generally expecting SLP to be used - even as fallback, so the
following adjusts both to match up, fixing the powerpc64 reported
testsuite issue.
Tested on x86_64-unknwon-linu
On Fri, Sep 20, 2024 at 08:01:58AM +0200, Richard Biener wrote:
> > P.S. I have a patch to replace UNSPEC_IEEE_M{AX,IN} with IF_THEN_ELSE
> > (except for the 3dNOW! PFMIN/MAX, those actually are documented to behave
> > differently), but it actually doesn't improve anything much, as
> > simplify_co
On Thu, Sep 19, 2024 at 4:37 PM Jakub Jelinek wrote:
>
> On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote:
> > On 9/19/24 7:57 AM, Richard Biener wrote:
> > > On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
> > > >
> > > > Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler
On Fri, Sep 20, 2024 at 3:07 AM Andrew Pinski wrote:
>
> For generic, `a != 0 ? a * b : 0` would match where `b` would be an expression
> which trap (in the case of the testcase, it was an integer division but it
> could be any).
>
> This fixes the issue by adding a condition for `(a != 0 ? expr
On Thu, Sep 19, 2024 at 10:49 PM Jakub Jelinek wrote:
>
> Hi!
>
> min/max patterns for intrinsics which on x86 result in the second
> input operand if the two operands are both zeros or one or both of them
> are a NaN shouldn't use SMIN/SMAX RTL, because that is similarly to
> MIN_EXPR/MAX_EXPR un
On Thu, Sep 19, 2024 at 10:50 PM Jakub Jelinek wrote:
>
> Hi!
>
> min/max patterns for intrinsics which on x86 result in the second
> input operand if the two operands are both zeros or one or both of them
> are a NaN shouldn't use SMIN/SMAX RTL, because that is similarly to
> MIN_EXPR/MAX_EXPR un
> > "Kong, Lingling" writes:
> > > Hi,
> > >
> > > This version has added a new optab named 'cfmovcc'. The new optab is
> > > used in the middle end to expand to cfcmov. And simplified my patch
> > > by trying to generate the conditional faulting movcc in
> > > noce_try_cmove_arith
> > function.
>
I'd love for (something like) gcc-testresults@ to be usefully
searchable (it can be done but... lacks), so please allow me:
On Fri, 13 Sep 2024, Frank Ch. Eigler wrote:
> diff --git a/contrib/test_summary b/contrib/test_summary
> index 5760b053ec27..867ada4d6b81 100755
> --- a/contrib/test_summar
Fix 'do-do' typos (should be 'dg-do'). No change in logs.
gcc/testsuite/ChangeLog:
* g++.dg/other/operator2.C: Fix dg-do directive.
* gcc.dg/Warray-bounds-67.c: Ditto.
* gcc.dg/cpp/builtin-macro-1.c: Ditto.
* gcc.dg/tree-ssa/builtin-snprintf-3.c: Ditto.
* o
I added some whitespace unintentionally in r15-3723-g284c03ec79ec20,
fix that.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Fix whitespace.
---
Pushed as obvious.
gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/testsu
> Am 20.09.2024 um 06:02 schrieb Andrew Pinski :
>
> There was only a few uses PHI_RESULT_PTR so lets remove it and use
> gimple_phi_result_ptr
> or gimple_phi_result directly instead.
> Since I was modifying ssa-iterators.h for the use of PHI_RESULT_PTR, change
> the use
> of PHI_RESULT the
In this case, they were all harmless in reality (no diff in test logs).
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-array-1.c: Fix dg-do directive syntax.
* gcc.dg/debug/btf/btf-bitfields-1.c: Ditto.
* gcc.dg/debug/btf/btf-bitfields-2.c: Ditto.
* gcc.dg/debug/b
There was only a few uses PHI_RESULT_PTR so lets remove it and use
gimple_phi_result_ptr
or gimple_phi_result directly instead.
Since I was modifying ssa-iterators.h for the use of PHI_RESULT_PTR, change the
use
of PHI_RESULT there to be gimple_phi_result instead.
This also removes one extra ind
This patch adds some of the float point instructions from
MIPS32 Release 6(mips32r6) with their respective built-in
functions and tests:
min_a_s, min_a_d
max_a_s, max_a_d
rint_s, rint_d
class_s, class_d
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_minmax): Include
From: Pan Li
Form 4:
#define DEF_SAT_S_ADD_FMT_4(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_add_##T##_fmt_4 (T x, T y) \
{ \
T sum;
From: Pan Li
This patch would like to add testcases of the signed scalar SAT_ADD
for form 3. Aka:
Form 3:
#define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_add_##T##_fmt_3 (T x, T y) \
{
On Thu, Sep 19, 2024 at 4:35 PM Jakub Jelinek wrote:
>
> On Thu, Sep 19, 2024 at 08:17:24AM +0200, Richard Biener wrote:
> > On Wed, Sep 18, 2024 at 7:33 PM Jakub Jelinek wrote:
> > >
> > > On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> > > > +1 I'd much rather learn about
For generic, `a != 0 ? a * b : 0` would match where `b` would be an expression
which trap (in the case of the testcase, it was an integer division but it
could be any).
This fixes the issue by adding a condition for `(a != 0 ? expr : 0)` to check
for expressions
which have side effects or traps.
Noticed how to fix this while working on the other patch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This implements part of P1787 to no longer complain about redeclaring an
entity via using-decl other than in a class scope.
PR c++/116160
gcc/cp/ChangeLog:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively I could solve this the other way around (have a new
'old_target = strip_using_decl (old)' and replace all usages of 'old'
except the usages in this patch); this is more churn but probably better
matches how other functi
GCC maintainers:
Please ignore this patch. Attached the wrong patch to the message.
Sorry for the noise.
Carl
On 9/19/24 4:40 PM, Carl Love wrote:
GCC maintainers:
This patch removes an expected value change that was made to verify
the error checking for the test
GCC maintainers:
This patch removes an expected value change that was made to verify the
error checking for the test was working. Apparently, it didn't get
removed from the final patch.
The patch fixes the single test error in the builtins-1-10-runnable.c test.
The patch was run on a Power
On Thu, Aug 22, 2024 at 2:45 PM Andrew Pinski wrote:
>
> Bootstrapping and using --disable-libstdcxx will cause a build failure deep
> in compiling
> stage2 so instead error out early in the toplevel configure so it is more
> user friendly.
>
> Bootstrapped and tested on x86_64-linux-gnu.
> Also
Sam James writes:
> Sam James writes:
>
>> libtool defaults to filtering flags passed at link-time.
>>
>> This brings the filtering in GCC's 'fork' of libtool into sync with
>> upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e.
>>
>> In particular, this now allows some harmless di
Arsen Arsenović writes:
> Gentle ping again. Full patch:
> https://inbox.sourceware.org/gcc-patches/86y14ptvdi@aarsen.me/
And again. To clarify, the above is a v2 of sorts (it has the comment
fixed, I just didn't update the subject).
TIA, have a lovely day.
--
Arsen Arsenović
signature
On Thu, 19 Sep 2024, mmalcom...@nvidia.com wrote:
> 6) Anything special about floating point maths that I'm tripping up on?
Correct atomic operations with floating-point operands should ensure that
exceptions raised exactly correspond to the operands for which the
operation succeeded, and not t
On Tue, Sep 17, 2024 at 11:53 PM Richard Biener
wrote:
>
> On Tue, Sep 17, 2024 at 4:36 AM Andrew Pinski
> wrote:
> >
> > This adds simple_dce_worklist to both the SLP vectorizer and the loop based
> > vectorizer.
> > This is a step into removing the dce after the loop based vectorizer. That
>
On Mon, Sep 16, 2024 at 10:52:43AM +0200, Mikael Morin wrote:
> > While I understand the intent of 'positive form' vs 'negative form', the
> > above might be clearer as
> >
> > Usage of intrinsics can be implemented either by generating a call
> > to the libgfortran library function or by
Hi!
Regarding ongoing maintenance efforts, and avoiding to build multilib
variants that probably nobody uses apart from a few of us testing these
out of routine (via building/linking with explicit '-mptx=3.1'), I
propose: "GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated",
see attached,
On Tue, 17 Sep 2024, Martin Uecker wrote:
> Here is a fix for a mistake I made when recursively checking for
> type compatibility.
>
>
> Bootstrapped and regression tested on x86-64.
>
>
> c: fix crash when checking for compatibility of structures [PR116726]
>
> When checking for
On Fri, 13 Sep 2024, Mikael Morin wrote:
> *PING*
>
> Joseph, could you take a quick look at the handling of the new option?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html
Individual new options like this are expected to be reviewed by
maintainers / reviewers for the rel
Hi!
The following patch uses type_id_in_expr_sentinel in a few spots which
did it all manually.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-09-19 Jakub Jelinek
* parser.cc (cp_parser_postfix_expression): Use
type_id_in_expr_sentinel instead of ma
Hi!
min/max patterns for intrinsics which on x86 result in the second
input operand if the two operands are both zeros or one or both of them
are a NaN shouldn't use SMIN/SMAX RTL, because that is similarly to
MIN_EXPR/MAX_EXPR undefined what will be the result in those cases.
The following patch
On Thu, Sep 19, 2024 at 08:17:24AM +0200, Richard Biener wrote:
> On Wed, Sep 18, 2024 at 7:33 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> > > +1 I'd much rather learn about this kind of error before the code reaches
> > > a review tool :)
On 9/18/24 1:20 PM, Thomas Koenig wrote:
OK for trunk?
OK and thanks.
Jerry
--- snip ---
On 9/19/24 5:35 PM, Marek Polacek wrote:
On Tue, Sep 17, 2024 at 12:50:46PM -0400, Jason Merrill wrote:
On 9/16/24 7:14 PM, Marek Polacek wrote:
+/* Mark an explicitly defaulted function FN as =deleted and warn.
+ IMPLICIT_FN is the corresponding special member function that
+ would have be
Am 19.09.24 um 12:16 schrieb Andre Vehreschild:
Hi Thomas,
submitting your patch as part of the mail got it corrupted by some mailer
adding line breaks. It does not apply for me. Because I can't test it, I have
more questions, see below:
I have attached it.
On Wed, 18 Sep 2024 22:22:15 +020
Stefan Schulze Frielinghaus writes:
> I have been missing the two test cases and removed them since they
> depend on -mno-lra.
Can't approve but it looks right. Thanks for handling it, especially so quickly!
>
> -- 8< --
>
> Since the old reload pass is about to be removed and we defaulted to L
Am 19.09.24 um 11:55 schrieb Andre Vehreschild:
Hi Thomas,
thanks for the patch. I have one proposal/question and one missing verb (IMO).
Else the patch looks fine to me. Ok for trunk.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 829ab00c665..e5ffe67 100644
---
Minor update – addressing the issues that Andre raised (thanks!):
'Add.' → 'New functions.' in the ChangeLog for 'fortran.c' and otherwise
libgomp.texi changes, only:
A bunch of typo fixes (preexisting and in the new text). I also added an
made-up example UUID for the GPUs, which should help
Hi!
I had not noticed that this patch makes gcc.target/arm/pr112337.c fail
because __builtin_mve_vldrwq_sv4si is no longer available.
Adding this fixes the problem:
diff --git a/gcc/testsuite/gcc.target/arm/pr112337.c
b/gcc/testsuite/gcc.target/arm/pr112337.c
index 10b7881b9f9..599229c1db0 1
Ping.
On Thu, Sep 05, 2024 at 06:32:28PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
>
> -- >8 --
> We ICE in decay_conversion with this test:
>
> struct S {
> S() {}
> };
> S arr[1][1];
> auto [m](arr3);
>
> But not when the last li
On Tue, Sep 17, 2024 at 12:50:46PM -0400, Jason Merrill wrote:
> On 9/16/24 7:14 PM, Marek Polacek wrote:
> > +/* Mark an explicitly defaulted function FN as =deleted and warn.
> > + IMPLICIT_FN is the corresponding special member function that
> > + would have been implicitly declared. */
> >
Thanks Robin.
> I think those tests don't really need to check for vsetvl anyway.
Looks only scan asm for RVV fixed-pointer insn is good enough for vector part,
which
is somehow different to scalar. I will make the change after this patch pushed.
Pan
-Original Message-
From: Robin Dapp
On Thu, 19 Sept 2024 at 14:12, wrote:
>
> From: Matthew Malcomson
>
> Hello, this is an RFC for adding an atomic floating point fetch_add builtin
> (and variants) to GCC. The atomic fetch_add operation is defined to work
> on the base floating point types in the C++20 standard chapter 31.7.3, an
On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote:
> On 9/19/24 7:57 AM, Richard Biener wrote:
> > On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
> > >
> > > Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
> >
> > I'm fine with this in general - do we have
Hi Andre,
thanks for reading the patch + commenting.
Andre Vehreschild wrote:
in the changelog of libgomp:
* fortran.c (omp_get_uid_from_device_,
omp_get_uid_from_device_8_): Add.
"Add." what? Can you be more specific, i.e. is it just a dummy or prototype?
Neither. It is a f
On Thu, 2024-09-19 at 10:21 -0400, Jason Merrill wrote:
/* snip */
> Another possibility would be to just say GCC 5, and adjust that upward
> if we run into problems.
I'd remind that GCC 5.1 is known as incapable to bootstrap recent GCC
releases due to PR 65801.
--
Xi Ruoyao
School of
The following reverts a bogus fix done for PR101009 and instead makes
sure we get into the same_access_functions () case when computing
the distance vector for g[1] and g[1] where the constants ended up
having different types. The generic code doesn't seem to handle
loop invariant dependences. Th
On 9/19/24 7:57 AM, Richard Biener wrote:
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
I'm fine with this in general - do we have needs of bumping the requirement for
GCC 15 though? IMO we should bump once we are r
I have been missing the two test cases and removed them since they
depend on -mno-lra.
-- 8< --
Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.
PR target/113953
gcc/ChangeLog:
* config/s390/s390.cc (s390_lra_p): Rem
Hi all,
in PR84870 an ICE was reported, that has been fixed in the meantime by some
other patch. Nevertheless did a testcase reveal that the memory handling still
was not correct. I.e. the test case in the patch was answering 2 for both x.b.a
and y.b.a which is not correct.
For a coarray all memo
Hi Tobias,
in the changelog of libgomp:
* fortran.c (omp_get_uid_from_device_,
omp_get_uid_from_device_8_): Add.
"Add." what? Can you be more specific, i.e. is it just a dummy or prototype?
In the libgomp/libgomp.texi
+@node omp_get_uid_from_device
+@subsection @code{omp_get_ui
On 9/19/24 7:24 AM, Robin Dapp wrote:
Hi,
this fixes asm-scan fallout from r15-3712-g5e3a4a01785e2d where we allow
SLP with SELECT_VL.
Assisted by sed and regtested on rv64gcv_zvfh_zvbb.
Rather lengthy but obvious, so going to commit after a while if the CI is
happy. I think those tests do
On 9/19/24 4:11 AM, Li, Pan2 wrote:
So for the future I'd suggest you post those with a remark that you think
they're obvious and going to commit in a day (or some other reasonable
timeframe) if there are no complaints.
Oh, I see. Thanks Robin for reminding.
That would be perfect. Do you ha
On 9/19/2024 2:18 PM, Kyrylo Tkachov wrote:
Hi Claudio,
On 19 Sep 2024, at 15:09, Claudio Bantaloukas
wrote:
External email: Use caution opening links or attachments
The ACLE defines a new scalar type, __mfp8. This is an opaque 8bit types that
can only be used by fp8 intrinsics. Additio
Hi,
this fixes asm-scan fallout from r15-3712-g5e3a4a01785e2d where we allow
SLP with SELECT_VL.
Assisted by sed and regtested on rv64gcv_zvfh_zvbb.
Rather lengthy but obvious, so going to commit after a while if the CI is
happy. I think those tests don't really need to check for vsetvl anyway,
Hi all,
in order to know and potentially re-use a specific offload device
(reproducibility,
affinity wise close to a CPU (socket), …) a mapping between an (universal?)
unique
identifier and the OpenMP device number is useful. Thus, TR13 added support for
it.
This is a collateral patch caused
Hi Claudio,
> On 19 Sep 2024, at 15:09, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> The ACLE defines a new scalar type, __mfp8. This is an opaque 8bit types that
> can only be used by fp8 intrinsics. Additionally, the mfloat8_t type is made
From: Matthew Malcomson
Do demo implementation in AArch64 since that's the backend I'm most
familiar with.
Nothing much else to say -- nice to see that the demo implementation
seems to work as expected (being used for fetch_add, add_fetch and
sub_fetch even though it's only defined for fetch_sub
From: Matthew Malcomson
Need to implement something in the
Things implemented in this patch:
1) Update the optabs definitions to include floating point versions of
atomic fetch_add variants.
2) When expanding into a CAS loop in RTL because the floating point
optab is not implemented, there
From: Matthew Malcomson
As it stands there are still a few things to look at whether they could
be improved:
1) Need to find the exact version of automake to use. I'm using
automake 1.15.1 from https://ftp.gnu.org/gnu/automake/ but the
header is claiming I'm using automake 1.15.
2) The int
From: Matthew Malcomson
Signed-off-by: Matthew Malcomson
---
gcc/doc/extend.texi | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 66c99ef7a66..a3e3e7da5d6 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13501,6 +135
From: Matthew Malcomson
Hello, this is an RFC for adding an atomic floating point fetch_add builtin
(and variants) to GCC. The atomic fetch_add operation is defined to work
on the base floating point types in the C++20 standard chapter 31.7.3, and
extended to work for all cv-unqualified floating
From: Matthew Malcomson
Points to question here are:
1) Whether checking for this particular internal builtin is OK (this one
happens to be the one implementing the operation for a `double`, we
would have to rely on the approach that if anyone implements this
operation for a `double` the
From: Matthew Malcomson
Have a bit of an ugly mapping from floating point type to the builtin
using that type. Would like to find some code-sharing between this, the
function (in a later patch in this series) that finds the relevant mode
from a given builtin, and the general sync-builtins.def fi
From: Matthew Malcomson
This commit just defines the new names -- as yet don't implement them.
Saving this commit because this is one decision, and recording
what the decision was and why:
Adding new floating point builtins for each floating point type that
is defined in the general code *except
The ACLE defines a new scalar type, __mfp8. This is an opaque 8bit types that
can only be used by fp8 intrinsics. Additionally, the mfloat8_t type is made
available in arm_neon.h and arm_sve.h as an alias of the same.
This implementation uses an unsigned INTEGER_TYPE, with precision 8 to
represen
From: kelefth
In expressions like (a != b || ((a ^ b) & c) == d) and
(a != b || (a ^ b) == c), (a ^ b) is folded to false.
In the equivalent expressions (((a ^ b) & c) == d || a != b) and
((a ^ b) == c || a != b) this is not happening.
This patch adds the following simplifications in match.pd:
(
I have sent a new version
(https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663350.html).
I also added :c to the ne operations.
Thanks,
Konstantinos
On Wed, Sep 18, 2024 at 1:52 PM Richard Biener
wrote:
>
> On Wed, Sep 18, 2024 at 10:42 AM Konstantinos Eleftheriou
> wrote:
> >
> > On Mo
Hi all,
the attached patch fixes an ICE when compiling with -fcoarray=lib and using
(proc_-)pointer component in a coarray. The code was looking at the wrong
location for the caf-token.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild *
Marc Poulhiès writes:
> Nicolas Boulenguez writes:
>
>> PR ada/114065
>>
>> Hello.
>> Any news about these patches?
>
> Hello,
>
> Sorry about the delay. Arnaud already replied on BZ, but I'll add a few
> remarks.
Also, I forgot to mention that your changes don't include any changelog
(required
> In 0001-Ada-merge-all-timeval-and-timespec-definitions-and-c.patch:
>
> > - -- C timeval represent a duration (used in Select for example). This
> > - -- structure is composed of a number of seconds and a number of micro
> > - -- seconds. The timeval structure is not exposed here becaus
Nicolas Boulenguez writes:
> PR ada/114065
>
> Hello.
> Any news about these patches?
Hello,
Sorry about the delay. Arnaud already replied on BZ, but I'll add a few
remarks.
In 0001-Ada-merge-all-timeval-and-timespec-definitions-and-c.patch:
> - -- C timeval represent a duration (used in S
There's special-casing for equal access functions which bypasses
printing the distance vectors. The following makes sure we print
them always which helps debugging.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-data-ref.cc (build_classic_dist_vector): Move
d
Richard Sandiford writes:
> Evgeny Karpov writes:
>> + {
>> + rtx const_int = imm;
>> + const_int = XEXP (const_int, 0);
>> + XEXP (const_int, 1) = GEN_INT(const_offset % (1 << 20));
>
> CONST_INTs are shared objects, so we can
> On 18 Sep 2024, at 20:33, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> From 05e010a4ad5ef8df082b3e03b253aad85e2a270c Mon Sep 17 00:00:00 2001
>> From: Jennifer Schmitz
>> Date: Tue, 17 Sep 2024 00:15:38 -0700
>> Su
On Thu, 19 Sep 2024, Robin Dapp wrote:
> > On Tue, 17 Sep 2024, Richard Biener wrote:
> >
> > > The following restores the use of .SELECT_VL for testcases where it
> > > is safe to use even when using SLP. I've for now restricted it
> > > to single-lane SLP plus optimistically allow store-lane no
Hi Thomas,
thanks for the patch. I have one proposal/question and one missing verb (IMO).
Else the patch looks fine to me. Ok for trunk.
> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index 829ab00c665..e5ffe67 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortr
Evgeny Karpov writes:
> Hello,
>
> Thank you for reviewing v1!
>
> v2 Changes:
> - Add extra comments and extend patch descriptions.
> - Extract libstdc++ changes to a separate patch.
> - Minor style refactoring based on the reviews.
> - Unify mingw_pe_declare_type for functions and objects.
Than
Evgeny Karpov writes:
> In some cases, the alignment can be bigger than BIGGEST_ALIGNMENT.
>
> The issue was detected while building FFmpeg.
> It creates structures, most likely for AVX optimization.
>
> For instance:
> float __attribute__((aligned (32))) large_aligned_array[3];
>
> BIGGEST_ALIGNM
Evgeny Karpov writes:
> LOCAL_LABEL_PREFIX has been changed to help the assembly
> compiler recognize local labels. Emitting locals has been
> replaced with the .lcomm directive to declare uninitialized
> data without defining an exact section. Functions and objects
> were missing declarations. Bi
On Thu, 19 Sep 2024, Haochen Jiang wrote:
> When I was backporting my doc patch in gcc trunk today, I found when
> adding -march=gracemont in GCC14, the corresponding wwwdoc is missing.
> This patch is adding that.
This looks fine, thank you.
Gerald
Hi Thomas,
comitted as gcc-15-3707-g361903ad1af.
Thanks for the review. I am reviewing your unsigned work at the moment.
Thanks again and regards,
Andre
On Wed, 18 Sep 2024 18:18:20 +0200
Thomas Koenig wrote:
> Am 18.09.24 um 12:31 schrieb Andre Vehreschild:
> > Regtested ok on x86_64
> So for the future I'd suggest you post those with a remark that you think
> they're obvious and going to commit in a day (or some other reasonable
> timeframe) if there are no complaints.
Oh, I see. Thanks Robin for reminding.
That would be perfect. Do you have any best practices for the remark
Jennifer Schmitz writes:
>> On 18 Sep 2024, at 20:33, Richard Sandiford
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Jennifer Schmitz writes:
>>> From 05e010a4ad5ef8df082b3e03b253aad85e2a270c Mon Sep 17 00:00:00 2001
>>> From: Jennifer Schmitz
>>> Date:
Hi Thomas,
thanks for review. Committed with the changes requested as:
gcc-15-3711-gde915fbe3cb
Thanks again.
Regards,
Andre
On Wed, 18 Sep 2024 18:24:19 +0200
Thomas Koenig wrote:
> Hi Andre,
>
> > Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> Extremely minor
Hi Thomas,
submitting your patch as part of the mail got it corrupted by some mailer
adding line breaks. It does not apply for me. Because I can't test it, I have
more questions, see below:
On Wed, 18 Sep 2024 22:22:15 +0200
Thomas Koenig wrote:
> This patch adds random number support for UNSIG
Evgeny Karpov writes:
> The current binutils implementation does not support offset up to 4GB in
> IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
> This is related to differences in ELF and COFF relocation records.
> There are ways to fix this. This work on relocation change will
Hi Thomas,
this look fine to. Ok for trunk.
Thanks for the patch,
Andre
On Wed, 18 Sep 2024 22:20:44 +0200
Thomas Koenig wrote:
> OK for trunk?
>
> This is based on the previous submissions. Again, this does not
> generate a new library version; rather it re-uses the signed
> integer v
Hi Thomas,
unfortunately I have some questions. Most of them are for my understanding.
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index 66a3635404a..a214b8bc1b3 100644
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -711,17 +711,9 @@ gfc_arith_uminus (gfc_expr *op
On Thu, 19 Sep 2024, Richard Sandiford wrote:
Martin Storsjö writes:
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and C
Hi Dusan,
sorry for the late reply.
> This patch addresses a missed opportunity to fuse vsetvl_infos.
> Instead of checking whether demands for merging configurations of
> vsetvl_info are all met, the demands are checked individually.
>
> The case in question occurs because of the conditional
> On Tue, 17 Sep 2024, Richard Biener wrote:
>
> > The following restores the use of .SELECT_VL for testcases where it
> > is safe to use even when using SLP. I've for now restricted it
> > to single-lane SLP plus optimistically allow store-lane nodes
> > and assume single-lane roots are not widen
> This patch would like fix the dump check times of vector SAT_ADD. The
> middle-end change makes the match times from 2 to 4 times.
>
> The below test suites are passed for this patch.
> * The rv64gcv fully regression test.
That's OK. And I think testsuite fixup patches like this you can consid
Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.
PR target/113953
gcc/ChangeLog:
* config/s390/s390.cc (s390_lra_p): Remove.
(TARGET_LRA_P): Remove.
* config/s390/s390.opt (mlra): Remove.
* conf
Martin Storsjö writes:
> On Thu, 12 Sep 2024, Evgeny Karpov wrote:
>
>> The current binutils implementation does not support offset up to 4GB in
>> IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
>> This is related to differences in ELF and COFF relocation records.
>
> Yes, I agre
Pengxuan Zheng writes:
> This is similar to the recent improvements to the Advanced SIMD popcount
> expansion by using SVE. We can utilize SVE to generate more efficient code for
> scalar mode popcount too.
>
> PR target/113860
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (p
On Thu, Sep 19, 2024 at 09:07:06AM +0200, Jakub Jelinek wrote:
> space is ' ' '\t' '\n' '\r' '\f' '\v' in the C locale,
> blank is ' ' '\t'
> cntrl is a lot of chars but not ' '
> if we extend by the safe-ctype
> vspace '\r' '\n'
> nvspace ' ' '\t' '\f' '\v' '\0'
> Obviously, we shouldn't look at '
On Thu, Sep 19, 2024 at 08:17:24AM +0200, Richard Biener wrote:
> On Wed, Sep 18, 2024 at 7:33 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> > > +1 I'd much rather learn about this kind of error before the code reaches
> > > a review tool :)
100 matches
Mail list logo
