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
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 sandf...@kde.org
+
+
On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
carew...@gmail.com 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
On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Hi again
On Wednesday 11 December 2013, Uros Bizjak wrote:
Hello!
PR gcc/59422
This patch extends the supported targets for function
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 =
Hello,
there's updated version of the patch.
Tested on x86_64 with enable bootstrap.
Martin
On 16 December 2013 00:21, Jan Hubicka hubi...@ucw.cz wrote:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 93e857df..d5a0ac8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3
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
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!
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
On 12/16/13 04:22, Hans-Peter Nilsson wrote:
From: Hans-Peter Nilssonh...@axis.com
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
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
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 Mon, Dec 9, 2013 at 4:48 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Dec 2, 2013 at 4:49 AM, H.J. Lu hjl.to...@gmail.com 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
Jakub Jelinek ja...@redhat.com 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
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
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 kyrylo.tkac...@arm.com
* config/arm/driver-arm.c
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 Tkachov
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 number of
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
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 zad...@naturalbridge.com writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every
Kenneth Zadeck zad...@naturalbridge.com 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 zad...@naturalbridge.com writes:
it is certainly true that in order to do an unbounded set of
On Sat, Dec 14, 2013 at 10:19:48AM +0100, Richard Biener wrote:
Oleg Endo oleg.e...@t-online.de 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
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
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com 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 zad...@naturalbridge.com writes:
it is
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() is not a
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 vmaka...@redhat.com wrote:
On 12/13/2013,
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
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
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
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 (working
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
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
===
---
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 ja...@redhat.com
PR libgomp/59337
* openmp.c (resolve_omp_atomic): Adjust error message.
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!
On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek ja...@redhat.com 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
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
Hi!
On Mon, 16 Dec 2013 09:58:07 +0100, Jakub Jelinek ja...@redhat.com 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
Hi!
On Mon, 16 Dec 2013 09:58:07 +0100, Jakub Jelinek ja...@redhat.com 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
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,
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 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 change to
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 after OpenACC support
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 collected
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
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
On Thu, Dec 12, 2013 at 5:36 AM, Jakub Jelinek ja...@redhat.com 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
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 ja...@redhat.com 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
On Mon, Dec 16, 2013 at 9:56 AM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
On Wed, Dec 11, 2013 at 11:51:55AM -0500, Jason Merrill wrote:
It's only safe to free the
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
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
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 relative
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
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
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
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,
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' business,
Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com 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 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?
It
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 the
On 12/16/2013 01:37 PM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
Comitted.
2013-12-16 Markus Trippelsdorf mar...@trippelsdorf.de
* 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
2013/12/16 Jakub Jelinek ja...@redhat.com:
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;
+
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 cm...@google.com
* go-gcc.cc (Gcc_backend::struct_field_expression): New
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
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 GCC.
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 tejohn...@google.com wrote:
On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson tejohn...@google.com wrote:
On
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
(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 h...@axis.com
Date: Sun, 15 Dec 2013 15:20:48 +0100
+// { dg-options -std=gnu++0x -DSAMPLES=3 { target { { arm*-* }
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
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li davi...@google.com 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
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;
+
On Sat, Dec 14, 2013 at 5:23 AM, Jakub Jelinek ja...@redhat.com 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
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 balaji.v.i...@intel.com
* omp-low.c (simd_clone_clauses_extract): Replaced
I got ...
me too on x86_64-apple-darwin13 with -m32 (gcc and g++).
r206009 is OK, r206026 is not.
Dominique
On Mon, Dec 16, 2013 at 1:44 PM, Dominique Dhumieres domi...@lps.ens.fr 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 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 tejohn...@google.com wrote:
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li davi...@google.com
wrote:
gcov_rewrite function is only needed (and defined)
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
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
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! Committed as
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 domi...@lps.ens.fr
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
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
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
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
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
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
- 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 this:
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
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 priority
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 for completeness.
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:
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
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
2013/12/13 Chung-Ju Wu jasonw...@gmail.com:
2013/12/11 Monk Chiang sh.chian...@gmail.com:
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
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_CREAT
94 matches
Mail list logo
