.. on the other hand, the below is a case which my patchlet, which
simply tracks pointers, does *not* handle correctly:
struct B { };
template struct A { };
A*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 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 trunk?
>
> gcc/
>
On Fri, Aug 22, 2014 at 1:51 PM, Kirill Yukhin 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 "_storedqu_mask"
>
> It seems like such a trick won't work for
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 lib
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.
Boots
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 struct A { };
A*p = 42;
should be fixable by complicating a bit the tracking, telling apart
m
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
+++ gc
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
>
> * doc/invoke.texi: -fno-cxa-atexit should be -fno-use-cxa-atex
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson wrote:
>
>> +/* non default branch cost */
>> +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
>> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
>> powerpc*-*-* xtensa*-*-* hppa*-*-* nios2*-*-*"} }
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 table
On 08/23/2014 10:26 AM, Mike Stump wrote:
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson wrote:
+/* non default branch cost */
+/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* v850*-*-*
picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-*
xtens
On Aug 23, 2014, at 9:37 AM, Sandra Loosemore 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
> value >= 2.
Soun
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
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphit
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 wrote:
> Hello,
>
> This bug is an error recovery issue. A data declaration is pars
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 wrote:
> > >
> > > > +/* non default branch cost */
> > > > +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
> > > > v850*-*-* picochip*-
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
symtab_rem
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
Google ref b/17124135
* auto-profile.c (read_aux_modules):
On Wed, 2014-08-06 13:19:48 -0400, David Malcolm 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 (see eg. build
http:
Is it a problem specific to LIPO?
David
On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson 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
> symtab_remove_unreachable_nodes, wh
ok.
David
On Sat, Aug 23, 2014 at 11:42 AM, Teresa Johnson 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 Teresa Johnso
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 the
Ok for google branch.
David
On Sat, Aug 23, 2014 at 11:58 AM, Teresa Johnson 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 there is none. Trun
Andi Kleen writes:
PING^2 !
Would be nice to make slim bootstrap work, it really speeds it up quite
a bit.
> From: Andi Kleen
>
> 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 conventions
> implement the code by hand ins
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 __cplu
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 a
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_
2014-08-19 22:04 GMT+08:00 Vladimir Makarov :
> 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
>>
>> * ira.c: Fix typo in comment.
> Thanks, Kito. Of course, the patch is ok. You
2014-08-22 1:45 GMT+08:00 Joseph S. Myers :
> 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 call-saved regis
2014-08-07 1:22 GMT+08:00 David Malcolm :
> 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".
> ---
> gcc/config/nds32/n
33 matches
Mail list logo
