On Tue, Dec 17, 2013 at 06:19:43AM +0100, Andreas Tobler wrote:
> The below patch allows me to get back to normal, means zero unexpected
> fails, on FreeBSD. The patch has been tested on Linux/x86 as well, no
> regressions.
On Linux, mkostemp performs on flags:
(flags & ~O_ACCMODE) | O_RDWR | O_CR
2013/12/13 Chung-Ju Wu :
> 2013/12/11 Monk Chiang :
>> Hi,
>>
>> Recently I used --target=nds32be-elf to configure nds32 gcc,
>> it seems that the big endian is not set as default.
>>
> [...]
>>
>> The following is the patch to fix this issue. Tested on nds32be-elf.
>>
>> OK to apply?
>>
>> Index:
On Mon, Dec 16, 2013 at 11:12:40PM +0100, Jakub Jelinek wrote:
> When testing the patch the overflow-2.c testcase didn't exist yet,
> nor was ubsan on -m32 actually ever reporting overflows on the DImode
> multiplication (it simply expanded it as normal DImode multiplication with
> no overflow chec
On Tue, Dec 17, 2013 at 03:51:14AM +, Iyer, Balaji V wrote:
> Hi Jakub,
> I will work on this, but I need a couple clarifications about some of
> your comments. Please see below:
>
> > > +#define CILK_SIMD_FN_CLAUSE_MASK \
> > > + ( (OMP_CLAUSE_MASK_1 << PRA
Hi all,
This commit http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg00376.html
uses the mkostemp function call. On FreeBSD 10.0 and up we have this
function too. But the function denies to accept other flags than the
ones mentioned in the man page.
From:
http://www.freebsd.org/cgi/man.cgi?query=mktemp&a
Ping x3.
On 13/12/10 12:57 PM, Chung-Lin Tang wrote:
> Ping x2.
>
> On 2013/12/5 12:19 PM, Chung-Lin Tang wrote:
>> Ping.
>>
>> On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
>>> Hi Bernd,
>>> I've updated the patch again, please see if it looks fit for approval
>>> now. Including ChangeLog again
> Yes, I figured that was the original idea behind it, but the final family of
> the jaguar processors seems to have become 16h instead of 14h (bobcat) at
> some point.
Yes. It is amdfam16h. I was supposed to pass on some comments on the patch.
1. Amdfam16h for Jaguar.
2. For Jaguar, the priorit
Hi Jakub,
I will work on this, but I need a couple clarifications about some of
your comments. Please see below:
> > +#define CILK_SIMD_FN_CLAUSE_MASK \
> > + ( (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_SIMDLEN)
> \
> > + | (OMP_CLAUSE_MASK_1 << PR
>
> > - return (gimple_omp_subcode (g) & GF_OMP_FOR_COMBINED) != 0;
> > + return (gimple_omp_for_kind (g) == GF_OMP_FOR_COMBINED);
>
> I don't really know this code, but this change seems unlikely to be correct.
> Can you explain it?
I really need help on this. I need a new enum type (I call t
Here are some soft merge conflict resolutions….
Ok?
Index: ChangeLog.wide-int
===
--- ChangeLog.wide-int (revision 206027)
+++ ChangeLog.wide-int (working copy)
@@ -340,6 +340,9 @@
* hooks.c
(hook_bool_dint_dint_uin
The buffer was too small… The print routines when printing in hex, use the
precision to form the output, and negative numbers have a few more s in
front than we might otherwise expect for the largest in on the machine.
Ok?
diff --git a/gcc/wide-int-print.h b/gcc/wide-int-print.h
index be93c
On 12/13/2013, 8:07 AM, Yvan Roux wrote:
Thanks for your help Vlad. Another bad news about this PR fix, is
that it has resurrected the thumb_movhi_clobber bug (PR 58785) but in
a different manner as the original failing testcase still pass. I
attached a testcase to be compiled with :
cc1 -mthu
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in gcov-io.c.
gcov_rewrite is petty much libgcov runtime implementation details so I
think it should be moved out. gcov_write_summary is not related to
gcov lo
> I think so -- they are private to libgcov. Honza, what do you think?
Hmm, the purpose of gcov-io was to be low level IO library for the basic
gcov file format. I am not sure if gcov_write_tag_length should really resist
in other file than gcov_write_tag.
I see a desire to isolate actual stdio
On Mon, Dec 16, 2013 at 01:50:09PM -0800, H.J. Lu wrote:
> On Mon, Dec 16, 2013 at 1:44 PM, Dominique Dhumieres
> wrote:
> >> I got ...
> >
> > me too on x86_64-apple-darwin13 with -m32 (gcc and g++).
> > r206009 is OK, r206026 is not.
> >
>
> Mine is r206017 is OK and r206027 is bad. The change
>> attached is a close-to-trivial patch which rejects the declaration of
>> 'abstract procedure pointers' (which is not a valid Fortran concept),
>> and thereby fixes an ICE-on-invalid.
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Looks good to me. Thanks for the patch!
Thanks! C
> must be introduced between r2060178 and r206026.
Likely r206026.
The ICE is
/opt/gcc/work/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:136:30: internal
compiler error: in gen_lowpart_general, at rtlhooks.c:51
/opt/gcc/work/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29: note: in
defini
On Mon, Dec 16, 2013 at 09:41:43PM +, Iyer, Balaji V wrote:
> --- gcc/c/c-parser.c (revision 205759)
> +++ gcc/c/c-parser.c (working copy)
> @@ -208,6 +208,12 @@
>/* True if we are in a context where the Objective-C "Property attribute"
> keywords are valid. */
>BOOL_BITFIELD o
I think so -- they are private to libgcov. Honza, what do you think?
thanks,
David
On Mon, Dec 16, 2013 at 1:17 PM, Teresa Johnson wrote:
> On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li
> wrote:
>> gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
>> Should it be move
On Mon, Dec 16, 2013 at 1:44 PM, Dominique Dhumieres wrote:
>> I got ...
>
> me too on x86_64-apple-darwin13 with -m32 (gcc and g++).
> r206009 is OK, r206026 is not.
>
Mine is r206017 is OK and r206027 is bad. The change
must be introduced between r2060178 and r206026.
--
H.J.
> I got ...
me too on x86_64-apple-darwin13 with -m32 (gcc and g++).
r206009 is OK, r206026 is not.
Dominique
Hi Jakub,
Attached, please find a fixed patch. I have also answered your
questions below. Is this Ok for trunk/branch?
Here are the ChangeLog entries:
Gcc/ChangeLog
2013-12-16 Balaji V. Iyer
* omp-low.c (simd_clone_clauses_extract): Replaced the string
"cilk s
On Sat, Dec 14, 2013 at 5:23 AM, Jakub Jelinek wrote:
> On Sat, Dec 14, 2013 at 02:20:05PM +0100, Marek Polacek wrote:
>> This adds two sanity tests for signed-integer-overflow sanitization.
>> One variant uses asms to prevent ccp/... from optimizing away the
>> computations. Nothing in these tes
On 12/15/2013 07:40 PM, Iyer, Balaji V wrote:
- tree clauses, tree *cclauses)
+ tree clauses_or_grain, tree *cclauses)
Instead of this, please make the grainsize a new type of clause.
- return (gimple_omp_subcode (g) & GF_OMP_FOR_COMBINED) != 0;
+ r
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li wrote:
> gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
> Should it be moved from common file gcov-io.c to libgcov.c?
Possibly. I just looked through gcov-io.c and there are several
additional functions that are only defined
Janus Weil wrote:
attached is a close-to-trivial patch which rejects the declaration of
'abstract procedure pointers' (which is not a valid Fortran concept),
and thereby fixes an ICE-on-invalid.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Looks good to me. Thanks for the patch!
[In
(Sorry for my very brief reply the other day, I was on my phone and so
using gmail is a pain.)
On 16 December 2013 04:22, Hans-Peter Nilsson wrote:
>> From: Hans-Peter Nilsson
>> Date: Sun, 15 Dec 2013 15:20:48 +0100
>
>> +// { dg-options "-std=gnu++0x -DSAMPLES=3" { target { { arm*-* } &&
>
On 12/16/13 11:43, Jakub Jelinek wrote:
On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote:
It can be the last thing, sure. I think the still unimplemented and
potentially useful are the floating point overflow sanitization (haven't
looked yet what exactly it is, I suppose casts from
gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
Should it be moved from common file gcov-io.c to libgcov.c?
David
On Thu, Dec 12, 2013 at 12:11 PM, Teresa Johnson wrote:
> On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson wrote:
>> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka
On Monday 16 December 2013, Gopalasubramanian, Ganesh wrote:
> > Btw, I couldn't find anything that corresponds to gcc's btver2 arch. Is
> > that an old term for what has become the Jaguar architecture?
>
> Yes, "btver2" = "jaguar". We have the name as per its family name (i.e,
> bobcat family) in
Hi all,
attached is a close-to-trivial patch which rejects the declaration of
'abstract procedure pointers' (which is not a valid Fortran concept),
and thereby fixes an ICE-on-invalid.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
[In principle the ICE is a regression, but I don't think t
This patch from Chris Manghane uses the backend interface for references
to struct fields. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2013-12-16 Chris Manghane
* go-gcc.cc (Gcc_backend::struct_field_expression): New function.
Index:
2013/12/16 Jakub Jelinek :
> On Fri, Dec 06, 2013 at 06:06:14PM +0100, Kai Tietz wrote:
>> --- config/i386/i386.c(Revision 205719)
>> +++ config/i386/i386.c(Arbeitskopie)
>> @@ -10934,18 +10937,21 @@ ix86_expand_prologue (void)
>> }
>>m->fs.sp_offset += allocate;
>>
>> + /
Comitted.
2013-12-16 Markus Trippelsdorf
* MAINTAINERS (Write After Approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index a3255aff5d64..410f96cb323c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -545,6 +545,7 @@ Kresten Krab Thorup k...@gcc.gnu.or
On 12/16/2013 01:37 PM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck
On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote:
> It can be the last thing, sure. I think the still unimplemented and
> potentially useful are the floating point overflow sanitization (haven't
> looked yet what exactly it is, I suppose casts from floating point to
> integers where t
On Dec 13, 2013, at 11:16 AM, Mike Stump wrote:
> Here are some soft merge conflict resolutions….
>
> I've checked them in to fix the build.
So, this let's us get farther…
Ok?
Index: ChangeLog.wide-int
===
--- ChangeLog.wide-int
On Mon, Dec 16, 2013 at 11:25:33AM -0700, Jeff Law wrote:
> As you note, there's some question as to whether or not this should
> be acceptable for 4.9. Yes it's well contained, but we really need
> to draw the line. Is this the last thing for the sanitizers that is
> still under consideration?
Kenneth Zadeck wrote:
>On 12/16/2013 09:37 AM, Richard Biener wrote:
>> Kenneth Zadeck wrote:
>>> On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> it is certa
On Mon, Dec 16, 2013 at 09:13:41AM -0700, Jeff Law wrote:
> On 12/13/13 12:42, Aldy Hernandez wrote:
> >I'm fixing something completely unrelated, and noticed this...
> >
> >Perhaps I'm missing something, but why do we need a gate when it always
> >returns true? Now that we have this `pass_data' b
On 12/14/13 12:53, Jakub Jelinek wrote:
Hi!
This patch implements one of the few remaining missing ubsan
sanitizations, in particular instrumentation which complains about
loads of (non-bitfield) bool or enum (the latter in C++ only) value
that is outside of the range allowed (0/1 for bool, min/
On 12/16/13 11:13, Aldy Hernandez wrote:
On 12/16/13 10:07, Jan Hubicka wrote:
On 12/13/13 12:42, Aldy Hernandez wrote:
I'm fixing something completely unrelated, and noticed this...
Perhaps I'm missing something, but why do we need a gate when it always
returns true? Now that we have this `p
On 12/14/13 00:55, Jakub Jelinek wrote:
Hi!
This patch on top of the
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00500.html
Hmm, this looks like it was missed review-wise.
ISTM we're getting a bit late in the process for this kind of thing.
But it's so well contained in the sanitization code
On 12/16/13 10:07, Jan Hubicka wrote:
On 12/13/13 12:42, Aldy Hernandez wrote:
I'm fixing something completely unrelated, and noticed this...
Perhaps I'm missing something, but why do we need a gate when it always
returns true? Now that we have this `pass_data' business, we can set
has_gate to
On Fri, Dec 06, 2013 at 06:06:14PM +0100, Kai Tietz wrote:
> --- config/i386/i386.c(Revision 205719)
> +++ config/i386/i386.c(Arbeitskopie)
> @@ -10934,18 +10937,21 @@ ix86_expand_prologue (void)
> }
>m->fs.sp_offset += allocate;
>
> + /* Use stack_pointer_rtx for relativ
> On 12/13/13 12:42, Aldy Hernandez wrote:
> >I'm fixing something completely unrelated, and noticed this...
> >
> >Perhaps I'm missing something, but why do we need a gate when it always
> >returns true? Now that we have this `pass_data' business, we can set
> >has_gate to false.
> >
> >I also fi
While debugging something completely unrelated I ran into this...
SSA_OP_VMAYUSE hasn't been around for a looong time. For that matter, I
think it was even me that got rid of it, so this was an sloppy oversight
on my part.
I also noticed that the SSA_OP* definitions in the documentation have
On Mon, Dec 16, 2013 at 9:56 AM, Jakub Jelinek wrote:
> On Mon, Dec 16, 2013 at 09:51:38AM -0800, H.J. Lu wrote:
>> On Thu, Dec 12, 2013 at 5:36 AM, Jakub Jelinek wrote:
>> > On Wed, Dec 11, 2013 at 11:51:55AM -0500, Jason Merrill wrote:
>> >> It's only safe to free the targs if they weren't used
On Mon, Dec 16, 2013 at 09:51:38AM -0800, H.J. Lu wrote:
> On Thu, Dec 12, 2013 at 5:36 AM, Jakub Jelinek wrote:
> > On Wed, Dec 11, 2013 at 11:51:55AM -0500, Jason Merrill wrote:
> >> It's only safe to free the targs if they weren't used to instantiate
> >> any templates, so I lean toward option
On Thu, Dec 12, 2013 at 5:36 AM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 11:51:55AM -0500, Jason Merrill wrote:
>> It's only safe to free the targs if they weren't used to instantiate
>> any templates, so I lean toward option #1. Did you test this with
>> strict gc?
>
> Ok, after IRC discu
On 12/16/13 08:13, Jeff Law wrote:
On 12/13/13 12:42, Aldy Hernandez wrote:
I'm fixing something completely unrelated, and noticed this...
Perhaps I'm missing something, but why do we need a gate when it always
returns true? Now that we have this `pass_data' business, we can set
has_gate to fa
On 12/16/2013, 11:44 AM, Jeff Law wrote:
On 12/11/13 09:49, Vladimir Makarov wrote:
I could prevent use validize_mem in rs6000.c but I prefer to do it
in change_addres_1 as other targets might have the same problem and it
is better to have one for all solution.
It's certainly been speculate
On Mon, 2013-12-16 at 11:15 -0500, Trevor Saunders wrote:
> > That could also be an option. Although having pointer wrappers already
> > in place might open some other opportunities in the future. For
> > instance it would make it relatively easy to try out reducing the number
> > of garbage col
On Mon, Dec 16, 2013 at 05:49:26PM +0100, Thomas Schwinge wrote:
> > > --- gcc/gimplify.c
> > > +++ gcc/gimplify.c
> > > @@ -129,6 +129,8 @@ struct gimplify_ctx
> > >bool in_cleanup_point_expr;
> > > };
> > >
> > > +/* Variable remapping context. */
> >
> > Please mention there OpenMP (and
On Mon, Dec 16, 2013 at 05:35:36PM +0100, Thomas Schwinge wrote:
> Sure, that's fine by me, and thanks for the explanation.
>
> > Plus, the change, being an ABI change, would need to be done on the
> > trunk rather than just on gomp-4_0-branch.
>
> It's not an ABI change, as I had limited the cha
Hi,
I was looking at some loops that can be vectorized by LLVM, but not GCC. One
type of loop is with store of negative step.
void test1(short * __restrict__ x, short * __restrict__ y, short * __restrict__
z)
{
int i;
for (i=127; i>=0; i--) {
x[i] = y[127-i] + z[127-i];
}
}
On Fri, Dec 13, 2013 at 06:37:22PM +, Iyer, Balaji V wrote:
> @@ -3765,6 +3777,93 @@
>return attr_name;
> }
>
> +/* Parses the vector attribute of SIMD enabled functions in Cilk Plus.
> + VEC_TOKEN is the "vector" token that is replaced with "simd" and
> + pushed into the token list.
Hi!
On Mon, 16 Dec 2013 09:58:07 +0100, Jakub Jelinek wrote:
> On Fri, Dec 13, 2013 at 11:12:03AM +0100, Thomas Schwinge wrote:
> > OK to apply the following cleanup patches to trunk, assuming that testing
> > (still running) is fine?
Thanks for the review!
> > Reflect reality in comment.
Hi!
On Mon, 16 Dec 2013 09:58:07 +0100, Jakub Jelinek wrote:
> On Fri, Dec 13, 2013 at 11:12:03AM +0100, Thomas Schwinge wrote:
> > --- gcc/gimplify.c
> > +++ gcc/gimplify.c
> > @@ -129,6 +129,8 @@ struct gimplify_ctx
> >bool in_cleanup_point_expr;
> > };
> >
> > +/* Variable remapping con
On 12/11/13 09:49, Vladimir Makarov wrote:
I could prevent use validize_mem in rs6000.c but I prefer to do it
in change_addres_1 as other targets might have the same problem and it
is better to have one for all solution.
It's certainly been speculated that a fair amount of the "target
depend
Hi!
On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> On Mon, Dec 16, 2013 at 08:41:02AM +0100, Thomas Schwinge wrote:
> > Here is the patch I propose for gomp-4_0-branch; OK?
>
> No. The reason for 3 separate arrays is that some of the values
> are always variable, some are sometimes
> That sounds less conservative though. Anyway, that was just some thought
> to fix the eventual fallout of making more types have BLKmode.
In the end I was too optimistic... Testing a revised patch on x86 revealed a
obscure case where the new BLKmode triggered a layout change (I presume that
Hi!
I've added "binary" word to the diagnostics, because apparently it wasn't
clear that unary - (and unary +) aren't valid for !$omp atomic.
Committed to trunk.
2013-12-16 Jakub Jelinek
PR libgomp/59337
* openmp.c (resolve_omp_atomic): Adjust error message.
* gfortr
On Mon, Dec 16, 2013 at 04:44:00PM +0100, Oleg Endo wrote:
> On Mon, 2013-12-16 at 09:57 -0500, Trevor Saunders wrote:
> > >
> > > BTW, if you look at the patch, I haven't overloaded any ++ operators:
> > >
> > > Index: gcc/vec.h
> > > =
On 12/13/13 12:42, Aldy Hernandez wrote:
I'm fixing something completely unrelated, and noticed this...
Perhaps I'm missing something, but why do we need a gate when it always
returns true? Now that we have this `pass_data' business, we can set
has_gate to false.
I also fixed a minor typo in a
On Mon, 2013-12-16 at 09:57 -0500, Trevor Saunders wrote:
> >
> > BTW, if you look at the patch, I haven't overloaded any ++ operators:
> >
> > Index: gcc/vec.h
> > ===
> > --- gcc/vec.h (revision 205866)
> > +++ gcc/vec.h
On Mon, Dec 16, 2013 at 08:41:02AM +0100, Thomas Schwinge wrote:
> Here is the patch I propose for gomp-4_0-branch; OK?
No. The reason for 3 separate arrays is that some of the values
are always variable, some are sometimes variable (sizes), some are
never variable (alignment + kind).
So, if anyt
Hi Jerry,
Glad to see you back!
I stumbled on this pr while trying to clean the files left after the tests
(see http://gcc.gnu.org/ml/fortran/2013-10/msg00083.html, note that
gfortran.dg/c_loc_test_22.f90 has already been applied). I have a pending
patch cleaning the remaining files; the full cle
On Wed, 11 Dec 2013, Tom G. Christensen wrote:
> Latest results for gcc 4.8.x.
>
> This patch supersedes the previous one sent on 2013-11-03 as it was
> never applied.
Thanks, applied (and sorry for missing the November edition, Tom)!
Gerald
Thanks for the fix Vladimir, I confirm that most of ARM regression are
fixed, and Thumb2 bootstrap is ok. I'm still working on sorting out
the remaining regressions, most of them are on Thumb1.
Thanks
Yvan
On 13 December 2013 22:10, Vladimir Makarov wrote:
> On 12/13/2013, 4:02 PM, Jakub Jelinek
On Fri, Dec 13, 2013 at 10:00:57PM +0100, Oleg Endo wrote:
> On Thu, 2013-12-12 at 03:13 -0500, Trevor Saunders wrote:
> > On Wed, Dec 11, 2013 at 06:47:37PM +0100, Oleg Endo wrote:
> > > On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> > > > Declaring the edge_iterator inside the for()
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of
On 12/14/13 13:14, Tom de Vries wrote:
I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here.
If I'm reading the archives correctly is the caller/callee may have
different ABIs (by way of sysv/ms_abi attributes). Presumably there's
some magic to deal with the differences in the ABI
On Sat, Dec 14, 2013 at 10:19:48AM +0100, Richard Biener wrote:
> Oleg Endo wrote:
> >On Thu, 2013-12-12 at 03:13 -0500, Trevor Saunders wrote:
> >> On Wed, Dec 11, 2013 at 06:47:37PM +0100, Oleg Endo wrote:
> >> > On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> >> > > Declaring the ed
Kenneth Zadeck wrote:
>On 12/16/2013 06:19 AM, Richard Biener wrote:
>> On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
>>> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
> it is certainly true that in order to do an unbounded set of
>operations,
> you would have
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggest
On 11/12/13 17:09, Kyrill Tkachov wrote:
> Hi all,
>
> Following up on the crypto intrinsics for AArch32
> (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00365.html), here is a patch
> adding C++ name mangling for the poly64x2_t container type. This of course
> depends on the Crypto intrinsics p
> Hi,
>
> On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote:
> > Hi,
> > this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
> > previously.
>
> This is the first time I hear about this but the change is obviously
> OK, thanks.
It actually seems to solve quite num
On 16/12/13 13:45, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds an entry for the Cortex-A12 to the arm_cpu_table. This will
> enable the -mcpu=native machinery to work on Linux systems.
>
> Tested arm-none-eabi on qemu.
>
> Ok for trunk?
>
> Thanks,
> Kyrill
>
>
> 2013-12-16 Kyrylo T
Hi all,
This patch adds an entry for the Cortex-A12 to the arm_cpu_table. This will
enable the -mcpu=native machinery to work on Linux systems.
Tested arm-none-eabi on qemu.
Ok for trunk?
Thanks,
Kyrill
2013-12-16 Kyrylo Tkachov
* config/arm/driver-arm.c (arm_cpu_table): Add cortex
Hi,
On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote:
> Hi,
> this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
> previously.
This is the first time I hear about this but the change is obviously
OK, thanks.
> Martin, I do not fully follow the logic of this func
Hi,
this patch fixes ICE in ipa_profile_generate_summary when the call is already
devirtualized before the pass starts.
Tested on x86_64-linux
Jan
Index: ChangeLog
===
--- ChangeLog (revision 206013)
+++ ChangeLog (working copy)
On Mon, Dec 9, 2013 at 4:48 AM, H.J. Lu wrote:
> On Mon, Dec 2, 2013 at 4:49 AM, H.J. Lu wrote:
>> Hi,
>>
>> "ld" is a special name for GCC driver. find_a_file has
>>
>> #ifdef DEFAULT_LINKER
>> if (! strcmp (name, "ld") && access (DEFAULT_LINKER, mode) == 0)
>> return xstrdup (DEFAULT_L
Jakub Jelinek wrote:
>On Sat, Dec 14, 2013 at 06:51:35PM +0100, Richard Biener wrote:
>> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> Ok.
>
>Thanks, committed. For 4.8, do you prefer this larger (thus more
>risky?)
>patch, or the smaller tree-ssa-ter.c change only?
On Sat, Dec 14, 2013 at 06:51:35PM +0100, Richard Biener wrote:
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Ok.
Thanks, committed. For 4.8, do you prefer this larger (thus more risky?)
patch, or the smaller tree-ssa-ter.c change only?
Jakub
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
>
> On 12/15/2013 11:40 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> it is certainly true that in order to do an unbounded set of operations,
>>> you would have to check on every operation. so my suggestion that we
>>> should remove the c
On 12/16/13 04:22, Hans-Peter Nilsson wrote:
From: Hans-Peter Nilsson
Date: Sun, 15 Dec 2013 15:20:48 +0100
+// { dg-options "-std=gnu++0x -DSAMPLES=3" { target { { arm*-* }&&
simulator } } }
+// { dg-options "-std=gnu++0x -DSAMPLES=1" { target simulator } }
JFTR, I managed to have
Hi!
I've noticed that the automatic dependencies changes resulted
in version.o not being recompiled for months. The problem is
that the automatic dependencies obviously record only dependencies
on version.c and version.h, but not about all the other files
because for those the Makefile runs cat o
Hi,
the problem here is that we ICE on an assert that crept in from earliler
stages of development where I wondered if we can hit this somewhat odd
situation.
Fixed thus.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 206011)
Hi!
For simd reductions when we force safelen(1) (either user did, or we punt),
my thoughts were that there is just one private var to merge and people
should initialize the reduction var to the right initialization value
already, so we can just copy it over instead of merging. But as the
testcas
> Hello,
>there's updated version of the patch.
>
> Tested on x86_64 with enable bootstrap.
>
> Martin
>
> On 16 December 2013 00:21, Jan Hubicka wrote:
> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> >> index 93e857df..d5a0ac8 100644
> >> --- a/gcc/ChangeLog
> >> +++ b/gcc/ChangeLog
> >>
> Btw, I couldn't find anything that corresponds to gcc's btver2 arch. Is that
> an old term for what has become the Jaguar architecture?
Yes, "btver2" = "jaguar". We have the name as per its family name (i.e, bobcat
family) in GCC.
Similarly we have the names "bdver2" = "piledriver", "bdver3"
On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak wrote:
> On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
> wrote:
>
>> Hi again
>> On Wednesday 11 December 2013, Uros Bizjak wrote:
>>> Hello!
>>>
>>> > PR gcc/59422
>>> >
>>> > This patch extends the supported targets for function multi versi
On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
wrote:
> Hi again
> On Wednesday 11 December 2013, Uros Bizjak wrote:
>> Hello!
>>
>> > PR gcc/59422
>> >
>> > This patch extends the supported targets for function multi versiong to
>> > also include Haswell, Silvermont, and the most recent
Patch updated to keep libgcc enums backwards compatible.
`Allan
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 205984)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-12-14 Allan Sandfeld Jensen
+
+PR gcc/59422
On Fri, Dec 13, 2013 at 11:12:03AM +0100, Thomas Schwinge wrote:
> OK to apply the following cleanup patches to trunk, assuming that testing
> (still running) is fine?
> gcc/c/
> * c-parser.c (c_parser_omp_parallel): Fix description.
> gcc/cp/
> parser.c (cp_parser_omp_para
96 matches
Mail list logo
