[PATCH] Fix PR 62157: disclean in libsanitizer not working

/Makefile.am +++ b/libsanitizer/Makefile.am @@ -28,6 +28,9 @@ SUBDIRS += hwasan endif endif +## Force DIST_SUBDIRS so that make distclean works +DIST_SUBDIRS = $(SUBDIRS) + ## May be used by toolexeclibdir. gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) diff --git a

[PATCH] Fix PR 19089: Environment variable TMP may yield gcc: abort

From: Andrew Pinski Even though I cannot reproduce the ICE any more, this is still a bug. We check already to see if we can access the directory but never check to see if the path is actually a directory. This adds the check and now we reject the file as not usable as a tmp directory. OK? Boots

[PATCH] tree-optimization: [PR101540] Simplify CONSTRUCTOR for vector(1) to be VCE

tree-optimization/101540 gcc/ChangeLog: * tree-ssa-forwprop.c (simplify_vector_constructor): Simplify constructor of vector of 1 element to just be a VIEW_CONVERT_EXPR. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr101540-1.c: New test. --- gcc/testsuite/gcc.dg/tree

[PATCH] Fix regression introduced by r12-5536.

_attr for those alternatives. Also this patch fixs a typo and some latent bugs which are related to moving HImode from/to sse register w/o TARGET_AVX512FP16. For optimization issues discussed in PR102811, I'll create another patch for it. [1] https://gcc.gnu.org/pipermail/gcc-regression/2021-

Re: [PATCH] rs6000/test: Add emulated gather test case

on 2021/11/27 上午12:24, Segher Boessenkool wrote: > Hi! > > On Thu, Nov 25, 2021 at 11:20:57AM +0800, Kewen.Lin wrote: >> This patch is to add a test case similar to the one in i386 >> to add testing coverage for 510.parest_r hotspots. > >> gcc/testsuite/ChangeLog

[PATCH] Optimize _Float16 usage for non AVX512FP16.

