Since nobody else seemed to be working on finishing up variable template
support, I've gone ahead and done it. There were only a few tweaks needed.
For the pr59638.C issue, I'm throwing away the implicit template
parameter list before we call start_decl so we don't actually create an
.. on the other hand, the below is a case which my patchlet, which
simply tracks pointers, does *not* handle correctly:
struct B { };
template class T struct A { };
Avoid(B::*)()const*p = 42;
should be fixable by complicating a bit the tracking, telling apart
member pointers.
Paolo.
On Fri, Aug 22, 2014 at 12:15 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
This patch extends shift patterns with per-element
shift value. It was adopted by approach suggested
in previous patches.
Bootstrapped.
New tests on top of patch-set all pass
under simulator.
Is it ok for
On Fri, Aug 22, 2014 at 1:51 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
This patch extends unaligned loads and stores patterns.
I've refactored original patch (stored on SVN's branch)
toward reducing complexity of conditions in
define_insn avx512_storedqumode_mask
It seems like
Hi,
The problem here is that builtin macros are marked with NO_WARN flag
depending on the value of Wbuiltin-macro-redefined, but this only
happens during libcpp initialization, so it doesn't work for #pragmas.
It neither works when using CPP(), since the default in the c.opt file
is set before
Hi,
Please find an update of test results for 4.8.x
Test Results for 4.8.3:
aarch64-unknown-linux-gnu
Best Regards,
Raghunath Lolur.
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving
Hi,
this patch fixes a defect Jan found with firefox and its shared objects. We
were inadvertently calling an externally visible and overridable symbol, rather
than the local shared object's instance. This led to strangely sparse gcov results.
I've taken the STRONG_ALIAS #define from glibc.
Hello,
This bug is an error recovery issue. A data declaration is parsed and
accepted, and added to gfc_current_ns-data, but the statement is
rejected. The rejected data decl is not rolled back, causing memory
corruption later on.
Proposed fix is to roll back DATA for rejected statements.
Hi again,
On 08/23/2014 09:16 AM, Paolo Carlini wrote:
.. on the other hand, the below is a case which my patchlet, which
simply tracks pointers, does *not* handle correctly:
struct B { };
template class T struct A { };
Avoid(B::*)()const*p = 42;
should be fixable by complicating a bit the
Applied.
Gerald
Index: gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.78
diff -u -r1.78 changes.html
--- gcc-4.9/changes.html16 Jul 2014 09:51:24 - 1.78
+++
On Mon, 18 Aug 2014, Joel Sherrill wrote:
I think this is a minor documentation bug which is in the head but also
seems to be in the gcc 4.4.7 docs shipped with CentOS 6.x.
OK to commit?
2014-08-18 Joel Sherrill joel.sherr...@oarcorp.com
* doc/invoke.texi: -fno-cxa-atexit should be
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
+/* non default branch cost */
+/* { dg-do run { target { ! m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
powerpc*-*-* xtensa*-*-* hppa*-*-*
The attached change fixes the PR. This problem affects building
texmaker and a few other Debian
packages.
The code in pa_asm_output_mi_thunk originally checked whether the
function was reachable with
a pc-relative branch, but the assembler complains if the branch can't
reach the stub
On 08/23/2014 10:26 AM, Mike Stump wrote:
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
+/* non default branch cost */
+/* { dg-do run { target { ! m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
On Aug 23, 2014, at 9:37 AM, Sandra Loosemore san...@codesourcery.com wrote:
If we're going to go through the trouble of adding a comment here, we might
as well make it something less terse and more explicit, like:
These tests fail unless the target backend overrides BRANCH_COST to return a
I see two regressions after r214069 on x86_64-apple-darwin13 for both -m32 and
-m64:
(1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect vectorized
2 loops 1
before I saw
[Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect
Dear Steven,
I am constantly amazed that data statement bugs keep turning up:-)
Anyway, your fix is fine for trunk and, if you feel so inclined, 4.8
and 4.9.
Thanks
Paul
On 23 August 2014 16:52, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This bug is an error recovery issue. A data
On 08/22/2014 04:36 PM, Jason Merrill wrote:
OK, thanks.
Jason
Committed 214400.
Attached patch is the one committed.
Thanks.
libcpp/
2014-08-23 Edward Smith-Rowland 3dw...@verizon.net
* include/cpplib.h (enum c_lang): Add CLK_GNUCXX1Z, CLK_CXX1Z;
Rename CLK_GNUCXX1Y,
On Sat, 23 Aug 2014, Sandra Loosemore wrote:
On 08/23/2014 10:26 AM, Mike Stump wrote:
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
+/* non default branch cost */
+/* { dg-do run { target { ! m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-*
This patch ensures we don't prematurely delete an abstract origin node, leading
to creating a new one after LIPO linking when we invoke similar handling in
symtab_remove_unreachable_nodes, which then does not have a resolved node. It
makes the handling of such nodes equivalent to that in
Fixes seg fault when using -fopt-info with AutoFDO LIPO. Ensure that the
mapping between module name and ident is setup.
Tested with regression tests and internal benchmarks. Ok for google/4_9
2014-08-23 Teresa Johnson tejohn...@google.com
Google ref b/17124135
*
On Wed, 2014-08-06 13:19:48 -0400, David Malcolm dmalc...@redhat.com wrote:
This is further scaffolding; convert the BB_* and SET_BB_* macros
into functions. Convert the BB_* rvalue-style functions into returning
rtx_insn * rather than plain rtx.
[...]
This gave some fallout for frv-linux
Is it a problem specific to LIPO?
David
On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson tejohn...@google.com wrote:
This patch ensures we don't prematurely delete an abstract origin node,
leading
to creating a new one after LIPO linking when we invoke similar handling in
ok.
David
On Sat, Aug 23, 2014 at 11:42 AM, Teresa Johnson tejohn...@google.com wrote:
Fixes seg fault when using -fopt-info with AutoFDO LIPO. Ensure that the
mapping between module name and ident is setup.
Tested with regression tests and internal benchmarks. Ok for google/4_9
2014-08-23
The ICE is, because we create a new node when querying the node during
symtab_remove_unreachable_nodes after LIPO linking is complete, and
then try to access its resolved node, for which there is none. Trunk
has the same code in these two locations, but the creation of a new
node after deleting
Ok for google branch.
David
On Sat, Aug 23, 2014 at 11:58 AM, Teresa Johnson tejohn...@google.com wrote:
The ICE is, because we create a new node when querying the node during
symtab_remove_unreachable_nodes after LIPO linking is complete, and
then try to access its resolved node, for which
Andi Kleen a...@firstfloor.org writes:
PING^2 !
Would be nice to make slim bootstrap work, it really speeds it up quite
a bit.
From: Andi Kleen a...@linux.intel.com
To use gcc-{ar,ranlib} for boot strap we need to add a -B option
to the tool. Since ar has weird and unusual argument
Based on my quick tests with it, it seems to me that we need more
tests for static member variable templates. My first attempt at something
like that gave an ICE...
With revision 214400 we have the C++14 value of __cplusplus set to the
correct value of 201402L (from 201300L).
We should use this in the std lib headers. This patch does this.
Also, we've set C++14 value of __cplusplus to 201500L so we can start
adding post-C++14 library bits with
#if
Hello world,
the attached patch uses the vec templates instead of the
home-grown memory management.
Did I get the style right? I was a bit confused because, with
the declarations used in the patch, using the vec_safe_truncate
function failed with a failure to find the right template.
I'm not an
On Sun, Aug 24, 2014 at 12:47:17AM +0200, Thomas Koenig wrote:
Hello world,
the attached patch uses the vec templates instead of the
home-grown memory management.
Did I get the style right? I was a bit confused because, with
the declarations used in the patch, using the vec_safe_truncate
2014-08-19 22:04 GMT+08:00 Vladimir Makarov vmaka...@redhat.com:
On 08/18/2014 10:51 AM, Kito Cheng wrote:
Hi Vladimir:
Here is a tiny typo in comment, allono - allocno.
ChangLog
2014-08-18 Kito Cheng k...@0xlab.org
* ira.c: Fix typo in comment.
Thanks, Kito. Of course, the
2014-08-22 1:45 GMT+08:00 Joseph S. Myers jos...@codesourcery.com:
On Thu, 21 Aug 2014, Richard Earnshaw wrote:
On 19/08/14 15:24, Kito Cheng wrote:
Hi Richard:
Hmm, I'm not sure about this. It might not be used at present, but on:
AArch64, with more call-clobbered registers than
2014-08-07 1:22 GMT+08:00 David Malcolm dmalc...@redhat.com:
gcc/
* config/nds32/nds32-protos.h (nds32_adjust_insn_length):
Strengthen first param from rtx to rtx_insn *.
* config/nds32/nds32.c (nds32_adjust_insn_length): Likewise for
param insn.
---
34 matches
Mail list logo
