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
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 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
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 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 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/
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 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 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.
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.
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
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
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 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 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 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 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 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: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, 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,
>>
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 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
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
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!
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!
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!
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!
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
[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
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
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/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/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 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 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
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 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
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 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 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 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
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 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.
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
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
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://
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
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 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
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 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
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 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 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 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
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 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
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, 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 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 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
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 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
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/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
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 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
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 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 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
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 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
73 matches
Mail list logo
