On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Wed, 27 Feb 2013, Richard Biener wrote:
Wouldn't it be better to simply pass this using the variable size handling
code? Thus, initialize args_size.var for too large constant size instead?
Would that be
On 03/01/2013 05:15 AM, Ulrich Drepper wrote:
On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik b...@redhat.com wrote:
Not seeing it.
Say for:
#include iostream
// A class for math constants.
templatetypename _RealType
struct __math_constants
{
// Constant @f$ \pi
On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown jul...@codesourcery.com wrote:
Hi,
Several new (ish?) autovectorizer features have apparently caused NEON
support for same to regress quite heavily in big-endian mode. This
patch is an attempt to fix things up, but is not without problems --
* PING * – The patch is rather simple and on the verge to be obvious.
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01106.html
Tobias
Tobias Burnus wrote:
(The attachment contains my original patch (simple rediff) and
Andreas' follow-up patch for libiberty.)
Tobias
Tobias Burnus wrote:
On Thu, Feb 28, 2013 at 7:43 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Feb 28, 2013 at 07:27:48PM +0100, Marek Polacek wrote:
The hunk
probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
in there should be probably handled in the same way. But I'll handle
that
I committed (Rev. 196372) after regtesting on x86-64-gnu-linux the
attached patch.
There are still plenty of leaks in the FE, including surprising ones:
The program end leaks memory while some more complicated programs
don't. (Tested with valgrind --leak-check=full and compiling with
Hi,
config/aarch64/aarch64.c attempts to do this:
#undef TARGET_FIXED_CONDITION_CODE_REG
#define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs
This patch adds the S to the end of TARGET_FIXED_CONDITION_CODE_REG
clearing a warning for redefining
Hi,
this is the ICE during the build of the Ada runtime on x86-64/Windows: the
compiler stops on the assertion in declare_return_variable:
var = return_slot;
gcc_assert (TREE_CODE (var) != SSA_NAME);
The problem stems for the fnsplit pass: it turns
P.Sin (const
Hi,
On trunk and 4.7 __aarch64_sync_cache_range gives a missing prototype
warning and two statement with no effect warnings as so:
---
.../libgcc/config/aarch64/sync-cache.c:22:1: warning: no previous prototype for
'__aarch64_sync_cache_range' [-Wmissing-prototypes]
__aarch64_sync_cache_range
On Fri, Mar 1, 2013 at 12:38 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this is the ICE during the build of the Ada runtime on x86-64/Windows: the
compiler stops on the assertion in declare_return_variable:
var = return_slot;
gcc_assert (TREE_CODE (var) !=
On Fri, 1 Mar 2013 11:07:17 +0100
Richard Biener richard.guent...@gmail.com wrote:
On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown
jul...@codesourcery.com wrote:
Hi,
Several new (ish?) autovectorizer features have apparently caused
NEON support for same to regress quite heavily in
On 01/03/13 11:41, James Greenhalgh wrote:
Hi,
On trunk and 4.7 __aarch64_sync_cache_range gives a missing prototype
warning and two statement with no effect warnings as so:
OK
/Marcus
OK
On 1 March 2013 10:49, James Greenhalgh james.greenha...@arm.com wrote:
Hi,
config/aarch64/aarch64.c attempts to do this:
#undef TARGET_FIXED_CONDITION_CODE_REG
#define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs
This patch adds the S to the end of
Hello!
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary structure. However, passing parts of complex number in a
structure is not the same as passing true C99 _Complex value, so this
workaround
The use of TAB there is fine. The issue is that you have trail
white
space at the end of the line, which is still present in the latest
patch.
Sorry. I confused it with spaces at the start of pattern instead of
trailing space. I have modified it as per your suggestion.
Please review
Do I understand correctly that the only issue is memory vs. register
element ordering? Thus a fixup could be as simple as extra shuffles
inserted after vector memory loads and before vector memory stores?
(with the hope of RTL optimizers optimizing those)?
It's not even necessary to
On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary structure. However, passing parts of complex number in a
structure is not the
On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor i...@google.com wrote:
On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary
This patch enables C++11 and concepts support by default on the
c++-concepts branch.
-- Gaby
2013-03-01 Gabriel Dos Reis g...@integrable-solutions.net
* gcc/c-family/c-common.c (cxx_dialect): Set C++11 as default.
* gcc/c-family/c.opt(flag_concepts): Add.
*
On Fri, Mar 1, 2013 at 3:50 PM, Uros Bizjak ubiz...@gmail.com wrote:
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary structure. However, passing parts of complex number in a
structure is not the
How about this patch then? As I said, I have code in need of
constants lined up and Edward likely also wants to take advantage of
them in some of his code.
Index: include/Makefile.am
===
--- include/Makefile.am (revision 196362)
But in theory this pessimizes code as aggregate_value_p returned true
for this? That is, isn't the bug that we rewrite a possible
return-slot-decl into SSA? (do we do that here?)
Yes, aggregate_value_p returns true for this because the ABI says that this
type is returned in memory. And,
The previous patch left a declaration for flag_concepts, which is bogus.
Applied to branch.
-- Gaby
2013-03-01 Gabriel Dos Reis g...@integrable-solutions.net
* lex.c (flag_concepts): Revert left over declaration.
Index: gcc/cp/lex.c
I am going to check in this testsuite patch as an obvious fix. We should make
sure a platform supports PIC before compiling with the -fpic flag.
Steve Ellcey
sell...@imgtec.com
2013-03-01 Steve Ellcey sell...@mips.com
* gcc.dg/pr56396.c: Require pic support.
diff --git
On Fri, Mar 01, 2013 at 07:57:12AM -0800, Steve Ellcey wrote:
I am going to check in this testsuite patch as an obvious fix. We should make
sure a platform supports PIC before compiling with the -fpic flag.
2013-03-01 Steve Ellcey sell...@mips.com
* gcc.dg/pr56396.c: Require pic
Two patches attached.
The reqs-parsing patch adds parsing support for template requirements
(i.e., requires clauses). This is supported for all template
declarations and non-template member functions of class templates.
Grammar changes are documented in comments. Semantic processing of
Committed after regtesting as Rev. 196387. (I forgot to mention that it
fixes PR56491)
http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00024.html
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 196386)
+++
On Fri, 1 Mar 2013, Tobias Burnus wrote:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01106.html
OK, though for the libiberty patch it would be good if someone can find
the make-obstacks-texi.sh script referred to in libiberty.texi, check it
in and get obstacks.texi exactly in sync with the
On Fri, Mar 1, 2013 at 10:12 AM, Andrew Sutton
andrew.n.sut...@gmail.com wrote:
Two patches attached.
The reqs-parsing patch adds parsing support for template requirements
(i.e., requires clauses). This is supported for all template
declarations and non-template member functions of class
On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor i...@google.com wrote:
On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary
On Fri, Mar 1, 2013 at 9:34 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor i...@google.com wrote:
On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak ubiz...@gmail.com wrote:
Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1],
On Fri, Mar 1, 2013 at 7:26 PM, Ian Lance Taylor i...@google.com wrote:
Right now the reflect.Call implementation is passing Go complex64 and
complex128 types as though they were implemented as struct { float32;
float32 } and struct { float64; float64 } respectively. The code
assumes that a
I have a few more distributions to be added. The triangle
distribution is the result of combining to uniform distributions and
therefore quite frequently used. The von Mises distribution (the
simple, 2D version) would be the first circular distribution.
The patch depends on the __math_constants
Joseph S. Myers wrote:
OK, though for the libiberty patch it would be good if someone can find
the make-obstacks-texi.sh script referred to in libiberty.texi, check it
in and get obstacks.texi exactly in sync with the output of that script
run on current glibc sources.
I couldn't find it, but
On Fri, Mar 1, 2013 at 10:50 AM, Uros Bizjak ubiz...@gmail.com wrote:
No problem for me, the attached patch was re-tested with libgo tests
on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu {,-m32} without
errors.
Committed with slightly different error messages, like so.
Thanks.
Ian
Hi!
This fixes leaks like
==31176== 176 bytes in 2 blocks are definitely lost in loss record 432 of 541
==31176==at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31176==by 0x114DF6F: xrealloc (xmalloc.c:177)
==31176==by 0x85E0AA: void
LRA branch was merged with trunk @ r196386.
The branch was successfully bootstrapped on x86 and x86-64.
Committed as rev. 196390.
Hi!
Except for the case when we set vec_oprnd1 to non-NULL, with j == 0
we always initialize vec_oprnds[01] with vect_get_vec_defs, which overwrites
the vectors rather than just filling them. So we shouldn't allocate the
vectors first.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok
Hi!
For the modifier == NONE !slp_node case we call vect_get_vec_defs, so
we overwrite vec_oprnds0, thus we shouldn't allocate it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
*
Hi!
When merging partitions together, we remove them from partitions vector,
thus don't free them at all. Fixed thusly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
*
Hi!
When I've tried --enable-checking=valgrind bootstrap recently, it failed
as soon as compiling first PCH header. The problem is that in
ggc_internal_alloc_stat we often increase the requested size through
ggc_round_alloc_size_1 (size, order, object_size);
and there is no way to query the
Hi!
This patch fixes various memory leaks in libcpp during PCH writing.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* files.c (_cpp_save_file_entries): Free result at the end.
*
Hi!
path vector has been only released when return false; later in the function,
but not in this case. Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-ssa-loop-ivcanon.c
Hi!
When ira_destroy is called, often (always?) this is after
loop_optimize_finalize call and thus current_loops is NULL, which results in
only freeing ira_loop_nodes[0] and not ira_loop_nodes[1] and above (if any).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
Hi!
The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies 1, we'd leak the result_chain vector too.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-03-01 Jakub Jelinek
Hi!
4.7 did here:
VEC_free (tree, heap, *vec_oprnds0);
*vec_oprnds0 = vec_tmp;
so vec_oprnds0-truncate (0) doesn't match that, and leaks memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR
On Fri, Mar 1, 2013 at 3:10 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
4.7 did here:
VEC_free (tree, heap, *vec_oprnds0);
*vec_oprnds0 = vec_tmp;
so vec_oprnds0-truncate (0) doesn't match that, and leaks memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
Jakub == Jakub Jelinek ja...@redhat.com writes:
Jakub 2013-03-01 Jakub Jelinek ja...@redhat.com
Jakub PR middle-end/56461
Jakub * files.c (_cpp_save_file_entries): Free result at the end.
Jakub * pch.c (cpp_string_free): New function.
Jakub (cpp_save_state): Use it in htab_create call.
The branch was merged with trunk @ r196387.
The branch was successfully bootstrapped on x86 and x86-64.
Committed as rev. 196391.
On 03/01/2013 01:23 PM, Jakub Jelinek wrote:
Hi!
The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies 1, we'd leak the result_chain vector too.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
On 03/01/2013 01:21 PM, Jakub Jelinek wrote:
Hi!
When ira_destroy is called, often (always?) this is after
loop_optimize_finalize call and thus current_loops is NULL, which results in
only freeing ira_loop_nodes[0] and not ira_loop_nodes[1] and above (if any).
Fixed thusly,
On 03/01/13, Ulrich Drepperdrep...@gmail.com wrote:
I have a few more distributions to be added. The triangle
distribution is the result of combining to uniform distributions and
therefore quite frequently used. The von Mises distribution (the
simple, 2D version) would be the first circular
The following patch limit the depth for post-dom walk in the analysis
-- in the presence of complicated control flow, the analysis should
bail out sooner.
Bootstrapped on x86-64/linux. No regressions found. OK for trunk?
thanks,
David
2013-03-01 Xinliang David Li davi...@google.com
*
On 03/01/2013 01:18 PM, Jakub Jelinek wrote:
Hi!
path vector has been only released when return false; later in the function,
but not in this case. Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2013-03-01 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
I'm checking in this patch to include/dwarf2.h, which was approved on binutils.
-cary
include/
* dwarf2.h (enum dwarf_sect): New enum type.
RCS file: /cvs/src/src/include/dwarf2.h,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- src/include/dwarf2.h
Jakub and Aldy,
It looks like I am having another problem with this patch. Jakubs earlier
patch fixed things
for me when building my mips-mti-elf target but I just started building glibc
in mips16 mode
with the latest compiler and I am running into this assert:
mktime.c:147:1: internal
On 03/01/2013 04:12 PM, Xinliang David Li wrote:
The following patch limit the depth for post-dom walk in the analysis
-- in the presence of complicated control flow, the analysis should
bail out sooner.
Bootstrapped on x86-64/linux. No regressions found. OK for trunk?
thanks,
David
On Wed, 27 Feb 2013, Jack Howarth wrote:
No, these are additional instances of the @item instead of @itemx change
which exist in gcc-4_6-branch and gcc-4_7-branch but not gcc trunk. There
is one extra instance in gcc-4_7-branch compared to gcc-4_6-branch...
Ahh, sorry for missing that. And
On Mon, 18 Feb 2013, Richard Biener wrote:
pBefore reporting that GCC compiles your code incorrectly, compile it
with codegcc -Wall -Wextra/code and see whether this shows anything
wrong with your code. Similarly, if compiling with
code-fno-strict-aliasing -fwrapv/code makes a
On Fri, Mar 1, 2013 at 5:55 PM, 3dw...@verizon.net wrote:
I was looking at a paper: Modeling Data using Directional Distributions by
Inderjit S. Dhillon and Suvrit Sra that looks
like it would be very similar to your multi-variate normal distribution.
These generalize von Mises to higher
60 matches
Mail list logo
