I understand that the literal operators for complex numbers for C++14
faltered at least in part because of the perceived ugliness of the float
operator:
constexpr complexfloat
operator i_f(); // fugly
The obvious choice
constexpr complexfloat
operator if();
failed because 'if' is a
Ed Smith-Rowland 3dw...@verizon.net writes:
constexpr complexfloat
operator if();
According to 2.14.8#10 this is ill-formed.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely
On 18 June 2013 07:04, Ed Smith-Rowland wrote:
I understand that the literal operators for complex numbers for C++14
faltered at least in part because of the perceived ugliness of the float
operator:
constexpr complexfloat
operator i_f(); // fugly
The obvious choice
constexpr
On 18 June 2013 08:35, Andreas Schwab wrote:
According to 2.14.8#10 this is ill-formed.
It's ill-formed for users to define it, but not ill-formed according
to the language grammar, and the compiler would need to implement that
grammar if operatorif gets added to the standard library (which
On 06/18/13, Jonathan Wakelyjwakely@gmail.com wrote:
On 18 June 2013 07:04, Ed Smith-Rowland wrote:
I understand that the literal operators for complex numbers for C++14
faltered at least in part because of the perceived ugliness of the float
operator:
constexpr complexfloat
If I'm running into
/* Figure out which alternative currently matches. */
if (! constrain_operands (1))
fatal_insn_not_found (insn);
'insn does not satisfy its constraints'
By the way, the instruction is
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
Little more information:
From lreg:
[..]
(insn 31 30 44 0 0x2cf51000 (set (mem/s:DI (plus:SI (reg:SI 884)
(symbol_ref:SI (acpi_lr_stat))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(const_int 0 [0x0])) 67 {*movdi} (insn_list 26 (nil))
(expr_list:REG_DEAD (reg:SI
On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote:
I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8. Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are seeing.
For me, all of the
Peter Bergner berg...@vnet.ibm.com writes:
I have yet to track down who has the write lock and why, but I am working
towards that. Talking with Andreas, he said he is seeing the same failure
on S390, so I'm wondering whether this might be a generic libitm issue
and it might hit Intel too.
On Tue, 2013-06-18 at 11:22 -0700, Andi Kleen wrote:
Peter Bergner berg...@vnet.ibm.com writes:
I have yet to track down who has the write lock and why, but I am working
towards that. Talking with Andreas, he said he is seeing the same failure
on S390, so I'm wondering whether this might
On Tue, 2013-06-18 at 18:41 +0200, Torvald Riegel wrote:
On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote:
I'll note that if I hack the call to
htm_abort_should_retry(ret) so that we break of of the loop and fallback
to SW TM, then the test case executes correctly.
That matches
Given Torvald's comment, can you verify whether your hw txn succeeds
(all the way to commit) or whether it is failing and somehow skips
the fall through code that is hanging for us (Power and S390)?
All the 3 transactions in reentrant.c abort. That's not surprising,
because there are usually
On Tue, Jun 18, 2013 at 8:43 AM, Hendrik Greving
hendrik.greving.in...@gmail.com wrote:
If I'm running into
/* Figure out which alternative currently matches. */
if (! constrain_operands (1))
fatal_insn_not_found (insn);
'insn does not satisfy its constraints'
By the way, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
--- Comment #1 from Stefan Sørensen stefan at astylos dot dk ---
Created attachment 30318
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30318action=edit
Simple testcase that triggers the ICE when built with -Os -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com ---
(In reply to Richard Biener from comment #1)
I don't think it works that way, hidden visibility makes it non-exported from
the dynamic object but it's still visible inside the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Dmitry G. Dyachenko dimhen at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Tue Jun 18 07:41:19 2013
New Revision: 200163
URL: http://gcc.gnu.org/viewcvs?rev=200163root=gccview=rev
Log:
PR c/57630
* c-decl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
I am testing
Index: lto-symtab.c
===
--- lto-symtab.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Thanks, Zhenqiang.
For me, it's a segfault in function DGETF2. gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0001d964 in dgetf2_ ()
(gdb) bt
#0 0x0001d964 in dgetf2_ ()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se ---
Created attachment 30319
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30319action=edit
reduced test case
Still ICEs 4.9-20130616, 4.8-20130613, and 4.7-20130615. Needs -O1 (or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
Bug 57483 depends on bug 57334, which changed state.
Bug 57334 Summary: [4.9 regression] ICE: in input_gimple_stmt, at
gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617
Nick Maclaren nmm1 at cam dot ac.uk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
--- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk ---
Because of the last comment, I am not going to close this as resolved,
invalid, but please do so if appropriate.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
--- Comment #2 from vijay Nag vijunag at gmail dot com ---
With the compiler flag -fno-var-tracking, it compiles in less than a minute.
Although it is quite conspicuous from back-trace I thought it is worth
mentioning this info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Bug ID: 57641
Summary: std::timed_mutex.try_lock_until() is broken
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I agree that code assumes the epochs are the same, but what you describe
doesn't make sense since high_resolution_clock and steady_clock have the same
epoch in our implementation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #2 from Hristo Venev mustrumr97 at gmail dot com ---
Am I very stupid, or is
#include mutex
#include chrono
using Clock=std::chrono::steady_clock;
int main(){
std::timed_mutex m;
m.lock();
Clock::time_point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Testcase using clock with an earlier epoch:
#include chrono
#include thread
#include mutex
#include assert.h
namespace C = std::chrono;
struct clock
{
typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
It's undefined behaviour because you try to lock the same mutex twice in the
same thread, see my testcase for a well-defined way to do it, calling
try_lock_until in a new thread.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Bug ID: 57642
Summary: vectorizer not working with function templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
--- Comment #1 from Yale Zhang yzhang1985 at gmail dot com ---
I would like to know if there's an easy work around for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643
Bug ID: 57643
Summary: libitm.c/reentrant.c hangs on POWER8 with HTM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609
Jan-Benedict Glaw jbg...@lug-owl.de changed:
What|Removed |Added
CC||jbg...@lug-owl.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Yale Zhang yzhang1985 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.2
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #2)
Patch works great for me and passes testing. Are you going to submit it? In
fact, I don't think you really need an approval.
If you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
No problem, patch sent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Works for me, could be marker as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644
Bug ID: 57644
Summary: [C++1y] Cannot bind bitfield to lvalue reference
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
Bug ID: 57645
Summary: Explicitly-declared destructor with no exception
specification is always noexcept(true)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57646
Bug ID: 57646
Summary: bogus warning about uninitialized ‘saved_stack.1’ with
gotos and VLAs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
2013/6/16 Ondřej Bílka nel...@seznam.cz:
On Sat, Jun 15, 2013 at 05:13:31PM +0800, Chung-Ju Wu wrote:
2013/6/14 Joseph S. Myers jos...@codesourcery.com:
On Thu, 13 Jun 2013, Richard Biener wrote:
Btw, rather than these kind of patches I'd appreciate if someone would
look
at a simple
On Mon, Jun 17, 2013 at 07:59:15PM -0500, Aldy Hernandez wrote:
As discussed on IRC. Attached are these changes you requested, plus
changing OMP_CLAUSE__SIMDUID__UID to OMP_CLAUSE__SIMDUID__DECL.
I will tackle the dot named builtins in the next iteration.
Thanks.
---
On Mon, Jun 17, 2013 at 6:54 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
The following patch shows a performance regression caused by the C++ changes
to evaluate side-effects in x += foo (); first and only then do the
addition. Previously if x
Hi all,
This patch adjusts a number of patterns in arm.md for the IT block rules
in -mrestrict-it. The changes are mostly straightforward, disabling the
cond_exec version for -mrestrict-it in some cases and adding
alternatives that can produce a 16-bit encoding in others.
Bootstrapped on
On 13/6/18 上午3:05, Sandra Loosemore wrote:
Ping? I think these are the most recent versions of the unreviewed
patches in the series:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00287.html
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00760.html
Hi,
During expand, function vcondmodemode inverses some CMP, e.g.
a LE b - b GE a
But if b is CONST0_RTX, b GE a will be an illegal insn.
(insn 933 932 934 113 (set (reg:V4SI 1027)
(unspec:V4SI [
(const_vector:V4SI [
(const_int 0 [0])
Hi,
the patch replaces next_real_insn with next_active_insn when checking
for JUMP TABLE insns.
This fixes ESA mode bootstrap on s390 which broke with r197266.
Comitted to mainline
Bye,
-Andreas-
2013-06-18 Andreas Krebbel andreas.kreb...@de.ibm.com
PR target/57609
*
On Tue, Jun 18, 2013 at 10:57 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the patch replaces next_real_insn with next_active_insn when checking
for JUMP TABLE insns.
This fixes ESA mode bootstrap on s390 which broke with r197266.
Comitted to mainline
Please revert this and
2013/6/18 Steven Bosscher stevenb@gmail.com:
On Tue, Jun 18, 2013 at 10:57 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the patch replaces next_real_insn with next_active_insn when checking
for JUMP TABLE insns.
This fixes ESA mode bootstrap on s390 which broke with
On Tue, Jun 18, 2013 at 11:29 AM, Chung-Ju Wu wrote:
Do you mean that your comment 6 in PR56809 is not a good solution
since you are going to remove JUMP_TABLE_DAT from active_insn_p ??
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809
No, that one I'll fix, it's fall-out from the
On 06/18/13 09:50, Zhenqiang Chen wrote:
Hi,
During expand, function vcondmodemode inverses some CMP, e.g.
a LE b - b GE a
But if b is CONST0_RTX, b GE a will be an illegal insn.
(insn 933 932 934 113 (set (reg:V4SI 1027)
(unspec:V4SI [
(const_vector:V4SI [
On Mon, Jun 17, 2013 at 6:11 PM, Jakub Jelinek ja...@redhat.com wrote:
This instruction has the predicates/constraints wrong, the r/m argument is
the middle-one, the value from which it should be extracted, rather than
the packed start/length argument. This got broken with PR50766, where the
On Tue, Jun 18, 2013 at 11:47:29AM +0200, Uros Bizjak wrote:
On Mon, Jun 17, 2013 at 6:11 PM, Jakub Jelinek ja...@redhat.com wrote:
This instruction has the predicates/constraints wrong, the r/m argument is
the middle-one, the value from which it should be extracted, rather than
the
This fixes PR57334, properly merging the chain of symtab nodes
sharing the same assembler name.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-06-18 Richard Biener rguent...@suse.de
PR lto/57334
* lto-symtab.c
Thanks,
Julian
ChangeLog
gcc/
* config/arm/arm.c (neon_vector_mem_operand): Add strict argument.
Permit virtual register pre-reload if !strict.
(coproc_secondary_reload_class): Adjust for neon_vector_mem_operand
change.
* config/arm/arm-protos.h
On Mon, 17 Jun 2013, Andi Kleen wrote:
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious reported problems.
-Andi
backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c:
Hello Chung-Ju,
On 06/18/2013 05:12 AM, Chung-Ju Wu wrote:
2013/6/18 David Edelsohn dje@gmail.com:
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber sebastian.hu...@embedded-brains.de
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
Okay.
Thanks, David
P.S. Please
Hi,
On 06/08/2013 10:57 AM, Paolo Carlini wrote:
Hi,
the bug reminds us to update the documentation about the value of
__cplusplus. I tentatively prepared the below, is it clear enough?
We could probably apply something to the branch too, without the
-std=c++1y bits, thus end simply like
Ping?
On Mon, Jun 10, 2013 at 2:13 PM, Igor Zamyatin izamya...@gmail.com wrote:
Hi!
This patch mentions support of Silvermont architecture in the
gcc-4.9/changes.html page.
OK to install?
Thanks,
Igor
Index: htdocs/gcc-4.9/changes.html
On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo oleg.e...@t-online.de wrote:
On Mon, 2013-06-17 at 10:41 +0200, Eric Botcazou wrote:
My mistake. It's because arm_legitimize_address cannot re-factor [r105 +
r165*4 + (-2064)] into rx = r105 + (-2064); [rx + r165*4]. Do you
suggest that this kind
On Tue, Jun 18, 2013 at 11:51 AM, Jakub Jelinek ja...@redhat.com wrote:
This instruction has the predicates/constraints wrong, the r/m argument is
the middle-one, the value from which it should be extracted, rather than
the packed start/length argument. This got broken with PR50766, where
On Mon, 17 Jun 2013, Andi Kleen wrote:
Richard Biener rguent...@suse.de writes:
Andi Kleen a...@firstfloor.org wrote:
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious
Ping.
Th patch is OK, thanks!
I see you added gcov.exp file support, do you have a testcases?
Honza
When I fixed PR57630, I failed to adjust the expected message in
gcc.dg/c90-fordecl-1.c test (sorry for that); so we regressed. Fixed
thusly, will commit as obvious.
Tested with make check-gcc RUNTESTFLAGS=dg.exp=c90-fordecl-1.c
2013-06-18 Marek Polacek pola...@redhat.com
*
On 18/06/13 11:35, Steven Bosscher wrote:
On Tue, Jun 18, 2013 at 11:29 AM, Chung-Ju Wu wrote:
Do you mean that your comment 6 in PR56809 is not a good solution
since you are going to remove JUMP_TABLE_DAT from active_insn_p ??
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809
No, that one
Hello!
Attached patch initializes return variable in get_fpu_except_flags.
Additionally, it uses __asm__ and __volatile__ consistently, as
recommended for header files and unifies a bunch of formatting issues
throughout the file.
2012-06-18 Uros Bizjak ubiz...@gmail.com
*
It is not necessary to maintain the pointer-map from cache entry to
cache index when reading trees. A quick estimate using the latest
WPA stats from firefox estimates its size to at least 1.5GB - apart
from the cost to maintain it. So the following patch makes it
possible to not maintain that
On Tue, Jun 18, 2013 at 10:59:56AM +0200, Steven Bosscher wrote:
On Tue, Jun 18, 2013 at 10:57 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the patch replaces next_real_insn with next_active_insn when checking
for JUMP TABLE insns.
This fixes ESA mode bootstrap on s390
Hi,
This is the first of a series of patches to implement a single, unified and
fine grained instruction classification attribute.
The first few patches will propose a refactoring of the instruction
classifications we currently have in place.
This first patch moves the multiplication and
On 18/06/13 13:33, Sofiane Naci wrote:
Hi,
This is the first of a series of patches to implement a single, unified and
fine grained instruction classification attribute.
The first few patches will propose a refactoring of the instruction
classifications we currently have in place.
This first
On Sun, 16 Jun 2013, Joern Rennecke wrote:
Quoting Eric Botcazou ebotca...@adacore.com:
Could you also check that your patch also fixes PR opt/57569 and, if so, add
the reference to the ChangeLog as well as the testcase?
Attached is what I'm currently testing. bootstrap on
On Tue, Jun 18, 2013 at 12:12 AM, Alan Modra amo...@gmail.com wrote:
I'd like to apply the following set of patches supporting powerpc64le
to the 4.8 branch. David has stated that he's happy with the idea,
even though technically these are not regressions. OK?
On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo oleg.e...@t-online.de wrote:
My observation is, that legitimizing addressing modes in the backend by
looking at one isolated address works, but doesn't give good results.
In the SH backend there
This fixes the mv?.C ICEs in the testsuite (and transforms a subset
of them to execute fails for me).
Running target unix/
FAIL: g++.dg/ext/mv12.C -std=gnu++98 execution test
FAIL: g++.dg/ext/mv12.C -std=gnu++11 execution test
FAIL: g++.dg/ext/mv2.C -std=gnu++98 execution test
FAIL:
make oldconfig
make CC=gcc LD=ld-from-linux-binutils AR=gcc-ar -j ..
Ok, it doesn't use LTO for me, not even with adding CFLAGS=-O2 -flto
here.
Can you send me a build log with V=1 ?
There are some checks for the environment at the beginning, maybe they fail.
-Andi
--
On 06/17/2013 08:21 PM, Paolo Carlini wrote:
I see... There is a little difficulty in that 56794 involves a non-type
variadic parameter and in that case type_dependent_expression_p returns
false. If I use value_dependent_expression_p things work, but I'm not
sure it's 100% correct.
I don't
This makes us use a pointer-map for the hashtable in lto_tree_ref_encoder
which avoids gazillion of malloc/free calls.
LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-06-18 Richard Biener rguent...@suse.de
* Makefile.in (LTO_STREAMER_H): Add
Hi,
On 06/18/2013 04:15 PM, Jason Merrill wrote:
On 06/17/2013 08:21 PM, Paolo Carlini wrote:
I see... There is a little difficulty in that 56794 involves a non-type
variadic parameter and in that case type_dependent_expression_p returns
false. If I use value_dependent_expression_p things
Hi,
This patch updates the documentation for type attribute. It complements
the changes proposed in the previous patch
OK for trunk?
-
Thanks
Sofiane
arm-update-insn-class-doc.diff
Description: Binary data
On Mon, Jun 17, 2013 at 06:01:10PM +0200, Jakub Jelinek wrote:
On Mon, Jun 17, 2013 at 03:52:54PM +, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
+; What the sanitizer should instrument
+Variable
+unsigned int flag_sanitize
Can't you just add
Hi,
The following patch removed pool_range/neg_pool_range attributes from
several instructions as a cleanup, which I believe to have been
incorrect:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01036.html
On a Mentor-local branch, this caused problems with instructions like:
(insn 77 53 87
On 18/06/13 16:42, Julian Brown wrote:
Hi,
The following patch removed pool_range/neg_pool_range attributes from
several instructions as a cleanup, which I believe to have been
incorrect:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01036.html
On a Mentor-local branch, this caused problems
That suggests
Index: gcc/expr.c
===
--- gcc/expr.c (revision 200164)
+++ gcc/expr.c (working copy)
@@ -9353,7 +9353,7 @@ expand_expr_real_1 (tree exp, rtx target
/* Variables inherited from containing functions
Ping.
On 06/06/2013 01:23 PM, Meador Inge wrote:
On 06/06/2013 08:11 AM, Richard Earnshaw wrote:
I understand (and agree with) this bit...
+(define_peephole2
+ [(set (reg:CC CC_REGNUM)
+(compare:CC (match_operand:SI 0 register_operand )
+(match_operand:SI 1
Richard Biener rguent...@suse.de writes:
It is not necessary to maintain the pointer-map from cache entry to
cache index when reading trees. A quick estimate using the latest
WPA stats from firefox estimates its size to at least 1.5GB - apart
from the cost to maintain it. So the following
Hi,
I checked in this patch to fix a typo in comments in config/i386/i386.c.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 200173)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-06-18 H.J. Lu hongjiu...@intel.com
On Tue, Jun 18, 2013 at 3:28 AM, Jan Hubicka hubi...@ucw.cz wrote:
Ping.
Th patch is OK, thanks!
I see you added gcov.exp file support, do you have a testcases?
Yes, I added support for verifying intermediate format in gcov.exp. I
also added a minimal testcase for intermediate format in
On Tue, Jun 18, 2013 at 2:17 PM, Andreas Krebbel wrote:
If you don't want me to use next_active_insn I probably have to do
something like this instead:
No. If the label is followed by jump table data, then NEXT_INSN(label)
will be the JUMP_TABLE_DATA rtx. See tablejump_p.
So the following
Just confirmed with the small build. It does. Running the large build
now.
Large build worked too.
Please check in.
1 - 100 of 117 matches
Mail list logo
