On Tue, Apr 9, 2024 at 4:07 AM Kewen.Lin wrote:
>
> on 2024/4/8 18:47, Richard Biener wrote:
> > On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As the comments in PR88309 show, there are two oversights
> >> in rs6000_gimple_fold_builtin that pass align in bytes to
> >> b
On Tue, 9 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> Debug stmts are allowed by the verifier before the returns_twice calls.
Huh, interesting ;)
> More importantly, they don't have a lhs, so the current handling of
> arg_stmts statements to force them on the edges ICEs.
>
> The following patch j
On Tue, 9 Apr 2024, Aldy Hernandez wrote:
> BTW, I'm not opposed to this patch. Thank you for tracking this down,
> and feel free to commit as is if y'all PMs agree it's OK. I just
> wanted to know if there's a better way going forward. I can certainly
> put it on my TODO list once stage1 opens
Hi!
Debug stmts are allowed by the verifier before the returns_twice calls.
More importantly, they don't have a lhs, so the current handling of
arg_stmts statements to force them on the edges ICEs.
The following patch just keeps them where they were before.
Bootstrapped/regtested on x86_64-linux
Hi!
sqrt should be 0.5ulp precise, but the current implementation is less
precise than that.
The following patch uses the soft-fp code (like e.g. glibc for x86) for it
if possible. I didn't want to replicate the libgcc infrastructure for
choosing the right sfp-machine.h, so the patch just uses a
BTW, I'm not opposed to this patch. Thank you for tracking this down,
and feel free to commit as is if y'all PMs agree it's OK. I just
wanted to know if there's a better way going forward. I can certainly
put it on my TODO list once stage1 opens again.
And no, there probably isn't an obstack fo
on 2024/4/9 11:20, Peter Bergner wrote:
> On 4/8/24 9:37 PM, Kewen.Lin wrote:
>> on 2024/4/8 21:21, Peter Bergner wrote:
>> I prefer to remove it completely, that is:
>>
>>> -mdirect-move
>>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>>
>> The reason why you still kep
On 4/8/24 5:04 PM, Iain Sandoe wrote:
Hi
PR 109627 is about functions that have had their bodies completely elided, but
still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
These are causing issues for some linkers because such functions result in FDEs
with a 0 code exte
On 4/8/24 9:37 PM, Kewen.Lin wrote:
> on 2024/4/8 21:21, Peter Bergner wrote:
> I prefer to remove it completely, that is:
>
>> -mdirect-move
>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>
> The reason why you still kept it is to keep a historical record here?
I be
On 4/4/24 07:27, Nathaniel Shead wrote:
On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote:
On 4/2/24 20:57, Nathaniel Shead wrote:
On Tue, Apr 02, 2024 at 01:18:17PM -0400, Jason Merrill wrote:
On 3/28/24 23:21, Nathaniel Shead wrote:
- && !(modules_p () && DECL_DECLARED_I
On Thu, Apr 4, 2024 at 4:42 PM Jakub Jelinek wrote:
>
> On Wed, Apr 19, 2023 at 02:40:59AM +, Jiang, Haochen via Gcc-patches
> wrote:
> > > > (define_insn "aesenc"
> > > > - [(set (match_operand:V2DI 0 "register_operand" "=x,x")
> > > > - (unspec:V2DI [(match_operand:V2DI 1 "register_
Hi Peter,
on 2024/4/8 21:21, Peter Bergner wrote:
> On 4/8/24 3:55 AM, Kewen.Lin wrote:
>> on 2024/4/6 06:28, Peter Bergner wrote:
>>> +mno-direct-move
>>> +Target Undocumented WarnRemoved
>>> +
>>> mdirect-move
>>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>>> +Tar
On 4/4/24 08:27, Nathaniel Shead wrote:
On Wed, Apr 03, 2024 at 02:16:25PM -0400, Jason Merrill wrote:
On 3/28/24 08:22, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The testcase in comment 15 of the linked PR is caused because the
following
on 2024/4/8 18:47, Richard Biener wrote:
> On Mon, Apr 8, 2024 at 11:23 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR114614 shows, the newly added test case gcov-20.c by
>> commit r14-9789-g08a52331803f66 failed on targets which do
>> not support atomic profile update, there would be a message
>> like
on 2024/4/8 18:47, Richard Biener wrote:
> On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As the comments in PR88309 show, there are two oversights
>> in rs6000_gimple_fold_builtin that pass align in bytes to
>> build_aligned_type but which actually requires align in
>> bits, it
On Tue, Apr 9, 2024 at 9:58 AM H.J. Lu wrote:
>
> Define __APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32.
> When __APX_INLINE_ASM_USE_GPR32__ is defined, inline asm statements
> should contain only instructions compatible with r16-r31.
Ok.
>
> gcc/
>
> PR target/114587
>
Define __APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32.
When __APX_INLINE_ASM_USE_GPR32__ is defined, inline asm statements
should contain only instructions compatible with r16-r31.
gcc/
PR target/114587
* config/i386/i386-c.cc (ix86_target_macros_internal): Define
On Mon, Apr 8, 2024 at 11:44 PM H.J. Lu wrote:
>
> Define following macros for APX options:
>
> 1. __APX_EGPR__: -mapx-features=egpr.
> 2. __APX_PUSH2POP2__: -mapx-features=push2pop2.
> 3. __APX_NDD__: -mapx-features=ndd.
> 4. __APX_PPX__: -mapx-features=ppx.
For -mapx-features=, we haven't decide
> -Original Message-
> From: Andrew Pinski (QUIC)
> Sent: Friday, March 22, 2024 10:50 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski (QUIC)
> Subject: [PATCH] Another ICE after conflicting types of redeclaration
> [PR110682]
>
> This another one of these ICE after error issues wit
On Mon, Apr 8, 2024 at 4:04 PM Iain Sandoe wrote:
>
> Hi
>
> PR 109627 is about functions that have had their bodies completely elided,
> but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
I was thinking about how to fix this once and for all. The easiest
method I could
Hi
PR 109627 is about functions that have had their bodies completely elided, but
still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
These are causing issues for some linkers because such functions result in FDEs
with a 0 code extent.
The simplest representation of this is
On 4/5/24 14:47, Marek Polacek wrote:
On Fri, Apr 05, 2024 at 09:40:48AM +0200, Jakub Jelinek wrote:
Hi!
When looking at maybe_warn_for_constant_evaluated for the trivial
infinite loops patch, I've noticed that it can emit weird diagnostics
for if constexpr in templates, first warn that std::is
On 4/5/24 03:57, Jakub Jelinek wrote:
Hi!
Here is a new version of the PR114462 P2809R3 patch.
As clarified on core, for trivially empty iteration statements
(where the condition isn't empty or INTEGER_CST, because those
loops can't contain std::is_constant_evaluated() in the condition
and the m
On 4/5/24 03:35, Jakub Jelinek wrote:
Hi!
While ctors/dtors don't return anything (undeclared void or this pointer
on arm) and copy assignment operators normally return a reference to *this,
it isn't invalid to return uselessly some class object which might need
destructing, but the OpenMP claus
Hi Christophe!
On 2024-04-04T16:27:19+, Christophe Lyon wrote:
> rust has the (empty) rust.dvi and rust.html rules, but lacks the
> (empty) rust.install-dvi and rust.install-html ones.
Thanks, looks good to me.
Grüße
Thomas
> 2024-04-04 Christophe Lyon
>
> gcc/rust/
> * M
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT generated for the extern variable declarations w
On 4/8/24 12:26, David Faust wrote:
The behavior introduced in
fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol referenc
Hi!
On 2024-04-08T13:24:06+0100, Andrew Stubbs wrote:
> On 08/04/2024 11:45, Thomas Schwinge wrote:
>> On 2024-03-28T08:00:50+0100, I wrote:
>>> On 2024-03-22T15:54:48+, Andrew Stubbs wrote:
This patch alters the default (preferred) vector size to 32 on RDNA
devices to
better
Hi!
On 2024-03-21T12:20:38+0100, I wrote:
> On 2024-02-16T10:48:53-0800, Mike Stump wrote:
>> On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>>>
>>> There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
>>> target. I think claiming for it that it is a lra target is stra
Dear all,
the attached patch fixes argument checking of:
- C_SIZEOF - rejects-valid (see below) and ICE-on-valid
- C_F_POINTER - ICE-on-invalid
The interesting part is that C_SIZEOF was not well specified until
after F2018, where an interp request lead to an edit that actually
loosened restricti
The behavior introduced in
fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a s
On 4/8/24 2:45 AM, Paul Richard Thomas wrote:
Hi All,
This one is blazingly 'obvious'. I haven't had the heart to investigate why somebody thought that it is a good idea to check if unreferenced symbols are finalizable because, I suspect, that
'somebody' was me. Worse, I tried a couple of other
On 4/8/24 2:53 AM, Tobias Burnus wrote:
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which cont
> Am 08.04.2024 um 18:40 schrieb Aldy Hernandez :
>
> On Mon, Apr 8, 2024 at 6:29 PM Richard Biener wrote:
>>
>>
>>
Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
>>>
>>> On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy
Hello,
On Sun, Apr 07 2024, Xi Ruoyao wrote:
> On Thu, 2024-04-04 at 23:19 +0200, Martin Jambor wrote:
>> The patch has been approved by Honza in Bugzilla. (I hope. He did write
>> it looked reasonable.) Together with the patch for PR 113907, it has
>> passed bootstrap, LTO bootstrap and LTO pro
Patch v2.
I realised that it's not only negative delim values that cause the
problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
will cause traits_type::find to match 'a' but then the eq_int_type
comparison will fail because (int)'a' != (int)('a' + 256).
This version of the p
I recently disabled _Utf8_view for -fno-char8_t, but we can just make it
use char instead of char8_t. The existing uses of it in the library are
unaffected.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Instead of just omitting the definition of __unicode::_Utf8_view when
char
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Adjust expected errors or skip tests as UNSUPPORTED if -fno-char8_t is
used in the test flags.
libstdc++-v3/ChangeLog:
* testsuite/20_util/integer_comparisons/equal_neg.cc: Use
no-opts selector for errors that depe
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.
libstdc++-v3/Ch
On Mon, Apr 8, 2024 at 6:29 PM Richard Biener wrote:
>
>
>
> > Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
> >
> > On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> PR middle-end/114604
> *
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
Best regards,
Pierre-Emmanuel
--
Prevent rust language from building when cargo is
missing.
config/ChangeLog:
* acx.m4: A
> Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
>
> On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>>
>> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
PR middle-end/114604
* gimple-range.cc (enable_ranger): Initialize the global
bi
On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>
> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > > PR middle-end/114604
> > > * gimple-range.cc (enable_ranger): Initialize the global
> > > bitmap obstack.
> > > (disable_ranger): Release it
Not sure how this happend, but: svsudot is supposed to be expanded
as USDOT with the operands swapped. However, a thinko in the
expansion of svsudot meant that the arguments weren't in fact
swapped; the attempted swap was just a no-op. And the testcases
blithely accepted that.
Tested on aarch64-
On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > PR middle-end/114604
> > * gimple-range.cc (enable_ranger): Initialize the global
> > bitmap obstack.
> > (disable_ranger): Release it.
> > ---
> > gcc/gimple-range.cc | 4
> > 1 file changed,
Define following macros for APX options:
1. __APX_EGPR__: -mapx-features=egpr.
2. __APX_PUSH2POP2__: -mapx-features=push2pop2.
3. __APX_NDD__: -mapx-features=ndd.
4. __APX_PPX__: -mapx-features=ppx.
5. __APX_INLINE_ASM_USE_GPR32__: -mapx-inline-asm-use-gpr32.
They can be used to make assembly cod
On Mon, Apr 8, 2024 at 11:50 AM Richard Biener wrote:
>
> The following fixes ranger bitmap allocation when invoked from IPA
> context where the global bitmap obstack possibly isn't initialized.
> Instead of trying to use one of the ranger obstacks the following
> simply initializes the global bit
Committed to trunk, thanks Tatsuyuki!
On Fri, Mar 29, 2024 at 2:32 PM Kito Cheng wrote:
>
> Hi Tatsuyuki:
>
> Thanks for your hard work and keep updating, the patch set is LGTM, I
> plan to commit this next week if no further comments :)
>
> Hi MaskRay:
>
> Thanks for your review on the patchset!
Here are two more patches for the condition coverage.
Inlined conditions are actually counted this time, as the recorded
expression mapping uses the new, deep-copied gconds as keys and not the
pointers from the source function.
The reported UB is gone when the number of conditions are exactly 64
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
constant for the next iteration at the end of the loop body, even if there
was never a next i
Properly add the condition -> expression mapping of inlined gconds from
the caller into the callee map. This is a fix for PR114599 that works
beyond fixing the segfault, as the previous fixed copied references to
the source gconds, not the deep copied ones that end up in the calle
body.
The new te
Hi!
The
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Richard Ball writes:
> Hi all,
>
> Adding the NEON-SVE bridge intrinsics that were missed
> in the last patch.
>
> Thanks,
> Richard
OK, thanks.
Richard
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index
> 9fd224c1df3f05eadcedaaa41c0859e712b93b78..df63af48298564de9c
On 4/8/24 3:55 AM, Kewen.Lin wrote:
> on 2024/4/6 06:28, Peter Bergner wrote:
>> +mno-direct-move
>> +Target Undocumented WarnRemoved
>> +
>> mdirect-move
>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>> +Target Undocumented WarnRemoved
>
> When reviewing my previous
Hi all,
Adding the NEON-SVE bridge intrinsics that were missed
in the last patch.
Thanks,
Richarddiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
9fd224c1df3f05eadcedaaa41c0859e712b93b78..df63af48298564de9c35bab1dd35891c2581e3d6
100644
--- a/htdocs/gcc-14/changes.html
"Swinney, Jonathan" writes:
> The test for this intrinsic was failing silently and so it failed to
> report the bug reported in 114521. This patch modifes the test to
> report the result.
>
> Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114521
>
> Signed-off-by: Jonathan Swinney
> ---
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, April 8, 2024 9:43 PM
> To: Jiang, Haochen
> Cc: Hongtao Liu ; gcc-patches@gcc.gnu.org; Liu, Hongtao
> ; ubiz...@gmail.com
> Subject: Re: [PATCH] i386: Fix aes/vaes patterns [PR114576]
>
> On Mon, Apr 08, 2024 at 12:33:39PM +
On Mon, Apr 08, 2024 at 12:33:39PM +, Jiang, Haochen wrote:
> Sorry for the late response since I am on vacation for now.
>
> > As the following testcase shows, the above change was incorrect.
> >
> > Using aes isa for the second alternative is obviously wrong, aes is enabled
> > whenever -ma
Hi Jakub,
Sorry for the late response since I am on vacation for now.
> As the following testcase shows, the above change was incorrect.
>
> Using aes isa for the second alternative is obviously wrong, aes is enabled
> whenever -maes is, regardless of -mavx or -mno-avx, so the above change
> mea
On 4/8/24 13:43, Ilya Leoshkevich wrote:
> On Sat, 2024-04-06 at 18:58 +0200, Jakub Jelinek wrote:
>> Hi!
>>
>> The following testcase is miscompiled, because we have initially
>> a movti which loads the 0x3f803f80ULL TImode constant
>> from constant pool. Later on we split it into a pair
On 08/04/2024 11:45, Thomas Schwinge wrote:
Hi!
On 2024-03-28T08:00:50+0100, I wrote:
On 2024-03-22T15:54:48+, Andrew Stubbs wrote:
This patch alters the default (preferred) vector size to 32 on RDNA devices to
better match the actual hardware. 64-lane vectors will continue to be
used wh
Segher Boessenkool writes:
> Hi!
>
> On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
>> The following avoids re-walking and re-combining the instructions
>> between i2 and i3 when the pattern of i2 doesn't change.
>>
>> Bootstrap and regtest running ontop of a reversal of
>> r14-
On Mon, 8 Apr 2024, Richard Biener wrote:
> On Fri, 5 Apr 2024, Jan Hubicka wrote:
>
> > > + /* When there's a call that might not return the last iteration
> > > + is possibly partial. This matches what we check in invariant
> > > + motion.
> > > + ??? For the call argument ev
On Sat, 2024-04-06 at 18:58 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because we have initially
> a movti which loads the 0x3f803f80ULL TImode constant
> from constant pool. Later on we split it into a pair of DImode
> loads. Now, for the first load (wh
On Fri, 5 Apr 2024, Jan Hubicka wrote:
> > + /* When there's a call that might not return the last iteration
> > +is possibly partial. This matches what we check in invariant
> > +motion.
> > +??? For the call argument evaluation it would be still OK. */
> > + if
On Mon, Apr 8, 2024 at 11:23 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR114614 shows, the newly added test case gcov-20.c by
> commit r14-9789-g08a52331803f66 failed on targets which do
> not support atomic profile update, there would be a message
> like:
>
> warning: target does not support atomic pr
On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
>
> Hi,
>
> As the comments in PR88309 show, there are two oversights
> in rs6000_gimple_fold_builtin that pass align in bytes to
> build_aligned_type but which actually requires align in
> bits, it causes unexpected ICE or hanging in function
> is_
Hi!
On 2024-03-28T08:00:50+0100, I wrote:
> On 2024-03-22T15:54:48+, Andrew Stubbs wrote:
>> This patch alters the default (preferred) vector size to 32 on RDNA devices
>> to
>> better match the actual hardware. 64-lane vectors will continue to be
>> used where they are hard-coded (such as
The `function_attribute_inlinable_p` hook documentation described it
returning the value if it is OK to inline the provided fndecl into "the
current function". AFAICS This hook is only called when
`current_function_decl` is the same as the `fndecl` argument that the
hook is given, hence asking whe
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which contains a named-list input file from SPEC
The following fixes ranger bitmap allocation when invoked from IPA
context where the global bitmap obstack possibly isn't initialized.
Instead of trying to use one of the ranger obstacks the following
simply initializes the global bitmap obstack around an active ranger.
Bootstrapped and tested on
Richard Biener writes:
> On Fri, Apr 5, 2024 at 3:52 PM Richard Sandiford
>> This isn't a regression on a known testcase. However, it's a nasty
>> wrong code bug that could conceivably trigger for autovec code (although
>> I've not been able to construct a reproducer so far). That fix is also
>>
Hi All,
This one is blazingly 'obvious'. I haven't had the heart to investigate why
somebody thought that it is a good idea to check if unreferenced symbols
are finalizable because, I suspect, that 'somebody' was me. Worse, I tried
a couple of other fixes before I hit on the 'obvious' one :-(
The
We're inspecting the replaced PHI node after releasing it.
Bootstrapped and tested on x86-64-unknown-linux-gnu, pushed.
PR tree-optimization/114624
* tree-scalar-evolution.cc (final_value_replacement_loop):
Get at the PHI arg location before releasing the PHI node.
Hi,
As the comments in PR88309 show, there are two oversights
in rs6000_gimple_fold_builtin that pass align in bytes to
build_aligned_type but which actually requires align in
bits, it causes unexpected ICE or hanging in function
is_miss_rate_acceptable due to zero align_unit value.
This patch is
Hi,
As PR114614 shows, the newly added test case gcov-20.c by
commit r14-9789-g08a52331803f66 failed on targets which do
not support atomic profile update, there would be a message
like:
warning: target does not support atomic profile update,
single mode is selected
Since the test c
Hi Mike,
on 2024/3/20 12:16, Michael Meissner wrote:
> This patch adds some simple tests for -mcpu=power11 support. In order to run
> these tests, you need an assembler that supports the appropriate option for
> supporting the Power11 processor (-mpower11 under Linux or -mpwr11 under AIX).
>
> I
On Mon, Apr 08, 2024 at 04:49:58PM +0800, Xi Ruoyao wrote:
> On Mon, 2024-04-08 at 16:46 +0800, Yang Yujie wrote:
> > v1 -> v2:
> > Remove spaces from changelog.
>
> I've rebuilt the base system with a GCC including this patch. LTO+PGO
> bootstrap fine, regtested fine, and no issues observed.
>
Hi Peter,
on 2024/4/6 06:28, Peter Bergner wrote:
> This is a cleanup patch in preparation to fixing the real bug in PR101865.
> TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
> Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
> and delete
On Mon, 2024-04-08 at 16:46 +0800, Yang Yujie wrote:
> v1 -> v2:
> Remove spaces from changelog.
I've rebuilt the base system with a GCC including this patch. LTO+PGO
bootstrap fine, regtested fine, and no issues observed.
I do usually include the optimization flags into LDFLAGS when I do LTO,
s
v1 -> v2:
Remove spaces from changelog.
This patch fixes the back-end context switching in cases where functions
should be built with their own target contexts instead of the
global one, such as LTO linking and functions with target attributes (TBD).
PR target/113233
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loon
LGTM. Thanks.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-08 16:09
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Refine the error msg for RVV intrinisc required ext
From: Pan Li
The RVV intrinisc API has sorts of required extension from both
the march
From: Pan Li
The RVV intrinisc API has sorts of required extension from both
the march or target attribute. It will have error message similar
to below:
built-in function '__riscv_vsetvl_e8m4\(vl\)' requires the V ISA extension
However, it is not accurate as we have many additional sub extenst
Tested on x86_64 and aarch64 Darwin, pushed to trunk, thanks,
Iain
--- 8< ---
The specs for coverage ere out of date leading to test fails for
fcondition-coverage cases. Fixed by updating to match the specs
in gcc/gcc.cc.
gcc/ChangeLog:
* config/darwin.h (LINK_COMMAND_SPEC_A): Update co
85 matches
Mail list logo
