Hongyu Wang 于2020年9月21日周一 下午1:30写道：
>
> Hi:
>
> This patch is about to support Intel Key Locker extension.
>
> Key Locker provides a mechanism to encrypt and decrypt data with an AES
key without having access to the raw key value.
>
> For more details, please refer to
Hi!
On Wed, Oct 07, 2020 at 04:53:11PM -0500, will schmidt wrote:
> > +;; AIX does not support extended mnemonic xxswapd. Use the basic
> > +;; mnemonic xxpermdi instead.
>
> I'd wonder if there can be additional logic using ( DEFAULT_ABI ==
> ABI_AIX ) sort of check to resolve this. It looks
On Mon, Oct 12, 2020 at 01:15:39PM -0700, Carl Love wrote:
> This patch fixes an error in how the vec_rlnm() builtin parameters are
> handled. The current test for this builtin are compile only. The
> issue was found in the path that adds the 128-bit operands to the
> vec_rlnm() builtin. The
Ping the following 9 patches to add support for building a GCC toolchain where
the default long double is IEEE 128-bit floating point instead of the IBM
extended double floating point.
The first patch was revised with input from Joesph Myers. I will list that
patch in this list. Most of these
Ping the following two patches to add IEEE 128-bit minimum, maximu, and
conditional move support:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554460.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554461.html
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street,
The analyzer's initial worklist was only populated with non-static
functions in the TU (along with those that look promising for call
summaries). Hence some static functions that were never explicitly
called but could be called via function pointers were not being
analyzed.
This patch remedies
Hi,
this patch fixes tramp3d ICE with PGO. It has turned out to be by a misupdate
in ignore_edge I introduced in previous patch that made us to not compute
SCCs correctly with -fno-lto.
While looking for problem I proofread the sources and also fortified the
srouces for situation where we insert
Enable the sincos optimization within callers of these
(single-argument) elementary functions.
Regstrapped on x86_64-linux-gnu, approved by Arno, checking in.
for gcc/ada/ChangeLog
* libgnat/a-ngelfu.ads (Sin, Cos): Make the single-argument
functions inline.
---
On Mon, 2020-10-12 at 15:43 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 07, 2020 at 04:08:12PM -0500, will schmidt wrote:
> > On Mon, 2020-10-05 at 11:51 -0700, Carl Love wrote:
> > > +/* Sign extend builtins that work on ISA 3.0, but not defined
> > > until ISA 3.1. */
> >
> > I
Hi!
On Mon, Oct 12, 2020 at 01:15:32PM -0700, Carl Love wrote:
> Patch 1, adds the 128-bit sign extension instruction support and
> corresponding builtin support.
> * config/rs6000/altivec.h (vec_signextll, vec_signexti): Add define
> for new builtins.
> *
Hi!
On Wed, Oct 07, 2020 at 04:08:12PM -0500, will schmidt wrote:
> On Mon, 2020-10-05 at 11:51 -0700, Carl Love wrote:
> > +/* Sign extend builtins that work on ISA 3.0, but not defined until ISA
> > 3.1. */
>
> I have mixed feelings about straddling the ISA 3.0 and 3.1 ; but not
> sure how
Will, Segher:
Patch 1, adds the 128-bit sign extension instruction support and
corresponding builtin support.
Removed the blank line per Will's latest feedback.
Retested the patch on Power 9 with no regression errors.
Carl
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats using the new P10 instructions
dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
otherwise the conversions continue to use the existing SW routines.
The
Will, Segher:
This patch adds the 128-bit integer support for divide, modulo, shift,
compare of 128-bit integers instructions and builtin support.
Fixed the references to 128-bit in ChangeLog that got missed in the
last go round.
Fixed missing spaces in emit_insn calls.
Re-tested the patch on
Will, Segher:
Patch 4 adds the vector 128-bit integer shift instruction support for
the V1TI type.
This patch also renames and moves the VSX_TI iterator from vsx.md to
VEC_TI in vector.md. The uses of VEC_TI are also updated.
Re-tested the patch on Power 9 with no regression errors.
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats.
Updated ChangeLog comments. Fixed up comments in the test program.
Re-tested the patch on Power 9 with no regression errors.
Will, Segher:
This patch fixes an error in how the vec_rlnm() builtin parameters are
handled. The current test for this builtin are compile only. The
issue was found in the path that adds the 128-bit operands to the
vec_rlnm() builtin. The new test for the 128-bit operands is a compile
and run
On Linux/x86_64,
83685efd5fd1623cfc4e4c435ce2773d95d458d1 is the first bad commit
commit 83685efd5fd1623cfc4e4c435ce2773d95d458d1
Author: Martin Sebor
Date: Fri Oct 9 14:48:43 2020 -0600
Generalize compute_objsize to return maximum size/offset instead of failing
(PR middle-end/97023).
On Thu, 8 Oct 2020, Iain Buclaw wrote:
> > Noticed in a build of a MIPS I toolchain. I have no way to run MIPS
> > regression-testing right now, however in `libopcodes' the L.D and S.D
> > instructions are strict aliases valid for the MIPS II and higher ISAs, and
> > just to double-check
From: Andrew MacLeod
[posting on behalf of Andrew]
We were ignoring the return value if op2 returned false and getting garbage
ranges propagated.
Tested on x86-64 Linux.
Pushed.
gcc/ChangeLog:
PR tree-optimization/97381
* gimple-range-gori.cc
I merged master revision 3175d40fc52fb8eb3c3b18cc343d773da24434fb to
the gccgo branch.
Ian
Hello, Martin,
On Oct 12, 2020, Martin Liška wrote:
> It seems the patch caused quite some clang warnings:
> /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/builtins.c:2366:5:
> warning: comparison of different enumeration types in switch statement
> ('combined_fn' and
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (PREDEFINED): Use __cplusplus=201703L
so that C++17 features are documented.
Tested x86_64-linux. Committed to trunk.
commit 925eb6a0fbf5aa6e99e8b461a41cbeeab507afcd
Author: Jonathan Wakely
Date: Mon Oct 12 18:14:01 2020
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in: Update to Doxygen 1.8.20 format.
Tested x86_64-linux. Committed to trunk.
commit c840700852c69b2bf7a73df77d8d9f0658330dae
Author: Jonathan Wakely
Date: Mon Oct 12 18:14:01 2020
libstdc++: Update doxyfile to Doxygen 1.8.20 format
On Mon, Oct 12, 2020 at 05:19:58PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, Oct 09, 2020 at 09:38:09AM +0100, Alex Coplan wrote:
> >> Hi Segher,
> >>
> >> On 08/10/2020 15:20, Segher Boessenkool wrote:
> >> > On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan
Division by zero should return VARYING, otherwise we propagate undefine all
over the
ranger and cause bad things to happen :). This fixes MOD 0 to also return
VARYING.
This is Andrew's patch. I forgot to use --author for proper patch
attribution.
Tested on x86-64 Linux.
Pushed to trunk.
On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> That's why I kept the reporting part manual on my side: once you know
> which commit introduced a failure/regression (either via bisect, or by
> some other way), it's not always easy to identify the gcc-patches
> message to which
Segher Boessenkool writes:
> On Fri, Oct 09, 2020 at 09:38:09AM +0100, Alex Coplan wrote:
>> Hi Segher,
>>
>> On 08/10/2020 15:20, Segher Boessenkool wrote:
>> > On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
>> > > Ping. The kernel is still broken on AArch64.
>> >
>> > You
This patch adds two new warnings:
-Wanalyzer-write-to-const
-Wanalyzer-write-to-string-literal
for code paths where the analyzer detects a write to a constant region.
As noted in the documentation part of the patch, the analyzer doesn't
prioritize detection of such writes, in that the
On 12/10/20 10:19 -0400, Patrick Palka via Libstdc++ wrote:
libstdc++-v3/ChangeLog:
* include/std/ranges (take_while_view::begin): Constrain the
const overload further as per LWG 3450.
(take_while_view::end): Likewise.
*
On 12/10/20 10:19 -0400, Patrick Palka via Libstdc++ wrote:
Now that the frontend bug PR96805 is fixed, we can apply the proposed
resolution for this issue.
This slightly deviates from the proposed resolution by declaring _CI a
member of take_view instead of take_view::_Sentinel, since it
On Mon, Oct 12, 2020 at 01:24:44PM +0100, Richard Sandiford wrote:
> Martin Sebor via Gcc-patches writes:
> > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> >> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> >> wrote:
> >>>
> >>> On Sat, Oct 03, 2020 at 12:21:04PM -0700,
Hi all,
first: *PING*.
secondly, I think the change to testsuite/lib/libgomp.exp's libgomp_init
is also needed.
(Hence, I now added it.) I have a too new system-installed libatomic to
be sure that
it fails without.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße
Hi Christophe,
On 12/10/2020 12:40, Christophe Lyon wrote:
Hi,
On Thu, 8 Oct 2020 at 16:22, Christophe Lyon wrote:
On Thu, 8 Oct 2020 at 16:08, Dennis Zhang wrote:
Hi Christophe,
On 08/10/2020 14:14, Christophe Lyon wrote:
Hi,
On Tue, 6 Oct 2020 at 15:37, Dennis Zhang via
On 10/11/20 9:44 PM, Jason Merrill wrote:
On 10/11/20 6:45 PM, Martin Sebor wrote:
On 10/9/20 9:13 AM, Jason Merrill wrote:
On 10/9/20 10:51 AM, Martin Sebor wrote:
On 10/8/20 1:40 PM, Jason Merrill wrote:
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On
Hi Tom,
On Mon, 12 Oct 2020, Tom de Vries wrote:
> Mention new -misa=sm_35 default for NVPTX target in the gcc 11 release
> notes.
>
> See also PR target/97348.
>
> Verified using the validator
>
> OK?
yes, this is okay.
FWIW, I am happy to review wwwdocs patches. As nvptx maintainer
you
libstdc++-v3/ChangeLog:
* include/std/ranges (take_while_view::begin): Constrain the
const overload further as per LWG 3450.
(take_while_view::end): Likewise.
* testsuite/std/ranges/adaptors/take_while.cc: Add test for LWG
3450.
---
Now that the frontend bug PR96805 is fixed, we can apply the proposed
resolution for this issue.
This slightly deviates from the proposed resolution by declaring _CI a
member of take_view instead of take_view::_Sentinel, since it doesn't
depend on anything within _Sentinel anymore.
Tested on
On Mon, Oct 12, 2020 at 3:27 PM Christophe Lyon via Gcc-patches
wrote:
>
> On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool
> wrote:
> >
> > On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > > wrote:
> > > > On Sat, Oct 03, 2020
On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool
wrote:
>
> On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > wrote:
> > > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> > > wrote:
> > > > On
Hi Christophe,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 12 October 2020 12:41
> To: Dennis Zhang
> Cc: Richard Earnshaw ; nd ;
> gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
>
> Subject: Re: Ping: [PATCH][Arm] Enable MVE SIMD
On Mon, Oct 12, 2020 at 1:31 PM Martin Liška wrote:
>
> On 10/12/20 1:27 PM, Richard Biener wrote:
> > Btw, POLY_INT_CST can likely be handled the same as INTEGER_CST - I suppose
> > you tried that? (it might need further adjustments downstream).
>
> Yes, it can. But it seemed to me like an
On 10/12/20 2:44 PM, Martin Liška wrote:
On 10/7/20 10:00 AM, Richard Biener wrote:
As said I'd have a BB-local pass over BBs recording the index variable
and the range covered by the BBs gcond, plus recording how many excess
stmts there are for eventual code motion.
Only after that BB-local
On Mon, Oct 12, 2020 at 02:39:24PM +0200, Martin Liška wrote:
> All right, I started to use init_range_entry in combination with
> linearize_expr_tree.
> One thing I have problem with is that linearize_expr_tree doesn't properly
> mark
> all statements as visited for cases like:
Not sure if
On 10/7/20 10:00 AM, Richard Biener wrote:
As said I'd have a BB-local pass over BBs recording the index variable
and the range covered by the BBs gcond, plus recording how many excess
stmts there are for eventual code motion.
Only after that BB-local pass start to group BBs in a walk from
On 10/6/20 4:12 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 03:48:38PM +0200, Martin Liška wrote:
On 10/6/20 9:47 AM, Richard Biener wrote:
But is it really extensible with the current implementation? I doubt so.
I must agree with the statement. So let's make the pass properly.
I would
When a VEC_PERM SLP node just permutes existing lanes this confuses
the SLP subgraph detection where I tried to elide a node-based
visited hash-map in a way that doesn't work. Fixed by adding such.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-10-12 Richard Biener
Martin Sebor via Gcc-patches writes:
> On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
>> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
>> wrote:
>>>
>>> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
>>> wrote:
On Linux/x86_64,
Ping?
On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html
--
Alan Modra
Australia Development Lab, IBM
On 10/12/20 1:34 PM, Tobias Burnus wrote:
> On 10/9/20 1:56 PM, Tom de Vries wrote:
>
>> [nvptx] Set -misa=sm_35 by default
> I committed the attached follow-up commit as obvious,
> r11-3818-g91e4e16b550540723cca824b9674c7d8c43f4849
Thanks for catching this.
Thanks,
- Tom
Hi,
On Thu, 8 Oct 2020 at 16:22, Christophe Lyon wrote:
>
> On Thu, 8 Oct 2020 at 16:08, Dennis Zhang wrote:
> >
> > Hi Christophe,
> >
> > On 08/10/2020 14:14, Christophe Lyon wrote:
> > > Hi,
> > >
> > >
> > > On Tue, 6 Oct 2020 at 15:37, Dennis Zhang via Gcc-patches
> > > wrote:
> > >>
> >
Hi,
Mention new -misa=sm_35 default for NVPTX target in the gcc 11 release notes.
See also PR target/97348.
Verified using the validator
OK?
Thanks,
- Tom
gcc-11/changes: NVPTX: Mention new -misa=sm_35 default
---
htdocs/gcc-11/changes.html | 8 +++-
1 file changed, 7 insertions(+), 1
"duanbo (C)" writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Wednesday, September 30, 2020 6:38 PM
>> To: duanbo (C)
>> Cc: GCC Patches
>> Subject: Re: [PATCH PR96757] aarch64: ICE during GIMPLE pass: vect
>>
>> Thanks for the
On 10/9/20 1:56 PM, Tom de Vries wrote:
[nvptx] Set -misa=sm_35 by default
I committed the attached follow-up commit as obvious,
r11-3818-g91e4e16b550540723cca824b9674c7d8c43f4849
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
On 10/12/20 1:27 PM, Richard Biener wrote:
Btw, POLY_INT_CST can likely be handled the same as INTEGER_CST - I suppose
you tried that? (it might need further adjustments downstream).
Yes, it can. But it seemed to me like an incorrect match:
On Mon, Oct 12, 2020 at 1:26 PM Richard Biener
wrote:
>
> On Mon, Oct 12, 2020 at 12:59 PM Martin Liška wrote:
> >
> > The patch fixes the following 2 issues:
> >
> >.MASK_STORE_LANES (, 4B, max_mask_34, vect_array.12);
> >
> > here we miss to return the last argument as stored value.
> >
>
On Mon, Oct 12, 2020 at 12:59 PM Martin Liška wrote:
>
> The patch fixes the following 2 issues:
>
>.MASK_STORE_LANES (, 4B, max_mask_34, vect_array.12);
>
> here we miss to return the last argument as stored value.
>
> ivtmp_32 = ivtmp_31 + POLY_INT_CST [4, 4];
>
> here we miss a bail out in
The patch fixes the following 2 issues:
.MASK_STORE_LANES (, 4B, max_mask_34, vect_array.12);
here we miss to return the last argument as stored value.
ivtmp_32 = ivtmp_31 + POLY_INT_CST [4, 4];
here we miss a bail out in vect_recog_over_widening_pattern.
gcc/ChangeLog:
PR
Hi all,
This patch fixes the PR by adjusting the input types of the intrinsic
prototypes to the ones mandated by ACLE
Turns out the tests in the testsuite were already using the correct ones, but
implicit conversions hid the bug...
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to
Hi,
This patch merges the D front-end implementation with upstream dmd
3a9790525. Fixes a symbol resolver bug where a private alias becomes
public if used before its declaration.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline, and backported to the gcc-10 and
Hi,
Some of the larger tests in the phobos testsuite on occasion trigger the
default timeout limit. Increasing the limit to 10 minutes should give
compilation enough time to finish.
Regression tested on x86_64-linux-gnu, and committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
Hi,
This patch merges the D front-end implementation with upstream dmd
3a9790525. Fixes the return codes to match the documentation of
Target::isVectorTypeSupported.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
Hi,
this is largely mechanical patch fixing some suboptimal datastrcuture decision
in modref. It records three different things
1) optimization_summaries that are used by tree-ssa-alias to disambiguate
(computed by local passes or ipa execute)
2) summaries produced by local analysis and
Pushed as obvious.
gcc/ChangeLog:
PR tree-optimization/97371
* range-op.cc (operator_rshift::op1_range): Ignore shifts larger than
or equal to type precision.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97371.c: New test.
---
gcc/range-op.cc| 7 +++
On 09.10.20 17:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. OK for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555782.html
> v1 -> v2: Use related_int_vector_mode.
>
>
>
> The vector copysign pattern incorrectly assumes that vector
> Prevents the following UBSAN error:
>
> ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/torture/pr49770.C -O2 -c
> /home/marxin/Programming/gcc2/gcc/ipa-modref-tree.h:482:22: runtime error:
> load of value 2, which is not a valid value for type 'bool'
> #0 0x1fdb4d1 in
Prevents the following UBSAN error:
./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/torture/pr49770.C
-O2 -c
/home/marxin/Programming/gcc2/gcc/ipa-modref-tree.h:482:22: runtime error: load
of value 2, which is not a valid value for type 'bool'
#0 0x1fdb4d1 in
Hello Alexander.
It seems the patch caused quite some clang warnings:
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/builtins.c:2366:5:
warning: comparison of different enumeration types in switch statement
('combined_fn' and 'built_in_function') [-Wenum-compare-switch]
Hi,
Currently, in order to use the switch -msoft-stack-reserve-local with the
default arg 128, you have to specify '-msoft-stack-reserve-local128'.
Fix the switch format such that you specify '-msoft-stack-reserve-local=128'
instead.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[nvptx]
On Mon, Oct 12, 2020 at 10:13:09AM +0200, Tobias Burnus wrote:
> This is a tiny update – and probably not the last for the GCC 11 status
> and especially as the project page is still linked prominently at some
> external pages:
>
> Update the GOMP project page a bit; some more revisions wouldn't
This is a tiny update – and probably not the last for the GCC 11 status
and especially as the project page is still linked prominently at some
external pages:
Update the GOMP project page a bit; some more revisions wouldn't harm,
however: https://gcc.gnu.org/projects/gomp/
OK? Wording
On Thu, 8 Oct 2020 at 11:58, Richard Earnshaw
wrote:
>
> On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote:
> > On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw
> > wrote:
> >>
> >> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
> >>> When mi_delta is > 255 and -mpure-code is
This appropriately makes matches all true after successful SLP discovery
to reliably succeed splitting. We were picking up an eventual all
false built-up from scalars state in some cases.
Bootstrap / regtest in progress on x86_64-unknown-linux-gnu.
2020-10-12 Richard Biener
*
This avoids abnormals in another place.
Bootstrap / regtest in progress on x86_64-unknown-linux-gnu.
2020-10-12 Richard Biener
PR tree-optimization/97357
* tree-ssa-loop-split.c (ssa_semi_invariant_p): Abnormal
SSA names are not semi invariant.
*
On Fri, 9 Oct 2020, Tom de Vries wrote:
> Hi,
>
> The function gimple_can_duplicate_bb_p currently always returns true.
>
> The presence of can_duplicate_bb_p in tracer.c however suggests that
> there are cases when bb's indeed cannot be duplicated.
>
> Move the implementation of
75 matches
Mail list logo
