Hello Everyone,
This patch will pass in "-L" 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 committed as obvious.
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 t
Ping. Is it ok for x86 maintainer?
Thanks,
Wei Mi.
On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi 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 ok
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 fo
On Fri, Nov 1, 2013 at 6:00 PM, Jeff Law 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 time to debu
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
* g++.dg/asan/asan_test.cc: Update the test
to match the fresh asan run-time.
* c-c++-common/
> > 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
On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
> 2013-10-XX Kostya Serebryany
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 function.
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 (gi
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 wo
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 Nov 1, 2013, at 12:45 PM, Jeff Law 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. :-)
From: tbsaunde
diff --git a/ChangeLog b/ChangeLog
index e925959..8c24d35 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-11-01 Trevor Saunders
+
+* MAINTAINERS (Write After Approval): Add myself.
+
2013-10-30 Jason Merrill
* Makefile.tpl (STAGE1_CONFIGURE_FLAGS): Pas
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.
On 11/01/13 14:39, David Edelsohn wrote:
On Fri, Nov 1, 2013 at 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 d
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
fru
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)
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
! gimple_call_set_lh
On Nov 1, 2013, at 1:50 PM, Steve Ellcey wrote:
> Yes, mingw does have sys/time.h, but their sys/time.h includes
> 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,
some bugs know it's
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 l
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',
cpplib-4.8.0.tr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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 a
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
l
On Fri, 2013-11-01 at 13:45 -0700, Mike Stump wrote:
> On Nov 1, 2013, at 12:56 PM, Steve Ellcey 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
Hi,
> Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely
> 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 inline.
Paolo
On Nov 1, 2013, at 12:56 PM, Steve Ellcey 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 sys/time.h? If so,
On Fri, Nov 1, 2013 at 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 t
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
OK.
Jason
On Fri, Nov 1, 2013 at 3:51 PM, Diego Novillo wrote:
> It must've been whitespace then. Your new patch applied just fine.
> I'll be committing shortly.
Committed at r204301.
Diego.
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)))
+cp_pars
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 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 we might want to mo
On Fri, 2013-11-01 at 12:43 -0700, Mike Stump wrote:
> On Nov 1, 2013, at 10:47 AM, Steve Ellcey 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
On Fri, Nov 1, 2013 at 3:33 PM, Trevor Saunders 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
> merging. Pat
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 re
On Nov 1, 2013, at 10:47 AM, Steve Ellcey 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 in my canad
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 d
> 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
On Thu, Oct 31, 2013 at 7:48 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> This patch is pretty dull, it just replaces a bunch of things of the form
> vec x;
> x.create (N); // N is a constant
> blah blah
> x.release ();
> by
> stack_vec x;
> blah blah
>
> Of course its even nicer than that in
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
> >+ declaration
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 HA
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
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 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 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 when
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
inde
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. */
+ stabilize_vla_si
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,
> SIMD_
-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 t
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
PR fortran/57445
* trans-expr.c (gfc_conv_class_to_class): Remove
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. But
On Thu, Oct 31, 2013 at 4:06 PM, David Malcolm 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 various preprocessor
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 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 http://gcc.gnu.org/bu
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 11/01/2013 09:31 AM, Richard Sandiford wrote:
Kenneth Zadeck 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 po
Kenneth Zadeck 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 all the differenc
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 g
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
> + LINEAR_STRIDE_Y
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
>>>
>>>N3421 C++1y Transparent functors
>>>* include/bits/stl_function.h (plus, minus,
>>>multip
On 1 November 2013 11:28, Marc Glisse wrote:
> On Fri, 1 Nov 2013, Jonathan Wakely wrote:
>
>> 2013-11-01 Jonathan Wakely
>>
>>N3421 C++1y Transparent functors
>>* include/bits/stl_function.h (plus, minus,
>>multiplies, divides, modulus, negate,
>>equal_to, not_eq
On Fri, 1 Nov 2013, Jonathan Wakely wrote:
2013-11-01 Jonathan Wakely
N3421 C++1y Transparent functors
* include/bits/stl_function.h (plus, minus,
multiplies, divides, modulus, negate,
equal_to, not_equal_to, greater, less,
greater_equal, less_equal, logica
Hi,
a simple, very old, oversight. Committed mainline and 4_8-branch.
Thanks,
Paolo.
//
2013-11-01 Paolo Carlini
PR libstdc++/58952
* include/c_global/cstdio: Undef getchar.
Index: include/c_global/cstdio
==
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!
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
is_reassociable
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 wor
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
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 b
Hello!
... so it can be used in insn output templates.
2013-11-01 Uros Bizjak
* 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 check.
(*movdf_
On Fri, Nov 1, 2013 at 3:03 AM, Cong Hou 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: usad_optab and
71 matches
Mail list logo
