On Tue, 2024-01-23 at 10:37 +0800, chenglulu wrote:
> LGTM!
>
> Thanks!
Pushed v2 as attached. The only change is in the comment: Qinggang told
me TLE LE relaxation actually *requires* explicit relocs.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From f12317306e
Hi!
As the following testcase shows, I forgot to call c_fully_fold on the
__atomic_*/__sync_* operands called on _BitInt address, the expressions
are then used inside of TARGET_EXPR initializers etc. and are never fully
folded later, which means we can ICE e.g. on C_MAYBE_CONST_EXPR trees
inside o
On Dec 5, 2023, Alexandre Oliva wrote:
> arm: fix c23 0-named-args caller-side stdarg
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639472.html
> The commit message doesn't name explicitly the fixed testsuite
> failures. Here they are:
> FAIL: gcc.dg/c23-stdarg-4.c execution
在 2024/1/23 下午4:04, Xi Ruoyao 写道:
On Tue, 2024-01-23 at 10:37 +0800, chenglulu wrote:
LGTM!
Thanks!
Pushed v2 as attached. The only change is in the comment: Qinggang told
me TLE LE relaxation actually *requires* explicit relocs.
I think one of the reasons is also because we cannot proper
Hi Mike,
on 2024/1/6 07:35, Michael Meissner wrote:
> This patch implements support for a potential future PowerPC cpu. Features
> added with -mcpu=future, may or may not be added to new PowerPC processors.
>
> This patch adds support for the -mcpu=future option. If you use -mcpu=future,
> the
on 2024/1/6 07:37, Michael Meissner wrote:
> This patch re-enables generating load and store vector pair instructions when
> doing certain memory copy operations when -mcpu=future is used.
>
> During power10 development, it was determined that using store vector pair
> instructions were problemati
Hi Steve,
Thanks for the patch. I’ll take time to do a proper review, but after a first
read I had the following questions:
- "an OS's libm may/will contain cospi(), etc.”: do those functions conform to
any standard? Are there plans to implement them outside FreeBSD at this point?
- On systems
Slightly changed patch:
nvptx_attach_host_thread_to_device now fails again with an error for
CUDA_ERROR_DEINITIALIZED, except for GOMP_OFFLOAD_fini_device.
I think it makes more sense that way.
Tobias Burnus wrote:
Testing showed that the libgomp.c/target-52.c failed with:
libgomp: cuCtxGet
Hi!
I see
../../gcc/config/gcn/gcn.cc: In function ‘void
gcn_hsa_declare_function_name(FILE*, const char*, tree)’:
../../gcc/config/gcn/gcn.cc:6568:67: warning: unused parameter ‘decl’
[-Wunused-parameter]
6568 | gcn_hsa_declare_function_name (FILE *file, const char *name, tree decl)
|
On Tue, Jan 16, 2024 at 07:32:03PM -0700, Jeff Law wrote:
>
>
> On 1/15/24 02:22, Ilya Leoshkevich wrote:
> > Compile tested for the ia64-elf target; bootstrap and regtest running
> > on x86_64-redhat-linux. Ok for trunk when successful?
> >
> >
> >
> > ia64-elf build fails with the following
On Tue, 23 Jan 2024 at 10:01, Jakub Jelinek wrote:
> Hi!
>
> I see
> ../../gcc/config/gcn/gcn.cc: In function ‘void
> gcn_hsa_declare_function_name(FILE*, const char*, tree)’:
> ../../gcc/config/gcn/gcn.cc:6568:67: warning: unused parameter ‘decl’
> [-Wunused-parameter]
> 6568 | gcn_hsa_declare_
SPEC 2017 wrf benchmark expose unreasonble memory usage of VSETVL PASS
that is, VSETVL PASS consume over 33 GB memory which make use impossible
to compile SPEC 2017 wrf in a laptop.
The root cause is wasting-memory variables:
unsigned num_exprs = num_bbs * num_regs;
sbitmap *avl_def_loc = sbitmap
While the bug is persisting that LTO streaming picks up a CONST_DECL
from an attribute argument on a VAR_DECL which with -fdebug-type-section
refers to a DIE in a type unit we can handle this gracefully, at least
with -fno-checking. Do so. The C++ frontend nevetheless should resolve
the CONST_DEC
In the original fix for this PR, I'd made sure that
including didn't reach the final return in
simulate_builtin_function_decl (which would indicate duplicate
function definitions). But it seems I forgot to do the same
thing for C++, which defines all of its overloads directly.
This patch fixes a
Hi Sandra,
thanks for the comments and proposals! An updated version is enclosed.
Unless you find more issues, I intent to commit it soon.
Tobias
PS: I think besides filling gaps, some editing wouldn't harm; if you
feel bored ...
https://gcc.gnu.org/onlinedocs/libgomp/
libgomp.texi: Documen
On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote:
>
> Hi Steve,
Hello, long time no see.
> Thanks for the patch. I’ll take time to do a proper review, but after a first
> read I had the following questions:
>
> - "an OS's libm may/will contain cospi(), etc.”: do those functions conform
> to a
When building GCC with --enable-default-ssp, the stack protector is
enabled for got-load.C, causing additional GOT loads for
__stack_chk_guard. So mem/u will be matched more than 2 times and the
test will fail.
Disable stack protector to fix this issue.
gcc/testsuite:
* g++.target/loong
The following avoids using exact_log2 on the number of SIMD clone calls
to be emitted when vectorizing calls since that can easily be not
a power of two in which case it will return -1. For different simd
clones the number of calls will differ by a multiply with a power of two
only so using floor_
On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> The following avoids using exact_log2 on the number of SIMD clone calls
> to be emitted when vectorizing calls since that can easily be not
> a power of two in which case it will return -1. For different simd
> clones the number of
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > The following avoids using exact_log2 on the number of SIMD clone calls
> > to be emitted when vectorizing calls since that can easily be not
> > a power of two in which case it will ret
The vect_int_mod target selector is evaluated with the options in
DEFAULT_VECTCFLAGS in effect, but these options are not automatically
passed to tests out of the vect directories. So this test fails on
targets where integer vector modulo operation is supported but requiring
an option to enable, f
Alex Coplan writes:
> On 22/01/2024 13:49, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > In r14-5820-ga49befbd2c783e751dc2110b544fe540eb7e33eb I added support to
>> > RTL-SSA for inserting new insns, which included support for users
>> > creating new defs.
>> >
>> > However, I missed that
Alex Coplan writes:
>> > + writeback_pats[i] = orig_rtl[i];
>> > +
>> > + // Now that we've characterized the defs involved, go through the
>> > + // debug uses and determine how to update them (if needed).
>> > + for (auto use : set->debug_insn_uses ())
>> > + {
>> > +if
On Tue, Jan 23, 2024 at 01:03:46PM +0100, Richard Biener wrote:
> On Tue, 23 Jan 2024, Jakub Jelinek wrote:
>
> > On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > > The following avoids using exact_log2 on the number of SIMD clone calls
> > > to be emitted when vectorizing calls
Alexandre Oliva writes:
> Calling arm_neon.h functions that take lanes as arguments may fail to
> report malformed values if the intrinsic happens to be optimized away,
> e.g. because it is pure or const and the result is unused.
>
> Adding __AARCH64_LANE_CHECK calls to the always_inline functions
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> On Tue, Jan 23, 2024 at 01:03:46PM +0100, Richard Biener wrote:
> > On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> >
> > > On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > > > The following avoids using exact_log2 on the number of SIMD c
On Tue, Jan 23, 2024 at 01:40:15PM +0100, Richard Biener wrote:
> It's never going to be 3 vs 2 but 3 * 2^n vs. 3 * 2^m so floor or
> ceil doesn't matter. In fact we could have just using
> some inverse of exact_log2 (n->simdclone->simdlen). That is,
> it's only simdlen that's varying in this add
LGTM!
Thanks!
在 2024/1/23 下午7:35, Xi Ruoyao 写道:
When building GCC with --enable-default-ssp, the stack protector is
enabled for got-load.C, causing additional GOT loads for
__stack_chk_guard. So mem/u will be matched more than 2 times and the
test will fail.
Disable stack protector to fix thi
On Tue, Jan 23, 2024 at 11:10:05AM +0100, Jakub Jelinek wrote:
> > --- a/gcc/config/ia64/ia64.cc
> > +++ b/gcc/config/ia64/ia64.cc
> > @@ -3886,7 +3886,7 @@ ia64_expand_prologue (void)
> > /* Output the textual info surrounding the prologue. */
> >
> > void
> > -ia64_start_function (FILE *file
On 22/01/2024 21:50, Alex Coplan wrote:
> On 22/01/2024 15:59, Richard Sandiford wrote:
> > Alex Coplan writes:
> > > As the PR shows (specifically #c7) we are missing updating uses of mem
> > > when inserting an stp in the aarch64 load/store pair fusion pass. This
> > > patch fixes that.
> > >
>
Fix the m2 build warning and error:
[...]
../../src/gcc/m2/mc/mc.flex:32:9: warning: "alloca" redefined
32 | #define alloca __builtin_alloca
| ^~
In file included from /usr/include/stdlib.h:587,
from :22:
/usr/include/alloca.h:35:10: note: this is the location
"H.J. Lu" writes:
> Fix the m2 build warning and error:
>
> [...]
> ../../src/gcc/m2/mc/mc.flex:32:9: warning: "alloca" redefined
>32 | #define alloca __builtin_alloca
> | ^~
> In file included from /usr/include/stdlib.h:587,
> from :22:
> /usr/include/alloc
On Mon, Jan 22, 2024 at 11:10 PM Richard Biener wrote:
>
> On Mon, 22 Jan 2024, Jeff Law wrote:
>
> >
> >
> > On 1/15/24 06:34, Richard Biener wrote:
> > > When the x86 backend generates code for cpymem with the rep_8byte
> > > strathegy for the 8 byte aligned main rep movq it needs to compute
> >
On Tue, Jan 23, 2024 at 6:15 AM H.J. Lu wrote:
>
> On Mon, Jan 22, 2024 at 11:10 PM Richard Biener wrote:
> >
> > On Mon, 22 Jan 2024, Jeff Law wrote:
> >
> > >
> > >
> > > On 1/15/24 06:34, Richard Biener wrote:
> > > > When the x86 backend generates code for cpymem with the rep_8byte
> > > > st
On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> Hi Steve,
>
> Thanks for the patch. I’ll take time to do a proper review, but
> after a first read I had the following questions:
>
> - "an OS's libm may/will contain cospi(), etc.”: do those functions
> conform to any standard? Are th
Fix ia32 test failure:
FAIL: gcc.dg/torture/pr113255.c -O1 (test for excess errors)
Excess errors:
cc1: error: '-mstringop-strategy=rep_8byte' not supported for 32-bit code
PR rtl-optimization/113255
* gcc.dg/torture/pr113255.c (dg-additional-options): Add only
if not i
There is no need to save callee-saved registers in noreturn functions
if they don't throw nor support exceptions. We can treat them the same
as functions with no_callee_saved_registers attribute.
Adjust stack-check-17.c for noreturn function which no longer saves any
registers.
With this change,
Changes in v3:
1. Rebase against commit 02e68389494
2. Don't add call_no_callee_saved_registers to machine_function since
all callee-saved registers are properly clobbered by callee with
no_callee_saved_registers attribute.
Changes in v2:
1. Rebase against commit f9df00340e3
2. Don't add redund
When an interrupt handler is implemented by an assembly stub which does:
1. Save all registers.
2. Call a C function.
3. Restore all registers.
4. Return from interrupt.
it is completely unnecessary to save and restore any registers in the C
function called by the assembly stub, even if they woul
Radek Barton writes:
> Hello Richard.
>
> Thank you for your suggestion. I am sending a patch update according to it.
>
>> How about avoiding the clash by using the names HIDDEN, SYMBOL_TYPE and
>> SYMBOL_SIZE, with SYMBOL_TYPE taking the symbol type as argument?
>
> Yes, unless the symbol is expl
Hi All,
This fixes a bug where vect_create_epilog_for_reduction does not handle the
case where all exits are early exits. In this case we should do like induction
handling code does and not have a main exit.
Bootstrapped Regtested on x86_64-pc-linux-gnu
with --enable-checking=release --enable-lt
On Tue, 23 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> This fixes a bug where vect_create_epilog_for_reduction does not handle the
> case where all exits are early exits. In this case we should do like
> induction
> handling code does and not have a main exit.
>
> Bootstrapped Regtested on
Adds missing bti instruction at the beginning of a virtual
thunk, when bti is enabled.
gcc/ChangeLog:
* config/arm/arm.cc (arm_output_mi_thunk): Emit
insn for bti_c when bti is enabled.
gcc/testsuite/ChangeLog:
* g++.target/arm/bti_thunk.C: New test.diff --git a/gcc/conf
On Mon, Jan 22, 2024 at 11:10 PM Richard Biener wrote:
>
> On Mon, 22 Jan 2024, Jeff Law wrote:
>
> >
> >
> > On 1/15/24 06:34, Richard Biener wrote:
> > > When the x86 backend generates code for cpymem with the rep_8byte
> > > strathegy for the 8 byte aligned main rep movq it needs to compute
> >
Hi All,
This renamed main_exit_p to last_val_reduc_p to more accurately
reflect what the value is calculating.
Ok for master if bootstrap passes? Incremental build shows it's fine.
Thanks,
Tamar
gcc/ChangeLog:
* tree-vect-loop.cc (vect_get_vect_def,
vect_create_epilog_for_reduc
From: Ronan Desplanques
gcc/ada/
* gnatvsn.ads: Update year.
---
gcc/ada/gnatvsn.ads | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/gnatvsn.ads b/gcc/ada/gnatvsn.ads
index 934c22206f7..29238362cc0 100644
--- a/gcc/ada/gnatvsn.ads
+++ b/gcc/ada/gnatvsn.ads
@@
> Am 23.01.2024 um 17:04 schrieb Tamar Christina :
>
> Hi All,
>
> This renamed main_exit_p to last_val_reduc_p to more accurately
> reflect what the value is calculating.
>
> Ok for master if bootstrap passes? Incremental build shows it's fine.
Ok
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
On Tue, Jan 23, 2024 at 06:40:27AM -0800, Steve Kargl wrote:
> On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> > Hi Steve,
> >
> > Thanks for the patch. I’ll take time to do a proper review, but
> > after a first read I had the following questions:
> >
> > - "an OS's libm may/will c
I've moved to BayLibre and don't have access to my codesourcery.com
address, at least for a while.
ChangeLog:
* MAINTAINERS: Update
Signed-off-by: Andrew Stubbs
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb5a4250
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote:
> >
> > Hi Steve,
>
> Hello, long time no see.
Time is short and we're all busy with life, but it is nice to see
familiar names!
>
> > Thanks for the patch. I’ll take time to d
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, I forgot to call c_fully_fold on the
> __atomic_*/__sync_* operands called on _BitInt address, the expressions
> are then used inside of TARGET_EXPR initializers etc. and are never fully
> folded later, which mea
Kwok Cheung Yeung wrote:
This patch adds support for the indirect clause on the OpenMP 'declare
target' directive in Fortran. As with the C and C++ front-ends, this
applies the 'omp declare target indirect' attribute on affected
function declarations. The C test cases have also been translated
On Mon, 2024-01-22 at 15:27 +0800, chenglulu wrote:
> > > The failure of this test case was because the compiler believes that two
> > > (UNSPEC_PCREL_64_PART2 [(symbol)]) instances would always produce the
> > > same result, but this isn't true because the result depends on PC. Thus
> > > (pc) ne
Change from v1: The message is changed as per the review.
The powerpc test-case is dropped from the changes as the
part quoted in a comment now does not change and so cannot
cause further confusion. The commit message is tweaked.
It now also mentions clang. I intend to commit this on
Thursday 202
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE attribute.
I factored the code for the treatment
On 1/22/24 13:11, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13?
-- >8 --
Here we handle the operator expression u < v inconsistently: in a SFINAE
context (such as a requires-expression) we accept the it, and in a
non-SFINAE context we re
Matthias Kretz writes:
> On Sunday, 10 December 2023 14:29:45 CET Richard Sandiford wrote:
>> Thanks for the patch and sorry for the slow review.
>
> Sorry for my slow reaction. I needed a long vacation. For now I'll focus on
> the design question wrt. multi-arch compilation.
>
>> I can only comm
On 1/19/24 21:18, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK. A lambda could return a dangling reference, but it's unlikely.
-- >8 --
-Wdangling-reference checks if a function receives a temporary as its
argument, and only warns if any of the argumen
On 1/19/24 02:41, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu using a cross-compiler to
arm-unknown-linux-gnueabihf with --enable-threads=0 that the link test
is correctly skipped. OK for trunk?
OK.
-- >8 --
This disables the new test added by r14-8168 on machines that don't have
TL
> SPEC 2017 wrf benchmark expose unreasonble memory usage of VSETVL PASS
> that is, VSETVL PASS consume over 33 GB memory which make use impossible
> to compile SPEC 2017 wrf in a laptop.
>
> The root cause is wasting-memory variables:
LGTM. The new code matches compute_lcm_local_properties mor
Updated my email address.
Committed as r14-8374-ged4c7893de2cba.
Tobias
commit ed4c7893de2cbae0a07bb4984e408d57e6db06f3
Author: Tobias Burnus
Date: Tue Jan 23 22:18:57 2024 +0100
MAINTAINERS: Update my email address
ChangeLog:
* MAINTAINERS: Update my email addr
On Tue, 23 Jan 2024, Jason Merrill wrote:
> On 1/22/24 13:11, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk/13?
> >
> > -- >8 --
> >
> > Here we handle the operator expression u < v inconsistently: in a SFINAE
> > context (such as a r
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initial
On Linux/x86_64,
a98d5130a6dcff2ed4db371e500550134777b8cf is the first bad commit
commit a98d5130a6dcff2ed4db371e500550134777b8cf
Author: Richard Biener
Date: Mon Jan 15 12:55:20 2024 +0100
rtl-optimization/113255 - base_alias_check vs. pointer difference
caused
FAIL: gcc.dg/guality/pr54
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
>
> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
> >>>
> >>> From: Björn Schäpers
> >>>
> >>> Fixes https://github.com/ianlanceta
>> Why that change? Was no-schedule necessary before and is not anymore?
>> Is it a result from the changes? I'd hope not.
Yes. But reasonable. So adapt testcase is enough.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-24 05:12
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kit
This is consistent with std::tuple's __const_assignable member function,
and will be reused when implementing the new pair::operator= overloads
from P2165R4.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (pair::_S_const_assignable): Define,
factored out from ...
(pair:
Tested on x86_64-pc-linux-gnu, does this look OK for trunK?
-- >8 --
This implements the C++23 paper P2165R4 Compatibility between tuple,
pair and tuple-like objects, which builds upon many changes from the
earlier C++23 paper P2321R2 zip.
Some declarations had to be moved around so that they're
On Tue, 23 Jan 2024, 23:53 Patrick Palka, wrote:
> This is consistent with std::tuple's __const_assignable member function,
> and will be reused when implementing the new pair::operator= overloads
> from P2165R4.
>
OK
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h (pair::_S_
Hi,
This is the 4th version of the patch.
It based on the following proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635884.html
Represent the missing dependence for the "counted_by" attribute and its
consumers
**The summary of the proposal is:
* Add a new internal functi
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This includ
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
Since the result type of the call to .ACCESS_WITH_SIZE is a pointer to
the element type. The original array_ref is converted to an indirect_ref,
which introduced two issues for the instrumenation of bound sanitizer:
A. The index for the original array_ref was mixed into the offset
expression for t
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
The reduced testcase for pr113429 (cam4 failure) needed additional
modules so it wasn't committed.
The fuzzer found a c testcase that was also fixed with pr113429's fix.
Adding it as a regression test.
PR 113429
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113429.c: N
ok
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-01-24 08:50
To: gcc-patches
CC: juzhe.zhong; kito.cheng; law; rdapp; vineetg; Patrick O'Neill
Subject: [PATCH] RISC-V: Add regression test for vsetvl bug pr113429
The reduced testcase for pr113429 (cam4 failure) needed additional
modules
The reduced testcase for pr113429 (cam4 failure) needed additional
modules so it wasn't committed.
The fuzzer found a c testcase that was also fixed with pr113429's fix.
Adding it as a regression test.
PR target/113429
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113
Hi Mike,
on 2024/1/12 01:29, Michael Meissner wrote:
> This is version 2 of the patch. The only difference is I made the test case
> simpler to read.
>
> In looking at support for load vector pair and store vector pair for the
> PowerPC in GCC, I noticed that we were missing a print_operand outp
On 1/23/24 8:30 PM, Kewen.Lin wrote:
>> -output_operand_lossage ("invalid %%x value");
>> +output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>> 'x'));
>
> Nit: Seems simpler with
>
> output_operand_lossage ("invalid %%%c value", (char) code);
Agreed, good catch.
From: Pan Li
According to the issue as below.
https://hub.fgit.cf/riscv-non-isa/riscv-elf-psabi-doc/pull/416
When the mode size of vls integer mode is less than 2 * XLEN, we will
take the gpr/fpr for both the args and the return values. Instead of
the reference. For example the below code:
typ
On Linux/x86_64,
a98d5130a6dcff2ed4db371e500550134777b8cf is the first bad commit
commit a98d5130a6dcff2ed4db371e500550134777b8cf
Author: Richard Biener
Date: Mon Jan 15 12:55:20 2024 +0100
rtl-optimization/113255 - base_alias_check vs. pointer difference
caused
FAIL: gcc.dg/torture/pr11
Hi Suwa-san,
I've finally processed the new issues introduced by this change.
On Wed, May 10, 2023 at 2:10 AM Max Filippov wrote:
> On Mon, May 8, 2023 at 6:38 AM Takayuki 'January June' Suwa
> wrote:
> >
> > gcc/ChangeLog:
> >
> > * config/xtensa/constraints.md (R, T, U):
> > C
From: Takayuki 'January June' Suwa
gcc/ChangeLog:
* config/xtensa/constraints.md (R, T, U):
Change define_constraint to define_memory_constraint.
* config/xtensa/predicates.md (move_operand): Don't check that a
constant pool operand size is a multiple of UNITS_PER
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
David Binderman 2017-07-01 13:24:44 UTC
trunk/gcc/cp/lex.c:116]: (style) Boolean result is used in bitwise
operation. Clarify expression with parentheses.
Source code is
gcc_checking_
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
>From 10b501ffa8a11c7f10fd6e6ab5d9a876a321fe13 Mon Sep 17 00:00:00 2001
From: Jasmine
Date: Tue, 23 Jan 2024 21:18:13 -0800
Subject: [PATCH] Fix compiler warning: Boolean result is used
on 2024/1/24 11:11, Peter Bergner wrote:
> On 1/23/24 8:30 PM, Kewen.Lin wrote:
>>> - output_operand_lossage ("invalid %%x value");
>>> + output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>>> 'x'));
>>
>> Nit: Seems simpler with
>>
>> output_operand_lossage ("invalid %%%c
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
>
> > - If I get this right, to take one example, the Fortran front-end will emit
> > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper
> > calling acospif(), which is called either from libm or from libgfortra
The split for movv8di is not ready to handle the case where the setting
register overlaps with the address of the memory that is being load.
Fixing the split than just making the output constraint as an early clobber
for this alternative. The split would first need to figure out which register
is o
On 22 January 2024 21:33:17 CET, Kwok Cheung Yeung
wrote:
>Hi
>
>There was a bug in the declare-target-indirect-2.c libgomp testcase (testing
>indirect calls in offloaded target regions, spread over multiple
>teams/threads) that due to an errant fallthrough in a switch statement
>resulted in o
89 matches
Mail list logo
