On Fri, Nov 1, 2013 at 3:03 AM, Cong Hou co...@google.com wrote:
According to your comments, I made the following modifications to this patch:
1. Now SAD pattern does not require the first and second operands to
be unsigned. And two versions (signed/unsigned) of the SAD optabs are
defined:
Hello!
... so it can be used in insn output templates.
2013-11-01 Uros Bizjak ubiz...@gmail.com
* configure.ac (HAVE_AS_IX86_INTERUNIT_MOVQ): Always define as 0/1.
* configure: Regenerate.
* config/i386/i386.md (*movdi_internal): Change
HAVE_AS_IX86_INTERUNIT_MOVQ to runtime
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all the differences I saw
for alpha-linux-gnu in gcc.c-torture.
Hunk 1: Preserve the current trunk
On Fri, Nov 01, 2013 at 02:03:52AM +, Cong Hou wrote:
3. Add the document for SAD_EXPR.
I think this patch should also document the new Standard Names usad and
ssad in doc/md.texi?
Your Changelog is missing the change to doc/generic.texi.
Thanks,
James
Hi!
On Thu, Oct 31, 2013 at 10:04:45PM -0500, Aldy Hernandez wrote:
Hello gentlemen. I'm CCing all of you, because each of you can
provide valuable feedback to various parts of the compiler which I
touch. I have sprinkled love notes with your names throughout the
post :).
Thanks for
Hi!
My recent reassoc patch caused following regression (though, it only started
failing on this testcase with Andrew's ifcombine changes).
The issue is that update_ops relies on walking the same stmts as get_ops
did, and uses has_single_uses (either directly or indirectly through
This implements another piece of the C++14 library, STL's transparent
functors proposal. I also added the is_transparent typedefs, which
come from another proposal but modify these diamond operators. I
hope to get round to using those typedefs to implement Joaquin's
heterogeneous lookup soon.
Hi,
a simple, very old, oversight. Committed mainline and 4_8-branch.
Thanks,
Paolo.
//
2013-11-01 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/58952
* include/c_global/cstdio: Undef getchar.
Index: include/c_global/cstdio
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid, negatevoid,
equal_tovoid, not_equal_tovoid,
On 1 November 2013 11:28, Marc Glisse wrote:
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
multipliesvoid, dividesvoid, modulusvoid,
On 1 November 2013 11:48, Jonathan Wakely wrote:
On 1 November 2013 11:28, Marc Glisse wrote:
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely jwakely@gmail.com
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plusvoid, minusvoid,
Hi!
One more thing:
On Thu, Oct 31, 2013 at 10:04:45PM -0500, Aldy Hernandez wrote:
+enum linear_stride_type {
+ LINEAR_STRIDE_NO,
+ LINEAR_STRIDE_YES_CONSTANT,
+ LINEAR_STRIDE_YES_VARIABLE
+};
...
+ /* If the linear stride is a constant, `linear_stride' is
+
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all the differences I saw
for alpha-linux-gnu in
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes
On 11/01/2013 09:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
On 10/31/2013 07:03 PM, Marc Glisse wrote:
* pt.c (value_dependent_expression_p): Handle null argument.
What is calling this with a null argument? The recursive call near the
end of the function checks for null there.
Jason
On Fri, 1 Nov 2013, Jason Merrill wrote:
On 10/31/2013 07:03 PM, Marc Glisse wrote:
* pt.c (value_dependent_expression_p): Handle null argument.
What is calling this with a null argument? The recursive call near the end
of the function checks for null there.
See
On 11/01/2013 11:13 AM, Marc Glisse wrote:
position). I can make it not call value_dependent_expression_p with a
null argument, but it seems more general to let
value_dependent_expression_p handle 0 like a number of other functions
already do.
OK. But the change is to type_..., not value_...,
On Thu, Oct 31, 2013 at 4:06 PM, David Malcolm dmalc...@redhat.com wrote:
It's possible to run GCC's sources through Doxygen by setting
INPUT_FILTER = contrib/filter_gcc_for_doxygen
within contrib/gcc.doxy and invoking doxygen on the latter file.
The script filters out
On Fri, 1 Nov 2013, Jason Merrill wrote:
On 11/01/2013 11:13 AM, Marc Glisse wrote:
position). I can make it not call value_dependent_expression_p with a
null argument, but it seems more general to let
value_dependent_expression_p handle 0 like a number of other functions
already do.
OK.
Dear All,
This one is trivial. The ICE was caused by an assert that turns out
to be spurious and has been removed.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
Cheers
Paul
2013-11-01 Paul Thomas pa...@gcc.gnu.org
PR fortran/57445
* trans-expr.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since part of it was to go into c-family (as per Joseph S. Myers's
email) and parts are not in c-family, I split the changelog into three
parts. I also changed the formatting of the changelog and patch as
per Dodji's comments. The attached patch is
On Fri, Nov 01, 2013 at 01:35:35PM +0100, Jakub Jelinek wrote:
So, IMHO much better would be to have an enum simd_clone_arg_type which
would be
enum simd_clone_arg_type
{
SIMD_CLONE_ARG_TYPE_VECTOR,
SIMD_CLONE_ARG_TYPE_UNIFORM,
SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP,
On 10/31/2013 02:28 PM, Marek Polacek wrote:
/* A variable sized array. */
itype = variable_size (itype);
+
+ /* We need to stabilize side-effects in VLA sizes for regular array
+declarations too, not just pointers to arrays. */
+
While working on a canadian cross build I ran into a problem with the
type of clock_t. If HAVE_CLOCK_T is not defined timevar.c defines
it to be int. I think the type should be long. I am using the mingw
compilers on linux in my canadian cross build and HAVE_CLOCK_T is not
getting set but
It seems that on some platforms the loops in
testsuite/gcc.dg/vect/pr58508.c may be unable to be vectorized. This
small patch added { dg-require-effective-target vect_int } to make
sure all loops can be vectorized.
thanks,
Cong
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
On 10/31/2013 03:07 PM, Paolo Carlini wrote:
... I understand that at this point likely this isn't 4.9 material anymore.
I think it's fine for 4.9, we're still in stage 1.
The revised patch is OK.
Jason
While doing a canadian cross build I ran into a problem with the caddr_t
type. configure.ac is using an obsolete version of AC_CHECK_TYPE to
create #define's of caddr_t and ssize_t if they are not defined by the
system. In addition to using an obsolete version of AC_CHECK_TYPE this
was causing a
On Fri, Nov 01, 2013 at 11:15:02AM -0700, Steve Ellcey wrote:
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1060,6 +1060,14 @@ helper_const_non_const_cast (const char *p)
#define DEBUG_VARIABLE
#endif
+#ifndef HAVE_CADDR_T
+typedef char *caddr_t;
+#endif
+
+#ifndef HAVE_SSIZE_T
On Fri, 2013-11-01 at 19:22 +0100, Marek Polacek wrote:
On Fri, Nov 01, 2013 at 11:15:02AM -0700, Steve Ellcey wrote:
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1060,6 +1060,14 @@ helper_const_non_const_cast (const char *p)
#define DEBUG_VARIABLE
#endif
+#ifndef HAVE_CADDR_T
On Fri, Nov 01, 2013 at 01:35:07PM -0400, Jason Merrill wrote:
On 10/31/2013 02:28 PM, Marek Polacek wrote:
/* A variable sized array. */
itype = variable_size (itype);
+
+ /* We need to stabilize side-effects in VLA sizes for regular array
+ declarations too, not
On Thu, Oct 31, 2013 at 7:48 PM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
This patch is pretty dull, it just replaces a bunch of things of the form
vecT x;
x.create (N); // N is a constant
blah blah
x.release ();
by
stack_vecT, N x;
blah blah
Of
The patch is OK, but it did not completely apply in my tree. Mind
sending an updated version (or point me at a git repo I can pull it
from).
interesting, I just pulled and rebased it onto r204296 without any manual
merging. Patch against r204296 attached (obviously haven't tested it
against
After discussing this for Richard S at some length today, I want to
withdraw this for now and re-examine the issue. I don't feel I
understand this as well as I thought I did... ;)
Thanks,
Bill
On Thu, 2013-10-31 at 21:06 -0500, Bill Schmidt wrote:
Hi maintainers,
I agree with David that
On Nov 1, 2013, at 10:47 AM, Steve Ellcey sell...@mips.com wrote:
While working on a canadian cross build I ran into a problem with the
type of clock_t. If HAVE_CLOCK_T is not defined
timevar.c defines it to be int. I think the type should be long. I am using
the mingw
compilers on linux
On 10/31/13 14:03, Robert Suchanek wrote:
Hi David,
No, I do not have read/write SVN access. I know a person who could commit the
patch for me, however, if you can commit it, I'd be grateful.
Note, I didn't see anywhere in this thread an indication this test had
been through a bootstrap and
On Fri, Nov 1, 2013 at 3:33 PM, Trevor Saunders tsaund...@mozilla.com wrote:
The patch is OK, but it did not completely apply in my tree. Mind
sending an updated version (or point me at a git repo I can pull it
from).
interesting, I just pulled and rebased it onto r204296 without any manual
On Fri, 2013-11-01 at 12:43 -0700, Mike Stump wrote:
On Nov 1, 2013, at 10:47 AM, Steve Ellcey sell...@mips.com wrote:
While working on a canadian cross build I ran into a problem with the
type of clock_t. If HAVE_CLOCK_T is not defined
timevar.c defines it to be int. I think the type
Doh, that had yesterday's date on the ChangeLog entry, I've just fixed
it with the next commit.
On 1 November 2013 20:09, Jonathan Wakely jwakely@gmail.com wrote:
Here's the final version of Luc's optional implementation that I'm
committing, tested on x86_64-linux.
(It occurs to me that
On 10/18/2013 02:48 PM, Aldy Hernandez wrote:
This has the potential of throwing my mind for a spin. Can I do this as
a followup, and keep it simple for now?
Sure.
+ else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (e)))
+
On Fri, Nov 1, 2013 at 3:51 PM, Diego Novillo dnovi...@google.com wrote:
It must've been whitespace then. Your new patch applied just fine.
I'll be committing shortly.
Committed at r204301.
Diego.
OK.
Jason
On 11/01/2013 03:10 PM, Marek Polacek wrote:
+ /* We need to stabilize side-effects in VLA sizes for regular array
+declarations too, not just pointers to arrays. */
This comment isn't really relevant to its new location. :)
OK with that removed.
Jason
On Fri, Nov 1, 2013 at 3:45 PM, Jeff Law l...@redhat.com wrote:
On 10/31/13 14:03, Robert Suchanek wrote:
Hi David,
No, I do not have read/write SVN access. I know a person who could commit
the patch for me, however, if you can commit it, I'd be grateful.
Note, I didn't see anywhere in
On Nov 1, 2013, at 12:56 PM, Steve Ellcey sell...@mips.com wrote:
You should report a bug to them and have them define clock_t.
They are defining clock_t, but for some reason the GCC configure is not
seeing it (perhaps because of what header files get included).
Curious, do you have
Hi,
Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely
jwakely@gmail.com ha scritto:
Here's the final version of Luc's optional implementation that I'm
committing, tested on x86_64-linux.
Great. Just noticed a minor nit: the fallback __constexpr_addressof appears not
to be
On Fri, 2013-11-01 at 13:45 -0700, Mike Stump wrote:
On Nov 1, 2013, at 12:56 PM, Steve Ellcey sell...@mips.com wrote:
You should report a bug to them and have them define clock_t.
They are defining clock_t, but for some reason the GCC configure is not
seeing it (perhaps because of what
libgcov.c is the main file to generate libgcov.a. This single source generates
21 object files and then archives to a library. These objects are of
very different purposes but they are in the same file guarded by various macros.
The source file becomes quite large and its readability becomes very
On 10/31/2013 12:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.
Mostly orthogonal
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Turkish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/tr.po
(This file,
cpplib-4.8.0.tr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
coordina...@translationproject.org
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
On Nov 1, 2013, at 1:50 PM, Steve Ellcey sell...@mips.com wrote:
Yes, mingw does have sys/time.h, but their sys/time.h includes time.h
so it should work. And now when I try to reproduce the problem it seems
to work.
:-) Don't worry, when I was in getting my degree, I helped out in the lab,
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
gimple_set_op (gs, 0, lhs);
to
static inline void
!
On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote:
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
The
On Thu, 31 Oct 2013, Ilya Enkovich wrote:
* tree-chkp.c: New.
This file includes tm.h. Inclusion of tm.h in front-end and GIMPLE files
is discouraged (well, we'd like to convert all target macros to hooks, but
the limited subset used in front-end and GIMPLE files are lower-hanging
On 11/01/13 14:39, David Edelsohn wrote:
On Fri, Nov 1, 2013 at 3:45 PM, Jeff Law l...@redhat.com wrote:
On 10/31/13 14:03, Robert Suchanek wrote:
Hi David,
No, I do not have read/write SVN access. I know a person who could commit
the patch for me, however, if you can commit it, I'd be
On Thu, 31 Oct 2013, Ilya Enkovich wrote:
This patch adds support Pointer Bounds Checker into c-family and LTO
front-ends. The main purpose of changes in front-end is to register all
statically initialized objects for checker. We also need to register
such objects created by compiler.
From: tbsaunde tbsaunde@138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/ChangeLog b/ChangeLog
index e925959..8c24d35 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-11-01 Trevor Saunders tsaund...@mozilla.com
+
+* MAINTAINERS (Write After Approval): Add myself.
+
2013-10-30
On Nov 1, 2013, at 12:45 PM, Jeff Law l...@redhat.com wrote:
Vlad, when approving patches, please make sure they've been through the usual
bootstrap and regression testing procedures.
I usually place the blame on the person committing it, as they broke it. :-)
Hello,
the issue was described in the PR and the message linked from there.
ao_ref_init_from_ptr_and_size calls get_ref_base_and_extent, which may
detect an array_ref of variable index, but ao_ref_init_from_ptr_and_size
never learns of it and uses the offset+size as if they were meaningful.
On Fri, 2013-11-01 at 17:36 -0400, Andrew MacLeod wrote:
On 10/31/2013 12:26 PM, David Malcolm wrote:
[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I
On Fri, 2013-11-01 at 22:57 +0100, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote:
On 11/01/2013 05:41 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:36:34PM -0400, Andrew MacLeod wrote:
static inline void
! gimple_call_set_lhs (gimple gs, tree
On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
2013-10-XX Kostya Serebryany k...@google.com
It is November now ;)
Looks good to me, except for a few ChangeLog issues:
Update to match the changed asan API.
* asan.c:
(asan_function_start): New
It is a start, but it doesnt do the rest of the work that needs doing to
really take advantage of it... which will be extensive.
for instance, we should change:
static inline void
! gimple_call_set_lhs (gimple gs, tree lhs)
{
- GIMPLE_CHECK (gs, GIMPLE_CALL);
Fixed all.
I'll commit on Monday so that I can respond to any failures if they
appear quickly.
Thanks!
--kcc
=== gcc/testsuite/ChangeLog
2013-11-04 Kostya Serebryany k...@google.com
* g++.dg/asan/asan_test.cc: Update the test
to match the fresh asan run-time.
On Fri, Nov 1, 2013 at 6:00 PM, Jeff Law l...@redhat.com wrote:
I'm not in a rush to revert... I don't plan on doing anything on the trunk
over the weekend. I'm comfortable waiting until Monday, both to see if
anyone else trips over whatever is going wrong and to give Robert or anyone
else
Hello,
As $SUBJECT. The assert for this has been in place for several months
now without triggering any issues, so I'd like to make this next step
before stage1 is over.
OK for trunk?
Ciao!
Steven
* rtlanal.c (tablejump_p): Expect a JUMP_TABLE_DATA to always follow
immediately after a label
Ping. Is it ok for x86 maintainer?
Thanks,
Wei Mi.
On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi w...@google.com wrote:
Go ahead and consider that pre-approved. Just send it to the list with a
note that I approved it in this thread.
Jeff
Thanks! The new patch addressed Jeff's comments.
Is it
On 11/1/2013, 3:45 PM, Jeff Law wrote:
On 10/31/13 14:03, Robert Suchanek wrote:
Hi David,
No, I do not have read/write SVN access. I know a person who could
commit the patch for me, however, if you can commit it, I'd be grateful.
Note, I didn't see anywhere in this thread an indication this
Hello Everyone,
This patch will pass in -Llibcilkrts_path to all the Cilk keywords
testsuite files. This patch should Pass all the Cilk keywords tests failing in
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00083.html. Tested no x86_64
SUSE machine (-m32 and -m64 mode) It is
71 matches
Mail list logo
