On Thu, Mar 7, 2019 at 12:49 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch adds vmovss/vmovsd masked intrinsics.
> On
> #include
> __m128 f1 (__m128 w, __mmask8 u, const float *p) { return _mm_mask_load_ss
> (w, u, p); }
> __m128 f2 (__mmask8 u, const float *p) { return _mm_maskz_load_
On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
wrote:
>
> On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> >
> > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
> > >
> > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu wrote:
> > > >
This patch to the Go frontend sets TREE_PUBLIC for only-inline
functions. This fixes GCC PR 89227. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu and ppc64le-linux-gnu. Committed to mainline.
Ian
2019-03-06 Ian Lance Taylor
PR go/89227
* go-gcc.cc (Gcc_backend::function): Set TREE_P
On Wed, Mar 6, 2019 at 6:39 PM Jakub Jelinek wrote:
>
> The following patch tries to improve diagnostics of toplevel asm qualifiers
> in C++ by actually parsing them and complaining if they appear at toplevel,
> instead of just emitting a parse error that ( is expected, e.g. some
> versions of Qt
I have committed a Go frontend patch by Than McIntosh that fixes
Array_type::do_export to not emit a type conversion, by fetching the
constant value and exporting that. This fixes Go issue 30628.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Unfortunately it ap
My e-mail is not going out and I don't know why. Just testing. Sorry.
Ian
Hi!
The following patch adds vmovss/vmovsd masked intrinsics.
On
#include
__m128 f1 (__m128 w, __mmask8 u, const float *p) { return _mm_mask_load_ss (w,
u, p); }
__m128 f2 (__mmask8 u, const float *p) { return _mm_maskz_load_ss (u, p); }
__m128d f3 (__m128d w, __mmask8 u, const double *p) { retu
Hi!
The following patch tries to improve diagnostics of toplevel asm qualifiers
in C++ by actually parsing them and complaining if they appear at toplevel,
instead of just emitting a parse error that ( is expected, e.g. some
versions of Qt do use toplevel asm volatile and apparently the Qt code is
On 03/06/2019 01:44 AM, Jonathan Wakely wrote:
> On 06/03/19 09:20 +, Pádraig Brady wrote:
>> On 03/06/2019 12:50 AM, Jonathan Wakely wrote:
>>> On 06/03/19 02:43 +, Pádraig Brady wrote:
On 02/26/2019 04:23 PM, Padraig Brady wrote:
>
>> Note jemalloc >= 5.1 is requ
On Tue, Mar 05, 2019 at 04:06:59PM -0500, Jason Merrill wrote:
> > Assuming output_view_list_offset is correct, the following patch adjusts
> > size_of_die/value_format accordingly.
>
> I would guess that omitting the handling from output_view_list_offset was an
> oversight in the view work. Alex
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html
(This is marked as a P1 regression.)
On 2/26/19 6:32 PM, Martin Sebor wrote:
Please disregard the original patch and consider the attached
version instead.
On 2/26/19 5:03 PM, Martin Sebor wrote:
The false positive in PR89350 is d
Committed as rev.269444 to trunk, rev.269445 to 8-branch.
Thanks for the review!
Harald
On 03/06/19 00:07, Thomas Koenig wrote:
> Hi Harald,
>
>> To the reviewer: I am not 100% sure that my solution is correct, but it
>> solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu.
>>
Here the used base::operator= gets into the list of foo's bindings for
operator=, but it shouldn't make the copy ctor deleted.
Tested x86_64-pc-linux-gnu, applying to trunk.
* class.c (classtype_has_move_assign_or_move_ctor_p): Don't consider
op= brought in by a using-declaration.
Hello world,
the attached patch fixes a 7/8/9 regression where dependency checking
was for class arrays and a scalar value was mishandled when the
dependency happened in an elemental function.
There was an ICE for the test case which is handled by
fixing up the class refs in gfc_walk_variable_ex
Now that we're doing implicit lambda capture in templates, we see x here as
the lambda capture. maybe_convert_cond was doing nothing in a template, so
we never called mark_rvalue_use on x. As part of the broad move toward
doing more processing of non-dependent expressions, let's do this
conversio
On Wed, Mar 06, 2019 at 10:15:33AM -0700, Martin Sebor wrote:
> I read through this thread but I'm not sure I understand the problem
> (or really the tree sharing business -- different GIMPLE statements
> sharing the same tree node?)
>
> Is the problem here that the checking computes a checksum of
On 3/1/19 2:11 AM, Jakub Jelinek wrote:
On Fri, Mar 01, 2019 at 09:49:03AM +0100, Richard Biener wrote:
On Fri, 1 Mar 2019, Jakub Jelinek wrote:
Some of the builtin folding sets TREE_NO_WARNING flags, which triggers as
--enable-checking=fold errors. I think we should allow setting of
TREE_NO_W
On 3/6/19 8:56 AM, Peter Bergner wrote:
> On 3/6/19 8:47 AM, Segher Boessenkool wrote:
>> Which means you can write it as just
>>
>> static int
>> matching_constraint_num (const char *constraint)
>> {
>> if (*constraint == '%')
>> constraint++;
>>
>> if (IN_RANGE (*constraint, '0', '9'))
>>
On 3/5/19 4:53 PM, Marek Polacek wrote:
On Tue, Mar 05, 2019 at 03:50:30PM -0500, Jason Merrill wrote:
On 3/4/19 7:17 PM, Marek Polacek wrote:
This patch fixes a bogus -Wredundant-move warning. In the test in the PR
the std::move call isn't redundant; the testcase won't actually compile
withou
On 3/5/19 5:23 PM, Jakub Jelinek wrote:
Hi!
In this PR, Jonathan argues that we should accept value initialization of
classes with flexible array member.
The following patch does that. Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
OK.
Jason
On 3/6/19 8:47 AM, Segher Boessenkool wrote:
> Which means you can write it as just
>
> static int
> matching_constraint_num (const char *constraint)
> {
> if (*constraint == '%')
> constraint++;
>
> if (IN_RANGE (*constraint, '0', '9'))
> return strtoul (constraint, NULL, 10);
>
>
Hi Peter,
On Wed, Feb 20, 2019 at 09:19:58PM -0600, Peter Bergner wrote:
> PR89313 exposes a bug in the asmcons pass where it replaces input operands
> with matching constraints with their associated output operands, as well as
> all other uses of its pseudo registers. This is normally fine. How
On Wed, Mar 6, 2019 at 6:08 AM Uros Bizjak wrote:
>
> On Wed, Mar 6, 2019 at 2:49 PM Ian Lance Taylor wrote:
> >
> > On Wed, Mar 6, 2019 at 5:39 AM Uros Bizjak wrote:
> > >
> > > On Tue, Mar 5, 2019 at 9:50 PM Ian Lance Taylor wrote:
> > > >
> > > > On Tue, Mar 5, 2019 at 1:02 AM Uros Bizjak w
On Wed, Mar 6, 2019 at 2:49 PM Ian Lance Taylor wrote:
>
> On Wed, Mar 6, 2019 at 5:39 AM Uros Bizjak wrote:
> >
> > On Tue, Mar 5, 2019 at 9:50 PM Ian Lance Taylor wrote:
> > >
> > > On Tue, Mar 5, 2019 at 1:02 AM Uros Bizjak wrote:
> > > >
> > > > > I've committed this patch to update to the
On Wed, Mar 6, 2019 at 5:39 AM Uros Bizjak wrote:
>
> On Tue, Mar 5, 2019 at 9:50 PM Ian Lance Taylor wrote:
> >
> > On Tue, Mar 5, 2019 at 1:02 AM Uros Bizjak wrote:
> > >
> > > > I've committed this patch to update to the final Go 1.12 release.
> > > > Bootstrapped and ran Go testsuite on x86_
On Wed, Mar 06, 2019 at 02:45:23PM +0100, Uros Bizjak wrote:
> The attached patch removes
>
> /space/homedirs/uros/gcc-svn/trunk/libobjc/encoding.c:84: warning:
> "DFmode" redefined
>84 | #define DFmode _C_DBL
> |
> In file included from ../.././gcc/tm.h:36,
> f
The attached patch removes
/space/homedirs/uros/gcc-svn/trunk/libobjc/encoding.c:84: warning:
"DFmode" redefined
84 | #define DFmode _C_DBL
|
In file included from ../.././gcc/tm.h:36,
from /space/homedirs/uros/gcc-svn/trunk/libobjc/encoding.c:37:
../.././gcc/ins
On Tue, Mar 5, 2019 at 9:50 PM Ian Lance Taylor wrote:
>
> On Tue, Mar 5, 2019 at 1:02 AM Uros Bizjak wrote:
> >
> > > I've committed this patch to update to the final Go 1.12 release.
> > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> > > to mainline.
> >
> > This patch
On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
>
> On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
> >
> > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu wrote:
> > > >
> > > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski wro
On 06/03/19 12:13 +, Jonathan Wakely wrote:
* include/std/type_traits [C++20] (is_bounded_array)
(is_unbounded_array, is_bounded_array_v, is_unbounded_array_v):
Define.
* testsuite/20_util/is_bounded_array/requirements/
explicit_instantiation.cc: N
Hi,
PR 88235 is a cgraph verification failure which is a false positive.
The problem is that after thunk expansion which is done as a part of
thunk inlining the verifier is no longer able to detect that a call
graph edge callee points to a clone of the destination of the now
expanded thunk in the
* include/bits/c++config.h (_cpp_lib_char8_t): Add L suffix to
constant.
* testsuite/experimental/feat-char8_t.cc: Likewise.
Tested powerpc64le-linux, committed to trunk.
commit 959e5191a2e9628bedb38439842331658dbc4a58
Author: Jonathan Wakely
Date: Wed Mar 6 12:02:47 2
* include/std/type_traits [C++20] (is_bounded_array)
(is_unbounded_array, is_bounded_array_v, is_unbounded_array_v):
Define.
* testsuite/20_util/is_bounded_array/requirements/
explicit_instantiation.cc: New test.
* testsuite/20_util/is_bounded_
* include/bits/ptr_traits.h [C++20] (pointer_traits::pointer_to):
Add constexpr.
* testsuite/20_util/pointer_traits/pointer_to_constexpr.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit 8125740feaa7aa66589d0922992b9bf1065e1699
Author: Jonathan Wakely
D
Pinging and adding Gerald to the CC list.
On 22/02/2019 10:45, Sudakshina Das wrote:
> Hi
>
> This patch documents the addition of the new Armv8.5-A and corresponding
> extensions in the gcc-9/changes.html.
> As per https://gcc.gnu.org/about.html, I have used W3 Validator.
> Is this ok for cvs?
Pushed. Thank you Andrew for your review.
//Claudiu
From: Andrew Burgess [andrew.burg...@embecosm.com]
Sent: Friday, March 01, 2019 11:07 AM
To: Vineet Gupta
Cc: gcc-patches@gcc.gnu.org; Claudiu Zissulescu;
linux-snps-...@lists.infradead.org; Claudiu Zissu
Hi.
The patch is a cherry pick from libsanitizer.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
libsanitizer/ChangeLog:
2019-03-06 Martin Liska
PR sanitizer/88684
* sanitizer_common/sanitizer_platform.h
Committed to CVS.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.49
diff -u -r1.49 changes.html
--- htdocs/gcc-9/changes.html 28 Feb 2019 21:49:05 - 1.49
+++ htd
The ARC port is changing the allocation order in the
arc_conditional_register_usage function, but this is not the proper
way. Thus, we employ ADJUST_REG_ALLOC_ORDER hook for this task.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc-protos.h (arc_adjust_reg_alloc_order): Declare.
-xx-xx Claudiu Zissulescu
* config/arc/arc.opt (mcode-density-frame): Get the inital value
from TARGET_CODE_DENSITY_FRAME_DEFAULT.
* config/arc/elf.h (TARGET_CODE_DENSITY_FRAME_DEFAULT): Define it
to 1.
* config/arc/linux.h (TARGET_CODE_DENSITY_FRAME_
-xx-xx Claudiu Zissulescu
* config/arc/arc-protos.h (arc_register_move_cost): Remove.
* config/arc/arc.c (arc_register_move_cost): Re-purpose it to
implement target hook.
(arc_memory_move_cost): New function.
(TARGET_REGISTER_MOVE_COST): Define.
-xx-xx Claudiu Zissulescu
* config/arc/arc.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define.
---
gcc/config/arc/arc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 9e086477027..a3a013e90e1 100644
--- a/gcc/config/arc/arc.c
++
-xx-xx Claudiu Zissulescu
* config/arc/arc.md (tst_movb): Fix constraint.
---
gcc/config/arc/arc.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index c64a7fdb653..1e64331f397 100644
--- a/gcc/config/arc/arc.m
Hi,
Please find a set of 5 patches as this:
[ARC] Introduce ADJUST_REG_ALLOC_ORDER.
This patch just cleans the old way of changing the register allocation
order and uses a gcc macro specially made for this task.
[ARC] Enable code density frame option for elf targets.
The com
On Mon, 4 Mar 2019, Richard Biener wrote:
>
> The CFG cleanup change made us remove an extra forwarder which somehow
> makes VRP jump threading go berzerk. Fortunately only on
> logical-op-non-short-circuit=0 targets so the easy way to fix the
> testcase is to force that our way.
>
> Tested on
This is quite common mistake when SVC is used as parameter for
interrupt attribute instead of SWI. Since gcc doesn't warn the
developer and treats this as undefined I propose following patch.
0001-Allow-SVC-as-a-parameter-of-intterupt-attribute.patch
Description: Binary data
On 06/03/19 11:56 +0200, Ville Voutilainen wrote:
On Wed, 6 Mar 2019 at 11:33, Jonathan Wakely wrote:
>+ else if constexpr (is_rvalue_reference_v<_Tp&&>)
I know what this is doing, but it still looks a little odd to ask if
T&& is an rvalue-reference.
Would it be clearer to structure this
On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>
> On 3/5/19 7:44 AM, Richard Biener wrote:
>
> > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > the MAX_EXPR introduced by folding makes it somewhat ugly.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in pr
@Honza: PING^1
On 2/20/19 10:10 AM, Martin Liška wrote:
> On 2/19/19 2:25 PM, Martin Jambor wrote:
>> Hi,
>>
>> On Tue, Feb 19 2019, Martin Liška wrote:
>>> On 2/14/19 11:19 AM, Jan Hubicka wrote:
>>
>> ...
>>
Next stage1 we should also teach the callback to ignore edges of calls
th
@Honza: PING^1
On 2/22/19 11:59 AM, Martin Liška wrote:
> Hi.
>
> The patch makes a significant verifier speed up in a project that
> has a dtor for which we create ~70.000 clones.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
>
On Wed, 6 Mar 2019 at 11:56, Ville Voutilainen
wrote:
> > This one definitely needs to be cast to void* and needs to use
> > addressof (or __addressof), otherwise ...
>
>
> Sure thing; an incremental diff attached.
And here's the whole shebang.
diff --git a/libstdc++-v3/include/std/variant b/libs
On Wed, 6 Mar 2019 at 11:33, Jonathan Wakely wrote:
> >+ else if constexpr (is_rvalue_reference_v<_Tp&&>)
>
> I know what this is doing, but it still looks a little odd to ask if
> T&& is an rvalue-reference.
>
> Would it be clearer to structure this as:
>
> if constexpr (is_lvalue_refe
On 06/03/19 09:20 +, Pádraig Brady wrote:
On 03/06/2019 12:50 AM, Jonathan Wakely wrote:
On 06/03/19 02:43 +, Pádraig Brady wrote:
On 02/26/2019 04:23 PM, Padraig Brady wrote:
Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.
How serious is the bug? What are the symptoms
On 05/03/19 23:27 +0200, Ville Voutilainen wrote:
On Mon, 4 Mar 2019 at 01:43, Ville Voutilainen
wrote:
On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
wrote:
> I consider variant to no longer be in the state of sin after this.
Sigh, except for the places where it self-destructs or placement-
On Wed, Mar 06, 2019 at 10:18:22AM +0100, Martin Liška wrote:
> On 3/5/19 5:01 PM, Jakub Jelinek wrote:
> > On Tue, Mar 05, 2019 at 04:53:54PM +0100, Martin Liška wrote:
> >> Hi.
> >>
> >> The param was added by Jakub. Should I mention it in invoke.texi?
> >
> > It is meant solely for the testsuit
On 03/06/2019 12:50 AM, Jonathan Wakely wrote:
> On 06/03/19 02:43 +, Pádraig Brady wrote:
>>
>>
>> On 02/26/2019 04:23 PM, Padraig Brady wrote:
>>>
Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.
How serious is the bug? What are the symptoms?
>>> I've updated th
On 3/5/19 5:01 PM, Jakub Jelinek wrote:
> On Tue, Mar 05, 2019 at 04:53:54PM +0100, Martin Liška wrote:
>> Hi.
>>
>> The param was added by Jakub. Should I mention it in invoke.texi?
>
> It is meant solely for the testsuite, so I wouldn't document it.
> But if others disagree, I'm not strongly opp
On Wed, Mar 06, 2019 at 01:49:54AM -0600, luo...@linux.vnet.ibm.com wrote:
> From: Xiong Hu Luo
>
> Backport r268834 of "Add support for the vec_sbox_be, vec_cipher_be etc."
> from mainline to gcc-8-branch.
>
> Regression-tested on Linux POWER8 LE. Backport patch for gcc-8-branch
> already got
On 06/03/19 02:43 +, Pádraig Brady wrote:
On 02/26/2019 04:23 PM, Padraig Brady wrote:
Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.
How serious is the bug? What are the symptoms?
I've updated the commit summary to say it's a crash.
Arguably that's better than mem corrup
59 matches
Mail list logo