so that redundant initialization cound be eliminated. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} and x86_64-pc-linux-gnu{-m32\ -march=cadcadelake,\ -march=cascadelake} Ok for trunk? gcc/ChangeLog: PR target/102811 * config/i386/i386.c (inline_secondary_memory_needed

Re: [PATCH] rs6000: Remove builtin mask check from builtin_decl [PR102347]

Hi Segher, on 2021/11/30 上午8:16, Segher Boessenkool wrote: > Hi! > > On Tue, Sep 28, 2021 at 04:13:40PM +0800, Kewen.Lin wrote: >> PR target/102347 >> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin >> mask check. > > (Don't wrap lines early please). > Fixed.

Re: [PATCH v2] rs6000: Modify the way for extra penalized cost

Hi Segher, on 2021/11/30 上午6:06, Segher Boessenkool wrote: > Hi! > > On Tue, Sep 28, 2021 at 04:16:04PM +0800, Kewen.Lin wrote: >> This patch follows the discussions here[1][2], where Segher >> pointed out the existing way to guard the extra penalized >> cost for strided/elementwise loads with a

Re: [PATCH v2] combine: Tweak the condition of last_set invalidation

Hi Segher, Thanks for the review! on 2021/11/30 上午6:28, Segher Boessenkool wrote: > Hi! > > On Fri, Jun 11, 2021 at 09:16:21PM +0800, Kewen.Lin wrote: +/* Should pick up the lowest luid if the references + are in the same block. */ +if (label_tick == rsp

[PATCH] [i386] Fix ICE in ix86_attr_length_immediate_default.

. Explicitly set_attr length_immediate for these patterns. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/103463 PR target/103484 * config/i386/i386.md (*x86_64_shld_1): Set_attr length_immediate to 1. (*x86_shld_1

[r12-5612 Regression] FAIL: gcc.target/i386/pr88531-1a.c (test for excess errors) on Linux/x86_64

compiler error) FAIL: gcc.target/i386/pr88531-1a.c (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-5612/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages

[r12-5612 Regression] FAIL: gcc.target/i386/pr88531-1a.c (test for excess errors) on Linux/x86_64

l compiler error) FAIL: libgomp.fortran/examples-4/simd-2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/examples-4/simd-2.f90 -Os (internal compiler error) FAIL: libgomp.fortran/examples-4/simd-2.f90 -Os (test for excess errors) with GCC configured with ../../gcc/configure --pre

Re: [PATCH] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

Hi Haochen, on 2021/12/1 下午5:01, HAO CHEN GUI via Gcc-patches wrote: > Hi, > This patch modifies the combine pattern with a helper - > change_pseudo_and_mask when recog fails. > The helper converts a single pseudo to the pseudo AND with a mask if the > outer operator is IOR/XOR

[PATCH] [i386] Prefer INT_SSE_REGS for SSE_FLOAT_MODE_P in preferred_reload_class.

-linux-gnu{-m32,} and x86_64-pc-linux-gnu{-m32\ march=cascadelake,\ -march=cadcadelake}. No big performace impact is abserved for SPEC2017 on ICX/CLX with both Ofast -march=native -flto -funroll-loops and -O2 -mtune=generic options. Ok for trunk? gcc/ChangeLog: PR target/95740

Re: [PATCH] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

Hi Mike, on 2021/12/3 上午8:51, Michael Meissner wrote: > On Mon, Nov 29, 2021 at 10:57:12AM -0600, Segher Boessenkool wrote: >> Why are there OPTION_MASKs for separate P10 fusion types here, as well as >> MASK_P10_FUSION? > > Well going back in time, before we used rs6000_isa_flags, we used the de

[PATCH v2] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

‘__builtin_ttest’ requires the ‘-mhtm’ option 3 | *b += __builtin_ttest(); | ^ Since bar doesn't support foo's required HTM feature. With this fix, bar doesn't inline foo and the case gets compiled well. I've added this test case as pr102059-5.c. [1] https:/

[PATCH] [i386] Prefer INT_SSE_REGS for SSE_FLOAT_MODE_P in preferred_reload_class.

Hi: > Please also consider TARGET_INTER_UNIT_MOVES_TO_VEC and > TARGET_INTER_UNIT_MOVES_FROM_VEC. Here's updated patch. Also honor TARGET_INTER_UNIT_MOVES_TO/FROM_VEC and in preferred_{,out_}reload_class. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32\ -march=k8,\ -march=k8

[PATCH] [Committed] New testcase for C++/71792, bitfields and auto

From: Andrew Pinski This testcase used to fail before GCC 6.4.0 due to the wrong type being used for auto when used with bitfields, the C++ front-end was using the "bitfield" type rather than the underlaying type. Committed the testcase after a quick check. PR c++/71792 gcc

[PATCH] [i386] Prefer INT_SSE_REGS for SSE_FLOAT_MODE_P in preferred_reload_class.

When moves between integer and sse registers are cheap. 2021-12-06 Hongtao Liu Uroš Bizjak gcc/ChangeLog: PR target/95740 * config/i386/i386.c (ix86_preferred_reload_class): Allow integer regs when moves between register units are cheap. * config

[patch, Fortran] IEEE support for aarch64-apple-darwin

Homebrew). It was authored more than a year ago, but I figured it wasn’t relevant to submit until the target was actually close to be in trunk: https://github.com/iains/gcc-darwin-arm64/commit/b107973550d3d9a9ce9acc751adbbe2171d13736 Bootstrapped and tested on aarch64-apple-darwin20 (macOS Big Sur) and

[PATCH] pragma: Update target option node when optimization changes [PR103515]

ux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it ok for trunk? BR, Kewen --- gcc/ChangeLog: PR target/103515 * attribs.c (decl_attributes): Check if target options change and create one node if so. gcc/testsuite/ChangeLog: PR target/103515 * gcc.

Re: [PATCH v2] rs6000: Fix some issues in rs6000_can_inline_p [PR102059]

optimization. */ | OPTION_MASK_SAVE_TOC_INDIRECT | OPTION_MASK_PCREL_OPT; >>> Why are there OPTION_MASKs for separate P10 fusion types here, as well as >>> MASK_P10_FUSION? >> >> Mike helped to explain the history, I've updated all of them using >>

[patch, Fortran] Make REAL(KIND=16) detection more robust

Hi, Right now, the logic in libgfortran for the detection of REAL(KIND=16) is in kinds-override.h: /* What are the C types corresponding to the real(kind=10) and real(kind=16) types? We currently rely on the following assumptions: -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is d

[PATCH] Fix C++/93809 and C++/83469: typenames and unions

union key, right now we just record it was a struct/class/typename one which is wrong. OK? Boostrapped and tested on x86_64-linux-gnu with no regressions. PR c++/83469 PR c++/93809 gcc/cp/ChangeLog: * cp-tree.h (UNION_CLASS_TYPE_P): New define. (TYPENAME_IS_UNION_P

[r12-5823 Regression] FAIL: g++.dg/cpp0x/decltype-bitfield1.C -std=c++2a (test for excess errors) on Linux/x86_64

=c++14 (test for excess errors) FAIL: g++.dg/cpp0x/decltype-bitfield1.C -std=c++17 (test for excess errors) FAIL: g++.dg/cpp0x/decltype-bitfield1.C -std=c++2a (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

Hi Richard, > This isn't a full review, but I do have a question: is this really specific > to Darwin? or is it really generic aarch64 code? If the former, then the > file name is not right and it should reflect the darwin-specific nature of > the contents. If the latter, then I wonder why m

[r12-5835 Regression] FAIL: libgomp.c++/target-this-4.C execution test on Linux/x86_64

execution test FAIL: libgomp.c++/target-this-3.C execution test FAIL: libgomp.c++/target-this-4.C execution test with GCC configured with ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-5835/usr --enable-clocale=gnu --with-system-zlib --with-demangler

[r12-5832 Regression] FAIL: g++.target/i386/pr100738-1.C -std=gnu++98 scan-assembler-times vblendvps[ \\t] 2 on Linux/x86_64

/i386/pr100738-1.C -std=gnu++98 scan-assembler-times vblendvps[ \\t] 2 with GCC configured with ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-5832/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable

[r12-5874 Regression] FAIL: g++.dg/warn/string1.C (test for warnings, line 17) on Linux/x86_64

/warn/string1.C(test for warnings, line 17) with GCC configured with ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-5874/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable

Re: [PATCH] pragma: Update target option node when optimization changes [PR103515]

on 2021/12/9 上午9:43, Jeff Law wrote: > > > On 12/6/2021 7:15 PM, Kewen.Lin via Gcc-patches wrote: >> Hi, >> >> For a function with optimize pragma, it's possible that the target >> options change as optimization options change.  Now we create one >>

Re: [PATCH] pragma: Update target option node when optimization changes [PR103515]

the hook think we don't need to switch.  With this patch, >> there is no unrolling for foo1, which is also consistent with the >> behavior by replacing pragma by attribute whether w/ and w/o this >> patch. >> >> Bootstrapped and regtested on x86_64-redhat-linux, aarch64

Re: [PATCH V4] rs6000: cannot_force_const_mem for HIGH code rtx[PR106460]

Hi Jeff, on 2022/10/12 14:48, Jiufu Guo via Gcc-patches wrote: > Hi, > > As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried > to store into constant pool and ICE occur. But actually, this rtx represents > partial incomplete addres

[r13-3219 Regression] FAIL: gcc.target/i386/pr92658-sse4.c scan-assembler-times pmovzxwq 2 on Linux/x86_64

-sse4.c scan-assembler-times pmovzxdq 2 FAIL: gcc.target/i386/pr92658-sse4.c scan-assembler-times pmovzxwd 2 FAIL: gcc.target/i386/pr92658-sse4.c scan-assembler-times pmovzxwq 2 with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3219/usr

Re: [PATCH v2] rs6000: Rework option -mpowerpc64 handling [PR106680]

and not to warn. >>> As Segher's latest comment, I decide not to warn them and >>> keep it consistent with before. >>> >>> Bootstrapped and regress-tested on: >>> - powerpc64-linux-gnu P7 and P8 {-m64,-m32} >>> - powerpc64le-linux-gnu P9

Re: [PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option. (1/2)

; These are based on and inspired by PR 101865, which > reports that _ARCH_PWR8 is disabled when -mno-vsx > is passed on the commandline. > > There are a small number of failures introduced by these tests, > those are resolved with the changes in part 2. > > OK for t

Re: [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865] (2/2)

ince we don't have a separated option for it now, and if users want to check the availability, they can check __VSX__ && _ARCH_PWR8 instead. > > This regests cleanly (power8,power9,power10), and resolves > PR 101865 as represented in the tests from (1/2). > > OK

[r13-3327 Regression] FAIL: libgomp.c++/loop-14.C (test for excess errors) on Linux/x86_64

error: in as_a, at is-a.h:242) FAIL: libgomp.c++/loop-13.C (test for excess errors) FAIL: libgomp.c++/loop-14.C (internal compiler error: in as_a, at is-a.h:242) FAIL: libgomp.c++/loop-14.C (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc

[PATCH] Canonicalize vec_perm index to make the first index come from the first vector.

Fix unexpected non-canon form from gimple vector selector. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/107271 * config/i386/i386-expand.cc (ix86_vec_perm_index_canon): New. (expand_vec_perm_shufps_shufps): Call

Re: [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865] (2/2)

Hi! on 2022/10/19 00:52, Segher Boessenkool wrote: > Hi! > > On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote: >> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote: >>> It did not happen in GCC 9 obviously. Do you want to take a >>> shot?

[PATCH] vect: Try folding first for shifted value generation [PR107240]

ft is gone, otherwise it's the same as before. It can help to make the failures of vect-bitfield-write-{2,3}.c gone on Power. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it ok for trunk? BR, Kewen - PR tree-optimization/107240

[PATCH] rs6000/test: Support vect_long_long effective target

ds some testing coverage. I'm going to push this soon if no objections. BR, Kewen - gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_vect_long_long): Add support for powerpc*-*-*. --- gcc/testsuite/lib/target-supports.exp | 5 - 1 file changed

Re: [PATCH] vect: Try folding first for shifted value generation [PR107240]

f vect-bitfield-write-{2,3}.c >> gone on Power. >> >> Bootstrapped and regtested on x86_64-redhat-linux, >> aarch64-linux-gnu and powerpc64{,le}-linux-gnu. >> >> Is it ok for trunk? >> >> BR, >> Kewen >> - >> PR t

[r13-3356 Regression] FAIL: libgomp.c++/loop-14.C (internal compiler error: verify_ssa failed) on Linux/x86_64

for excess errors) with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3356/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx

[r13-3360 Regression] FAIL: gcc.dg/c2x-enum-1.c (test for excess errors) on Linux/x86_64

) with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3360/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux

Re: [PATCH v3, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

> > Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. > Is this okay for trunk? Any recommendations? Thanks a lot. > > ChangeLog > 2022-09-07 Haochen Gui > > gcc/ > * config/rs6000/rs6000-builtins.def > (__builtin_vsx_scalar

Re: [PATCH] rs6000: using li/lis+oris/xoris to build constants

Hi Jeff, Sorry for late review, some comments are inline. on 2022/8/24 16:13, Jiufu Guo via Gcc-patches wrote: > Hi, > > PR106708 constaint some constants which can be support by li/lis + oris/xoris. > > For constant C: > if ((c & 0x80008000ULL) == 0x8000UL

Re: [PATCH] mips: Add appropriate linker flags when compiling with -static-pie

On Wed, Oct 12, 2022 at 2:18 PM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > On 9/25/22 09:49, linted via Gcc-patches wrote: > > Hello, > > I'm just checking to see if anyone has had a chance to look at this. > > > > Thank you >

Re: Adding a new thread model to GCC

On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one of them for GCC 13, but I don't know Windows well enough to determine which

Re: Adding a new thread model to GCC

On 2022-10-21 10:48, Jonathan Wakely wrote: On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++ wrote: On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: > How does this compare with Eric B's proposal at > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.ht

Re: Adding a new thread model to GCC

On 2022-10-21 11:36, LIU Hao wrote: 在 2022/10/21 18:09, i.nix...@autistici.org 写道: On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accep

Re: Adding a new thread model to GCC

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? My proposal was to reimplement (and extend) the native thread model (win32) instead of adding a new one, the adva

Re: Adding a new thread model to GCC

On 2022-10-21 12:19, LIU Hao wrote: 在 2022/10/21 19:54, i.nix...@autistici.org 写道: Jacek Caban, who is also a mingw-w64 developer, expressed the same idea a few days ago. While integrating mcfgthread into gcc is practically possible, my concerns are: * GCC never provides a threading

Re: Adding a new thread model to GCC

On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches wrote: > > On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: > >>>/How does this compare with Eric B's proposal at > >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg0

Re: [PATCH] d: Remove D-specific version definitions from target headers

> On 17/10/2022 20:08 CEST Iain Buclaw wrote: > > > Hi, > > This splits up the targetdm sources so that each file only handles one > target platform. > > Having all logic kept in the headers means that they could become out of > sync when a new target is added (loongarch*-*-linux*) or acciden

Re: Adding a new thread model to GCC

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? My proposal was to reimplement (and extend) the native thread model (win32) instead of adding a new one, the adva

Re: Adding a new thread model to GCC

On 2022-10-24 08:15, Eric Botcazou wrote: could you please refresh/recheck your patch for the current gcc master and solve the objections noted in the thread? is it possible? Hi, I can do the former, but not the latter as my development setup (mostly testing) on Windows has nearly

vect: Fix wrong shift_n after widening on BE [PR107338]

for trunk? BR, Kewen - PR tree-optimization/107338 gcc/ChangeLog: * tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern): Move shfit_n calculation before the adjustments for widening loads. --- gcc/tree-vect-patterns.cc | 17 +++-- 1 file changed, 11 i

[r13-3463 Regression] FAIL: gcc.target/i386/builtin_target.c (test for excess errors) on Linux/x86_64

errors) with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3463/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux

Re: vect: Fix wrong shift_n after widening on BE [PR107338]

on 2022/10/24 20:55, Richard Biener wrote: > On Mon, Oct 24, 2022 at 12:43 PM Kewen.Lin wrote: >> >> Hi, >> >> As PR107338 shows, with the use of widening loads, the >> container_type can become a wider type, it causes us to >> get wrong shift_n since the BIT_FIELD_REF offset actually >> becomes b

[r13-3476 Regression] FAIL: gcc.dg/vect/pr100756.c scan-tree-dump-not vect "epilog loop required" on Linux/x86_64

-ffat-lto-objects scan-tree-dump-not vect "epilog loop required" FAIL: gcc.dg/vect/pr100756.c scan-tree-dump-not vect "epilog loop required" with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3476/usr --enable-cloca

[PATCH] [x86] Enable V4BFmode and V2BFmode.

ed on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/107261 * config/i386/i386-modes.def (VECTOR_MODE): Support V2BFmode. * config/i386/i386.cc (classify_argument): Handle V4BFmode and V2BFmode. (ix86_convert_const_vector_to_integer):

Re: [PATCH] testsuite: Fix failure in test pr105586.c [PR107171]

Hi Surya, on 2022/10/14 01:02, Surya Kumari Jangala via Gcc-patches wrote: > testsuite: Fix failure in test pr105586.c [PR107171] > > The test pr105586.c fails on a big endian system when run in 32bit > mode. The failure occurs as the test case does not guard against > unsup

[PATCH] testsuite: Adjust vect-bitfield-read-* with vect_shift and vect_long_long [PR107240]

for them. This patch can help to fix remaining vect-bitfield-* test failures on powerpc. Tested on powerpc64-linux-gnu P7 and P8, as well as powerpc64le-linux-gnu P9 and P10. Is it ok for trunk? BR, Kewen - PR testsuite/107240 gcc/testsuite/ChangeLog: * gcc.dg/vect/vect

[PATCH] [x86] Fix incorrect digit constraint

operands in the pattern are both input operands. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/107057 * config/i386/sse.md (*vec_interleave_highv2df): Remove constraint 1. (*vec_interleave_lowv2df): Ditto

[PATCH] Use simple_dce_from_worklist with match_simplify_replacement.

gcc/ChangeLog: * tree-ssa-phiopt.cc: Include tree-ssa-dce.h (replace_phi_edge_with_variable): New argument, dce_ssa_names. Call simple_dce_from_worklist. (match_simplify_replacement): If we inserted a sequence, mark the lhs of the new sequence to be possible

[r13-3540 Regression] FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 1 on Linux/x86_64

b-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "loop vectorized" 1 FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 1 with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-

[PATCH V2] [x86] Fix incorrect digit constraint

rands in the pattern are both input operands. gcc/ChangeLog: PR target/107057 * config/i386/sse.md (*vec_interleave_highv2df): Remove constraint 1. (*vec_interleave_lowv2df): Ditto. (vec_concatv2df): Ditto. (*avx512f_unpcklpd512): Ditto an

[PATCH] Enable more optimization for 32-bit/64-bit shrd/shld with imm shift count.

-m32,}. Ok for trunk? gcc/ChangeLog: PR target/55583 * config/i386/i386.md (*x86_64_shld_1): Rename to .. (x86_64_shld_1): .. this. (*x86_shld_1): Rename to .. (x86_shld_1): .. this. (*x86_64_shrd_1): Rename to .. (x86_64_shrd_1): .. this.

Re: Adding a new thread model to GCC

the original patch at: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html This reimplements the GNU threads library on native Windows (except for the Objective-C specific subset) using direct Win32 API calls, in lieu of the implementation based on semaphores. This base

Re: [PATCH] Add __builtin_iseqsig()

all for GCC 13. FX

[r13-3570 Regression] FAIL: g++.dg/other/pr39060.C -std=c++98 (test for excess errors) on Linux/x86_64

/other/pr39060.C -std=c++98 (internal compiler error: canonical types differ for identical types 'void (A::)(void*)' and 'void (A::)(void*)') FAIL: g++.dg/other/pr39060.C -std=c++98 (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/export/us

Re: Adding a new thread model to GCC

On 2022-10-31 09:18, Eric Botcazou wrote: hello Eric! This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when the switch --enable-libstdcxx-threads is passed, which means that C++11 threads are still disabled by default *unless* MinGW-W64 itself is configured for Windows Vista

[r13-3596 Regression] FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 x == 10 - i on Linux/x86_64

-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 x == 10 - i with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3596/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c

[PATCH] vect: Fold LEN_{LOAD,STORE} if it's for the whole vector [PR107412]

-optimization/107412 gcc/ChangeLog: * gimple-fold.cc (gimple_fold_mask_load_store_mem_ref): Rename to ... (gimple_fold_partial_load_store_mem_ref): ... this, add one parameter mask_p indicating it's for mask or length, and add some handlings for IFN LEN_{LOAD,

[PATCH] testsuite: Fix gen-vect-34.c with vect_masked_load [PR106806]

hines with default AVX support, or if we adjust the current check_avx_available with current_compiler_flags. Is it ok for trunk? BR, Kewen - PR testsuite/106806 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/gen-vect-34.c: Adjust with vect_masked_load effective target

Re: Adding a new thread model to GCC

hi Eric, Jonathan, I was able to successfully build gcc-trunk using the provided patch. moreover, I was able to successfully build all of the packages used in the toolchain! (gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses, readline, gdbm, tcl, tk, openssl, xz-utils

Re: Adding a new thread model to GCC

On 2022-11-02 21:27, Eric Botcazou wrote: Great! Did you check that C++ threads are enabled in your build? If they are, you must be able to run the attached C++ test; if they are not (because the MinGW64 build is configured for older versions of Windows), you need to configure the compiler

[PATCH 1/2] Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector types

x86_64-linux-gnu with no regressions gcc/ChangeLog: PR tree-optimization/105532 * match.pd (~(X >> Y) -> ~X >> Y): Check if it is an integral type before calling tree_nonzero_bits. (popcount(X) + popcount(Y)): Likewise. (popcount(X&C

[PATCH 0/2] tree_nonzero_bits vs vector and complex types

ks, Andrew Pinski Andrew Pinski (2): Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector types Add assert for type on tree_nonzero_bits gcc/fold-const.cc | 3 +++ gcc/match.pd | 25 +++ .../gcc

[PATCH 2/2] Add assert for type on tree_nonzero_bits

From: Andrew Pinski Right now anyone could call tree_nonzero_bits with either complex or vector types and this will return the wrong thing. So just assert that nobody calls it with this. OK? Bootstrapped and tested with no regressions on x86_64-linux-gnu. gcc/ChangeLog: * fold

[COMMITTED] [AARCH64] Remove reference to MD_INCLUDES

don't have access to those targets. Committed as obvious. Thanks, Andrew Pinski gcc/ChangeLog: * config/aarch64/aarch64.md: Remove comment about MD_INCLUDES as it is out of date and not needed. --- gcc/config/aarch64/aarch64.md | 3 --- 1 file changed, 3 deletions(-) diff --

[PATCH v2] rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]

entry foo,.-foo nop Bootstrapped and regtested on powerpc64-linux-gnu P7 & P8, and powerpc64le-linux-gnu P9 & P10. v2: Update some comments, error message wordings, and test cases as Segher's review comments. v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599

[PATCH] vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

ted on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it ok for trunk? If it's ok, I guess we want this to be backported? BR, Kewen ----- PR tree-optimization/106322 gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_call): Don't allow ve

Re: [PATCH] rs6000: avoid ineffective replacement of splitters

Hi Jeff, on 2022/8/12 14:39, Jiufu Guo via Gcc-patches wrote: > Hi, > > As a comment in > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599556.html > > Those splitters call rs6000_emit_set_const directly, and the replacements > are never used. Using (pc) wou

Re: [PATCH] vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

at-linux, >> aarch64-linux-gnu and powerpc64{,le}-linux-gnu. >> >> Is it ok for trunk? > > OK for trunk. > >> If it's ok, I guess we want this to be >> backported? > > Yes, but you just missed the RC for 12.2 so please wait until after GCC 12.

[r13-2029 Regression] FAIL: gcc.dg/analyzer/torture/pr93451.c -Os (test for excess errors) on Linux/x86_64

/analyzer/torture/pr93451.c -O3 -g (test for excess errors) FAIL: gcc.dg/analyzer/torture/pr93451.c -Os (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-2029/usr --enable-clocale=gnu --with-system-zlib

Re: [PATCH] vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

Hi Richi, >> >> Yes, but you just missed the RC for 12.2 so please wait until after GCC 12.2 >> is released and the branch is open again. The testcase looks mightly >> complicated >> so fallout there might be well possible as well ;) I suppose it wasn't

PING^1 [PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html BR, Kewen on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote: > Hi, > > As the failure of test case gcc.target/powerpc/pr92398.p9-.c in > PR106345 shows, some test sources for some power

PING^1 [PATCH] rs6000: Suggest unroll factor for loop vectorization

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html BR, Kewen on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote: > Hi, > > Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one > unroll factor to be applied to vectorization factor when > vecto

PING^4 [PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html BR, Kewen >> >>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote: >>>> Hi, >>>> >>>> PR105485 exposes that new builtin function framework doesn't handle >

PING^4 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html BR, Kewen >>>> Hi, >>>> >>>> As PR104482 shown, it's one regression about the handlings when >>>> the argument number is more than the one of built-in function

PING^2 [PATCH v4] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html BR, Kewen > > on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote: >> Hi Segher! >> >> on 2022/6/25 00:49, Segher Boessenkool wrote: >>> Hi! >>> >>> On Fri

Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

for_speed_p which is equal to the invertion >>>> of optimize_function_for_size_p. At that time cfun->decl is valid >>>> but no cgraph node for it, w/o this patch function >>>> optimize_function_for_speed_p returns true eventually, while it >>>> r

Re: [PATCH] Implement __builtin_issignaling

s is checked by check_effective_target_issignaling in gcc/testsuite/lib/target-supports.exp, and probes the support for the issignaling macro in . I think it would make sense to adjust those tests to run on a wider range of targets, using the new built-in. FX

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

Question to the Fortran maintainers: Do you know if the standard allows IEEE_CLASS and IEEE_VALUE to be used as procedure pointers? I think not, because they do not follow (in F2008) the standard constraint C729 / R740. If so, we need to keep these functions implementations in libgfortran for n

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

Hi Jakub, I have two questions, on this and the ieee_class patch: > + tree type = TREE_TYPE (arg); > + gcc_assert (TREE_CODE (type) == RECORD_TYPE); > + tree field = NULL_TREE; > + for (tree f = TYPE_FIELDS (type); f != NULL_TREE; f = DECL_CHAIN (f)) > +if (TREE_CODE (f) == FIELD_DECL) >

Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi Segher, Thanks for the review! on 2022/8/16 05:30, Segher Boessenkool wrote: > Hi! > > On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote: >> on 2022/6/25 00:49, Segher Boessenkool wrote: >> Many thanks for all the further explanation above! The attached patch >> updated the misleadin

Re: [PATCH v2] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

r150:V4SI=vec_select(vec_concat(r141:V4SI,r146:V4SI),parallel) > 24: {r151:SI=vec_select(r146:V4SI,parallel [const_int 1]);} > > The endianness check need only once at ASM generation finally. > ASM would be better due to nested vec_select simplified to simple scalar > loa

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

Hi, >> Why looping over fields? The class type is a simple type with only one >> member (and it should be an integer, we can assert that). > > I wanted to make sure it has exactly one field. > The ieee_arithmetic.F90 module in libgfortran surely does that, but I've > been worrying about some use

[r13-2098 Regression] FAIL: gcc.dg/tree-prof/cmpsf-1.c scan-tree-dump-not dom2 "Invalid sum" on Linux/x86_64

-dump-not dom2 "Invalid sum" with GCC configured with ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-2098/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --w

<    8   9   10   11   12   13   14   15   16   17   >