On 6/10/20 3:10 AM, qianchao wrote:
Thanks for reviewing this. Could you please help install this patch?
Sure, but the patch can't survive ChangeLog verification script:
1) please do not modify ChangeLog files changes, these are generated
from git commit message: https://gcc.gnu.org/codingconve
v2: Update rs6000 length_mode hook to QImode, also update description of the
hook.
gcc/ChangeLog:
2020-MM-DD Kewen Lin
* config/rs6000/rs6000.c (TARGET_VECTORIZE_LENGTH_MODE): New macro.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: New hook.
* target.def: Like
V2: Update the define_expand to use QImode.
gcc/ChangeLog:
2020-MM-DD Kewen Lin
* config/rs6000/vsx.md (lenloadqi): New define_expand.
(lenstoreqi): Likewise.
---
gcc/config/rs6000/vsx.md | 32
1 file changed, 32 insertions(+)
diff --git a/
V2: Convert the length to targetm.vectorize.length_mode in
related IFN expand functions.
btw, since it depends on this hook now, it should be
committed after the hook patch if accepted in future.
gcc/ChangeLog:
2020-MM-DD Kewen Lin
* doc/md.texi (lenload@var{m}@var{n}): Document.
gcc/ChangeLog:
* tree-vect-loop-manip.c (vect_set_loop_controls_directly): Rename
LOOP_VINFO_MASK_COMPARE_TYPE to LOOP_VINFO_COMPARE_TYPE. Rename
LOOP_VINFO_MASK_IV_TYPE to LOOP_VINFO_IV_TYPE.
(vect_set_loop_condition_masked): Renamed to ...
(vect_set_loop_
gcc/ChangeLog:
* tree-vect-loop-manip.c (vect_set_loop_mask): Renamed to ...
(vect_set_loop_control): ... this.
(vect_maybe_permute_loop_masks): Rename rgroup_masks related things.
(vect_set_loop_masks_directly): Renamed to ...
(vect_set_loop_controls_direct
gcc/ChangeLog:
* tree-vect-loop-manip.c (vect_set_loop_condition): Rename
LOOP_VINFO_FULLY_MASKED_P to LOOP_VINFO_USING_PARTIAL_VECTORS_P.
(vect_gen_vector_loop_niters): Likewise.
(vect_do_peeling): Likewise.
* tree-vect-loop.c (_loop_vec_info::_loop_vec_inf
gcc/ChangeLog:
* tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Rename
can_fully_mask_p to can_use_partial_vectors_p.
(vect_analyze_loop_2): Rename LOOP_VINFO_CAN_FULLY_MASK_P to
LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P. Rename saved_can_fully_mask_p
to sav
Hi all,
As Richard suggested in vector with length reviews here
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547077.html,
this series is responsible for some renaming and refactoring
related to existing fully masking supports. Since we are going
to introduce length-based partial vectorizat
On 09/06/20 10:53 pm, Jonathan Wakely wrote:
On 09/06/20 22:42 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrot
On 6/9/20 7:54 PM, Marek Polacek wrote:
Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier. In this case we never go
Thanks for reviewing this. Could you please help install this patch?
Thanks,
Qian Chao.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, June 9, 2020 8:56 PM
> To: qianchao
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95569] ICE in
Segher:
So I have been looking at the predicate definitions that I had created.
On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > +;; Return 1 if op is a 32-bit constant signed integer
> > +(define_predicate "s32bit_cint_operand"
> > + (and (match_code "const_int")
> > + (ma
Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier. In this case we never got around
to re-parsing it because the noex
On Wed, 10 Jun 2020, Patrick McGehearty wrote:
> I see your point about other floating point formats.
> According to the C standard, DOUBLE precision must
> have a DBL_MAX of at least 1E+37. That is (slightly)
> greater than 0x1.0p+63.
>
> Would
> #define RMIN2 (0x1.0p-53)
> #define RMINSCAL (0x1
I see your point about other floating point formats.
According to the C standard, DOUBLE precision must
have a DBL_MAX of at least 1E+37. That is (slightly)
greater than 0x1.0p+63.
Would
#define RMIN2 (0x1.0p-53)
#define RMINSCAL (0x1.0p+51)
be acceptable?
Those will be in range for any architect
Hi!
Everything Will said included by reference :-)
On Mon, Jun 01, 2020 at 04:01:53PM -0400, Michael Meissner wrote:
> Add support for the new IEEE 128-bit minimum, maximum, and set compare mask
> instructions when -mcpu=future was used.
You can say "ISA 3.1 instructions" now :-) That may read
On Tue, Jun 9, 2020 at 2:56 PM Alex Butler wrote:
>
> Replaced for consistency with the rest of the aarch64 backend.
>
> Testing done:
> Cross-compiled and regression tested on aarch64-none-elf, no issues.
If we 100% know the size of the buffer that passes to sprintf is
reasonable for the format
As clarified by LWG 3265, std::move_iterator is supposed to have an
assignment operator that converts from a different specialization of
std::move_iterator, which performs an assignment. That has always been
missing from libstdc++, so assigning a different type actually performs
a converting constr
Replaced for consistency with the rest of the aarch64 backend.
Testing done:
Cross-compiled and regression tested on aarch64-none-elf, no issues.
---
gcc/ChangeLog:
2020-04-08 Alex Butler
* config/aarch64/aarch64.md (cb1): Replace
sprintf with snprintf
---
aarch64.md |2
As Martin Sebor points out, the ChangeLog entries should not be included
in the patch. So I have removed those. I also made some changes to this
patch that were necessary because of changes to the other patch.
See the patch below:
From 676b6436835434f89c8511cd68e89947c32f11c6 Mon Sep 17 00:00:00 2
Hi!
On Mon, Jun 01, 2020 at 04:01:52PM -0400, Michael Meissner wrote:
> This patch renames some functions that were added for power9 support that are
> named '_p9' to be '_hw'. This is preparation for the next patch that wants to
> extend these functions for -mcpu=power support.
_hw means nothin
Martin Sebor writes:
> On 6/8/20 7:07 PM, Asher Gordon wrote:
>>
>> OK, these will be easy to fix. Should my other patch¹ (which implements
>> -Wuniversal-initializer) also have PR c/95379?
>
> I'm sure that would be fine but since it's a separate enhancement
> it doesn't need to. It's up to you
On Tue, 2020-06-02 at 18:12 -0600, Martin Sebor wrote:
> The compute_objsize() function started out as a thin wrapper around
> compute_builtin_object_size(), but over time developed its own
> features to compensate for the other function's limitations (such
> as its inability to work with ranges).
The standard requires that std::bad_optional_access' default
constructor has a non-throwing exception specification.
* include/std/optional (bad_optional_access): Define default
constructor and destructor as defaulted.
* testsuite/20_util/optional/bad_access.cc: New test.
On Thu, 2020-05-21 at 14:04 +0200, Martin Liška wrote:
> PING^1
>
> On 3/20/20 4:55 PM, Martin Liška wrote:
> > Ok, it would be possible, but if you take a look at options-save.c there's
> > no
> > function that will leverage that. It's a generated code so I guess we can
> > live with that?
Given
On Mon, 2020-05-18 at 19:59 +0200, Aldy Hernandez wrote:
> Howdy.
>
> The main evrp domwalker seems cut and pasted from the
> substitute_and_fold_engine (or was it the other way around?). Albeit,
> there are a few things that evrp does, like set up ranges, but these can
> be set up with virtu
On 09/06/20 22:42 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumon
On 09/06/20 22:35 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 12:24 pm, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
ÃÂ ÃÂ ÃÂ Here is the last of my algo patches this time to extend
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo pat
On Thu, 2020-04-02 at 06:35 +, xiezhiheng wrote:
> Hi,
> I've created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
>
> And I'm going to solve this problem by propagating def's insn to its use
> when they are at the same loop in fwprop pass.
> I mean somet
On 09/06/20 22:20 +0200, François Dumont via Libstdc++ wrote:
On 08/06/20 8:20 pm, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
ÃÂ ÃÂ ÃÂ Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators a
Hi!
On Mon, Jun 01, 2020 at 04:01:51PM -0400, Michael Meissner wrote:
> Add support for generating BRH/BRW/BRD when -mcpu=future is used.
> * config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
> generate the BRH instruction.
"Add alternative for brh."? If the changelog ruthles
On 09/06/20 12:24 pm, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode
On Tue, 2 Jun 2020 at 15:25, Martin Liška wrote:
>
> On 6/2/20 4:14 PM, Jonathan Wakely wrote:
> > On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote:
> >>
> >> On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
> >>>
> >>> On 6/2/20 1:48 PM, Martin Liška wrote:
> I tend to this approach. Let
On Sun, 2020-05-24 at 11:22 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Sun, May 24, 2020 at 07:03:13PM +0530, Kamlesh Kumar wrote:
> > In this patch series trying to address same by creating a struct Tuple
> > which bundles existing rtx and machine_mode and added one more
> > bool member which
On Tue, 2020-06-02 at 15:00 +0100, Richard Sandiford wrote:
> This patch uses parameter packs to define insn_gen_fn::operator().
> I guess in some ways it's C++-ification for its own sake, but it does
> make things simpler and removes the current artificial limit of 16
> arguments.
>
> Note that t
On 08/06/20 8:20 pm, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
   To do so I had to return int in impleme
On Wed, 2020-05-20 at 21:32 +0200, Michael Kuhn wrote:
> Hi,
>
> when specifying a non-system prefix with --with-zstd, the build fails
> because the header and library cannot be found (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005).
>
> The attached patch fixes the problem and is what
On 6/9/20 9:42 PM, Rainer Orth wrote:
Excess errors:
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'
Sorry for that, I'm going to install the following patch.
Martin
>From 20e0cd44f9c3e9402a0cd26a0332556391902cb6 Mon Sep 17 00:00:00 2001
From: Martin Liska
D
On 09/06/20 20:42 +0100, Jonathan Wakely wrote:
Also add comment explaining what the script does.
contrib/ChangeLog:
* gcc-changelog/git_email.py: Set exit status on error.
Committed as obvious.
With that change to git_email.py I can use the following change to the
contrib/prepare-c
On Fri, 2020-06-05 at 08:18 -0700, H.J. Lu wrote:
> On Tue, May 12, 2020 at 10:28 AM Jeff Law wrote:
> > On Fri, 2020-05-08 at 06:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > Don't perform CET run-time check for host when cross compiling. Instead,
> > > enable CET in cross compiler if possible
Also add comment explaining what the script does.
contrib/ChangeLog:
* gcc-changelog/git_email.py: Set exit status on error.
Committed as obvious.
commit 62963c60fc19d07615afe9d4f1b897b2f60801b2
Author: Jonathan Wakely
Date: Tue Jun 9 20:39:39 2020 +0100
gcc-changelog: Use non-
On Tue, Jun 9, 2020 at 5:04 AM Iain Sandoe wrote:
> Hi C++ folks,
>
> There are a number of places in the coroutine codegen where we need to
> build calls to promise methods.
>
> Such methods can, in several cases, also be constexpr or static (or both)
> which leads to the PR,
>
> Now the mechani
On Fri, 2020-06-05 at 09:57 -0300, Alexandre Oliva wrote:
> The testcase for PR51447, on x86_64, uses rbx as a global register
> variable for the global PTR variable.
>
> A runtime system might legitimately hold in rbx a value expected to be
> preserved across the call to main, but its use as a gl
Jakub Jelinek via Gcc-patches writes:
> On Tue, Jun 09, 2020 at 02:32:36PM +0200, Martin Liška wrote:
>> >From 5fe0671ad79d14d1c9d0fead1a471875a4416fac Mon Sep 17 00:00:00 2001
>> From: Martin Liska
>> Date: Tue, 9 Jun 2020 13:03:55 +0200
>> Subject: [PATCH] sanitizer: do not inline no-sanitize
On Thu, 2020-06-04 at 11:09 +0200, Christophe Lyon wrote:
> Hi,
>
> On Thu, 4 Jun 2020 at 01:03, Jeff Law via Gcc-patches
> wrote:
> > On Fri, 2020-01-31 at 15:50 -0300, Vitor Guidi wrote:
> > > I took the required steps. The patch is attached to this email, I hope
> > > I got it right this time.
On 6/9/20 3:47 PM, Marco Elver wrote:
I think one of you has to commit the patch, as we don't have access to
the GCC git repository.
I've just done that.
I also fixed few wrong formatting issues, next time please use
./contrib/check_GNU_style.py.
You'll be preparing one another patch, please
On 6/9/20 6:32 PM, Richard Biener wrote:
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
On 6/8/20 4:53 PM, Martin Liška wrote:
Hi.
Thank you for the report. It's caused by fact that LLVM switch in 4d474e078ac7
to c++14. So that I suggest to use gnu++14.
Patch can bootstrap on x86_64-li
I think I'd prefer the fix on the other side, if reasonable. I'd give them
some time to see about a fix there before selecting this patch.
On Jun 9, 2020, at 5:42 AM, Martin Jambor wrote:
> On Tue, Jun 09 2020, Thomas Schwinge wrote:
>> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>>> T
Hi,
Hope you are safe and doing great.
Would you be interested in acquiring the records of Chemical industries
list to promote your product and service?
*Key contacts*: Ceo, Engineers, Chemists, Health and Safety Specialists,
Soil and Plant Scientists and more.
If you are interested ple
This fixes two issues in our handling of constrained class template
friend declarations.
The first issue is that we fail to set the constraints on the injected
class template declaration during tsubst_friend_class.
The second issue is that the template parameter levels within the parsed
constrain
Another part of 95369 is that we accept designated initializers with
non-aggregate types. That seems to be wrong since they're part of
aggregate initialization. clang/icc also reject it.
(Un)fortunately there are multiple contexts where we can use designated
initializers: function-like casts, me
> Like this?
Fine with me, thanks!
--
Eric Botcazou
Hi Bernhard,
For Fortran identifiers, that would be really good. Would you do that?
Is it really needed?
We do not enter internal helper names (class names, anything
artificial, anything leading underscore or leading uppercase) to the
suggestions proposals so should never actually recommend a
Hi,
This patch merges the D front-end implementation with upstream dmd
13d67c575. Contains many small API changes, most contained within the
front-end, but some spill out into the codegen.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/C
May I please ping this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545426.html
Thanks!
-Lewis
On Fri, May 08, 2020 at 03:35:25PM -0400, Lewis Hyatt wrote:
> On Fri, Jan 31, 2020 at 03:31:59PM -0500, David Malcolm wrote:
> > On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> >
On Tue, May 26, 2020 at 6:27 AM Martin Liška wrote:
>
> On 5/26/20 1:59 PM, H.J. Lu wrote:
> > On Tue, May 26, 2020 at 2:30 AM Martin Liška wrote:
> >>
> >> On 5/25/20 7:42 PM, H.J. Lu wrote:
> >>> Here is the updated patch. OK for master?
> >>
> >> Thank you for the updated patch.
> >>
> >> I h
On Fri, May 22, 2020 at 4:22 AM H.J. Lu wrote:
>
> On Sat, May 2, 2020 at 4:55 AM H.J. Lu wrote:
> >
> > Currently patchable area is at the wrong place. It is placed immediately
> > after function label, before both .cfi_startproc and ENDBR. This patch
> > adds UNSPECV_PATCHABLE_AREA for pseudo
On Sun, May 31, 2020 at 4:10 PM H.J. Lu wrote:
>
> We used to expand memcmp to "repz cmpsb" via cmpstrnsi. It was changed
> by
>
> commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
> Author: Nick Clifton
> Date: Fri Aug 12 16:26:11 2011 +
>
> builtins.c (expand_builtin_memcmp): Do not us
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
>
> On 6/8/20 4:53 PM, Martin Liška wrote:
> > Hi.
> >
> > Thank you for the report. It's caused by fact that LLVM switch in
> > 4d474e078ac7
> > to c++14. So that I suggest to use gnu++14.
> >
> > Patch can bootstrap on x86_64-linux-gnu and sur
This removes dead code left over from the reduction vectorization
refactoring last year.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-06-09 Richard Biener
* tree-vect-loop.c (vectorizable_induction): Remove dead code.
---
gcc/tree-vect-loop.c | 42 ---
On 09/06/20 17:11 +0100, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimiza
On 6/9/20 8:41 AM, Eric Botcazou wrote:
Yes, but the problem is that remap_decl isn't getting called.
Right, I can get it to be called by adding a pushdecl to grokdeclarator...
Attaching it to the BIND_EXPR doesn't help walk_tree_1 do the right
thing with the DECL_EXPR.
... but, indeed, thi
We only need to predeclare a VLA type if it's wrapped in a pointer type;
otherwise gimplify_type_sizes will handle it.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/95552
* cp-gimplify.c (predeclare_vla): Only predeclare a VLA if it's
wrapped in
On Tue, Jun 9, 2020 at 5:51 PM Martin Sebor wrote:
>
> On 6/9/20 1:43 AM, Richard Biener wrote:
> > On Mon, Jun 8, 2020 at 11:59 PM Martin Sebor via Gcc-patches
> > wrote:
> >>
> >> PR 95581 reports an ICE in a call to gimple_call_arg() with
> >> an out-of-bounds argument number (2). The attache
On 6/9/20 1:43 AM, Richard Biener wrote:
On Mon, Jun 8, 2020 at 11:59 PM Martin Sebor via Gcc-patches
wrote:
PR 95581 reports an ICE in a call to gimple_call_arg() with
an out-of-bounds argument number (2). The attached patch avoids
the ICE but I'm not sure it's the right fix. Other than ver
On Tue, 2020-06-09 at 17:26 +0200, Jakub Jelinek wrote:
> On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote:
> > On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> > > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > > > While technically OK the issue is
On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote:
> On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > > While technically OK the issue is that it does not solve the x86 issue
> > > > which with incomin
On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > While technically OK the issue is that it does not solve the x86 issue
> > > which with incoming stack alignment < 8 bytes does not perform
> > > dynamic re-alig
On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > While technically OK the issue is that it does not solve the x86 issue
> > which with incoming stack alignment < 8 bytes does not perform
> > dynamic re-alignment to align 'long long' variables appropriately.
> > Currentl
On Tue, 2020-06-09 at 09:17 +0200, Richard Biener wrote:
> On Mon, Jun 8, 2020 at 11:13 PM Jeff Law via Gcc-patches
> wrote:
> >
> > We're seeing some failures due to the local-alignment pass. For example on
> > sh4:
> >
> > Tests that now fail, but worked before (16 tests):
> >
> > gcc.dg/pr
The 'you' here is Richi, which Richi is probably aware but maybe not the
rest of the list :')
On 09/06/2020 15:29, Andre Vieira (lists) wrote:
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant to
be do
On Tue, 2020-06-09 at 01:00 +, Segher Boessenkool wrote:
> Some testcases failed (esp. with --with-cpu=power9) after my change
> to
> prefer xxperm over vperm when all else is equal. Fix that. (This
> also
> tightens the relevant REs somewhat).
>
> Tested on way too many configurations. Com
Hi Alexandre,
> When the linker plugin is not available, dump outputs in lto runs are
> different from those outputs.exp tests expect, so skip them for now.
>
> Regstrapped on x86_64-linux-gnu. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> * outputs.exp (skip_lto): Set when missing
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant to be
doing. Maybe something to look at later.
I have also included three tests that show it working for some simple
cases and even a nested one.
Unf
On Tue, Jun 09, 2020 at 04:02:19PM +0200, Tobias Burnus wrote:
> It turned out that this patch fails with LTO and partitions,
> causing fails at runtime such as
> libgomp: Duplicate node
> via libgomp/splay-tree.c's splay_tree_insert.
>
> In the test case, the problem occurred for functions - na
It turned out that this patch fails with LTO and partitions,
causing fails at runtime such as
libgomp: Duplicate node
via libgomp/splay-tree.c's splay_tree_insert.
In the test case, the problem occurred for functions - namely
main._omp_fn.* on the host.
If the code is run in LTO context, the fi
This removes dead code that was left over from the reduction
vectorization refactoring last year.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-06-09 Richard Biener
* tree-vect-stmts.c (vect_transform_stmt): Remove dead code.
---
gcc/tree-vect-stmts.c | 4
On Tue, 9 Jun 2020 at 15:22, Jakub Jelinek wrote:
>
> On Tue, Jun 09, 2020 at 03:15:39PM +0200, Marco Elver wrote:
> > gcc/
> > * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> > * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> > builtin for volatile in
On Mon, Jun 8, 2020 at 1:04 PM Martin Liška wrote:
>
> Hello.
>
> Thank you for the approval. There's the patch that defines 4 new
> DEF_INTERNAL_OPTAB_FN.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> It also builds on ppc64le-linux-gnu.
>
> Ready to be installed?
> -Original Message-
> From: Richard Biener
> Sent: 09 June 2020 14:24
> To: Alex Coplan
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] move permutation validity check
>
> On Tue, Jun 9, 2020 at 3:22 PM Alex Coplan wrote:
> >
> > > -Original Message-
> > >
On Tue, Jun 9, 2020 at 3:22 PM Alex Coplan wrote:
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of Richard
> > Biener
> > Sent: 05 May 2020 14:49
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] move permutation validity check
> >
> >
> > This delays the SLP permutation che
> -Original Message-
> From: Gcc-patches On Behalf Of Richard
> Biener
> Sent: 05 May 2020 14:49
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] move permutation validity check
>
>
> This delays the SLP permutation check to vectorizable_load and optimizes
> permutations only after all S
On Tue, Jun 09, 2020 at 03:15:39PM +0200, Marco Elver wrote:
> gcc/
> * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> builtin for volatile instrumentation of reads/writes.
> (BUILT_IN_TSAN_VOLATILE_
Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing volatiles.
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For libgomp offloading testing, I'm seeing a number of failures like:
UNSUPPORTED:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop
On Tue, Jun 9, 2020 at 12:19 PM Eric Botcazou wrote:
>
> > I'm probably completely misunderstanding how TYPE_REVERSE_STORAGE_ORDER
> > works and what the constraints are. But if the memcpy is the storage order
> > barrier then what cases are OK?
> >
> > - both source and destination objects are
On Tue, Jun 9, 2020 at 11:47 AM qianchao wrote:
>
> Hi
>
> Commit eb72dc663e9070b281be83a80f6f838a3a878822 introduces a ICE on AArch64.
> See the discussion on the bug for details.
> Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95569
>
> Trivial patch fixing the ICE attached.
>
> Bootstrap a
Hi,
On Tue, Jun 09 2020, Thomas Schwinge wrote:
> Hi!
>
> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>> Thanks, here's the combined patch I'm checking in.
>>
>> revamp dump and aux output names
>
> For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
>
> Running [...]/
> Yes, but the problem is that remap_decl isn't getting called.
Right, I can get it to be called by adding a pushdecl to grokdeclarator...
> Attaching it to the BIND_EXPR doesn't help walk_tree_1 do the right
> thing with the DECL_EXPR.
... but, indeed, this still ICEs. So the key is that the D
Pushed to master.
gcc/ChangeLog:
* gcov-dump.c (print_usage): Fix spacing for --raw option
in --help.
---
gcc/gcov-dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcov-dump.c b/gcc/gcov-dump.c
index 90cbd1ace52..ffb71ca4b68 100644
--- a/gcc/gcov-du
On Tue, Jun 09, 2020 at 02:32:36PM +0200, Martin Liška wrote:
> >From 5fe0671ad79d14d1c9d0fead1a471875a4416fac Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Tue, 9 Jun 2020 13:03:55 +0200
> Subject: [PATCH] sanitizer: do not inline no-sanitize into sanitizer fn
>
> gcc/ChangeLog:
>
>
On 6/9/20 2:15 PM, Jakub Jelinek wrote:
Sorry for not writing everything at once, but are the
SANITIZER_POINTER_{COMPARE,SUBTRACT} differences unimportant?
They are. I got confused that they are not
part of SANITIZE_UNDEFINED or SANITIZE_UNDEFINED_NONDEFAULT.
Anyway, good point!
Martin
>From
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
Running [...]/source-gcc/gcc/testsuite/brig.dg/dg.exp ...
PASS: brig.dg/t
On Tue, 9 Jun 2020 12:41:21 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2020-06-05T21:31:08+0100, Julian Brown
> wrote:
> >> For the OpenACC runtime API 'acc_attach' etc. routines they don't,
> >> so what's the conceptual reason that for the corresponding OpenACC
> >> directive variants, '
Hi Richard,
The 06/09/2020 12:44, Richard Sandiford wrote:
> Tamar Christina writes:
> > Hi Richard,
> > The 06/08/2020 16:42, Richard Sandiford wrote:
> >> Tamar Christina writes:
> >> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> > index
> >> > 97da60762390db
On Tue, Jun 09, 2020 at 02:09:06PM +0200, Martin Liška wrote:
> - return ((sanitize_flags_p (SANITIZE_ADDRESS, caller)
> -== sanitize_flags_p (SANITIZE_ADDRESS, callee))
> - && (sanitize_flags_p (SANITIZE_POINTER_COMPARE, caller)
> - == sanitize_flags_p (SANITIZE_POINTER_CO
On 6/9/20 2:01 PM, Jakub Jelinek wrote:
On Tue, Jun 09, 2020 at 01:53:38PM +0200, Martin Liška wrote:
+ const sanitize_code codes[] =
+{
+ SANITIZE_ADDRESS,
+ SANITIZE_THREAD,
+ SANITIZE_LEAK,
Why leak?
I was too eager ;)
That is really a link time option only, doesn't
1 - 100 of 153 matches
Mail list logo
