Gerald Pfeifer wrote:
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Thanks for looking at the patch. However, the patch has a link problem.
The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes
On Thu, Oct 24, 2013 at 11:14:42PM -0600, Jeff Law wrote:
On 10/24/13 15:10, Eric Botcazou wrote:
As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the
Jason Merrill wrote:
On 10/10/2013 04:46 AM, Tobias Burnus wrote:
I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.
I would think that a range-based loop over an array should vectorize
nicely:
int ar[8];
for (int i:
Hi Richard,
Did you just propose:
--- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
+++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
@@ -471,27 +471,7 @@
static enum machine_mode
mode_for_array (tree elem_type, tree size)
{
- tree elem_size;
- unsigned HOST_WIDE_INT
On Fri, Oct 25, 2013 at 08:22:22AM +0200, Tobias Burnus wrote:
Jason Merrill wrote:
On 10/10/2013 04:46 AM, Tobias Burnus wrote:
I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.
I would think that a range-based
Hi Kirill,
with the current trunk (newst git mirror version), bootstrapping fails
here with the following error. Did you forget to commit one file?
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual
Adding Ilya.
On 25 October 2013 10:48, Tobias Burnus bur...@net-b.de wrote:
Hi Kirill,
with the current trunk (newst git mirror version), bootstrapping fails
here with the following error. Did you forget to commit one file?
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
Hello!
2013-10-25 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.h (TARGET_MPX): New define.
(TARGET_MPX_P): Ditto.
Tested on x86_64-pc-linux-gnu, committed.
Uros.
Index: i386.h
===
--- i386.h (revision 204047)
On Fri, Oct 25, 2013 at 03:11:40AM +0200, Gerald Pfeifer wrote:
Hi Tobias,
On Thu, 24 Oct 2013, Tobias Burnus wrote:
the attached patch updates the gomp project patch.
(Besides adding an item for the OpenMP 4.0 merge, I removed the 95 from
Fortran 95 as Fortran is backward compatible and
Hi!
Ping. To sum it up, with these patches applied, there are no changes for
a regular build (not using the new configure options). On the other
hand, configuring GCC as described, it is possible use the 32-bit x86
linker for/with a x86_64 build, and get the very same GCC test results as
when
On Thu, 24 Oct 2013, Paolo Carlini wrote:
Hi,
this is just a preview, but I decided to send it out early to understand if
I'm on the right track or not. As you can see in the Bug, this started as a
spin-off of a library issue with complex pow, which led us to:
Dear all,
I have committed the patch below as obvious (Rev. 204049).
Seemingly, there are a lot of places which have to be updated for
a new OpenMP version ...
Tobias
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (Revision
Actually I think it's jfc's code; he had a major revamp of alias.c back
in the early egcs days and getting it integrated was one of the
project's early wins. Sadly, jfc hasn't been involved in GCC work for a
long long time.
OK, thanks for the clarification.
Anyway, I think the issue here
On 24/10/13 20:03, Kugan wrote:
Hi Kyrill,
It happens for armv5te arm-none-linux-gnueabi. --with-mode=arm
--with-arch=armv5te --with-float=soft
Ah ok, I can reproduce it now. So, while I agree that we add a scan for vbit and
vbif to these testcases, there seems to be something dodgy going
On Thu, Oct 24, 2013 at 10:35 PM, Jeff Law l...@redhat.com wrote:
On 10/24/13 07:40, Richard Biener wrote:
we were supposed to remove mudflap for 4.9, no?
Really? I guess it hasn't been removed yet since the include is still
there? who is doing that?
Yeah, nobody has done it yet
OK, so it is about 2%. Did you try if you need lookahead even in the early
pass (before reload)? My guess would be so, but if not, it could cut the
cost to half. For -Ofast/-O3 it looks resonable to me, but we will need to
announce it on the ML. For other settings I think we need to
On Fri, Oct 25, 2013 at 3:17 AM, David Malcolm dmalc...@redhat.com wrote:
I noticed that some of the macros in tree.h that act on trees have
parameters named CODE, rather NODE, which is confusing when in the
presence of other macros that act on enum tree_code values.
The attached patch
Hello,
this patch fixes the recently discovered data store race on arm-eabi-gcc with
-fno-strict-volatile-bitfields
for structures like this:
#define test_type unsigned short
typedef struct s{
unsigned char Prefix[1];
test_type Type;
}__attribute((__packed__,__aligned__(4))) ss;
volatile ss
Thanks. Installed on the trunk.
Well, no, that will be problematic for some architectures. The history of
this piece of code is complicated and it's admittedly lacking a comment, but
the purpose of the block is clear enough:
op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_SUM);
2013/10/25 Uros Bizjak ubiz...@gmail.com:
Hello!
2013-10-25 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.h (TARGET_MPX): New define.
(TARGET_MPX_P): Ditto.
Tested on x86_64-pc-linux-gnu, committed.
Thanks for fixing it!
Uros.
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
Hi!
As discussed on IRC, this patch attempts to preserve VRP computed
range info for some simple __builtin_unreachable () using assertions.
If there are no immediate uses of some SSA_NAME except for those in
a condition guarding __builtin_unreachable () and in ASSERT_EXPR
in the following basic
On 10/25/2013 06:30 AM, Tim Shen wrote:
This patch optimizes BFS executor by removing quantifier tracking, but
precisely control the assignment order of the variable recording the
optimal solution.
Ok. Are there measurable performance changes at this point? I'm asking
because we should take the
Hi,
On 10/24/2013 09:22 PM, François Dumont wrote:
Ok to commit ?
Looks great to me.
Thanks!
Paolo.
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find
On Fri, Oct 25, 2013 at 8:29 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi Richard,
Did you just propose:
--- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
+++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
@@ -471,27 +471,7 @@
static enum machine_mode
mode_for_array
Hi!
tree-ssa-ccp.c already computes which bits are known to be zero, but
we preserve that info only for pointers and not for integers.
This patch changes SSA_NAME_RANGE_INFO, so we preserve that info even for
integers. The bitmask is also computed from range info.
There are no users of this
On Fri, Oct 25, 2013 at 10:40 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello,
this patch fixes the recently discovered data store race on arm-eabi-gcc with
-fno-strict-volatile-bitfields
for structures like this:
#define test_type unsigned short
typedef struct s{
unsigned
On Fri, 25 Oct 2013, Richard Biener wrote:
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I
On Fri, Oct 25, 2013 at 11:29 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 25 Oct 2013, Richard Biener wrote:
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse marc.gli...@inria.fr
wrote:
On Thu, 24 Oct
Doesn't that also apply to arithmetic on symbols when the offset is NULL?
This can presumably be retrofitted when the offset is null or constant.
But yes, the codegen example posted shows this kind of difference
(though it doesn't seem to save anything for that case). I'd have expected
a
Hi,
Eh ... even
register struct { int i; int a[0]; } asm (ebx);
works. Also with int a[1] but not with a[2]. So just handling trailing
arrays makes this case regress as well.
Now I'd call this use questionable ... but we've likely supported that
for decades and cannot change that now.
Hi,
On 10/18/2013 04:42 AM, Ed Smith-Rowland wrote:
--- testsuite/g++.dg/cpp1y/pr58708.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr58708.C(working copy)
@@ -0,0 +1,70 @@
+// { dg-options -std=c++1y }
+
+#include array
+#include vector
+#include type_traits
+#include testsuite_hooks.h
are
Hi,
On 10/23/2013 09:16 PM, Jason Merrill wrote:
The second hunk adds %X for printing an exception-specification in
diagnostics.
In my experience these convenience %? that we have got easily trigger
warnings during bootstrap/build, eg:
/scratch/Gcc/svn-dirs/trunk/gcc/cp/error.c:3302:53:
On Fri, 25 Oct 2013, Richard Biener wrote:
Ah, so you are looking at call_may_clobber_ref_p_1 and its pointer handling
when special-casing builtins?
Yes.
Note that fields can only be disambiguated
if the size of the access is known
TBAA could also help sometimes.
(not sure what fancy
On Fri, Oct 25, 2013 at 12:39:58PM +0200, Paolo Carlini wrote:
On 10/23/2013 09:16 PM, Jason Merrill wrote:
The second hunk adds %X for printing an exception-specification in
diagnostics.
In my experience these convenience %? that we have got easily
trigger warnings during bootstrap/build,
On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
Eh ... even
register struct { int i; int a[0]; } asm (ebx);
works. Also with int a[1] but not with a[2]. So just handling trailing
arrays makes this case regress as well.
Now I'd call this use
Hi,
I had a look to the testcases Jason added / tweaked in his recent patch
about trivial but non-callable [cd]tors: I think a simple testcase
directly from 54812 cannot hurt.
Thanks,
Paolo.
2013-10-25 Paolo Carlini paolo.carl...@oracle.com
PR c++/54812
*
Hi, all,
This is v4 patch for Andes nds32 port on machine description part 3,
which includes other rtl patterns and settings.
gcc/
2013-10-25 Chung-Ju Wu jasonw...@gmail.com
Shiva Chen shiva0...@gmail.com
* config/nds32/constants.md: New file.
*
Hi, GCC global reviewers,
I would like to thank Joseph Myers's preliminary review and
Richard Sandiford's help for further technical review in these
three months:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01138.html
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01180.html
Their comments
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
losing
Hi,
On Fri, 25 Oct 2013 11:26:20, Richard Biener wrote:
On Fri, Oct 25, 2013 at 10:40 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello,
this patch fixes the recently discovered data store race on arm-eabi-gcc
with -fno-strict-volatile-bitfields
for structures like this:
On 10/25/2013 06:08 AM, Paolo Carlini wrote:
Hi,
On 10/18/2013 04:42 AM, Ed Smith-Rowland wrote:
--- testsuite/g++.dg/cpp1y/pr58708.C (revision 0)
+++ testsuite/g++.dg/cpp1y/pr58708.C(working copy)
@@ -0,0 +1,70 @@
+// { dg-options -std=c++1y }
+
+#include array
+#include vector
+#include
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
This patch prevents the use of requires expressions in non-template
scopes. This restriction was relaxed in the most recent version of
concepts lite, but the implementation requires some thought. For now,
I am marking it an error to make it consistent with previous versions
of the spec.
OK, so it is about 2%. Did you try if you need lookahead even in the early
pass (before reload)? My guess would be so, but if not, it could cut the
cost to half. For -Ofast/-O3 it looks resonable to me, but we will need
to announce it on the ML. For other settings I think we need
On Fri, 25 Oct 2013, Jan Hubicka wrote:
OK, so it is about 2%. Did you try if you need lookahead even in the
early pass (before reload)? My guess would be so, but if not, it could
cut the cost to half. For -Ofast/-O3 it looks resonable to me, but we
will need to announce it on
On Fri, 25 Oct 2013, Tobias Burnus wrote:
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it
On 25 October 2013 05:15, DJ Delorie d...@redhat.com wrote:
Yup, my registers are smaller than Pmode.
This is what I ended up with...
Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one.
Well, it's not really a lie if you map hardware registers 22 and
Hi,
On Fri, Oct 25, 2013 at 12:51:13PM +0200, Richard Biener wrote:
On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
Eh ... even
register struct { int i; int a[0]; } asm (ebx);
works. Also with int a[1] but not with a[2]. So just handling
But it's nothing to do with construction inside
memory_address_addr_space but with validity of an address construct.
first thing memory_address_addr_space does is deconstructing
address_mode from as parameter. But if one doesn't pass actual mode
there's not way to find it and call to
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
I think this patch should be sufficient - no containers,
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++ front-end
testcase doesn't, why not.
Paolo.
I think
Hi,
On 10/25/2013 04:05 PM, Tim Shen wrote:
On Fri, Oct 25, 2013 at 5:07 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Ok. Are there measurable performance changes at this point? I'm asking
because we should take the chance and add performance testcases when we
improve the performance:
Hello,
This patch implements the cmpstrnsi pattern to support the strncmp
builtin for constant lengths. The cmp/str instructions is used for size
= 8 bytes, else fall back to the byte-at-a-time check to favor small
strings.
I now also handle the cases where align is known for both cmpstr and
In the ChangeLog, the entry
* gcc/config/sh/sh-mem.cc (sh_expand_cmpnstr): Moved here.
is instead
* gcc/config/sh/sh-mem.cc (sh_expand_cmpnstr): New function.
Sorry for this,
Christian
On 07/09/13 18:54, Jason Merrill wrote:
OK.
I've reproduced the same problem with the 4.7 and 4.8 branch, and checked that
applying the patch fixes the problem.
Committed to 4.7 and 4.8 branch as well.
Thanks,
- Tom
On 10/25/2013 04:22 PM, Tim Shen wrote:
On Fri, Oct 25, 2013 at 10:12 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
Ah good. Can't you just have split_bfs.cc defining the
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT macro and including the existing
split.cc?
Here :) Hack the __FILE__ macro to let
Andrew == Andrew Pinski pins...@gmail.com writes:
enum raw_str_phase phase = RAW_STR_PREFIX;
Andrew This is a good work around but please add a comment of why this is
Andrew needed (to work around a bug in XLC++).
I agree.
It's ok with this update.
thanks,
Tom
On 10/25/2013 10:01 AM, Paolo Carlini wrote:
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++
On 10/25/2013 10:01 AM, Paolo Carlini wrote:
On 10/25/2013 03:46 PM, Ed Smith-Rowland wrote:
On 10/25/2013 07:54 AM, Paolo Carlini wrote:
On 10/25/2013 01:38 PM, Ed Smith-Rowland wrote:
So, you also want a library testcase?
Up to you: if you feel it would test something that the c++
On 10/25/2013 04:29 PM, Ed Smith-Rowland wrote:
Here is one with necessary tools inlined.
You still have a lot of redundant code... I'm not going to insist anyway.
Paolo.
On Fri, Oct 25, 2013 at 10:29:41AM -0400, Ed Smith-Rowland wrote:
2013-10-25 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58708
* parser.c (make_string_pack): Discover non-const type and size
of character and build parm pack with correct type and chars.
Hi,
On Thu, Oct 24, 2013 at 01:02:51AM +0200, Steven Bosscher wrote:
On Wed, Oct 23, 2013 at 6:46 PM, Martin Jambor wrote:
/* Perform the second half of the transformation started in
@@ -4522,7 +4704,15 @@ ira (FILE *f)
allocation because of -O0 usage or because the function is
Hi,
here the issue is that we fail to detect shadowing declarations in
inline member function templates. The reason is the following check in
check_template_shadow:
if (decl == olddecl
- || TEMPLATE_PARMS_FOR_INLINE (current_template_parms))
+ || (DECL_TEMPLATE_PARM_P (decl)
+
OK.
Jason
On Thu, Oct 24, 2013 at 09:17:55PM +0200, Tobias Burnus wrote:
2013-08-24 Tobias Burnus bur...@net-b.de
PR other/33426
* g++.dg/parse/ivdep.C: New.
* g++.dg/vect/pr33426-ivdep.cc: New.
FYI, I'm seeing various new FAILs on i686-linux:
+FAIL: gcc.dg/vect/vect-ivdep-1.c
On 10/25/13 03:29, Marc Glisse wrote:
It doesn't get lost, but this is the missed optimization that malloc
results still alias with global pointers (here a function argument).
Taking into account the offset shouldn't change anything.
I think this is a different issue (but if you say
On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
On Mon, 21 Oct 2013, Mike Stump wrote:
On Oct 21, 2013, at 3:28 AM, Vidya Praveen vidyaprav...@arm.com wrote:
Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes
On Fri, 25 Oct 2013, Richard Biener wrote:
Ok with preserving options as dummy, see examples like
fargument-alias
Common Ignore
Does nothing. Preserved for backward compatibility.
I don't think we should sorry (), but we can certainly warn that
mudflap was replaced by
On Fri, 25 Oct 2013, Richard Biener wrote:
Btw, the C++ standard doesn't cover packed or aligned attributes so
we could declare this a non-issue. Any opinion on that?
I think the memory model naturally applies to packed structures (i.e.,
writes to fields in them should not write to any other
On Thu, Oct 24, 2013 at 03:57:17PM -0400, Jason Merrill wrote:
On 09/25/2013 08:41 AM, Marek Polacek wrote:
+ /* Do the instrumentation of VLAs if desired. */
+ if ((flag_sanitize SANITIZE_VLA)
+ size !TREE_CONSTANT (size)
+ /* From C++1y onwards, we throw an exception on a
On Fri, 25 Oct 2013, Richard Biener wrote:
you can followup with handling POINTER_PLUS_EXPR if you like.
Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
2013-10-26 Marc Glisse marc.gli...@inria.fr
gcc/
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for a
On Thu, 2013-10-10 at 09:56 +0200, Richard Biener wrote:
As a general observation I don't like the
if (pass-has_foo_member_function)
pass-foo_member_function ()
style. It is totally against the idea of having virtual functions. Why
not simply provide stub implementations in the base
Hi!
The following patch makes use of the computed nonzero_bits preserved
in the SSA_NAME_RANGE_INFO.
I chose to write a new routine instead of improving current
highest_pow2_factor, because that routine didn't care about overflows etc.
and by working on ctz numbers instead of powers of two in
Late in the C++11 process it was decided that a constructor or
destructor can be trivial but not callable; as a result, everywhere that
assumed that a call to a trivial function didn't need any processing
needed to be updated. This patch does that.
This has introduced a problem for the
2013/10/25 Jeff Law l...@redhat.com:
On 10/21/13 05:49, Ilya Enkovich wrote:
Hi,
This patch introduces built-in functions used by Pointers Checker and flag
to enable Pointers Checker. Builtins available for user are expanded in
expand_builtin. All other builtins are not allowed in expand
On 10/25/2013 12:58 PM, Marek Polacek wrote:
I've tried to implement the instrumentation in cp_finish_decl.
However, the problem is with multidimensional arrays, e.g. for
int x = -1;
int a[1][x];
array_of_runtime_bound_p returns false, thus we don't instrument this
at all, nor throw an
On 10/25/2013 01:53 PM, Eric Botcazou wrote:
This has introduced a problem for the -fdump-ada-spec machinery, which boils
down to the TYPE_METHODS field of the following structure:
struct _outer {
struct _inner {
int x;
} inner;
} outer;
Previously it was empty, now it
On Fri, Oct 25, 2013 at 02:17:48PM -0400, Jason Merrill wrote:
On 10/25/2013 12:58 PM, Marek Polacek wrote:
I've tried to implement the instrumentation in cp_finish_decl.
However, the problem is with multidimensional arrays, e.g. for
int x = -1;
int a[1][x];
array_of_runtime_bound_p
On 10/25/2013 03:03 PM, Marek Polacek wrote:
On Fri, Oct 25, 2013 at 02:17:48PM -0400, Jason Merrill wrote:
I think the right place to handle both ubsan and c++1y VLA checks is
in compute_array_index_type, in the block where we're calling
variable_size.
I'm sorry, you want me to move the
Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one.
Well, it's not really a lie if you map hardware registers 22 and 23 to
a single register for the purposes of gcc internals.
Yeah, I'm basically making those two registers into a permanent bigger
Jakub Jelinek wrote:
FYI, I'm seeing various new FAILs on i686-linux:
+FAIL: gcc.dg/vect/vect-ivdep-1.c (test for warnings, line )
+FAIL: gcc.dg/vect/vect-ivdep-1.c -flto (test for warnings, line )
+FAIL: gfortran.dg/vect/vect-do-concurrent-1.f90 -O (test for warnings, line
)
+FAIL:
On 2013-10-10 14:07 , tsaund...@mozilla.com wrote:
This makes the implementation of stack vectors simpler and easier to use. This
works by
making
On Fri, 25 Oct 2013, Mike Stump wrote:
On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
I too would like to include this change on those branches, as
recent generic newlib changes has caused these tests to break
On Fri, Oct 25, 2013 at 03:30:47PM -0400, Diego Novillo wrote:
On 2013-10-10 14:07 , tsaund...@mozilla.com wrote:
This makes the implementation of stack vectors simpler and easier to use.
This
Tobias Burnus wrote:
Thanks for looking at the patch. However, the patch has a link
problem. The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
That's also the link I use in the changes.html file. However, some
script changes the link to:
Tobias Burnus wrote:
Jason Merrill wrote:
I would think that a range-based loop over an array should vectorize
nicely:
[...]
Therefore, I will send a follow up patch.
Attached is that patch [C++].
[C/C++:] Additionally, as Jakub proposed and other compilers also
support, the patch accepts
I've committed the following patch to use LRA for ppc. By default
reload pass is used. To use LRA, please add option -mlra.
I also removed change in constraints for swap insn as it was
requested by David Edelsohn. It was necessary to fix one failure of new
gcc tests. I'll work on more
On 10/25/13 10:26, Joseph S. Myers wrote:
On Fri, 25 Oct 2013, Richard Biener wrote:
Ok with preserving options as dummy, see examples like
fargument-alias
Common Ignore
Does nothing. Preserved for backward compatibility.
I don't think we should sorry (), but we can certainly warn that
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58759
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 204080.
2013-10-25 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/58759
* lra-constraints.c
This patch addresses various forms of failure described in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html
It adds a default: gcc_unreachable(); to the autogenerated switch()
statement in the routines for a base class, converting various kinds of
tag errors from leading to silent
On Fri, 25 Oct 2013, Tobias Burnus wrote:
Tobias Burnus wrote:
Jason Merrill wrote:
I would think that a range-based loop over an array should vectorize
nicely:
[...]
Therefore, I will send a follow up patch.
Attached is that patch [C++].
[C/C++:] Additionally, as Jakub
Hi!
And here is a patch that allows vectorization without peeling for alignment
and scalar loop for bound even for fn2, fn3 and fn4 in the following
testcase, though as with the range __builtin_unreachable () notes, it is
quite fragile, because it only works if there are no immediate uses of the
Hi,
This patch writes out ggc_memory to gcda files.
Google branches only. Test is ongoing. OK to check-in after test passes?
-Rong
2013-10-25 Rong Xu x...@google.com
* contrib/profile_tool (ModuleInfo): write out ggc_memory to gcda file.
* gcc/gcov-io.c
If the propagation finds an infinite look, if the in-edge count is
non-zero, then it will cause compiler go into infinite loop when
building with AutoFDO.
Bootstrapped and regression test on-going.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
Christian Bruel christian.br...@st.com wrote:
No regressions for -m2 and -m4 for sh-elf.
OK for trunk ?
OK with the change of ChangeLog entry suggested by your another mail.
Thanks!
Regards,
kaz
Looks good.
David
On Fri, Oct 25, 2013 at 4:04 PM, Rong Xu x...@google.com wrote:
Hi,
This patch writes out ggc_memory to gcda files.
Google branches only. Test is ongoing. OK to check-in after test passes?
-Rong
What is the usual number of iterations?
David
On Fri, Oct 25, 2013 at 4:10 PM, Dehao Chen de...@google.com wrote:
If the propagation finds an infinite look, if the in-edge count is
non-zero, then it will cause compiler go into infinite loop when
building with AutoFDO.
Bootstrapped and
1 - 100 of 104 matches
Mail list logo
