On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
> >> with your patch, we would only warn about
> >>
> >> var .and. func()
> >>
> >> and not about
> >>
> >> func() .and. var.
> >>
> >> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
> >> always be exectued, or if it does, I hav
2018-06-26 23:16 GMT+02:00 Jakub Jelinek :
> On Tue, Jun 26, 2018 at 11:12:40PM +0200, Thomas Koenig wrote:
>> Hi Janus,
>>
>> with your patch, we would only warn about
>>
>> var .and. func()
>>
>> and not about
>>
>> func() .and. var.
>>
>> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
Hi Richard,
Thanks for the review,
On 25 June 2018 at 20:20, Richard Biener wrote:
> On Fri, Jun 22, 2018 at 11:16 AM Kugan Vivekanandarajah
> wrote:
>>
>> gcc/ChangeLog:
>
> @@ -1516,6 +1521,114 @@ minmax_replacement (basic_block cond_bb,
> basic_block middle_bb,
>
>return true;
> }
> +/*
Hi Richard,
Thanks for the review.
On 25 June 2018 at 20:02, Richard Biener wrote:
> On Fri, Jun 22, 2018 at 11:14 AM Kugan Vivekanandarajah
> wrote:
>>
>> gcc/ChangeLog:
>
> The canonical way is calling simplify_using_initial_conditions on the
> may_be_zero condition.
>
> Richard.
>
>> 2018-06
Hi Richard,
Thanks for the review.
On 25 June 2018 at 20:01, Richard Biener wrote:
> On Fri, Jun 22, 2018 at 11:13 AM Kugan Vivekanandarajah
> wrote:
>>
>> [PATCH 1/3][POPCOUNT] Handle COND_EXPR in expression_expensive_p
>
> This says that COND_EXPR itself isn't expensive. I think we should
>
In this PR, we have a large std::array of pairs. Since the C array is
wrapped in a class we don't go to build_vec_init, so we end up with
digest_init wanting to build up the element initializer for each
element of the array.
In the more general case, like 80272, we have a data structure
problem:
When the std::pair constructors got more complex to handle, it
aggravated a preexisting algorithmic problem in template overload
resolution:
As part of template argument deduction in a call, once we've deduced
all the template arguments we can but before we substitute them to
form an actual declar
With the exception of built-ins with the ellipsis (like sprintf),
GCC silently accepts declarations of built-in functions without
prototypes as well as calls to such functions with any numbers
or types of arguments, compatible or otherwise. Calls with
arguments whose number and types match exactl
On 22/06/18 00:28 +0100, Jonathan Wakely wrote:
The explicit instantiation declarations for std::basic_string are
disabled for C++17 (and later) so that basic_string symbols get
implicitly instantiated in every translation unit that needs them. On
targets that don't support STB_GNU_UNIQUE this l
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain. However I haven't quit on reducing
Debug mode performance impact.
So this patch make use of
On Tue, 2018-06-26 at 01:44 +0200, Paolo Carlini wrote:
> Hi,
>
> this includes straightforward tweaks to check_concept_fn and quite a
> bit
> of additional work on grokdeclarator: most of it is also rather
> straightforward. In a few places there is the subtlety that we want
> to
> handle toge
Attached is an updated patch to tighten up the warning and also
prevent ICEs in the middle-end like in PR 86308 or PR 86202.
I took Richard's suggestion to add the POINTER_TYPE_P() check
to detect pointer/integer conflicts. That also avoids the ICEs
above.
I also dealt with the fileptr_type_nod
> The AArch64 parts are OK. I've been holding off approving the patch while
> I wait for Eric to reply on the x86_64 fails with your new testcase.
The test is not portable in any case since it uses the "optimize" attribute so
I'd just make it specific to Aarch64 and install the patch.
--
Eric B
On 06/23/2018 08:38 AM, Dimitar Dimitrov wrote:
For some targets, Pmode != UNITS_PER_WORD. Take this into account
when marking hard registers as being used.
I tested C and C++ testsuits for x86_64 with and without this
patch. There was no regression, i.e. gcc.sum and g++.sum matched
exactly.
On Wed, Jun 20, 2018 at 05:15:37AM -0500, Tamar Christina wrote:
> Hi Kyrill,
>
> Many thanks for the review!
>
> The 06/19/2018 16:47, Kyrill Tkachov wrote:
> > Hi Tamar,
> >
> > On 19/06/18 15:07, Tamar Christina wrote:
> > > Hi All,
> > >
> > > This fixes a regression where we don't have an i
On Wed, Jun 20, 2018 at 04:41:18AM -0500, Siddhesh Poyarekar wrote:
> On 06/19/2018 09:11 PM, James Greenhalgh wrote:
> > On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote:
> >> r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
> >> which this comment about X30 n
On Fri, Jun 22, 2018 at 02:52:33AM -0500, Hongbo Zhang wrote:
> HXT semiconductor's CPU core Phecda, as a variant of Qualcomm qdf24xx,
> reuses the same tuning structure and pipeline with it.
OK.
Thanks,
James
> 2018-06-19 Hongbo Zhang
>
> * config/aarch64/aarch64-cores.def (AARCH64_CO
On Mon, Jun 25, 2018 at 04:24:14AM -0500, Sudakshina Das wrote:
> PING!
>
> On 14/06/18 12:10, Sudakshina Das wrote:
> > Hi Eric
> >
> > On 07/06/18 16:33, Eric Botcazou wrote:
> >>> Sorry this fell off my radar. I have reg-tested it on x86 and tried it
> >>> on the sparc machine from the gcc far
On Tue, Jun 26, 2018 at 11:12:40PM +0200, Thomas Koenig wrote:
> Hi Janus,
>
> with your patch, we would only warn about
>
> var .and. func()
>
> and not about
>
> func() .and. var.
>
> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
> always be exectued, or if it does, I have not se
On 06/26/2018 03:31 PM, David Malcolm wrote:
Which assert are you referring to?
Hm, I think I may have been confused by the unsigned arithmetic check in:
if (start_location <= set->highest_line
|| start_location > LINEMAPS_MACRO_LOWEST_LOCATION (set))
/* We ran out of macro map spa
Hi Janus,
with your patch, we would only warn about
var .and. func()
and not about
func() .and. var.
AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
always be exectued, or if it does, I have not seen the
documentation; it just happens to match what we currently
see (which may be due
On 06/26/2018 06:43 AM, Richard Biener wrote:
>
> A patch from Honza not LTO streaming DECL_ORIGINAL_TYPE ends up
> ICEing during LTO bootstrap because we end up not re-using the
> DIE we create late during LTRANS for a subprogram because its
> parent is a namespace rather than a CU DIE (or a modu
On Mon, 2018-06-25 at 15:34 +0200, Richard Biener wrote:
> On Wed, Jun 20, 2018 at 6:34 PM David Malcolm
> wrote:
> >
> > Here's v3 of the patch (one big patch this time, rather than a
> > kit).
> >
> > Like the v2 patch kit, this patch reuses the existing dump API,
> > rather than inventing its
Hi,
This adds Vim syntax highlighting rules for match.pd and packages them together
with gcc-rtl.vim and gimple.vim, creating contrib/vim-gcc-dev subtree that can
be installed as a common Vim plugin.
Thanks.
Alexander
* vim-gcc-dev/README: New file.
* vim-gcc-dev/ftdetect/gcc-dev
On 06/26/2018 05:59 AM, Rasmus Villemoes wrote:
> When adding the vxworks_iolib_include_unistd hack I failed to add the
> appropriate hunk to the tests/base/ioLib.h file, causing "make
> check-fixincludes" to fail.
>
> OK for trunk?
>
> 2018-06-26 Rasmus Villemoes
>
> fixincludes/
>
>
On 06/26/2018 02:54 AM, Eric Botcazou wrote:
> Hi,
>
> this makes sure the goto_locus present (or not) on edges is properly remapped
> during inlining.
>
> Tested on x86-64/Linux, OK for the mainline?
>
>
> 2018-06-26 Eric Botcazou
>
> * tree-inline.c (remap_location): New function e
Hi Segher,
This patch, as revised in response to your suggestions, was committed to trunk
on 4/17/2018.
Is this ok for backporting to gcc8, gcc7, and gcc6?
Thanks.
On 4/13/18 3:15 PM, Kelvin Nilsen wrote:
> Twelve failures have been occuring in the bfp test directory during -m32
> regressio
On Tue, 2018-06-26 at 14:28 -0400, Nathan Sidwell wrote:
> I've been wandering around the line-map machinery on the modules
> branch.
> One thing I noticed was the padding of the line_map type hierarchy
> was
> unfortunate. That made me sad. This patch fixes that.
>
> Rather than keep the th
On 26/06/18 15:09 -0400, David Edelsohn wrote:
The recent addition of
testsuite/experimental/algorithm/sample-2.cc
testsuite/experimental/algorithm/shuffle.cc
introduced link errors on AIX. AIX (and Solaris) require additional
options for TLS in some situations.
This patch adds the dejagnu TL
The recent addition of
testsuite/experimental/algorithm/sample-2.cc
testsuite/experimental/algorithm/shuffle.cc
introduced link errors on AIX. AIX (and Solaris) require additional
options for TLS in some situations.
This patch adds the dejagnu TLS directives.
Was this dependency intended? Is
In recently committed patch to correct code generation for the vec_packsu
(vector unsigned long long, vector unsigned long long) built-in function, I
accidentally left a comment in place that was not relevant to the final patch
that was committed.
This patch fixes that comment. After regressio
I've been wandering around the line-map machinery on the modules branch.
One thing I noticed was the padding of the line_map type hierarchy was
unfortunate. That made me sad. This patch fixes that.
Rather than keep the the reason field in line_map, I move it to
line_map_ordinary. That allo
On 06/26/2018 02:06 AM, Richard Biener wrote:
> On Tue, Jun 26, 2018 at 2:21 AM David Malcolm wrote:
>>
>> I ran into this bootstrap failure (with r262092):
>>
>> ../../../src/gcc/tree-vect-loop.c: In function ‘_loop_vec_info*
>> vect_analyze_loop(loop*, loop_vec_info, vec_info_shared*)’:
>> ../.
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug
mode performance impact.
So this patch make use of the existing std::__niter_base to get
rid of the
Hi!
On Mon, Jun 25, 2018 at 10:41:32AM -0500, Aaron Sawdey wrote:
> In gcc 8 I added support for unaligned vsx in the builtin expansion of
> memset(x,0,y). Turns out that for memset of less than 32 bytes, this
> doesn't really help much, and it also runs into an egregious load-hit-
> store case in
This patch adds a concept of nested "scopes" to dumpfile.c's dump_*_loc
calls, and wires it up to the DUMP_VECT_SCOPE macro in tree-vectorizer.h,
so that the nested structure is shown in -fopt-info by indentation.
For example, this converts -fopt-info-all e.g. from:
test.c:8:3: note: === analyzin
On Mon, 2018-06-25 at 15:34 +0200, Richard Biener wrote:
> On Wed, Jun 20, 2018 at 6:34 PM David Malcolm
> wrote:
> >
> > Here's v3 of the patch (one big patch this time, rather than a
> > kit).
> >
> > Like the v2 patch kit, this patch reuses the existing dump API,
> > rather than inventing its
Joseph Myers wrote:
> On Thu, 21 Jun 2018, Jeff Law wrote:
>
> > I think all this implies that the setting of -fno-math-errno by default
> > really depends on the math library in use since it's the library that
> > has to arrange for either errno to get set or for an exception to be raised.
>
> If
On 02/06/18 14:00 +0200, François Dumont wrote:
Hi
Here is this patch again, I consider all your remarks and also
made some changes considering feedback on rbtree patch.
+ _Vector_impl(_Tp_alloc_type const& __a) _GLIBCXX_NOEXCEPT
+ : _Tp_alloc_type(__a)
+ { }
+
+#if _
Cannot identify what sorting is used for that list (if any), so putting
it at the end (and -gsplit-dwarf also follows -fvar-tracking-assignments
in the "Options for Debugging Your Program" section).
Author: Stephan Bergmann
Date: Tue Jun 26 15:04:54 2018 +0200
Documentation: -gsplit-dw
On 2018-06-19 18:45, Olivier Hainque wrote:
> Hi Rasmus,
>
>
> 1/6:
>> vxworks: add target/h/wrn/coreip to the set of system include paths
>
> As we discussed on the message dedicated to this patch, this
> one is ok.
>
> For the rest, I still have concerns for part of the patches. Some
> would
A patch from Honza not LTO streaming DECL_ORIGINAL_TYPE ends up
ICEing during LTO bootstrap because we end up not re-using the
DIE we create late during LTRANS for a subprogram because its
parent is a namespace rather than a CU DIE (or a module).
I'm wondering of the general reason why we enforc
On Sat, 23 Jun 2018, Segher Boessenkool wrote:
> On Thu, Jun 21, 2018 at 10:43:16PM +, Joseph Myers wrote:
> > On Thu, 21 Jun 2018, Segher Boessenkool wrote:
> >
> > > The comment doesn't make much sense. If long double is IBM, the long
> > > double complex mode is ICmode, not KCmode. "To g
On 26/06/18 09:19 +0200, Stephan Bergmann wrote:
On 08/06/18 13:01, Jonathan Wakely wrote:
Nothing very exciting, just adding noexcept and defaulting some
members.
* include/bits/regex.h (sub_match): Add noexcept to default
constructor and length observer.
(match_results): Add noexc
When adding the vxworks_iolib_include_unistd hack I failed to add the
appropriate hunk to the tests/base/ioLib.h file, causing "make
check-fixincludes" to fail.
OK for trunk?
2018-06-26 Rasmus Villemoes
fixincludes/
* tests/base/ioLib.h [VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK]: Add
On Tue, Jun 26, 2018 at 12:52 PM, Jakub Jelinek wrote:
> Hi!
>
> These peephole2s assume that when matching insns like:
> [(parallel [(set (reg FLAGS_REG) (match_operand 0))
> (match_operand 4)])
> that operands[4] must be a set of a register with operands[0]
> as SET_SRC, but that
Hi!
These peephole2s assume that when matching insns like:
[(parallel [(set (reg FLAGS_REG) (match_operand 0))
(match_operand 4)])
that operands[4] must be a set of a register with operands[0]
as SET_SRC, but that isn't the case e.g. for:
(insn 9 8 10 2 (parallel [
(set
On Tue, Jun 26, 2018 at 11:20:32AM +0200, Rainer Orth wrote:
> > Committed (after moving the testcase to gcc.target/i386).
>
> the new testcase FAILs on 32-bit Solaris/x86
>
> FAIL: gcc.target/i386/pr86257.c scan-assembler data16[ \\t]*leaq
>
> and, according to gcc-testresults, also on i586-unk
From: villemoes
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@262133
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 7d1dd1faaca..5010ba97135 100644
--- a/ChangeLog
+++ b/ChangeLog
@@
Hi Tom,
> On 06/24/2018 11:56 PM, Jan Hubicka wrote:
>>> Hi,
>>>
>>> [ The analysis of this PR was done at https://stackoverflow.com/a/33557963 ,
>>> November 2015. ]
>>>
>>> This tls sequence:
>>> ...
>>> 0x00 .byte 0x66
>>> 0x01 leaq x@tlsgd(%rip),%rdi
>>> 0x08 .word 0x
>>> 0x0a rex64
>>> 0
On 06/26/2018 11:17 AM, Rainer Orth wrote:
> Hi Andreas,
>
>> When turning a user-defined numerical literal into an operator
>> invocation the literal needs to be translated to the execution
>> character set.
>>
>> Bootstrapped and regtested on s390x. x86_64 still running.
>> Ok to apply if x86_64
Hi Andreas,
> When turning a user-defined numerical literal into an operator
> invocation the literal needs to be translated to the execution
> character set.
>
> Bootstrapped and regtested on s390x. x86_64 still running.
> Ok to apply if x86_64 is clean?
the new testcase FAILs on Solaris
FAIL:
Hi,
this makes sure the goto_locus present (or not) on edges is properly remapped
during inlining.
Tested on x86-64/Linux, OK for the mainline?
2018-06-26 Eric Botcazou
* tree-inline.c (remap_location): New function extracted from...
(copy_edges_for_bb): Add ID parameter.
On Tue, Jun 26, 2018 at 10:21 AM Alexandre Oliva wrote:
>
> On Jun 22, 2018, Jeff Law wrote:
>
> > On 06/12/2018 08:02 PM, Alexandre Oliva wrote:
> >>
> >> We didn't split cross-partition ranges in loclists to output a
> >> whole-function location expression, but with nonzero locviews, we
> >> fo
On Jun 22, 2018, Jeff Law wrote:
> On 06/12/2018 08:02 PM, Alexandre Oliva wrote:
>>
>> We didn't split cross-partition ranges in loclists to output a
>> whole-function location expression, but with nonzero locviews, we
>> force loclists, and then we have to split to avoid cross-partition
>> lis
On Tue, Jun 26, 2018 at 2:21 AM David Malcolm wrote:
>
> I ran into this bootstrap failure (with r262092):
>
> ../../../src/gcc/tree-vect-loop.c: In function ‘_loop_vec_info*
> vect_analyze_loop(loop*, loop_vec_info, vec_info_shared*)’:
> ../../../src/gcc/tree-vect-loop.c:1946:25: error: ‘n_stmts
On 08/06/18 13:01, Jonathan Wakely wrote:
Nothing very exciting, just adding noexcept and defaulting some
members.
* include/bits/regex.h (sub_match): Add noexcept to default
constructor and length observer.
(match_results): Add noexcept to default constructor and observers
w
57 matches
Mail list logo