Merge new optabs with the existing implementations for signbit and
isinf.
gcc/ChangeLog:
* config/s390/s390.h (S390_TDC_POSITIVE_ZERO): Remove.
(S390_TDC_NEGATIVE_ZERO): Remove.
(S390_TDC_POSITIVE_NORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_NORMALIZED_BFP_NU
Hi,
in PR118154 we emit strided stores but the first of those does not
always have the proper VTYPE. That's because we erroneously delete
a necessary vsetvl.
In order to determine whether to elide
(1)
Expr[7]: VALID (insn 116, bb 17)
Demand fields: demand_ratio_and_ge_sew demand_a
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-01-14 16:19
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH v2] RISC-V: Fix vsetvl compatibility predicate [PR118154].
Hi,
As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
When looking at the generated code, we can see that the generated code
is vectorized differently, resulting in a reduction from 225 instructions
down to 109. On the performance side, no changes were measured on a 5950X.
This
On Tue, 14 Jan 2025, Christoph Müllner wrote:
> As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> When looking at the generated code, we can see that the generated code
> is vectorized differently, resulting in a reduction from 225 instructions
> down to 109. On the perfo
This adds the missing support for the S/390 and RISC-V architectures to the
object file reader present in the run-time library, fixing the regression.
Tested on x86-64/Linux, applied on the mainline.
2025-01-13 Eric Botcazou
PR ada/118459
* libgnat/s-objrea.ads (Object_Arch)
When we have the situation of an external SLP node that is
permuted the scalar stmts recorded in the permute node do not
mean the scalar computation can be removed. We are removing
those stmts from the vectorized_scalar_stmts for this reason
but we fail to check this set when we cost scalar stmts.
Tamar Christina writes:
> Hi All,
>
> When both -mcpu and -march are specified, the value of -march wins out.
>
> This is done correctly for the calls to cc1 and for the assembler directives
> we
> put out in assembly files.
>
> However in the call to as we don't do this and instead use the arch
On Mon, Jan 13, 2025 at 07:00:18PM -0500, Jason Merrill wrote:
> On 1/12/25 7:03 AM, Nathaniel Shead wrote:
> > On Sun, Jan 12, 2025 at 04:14:41AM +1100, Nathaniel Shead wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The ICE in the l
On Mon, Jan 13, 2025 at 08:35:57PM -0500, Jason Merrill wrote:
> I'd rather hoist the build_static_cast from later; the rules for static cast
> aren't quite the same as can_convert. See:
>
> > if (defining)
> > {
> > tree val;
> > if (code == EQ_EXPR)
> >
Hi,
On 14 Jan 2025, at 2:56, Jason Merrill wrote:
> On 1/12/25 2:39 PM, Simon Martin wrote:
>> [ Fixing David’s email address :-/ ]
>>
>> Hi,
>>
>> On 9 Jan 2025, at 20:08, Simon Martin wrote:
>>
>>> On 9 Jan 2025, at 20:00, Marek Polacek wrote:
>>>
On Thu, Jan 09, 2025 at 12:05:43PM -0500,
If the target does not support floating-point, we register FP vector
types as 'void' (see register_vector_type).
The leads to warnings about 'pure attribute on function returning
void' when we declare the various load intrinsics because their
call_properties say CP_READ_MEMORY (thus giving them th
Hi!
On 2021-11-06T00:51:59+0800, Chung-Lin Tang wrote:
> On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
>> On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
>>> + OMP_CLAUSE_MAP_IMPLICIT_P (clause) = 1;
>> As Thomas mentioned, there is now also OMP_CLAUSE_MAP_IMPLICIT that means
On 1/14/25 4:57 AM, Jakub Jelinek wrote:
On Mon, Jan 13, 2025 at 08:35:57PM -0500, Jason Merrill wrote:
I'd rather hoist the build_static_cast from later; the rules for static cast
aren't quite the same as can_convert. See:
if (defining)
{
tree val;
if (c
[ Apologies for the previous incomplete, garbled email - I used the
shortcut to send the email by mistake way too early ]
Hi Jason,
On 14 Jan 2025, at 11:43, Simon Martin wrote:
> Hi,
>
> On 14 Jan 2025, at 2:56, Jason Merrill wrote:
>
>> On 1/12/25 2:39 PM, Simon Martin wrote:
>>> [ Fixing Dav
On Tue, 14 Jan 2025, Christoph Müllner wrote:
> On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
> >
> > On Tue, 14 Jan 2025, Christoph Müllner wrote:
> >
> > > As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> > > When looking at the generated code, we can see that
Andrew Carlotti writes:
> Features from a cpu or base architecture that were explicitly disabled
> by a +nofeat option were being incorrectly added back in before checking
> for conflicts between -mcpu and -march options. This patch instead
> compares the returned feature masks directly.
>
> gcc/
Andrew Carlotti writes:
> Replace `enum aarch64_processor` and `enum target_cpus` with
> `enum aarch64_cpu`, and prefix the entries with `AARCH64_CPU_`.
> Also rename aarch64_none to aarch64_no_cpu.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-opts.h
> (enum aarch64_processor): Rena
Andrew Carlotti writes:
> The list of cores in aarch64-common.cc included an explicit "generic"
> entry, despite this entry also being present in aarch64-cores.def.
>
> gcc/ChangeLog:
>
> * common/config/aarch64/aarch64-common.cc
> (all_cores): Remove explicit generic entry.
OK, thank
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
In c++/102990 we had a problem where massage_init_elt got {},
digest_nsdmi_init turned that {} into { .value = (int) 1.0e+0 },
and we crashed in the call to fold_non_dependent_init because
a FIX_TRUNC_EXPR/FLOAT_EXPR go
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support for dynamic selectors
(PR113904) and fixes a selector scoring bug reported as PR114596. I hope
this rewrite also improve
This patch adds basic support for three new tree node types that will
be used in subsequent patches to support OpenMP metadirectives and
dynamic selectors.
OMP_METADIRECTIVE is the internal representation of parsed OpenMP
metadirective constructs. It's produced by the front ends and is expanded
d
I've now pushed the 3 big patches that set up the new infrastructure
for metadirectives and dynamic selectors. Part 4 of the previous
version of the series (labeled "v5") has already been approved and
pushed, and I'll be reposting the remaining 5 not-yet-approved parts
that add the user-visible su
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_constructs flag has replaced
calls_decla
On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
>
> On Tue, 14 Jan 2025, Christoph Müllner wrote:
>
> > As reported in PR117079, commit ab18785840d7b8 broke the test pr105493.c.
> > When looking at the generated code, we can see that the generated code
> > is vectorized differently, resultin
Wilco Dijkstra writes:
> ILP32 was originally intended to make porting to AArch64 easier. Support was
> never merged in the Linux kernel or GLIBC, so it has been unsupported for many
> years. There isn't a benefit in keeping unsupported features forever, so
> deprecate it now (and it could be re
"Robin Dapp" writes:
>> OK, thanks.
>>
>> Richard
>
> The issue is also present on GCC 14 as well and the patch applies cleanly.
> Regtested on rv64gcv_zvl512b. To make it explicit: OK to backport to 14?
Yes, thanks.
Richard
On Tue, Jan 14, 2025 at 2:35 PM Richard Biener wrote:
>
> On Tue, 14 Jan 2025, Christoph Müllner wrote:
>
> > On Tue, Jan 14, 2025 at 1:46 PM Richard Biener wrote:
> > >
> > > On Tue, 14 Jan 2025, Christoph Müllner wrote:
> > >
> > > > As reported in PR117079, commit ab18785840d7b8 broke the test
Jeff Law writes:
> On 12/30/24 3:02 PM, Richard Sandiford wrote:
>
>>
>> So it seems like it's a bit of a mess :(
>>
>> If we do try to fix combine, I think something like the attached
>> would fit within the current scheme. It is a pure shift-for-shift
>> transformation, avoiding any extension
> On 13 Jan 2025, at 18:51, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>> Hi Folks,
>>
>>> On 10 Jan 2025, at 18:30, Wilco Dijkstra wrote:
>>>
>>> Hi Andrew,
>>>
Personally I would like this deprecated even for bare-metal. Yes the
iwatch ABI is an ILP32 ABI but I don't see
Hi,
Thomas Schwinge wrote:
On 2021-11-06T00:51:59+0800, Chung-Lin Tang wrote:
On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
+ OMP_CLAUSE_MAP_IMPLICIT_P (clause) = 1;
As Thomas mentioned, there is now also OMP_CLAUSE_MAP_IMPL
> OK, thanks.
>
> Richard
The issue is also present on GCC 14 as well and the patch applies cleanly.
Regtested on rv64gcv_zvl512b. To make it explicit: OK to backport to 14?
--
Regards
Robin
Jeff Law writes:
> On 1/6/25 6:03 AM, Maciej W. Rozycki wrote:
...
>> There are notable regressions between a plain `-mno-bwx'
>> configuration
>> and a `-mno-bwx -msafe-partial' one:
>> FAIL: gm2/iso/run/pass/strcons.mod execution, -g
>> FAIL: gm2/iso/run/pass/strcons.mod execution, -O
>> FAI
As suggested in
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673558.html
update the gcc-15 Changes page:
Add ILP32 depreciation to Caveats section.
---
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index
1c690c4a168f4d6297ad33dd5b798e9200792dc5..d5037efb34cc8e6
Hi Richard,
>> + if (TARGET_ILP32)
>> + warning (OPT_Wdeprecated, "%<-mabi=ilp32%> is deprecated.");
>
> There should be no "." at the end of the message.
Right, fixed in v2 below.
> Otherwise it looks good to me, although like Kyrill says, it'll also
> need a release note.
I've added one,
On 1/14/25 11:25 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
OK for all.
-- >8 --
In c++/102990 we had a problem where massage_init_elt got {},
digest_nsdmi_init turned that {} into { .value = (int) 1.0e+0 },
and we crashed in the call to fol
Andrew Carlotti writes:
> Also add a (currently unused) processor field to processor_info, and
> change name from "" to NULL for the terminating array entries.
>
> gcc/ChangeLog:
>
> * common/config/aarch64/aarch64-common.cc
> (struct aarch64_option_extension): Rename to..
> (str
Andrew Carlotti writes:
> Replace `const struct processor *` in output parameters with
> `aarch64_arch` or `aarch64_cpu`.
>
> Replace `std:string` parameter in aarch64_print_hint_for_extensions with
> `char *`.
>
> Also name the return parameters more clearly and consistently.
>
> gcc/ChangeLog:
>
On Mon, Jan 13, 2025 at 11:03:54PM +0100, anetczuk wrote:
> Raw dump of lang tree was missing information about virtual method call.
Please resend the patch as an attachment, it's not applicable as-is.
> The information is provided in "tok" field of obj_type_ref.
>
> gcc/ChangeLog:
>
> * tree-
Andrew Carlotti writes:
> It seems odd that we add "native" to the list for -march but not for
> -mcpu. This is probably a bug, but for now we'll preserve the existing
> behaviour.
Yeah, agree it looks like a bug (but also that it's not something
to fix as part of this series).
> gcc/ChangeLog:
Andrew Carlotti writes:
> gcc/ChangeLog:
>
> * common/config/aarch64/aarch64-common.cc
> (aarch64_get_all_extension_candidates): Inline into...
> (aarch64_print_hint_for_extensions): ...this.
OK, thanks.
Richard
> diff --git a/gcc/common/config/aarch64/aarch64-common.cc
> b/g
Andrew Carlotti writes:
> Aside from moving the functions, the only changes are to make them
> non-static, and to use the existing info arrays within aarch64-common.cc
> instead of the info arrays remaining in aarch64.cc.
>
> gcc/ChangeLog:
>
> * common/config/aarch64/aarch64-common.cc
>
Thanks for review. New version in attachment.
On 2025-01-14 19:03, Marek Polacek wrote:
On Mon, Jan 13, 2025 at 11:03:54PM +0100, anetczuk wrote:
Raw dump of lang tree was missing information about virtual method call.
Please resend the patch as an attachment, it's not applicable as-is.
T
On Mon, 13 Jan 2025, Jason Merrill wrote:
> On 1/13/25 3:27 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
>
> OK, but do we also need this in the "still packed" case earlier in the
> function?
I think so in principle, though I wa
gcc/ChangeLog:
* gcc/config/riscv/riscv.cc
(is_zicfilp_p): New function.
(is_zicfiss_p): New function.
* gcc/config/riscv/riscv-zicfilp.cc: Update.
* gcc/config/riscv/riscv.h: Update.
* gcc/config/riscv/riscv.md: Update.
gcc/testsuite/ChangeLog:
Update gcc/testsuite/c-c++-common/fcf-protection-[1-7].c.
On Wed, Jan 15, 2025 at 3:54 PM Monk Chiang wrote:
> gcc/ChangeLog:
> * gcc/config/riscv/riscv.cc
> (is_zicfilp_p): New function.
> (is_zicfiss_p): New function.
> * gcc/config/riscv/riscv-zicfilp.cc: U
This patch is implemented according to the RISC-V CFI specification.
It supports the generation of shadow stack instructions in the prologue,
epilogue, non-local gotos, and unwinding.
RISC-V CFI SPEC: https://github.com/riscv/riscv-cfi
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc:
gcc/ChangeLog:
* gcc/config/riscv/riscv.cc
(riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
* gcc/config/riscv/linux.h (TARGET_ASM_FILE_END): Define.
libgcc/ChangeLog:
* libgcc/config/riscv/crti.S: Add lpad instructions.
* libgcc/config/riscv/cr
On 1/14/25 7:57 AM, Richard Sandiford wrote:
Jeff Law writes:
On 12/30/24 3:02 PM, Richard Sandiford wrote:
So it seems like it's a bit of a mess :(
If we do try to fix combine, I think something like the attached
would fit within the current scheme. It is a pure shift-for-shift
transfor
Clearly an oversight in the generic-ooo model caught by the checking
code. I should have realized it was generic-ooo as we don't have a
pipeline description for the tenstorrent design yet, just the costing model.
The patch was extracted from the BZ which indicated Anton was the
author, so I
On 1/13/25 1:08 PM, Keith Packard wrote:
In doing picolibc testing for lm32, I discovered that varargs handling
had an issue when the set of anonymous arguments spanned register
arguments and stack arguments.
On lm32, FIRST_PARM_OFFSET is '4', meaning there are four bytes
between the stack t
> lm32 is currently scheduled to be deprecated as it hasn't been converted
> to use LRA instead of reload. Deprecation would happen with the gcc-15
> release and removal in gcc-16 if nobody steps forward to do the
> conversion.
I kinda wondered. Frankly, I treated this adventure as a way to le
On 1/9/25 05:17, Tobias Burnus wrote:
Hi Sandra,
I had a first glance at your patch, albeit very superficial. I found one
issue reading the code - and observed some issues when running it against
some existing external tests.
I will have a deeper looker later, will now first do another iteratio
On Tue, Jan 14, 2025 at 08:35:44PM +0100, anetczuk wrote:
> Thanks for review. New version in attachment.
Thanks, your patch looks good to me but I can't approve it.
FWIW, the result is that instead of:
@123obj_type_ref type: @147
we'll print:
@123obj_type_ref type: @147 ex
On Mon, Jan 13, 2025 at 1:02 AM Monk Chiang wrote:
>
> * gcc/config/riscv/riscv.cc
> (riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
>
> * libgcc/config/riscv/riscv-asm.h: Add GNU_PROPERTY for ZICFILP,
> ZICFISS.
>
ELF attributes (.riscv.attributes
gcc/testsuite/ChangeLog
* c-c++-common/gomp/adjust-args-6.c: New.
* c-c++-common/gomp/attrs-metadirective-1.c: New.
* c-c++-common/gomp/attrs-metadirective-2.c: New.
* c-c++-common/gomp/attrs-metadirective-3.c: New.
* c-c++-common/gomp/attrs-metadirective-4.c
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic selector support.
(OpenM
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/c-family/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META.
(c_omp_expand_variant_construct): Declare.
* c
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target trait is added to the beginni
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait_property_expr.
(processing_omp_trait_proper
Here is a new version of the not-yet-committed parts of the series to add
support for metadirectives and dynamic selectors. At this point, the
middle-end support is in, but the front ends don't parse metadirectives,
nothing creates the new tree data structures, and there are no test cases.
This g
gcc/fortran/ChangeLog
PR middle-end/112779
PR middle-end/113904
* decl.cc (gfc_match_end): Handle COMP_OMP_BEGIN_METADIRECTIVE and
COMP_OMP_METADIRECTIVE.
* dump-parse-tree.cc (show_omp_node): Handle EXEC_OMP_METADIRECTIVE.
(show_code_node): Likewise.
Hi Sandra,
Sandra Loosemore wrote:
On 1/9/25 05:17, Tobias Burnus wrote:
A case where 'omp error' diagnostic should be delayed - and (here)
suppressed:
["should" in the sense it would be good not in the sense "shall".]
program_control/sources/error.1.c:15:23: error: ‘pragma omp error’
encou
The RISCV psABI already specifies ELF attributes as the mechanism for
attaching feature bits to object files, so it is neither necessary nor
desirable to add another.
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#attributes
G
On Tue, Jan 14, 2025 at 3:07 PM Greg
On 1/14/25 2:13 PM, Simon Martin wrote:
On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
wrote:
We currently accept the following invalid code (EDG and MSVC do as
well)
clang does too: https://github.com/llvm/llvm-project/issues/121706 .
Note it m
On 1/14/25 8:25 AM, Simon Martin wrote:
[ Apologies for the previous incomplete, garbled email - I used the
shortcut to send the email by mistake way too early ]
Hi Jason,
On 14 Jan 2025, at 11:43, Simon Martin wrote:
Hi,
On 14 Jan 2025, at 2:56, Jason Merrill wrote:
On 1/12/25 2:39 PM, Si
Hi Richard,
> Sorry to be awkward, but I don't think we should put
> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT in base.
> CHEAP_SHIFT_EXTEND is a good base flag because it means we can make full
> use of a certain group of instructions. FULLY_PIPELINED_FMA similarly
> means that FMA chains beh
Wilco Dijkstra writes:
> As suggested in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673558.html
> update the gcc-15 Changes page:
>
> Add ILP32 depreciation to Caveats section.
OK once the GCC patch has gone in.
Thanks,
Richard
>
> ---
>
> diff --git a/htdocs/gcc-15/changes.html
On 1/14/25 2:56 PM, Marek Polacek wrote:
On Tue, Jan 14, 2025 at 08:35:44PM +0100, anetczuk wrote:
Thanks for review. New version in attachment.
Thanks, your patch looks good to me but I can't approve it.
Applied, thanks. This was small enough to not worry about copyright,
but for future c
Excerpts from Iain Sandoe's message of Januar 14, 2025 9:10 pm:
> Tested on x86_64, i686 darwin17 and aarch64 darwin21,
> OK for trunk, or alternate solution?
> thanks,
> Iain
>
Thank Iain,
Could a pull request be made upstream here?
https://github.com/dlang/dmd/pulls
Location of this module i
On 1/10/25 4:21 AM, Jakub Jelinek wrote:
On Thu, Jan 09, 2025 at 09:30:04PM -0500, Jason Merrill wrote:
--- gcc/cp/call.cc.jj 2024-12-11 17:27:52.481221310 +0100
+++ gcc/cp/call.cc 2024-12-19 18:50:52.478315892 +0100
@@ -8766,8 +8766,8 @@ convert_like_internal (conversion *convs
i
On Tue, 14 Jan 2025, Jason Merrill wrote:
> On 1/10/25 1:36 PM, Patrick Palka wrote:
> > On Tue, 1 Oct 2024, Patrick Palka wrote:
> > > On Mon, 16 Sep 2024, Patrick Palka wrote:
> > > > On Thu, 30 Nov 2023, Patrick Palka wrote:
> > > > > On Fri, 3 Nov 2023, Patrick Palka wrote:
> > > > > > On Tue,
The following makes niter analysis recognize a loop with an exit
condition scanning over a STRING_CST. This is done via enhancing
the force evaluation code rather than recognizing for example
strlen (s) as number of iterations because it allows to handle
some more cases.
STRING_CSTs are easy to h
The following addresses the fact that with loop masking (or regular
mask loads) we do not implement load shortening but we override
the case where we need that for correctness. Likewise when we
attempt to use loop masking to handle large trailing gaps we cannot
do so when there's this overrun case
pinging in case this was missed.
From: Aditya K
Sent: Sunday, December 29, 2024 6:36 PM
To: gcc-patches@gcc.gnu.org ; libstd...@gcc.gnu.org
Cc: jwak...@redhat.com
Subject: [PATCH] libstdc++: Use string::push_back instead of string::operator+=
>From db5036e40ed
On 1/10/25 1:36 PM, Patrick Palka wrote:
On Tue, 1 Oct 2024, Patrick Palka wrote:
On Mon, 16 Sep 2024, Patrick Palka wrote:
On Thu, 30 Nov 2023, Patrick Palka wrote:
On Fri, 3 Nov 2023, Patrick Palka wrote:
On Tue, 3 May 2022, Jason Merrill wrote:
On 5/2/22 14:50, Patrick Palka wrote:
Curr
On 1/14/25 1:43 PM, Patrick Palka wrote:
On Mon, 13 Jan 2025, Jason Merrill wrote:
On 1/13/25 3:27 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK, but do we also need this in the "still packed" case earlier in the
function?
I thi
Tested on x86_64, i686 darwin17 and aarch64 darwin21,
OK for trunk, or alternate solution?
thanks,
Iain
--- 8< ---
Recent merges from libphobos have broken bootstrap on many/most Darwin
version (those with 32bit multilibs, 32bit hosts, aarch64 and powerpc).
This is because the thread data are no
Hi,
This patch merges the D front-end and runtime library with upstream dmd
d6f693b46a, and the standard library with phobos 336bed6d8.
Synchronizing with the latest changes in v2.110.0.
D front-end changes:
- Import latest fixes from dmd v2.110.0-rc.1.
D runtime changes:
- Im
Hi,
On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
> On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
> wrote:
>>
>> We currently accept the following invalid code (EDG and MSVC do as
>> well)
>
> clang does too: https://github.com/llvm/llvm-project/issues/121706 .
>
> Note it might be useful if
committed to trunk
On Mon, Jan 6, 2025 at 6:06 PM Kito Cheng wrote:
>
> `.MASK_LEN_FOLD_LEFT_PLUS`(or `mask_len_fold_left_plus_m`) is expecting the
> return value will be the start value even if the length is 0.
>
> However current code gen in RISC-V backend is not meet that semantic, it will
> r
This patch only support landing pad value is 1.
The next version will implement function signature based labeling
scheme.
RISC-V CFI SPEC: https://github.com/riscv/riscv-cfi
gcc/ChangeLog:
* gcc/common/config/riscv/riscv-common.cc: Add ZICFILP ISA
string.
* gcc/config.gc
82 matches
Mail list logo
