If MIPS MCU extension is enable, the IPL section in Cause and Status
registers has been expand to 8bit instead of 6bit.
In Cause: the bits are 10-17.
In Status: the bits are 10-16 and 18.
MD00834-2B-MUCON-AFP-01.03.pdf: P49 and P61.
gcc/ChangeLog:
* config/mips/mips.cc (mips_expand_prol
The size argument in strncmp only describe the maximum length to which
to compare two strings and is not an indication of sizes of the two
source strings. Do not warn if it is larger than the two input strings
because it is entirely likely that the size argument is a conservative
maximum to accomm
I forgot to CC the gcc-patches mailing list on the original patch submission.
Adding it in now. Sorry.
On 3/14/22 8:24 PM, Segher Boessenkool wrote:
>> gcc/
>> PR target/104923
>> * config/rs6000/predicates.md (mma_disassemble_output_operand):
>> Restrict acceptable MEM addresses.
>
On Tue, Mar 15, 2022 at 2:21 AM Mohamed Atef
wrote:
> Hi Jakub,
> i will fix all the issues and i will use the script on the website.
> On Mon, Mar 14, 2022 at 6:23 PM Jakub Jelinek wrote:
>
>> Hi!
>>
>> Sorry for the delay, GCC is currently in stage 4, which means a lot of us
>> concentrate on
On Mon, 2022-03-14 at 18:04 -0700, Andrew Pinski via Gcc-patches wrote:
> On Mon, Mar 14, 2022 at 5:33 PM Joern Rennecke
> wrote:
> >
> > Most microprocessors have efficient ways to perform CRC operations, be
> > that with lookup tables, rotates, or even special instructions.
> > However, because
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
Thanks
On 28/2/2022 上午 11:17, HAO CHEN GUI wrote:
> Hi,
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591507.html
Thanks
On 10/3/2022 下午 2:31, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into mode iterator used in vector comparison
> expands.With the patch, both built-ins and direct comparison could generat
On Mon, Mar 14, 2022 at 5:33 PM Joern Rennecke
wrote:
>
> Most microprocessors have efficient ways to perform CRC operations, be
> that with lookup tables, rotates, or even special instructions.
> However, because we lack a representation for CRC in the compiler, we
> can't do proper instruction s
Most microprocessors have efficient ways to perform CRC operations, be
that with lookup tables, rotates, or even special instructions.
However, because we lack a representation for CRC in the compiler, we
can't do proper instruction selection. With this patch I seek out to
rectify this,
I've avoid
Hi Jakub,
i will fix all the issues and i will use the script on the website.
On Mon, Mar 14, 2022 at 6:23 PM Jakub Jelinek wrote:
> Hi!
>
> Sorry for the delay, GCC is currently in stage 4, which means a lot of us
> concentrate on fixing GCC 12 so that it can be released soon and projects
> that
I noticed that when there are registers to save (that can vary with
ABI), shrink-wrapping would
arrange for a more expeditious early return than when there were no
registers to save,
but still some dull argument copies to make for the main function,
even if they are not
needed for the early return
On 3/12/22 14:22, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
On 3/14/22 13:13, Patrick Palka wrote:
On Fri, 11 Mar 2022, Jason Merrill wrote:
On 3/10/22 11:27, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a func
On 3/14/22 13:24, Patrick Palka wrote:
When a lookup is ambiguous, lookup_member still attempts to check
access of the first member found before diagnosing the ambiguity and
erroring out, which may cause us to issue an extraneous access error
in case of ambiguous lookup as in the testcase below (
On Mon, 14 Mar 2022 at 14:17, Patrick Palka via Libstdc++
wrote:
>
> On Fri, 11 Mar 2022, Jonathan Wakely wrote:
>
> > Patrick, I think this is right, but please take a look to double check.
> >
> > I think we should fix the feature-test macro conditions for gcc-11 too,
> > although it's a bit mor
I've been wondering about the possible performance/missed-optimization
impact of my patch for PR middle-end/98420 and similar IEEE correctness
fixes that disable constant folding optimizations when worrying about -0.0.
In the common situation where the floating point result is used by a
FP compari
Ping.
Summary: Currently, the macro guards for TARGET_CAN_SPLIT_STACK are not
aligned with the implementation of ix86_supports_split_stack on x86.
That is, on musl systems TARGET_CAN_SPLIT_STACK is defined even though
-fsplit-stack is not supported (via ix86_supports_split_stack). This
prevents gc
Hello,
this workarounds the regression I introduced with the fix for pr104228.
The problem comes from the evaluation of character length for the
associate target (y) in the testcase.
The expression is non-scalar which is not supported at that point, as no
scalarization setup is made there.
My
Use AC_CACHE_CHECK to store the result of the header check for
systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
AC_CACHE_CHECK(..., glibcxx_cv_sys_sdt_h).
gcc/
* configure.ac: Add AC_CACHE_CHECK(..., gcc_cv_sys_sdt_h).
* configure: Regenerate.
---
gcc/configure
When a lookup is ambiguous, lookup_member still attempts to check
access of the first member found before diagnosing the ambiguity and
erroring out, which may cause us to issue an extraneous access error
in case of ambiguous lookup as in the testcase below (for B1::foo).
This patch fixes this by s
Hi Jeff,
> What I find rather surprising is the location of your changes -- they feel
> incomplete. For example, you fix the callee side of returns in
> expand_value_return, but I don't analogous code for the caller side.
>
> Similarly while you fix things for arguments in expand_expr_real_1,
On Fri, 11 Mar 2022, Jason Merrill wrote:
> On 3/10/22 11:27, Patrick Palka wrote:
> > On Wed, 9 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/1/22 18:08, Patrick Palka wrote:
> > > > A well-formed call to std::move/forward is equivalent to a cast, but the
> > > > former being a function call mea
On Mon, 2022-03-14 at 16:04 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Now I think the only rational ways are:
> >
> > (1) allow zeroing more registers than need_zeroed_hardregs.
>
> I think this is the way to go. I agree it's a bit hacky, but it seems
> like the least worst opti
On Mon, 2022-03-14 at 16:18 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > * configure.tgt: Enable build on mips64.
I changed this to "mips*64*-*-linux*" to be more precise.
> OK, thanks.
>
> Richard
Two patches pushed as r12-7645 and r12-7646, with the minor changelog
modifi
Hi!
Sorry for the delay, GCC is currently in stage 4, which means a lot of us
concentrate on fixing GCC 12 so that it can be released soon and projects
that are clearly GCC 13 material are much lower priority.
On Wed, Feb 16, 2022 at 11:04:13PM +0200, Mohamed Atef via Gcc-patches wrote:
> --- a/l
Xi Ruoyao writes:
> Bootstrapped and regtested on mips64el-linux-gnuabi64.
>
> bootstrap-ubsan revealed 3 bugs (PR 104842, 104843, 104851).
> bootstrap-asan did not reveal any new bug.
>
> gcc/
>
> * config/mips/mips.h (SUBTARGET_SHADOW_OFFSET): Define.
> * config/mips/mips.cc (mips_op
Xi Ruoyao writes:
> libsanitizer/
>
> * sanitizer_common/sanitizer_atomic_clang.h: Ensures to only
> include sanitizer_atomic_clang_mips.h for O32.
OK, thanks.
Richard
> ---
> libsanitizer/sanitizer_common/sanitizer_atomic_clang.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 dele
Sorry for the slow response, was out for a few days.
Xi Ruoyao writes:
> On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
>> On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
>> > Hi, Ruoyao,
>> >
>> > (I might not be able to reply to this thread till next Wed due to a
>> >
Richard Biener writes:
> On Wed, Mar 9, 2022 at 7:04 PM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > On Wed, Mar 2, 2022 at 10:18 PM H.J. Lu wrote:
>> >>
>> >> On Wed, Mar 02, 2022 at 09:51:26AM +0100, Richard Biener wrote:
>> >> > On Tue, Mar 1, 2022 at 11:41 PM
Hi Tobias,
Minor remark to the test:
On 11.03.22 13:30, Marcel Vollweiler wrote:
+ int d = omp_get_default_device ();
...
+ int shared_mem = 0;
+ #pragma omp target map (alloc: shared_mem) device (d)
+shared_mem = 1;
+ if (omp_target_is_accessible (p, sizeof (int), d) != shared_mem)
"Roger Sayle" writes:
> Hi Richard,
>> Yes, which is why I think the target should claim argument passing happens
> in reg:HI.
>
> Unfortunately, this hits another "feature" of the nvptx backend; it's a
>
> /* Implement TARGET_MODES_TIEABLE_P. */
> bool nvptx_modes_tieable_p (machine_mode, machi
On 2/9/2022 1:12 PM, Roger Sayle wrote:
This patch adds middle-end support for target ABIs that pass/return
floating point values in integer registers with precision wider than
the original FP mode. An example, is the nvptx backend where 16-bit
HFmode registers are passed/returned as (promote
On 3/14/2022 2:39 AM, Roger Sayle wrote:
The only (other?) possible point of contention is the (arbitrary) decision that
when passing floating point values in a larger integer register, the code is
hardwired to use zero-extension. This in theory could be turned into a target
hook to support
On 3/14/2022 3:09 AM, Richard Biener wrote:
On Mon, 14 Mar 2022, Roger Sayle wrote:
I thought I'd add a few comments that might help reviewers of this patch.
Most importantly, this patch should be completely safe, as both changes
only trigger with FLOAT vs INT size mismatches which currently
On Mon, 14 Mar 2022, Roger Sayle wrote:
>
> Hi Richard,
> > Yes, which is why I think the target should claim argument passing happens
> in reg:HI.
>
> Unfortunately, this hits another "feature" of the nvptx backend; it's a
>
> /* Implement TARGET_MODES_TIEABLE_P. */
> bool nvptx_modes_tieabl
On Mon, Mar 14, 2022 at 7:03 AM Jakub Jelinek wrote:
>
> On Mon, Mar 14, 2022 at 06:49:01AM -0700, H.J. Lu via Gcc-patches wrote:
> > gcc/
> >
> > PR target/104890
> > * config/i386/i386.cc (ix86_can_inline_p): Ignore
> > OPTION_MASK_ISA_64BIT for -m32.
> >
> > gcc/testsuite/
> >
Push target("general-regs-only") in if x87 is enabled.
gcc/
PR target/104890
* config/i386/x86gprintrin.h: Also check _SOFT_FLOAT before
pushing target("general-regs-only").
gcc/testsuite/
PR target/104890
* gcc.target/i386/pr104890.c: New test.
---
gcc
Hi Richard,
> Yes, which is why I think the target should claim argument passing happens
in reg:HI.
Unfortunately, this hits another "feature" of the nvptx backend; it's a
/* Implement TARGET_MODES_TIEABLE_P. */
bool nvptx_modes_tieable_p (machine_mode, machine_mode) { return false; }
/* Impl
On Fri, 11 Mar 2022, Jonathan Wakely wrote:
> Patrick, I think this is right, but please take a look to double check.
>
> I think we should fix the feature-test macro conditions for gcc-11 too,
> although it's a bit more complicated there. It should depend on IEEE
> float and double *and* useloca
On Mon, Mar 14, 2022 at 09:26:57AM -0400, Marek Polacek via Gcc-patches wrote:
> Thanks for the patch.
>
> The new configure option needs documenting in doc/install.texi, and configure
> needs to be regenerated.
More importantly, I don't see explanation why the patch is needed, analysis
why did t
On Mon, Mar 14, 2022 at 06:49:01AM -0700, H.J. Lu via Gcc-patches wrote:
> gcc/
>
> PR target/104890
> * config/i386/i386.cc (ix86_can_inline_p): Ignore
> OPTION_MASK_ISA_64BIT for -m32.
>
> gcc/testsuite/
>
> PR target/104890
> * gcc.target/i386/pr104890.c: New tes
On Mon, Mar 14, 2022 at 6:49 AM H.J. Lu wrote:
>
> gcc/
>
> PR target/104890
> * config/i386/i386.cc (ix86_can_inline_p): Ignore
> OPTION_MASK_ISA_64BIT for -m32.
Please ignore this.
> gcc/testsuite/
>
> PR target/104890
> * gcc.target/i386/pr104890.c: New
gcc/
PR target/104890
* config/i386/i386.cc (ix86_can_inline_p): Ignore
OPTION_MASK_ISA_64BIT for -m32.
gcc/testsuite/
PR target/104890
* gcc.target/i386/pr104890.c: New test.
---
gcc/config/i386/i386.cc | 4
gcc/testsuite/gcc.targe
On 2022-03-12 14:37, Jakub Jelinek wrote:
Hi!
The following testcase ICEs on powerpc-linux, because lra_substitute_pseudo
substitutes (const_int 1) into a subreg operand. First a subreg of subreg
of a reg appears in a debug insn (which surely is invalid outside of
debug insns, but in debug in
On Mon, 14 Mar 2022, Roger Sayle wrote:
>
> Hi Richard,
>
> > The above seems backwards - it should be (subreg:HF (reg:SI 0)), no?
>
> Line 949 of emit-rtl.cc in the definition of "validate_subreg" contains:
>
> /* Subregs involving floating point modes are not allowed to
> change size.
On Mon, Mar 14, 2022 at 01:48:21PM +0100, David Seifert via Gcc-patches wrote:
> Bug: https://bugs.gentoo.org/654748
>
> gcc/configure.ac
> * Add --enable-systemtap switch to explicitly allow for
> disabling systemtap even if the target libc supports it.
> ---
> gcc/configure.ac |
Pushed to trunk now.
On 11/03/22 18:38 +, Jonathan Wakely wrote:
I'm going to push this as obvious, but do I need to do anything special
to sync it with binutils, or will that happen next time somebody needs a
proper fix?
-- >8 --
The custom option for enabling/disabling libstdc++ is not s
Tested powerpc64le-linux and sparc-sun-solaris2.11, pushed to trunk.
This should be backported too. It's not a regression, but this code is
just broken on 16-bit targets.
-- >8 --
The current code in read_utf8_code_point assumes that integer promotion
will create a 32-bit int, but that's not tru
Bug: https://bugs.gentoo.org/654748
gcc/configure.ac
* Add --enable-systemtap switch to explicitly allow for
disabling systemtap even if the target libc supports it.
---
gcc/configure.ac | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git
On Mon, Mar 14, 2022 at 8:20 PM Hongtao Liu wrote:
>
> On Mon, Mar 14, 2022 at 7:25 PM Jakub Jelinek wrote:
> >
> > On Sun, Mar 13, 2022 at 09:34:10PM +0800, Hongtao Liu wrote:
> > > LGTM, thanks for handling this.
> >
> > Thanks, committed.
> >
> > > > Note, while the Intrinsics guide for _mm_lo
On Mon, Mar 14, 2022 at 7:25 PM Jakub Jelinek wrote:
>
> On Sun, Mar 13, 2022 at 09:34:10PM +0800, Hongtao Liu wrote:
> > LGTM, thanks for handling this.
>
> Thanks, committed.
>
> > > Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
> > > for _mm_loadu_si16 it says strangely SSE. B
Hi Richard,
> The above seems backwards - it should be (subreg:HF (reg:SI 0)), no?
Line 949 of emit-rtl.cc in the definition of "validate_subreg" contains:
/* Subregs involving floating point modes are not allowed to
change size. Therefore (subreg:DI (reg:DF) 0) is fine, but
(subr
On Sun, Mar 13, 2022 at 09:34:10PM +0800, Hongtao Liu wrote:
> LGTM, thanks for handling this.
Thanks, committed.
> > Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
> > for _mm_loadu_si16 it says strangely SSE. But the intrinsics
> > returns __m128i, which is only defined in emmi
On Mon, Mar 14, 2022 at 9:03 AM Iain Sandoe wrote:
>
>
>
> > On 14 Mar 2022, at 07:45, Richard Biener wrote:
> >
> > On Mon, Mar 14, 2022 at 12:17 AM Iain Sandoe via Gcc-patches
> > wrote:
> >>
> >> Some versions of the BSD getaddrinfo() call do not work with the specific
> >> input of "0" for t
> Here is an updated patch for it. Ok for trunk?
>
> 2022-03-14 Jakub Jelinek
>
> PR rtl-optimization/104814
> * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb doesn't
> end with onlyjump_p. Assume BB_END (test_bb) is always non-NULL.
>
> * gcc.c-tortur
On Sun, Mar 13, 2022 at 02:43:18PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Are the !BB_END tests really necessary? cond_exec_process_if_block has the
> > same test on onlyjump_p without it. Likewise for noce_find_if_block.
>
> Probably not, I've put it there only because the neighboring
On Mon, 14 Mar 2022, Roger Sayle wrote:
>
> Hi Richard,
> Thanks for asking.
> The issue is with 16-bit floating point HFmode, where clang on nvptx passes
> HFmode
> values in SImode registers, and for binary compatibility GCC needs to do the
> same.
> Their motivation is that for compatibility w
On 3/11/22 20:24, Detlef Vollmann wrote:
On 3/11/22 18:59, Jonathan Wakely wrote:
Thanks. Now I'm getting a build failure because libtol wasn't created
in the avr/libstdc++-v3 directory of the build tree, but I'll have to
look into that next week.
/bin/sh: ../libtool: No such file or directory
Hi Richard,
Thanks for asking.
The issue is with 16-bit floating point HFmode, where clang on nvptx passes
HFmode
values in SImode registers, and for binary compatibility GCC needs to do the
same.
Their motivation is that for compatibility with older GPUs and the x86_64
host, HFmode
parameters ar
Hi!
This fixes typos and while changing that, also uses %< %> around attribute
names and fixes up formatting.
2022-03-14 Jakub Jelinek
PR other/104899
* config/bfin/bfin.cc (bfin_handle_longcall_attribute): Fix a typo
in diagnostic message - cannott -> cannot. Use %<
On Mon, 14 Mar 2022, Roger Sayle wrote:
>
> I thought I'd add a few comments that might help reviewers of this patch.
> Most importantly, this patch should be completely safe, as both changes
> only trigger with FLOAT vs INT size mismatches which currently both ICE in
> the compiler a few lines l
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html
R30_REGNUM could also be used as a component in shrink-wrapping
separate, this patch enables it in aarch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_get_separate_comp
I thought I'd add a few comments that might help reviewers of this patch.
Most importantly, this patch should be completely safe, as both changes
only trigger with FLOAT vs INT size mismatches which currently both ICE in
the compiler a few lines later. Admittedly, this indicates something odd
ab
On 3/2/22 20:18, Jeff Law via Gcc-patches wrote:
On 2/28/2022 5:54 AM, Richard Biener via Gcc-patches wrote:
On Mon, 28 Feb 2022, Tobias Burnus wrote:
Ping**3
On 23.02.22 09:42, Tobias Burnus wrote:
PING**2 for the ME review or at least comments to that patch,
which fixes a build issue/ICE
> On 14 Mar 2022, at 07:45, Richard Biener wrote:
>
> On Mon, Mar 14, 2022 at 12:17 AM Iain Sandoe via Gcc-patches
> wrote:
>>
>> Some versions of the BSD getaddrinfo() call do not work with the specific
>> input of "0" for the servname entry (a segv results). Since we are making
>> the cal
On Fri, Mar 11, 2022 at 5:31 PM Qing Zhao via Gcc-patches
wrote:
>
>
> Hi,
>
> I plan to backport the patch to fix PR100775:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
>
> To gcc11 since this is a general bug to -fzero-call-used-regs. And should be
> fixed in gcc11 as well.
>
> I have
On Mon, Mar 14, 2022 at 12:17 AM Iain Sandoe via Gcc-patches
wrote:
>
> Some versions of the BSD getaddrinfo() call do not work with the specific
> input of "0" for the servname entry (a segv results). Since we are making
> the call with a dummy port number, the value is actually not important, o
On Mon, Mar 14, 2022 at 12:16 AM Iain Sandoe via Gcc-patches
wrote:
>
> The getaddrinfo() call requires either a non-null name for the server or
> a port service / number. In the code that opens a connection we have
> been calling this with a dummy port number of "0". Unfortunately this
> trigge
On Sun, Mar 13, 2022 at 12:39 AM Marc Glisse via Gcc-patches
wrote:
>
> On Fri, 11 Mar 2022, Roger Sayle wrote:
>
> +(match vec_same_elem_p
> + CONSTRUCTOR@0
> + (if (uniform_vector_p (TREE_CODE (@0) == SSA_NAME
> +? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) :
> @0
69 matches
Mail list logo
