On Thu, Aug 7, 2025 at 8:37 AM Andrew Pinski wrote:
>
> Like r0-46282-gf41115930523b3, but this time for normal variables
> rather than the constant pool.
> With the simple C++ code on ia32:
> ```
> std::initializer_list a = {0.3l};
> ```
> GCC currently produces:
> ```
> .section.
On Wed, 6 Aug 2025, Robin Dapp wrote:
> > + elsvals)
> > + || gs_info->decl != NULL_TREE)
>
> Does GATHER_SCATTER_LEGACY_P work here? Or is ifn != IFN_LAST?
It should work. Note I'm a bit unhappy about GATHER_SCATTER_LEGACY_P
and friend
On Wed, 6 Aug 2025, Tobias Burnus wrote:
> This patch updates contrib/download_prerequisites to download
> newer versions (the latest) of GMP, MPFR and MPC.
>
> Main reason is a newer MPFR that provides C23 functions,
> additionally, the usual bug fixes or the new "away from zero"
> rounding in M
Like r0-46282-gf41115930523b3, but this time for normal variables
rather than the constant pool.
With the simple C++ code on ia32:
```
std::initializer_list a = {0.3l};
```
GCC currently produces:
```
.section.rodata.cst16,"aM",@progbits,16
.align 16
.type _ZGR1a_,
On Wed, Aug 06, 2025 at 05:57:14PM +0200, Jakub Jelinek wrote:
> On Wed, Aug 06, 2025 at 05:40:09PM +0200, Stefan Schulze Frielinghaus wrote:
> > On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> > > On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> > > >
I think upon further reflection, I have a slightly different read of what's
going on.
See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
https://www.airs.com/ian/configure/configure_8.html (rendering of since-deleted
from the GDB repo item referenced in reply), which I also foun
Changes in v2:
* Re-initialize inner loop variables.
* Compute result optimistically, check outcome reliably.
Changes:
* Whitespace tweaks aside, this just strips out the existing fixup and
wraps the generator in a do .. while loop.
Implement P0952R2 "A new specification for std::generate_ca
On 8/6/25 3:34 PM, Patrick Palka wrote:
On Tue, 5 Aug 2025, Jason Merrill wrote:
On 7/31/25 10:51 AM, Patrick Palka wrote:
On Thu, 31 Jul 2025, Jason Merrill wrote:
On 7/30/25 5:48 PM, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On 8/6/25 6:27 PM, Sam James wrote:
This fails for me as:
+ERROR: g++.dg/cpp26/constexpr-new3.C -std=c++26: unknown dg option: 2 for "
dg-error 40 "accessing value of 'int [2]' object through a 'long int' glvalue in a
constant expression" "
otherwise.
Escape '[' and ']'.
Oops, thanks.
gc
On 7/25/25 2:24 PM, Patrick Palka wrote:
After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
comparison operator expressed as a built-in acting on an operator<=>
call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
returns a class type (std::strong/weak/partial_
Changes:
* Whitespace tweaks aside, this just strips out the existing fixup and
wraps the generator in a do .. while loop.
Implement P0952R2 "A new specification for std::generate_canonical".
It has us start over if the naive generation of a float in 0..1
comes up exactly equal to 1, which occu
On 8/6/25 7:13 AM, Jakub Jelinek wrote:
Hi!
Another part of the C++26 P2843R3, this time in
https://eel.is/c++draft/cpp.include#7
changing former (compile time) undefined behavior to IFNDR.
With IFNDR we wouldn't have to test anything I guess, but this still adds
the cases from the 3.4 section
On 8/6/25 8:17 AM, Jakub Jelinek wrote:
Hi!
From the paper it isn't clear what caused the decision changes, not to drop
the "the token defined is generated as a result of this replacement process or"
part and make [cpp.cond]/10 violations IFNDR rather than ill-formed (the
latter maybe so that t
On 8/6/25 10:29 AM, Jakub Jelinek wrote:
Hi!
And here is the last part of the paper. Contrary what the paper claims
(clearly they haven't tried -pedantic nor -pedantic-errors), I think we
already diagnose everything we should.
Tested on x86_64-linux and i686-linux, ok for trunk?
OK.
2025-0
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-08-04 17:09
To: gcc-patches
CC: kito.ch...@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com;
pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Expand const_vector with 2 elts per pattern.
Hi,
In PR121334 we are asked
Thanks Robin.
> I assume the test expectation changes are necessary because the subrtx check
> captures all operations and with the default settings (scalar-vec-cost = 0)
> we
> always prefer vv over vx/vf?
Yes, of course. The previous vx/vf combine patch(s) needs to do similar change
too.
Le
This fails for me as:
+ERROR: g++.dg/cpp26/constexpr-new3.C -std=c++26: unknown dg option: 2 for "
dg-error 40 "accessing value of 'int [2]' object through a 'long int' glvalue
in a constant expression" "
otherwise.
Escape '[' and ']'.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/constexpr
So just an FYI. My entire testing infrastructure system lost its mind
over the last week or so. Initially it was just failing to record
testresults, then is stopped running jobs.
No idea why Jenkins lost its mind -- it's running inside a docker
container and shouldn't have had anything ch
From: John Ericson
Prefatory note:
I've since learned that this quite similar to
https://inbox.sourceware.org/gcc-patches/20240522095404.1825269-1-...@gcc.gnu.org/,
postdating my original patch series, but predating this version. See
that thread for additional motivation. That patch updated a fe
From: John Ericson
We will use this in the subsequent patch to control what filenames we
search for.
gcc/ChangeLog:
* gcc.cc (for_each_path): Pass an additional boolean argument to
the callback specifying whether the current directly being
searched is machine-specific, a
OK I am going to submit a new version which is now in 4 steps. The first 3
steps are entirely behavior non-changing (or at least that is their intent) ---
pure refactors. The 4th and final one along does the behavior change, and
contains the motivation for that behavior change. Clang prior art i
Now that `find_a_program` and `find_a_file` have been separated, we
don't need a mode parameter, because one is always doing `R_OK`, and the
other is always doing `X_OK`.
This change also proves that some of the code I removed from
`find_a_file` in the previous commit is actually dead.
gcc/Change
From: John Ericson
This continues what I started in way back in
5fee8a0a9223d030c66d53c104fb0a431369248f --- there is no
executable-specific logic cluttering up find_a_file either, but instead
there is a clean separation.
The cost of this is that there is now some code duplication, but in
subseq
On 8/6/25 13:22, Joseph Myers wrote:
> On Wed, 6 Aug 2025, David Faust wrote:
>
>> So IMO the best option will be to reject wide strings in the attribute
>> handler. (The alternative, I guess, is to ensure the argument is
>> always exported to UTF-8 before being written (?))
>>
>> I see that w
On Wed, 6 Aug 2025, David Faust wrote:
> So IMO the best option will be to reject wide strings in the attribute
> handler. (The alternative, I guess, is to ensure the argument is
> always exported to UTF-8 before being written (?))
>
> I see that we can get the character size from the TREE_TYPE
> I don't see how this makes any sense. If TARGET_SIMD or TARGET_FP
> are true, the compiler may at any time use a SIMD register for anything -
> including in integer-only code.
Thanks for reviewing my proposed patch. I'm struggling to migrate the
Zephyr project from GCC 12.2 to a more recent ver
On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> > After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
> > comparison operator expressed as a built-in acting on an operator<=>
> > call, e.g. operator<=>(x, y) < 0. This is because oper
On Tue, 5 Aug 2025, Jason Merrill wrote:
> On 7/31/25 10:51 AM, Patrick Palka wrote:
> > On Thu, 31 Jul 2025, Jason Merrill wrote:
> >
> > > On 7/30/25 5:48 PM, Patrick Palka wrote:
> > > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> > > >
> > > > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
Andrew Pinski wrote:
> I am trying to understand the difference between this option and
> -mgeneral-regs-only since you mentioned that FPU will be disabled for
> those cases.
Thanks for taking a look at the patch; I was also surprised that there
wasn't some existing option that I could use.
Thi
In addition to gzip format our snapshots and releases have been using
xz instead of bzip2 for a while.
gcc:
PR target/69374
* doc/install.texi (Prerequisites): Replace bzip2 by xz.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc
Hi Keith,
> This option (enabled by default) preserves existing behavior by
> allowing use of Advanced SIMD registers while expanding
> memset/memcpy/memmove operations into inline instructions.
>
> Disabling this option prevents use of these registers for environments
> where the FPU may be disab
On 5/1/25 3:26 AM, Jakub Jelinek wrote:
Hi!
The following patch implements the C++26
P1061R10 - Structured Bindings can introduce a Pack
paper.
One thing unresolved in the patch is mangling, I've raised
https://github.com/itanium-cxx-abi/cxx-abi/issues/200
for that but no comments there yet. On
On Wed, Aug 6, 2025 at 11:20 AM Keith Packard wrote:
>
> This option (enabled by default) preserves existing behavior by
> allowing use of Advanced SIMD registers while expanding
> memset/memcpy/memmove operations into inline instructions.
>
> Disabling this option prevents use of these registers
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> On Tue, Aug 05, 2025 at 03:52:12PM -0700, Jason Merrill wrote:
> > Hmm, the names in "Table 4"
> > https://eel.is/c++draft/lex.name#tab:lex.name.special are also
> > context-sensitive. I agree with ignoring the ObjC keywords because they
> > aren't part
On 8/4/25 13:17, Joseph Myers wrote:
> On Mon, 4 Aug 2025, David Faust wrote:
>
>> Hi Joseph,
>>
>> Could you please take a look at the front-end portion of this
>> series when you have a moment?
>>
>> New attributes/handlers - Patch 1:
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/6
On Wed, 6 Aug 2025, John Ericson wrote:
> I can't quite tell, but I have a nagging suspicion that this is unused.
> It would be nice to simplify some of the multilib stuff, and the
> complexity around source directory (rather than build directory)
> handling seems like it ought not to be so necess
On Tue, Aug 5, 2025 at 1:32 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > "H.J. Lu" writes:
> >> On Mon, Aug 4, 2025 at 3:28 PM H.J. Lu wrote:
> >>>
> >>> On Mon, Aug 4, 2025 at 2:04 PM H.J. Lu wrote:
> >>> >
> >>> > On Mon, Aug 4, 2025 at 8:50 AM Richard Sandiford
> >>> > wro
This option (enabled by default) preserves existing behavior by
allowing use of Advanced SIMD registers while expanding
memset/memcpy/memmove operations into inline instructions.
Disabling this option prevents use of these registers for environments
where the FPU may be disabled to reduce the cost
This option (enabled by default) preserves existing behavior by
allowing use of Advanced SIMD registers while expanding
memset/memcpy/memmove operations into inline instructions.
Disabling this option prevents use of these registers for environments
where the FPU may be disabled to reduce the cost
These targets are regularly used for embedded applications for
portions of code where the Advanced SIMD registers may not be
preserved, such as interrupt handlers.
Disabling the use of SIMD registers for memset/memcpy operations by
default ensures that code which doesn't overtly perform FPU or SIM
This implements the simple copy prop of aggregates into
arguments of function calls. This can reduce the number of copies
done. Just like removing of an extra copy in general, this can and
will help out SRA; since we might not need to do a full scalarization
of the aggregate now.
This is the simpl
While looking into the gimple level after optimization of the highway code
from google, I noticed in .optimized we still have:
```
MEM [(short int *)&a] = { 0, 0, 0, 0, 0, 0, 0, 0 };
D.4398 = a;
a ={v} {CLOBBER(eos)};
D.4389 = D.4398;
D.4390 = D.4389;
D.4361 = D.4390;
D.4195 = D.4361
This is version 3 of the patches:
https://inbox.sourceware.org/gcc-patches/20250802035048.3815303-1-quic_apin...@quicinc.com/T/#m757887289de93b288be742132f9a56a9c3812514
For the memset patch, I had forgot to include the limit for the walker.
This has now been added back and some minor formating is
One thing I noticed while working on copy prop for aggregates is that we start
with
a memcpy like statement and then walk backwards. This means we could have a few
walks
backwards to see there was no statement for zeroing. Instead this changes the
walk
backwards into a true forwprop. In the futu
In the testcase provided, currently we lose the landing pad for the exception
that could
throw from the aggregate load as we remove one copy and the second statement
where load
happens was not marked as throwable before so the landing pad for that internal
throw is
now gone.
The fix is to ignor
While thinking about how to implement the rest of the copy prop and makes sure
not
to introduce some compile time problems, optimize_agr_copyprop should be changed
into a forwproping rather than looking backwards.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-fo
+ elsvals)
+ || gs_info->decl != NULL_TREE)
Does GATHER_SCATTER_LEGACY_P work here? Or is ifn != IFN_LAST?
--
Regards
Robin
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
GCC internally was also using a uint32_t for this, which would overflow
when translating from DWARF for arrays with more with more than
UINT32_MAX elements.
On Wed, Aug 06, 2025 at 05:40:09PM +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> > On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> > > On Tue, Aug 05, 2025 at 04:23:14PM +0200, Stefan Schulze Frielinghaus
On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> > On Tue, Aug 05, 2025 at 04:23:14PM +0200, Stefan Schulze Frielinghaus wrote:
> > > From: Stefan Schulze Frielinghaus
> > >
> > > From: Stefan Schulze F
Hi @Jeff Law and @kito.ch...@sifive.com
,
Please do needful with your comments for the subjected patch .
Thank you
~U
On Wed, Jul 30, 2025 at 6:50 PM Umesh Kalappa
wrote:
> Hi All,
>
> Please do needful with reviewing the below changes (that enable mips
> custom prefetch instruction ) and
Oops, looks like I mess up a testcase name. Fixed in this version.
On 8/6/2025 10:57 PM, Yuao Ma wrote:
Hi Tobias,
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std
Hi Tobias,
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
Done. Testcase added.
* I have a minor documentation nit; current wording is
at
The old C-style was cumbersome make making one responsible for manually
create and pass a closure (separate function and *_info class for
closed-over variables).
I would have liked to redo this with C++ lambdas, so we could:
- derive environment types implicitly
- have fewer stray static function
This patch updates contrib/download_prerequisites to download
newer versions (the latest) of GMP, MPFR and MPC.
Main reason is a newer MPFR that provides C23 functions,
additionally, the usual bug fixes or the new "away from zero"
rounding in MPC might turn out to be useful. GMP also claims
bette
From: Pan Li
The previous cost value for vec_duplicate almost bases on the operators
like add/minus. The rtx_cost function try to match them case by case
and find if it has vec_duplicate, then update the cost values.
It is Ok when we initially add it but looks confused/redundant as more
and mor
Looks much more reasonable, thanks.
I assume the test expectation changes are necessary because the subrtx check
captures all operations and with the default settings (scalar-vec-cost = 0) we
always prefer vv over vx/vf?
--
Regards
Robin
Hi!
And here is the last part of the paper. Contrary what the paper claims
(clearly they haven't tried -pedantic nor -pedantic-errors), I think we
already diagnose everything we should.
Tested on x86_64-linux and i686-linux, ok for trunk?
2025-08-06 Jakub Jelinek
PR preprocessor/120
When the doubly-linked list tests were introduced, the tests were
printing the content of the list forward and backward. However, this
printing is not needed outside of debugging, and confuses people because
the output is not only composed of PASS: lines.
This patch disables the printing of the li
This patch is a follow-up of the discussion in [1], and was already approved by
Richard Sandiford (GCC), and Jan Beulich (binutils).
[1]:
https://inbox.sourceware.org/binutils/e8e281d1-cd6f-46d5-af80-dee81e73d...@suse.com/
Matthieu Longo (1):
libiberty: disable logging of list content for dou
On 8/6/2025 5:20 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for the patch. — I have one nit:
Yuao Ma wrote:
This patch cleans up a duplicate test driver.
Regression-tested. OK for trunk?
...
Subject: [PATCH] fortran: cleanup duplicate tests for
c_f_pointer_shape_driver; nfc
'; nfc'?
tes
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This diagnostic failed to specify the actual type of the object being
accessed through a glvalue of an incompatible type, and could also use to
indicate where that object comes from.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_indir
The PowerPC ISA has Load-And-Reserve and Store-Conditional instructions
which can be used to construct a sequence of instructions that appears
to perform an atomic update operation on an aligned storage location.
The larx (load-and-reserve) instruction supports an Exclusive Access
Hint (EH). A val
On Wed, 6 Aug 2025, Pengfei Li wrote:
> Hi Richard,
>
> > Can you split this fix out? I guess the bug is latent on branches
> > as well?
>
> > Otherwise the patch looks good to me - thanks for the very
> > nice work.
>
> Thanks for your review.
>
> The small fix is in a code path that had bee
The main gather/scatter discovery happens at SLP discovery time,
the base address and the offset scale are currently not explicitly
represented in the SLP tree. This requires re-discovery of them
during vectorizable_store/load. The following fixes this by
recording this info into the SLP tree. T
Hi Richard,
> Can you split this fix out? I guess the bug is latent on branches
> as well?
> Otherwise the patch looks good to me - thanks for the very
> nice work.
Thanks for your review.
The small fix is in a code path that had been unreachable before, since peeling
with masking for VLA mode
Both vectorizable_load and vectorizable_store compute an alias
type commoning differences between SLP lanes. The following
makes sure to use that for gather/scatter rather than the
random one from the representative created during scalar stmt
gather/scatter analysis.
* tree-vect-stmts.cc
The following removes the redundant check on supported gather/scatter
IFN in check_load_store_for_partial_vectors which is already done
and adjusts those to check the recorded ifn, also allowing legacy
gather/scatter which all handle masking.
* tree-vect-stmts.cc (check_load_store_for_part
Hi!
>From the paper it isn't clear what caused the decision changes, not to drop
the "the token defined is generated as a result of this replacement process or"
part and make [cpp.cond]/10 violations IFNDR rather than ill-formed (the
latter maybe so that the extension to handle e.g. !A(A) below et
On Fri, 1 Aug 2025, Pengfei Li wrote:
> This patch extends the support for peeling and versioning for alignment
> from VLS modes to VLA modes. The key change is allowing the DR target
> alignment to be set to a non-constant poly_int. Since the value must be
> a power-of-two, for variable VFs, the
Hi Richard,
+++ b/gcc/config/aarch64/aarch64.md
@@ -876,10 +876,16 @@
(clobber (reg:CC CC_REGNUM))]
"TARGET_CMPBR && aarch64_cb_rhs (, operands[1])"
{
-return (get_attr_far_branch (insn) == FAR_BRANCH_NO)
- ? "cb\\t%0, %1, %l2"
- : aarch64_gen_far_branch (operands, 2,
-
On 8/6/25 00:45, Karl Meakin wrote:
Now that the body of `cbranch` and `cbranch` are the same, could we merge
them into one rule?
No, the bodies are the same but the predicates are not.
r~
On 05/08/2025 11:22, Tejas Belagod wrote:
On 31/07/2025 15:20, Kyrylo Tkachov wrote:
On 31 Jul 2025, at 14:34, Tejas Belagod wrote:
The test was unsafe when tested on different vector lengths. This patch
fixes it to work on all lengths.
Ok. I’ve seen this test fail on GCC 15 branch too,
Hi!
Another part of the C++26 P2843R3, this time in
https://eel.is/c++draft/cpp.include#7
changing former (compile time) undefined behavior to IFNDR.
With IFNDR we wouldn't have to test anything I guess, but this still adds
the cases from the 3.4 section of the paper plus related tests.
The paper
Hi!
Sorry, my bootstrap failed last night because of this, I've fixed it
up and it bootstrapped/regtested fine overnight, but in the morning
forgot to adjust the patch before committing.
Without this there is
.../gimple-lower-bitint.cc:7678:36: error: comparison of integer expressions of
differe
Changes from v5:
1. Fixes based on Jakub's review on v5.
2. Not including patches already approved. (Except for patch 4,
which is here so that it's easier to commit if the series is OK
for trunk.)
This series was bootstrapped and tested on x86_64-linux-gnu and
loongarch64-linux-gnu.
Yang
On Wed, Aug 06, 2025 at 05:57:52PM +0800, Yang Yujie wrote:
> A _BitInt value may rely on a conversion to become properly extended.
> So a conversion to _BitInt is not trivially removable even if the
> types of the result and the operand have the same precision and size.
>
> This patch fixes gcc.d
On Wed, Aug 06, 2025 at 11:58:09AM GMT, Jakub Jelinek wrote:
> On Wed, Aug 06, 2025 at 05:57:49PM +0800, Yang Yujie wrote:
> > This patch also make casts of ABI-extended large/huge _BitInts
> > behave the same as the small/middle case, i.e. no-op for casts
> > to a higher precision _BitInt with the
On Wed, Aug 06, 2025 at 05:57:51PM +0800, Yang Yujie wrote:
> A widening cast from a signed _BitInt operand to an unsigned _BitInt
> type involves filling the extra limb(s) with sign extension.
> On a target that wants _BitInts extended in memory, if this unsigned
> type has a partial limb, the unu
On Wed, Aug 06, 2025 at 05:57:50PM +0800, Yang Yujie wrote:
> In BEXTC, whether a _BitInt object is properly extended is examined
> by a value comparison against a copied object in a wider _BitInt
> type that utilizes all of the partial limb.
>
> Since the (implicit) conversion to the wider type m
On Wed, Aug 06, 2025 at 05:57:49PM +0800, Yang Yujie wrote:
> This patch also make casts of ABI-extended large/huge _BitInts
> behave the same as the small/middle case, i.e. no-op for casts
> to a higher precision _BitInt with the same number of limbs /
> extension for casts that turns a full top l
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patch fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because extensi
This patch also make casts of ABI-extended large/huge _BitInts
behave the same as the small/middle case, i.e. no-op for casts
to a higher precision _BitInt with the same number of limbs /
extension for casts that turns a full top limb into a partial limb.
This conveniently helps keep some code with
A widening cast from a signed _BitInt operand to an unsigned _BitInt
type involves filling the extra limb(s) with sign extension.
On a target that wants _BitInts extended in memory, if this unsigned
type has a partial limb, the unused part of it should be zeroed.
e.g. Assuming limb_mode == E_DImod
In BEXTC, whether a _BitInt object is properly extended is examined
by a value comparison against a copied object in a wider _BitInt
type that utilizes all of the partial limb.
Since the (implicit) conversion to the wider type may be optimized
away now and cause the result of the comparison to alw
On Tue, Aug 05, 2025 at 03:52:12PM -0700, Jason Merrill wrote:
> Hmm, the names in "Table 4"
> https://eel.is/c++draft/lex.name#tab:lex.name.special are also
> context-sensitive. I agree with ignoring the ObjC keywords because they
> aren't part of the C++ standard, but I'd drop the "context-sensi
Hi Yuao,
thanks for the patch. — I have one nit:
Yuao Ma wrote:
This patch cleans up a duplicate test driver.
Regression-tested. OK for trunk?
...
Subject: [PATCH] fortran: cleanup duplicate tests for
c_f_pointer_shape_driver; nfc
'; nfc'?
tests_2_driver and tests_4_driver are identical,
Am 05.08.25 um 21:25 schrieb Jerry D:
> Hello,
>
> The attached patch fixes the subject bug by adding checks for ';' it specific
> places to avoid eating them and/or giving false errors.
>
Jerry, thanks a lot for tackling this!
But in an ideal world, standards would define a delimiter argument f
Hi!
aarch64 for some strange reason unconditionally enables -Werror for libgcc
building and this particular file for some strange reason contains
a useless static forward declaration of a function only defined in the
#if defined __sun__ && defined __svr4__
block and not otherwise (with __attribu
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> aarch64 for some strange reason unconditionally enables -Werror for libgcc
> building and this particular file for some strange reason contains
> a useless static forward declaration of a function only defined in the
> #if defined __sun__ && de
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled on aarch64-linux.
> The problem is in the optimization to shorten large constants
> in PHI arguments.
> In a couple of places during bitint lowering we compute
> minimal precision of constant and if it is sig
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> handle_operand_addr (used for the cases where we use libgcc APIs, so
> multiplication, division, modulo, casts of _BitInt to float/dfp) when it
> sees default definition of an SSA_NAME which is not PARM_DECL (i.e.
> uninitialized one) just alloca
On Wed, Aug 6, 2025 at 10:18 AM Yangyu Chen wrote:
>
> I apologize for missing that. Although I don't have write access,
> I have contributed numerous commits and thousands of lines of code
> to GCC.
>
> Could you please commit this patch for me?
No problem, will do later today.
Thanks,
Uros.
>
Hi!
The following testcase is miscompiled on aarch64-linux.
The problem is in the optimization to shorten large constants
in PHI arguments.
In a couple of places during bitint lowering we compute
minimal precision of constant and if it is significantly
smaller than the precision of the type, store
On Wed, 6 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> OpenBSD headers apparently instead of just
> #define SIZE_MAX something
> do
> #ifndef SIZE_MAX
> #define SIZE_MAX something
> #endif
> This causes problem with gengtype-lex.cc, where the flex generated
> code has
> #ifndef SIZE_MAX
> #defi
Both vectorizable_load and vectorizable_store compute an alias
type commoning differences between SLP lanes. The following
makes sure to use that for gather/scatter rather than the
random one from the representative created during scalar stmt
gather/scatter analysis.
Bootstrapped and tested on x8
The following simplifies vect_supportable_dr_alignment based on
the observation that we always dereference dr_info so it cannot
be NULL, likewise we always dereference dr so that cannot be NULL
either.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
* tree-vect-data-refs.cc (vect_sup
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
* I have a minor documentation nit; current wording is
at https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html
Namely, ...
Yu
On Wed, Jul 30, 2025 at 7:24 PM Yangyu Chen wrote:
>
> This patch adds the missing PTA_POPCNT and PTA_LZCNT with the PTA_ABM
> bitmask definition for the bdver1, btver1, and lujiazui architectures
> in the i386 architecture configuration file.
>
> Although these two features were not present in th
I apologize for missing that. Although I don't have write access,
I have contributed numerous commits and thousands of lines of code
to GCC.
Could you please commit this patch for me?
Thanks,
Yangyu Chen
> On 6 Aug 2025, at 16:13, Uros Bizjak wrote:
>
> On Wed, Jul 30, 2025 at 7:24 PM Yangyu C
1 - 100 of 105 matches
Mail list logo
