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 () &&
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
>
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
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
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
>>>
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
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
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 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
>>
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 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
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
"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
>
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
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
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
>
Hi!
The
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
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
> *
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
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
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
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.
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
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
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:
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
> 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
> 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
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
Jørgen Kvalsvik writes:
> Hi,
>
> I propose these fixes for the current issues with the condition
> coverage.
>
> Rainer, I propose to simply delete the test with __sigsetjmp. I don't
> think it actually detects anything reasonable any more, I kept it around
> to prevent a regression. Since then
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
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
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
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
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
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
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, 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 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).
>
>
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.
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
v1 -> v2:
Remove spaces from changelog.
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,
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 :-(
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
>
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
> -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
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/
> *
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
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
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
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
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
> -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
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
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
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
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
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
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
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
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
>
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
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. */
> > +
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
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
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
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,
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
81 matches
Mail list logo
