On Fri, Sep 2, 2016 at 4:46 PM, Yuri Rumyantsev wrote:
> Hi Jeff,
>
> I am trying to reduce cost of repeated call of if-conversion for
> epilogue vectorization. I'd like to clarify your recommendation -
> should I design additional support for versioning in
> vect_do_peeling_for_loop_bound or ligh
Ping.
diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c
index 2beadbc..d66fcb1 100644
--- a/gcc/gimple-match-head.c
+++ b/gcc/gimple-match-head.c
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include "internal-fn.h"
#include "case-cfn-macros.h"
#include "gimp
On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries wrote:
> On 04/09/16 16:08, Richard Biener wrote:
>>
>> On September 4, 2016 12:33:02 PM GMT+02:00, Tom de Vries
>> wrote:
>>>
>>> On 04/09/16 08:12, Richard Biener wrote:
On September 3, 2016 5:23:35 PM GMT+02:00, Tom de Vries
>>>
>>> wrot
On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah
wrote:
> Hi All,
>
> While looking at gcc source, I noticed that we are iterating over SSA
> variable from 0 to num_ssa_names in some cases and 1 to num_ssa_names
> in others. It seems that variable 0 is always NULL TREE.
Yeah, that's artific
On Fri, Sep 2, 2016 at 5:07 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, we have
> static GTY(()) vec *odr_types_ptr;
> #define odr_types (*odr_types_ptr)
> and in the else block do
> odr_types[val->id] = 0;
> first (which is actually
> (*odr_types_ptr)[val->id] = 0;
> without t
On Fri, 2 Sep 2016, Jakub Jelinek wrote:
> Hi!
>
> The two ports that use define_subst (ix86 and visium) don't do anything in
> this function, other than returning early - return insn_out, so all I could
> do is look at the intent.
> The *insn_out == '*' || *insn_out != '@' got flagged by some to
Ok, thanks. The full updated patch is below. I also removed the
'--whole-archive' thing from -static-libmpxwrappers case.
Would that be possible to backport that patch to 6 branch as well?
And could you please also address Sergey's comment on adding weak
symbol that he's made in the bugzilla?
dif
On 09/04/2016 02:12 PM, Uros Bizjak wrote:
As shown in the PR [1], combine is able to simplify lowpart
CONST_VECTOR constant pool reference to its inner-mode reference.
However, plus_constant was not able to extract the constant from
narrowed access.
Attached patch teaches plus_constant how to h
On Thu, 19 May 2016, Jeff Law wrote:
Spurred by the lack of response to Sandra's message WRT a cygwin/mingw
issue, I did a quick pass through the MAINTAINERS file for folks that
are listed as maintainers, but aren't (to the best of my knowledge)
acting in those positions anymore.
I removed th
On 09/02/2016 05:13 PM, Marek Polacek wrote:
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 87da1f1..38d55d4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5437,8 +5437,8 @@ if (a < 0 && a < 0) @{ @dots{} @}
@opindex Wlogical-not-parentheses
@opindex Wno-logical-not-parent
Hi Eric,
On Sun, Sep 04, 2016 at 10:14:22PM +0200, Eric Botcazou wrote:
> * config/aarch64/aarch64.h(TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Define
Space after ":". Many spaces are missing in the changelogs for this
series.
> Index: config/rs6000/rs6000.h
> ===
On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote:
> On 09/02/2016 05:13 PM, Marek Polacek wrote:
> > diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
> > index 87da1f1..38d55d4 100644
> > --- gcc/doc/invoke.texi
> > +++ gcc/doc/invoke.texi
> > @@ -5437,8 +5437,8 @@ if (a < 0 && a < 0
On September 5, 2016 12:11:47 PM GMT+02:00, Bernd Schmidt
wrote:
>On 09/04/2016 02:12 PM, Uros Bizjak wrote:
>> As shown in the PR [1], combine is able to simplify lowpart
>> CONST_VECTOR constant pool reference to its inner-mode reference.
>> However, plus_constant was not able to extract the co
On Sun, 4 Sep 2016, Bernd Edlinger wrote:
> good to have as well. But this code would still be suspicious
> even if (x << y) is put in parentheses, because the shift count does
> not change the result of the condition, as the integer overflow is
> undefined behavior, and if it does not have side
On Sat, 3 Sep 2016, Andreas Schwab wrote:
> On Aug 17 2016, Joseph Myers wrote:
>
> > Index: gcc/testsuite/gcc.dg/torture/float32-basic.c
> > ===
> > --- gcc/testsuite/gcc.dg/torture/float32-basic.c(nonexistent)
> > +++ gcc/test
On Sun, 4 Sep 2016, Uros Bizjak wrote:
> It looks that different handling of _Complex char, _Complex short and
> _Complex float is there on purpose. Is (was?) there a limitation in a
> c language standard that prevents passing of these arguments as
> varargs?
Well, ISO C doesn't define complex in
Hi all,
This patch adds __artificial__ attribute to the intrinsics
in arm_neon.h so that costs are associated to the user
function during profiling and during the intrinsics are
are hidden in trace.
The attribute does not affect code generation.
No new tests for this since it would require a gdb
On 1 September 2016 at 21:28, Martin Sebor wrote:
>> The attached version passes bootstrap+test on ppc64le-linux-gnu.
>> Given that it only looks if parameters are restrict qualified and not
>> how they're used inside the callee,
>> this can have false positives as in above test-cases.
>> Should t
On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
> Hi,
>
> > + r += !a == ~b;
> > + r += !a == ~(int) b;
>
> I don't understand why ~b should not be warned at -Wall.
Yeah, there was an RFE for this but I'm not finding it.
> Frankly I don't even understand why the above state
On 09/05/16 14:03, Marek Polacek wrote:
> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
>> Hi,
>>
>> > + r += !a == ~b;
>> > + r += !a == ~(int) b;
>>
>> I don't understand why ~b should not be warned at -Wall.
>
> Yeah, there was an RFE for this but I'm not finding it.
>
I
On Mon, Sep 05, 2016 at 02:08:20PM +, Bernd Edlinger wrote:
> On 09/05/16 14:03, Marek Polacek wrote:
> > On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
> >> Hi,
> >>
> >> > + r += !a == ~b;
> >> > + r += !a == ~(int) b;
> >>
> >> I don't understand why ~b should not be w
On 09/05/16 13:23, Joseph Myers wrote:
> On Sun, 4 Sep 2016, Bernd Edlinger wrote:
>
>> good to have as well. But this code would still be suspicious
>> even if (x << y) is put in parentheses, because the shift count does
>> not change the result of the condition, as the integer overflow is
>> und
Hi All,
This patch allows the FP register to be used as a call-saved
register when -fomit-frame-pointer is used.
The change is done in such a way that the defaults do not change.
To use the FP register both -fomit-frame-pointer and
-fcall-saved- need to be used.
Regression ran on aarch64-none-li
On 9/5/16, Bernd Edlinger wrote:
> On 09/05/16 14:03, Marek Polacek wrote:
>> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> > + r += !a == ~b;
>>> > + r += !a == ~(int) b;
>>>
>>> I don't understand why ~b should not be warned at -Wall.
>>
>> Yeah, there was
On 09/05/16 16:28, Marek Polacek wrote:
> On Mon, Sep 05, 2016 at 02:08:20PM +, Bernd Edlinger wrote:
>> On 09/05/16 14:03, Marek Polacek wrote:
>>> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
Hi,
> + r += !a == ~b;
> + r += !a == ~(int) b;
>
On 09/05/16 17:00, Eric Gallager wrote:
> On 9/5/16, Bernd Edlinger wrote:
>> On 09/05/16 14:03, Marek Polacek wrote:
>>> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote:
Hi,
> + r += !a == ~b;
> + r += !a == ~(int) b;
I don't understand why ~b
Hi!
I'd like to ping 3 patches from a week ago:
http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html
- PR77375 - wrong-code with mutable members in base classes
http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html
- PR77338 - fix constexpr ICE on PARM_DECL with incomplete type
http://
As discussed. I think I should ask a Global reviewer to approve this
one. For obvious reasons I haven't included the diffs to the deleted
gcc/java and libjava directories. The whole tree, post GCJ-deletion,
is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
if anyone would like
On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed. I think I should ask a Global reviewer to approve this
> one. For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories. The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/bran
On 05/09/16 16:29, Matthias Klose wrote:
> Please consider removing boehm-gc as well. The only other user is
> --enable-objc-gc, which better should use an external boehm-gc.
I can do that, but I do not want to do so with this patch.
Andrew.
Andrew Haley writes:
> As discussed. I think I should ask a Global reviewer to approve this
> one. For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories. The whole tree, post GCJ-deletion, is
> at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deleti
On 09/05/2016 12:52 PM, Marek Polacek wrote:
On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote:
On 09/02/2016 05:13 PM, Marek Polacek wrote:
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 87da1f1..38d55d4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5437,8
On 05/09/16 09:49, Richard Biener wrote:
On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries wrote:
> On 04/09/16 16:08, Richard Biener wrote:
>>
>> On September 4, 2016 12:33:02 PM GMT+02:00, Tom de Vries
>> wrote:
>>>
>>> On 04/09/16 08:12, Richard Biener wrote:
On September 3, 2016 5
On 05/09/16 17:15, Richard Biener wrote:
> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley
> wrote:
>> As discussed. I think I should ask a Global reviewer to approve this
>> one. For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories. The w
On Mon, 5 Sep 2016, Andrew Haley wrote:
> As discussed. I think I should ask a Global reviewer to approve this
> one. For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories. The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branc
On 09/05/2016 09:55 AM, Bernd Schmidt wrote:
On 09/05/2016 12:52 PM, Marek Polacek wrote:
On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote:
On 09/02/2016 05:13 PM, Marek Polacek wrote:
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 87da1f1..38d55d4 100644
--- gcc/doc/i
Hi Richard,
what do you think of this patch, is it OK (with the suggested wording)?
Thanks
Bernd.
On 08/05/16 16:06, Richard Earnshaw (lists) wrote:
> On 05/08/16 13:49, Bernd Edlinger wrote:
>> On 08/05/16 11:29, Richard Earnshaw (lists) wrote:
>>> On 04/08/16 22:16, Bernd Edlinger wrote:
On Mon, 5 Sep 2016, Marek Polacek wrote:
> Still not sure about other operations. I guess no one would
> object to warning on bool1 % bool2, but should we warn for
> bool1 + bool2?
I think boolean addition (with the result interpreted as an integer, not
converted back to boolean) is perfectly r
On Mon, 5 Sep 2016, Bernd Edlinger wrote:
> But I think the reasoning is still correct, left shifting
> in a boolean context is suspicious, even if -fwrapv may make
> it defined. Do you agree?
Well, you can argue that if you want to test whether low bits are all
zero, you should just use binary
On 09/01/2016 06:22 AM, Gerald Pfeifer wrote:
Hi Sandra,
On Wed, 29 Aug 2012, Sandra Loosemore wrote:
I've had this largish pile of random copy-edits to invoke.texi left over
from my previous passes through that file earlier this year.
that was an amazing amount of changes; I admire your pati
On 09/01/2016 01:04 PM, Gerald Pfeifer wrote:
On Wed, 29 Aug 2012, Sandra Loosemore wrote:
* doc/invoke.texi: Fix numerous typos and punctuation/grammatical
errors throughout the file. Re-word some awkward sentences and
paragraphs.
I noticed you changed return-value an
On 09/05/16 18:45, Joseph Myers wrote:
> On Mon, 5 Sep 2016, Marek Polacek wrote:
>
>> Still not sure about other operations. I guess no one would
>> object to warning on bool1 % bool2, but should we warn for
>> bool1 + bool2?
>
> I think boolean addition (with the result interpreted as an integer
On 09/02/2016 12:17 AM, Gerald Pfeifer wrote:
On Wed, 29 Aug 2012, Sandra Loosemore wrote:
* doc/invoke.texi: Fix numerous typos and punctuation/grammatical
errors throughout the file. Re-word some awkward sentences and
paragraphs.
There are three questions (and to som
[Patch version 2 adds an update to cxx_fundamental_alignment_p.]
The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in
such a way that they are basic types, meaning that max_align_t must be
at least as aligned as those types.
On 32-bit x86, max_align_t is currently 8-byte aligned
Hi!
On Fri, Aug 05, 2016 at 02:22:39PM +0200, Uros Bizjak wrote:
> 2016-08-05 Uros Bizjak
>
> * config/i386/i386.md (*zero_extendsidi2): Add (*r,*k) alternative.
> (zero_extenddi2): Ditto.
> (*zero_extendsi2): Ditto.
> (*zero_extendqihi2): Ditto.
As the PR says, unfortunately
Hi!
cxx_eval_switch_expr assumes that SWITCH_EXPR's body is always a
STATEMENT_LIST, but that doesn't have to be the case.
As the testcase shows, if there are any variable declarations in the
switch body, it can be also a BIND_EXPR, which cxx_eval_constant_expression
handles properly, and as bar i
Hi!
As the testcase shows, if we want to diagnose a md builtin not enabled in
the current ISA, we call error and then return const0_rtx. That isn't a
good choice if the result is BLKmode, which can happen for vector modes
that aren't enabled in the current ISA. In that case, returning target
is
Hi!
The recent concept changes that were also backported to 6.2 break
diagnostics e.g. on the following testcase, sometimes it ICEs during
reporting of the first error, so isn't just a normal low prio error
recovery. The thing is that on the testcase the VAR_DECL has no
DECL_LANG_SPECIFIC, DECL_D
Hi!
While it would be perhaps nice to pass explicit location_t in the target
option handling code, there are hundreds of error/warning/sorry calls
in lots of backends, and lots of those routines are used not just
for the process_options time (i.e. command line options), but also for
pragma GCC tar
Hi!
While most of the i386.opt -m= options have enum args and thus
cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also
-mrecip=) don't use that, with the CPU strings being maintained inside of a
function rather than in some *.def file that could be also sourced into the
On September 5, 2016 7:20:57 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>While it would be perhaps nice to pass explicit location_t in the
>target
>option handling code, there are hundreds of error/warning/sorry calls
>in lots of backends, and lots of those routines are used not just
>for the proc
https://gcc.gnu.org/ml/fortran/2016-08/msg00173.html
On Mon, Aug 29, 2016 at 8:36 AM, Fritz Reese wrote:
>
> https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
> On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote:
> > This patch extends the GNU Fortran front-end to add support for
> > DEC-style
On 9/5/16, Matthias Klose wrote:
> On 05.09.2016 17:13, Andrew Haley wrote:
>> As discussed. I think I should ask a Global reviewer to approve this
>> one. For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories. The whole tree, post GCJ-deletion,
>>
On Mon, Sep 5, 2016 at 7:07 PM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Aug 05, 2016 at 02:22:39PM +0200, Uros Bizjak wrote:
>> 2016-08-05 Uros Bizjak
>>
>> * config/i386/i386.md (*zero_extendsidi2): Add (*r,*k) alternative.
>> (zero_extenddi2): Ditto.
>> (*zero_extendsi2): Ditto.
>>
On 9/5/16, Gerald Pfeifer wrote:
> On Mon, 5 Sep 2016, Andrew Haley wrote:
>> As discussed. I think I should ask a Global reviewer to approve this
>> one. For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories. The whole tree, post GCJ-deletion,
>> i
On Mon, Sep 5, 2016 at 7:14 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, if we want to diagnose a md builtin not enabled in
> the current ISA, we call error and then return const0_rtx. That isn't a
> good choice if the result is BLKmode, which can happen for vector modes
> that aren'
On Mon, Sep 5, 2016 at 7:25 PM, Jakub Jelinek wrote:
> Hi!
>
> While most of the i386.opt -m= options have enum args and thus
> cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also
> -mrecip=) don't use that, with the CPU strings being maintained inside of a
> function r
On 05/09/16 18:25, Jakub Jelinek wrote:
Hi!
While most of the i386.opt -m= options have enum args and thus
cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also
-mrecip=) don't use that, with the CPU strings being maintained inside of a
function rather than in some *.de
On Sat, Sep 3, 2016 at 12:46 PM, Mikhail Strelnikov wrote:
> Hello,
>
> Following code does not compile,
>
> #include
>
> namespace n
> {
> template
> void operator&(T) {}
> struct s{};
> }
>
> int main()
> {
> std::variant v;
> std::get(v);
> }
>
> error: include/c++/7.0.0/var
On Mon, Sep 05, 2016 at 08:42:37PM +0100, Manuel López-Ibáñez wrote:
> Something like the following should avoid a lot of (future) duplication
> (untested):
You're right. I've missed that I actually push the candidates into a vector
anyway, so the concatenation can be done in a common code.
> I
On 05/09/16 20:42, Manuel López-Ibáñez wrote:
On 05/09/16 18:25, Jakub Jelinek wrote:
Hi!
While most of the i386.opt -m= options have enum args and thus
cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also
-mrecip=) don't use that, with the CPU strings being maintaine
On 09/05/16 21:23, Denis Campredon wrote:
> Hi,
> Your patch does not emit warning for the following case:
> void f(int j){bool i = j ?: 3;}
>
> But for emit one for
> void f(){bool i = 4 ?: 2;}
> Regards
>
Yes, good point.
It is probably not completely unrealistic
that the middle expression may
2016-09-05 12:56 GMT+03:00 Alexander Ivchenko :
> Ok, thanks. The full updated patch is below. I also removed the
> '--whole-archive' thing from -static-libmpxwrappers case.
This version is OK for trunk with proper ChangeLog and after proper testing.
> Would that be possible to backport that patc
Hi!
Upstream has accepted my fix, so I've cherry-picked it to trunk and added
another testcase, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2016-09-05 Jakub Jelinek
PR sanitizer/77396
* asan/asan_globals.cc: Cherry-pick upstream r280657.
Hi!
I've noticed the comment in check_effective_target_vect_simd_clones
doesn't match the reality, fixed thusly, committed to trunk as obvious.
2016-09-05 Jakub Jelinek
* lib/target-supports.exp (check_effective_target_vect_simd_clones):
Update comment to mention also avx512f.
On Mon, Sep 5, 2016 at 4:53 AM, Tamar Christina wrote:
> Hi all,
>
> This patch adds __artificial__ attribute to the intrinsics
> in arm_neon.h so that costs are associated to the user
> function during profiling and during the intrinsics are
> are hidden in trace.
>
> The attribute does not affec
Hi,
I've noticed that there is already a -Wparentheses warning for code like
int y = x == 2 ?: 1
=> warning: the omitted middle operand in ?: will always be 'true',
suggest explicit middle operand [-Wparentheses]
But it is not emitted for code that uses bool, like:
void foo(bool x)
{
int
On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed. I think I should ask a Global reviewer to approve this
> one. For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories. The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/
On Sep 4, 2016, at 10:23 AM, Dominique d'Humières wrote:
>
> The same should apply to g++.dg/debug/dwarf2/template-params-12g.C:
>
> --- ../_clean/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C
> 2016-08-12 09:59:34.0 +0200
> +++ gcc/testsuite/g++.dg/debug/dwarf2/template-param
On Mon, 2016-09-05 at 21:00 +0200, Uros Bizjak wrote:
> On Mon, Sep 5, 2016 at 7:25 PM, Jakub Jelinek
> wrote:
> > Hi!
> >
> > While most of the i386.opt -m= options have enum args and thus
> > cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy=
> > (and also
> > -mrecip=) don't
On 9/5/16, Bernd Edlinger wrote:
> On 05.09.2016 17:13, Andrew Haley wrote:
> > As discussed. I think I should ask a Global reviewer to approve this
> > one. For obvious reasons I haven't included the diffs to the deleted
> > gcc/java and libjava directories. The whole tree, post GCJ-deletio
Hi Richard,
On 5 September 2016 at 17:57, Richard Biener wrote:
> On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah
> wrote:
>> Hi All,
>>
>> While looking at gcc source, I noticed that we are iterating over SSA
>> variable from 0 to num_ssa_names in some cases and 1 to num_ssa_names
>> in
On 23 August 2016 at 17:17, Ville Voutilainen
wrote:
> Tested on Linux-x64.
>
> N.B. I know that the assignment operators have constraints in template
> parameters, I want to move them to the return type separately.
>
> N.B2. This fixes the bug for std::optional only; I plan to port the fix
> to s
73 matches
Mail list logo
