On Tue, Dec 21, 2021 at 6:22 AM Haochen Jiang wrote:
>
> Hi all,
>
> This patch adds missing BMI function _tzcnt_u16, _andn_u32, _andn_u64 to
> align with clang.
>
> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>
> BRs,
> Haochen
>
> gcc/ChangeLog:
>
> * config/i386/bmiintrin.h
Am Di., 21. Dez. 2021 um 07:08 Uhr schrieb François Dumont via
Libstdc++ :
>
> Hi
>
> Is there a chance for this patch to be integrated for next gcc
> release ?
>
> François
>
No counterargument for the acceptance, but: Shouldn't
__small_size_threshold() be a noexcept function?
- Daniel
The purpose of those define_insn_and_split:
1. Combine vpcmpuw and zero_extend into vpcmpuw.
2. Canonicalize vpcmpuw pattern so CSE can replace duplicate vpcmpuw to just
kmov
3. Use DImode as dest of zero_extend so cprop_hardreg can eliminate redundant
kmov.
It should partially fix the issue in
* Fāng-ruì Sòng:
>> I *think* you can get what you need via existing GLIBC_PRIVATE
>> interfaces. But in order to describe how to caox the data out of glibc,
>> I need to know what you need.
>
> Unfortunate no, not reliably. Currently _dl_get_tls_static_info
>
Hi
Is there a chance for this patch to be integrated for next gcc
release ?
François
On 23/09/21 6:36 am, François Dumont wrote:
Ping ?
On 16/08/21 9:03 pm, François Dumont wrote:
On 17/07/20 2:58 pm, Jonathan Wakely wrote:
On 17/11/19 22:31 +0100, François Dumont wrote:
This is
Hi all,
This patch adds missing BMI function _tzcnt_u16, _andn_u32, _andn_u64 to align
with clang.
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
BRs,
Haochen
gcc/ChangeLog:
* config/i386/bmiintrin.h (_tzcnt_u16): New define function.
(_andn_u32): Ditto.
(_andn_u64):
On 2021/12/20 15:29, Richard Biener wrote:
> On Wed, Dec 8, 2021 at 7:32 AM Xionghu Luo wrote:
>>
>>
>>
>> On 2021/12/7 20:17, Richard Biener wrote:
> + class loop *coldest_loop = coldest_outermost_loop[loop->num];
> + if (loop_depth (coldest_loop) < loop_depth (outermost_loop))
On 2021/12/13 16:57, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/12/9 07:47, Jeff Law wrote:
>>> diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
>>> index 3f6ad046623..33128061aab 100644
>>> --- a/gcc/tree-ssa-loop-split.c
>>> +++ b/gcc/tree-ssa-loop-split.c
>>>
>>> @@
On 2021/12/16 19:18, Jan Hubicka wrote:
>>>
>>>
>>> ./contrib/analyze_brprob.py ~/workspace/tests/spec2017/dump_file_all
>>> HEURISTICS BRANCHES (REL) BR. HITRATE
>>> HITRATE COVERAGE COVERAGE (REL) predict.def (REL) HOT
>>> branches (>10%)
On 2021/12/21 09:32, David Edelsohn wrote:
> Explicit clobbers like this help one side of the issue. For vscr, other
> than the sat bit there is only the nj bit, and we just ignore that :-)
>
>> This patch is okay. Thanks for updating the machine description and
>> for cleaning up the
On Mon, Nov 29, 2021 at 11:30 AM Florian Weimer wrote:
>
> * Fāng-ruì Sòng:
>
> > PING^3
>
> I think the core issue with this patch is like this:
>
> * I do not want to commit glibc to a public API that disallows future
> changes to the way we allocate static TLS. While static TLS objects
>
On 2021/12/21 10:19, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/12/21 09:32, David Edelsohn wrote:
>> On Mon, Dec 20, 2021 at 6:55 PM Segher Boessenkool
>> wrote:
>>>
>>> On Mon, Dec 20, 2021 at 11:45:45AM -0500, David Edelsohn wrote:
On Mon, Dec 20, 2021 at 3:24 AM Xionghu Luo
On 2021/12/21 09:32, David Edelsohn wrote:
> On Mon, Dec 20, 2021 at 6:55 PM Segher Boessenkool
> wrote:
>>
>> On Mon, Dec 20, 2021 at 11:45:45AM -0500, David Edelsohn wrote:
>>> On Mon, Dec 20, 2021 at 3:24 AM Xionghu Luo wrote:
These four UNSPECS seems could be replaced with native
On Mon, Dec 20, 2021 at 6:55 PM Segher Boessenkool
wrote:
>
> On Mon, Dec 20, 2021 at 11:45:45AM -0500, David Edelsohn wrote:
> > On Mon, Dec 20, 2021 at 3:24 AM Xionghu Luo wrote:
> > > These four UNSPECS seems could be replaced with native RTL, and why
> > > "(set (reg:SI VSCR_REGNO)
On Mon, Dec 20, 2021 at 11:45:45AM -0500, David Edelsohn wrote:
> On Mon, Dec 20, 2021 at 3:24 AM Xionghu Luo wrote:
> > These four UNSPECS seems could be replaced with native RTL, and why
> > "(set (reg:SI VSCR_REGNO) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))"
> > in the RTL pattern, per ISA
Hi!
On Mon, Dec 20, 2021 at 01:55:51PM +0800, HAO CHEN GUI wrote:
> * config/rs6000/rs6000-call.c
> (rs6000_expand_set_fpscr_rn_builtin): Not copy argument to a reg if
> it's a constant. The pattern for constant can be recognized now.
(Two spaces after full stop).
> +;; Return
On Sat, 27 Nov 2021 22:18:23 +
Daniil Stas wrote:
> This option is enabled by default when -Wformat option is enabled. A
> user can specify -Wno-format-int-precision to disable emitting
> warnings when passing an argument of an incompatible integer type to
> a 'd', 'i', 'b', 'B', 'o', 'u',
On Mon, Dec 20, 2021 at 12:38 PM Jakub Jelinek wrote:
>
> On Mon, Dec 20, 2021 at 11:44:08AM -0800, H.J. Lu wrote:
> > The problem is in
> >
> > (define_memory_constraint "TARGET_MEM_CONSTRAINT"
> > "Matches any valid memory."
> > (and (match_code "mem")
> >(match_test
Dear all,
we need to check the arguments of the elemental MASKL and MASKR
intrinsics also before simplifying.
Testcase by Gerhard. The fix is almost obvious, but I'm happy to
get feedback in case there is something I overlooked. (There is
already a check on scalar arguments to MASKL/MASKR,
Hello,
This change adjusts the processing of --sysroot to save the option in the
internal "switches" array, which lets self-specs test for it and provide a
default value possibly dependent on environment variables, as in
--with-specs=%{!-sysroot*:--sysroot=%:getenv("WIND_BASE" /target)}
This
Dear all,
again found by Gerhard: using a BOZ literal constant in situations
where an interoperable object is expected can lead to an ICE.
But obviously a BOZ in not interoperable.
Obvious patch, regtested on x86_64-pc-linux-gnu.
Will commit within 48h unless there are objections or better
Dear all,
we need to check that expressions in CASE selectors are scalar,
and reject them early if they aren't.
Testcase by Gerhard. The fix is obvious and sort of a follow-up
to the fix for PR103591.
Regtested on x86_64-pc-linux-gnu.
Will commit as obvious within 48h unless there are
> On 20/12/2021 16:41 Alex Xu (Hello71) wrote:
>
>
> Excerpts from ibuc...@gdcproject.org's message of December 20, 2021 8:56 am:
> >> On 20/12/2021 01:08 Alex Xu (Hello71) via Gcc-patches
> >> wrote:
> >>
> >>
> >> On musl, linking against libphobos fails because it requires ucontext
>
On Mon, Dec 20, 2021 at 03:21:04PM -0500, Jason Merrill via Gcc-patches wrote:
> > @@ -3215,6 +3215,14 @@ check_tokens (const token_t *tokens, unsigned ntoks,
> > plural = "s";
> > }
> > + /* As an exception, don't warn about "decl-specifier*" since
> > +
On Mon, Dec 20, 2021 at 11:44:08AM -0800, H.J. Lu wrote:
> The problem is in
>
> (define_memory_constraint "TARGET_MEM_CONSTRAINT"
> "Matches any valid memory."
> (and (match_code "mem")
>(match_test "memory_address_addr_space_p (GET_MODE (op), XEXP (op, 0),
>
On 12/17/21 17:59, Marek Polacek wrote:
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
every time I
The clever trick to duplicate the value of the input operand into itself
proved not so clever after all. The splitter should not clobber the input
operand in any case, since the register can hold the value outside the HImode
lowpart when accessed as subreg. Use the standard earlyclobber approach
On Thu, Nov 18, 2021 at 07:30:36PM +, Hafiz Abid Qadeer wrote:
> + if (gfc_match (" : ") != MATCH_YES)
> + {
> + /* If no ":" then there is no allocator, we backtrack
> + and read the variable list. */
> + gfc_free_expr
On Mon, Dec 20, 2021 at 6:53 AM Jakub Jelinek wrote:
>
> On Sun, Dec 19, 2021 at 12:06:30PM -0800, H.J. Lu via Gcc-patches wrote:
> > --- a/gcc/config/i386/predicates.md
> > +++ b/gcc/config/i386/predicates.md
> > @@ -1199,6 +1199,12 @@
> >(and (match_operand 0 "memory_operand")
> >
On 12/16/2021 12:56 PM, Martin Sebor via Gcc-patches wrote:
Enabling vectorization at -O2 caused quite a few tests for
warnings to start failing in GCC 12. These tests were xfailed
and bugs were opened to track the problems until they can be
fully analyzed and ultimately fixed before GCC 12
On 12/17/21 17:58, Marek Polacek wrote:
This fixes
gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str +
((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing]
4618 | unsigned char s[3] = { '\'', str[i], '\'' };
|
On 12/20/21 12:46, Patrick Palka wrote:
When instantiating a call to a member function of a class template, we
repeat the member function lookup in order to obtain the corresponding
partially instantiated functions. Within an incomplete-class context
however, we need to be more careful when
Hi,
This patch merges the D front-end with upstream dmd ad8412530, and the
run-time libraries with upstream druntime fd9a4544 and phobos 495e835c2.
D front-end changes:
- Import dmd v2.098.1
- Remove calling of _d_delstruct from code generator.
Druntime changes:
- Import druntime
Hi Martin,
> On 12/16/21 19:43, Joseph Myers wrote:
>> On Thu, 16 Dec 2021, Martin Liška wrote:
>>
>>> Hello.
>>>
>>> Oh, sorry, it was me and I forgot to send the patch to the mailing list.
>>> I've basically taken it as: https://github.com/gcc-mirror/gcc/pull/57.
>>>
>>> Should I revert the
On Mon, Dec 20, 2021 at 3:24 AM Xionghu Luo wrote:
>
> These four UNSPECS seems could be replaced with native RTL, and why
> "(set (reg:SI VSCR_REGNO) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))"
> in the RTL pattern, per ISA of VSCR bit 127(VECTOR Saturation, SAT):
>
> This bit is sticky;
> On 20 Dec 2021, at 17:31, Jeff Law wrote:
>
> Given how vxworks specific these fixinc bits are, I think they reasonably
> fall under maintainership of vxworks bits.
>
> So I think you can/should self-approve :-)
Thanks Jeff,
Rasmus has provided useful feedback on some of the
hunks and
On 12/17/2021 4:55 AM, Olivier Hainque via Gcc-patches wrote:
Hello,
The attached patch adjusts a very old fixincludes hack for
VxWorks, to expose a varargs function prototype for "mkdir"
instead of a varargs macro (!).
The function version is more amenable to calls from C++ like
Hi Rasmus,
> On 20 Dec 2021, at 12:40, Rasmus Villemoes wrote:
>
> On 10/12/2021 19.24, Olivier Hainque wrote:
>
>> For the toolchains we build, this is achieved with a few
>> configure options like:
>>
>> --with-sysroot
>> --with-build-sysroot=${WIND_BASE}/target
>
> So forward-porting
Updated version of patch following AArch64 review.
Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
Ok for master? and backport along with the first patch?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/102819
PR tree-optimization/103169
*
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, December 17, 2021 4:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex mul,
> fma
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, December 17, 2021 4:19 PM
> To: Tamar Christina via Gcc-patches
> Cc: Tamar Christina ; nd ;
> rguent...@suse.de
> Subject: Re: [1/3 PATCH]middle-end vect: Simplify and extend the complex
> numbers validation routines.
>
>
> On 20 Dec 2021, at 16:32, Jeff Law wrote:
>
>
>
> On 12/17/2021 4:21 AM, Olivier Hainque via Gcc-patches wrote:
>> Hello,
>>
>> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html
>>
>> please ?
>>
>> Thanks in advance!
> OK for the trunk.
> Sorry it got
This patch is submitted now for review and so I can commit a backport it
to the OG11 branch, but isn't suitable for mainline until stage 1.
The patch implements support for omp_low_lat_mem_space and
omp_low_lat_mem_alloc on NVPTX offload devices. The omp_pteam_mem_alloc,
omp_cgroup_mem_alloc
On Mon, Dec 20, 2021 at 12:56 AM HAO CHEN GUI wrote:
>
> Hi,
> I modified the patch according to David and Segher's advice.
>
> This patch defines a pattern for mffscrni. If the RN is a constant, it can
> call
> gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype
>
Excerpts from ibuc...@gdcproject.org's message of December 20, 2021 8:56 am:
>> On 20/12/2021 01:08 Alex Xu (Hello71) via Gcc-patches
>> wrote:
>>
>>
>> On musl, linking against libphobos fails because it requires ucontext
>> but is not explicitly linked against it. This is caused by
On 12/17/2021 4:21 AM, Olivier Hainque via Gcc-patches wrote:
Hello,
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html
please ?
Thanks in advance!
OK for the trunk. Sorry it got lost.
jeff
On 12/17/2021 3:59 PM, Marek Polacek via Gcc-patches wrote:
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead
On 12/18/2021 11:01 AM, Joel Sherrill wrote:
On Sat, Dec 18, 2021 at 10:13 AM Joel Sherrill wrote:
On Fri, Dec 17, 2021, 9:57 PM Jeff Law wrote:
On 12/17/2021 9:10 AM, Joel Sherrill wrote:
---
gcc/config.gcc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config.gcc
Hi all,
This patch removes the "sorry" message for the OpenMP "requires
dynamic_allocators" feature in C, C++ and Fortran.
The clause is supposed to state that the user code will not work without
the omp_alloc/omp_free and omp_init_allocator/omp_destroy_allocator and
these things *are*
On Sun, Dec 19, 2021 at 12:06:30PM -0800, H.J. Lu via Gcc-patches wrote:
> --- a/gcc/config/i386/predicates.md
> +++ b/gcc/config/i386/predicates.md
> @@ -1199,6 +1199,12 @@
>(and (match_operand 0 "memory_operand")
> (not (match_test "x86_extended_reg_mentioned_p (op)"
>
> +;;
On Mon, 2021-12-20 at 15:35 +0800, Xi Ruoyao via Gcc-patches wrote:
> Hi,
>
> I've bootstraped the patch with my GNU-stack fix
> (https://github.com/loongson/gcc/pull/62) and --enable-werror-always.
> Bootstrap succeeded, but with some warnings:
>
>
> On 20/12/2021 01:08 Alex Xu (Hello71) via Gcc-patches
> wrote:
>
>
> On musl, linking against libphobos fails because it requires ucontext
> but is not explicitly linked against it. This is caused by configure
> assuming that it is implemented in assembly, but it is actually not
>
On Fri, 17 Dec 2021, Joel Sherrill wrote:
> +
> +
> +The m32c*-*-rtems* configuration has been obsoleted and will
> +be removed in a future release.
Aye. Thank you!
Gerald
On Sat, 18 Dec 2021, Joel Sherrill wrote:
> Can I commit the gcc and wwwdocs patch for m32c-rtems and let Jeff or
> someone follow up completely eliminating m32c?
Sure from my side (wwwdocs, and you probably could declare the removal
as "obvious" and/or approved by Jeff).
Gerald
Alex Coplan via Gcc-patches writes:
> Hi,
>
> This fixes PR103500 i.e. ensuring that stack slots for
> passed-by-reference overaligned types are appropriately aligned. For the
> testcase:
>
> typedef struct __attribute__((aligned(32))) {
> long x,y;
> } S;
> S x;
> void f(S);
> void g(void) {
On Mon, Dec 20, 2021 at 12:26 PM Roger Sayle wrote:
>
>
> Hi Uros,
> Many thanks for the review. Here's a revised patch incorporating your
> suggestion to use a single define_insn with a mode iterator instead of two
> new near identical define_insns for SImode and DImode. I initially tried
>
On Fri, 2021-12-10 at 15:43 +0800, Chenghua Xu wrote:
> +
> +INT_MODE (OI, 32);
> +
> +/* Keep the OI modes from confusing the compiler into thinking
> + that these modes could actually be used for computation. They are
> + only holders for vectors during data movement. */
> +#define
Hi FX,
I’m not opposed, but I’d really like to get this into the current branch. It is
a much less invasive change than the power-ieee128 work. The only case I
changed is the case where there is a kind 16, and there is a long double, but
the long double is neither kind 10 neither kind 16.
Apologies for the delay, the email fell through the cracks somehow.
The updated patch looks like it would work alright, only needs a couple tests,
e.g.:
https://github.com/rust-lang/rustc-demangle/blob/2811a1ad6f7c8bead2ef3671e4fdc10de1553e96/src/lib.rs#L413-L422
Thanks for a DWARF-related patch review (+ fix by yourself). Otherwise,
still pending are the following OpenMP patches.
The first one is a revised patch following the review comment and
affects Fortran only. The second one is also a rather small &
post-review revised patch.
On 06.12.21 15:56,
On 10/12/2021 19.24, Olivier Hainque wrote:
> For the toolchains we build, this is achieved with a few
> configure options like:
>
> --with-sysroot
> --with-build-sysroot=${WIND_BASE}/target
So forward-porting our private patches up until
7bf710b5116 - libstdc++: Add support for '?' in
Pushed as obvious.
Martin
gcc/jit/libgccjit.c:3957:8: warning: type 'struct version_info' violates the
C++ One Definition Rule [-Wodr]
../../gcc/jit/libgccjit.c:3957:8: warning: type 'struct version_info' violates
the C++ One Definition Rule [-Wodr]
3957 | struct version_info
Pushed as obvious after testing.
Cheers,
Martin
gcc/ChangeLog:
* opts.c (default_options_optimization): Support -Oz in -Ox option
hints.
---
gcc/opts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/opts.c b/gcc/opts.c
index f45ecc56726..cdd6463e49b 100644
Hi Uros,
Many thanks for the review. Here's a revised patch incorporating your
suggestion to use a single define_insn with a mode iterator instead of two
new near identical define_insns for SImode and DImode. I initially tried
SWI48, but a testsuite failure of pr82418.c revealed that it's more
Gentile ping for this :), thanks.
Link: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586204.html
Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].
To enable SCS in user mode, in addition to compiler,
These four UNSPECS seems could be replaced with native RTL, and why
"(set (reg:SI VSCR_REGNO) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))"
in the RTL pattern, per ISA of VSCR bit 127(VECTOR Saturation, SAT):
This bit is sticky; that is, once set to 1 it
remains set to 1 until it is set to 0
On Wed, Dec 15, 2021 at 3:50 PM Jakub Jelinek wrote:
>
> On Mon, Nov 29, 2021 at 05:25:30AM -0700, H.J. Lu wrote:
> > > I'd like to ping this patch, but perhaps first it would be nice to discuss
> > > it in the x86-64 psABI group.
> > > The current psABI doesn't seem to mention zero sized
On Sun, Dec 19, 2021 at 9:06 PM H.J. Lu wrote:
>
> x86_64_general_operand is different from general_operand for 64-bit
> target. To avoid LRA selecting a memory operand which doesn't satisfy
> x86_64_general_operand for 64-bit target:
>
> 1. Add a 'BM' constraint which is similar to the 'm'
68 matches
Mail list logo
