On 3/12/2023 1:48 AM, Jeff Law wrote:
On 1/6/23 01:31, anothername27-unity--- via Gcc-patches wrote:
From: Himal
Hi,
This might be a better fix.
Regards.
PS. I had to use a different email.
---
libiberty/unlink-if-ordinary.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a
Hi Segher,
on 2023/3/9 22:55, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote:
>> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
>>> PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
>>>
64-pc-linux-gnu{-m32,}.
Ok for GCC 11/12 backport?
if (mdaz-ftz)
link crtfastmath.o
else if ((Ofast || ffast-math || funsafe-math-optimizations)
&& !mno-daz-ftz)
link crtfastmath.o
else
Don't link crtfastmath.o
gcc/ChangeLog:
=disable -O1 (internal compiler error: in
extract_insn, at recog.cc:2791)
FAIL: libgomp.oacc-fortran/update-dt-array.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O1 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/89701
* common.opt: Refactor -fcf-protection= to support combination
of param.
* lto-wrapper.c (merge_and_complain): Adjusted.
* opts.c
i Gao
Sent At:2023 May 6 (Sat.) 16:53
Recipient:Sinan
Cc:jiawei ; gcc-patches
Subject:Re: Re: [PATCH 4/5] RISC-V: Add Zcmp extension supports.
On 2023-05-05 23:57 Sinan wrote:
>
>> hi Jiawei
>>
>> Please ignore my previous reply. I accidently sent the email before I
>>
or indicate which testcase can demonstrate
>this pass?
>
>And I would prefer this pass split from this patch, let it become a separated
>patch including testcase.
This comment is incorrect.
this pass is to search `ret`, `cm.pop` and `mv a0, 0` and try to combine them
into cm.popretz a
t they both "conflicts" cf_full,
cf_none. And current EnumSet don't handle this well.
So in the current implementation, only cf_full,cf_none are exclusive
to each other, but they can be combined with any cf_branch, cf_return,
cf_check. It's not perfect, but still an improveme
e inserted entry has a size of 0 (i.e. if range[1] -
> > range[0] == 0) then the btree_insert call in __register_frame_info_bases
> > will not insert anything. This is not accounted for in
> > [snip]
> >
> > Would be cool if this could be fixed on the GCC trunk.
>
&
On Mon May 15, 2023 at 12:35 AM CEST, Thomas Neumann wrote:
> > even building the flatbuffers repo externally using cmake at the same
> > revision
> > didn't reproduce it.
> >
> > that said, i have attached a dockerfile that shows you what /does/ fail,
> > under
> > the specific conditions. but
Hi,
When running regression tests related to
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616772.html,
I noticed a bunch of failures because some tests explicitly pass in
-fdelete-null-pointer-checks, even if the target is configured to keep them.
This patch skips such failing tests by
Hi Carl,
on 2023/4/14 01:58, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> The following fix updates the expected instruction counts for the
> test int_128bit-runnable.c test. The counts changed as a result of a
> commit to support 128-bit integer divide and modul
Hi Carl,
on 2023/4/14 03:42, Carl Love via Gcc-patches wrote:
>
> GCC maintainers:
>
> The following patch fixes the dg-options for test powerpc/rs600-
> fpint.c. The test now works correctly on Power 10. The patch has been
> tested on Power10 with no regressions.
>
&g
M, x for M means it is ok for either
> 1 or 0; '||' means concatenation.
>
> This patch update rs6000_emit_set_long_const to support those constants.
>
> Compare with previous version:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607618.htm
> This patch fix
According to Jeff's review feedback, the issues regarding UNSPEC's
implementation of round, ceil, nearbyint, etc. still need to be determined:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617706.html
source:
https://github.com/majin2020/gcc-mir
instruction was added
> > principally to
> >accelerate the processing of JavaScript Numbers.", so it seems that no
> > implementation
> >is required.
> >
> > 3, The instructions FMINM and FMAXM correspond to C23 library function
> > fmini
ous bit M, x for M means it is ok for either
1 or 0; '||' means concatenation.
This patch update rs6000_emit_set_long_const to support those
constants.
Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607618.htm
This patch fix conflicts with tru
Hi,
When working on a cost tweaking patch, I found that a newly
added test case has different dumpings with stage-1 and
bootstrapped gcc. By looking into it, the apparent reason
is vect_analyze_loop_2 doesn't get slp_done_for_suggested_uf
set expectedly, the following retrying will us
u and powerpc64{,le}-linux-gnu.
BR,
Kewen
-----
gcc/ChangeLog:
* tree-vect-slp.cc (vect_transform_slp_perm_load_1): Refactor the
handling on the case index == count.
---
gcc/tree-vect-slp.cc | 89 ++--
1 file changed, 44 insertions(+
per_build, it's inconsistent
with the transformation part.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
Is it ok for trunk?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563624.html
BR,
Kewen
-
gcc/ChangeLog:
Hi,
I'd like to gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614818.html
BR,
Kewen
on 2023/3/29 15:18, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> By addressing Alexander's comments, against v1 this
> patch v2 mainly:
>
>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614228.html
BR,
Kewen
on 2023/3/20 14:33, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> One of my workmates found there is a warning like:
>
> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
>
> on 2022/11/24 17:15, Kewen Lin wrote:
>> Hi,
>>
>> Following Segher's suggestion, this patch series is to rework
>> function rs6000_emit_vector_com
?
gcc/ChangeLog:
* ira-costs.cc (scan_one_insn): Only use NO_REGS in cost
calculation when !hard_regno_mode_ok for GENERAL_REGS and
mode, otherwise still use GENERAL_REGS.
---
gcc/ira-costs.cc | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc
no any further uses here.
for ...
// B4 building nothing
}
// B5 ...
}
BR,
Kewen
>
>> Bootstrapped and regtested on x86_64-redhat-linux,
>> aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
>>
>> BR,
>> Kewe
On 26/04/23, 5:51 PM, "Richard Biener" mailto:richard.guent...@gmail.com>> wrote:
> On Wed, Apr 26, 2023 at 12:56 PM <mailto:senthilkumar.selva...@microchip.com>> wrote:
> >
> > On Wed, Apr 26, 2023 at 3:15 PM Richard Biener via Gcc-patches
&g
of more stuff.
This has been tested on powerpc64le-linux with nvptx offloading(Volta),
submitting here for trunk.
I am planning to commit this to devel/omp/gcc-12 (and probably 13 soon) after
more testing concludes.
Thanks,
Chung-Lin
2023-05-19 Chung-Lin Tang
gcc/ChangeLog
* builti
on 2023/5/17 14:32, Richard Biener wrote:
> On Wed, May 17, 2023 at 8:06 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> When working on a cost tweaking patch, I found that a newly
>> added test case has different dumpings with stage-1 and
>> bootstrapped gcc. By loo
on 2023/5/18 14:12, Richard Biener wrote:
> On Wed, May 17, 2023 at 9:19 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> on 2023/5/17 14:34, Richard Biener wrote:
>>> On Wed, May 17, 2023 at 8:09 AM Kewen.Lin wrote:
Hi,
This patch is to refactor the handlings for the case (index
>>>
Hi Carl,
on 2023/5/19 05:12, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> version 2. Fixed an issue with the test case. The dg-options line was
> missing.
>
> The following patch adds an overloaded builtin. There are two possible
> arguments for the
LE with no regressions.
>
> Thanks
> Gui Haochen
>
> ChangeLog
> 2023-05-04 Haochen Gui
>
> gcc/
> PR target/104124
> * config/rs6000/altivec.md (*altivec_vupkhs_direct): Rename
> to...
> (altivec_vupkhs_direct): ...this.
>
Also for 64-bit vector abs intrinsics _mm_abs_{pi8,pi16,pi32}.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/109900
* config/i386/i386.cc (ix86_gimple_fold_builtin): Fold
_mm{,256,512}_abs_{epi8,epi16,epi32,epi64} and
Hi Carl,
on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> The following patch fixes errors in the arguments in the
> __builtin_altivec_tr_stxvrhx, __builtin_altivec_tr_stxvrwx builtin
> definitions. Note, these builtins are used by
minated and the regressed
case is corner. So we can probably install this patch first and open a bug
for further enhancement.
Segher, what do you think of this?
BR,
Kewen
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
>
> Thanks
> Gui Haochen
&
d and regtested on x86_64-redhat-linux,
>> aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
>>
>> Is it ok for trunk?
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563624.html
>>
>> BR,
>> Kewen
>> -
>> gcc/ChangeL
on 2023/5/23 03:50, Carl Love wrote:
> On Mon, 2023-05-22 at 17:04 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> The following patch fixes errors in the a
on 2023/5/23 01:31, Carl Love wrote:
> On Mon, 2023-05-22 at 14:36 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/19 05:12, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> version 2. Fixed an issue with the test case. The
t; could under-cost for vector permutation, since the costing
>>>> doesn't try to consider nvectors_per_build, it's inconsistent
>>>> with the transformation part.
>>>>
>>>> Bootstrapped and regtested on x86_64-redhat-linux,
>>>> a
on 2023/5/24 06:30, Peter Bergner wrote:
> On 5/23/23 12:24 AM, Kewen.Lin wrote:
>> on 2023/5/23 01:31, Carl Love wrote:
>>> The builtins were requested for use in GLibC. As of version 2.31 they
>>> were added as inline asm. They requested a builtin so the asm could be
>>> removed.
>>
>> So IMHO
on 2023/5/24 13:42, Alexandre Oliva via Gcc-patches wrote:
>
> The bogus warning is present on 32-bit ppc-vx7r2 too, so drop the 64
> from the powerpc xfail triplet.
>
> Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
> with gcc-12.
It xfail-ed on my loc
on 2023/5/24 23:20, Carl Love wrote:
> On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote:
>> on 2023/5/24 06:30, Peter Bergner wrote:
>>> On 5/23/23 12:24 AM, Kewen.Lin wrote:
on 2023/5/23 01:31, Carl Love wrote:
> The builtins were requested for use in GLibC. As of version
> 2.31 th
ed test results confirm it.
Thanks for fixing, I tested this on ppc64le and ppc64 {-m64,-m32}
well.
>
> Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
> with gcc-12.
>
> for gcc/testsuite/ChangeLog
I think this is for PR101169, could you add it as PR marker?
&
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
Co-authored-by: Naveen H S
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc (layout_nonempty_base_or_field): Fix the type of
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc (layout_nonempty_base_or_field): Fix the type of
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc (layout_nonempty_base_or_field): Fix the type of
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc (layout_nonempty_base_or_field): Fix the type of
similar. The code is similar to how it is handled in the C front-end.
2021-04-03 Andrew Pinski
Co-authored-by: Naveen H S
gcc/ChangeLog:
* c-family/c-attribs.cc (handle_scalar_storage_order_attribute):
Do not reject the C++ cases.
* cp/class.cc
V64QImode,V32HImode,V16SImode,V8DImode for AVX512.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/ChangeLog:
PR target/100711
* config/i386/sse.md (*andnot3): Extend below splitter
to VI_AVX2 to cover more modes.
gcc/testsuite/ChangeLog
lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since
icelake. At least for icelake and later intel Core processors, the
errata tune is not needed. And the tune isn't need for ATOM either.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
Hi Segher,
on 2021/1/22 上午8:30, Segher Boessenkool wrote:
> Hi Ke Wen,
>
> On Fri, Jan 15, 2021 at 04:06:17PM +0800, Kewen.Lin wrote:
>> on 2021/1/15 上午8:22, Segher Boessenkool wrote:
>>> On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote:
... op regX // this regX could find wrong
.C scan-assembler-not vpcmpgt|vpcmpeq|vpsra
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6849/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable
Hi Segher/Richard B./Richard S.,
Many thanks for your all helps and comments on this!
on 2021/1/25 下午3:56, Richard Biener wrote:
> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>
>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
>>> On Thu, 21 Jan 2021, Segher Boessenkool wrote
on 2021/1/26 上午1:59, Richard Sandiford via Gcc-patches wrote:
> Richard Biener writes:
>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>>
>>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
>>>> On Thu, 21 Jan 2021, Segher Boessenkool wrote:
on 2021/1/26 上午4:37, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 25, 2021 at 05:59:23PM +, Richard Sandiford wrote:
>> Richard Biener writes:
>>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
But what could have been done differently that would have helped? Of
course Ke Wen co
on 2021/1/26 下午6:53, Richard Biener wrote:
> On Tue, 26 Jan 2021, Kewen.Lin wrote:
>
>> Hi Segher/Richard B./Richard S.,
>>
>> Many thanks for your all helps and comments on this!
>>
>> on 2021/1/25 下午3:56, Richard Biener wrote:
>>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>>>
On Fri, J
Hi,
As described in commit message, we need to avoid computing niters info for fake
edges. This simple patch does this by two changes.
Bootstrap and test on X86_64, is it ok?
Thanks,
bin
pr97627-20210128.patch
Description: Binary data
On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches
> wrote:
> >
> > Hi,
> > As described in commit message, we need to avoid computing niters info for
> > fake
> > edges. Thi
On Fri, Jan 29, 2021 at 3:55 PM Richard Biener
wrote:
>
> On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote:
> >
> > On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gc
-1.c -O1 (internal compiler error)
FAIL: gcc.c-torture/compile/20051216-1.c -O1 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6981/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in
trunk if bootstrap/regtest passes?
Thanks,
Aaron
contrib/ChangeLog:
* gcc_update (files_and_dependencies): Add dependency for
gcc/config/rs6000/fusion.md on gcc/config/rs6000/genfusion.md.
gcc/ChangeLog:
* config/rs6000/t-rs6000: Comment out auto generati
.C -std=c++17 (test for errors, line 7)
FAIL: g++.dg/cpp0x/alias-decl-dr1558.C -std=c++17 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7011/usr
--enable-clocale=gnu --with-system-zlib --with
/pr77550.C (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7011/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without
This isn't
a huge problem in practice, but some possible combinations still won't
happen."
Bootstrapped/regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8, also SPEC2017 build/run passed on P9.
Is it ok for trunk?
BR,
Kewen
[1] https://gcc.gnu.org/pipermail/gcc-pat
-foffload=disable -Os (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -Os (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master
-chartypes-1.f90 -O (internal compiler error)
FAIL: gfortran.dg/goacc/derived-chartypes-1.f90 -O (test for excess errors)
FAIL: gfortran.dg/goacc/derived-chartypes-2.f90 -O (internal compiler error)
FAIL: gfortran.dg/goacc/derived-chartypes-2.f90 -O (test for excess errors)
with GCC
The attached patch has been bootstrapped and regression tested. It addresses PR
analyzer/98797, which is built off the expected failures in
gcc/testsuite/gcc.dg/analyzer/casts-1.c It fixes those failures and additional
manifestations. That testsuite file has been updated to no longer expect
:43 2021 -0800
Address the bug found in test file gcc/testsuite/gcc.dg/analyzer/casts-1.c, as
recorded by the XFAIL, and some simpler and more complex versions found during
the investigation of it. PR analyzer/98797 was opened for these bugs.
The simplest manifestation of this
I hope that writing the detailed commit message will encourage someone
with better knowledge of GCC internals to point out a better place for
this logic. I can follow through with any suggestions :)
On Sat, Feb 13, 2021 at 12:20:30PM +, Maya Rashish wrote:
> Some subtargets don't pro
cc and store.cc include those).
As you know, I am very new to gcc and so was happy when I could hack my
way to this working at all. I already assumed my direct access was not
correct. Most of what I did is based on "RTFS" since the manual does not
really cover the right way to do these t
mat
> the latters into a similar rejection style.
>
> Currently, get_field_at_bit_offset is not an externally visible function.
> I am taking your instruction to reuse it to mean a prototype should
> be added to the relevant header (it would be region.h I think, as long as
> both regio
-cmi ,/pr99023_a.H
(gcm.cache/,/pr99023_a.H.gcm)
FAIL: g++.dg/modules/pr99023_a.H (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7271/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
le brackets). I have replaced the first
expression with int_bit_position (covering_field), I am not sure where to
properly
access the size of the field. FWIW, I found your region::get_byte_size, which
calls int_size_in_bytes, but this crashes gcc for a field tree, it wants a
type tree.
Additionally, is t
Hi,
I'd like to gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564758.html
BR,
Kewen
on 2021/2/3 下午2:37, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch merges the previously approved one[1] and its relied patch
> made by Segher here[2], it&#
Hi David,
Please find my revised patch attached. You should find all items addressed. I
have bootstrapped and rerun the testsuite (gcc and g++ only). Also, you
should have seen my legal paperwork go in.
1) The commit message has been updated to reflect the nomenclature in the
testsuite, as well
it's to make unsigned int vector init go with
>> rldimi to merge two integers instead of shift and ior.
>
>> gcc/ChangeLog:
>>
>> 2020-02-03 Segher Boessenkool
>> Kewen Lin
>>
>> * config/rs6000/rs6000.md (*rotl3_insert_3): R
prove the naming, and rewrote a number of comments to make them consistent
with the code, and generally tried to make things more readable.
OK for trunk if bootstrap/regtest passes?
Thanks!
Aaron
gcc/ChangeLog:
* config.gcc: Add pcrel-opt.o.
* config/rs6000/pcrel-opt.c: New
c. These corrected errors were for
addition and subtraction manipulations of variables within a
conditional. Other manipulations, like multiply and divide, are still
failing as expected because no handler has been added.
gcc/analyzer/ChangeLog:
PR analyzer/94362
std=c++14 (test for excess errors)
FAIL: g++.dg/ext/attr-lambda3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/ext/attr-lambda3.C -std=c++2a (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7430/
on 2021/1/27 下午5:43, Kewen.Lin via Gcc-patches wrote:
> on 2021/1/26 下午6:53, Richard Biener wrote:
>> On Tue, 26 Jan 2021, Kewen.Lin wrote:
>>
>>> Hi Segher/Richard B./Richard S.,
>>>
>>> Many thanks for your all helps and comments on this!
>>
Hi,
It may not be worth altering at this point, but it seems like it would leave
less
bugs open if all the constraints go in as "closed" ranges and all evals are
translated to closed intervals. So, if (idx > 0) and if (idx >= 1) are the same
constraint. I know this won't be an option for eventual
I have been kicking these sorts of ideas around ever since I came to understand
that
the second "UNKNOWN" in the for loop that originally started this was due to
the state
merge as we loop. For now, and I don't mean this disrespectfully because it is
very
hard to get right, the whole issue of me
Wow! I wasn't expecting that to work. Obviously we know that there is currently
no handler for binop_svalue in the constraints so I would have to watch it run
with
state merging disabled to see how it is managing the unroll. The fact that
merging
breaks it is indicative of what we are saying tho
, Jeff Law wrote:
> On 3/2/21 6:40 PM, David Malcolm via Gcc-patches wrote:
>
> > > My devil's advocate position would be if the analyzer raises
> > > exception on
> > > any possible overflow, will that overwhelm the user with false
> > > positives
warnings, line 13)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7469/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable
warnings, line 13)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-10/releases/gcc-10/r10-9413/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
config/aarch64/aarch64-arches.def (armv8.1-a): Modify ARCH_REV as per
latest ACLE.
(armv8.2-a): Likewise.
(armv8.3-a): Likewise.
(armv8.4-a): Likewise.
(armv8.5-a): Likewise.
(armv8.6-a): Likewise.
---
gcc/config/aarch64/aarch64-arches.def | 15
predicate (ds_form_mem_operand) that only
accepts what we can take as for a ds-form load. Then a small
modification of the genfusion.pl script changes the relevant
ld+cmpi patterns to use the new predicate.
OK for trunk if bootstrap/regtest passes?
gcc/ChangeLog
PR target/99070
;
FAIL: g++.dg/modules/builtin-3_a.C -std=c++2b scan-lang-dump module
"Writing:-[0-9]*'s named merge key \\(decl\\) type_decl:'::__builtin_va_list'"
FAIL: g++.dg/modules/builtin-3_a.C -std=c++2b scan-lang-dump module "Wrote
GMF:-[0-9]* type_decl:'::__builtin_v
]
caused
FAIL: gcc.target/i386/pr78103-2.c scan-assembler \\m(leal|addl)\\M
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2649/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable
test on x86_64-linux-gnu{-m32,}.
Pushed to trunk if there're no objections.
gcc/ChangeLog:
* config/i386/sse.md (cond_):New expander.
(cond_mul): Ditto.
(cond_div): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/cond_op_addsubmuldiv_double-1.c
on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
> Hi Richi,
>
> on 2021/7/30 下午7:34, Richard Biener wrote:
>> This adds a gather vectorization capability to the vectorizer
>> without target support by decomposing the offset vector, doing
>> sclar loads and then
gcc/ChangeLog:
* config/i386/i386-modes.def (FLOAT_MODE): Define ieee HFmode.
* config/i386/i386.c (enum x86_64_reg_class): Add
X86_64_SSEHF_CLASS.
(merge_classes): Handle X86_64_SSEHF_CLASS.
(examine_argument): Ditto.
(construct_container): Ditto
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.
AVX512FP16: Support vector init/broadcast/set/extract for FP16.
gcc/ada/gcc-interface/misc.c | 3 +
gcc/c-family/c-common.c | 6 +-
gcc/c-family/c-cppbuiltin.c | 6 +-
gcc
gcc/ada/ChangeLog:
* gcc-interface/misc.c (gnat_post_options): Issue an error for
-fexcess-precision=16.
gcc/c-family/ChangeLog:
* c-common.c (excess_precision_mode_join): Update below comments.
(c_ts18661_flt_eval_method): Set excess_precision_type to
libgcc/ChangeLog
* soft-fp/eqhf2.c: New file.
* soft-fp/extendhfdf2.c: New file.
* soft-fp/extendhfsf2.c: New file.
* soft-fp/extendhfxf2.c: New file.
* soft-fp/half.h (FP_CMP_EQ_H): New marco.
* soft-fp/truncdfhf2.c: New file
* soft-fp/trunc
libgcc/ChangeLog:
* config/i386/32/sfp-machine.h (_FP_NANFRAC_H): New macro.
* config/i386/64/sfp-machine.h (_FP_NANFRAC_H): Ditto.
* config/i386/sfp-machine.h (_FP_NANSIGN_H): Ditto.
* config/i386/t-softfp: Add hf soft-fp.
* config.host: Add i386/64/t-softf
gcc/ChangeLog:
* config/i386/avx512fp16intrin.h (_mm_set_ph): New intrinsic.
(_mm256_set_ph): Likewise.
(_mm512_set_ph): Likewise.
(_mm_setr_ph): Likewise.
(_mm256_setr_ph): Likewise.
(_mm512_setr_ph): Likewise.
(_mm_set1_ph): Likewise
From: "Guo, Xuepeng"
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect FEATURE_AVX512FP16.
* common/config/i386/i386-common.c
(OPTION_MASK_ISA_AVX512FP16_SET,
OPTION_MASK_ISA_AVX512
on 2021/8/2 下午3:09, Richard Biener wrote:
> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>
>> on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Richi,
>>>
>>> on 2021/7/30 下午7:34, Richard Biener wrote:
>>>> This adds a gather vectorizati
701 - 800 of 41351 matches
Mail list logo
