On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers
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 compatible with the A
On 03/01/2013 05:15 AM, Ulrich Drepper wrote:
On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik wrote:
Not seeing it.
Say for:
#include
// A class for math constants.
template
struct __math_constants
{
// Constant @f$ \pi @f$.
static constexpr _RealType __pi
On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown 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 --
> maybe someone will hav
* 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:
This
On Thu, Feb 28, 2013 at 7:43 PM, Jakub Jelinek 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 separately.
>
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
-fsynt
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 TARGET_FIXED_CONDITION_RE
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 long_long_flo
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_rang
On Fri, Mar 1, 2013 at 12:38 PM, Eric Botcazou 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) != SSA_NAME);
>
> The pr
On Fri, 1 Mar 2013 11:07:17 +0100
Richard Biener wrote:
> On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown
> 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 t
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 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 TARGET_FIXED_CONDITION_CODE
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 introdu
> >> 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.
> Pleas
> > 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 nece
On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak 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 same as passi
On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor wrote:
> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak 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 pa
This patch enables C++11 and concepts support by default on the
c++-concepts branch.
-- Gaby
2013-03-01 Gabriel Dos Reis
* gcc/c-family/c-common.c (cxx_dialect): Set C++11 as default.
* gcc/c-family/c.opt(flag_concepts): Add.
* gcc/cp/lex.c (flag_concepts): New. Enab
On Fri, Mar 1, 2013 at 3:50 PM, Uros Bizjak 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 same a
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
* lex.c (flag_concepts): Revert left over declaration.
Index: gcc/cp/lex.c
===
--- gcc/
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
* gcc.dg/pr56396.c: Require pic support.
diff --git a/gcc/testsuite/gcc.dg/pr563
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
>
> * gcc.dg/pr56396.c: Require pic support.
O
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
constraints
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)
+++ gcc/f
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 o
On Fri, Mar 1, 2013 at 10:12 AM, Andrew Sutton
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 templates.
> Grammar chan
On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor wrote:
> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak 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 pa
On Fri, Mar 1, 2013 at 9:34 AM, Uros Bizjak wrote:
> On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor wrote:
>> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak wrote:
>>>
>>> Due to the fact that libFFI does not handle C99 _Complex arguments
>>> correctly [1], libgo passes Complex64 and Complex128 a
On Fri, Mar 1, 2013 at 7:26 PM, Ian Lance Taylor 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 function tha
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 I
On Fri, Mar 1, 2013 at 10:50 AM, Uros Bizjak 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
foo.patch
Descripti
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
va_heap::reserve(vec*&, unsigned int, bool) (vec.h
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 fo
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
PR middle-end/56461
* tree-vect-stmts.c (vectori
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
PR middle-end/56461
* tree-loop-distribution.c (ldist_gen): Ca
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 act
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
PR middle-end/56461
* files.c (_cpp_save_file_entries): Free result at the end.
* pch.c (cpp_string_fr
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
PR middle-end/56461
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Releas
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
trunk
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
PR middle-end/56461
On Fri, Mar 1, 2013 at 3:10 PM, Jakub Jelinek 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 for
> t
> "Jakub" == Jakub Jelinek writes:
Jakub> 2013-03-01 Jakub Jelinek
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.
Jakub> (cpp_write_pch_d
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 i686-l
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, bootstrapped/regtest
On 03/01/13, Ulrich Drepper 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 distribution.
The pa
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
* tree-ssa-uninit.c (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
PR middle-end/56461
* tree-ssa-l
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 2012/11
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 compile
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
2013-0
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. A
On Mon, 18 Feb 2013, Richard Biener wrote:
>> Before reporting that GCC compiles your code incorrectly, compile it
>> with gcc -Wall -Wextra and see whether this shows anything
>> wrong with your code. Similarly, if compiling with
>> -fno-strict-aliasing -fwrapv makes a difference, your co
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 high
60 matches
Mail list logo
