[C++14] Admit C++ keywords as literal suffixes.
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 keyword. The 'if' keyword can never be exposed
in this context either by usage in a literal or by explicit call.
Allowing keywords as literal operator suffixes turns out to be a 6-liner
if gcc. I actually think *disallowing* them is a bit of a bug. (Not
sure if it was me or the standard).
I don't know if that's the wording but I just wanted to offer a working
implementation of the idea.
Ed
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 200158)
+++ gcc/cp/parser.c (working copy)
@@ -12359,6 +12358,13 @@
return cp_literal_operator_id (name);
}
}
+ else if (token-type == CPP_KEYWORD)
+ {
+ id = ridpointers [(int) token-keyword];
+ cp_lexer_consume_token (parser-lexer);
+ const char *name = IDENTIFIER_POINTER (id);
+ return cp_literal_operator_id (name);
+ }
else
{
error (expected suffix identifier);
Re: [C++14] Admit C++ keywords as literal suffixes.
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 different.
Re: [C++14] Admit C++ keywords as literal suffixes.
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 complexfloat operator if(); failed because 'if' is a keyword. The 'if' keyword can never be exposed in this context either by usage in a literal or by explicit call. Allowing keywords as literal operator suffixes turns out to be a 6-liner if gcc. I actually think *disallowing* them is a bit of a bug. (Not sure if it was me or the standard). The standard disallowed them, but that was changed by DR 1473 so you can define operator if now (with no whitespace between the string-literal and suffix, IIUC) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473 IMHO you should implement exactly that resolution, not just a kluge to allow keywords.
Re: [C++14] Admit C++ keywords as literal suffixes.
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 could happen if an NB insists on the complex literals being in C++14, which can be done without the horrifically ugly i_f suffix now thanks to DR 1473.)
Re: Re: [C++14] Admit C++ keywords as literal suffixes.
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 operator i_f(); // fugly The obvious choice constexpr complexfloat operator if(); failed because 'if' is a keyword. The 'if' keyword can never be exposed in this context either by usage in a literal or by explicit call. Allowing keywords as literal operator suffixes turns out to be a 6-liner if gcc. I actually think *disallowing* them is a bit of a bug. (Not sure if it was me or the standard). The standard disallowed them, but that was changed by DR 1473 so you can define operator if now (with no whitespace between the string-literal and suffix, IIUC) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473 IMHO you should implement exactly that resolution, not just a kluge to allow keywords. I did not see this DR and that it passed. I just heard something was in the works. This resolution seems eminently sensible. I withdraw my kludge and will work on DR 1473 implementation. Thanks, Ed
reload_cse_simplify_operands
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])
(symbol_ref:SI (acpi_lr_stat))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
Asking abstractly, does this mean that I need to support more
constraints in movdi, or does it mean that reload did something wrong?
Thanks,
- Hendrik
Re: reload_cse_simplify_operands
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 884)
(nil)))
[..]
From greg:
(insn 31 30 325 0 0x2cf51000 (set (reg:DI 56 r56)
(const_int 0 [0x0])) 67 {*movdi} (insn_list 26 (nil))
(nil))
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
(symbol_ref:SI (acpi_lr_stat))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
- Hendrik Greving
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 instruction is
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
(symbol_ref:SI (acpi_lr_stat))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
Asking abstractly, does this mean that I need to support more
constraints in movdi, or does it mean that reload did something wrong?
Thanks,
- Hendrik
Re: Libitm issues porting to POWER8 HTM
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 libitm execution test cases in libitm/testsuite/libitm.c/ compile and execute without error, except for reentrant.c, which hangs for me. My gdb hasn't been ported to support HTM on Power yet, so debugging has been slow, but what I've learned is, that my tbegin. instruction succeeds, but I fail the test (meaning someone has the write lock) at beginend.cc:200: if (unlikely(serial_lock.is_write_locked())) htm_abort(); ...so we abort the transaction. The failure is not persistent, so we do not break out of the loop due to: if (!htm_abort_should_retry(ret)) break; We then fall into the following code, where we hang trying to get the read lock: serial_lock.read_lock(tx); 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. I think that this is a bug in libitm's HTM fastpath. What I suppose happens is that we have a relaxed outermost transaction that executes unsafe code (see reentrant.c), thus switches to serial-irrevocable mode, and then tries to start a nested transaction. The nested txn then observes in the HTM fastpath that there is a serial-mode txn already, but it never checks whether it is enclosed in an already serial outermost transaction. Does anyone know whether this executes correctly on Intel hardware with RTM? I don't know currently, but I suppose the bug should trigger there too (unless, for some reason, the nested txn always aborts immediately with RTM). 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 what I suppose the bug is. Please feel free to create a bug report. I will work on a patch. Torvald
Re: Libitm issues porting to POWER8 HTM
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. Does anyone know whether this executes correctly on Intel hardware with RTM? I'll note that if I hack the call to FWIW on a TSX system I get the following for libitm with current trunk. So no hangs on reentrant at least. Native configuration is x86_64-unknown-linux-gnu === libitm tests === Schedule of variations: unix Running target unix Running /home/ak/gcc/gcc/libitm/testsuite/libitm.c/c.exp ... PASS: libitm.c/cancel.c (test for excess errors) PASS: libitm.c/cancel.c execution test PASS: libitm.c/clone-1.c (test for excess errors) PASS: libitm.c/clone-1.c execution test PASS: libitm.c/dropref-2.c (test for excess errors) XFAIL: libitm.c/dropref-2.c execution test PASS: libitm.c/dropref.c (test for excess errors) XFAIL: libitm.c/dropref.c execution test PASS: libitm.c/memcpy-1.c (test for excess errors) PASS: libitm.c/memcpy-1.c execution test PASS: libitm.c/memset-1.c (test for excess errors) PASS: libitm.c/memset-1.c execution test PASS: libitm.c/notx.c (test for excess errors) PASS: libitm.c/notx.c execution test PASS: libitm.c/reentrant.c (test for excess errors) PASS: libitm.c/reentrant.c execution test PASS: libitm.c/simple-1.c (test for excess errors) PASS: libitm.c/simple-1.c execution test PASS: libitm.c/simple-2.c (test for excess errors) PASS: libitm.c/simple-2.c execution test PASS: libitm.c/stackundo.c (test for excess errors) PASS: libitm.c/stackundo.c execution test PASS: libitm.c/txrelease.c (test for excess errors) PASS: libitm.c/txrelease.c execution test Running /home/ak/gcc/gcc/libitm/testsuite/libitm.c++/c++.exp ... PASS: libitm.c++/dropref.C (test for excess errors) XFAIL: libitm.c++/dropref.C execution test PASS: libitm.c++/eh-1.C (test for excess errors) PASS: libitm.c++/eh-1.C execution test UNSUPPORTED: libitm.c++/static_ctor.C PASS: libitm.c++/throwdown.C (test for excess errors) === libitm Summary === # of expected passes26 # of expected failures 3 # of unsupported tests 1 -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: Libitm issues porting to POWER8 HTM
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 be a generic libitm issue and it might hit Intel too. Does anyone know whether this executes correctly on Intel hardware with RTM? I'll note that if I hack the call to FWIW on a TSX system I get the following for libitm with current trunk. So no hangs on reentrant at least. 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)? Thanks! Peter
Re: Libitm issues porting to POWER8 HTM
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 what I suppose the bug is. Please feel free to create a bug report. I will work on a patch. Done. http://gcc.gnu.org/PR57643 Since this seems to pass on x86, let me know if you want me to test a patch on our power8 system. Peter
Re: Libitm issues porting to POWER8 HTM
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 lots of aborts in the startup phase of programs, and the test doesn't use a loop. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: reload_cse_simplify_operands
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 instruction is
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
(symbol_ref:SI (acpi_lr_stat))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
Asking abstractly, does this mean that I need to support more
constraints in movdi, or does it mean that reload did something wrong?
It means that your predicate accepts operands that do not match your
constraints. So you need to support more constraints or you need to
tighten your predicates.
Ian
[Bug target/57636] cr16: ICE while building libgcc
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
[Bug lto/57613] [LTO] error multiple definition symbol for local symbol
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 object. You probably want to mark it local instead? You are right. Thanks for clarifcation
[Bug lto/57613] [LTO] error multiple definition symbol for local symbol
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 Resolution|--- |INVALID
[Bug c/57630] Error should include -std=c11 and friends
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 (check_for_loop_decls): Improve diagnostics messages. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug c/57630] Error should include -std=c11 and friends
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 Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
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 200151)
+++ lto-symtab.c(working copy)
@@ -523,7 +523,8 @@ lto_symtab_merge_decls (void)
FOR_EACH_SYMBOL (node)
if (lto_symtab_symbol_p (node)
-node-symbol.next_sharing_asm_name)
+(node-symbol.next_sharing_asm_name
+ || node-symbol.previous_sharing_asm_name))
{
symtab_node n;
@@ -639,6 +640,7 @@ lto_symtab_prevailing_decl (tree decl)
ret = symtab_node_for_asm (DECL_ASSEMBLER_NAME (decl));
if (!ret)
return decl;
+ gcc_checking_assert (TREE_PUBLIC (ret-symbol.decl) !DECL_EXTERNAL
(ret-symbol.decl));
return ret-symbol.decl;
}
The loop looks weird. It probably should be re-structured to a simple
FOR_EACH_SYMBOL (node)
if (!node-symbol.prev_sharing_asm_name
node-symbol.next_sharing_asm_name)
lto_symtab_merge_decls_1 (node);
and not put too much magic into it.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
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 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Which fixes the testcase, too. Giving it testing.
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
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_ () #1 0x000255a4 in dgetrf_ () #2 0x00015856 in sysnsl_ () #3 0x0001194e in MAIN__ () at galgel.f90:9 Looking further into it, the segfault seems to be from the function idamax that is inlined in dgetf2. Hope this helps, Kyrill
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
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 higher) -funroll-loops -m68000 (or -m68010). With -m68020 or higher it doesn't ICE. Suspect a target bug, so adding Andreas to cc: list.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
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 Resolution|--- |FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 18 09:56:59 2013 New Revision: 200165 URL: http://gcc.gnu.org/viewcvs?rev=200165root=gccview=rev Log: 2013-06-18 Richard Biener rguent...@suse.de PR lto/57334 * lto-symtab.c (lto_symtab_merge_decls): Process nodes properly. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-symtab.c
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
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 |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/57617] OpenMP critical does not seem to synchronise correctly
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 Resolution|--- |INVALID --- Comment #1 from Nick Maclaren nmm1 at cam dot ac.uk --- Brilliant. I had finger trouble with SSH. I do not know how I managed to look at the wrong version of the code for so long, but the update-in-critical failures for both compilers are my error. I shall change it to resolved but, if it resurfaces, it's my error. Sorry.
[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does
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.
[Bug rtl-optimization/57635] gcc hanging while compiling huge files
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.
[Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken
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: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mustrumr97 at gmail dot com It uses the duration since the time_point's clock's epoch. What if it's not the right clock? Different clocks may have different epochs. On my computer, the function works OK if the time_point is from high_resolution_clock but doesn't work if it's from steady_clock.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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. Are you seeing the first problem described at PR 54562? Do you have a testcase?
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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 tp=Clock::now()+std::chrono::seconds(2);
if(m.try_lock_until(tp)) return 1;
return 0;
}
supposed to run for ~2s and return 0?
With clang++ -stdlib=libc++ it works as I expect.
With clang++ -stdlib=libstdc++ and with g++ it returns 1 after 0.001s.
The result is the same for std::chrono::high_resolution_clock.
The test from cppreference.com is very similar.
http://en.cppreference.com/w/cpp/thread/timed_mutex/try_lock_until
What the hell is going on?
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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 C::system_clock::rep rep;
typedef C::system_clock::period period;
typedef C::system_clock::duration duration;
typedef std::chrono::time_pointclock time_point;
static constexpr bool is_steady = C::system_clock::is_steady;
static time_point now() {
return time_point(C::system_clock::now().time_since_epoch() +
C::seconds(10));
}
};
std::timed_mutex mx;
void f()
{
mx.try_lock_until(clock::now() + C::milliseconds(1));
}
int main()
{
std::lock_guardstd::timed_mutex l(mx);
auto start = C::system_clock::now();
std::thread t(f);
t.join();
auto stop = C::system_clock::now();
assert( (stop - start) C::seconds(9) );
}
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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 reconfirmed||2013-06-18 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- The timed mutex requirements [thread.timedmutex.requirements] say: The expression m.try_lock_until(abs_time) shall be well-formed and have the following semantics: Requires: If m is of type std::timed_mutex, the calling thread does not own the mutex. Anyway, confirming as there's a bug here relating to clocks with different epochs, but it's easy enough to fix, I can look into it. The same problem exists with the private mutex type defined in std::shared_mutex
[Bug tree-optimization/57642] New: vectorizer not working with function templates
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: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yzhang1985 at gmail dot com
Hi, the following simple loop doesn't vectorize in GCC 4.8.1, but does with
4.3.2. It does vectorize if I make DoIt a regular function instead of a
templated function.
#include iostream
#include math.h
#include emmintrin.h
#include stdint.h
#include nmmintrin.h
#include stdlib.h
class SqrtFunc
{
public:
float operator()(float x)
{
return (((3.02f * x) + 1.5f) * x - 2.1f) * x + 1.5f;
}
};
template typename Functor
void DoIt(float *data, int size, Functor functor)
{
for (int i = 0; i size; ++i)
{
data[i] = functor(data[i]);
}
}
int main()
{
float data[2048];
SqrtFunc functor;
DoIt(data, sizeof(data), functor);
return 0;
}
[Bug tree-optimization/57642] vectorizer not working with function templates
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.
[Bug libitm/57643] New: libitm.c/reentrant.c hangs on POWER8 with HTM
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: libitm Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org The libitm.c/reentrant.c test case hangs on POWER8 hardware with HTM. The symptoms I'm seeing are my tbegin. instruction succeeds, but we fail the test (meaning someone has the write lock) at beginend.cc:200: if (unlikely(serial_lock.is_write_locked())) htm_abort(); ...so we abort the transaction. The failure is not persistent, so we do not break out of the loop due to: if (!htm_abort_should_retry(ret)) break; We then fall into the following code, where we hang trying to get the read lock: serial_lock.read_lock(tx); 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. Andreas Krebbel said this fails on S390 as well. Andreas Kleen said this works on X86 with RTM. It's unknown whether on X86 whether its hw txn fails or succeeds or whether if it does fail over to sw txn, whether it skips the code we're hanging in.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#type error
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 dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Maybe this? It works for this testcase, but haven't run the testsuite. Index: pt.c === --- pt.c(revision 198545) +++ pt.c(working copy) @@ -16940,11 +16940,11 @@ unify (tree tparms, tree targs, tree par else if (uses_template_parms (tparm)) /* We haven't deduced the type of this parameter yet. Try again later. */ return unify_success (explain_p); else - return unify_type_mismatch (explain_p, tparm, arg); + return unify_type_mismatch (explain_p, tparm, TREE_TYPE (arg)); /* If ARG is a parameter pack or an expansion, we cannot unify against it unless PARM is also a parameter pack. */ if ((template_parameter_pack_p (arg) || PACK_EXPANSION_P (arg)) !TEMPLATE_PARM_PARAMETER_PACK (parm))
[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266
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 --- Comment #1 from Jan-Benedict Glaw jbg...@lug-owl.de --- Your recent commit breaks gcc build: commit f5cf1225bb37f43fa5bfca32cddadb9ee61aaa63 Author: krebbel krebbel@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Jun 18 08:59:46 2013 + 2013-06-18 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/57609 * config/s390/s390.c (s390_chunkify_start): Replace next_real_insn with next_active_insn. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@200164 138bc75d-0d04-0410-961f-82ee72b054a4 g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace\ ../../../../gcc/gcc/config/s390/s390.c -o s390.o ../../../../gcc/gcc/config/s390/s390.c: In function ‘constant_pool* s390_chunkify_start()’: ../../../../gcc/gcc/config/s390/s390.c:7088:7: error: ‘dump_file’ was not declared in this scope ../../../../gcc/gcc/config/s390/s390.c:7099:6: error: ‘dump_file’ was not declared in this scope ../../../../gcc/gcc/config/s390/s390.c:7100:19: error: ‘print_rtx’ was not declared in this scope make[2]: *** [s390.o] Error 1 make[2]: Leaving directory `/home/vaxbuild/build/s390x-linux/gcc-stage1/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/vaxbuild/build/s390x-linux/gcc-stage1' You need to include dumpfile.h (for dump_file) and rtl.h (for print_rtx).
[Bug tree-optimization/57642] vectorizer not working with function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642 Yale Zhang yzhang1985 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Yale Zhang yzhang1985 at gmail dot com --- Sorry, please close this. My loop was eliminated as dead code, thus no vectorization. I saw the message not enough data-refs for auto-vectorization, which made me think it wasn't being vectorized, but that's probably from somewhere else.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type
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 CC|i.nixman at gmail dot com | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Comment #1 fixed in mainline so far.
[Bug other/53317] Conversion from __int128 to __float128
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 --- Comment #4 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Bug rediscovered through inspection of soft-fp code, patch posted at: http://sourceware.org/ml/libc-alpha/2013-06/msg00656.html I have a complete, tested GCC patch updating soft-fp and adding a testcase ready to commit once the soft-fp patch is approved for glibc. If someone then wishes to backport a fix for this (as a wrong-code bug) to active release branches, the soft-fp patch itself (plus GCC testcase) should be easy enough to apply to past branches without the whole soft-fp update.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
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 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk, I'll fix this for 4.8.2 as well.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#type error
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 Last reconfirmed||2013-06-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- 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.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#type error
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 could do that for me, I would appreciate it. Sadly, I don't have as much free time to dedicate to GCC as I used to. If you don't have time, I will eventually do it, but it may take me some time.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#type error
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.
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
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.
[Bug libstdc++/54562] mutex and condition variable timers
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
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
Created attachment 30320
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30320action=edit
proposed patch to use clocks correctly
The condition_variable change should be unnecessary, as high_resolution_clock
is a typedef for system_clock in our implementation.
The timed_mutex change is an improvement but not ideal, because the standard
says implementations should use a steady clock for try_lock_for() but use the
system_clock for try_lock_until(), and pthread_mutex_timedlock() uses
CLOCK_REALTIME, which corresponds to our system_clock.
I'm going to test this patch (against the current svn trunk, after
gcc.gnu.org/r200180) to fix the timed_mutex issue. The patch attempts to use
the steady clock for relative timeouts, converting to the high_resolution_clock
(aka system_clock) for the pthread call, and re-checks on timeout to handle
cases where a clock is adjusted during the wait.
N.B. your test technically has undefined behaviour because it attempts to
relock the mutex in the same thread, I'm using this to reproduce the problem
instead:
#include iostream
#include chrono
#include mutex
#include thread
typedef std::chrono::high_resolution_clock rt_clock;
typedef std::chrono::time_pointrt_clock rt_time_point;
std::timed_mutex mutex;
void f()
{
mutex.try_lock_for(std::chrono::seconds(3));
}
int main()
{
mutex.lock();
std::cout mutex locked std::endl;
rt_time_point t1 = rt_clock::now();
std::thread(f).join();
rt_time_point t2 = rt_clock::now();
std::cout delay:
std::chrono::duration_caststd::chrono::seconds(t2-t1).count()
std::endl;
return 0;
}
[Bug c++/57644] New: [C++1y] Cannot bind bitfield to lvalue reference
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: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-snapshot --version
g++-snapshot (Debian 20130603-1) 4.9.0 20130603 (experimental) [trunk revision
199603]
$ cat main.cpp
struct foo {
unsigned i: 32;
};
int main()
{
foo f {};
return (f.i);
}
$ g++-snapshot -std=c++1y main.cpp
main.cpp: In function 'int main()':
main.cpp:8:15: error: cannot bind bitfield 'f.foo::i' to 'unsigned int'
return (f.i);
^
---
The code is accepted if either the parens are removed (i.e. just return f.i;)
or when using -std=c++11.
[Bug c++/57645] New: Explicitly-declared destructor with no exception specification is always noexcept(true)
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: travis at gockelhut dot com
#include type_traits
struct Thrower
{
~Thrower() noexcept(false) { throw 1; }
};
struct Explicit
{
~Explicit() {}
Thrower t;
};
static_assert(!std::is_nothrow_destructibleExplicit::value, Explicit);
This will fail on the static_assert in 4.8, in contrast to §15.4.14:
..If f is an...destructor...it's implicit exception-specification
specifies...f has the exception-specification noexcept(true) if every
function it directly invokes allows no exceptions.
And Thrower::~Thrower is directly invoked according to §12.4.8:
After executing the body of the destructor and destroying any automatic
objects allocated within the body, a destructor for class X calls the
destructors for X’s direct non-variant non-static data members...
[Bug c++/57646] New: bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs
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 Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: b.r.longbons at gmail dot com Created attachment 30321 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30321action=edit minimal testcase The attached reduced testcase gives a warning that a nonexistent variable, 'saved_stack.1', may be used uninitialized. The testcase does not need any special compiler flags. There are a bunch of bugs with similar descriptions, but they either don't involve invented variables or were marked as fixed. In particular, it looks fairly similar to bug 43013, which was fixed before 4.6.0. The differences I can see are that this only seems to happen in C++ with VLAs. Bad versions, all amd64: Gentoo: 4.4.7, 4.5.4, 4.6.0, 4.6.1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2, 4.7.3 Debian: 4.6.4-2, 4.7.3-4, 4.8.1-2 4.3.6 does not exhibit this issue, but that's too old to compile the codebase this is in. Since I haven't found a workaround short of disabling the warning, I'm stuck with clang for now, which lacks support for a lot of other essential warnings (*grumbles about old bug reports that still aren't fixed*).
Re: [PATCH 4/4] Fix leading spaces.
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 pre(post?)-commit hook that enforces those whitespace rules. In the cpp testsuite we definitely want tests with bad whitespace (e.g. gcc.dg/cpp/backslash*.c) and generally I think it's wrong to be changing whitespace in the testsuite without an understanding of what the test is testing and how the whitespace is irrelevant to that (more generally, cleanups of compiler tests are suspect without such an understanding of what is or is not significant in a particular test). And so you need to allow addition of otherwise bad whitespace there. It's not obvious whether there might be other cases needing such whitespace as well. Either by adjusting the committed content or by rejecting the commit(?) I don't think hooks adjusting committed content are likely to work at all. -- Joseph S. Myers jos...@codesourcery.com By having a look at Ondřej's patch, it is nice to fix existing codes with proper whitespace/tab rules. But it covers too much under whole gcc source tree. Like Joseph said, we may accidentally change the cases that need bad whitespace. Perhaps we should gradually fix them? i.e. We can only fix leading spaces for some obvious cases (gcc/*.c gcc/c-family/*.c ...), leaving other source (gcc/testsuite/* gcc/config/* ...) untouched. I uploaded new version that touches only gcc/*.[ch] gcc/c-family/*.[ch] to http://kam.mff.cuni.cz/~ondra/stylepp.tar.bz2 patches are also updated. IMHO, the preliminary whitelist could be: gcc/*.[ch] gcc/c/*.[ch] gcc/c-family/*.[ch] gcc/common/*.[ch] gcc/cp/*.[ch] Anyway what in gcc/config/*.c depends on leading/trailing spaces? In general, I agree with you that all stuff under gcc/config/ and gcc/common/config/ are supposed to follow whitespace rules. But I think it would be better to have corresponding port maintainers make the decision. Your tool and patches look great to me. It helps fixup the existing codes with strong whitespace convention. But I am sorry that I don't have right to approve it. You will need some reviewers to review the patch and give the OK. If you do not receive any response to the patches within two weeks or so, you can 'ping' it with a follow-up mail to remind reviewers. :) Best regards, jasonwucj
Re: [gomp4] Some progress on #pragma omp simd
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.
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -227,6 +227,7 @@ DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT128_DFLOAT128,
BT_DFLOAT128, BT_DFLOAT128)
DEF_FUNCTION_TYPE_1 (BT_FN_VOID_VPTR, BT_VOID, BT_VOLATILE_PTR)
DEF_FUNCTION_TYPE_1 (BT_FN_VOID_PTRPTR, BT_VOID, BT_PTR_PTR)
DEF_FUNCTION_TYPE_1 (BT_FN_UINT_UINT, BT_UINT, BT_UINT)
+DEF_FUNCTION_TYPE_1 (BT_FN_UINT_PTR, BT_UINT, BT_PTR)
DEF_FUNCTION_TYPE_1 (BT_FN_ULONG_ULONG, BT_ULONG, BT_ULONG)
DEF_FUNCTION_TYPE_1 (BT_FN_ULONGLONG_ULONGLONG, BT_ULONGLONG, BT_ULONGLONG)
DEF_FUNCTION_TYPE_1 (BT_FN_UINT16_UINT16, BT_UINT16, BT_UINT16)
You can avoid this by using say unsigned_type_node as the type of the magic
decl rather than pointer type. Though, with internal functions this will
not be needed anyway.
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index 6cc9a6c..41677bc 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -176,7 +176,7 @@ struct GTY ((chain_next (%h.next))) loop {
/* For SIMD loops, this is a unique identifier of the loop, referenced
by __builtin_GOMP.simd_vf and __builtin_GOMP.simd_lane builtins. */
- unsigned int simduid;
+ tree simduid;
/* True if we should try harder to vectorize this loop. */
bool force_vect;
Please move simduid after force_vect, so that it is better packed.
Jakub
Re: [C/C++ PATCH] Handle COMPOUND_EXPR in convert_to_* (PR c++/56493)
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 was say int and foo () returned unsigned long long, convert_to_integer would narrow the addition to unsigned int, but as we now pass to convert_to_* a COMPOUND_EXPR with the side-effects on the op0 and addition on op1 of the COMPOUND_EXPR, convert_to_integer doesn't perform this shortening and unfortunately we don't have any gimple optimization yet to do this later on. This patch fixes it by handling COMPOUND_EXPR in convert_to_* where we care about TREE_CODE of the expr. Ok for trunk? Ok for 4.8 as well after a while? I suppose it's OK to fix the regression, though really we should be eliminating these early convert_to_* optimizations (optimizing later on GIMPLE if possible) rather than adding to them. I agree. The correct place for this is in tree-ssa-forwprop.c (for now). Richard.
[PATCH][ARM][7/n] Partial IT block deprecation in ARMv8 AArch32 - straightforward arm.md changes
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 Cortex-A15 and tested arm-none-eabi on a model on armv7-a and armv8-a architecture levels. Ok for trunk? Thanks, Kyrill 2013-06-18 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm.md (arm_mulsi3_v6): Add alternative for 16-bit encoding. (mulsi3addsi_v6): Disable predicable variant for arm_restrict_it. (mulsi3subsi): Likewise. (mulsidi3adddi): Likewise. (mulsidi3_v6): Likewise. (umulsidi3_v6): Likewise. (umulsidi3adddi_v6): Likewise. (smulsi3_highpart_v6): Likewise. (umulsi3_highpart_v6): Likewise. (mulhisi3tb): Likewise. (mulhisi3bt): Likewise. (mulhisi3tt): Likewise. (maddhisi4): Likewise. (maddhisi4tb): Likewise. (maddhisi4tt): Likewise. (maddhidi4): Likewise. (maddhidi4tb): Likewise. (maddhidi4tt): Likewise. (zeroextractsi_compare0_scratch): Likewise. (insv_zero): Likewise. (insv_t2): Likewise. (anddi_notzesidi_di): Likewise. (anddi_notsesidi_di): Likewise. (andsi_notsi_si): Likewise. (iordi_zesidi_di): Likewise. (xordi_zesidi_di): Likewise. (andsi_iorsi3_notsi): Likewise. (smax_0): Likewise. (smax_m1): Likewise. (smin_0): Likewise. (not_shiftsi): Likewise. (unaligned_loadsi): Likewise. (unaligned_loadhis): Likewise. (unaligned_loadhiu): Likewise. (unaligned_storesi): Likewise. (unaligned_storehi): Likewise. (extv_reg): Likewise. (extzv_t2): Likewise. (divsi3): Likewise. (udivsi3): Likewise. (arm_zero_extendhisi2addsi): Likewise. (arm_zero_extendqisi2addsi): Likewise. (compareqi_eq0): Likewise. (arm_extendhisi2_v6): Likewise. (arm_extendqisi2addsi): Likewise. (arm_movt): Likewise. (thumb2_ldrd): Likewise. (thumb2_ldrd_base): Likewise. (thumb2_ldrd_base_neg): Likewise. (thumb2_strd): Likewise. (thumb2_strd_base): Likewise. (thumb2_strd_base_neg): Likewise. (arm_negsi2): Add alternative for 16-bit encoding. (arm_one_cmplsi2): Likewise. 08-armmd-straight.patch Description: Binary data
Re: [ping**2] Nios II port
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 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01085.html There are also these two parts that have been reviewed already: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01329.html [approved but not applied yet?] That Dwarf fix has already been applied. http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01087.html [needs minor cleanup and separate consideration] Yes, I forgot about this one. Need some cleanup to be more robust. Will resubmit separately. Chung-Lin
[PATCH, ARM] Fix unrecognizable vector comparisons
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])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(reg:V4SI 1023 [ vect_var_.49 ])
(const_int 1 [0x1])
] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
(nil))
Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
for more. And the bug also happens for FSF trunk.
The similar issue
(https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
had fixed on AARCH64:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
The patch is similar to the fix for aarch64.
Bootstrap and no make check regression on Panda Board.
Is it OK for trunk and 4.8?
Thanks!
-Zhenqiang
ChangeLog:
2013-06-18 Zhenqiang Chen zhenqiang.c...@linaro.org
* config/arm/neon.md (vcond): Fix floating-point vector
comparisons against 0.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index e814df0..9299ae5 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -1671,6 +1671,7 @@
? 3 : 1;
rtx magic_rtx = GEN_INT (magic_word);
int inverse = 0;
+ int use_zero_form = 0;
int swap_bsl_operands = 0;
rtx mask = gen_reg_rtx (V_cmp_resultmode);
rtx tmp = gen_reg_rtx (V_cmp_resultmode);
@@ -1681,12 +1682,16 @@
switch (GET_CODE (operands[3]))
{
case GE:
+case GT:
case LE:
+case LT:
case EQ:
- if (!REG_P (operands[5])
- (operands[5] != CONST0_RTX (MODEmode)))
- operands[5] = force_reg (MODEmode, operands[5]);
- break;
+ if (operands[5] == CONST0_RTX (MODEmode))
+ {
+ use_zero_form = 1;
+ break;
+ }
+ /* Fall through. */
default:
if (!REG_P (operands[5]))
operands[5] = force_reg (MODEmode, operands[5]);
@@ -1737,7 +1742,26 @@
a GT b - a GT b
a LE b - b GE a
a LT b - b GT a
-a EQ b - a EQ b */
+a EQ b - a EQ b
+Note that there also exist direct comparison against 0 forms,
+so catch those as a special case. */
+ if (use_zero_form)
+ {
+ inverse = 0;
+ switch (GET_CODE (operands[3]))
+ {
+ case LT:
+ base_comparison = gen_neon_vcltmode;
+ break;
+ case LE:
+ base_comparison = gen_neon_vclemode;
+ break;
+ default:
+ /* Do nothing, other zero form cases already have the correct
+base_comparison. */
+ break;
+ }
+ }
if (!inverse)
emit_insn (base_comparison (mask, operands[4], operands[5], magic_rtx));
[Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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
* config/s390/s390.c (s390_chunkify_start): Replace next_real_insn
with next_active_insn.
---
gcc/config/s390/s390.c |4
1 file changed, 4 modifications(!)
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_chunkify_start (void)
*** 7012,7018
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
! rtx vec_insn = next_real_insn (insn);
if (! vec_insn || ! JUMP_TABLE_DATA_P (vec_insn))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
--- 7012,7018
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
! rtx vec_insn = next_active_insn (insn);
if (! vec_insn || ! JUMP_TABLE_DATA_P (vec_insn))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
*** s390_chunkify_start (void)
*** 7043,7049
{
/* Find the jump table used by this casesi jump. */
rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
! rtx vec_insn = next_real_insn (vec_label);
if (vec_insn JUMP_TABLE_DATA_P (vec_insn))
{
rtx vec_pat = PATTERN (vec_insn);
--- 7043,7049
{
/* Find the jump table used by this casesi jump. */
rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
! rtx vec_insn = next_active_insn (vec_label);
if (vec_insn JUMP_TABLE_DATA_P (vec_insn))
{
rtx vec_pat = PATTERN (vec_insn);
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 find another solution. JUMP_TABLE_DATA is not an active insn, and I will be removing it soon from active_insn_p. How big does a FIXME have to be for people to notice? Ciao! Steven
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 r197266. Comitted to mainline Please revert this and find another solution. JUMP_TABLE_DATA is not an active insn, and I will be removing it soon from active_insn_p. How big does a FIXME have to be for people to notice? Ciao! Steven Hi, Steven, 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 Best regards, jasonwucj
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 JUMP_TABLE_DATA change and thus my responsibility to fix. Ciao! Steven
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
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 [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(reg:V4SI 1023 [ vect_var_.49 ])
(const_int 1 [0x1])
] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
(nil))
Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
for more. And the bug also happens for FSF trunk.
The similar issue
(https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
had fixed on AARCH64:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
The patch is similar to the fix for aarch64.
Bootstrap and no make check regression on Panda Board.
Is it OK for trunk and 4.8?
No, not without an appropriate set of testcases that exercise these cases.
regards
Ramana
Thanks!
-Zhenqiang
ChangeLog:
2013-06-18 Zhenqiang Chen zhenqiang.c...@linaro.org
* config/arm/neon.md (vcond): Fix floating-point vector
comparisons against 0.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index e814df0..9299ae5 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -1671,6 +1671,7 @@
? 3 : 1;
rtx magic_rtx = GEN_INT (magic_word);
int inverse = 0;
+ int use_zero_form = 0;
int swap_bsl_operands = 0;
rtx mask = gen_reg_rtx (V_cmp_resultmode);
rtx tmp = gen_reg_rtx (V_cmp_resultmode);
@@ -1681,12 +1682,16 @@
switch (GET_CODE (operands[3]))
{
case GE:
+case GT:
case LE:
+case LT:
case EQ:
- if (!REG_P (operands[5])
- (operands[5] != CONST0_RTX (MODEmode)))
- operands[5] = force_reg (MODEmode, operands[5]);
- break;
+ if (operands[5] == CONST0_RTX (MODEmode))
+ {
+ use_zero_form = 1;
+ break;
+ }
+ /* Fall through. */
default:
if (!REG_P (operands[5]))
operands[5] = force_reg (MODEmode, operands[5]);
@@ -1737,7 +1742,26 @@
a GT b - a GT b
a LE b - b GE a
a LT b - b GT a
-a EQ b - a EQ b */
+a EQ b - a EQ b
+Note that there also exist direct comparison against 0 forms,
+so catch those as a special case. */
+ if (use_zero_form)
+ {
+ inverse = 0;
+ switch (GET_CODE (operands[3]))
+ {
+ case LT:
+ base_comparison = gen_neon_vcltmode;
+ break;
+ case LE:
+ base_comparison = gen_neon_vclemode;
+ break;
+ default:
+ /* Do nothing, other zero form cases already have the correct
+base_comparison. */
+ break;
+ }
+ }
if (!inverse)
emit_insn (base_comparison (mask, operands[4], operands[5], magic_rtx));
Re: [PATCH] Fix up bmi_bextr_mode (PR target/57623)
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
patch hasn't touched just BMI2, but for unknown reasons also this BMI
instruction which was handled right in GCC 4.6.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8/4.7?
BTW, the AVX2 docs document _bextr_u{32,64} 3 argument intrinsics, rather
than the __bextr_u{32,64} 2 argument intrinsics we have in GCC right now.
Something to fix up (as the names are different, perhaps we can both the old
ones and the new ones implemented say as return __bextr_u32 (x, (y 255) |
(z 8)); or similar)?
It looks to me that GCC's double-underscored version is wrong. We are
looking for compatibility with official bmiintrin.h header. Kirill,
can you please comment on this issue?
2013-06-17 Jakub Jelinek ja...@redhat.com
PR target/57623
* config/i386/i386.md (bmi_bextr_mode): Swap predicates and
constraints of operand 1 and 2.
* gcc.target/i386/bmi-bextr-3.c: New test.
The fix itself looks good to me as far as insn is concerned, but
please wait until the issue with builtins is resolved.
Thanks,
Uros.
Re: [PATCH] Fix up bmi_bextr_mode (PR target/57623)
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 packed start/length argument. This got broken with PR50766, where the
patch hasn't touched just BMI2, but for unknown reasons also this BMI
instruction which was handled right in GCC 4.6.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8/4.7?
BTW, the AVX2 docs document _bextr_u{32,64} 3 argument intrinsics, rather
than the __bextr_u{32,64} 2 argument intrinsics we have in GCC right now.
Something to fix up (as the names are different, perhaps we can both the old
ones and the new ones implemented say as return __bextr_u32 (x, (y 255) |
(z 8)); or similar)?
It looks to me that GCC's double-underscored version is wrong. We are
looking for compatibility with official bmiintrin.h header. Kirill,
can you please comment on this issue?
Well, bmiintrin.h has been added first as an AMD ISA extension, and I think for
AMD extensions the GCC headers are the official place (the AMD docs don't
mention the intrinsics at all), and only later on also added as Intel ISA
extension. So I'd say it is fine to keep the __bextr_* variants (as written
in the PR, sometimes the two argument ones can be useful if you e.g.
precompute the start/length pairs ahead of time) and just add the one
underscored ones to match ICC/AVX2 documentation.
Jakub
[PATCH] Fix PR57334
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 (lto_symtab_merge_decls): Process nodes properly.
Index: gcc/lto-symtab.c
===
--- gcc/lto-symtab.c(revision 200163)
+++ gcc/lto-symtab.c(working copy)
@@ -522,19 +522,9 @@ lto_symtab_merge_decls (void)
symtab_initialize_asm_name_hash ();
FOR_EACH_SYMBOL (node)
-if (lto_symtab_symbol_p (node)
+if (!node-symbol.previous_sharing_asm_name
node-symbol.next_sharing_asm_name)
- {
-symtab_node n;
-
- /* To avoid duplicated work, see if this is first real symbol in the
- chain. */
- for (n = node-symbol.previous_sharing_asm_name;
-n !lto_symtab_symbol_p (n); n =
n-symbol.previous_sharing_asm_name)
- ;
- if (!n)
- lto_symtab_merge_decls_1 (node);
- }
+ lto_symtab_merge_decls_1 (node);
}
/* Helper to process the decl chain for the symbol table entry *SLOT. */
Re: [PATCH, ARM] Fix gcc.dg/pr48335-5.c ICE with NEON enabled
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 (neon_vector_mem_operand): Adjust prototype. * config/arm/neon.md (movmisalignmode): Use neon_perm_struct_or_reg_operand instead of neon_struct_or_register_operand. (*movmisalignmode_neon_load, *movmisalignmode_neon_store): Use neon_permissive_struct_operand instead of neon_struct_operand. * config/arm/constraints.md (Un, Um, Us): Adjust calls to neon_vector_mem_operand. * config/arm/predicates.md (neon_struct_operand): Adjust call to neon_vector_mem_operand. (neon_permissive_struct_operand): New. (neon_struct_or_register_operand): Rename to... (neon_perm_struct_or_reg_operand): This. Adjust call to neon_vector_mem_operand. Ok but this also needs to go to FSF 4.8 if no RM objects and after a few days of soaking on trunk. regards Ramana
Re: [PATCH] Re-write LTO type merging again, do tree merging
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: In function 'unlzo': /backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c:79:8: internal compiler error: in expand_expr_real_1, at expr.c:9361 parse += 7; ^ 0x5ea175 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:9356 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 should have been lowered by this point. */ context = decl_function_context (exp); - gcc_assert (!context + gcc_assert (SCOPE_FILE_SCOPE_P (context) || context == current_function_decl || TREE_STATIC (exp) || DECL_EXTERNAL (exp) might fix it. Richard.
Re: [PATCH] PowerPC: Fix test case for PR55033
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 explicitly copy me on patches. Hi, Sebastian, Since David has pproved your patch, do you need me to help commit this fix again? I'd happy to do this for you. :) yes, please commit it for me. Thanks. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
PING [C++ docs patch] PR 56544
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 '; or @code{201103L}, per the
2011 C++ standard' or more verbosely say that with -std=c++1y too the
value is 201103L.
Is this patch straightforward enough to go in? Opinions about the branch?
Thanks...
Paolo.
Re: [Patch wwwdocs] gcc-4.9 changes: mention support of the Intel Silvermont microarchitecture
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 === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.17 diff -c -1 -r1.17 changes.html *** htdocs/gcc-4.9/changes.html 6 Jun 2013 11:15:24 - 1.17 --- htdocs/gcc-4.9/changes.html 10 Jun 2013 10:11:24 - *** *** 177,178 --- 177,185 + h3IA-32/x86-64/h3 + ul + li GCC now supports new Intel microarchitecture named Silvermont + through code-march=slm/code. + /li + /ul + h3 id=rxRX/h3
Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
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 of transformation should be done in backend? I can think of some disadvantages by doing it in backend: Different kinds of address expression might be wanted in different phase of compilation, for example, sometimes GCC wants to force computation of address expression out of memory access because it cannot CSE array indexing. It's difficult to differentiate in backend. It's equally difficult in memory_address_addr_space and it affects all the architectures at once... You said in the original message that Thumb2 and ARM modes are already not equally sensitive to it, so it's not unthinkable that some architectures might not want it at all. Therefore, yes, this should preferably be handled in arm_legitimize_address. 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 is this a particular case with displacement addressing (register + constant). On SH displacements for byte addressing are 0..15, 0..31 for 16 bit words and 0..63 for 32 bit words. sh_legitimize_address (or rather sh_find_mov_disp_adjust) uses a fixed heuristic to satisfy the displacement constraint and splits out a plus insn if needed to adjust the base address. Of course that fixed heuristic doesn't work for some cases and thus sometimes results in unnecessary base address adjustments. I had the idea of replacing the current (partially defunct) auto-inc-dec RTL pass with a more generic addressing mode selection pass: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590 Any suggestions/comments/... are highly appreciated. In PR56590, is PR50749 the only one that correlate with auto-inc-dec? Others seem just problems of wrong addressing mode. And one point on PR50749, auto-inc-dec depends on ivopt to choose auto-increment candidate. Since you disabled ivopt, I bet GCC will miss lots of auto-increment opportunities. Thanks. bin -- Best Regards.
Re: [PATCH] Fix up bmi_bextr_mode (PR target/57623)
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 the
patch hasn't touched just BMI2, but for unknown reasons also this BMI
instruction which was handled right in GCC 4.6.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.8/4.7?
BTW, the AVX2 docs document _bextr_u{32,64} 3 argument intrinsics, rather
than the __bextr_u{32,64} 2 argument intrinsics we have in GCC right now.
Something to fix up (as the names are different, perhaps we can both the
old
ones and the new ones implemented say as return __bextr_u32 (x, (y 255) |
(z 8)); or similar)?
It looks to me that GCC's double-underscored version is wrong. We are
looking for compatibility with official bmiintrin.h header. Kirill,
can you please comment on this issue?
Well, bmiintrin.h has been added first as an AMD ISA extension, and I think
for
AMD extensions the GCC headers are the official place (the AMD docs don't
mention the intrinsics at all), and only later on also added as Intel ISA
extension. So I'd say it is fine to keep the __bextr_* variants (as written
in the PR, sometimes the two argument ones can be useful if you e.g.
precompute the start/length pairs ahead of time) and just add the one
underscored ones to match ICC/AVX2 documentation.
I agree with this proposal, but probably we need to review the whole
bmiintrin.h for intel additions.
Uros.
Re: [PATCH] Re-write LTO type merging again, do tree merging
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 reported problems. Instructions for reproducing this issue appreciated. I've never built lto kernels. Install recent HJ Lu's Linux binutils somewhere (https://www.kernel.org/pub/linux/devel/binutils/) Build a gcc that uses the linker from above as plugin ld Check out git://github.com/andikleen/linux-misc -b lto-3.9 Put attached config as .config into build dir. 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. Richard. -Andi -- Richard Biener rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [patch] gcov intermediate format
Ping. Th patch is OK, thanks! I see you added gcov.exp file support, do you have a testcases? Honza
[PATCH] Fix c90-fordecl-1.c test
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
* gcc.dg/c90-fordecl-1.c: Adjust expected message.
--- gcc/testsuite/gcc.dg/c90-fordecl-1.c.mp32013-06-18 12:10:11.233225073
+0200
+++ gcc/testsuite/gcc.dg/c90-fordecl-1.c2013-06-18 12:11:27.332603234
+0200
@@ -9,6 +9,6 @@ foo (void)
int j = 0;
for (int i = 1; i = 10; i++) /* { dg-bogus warning warning in place of
error } */
j += i;
- /* { dg-error 'for' loop initial declarations are only allowed in C99 mode
declaration in for loop { target *-*-* } 10 } */
- /* { dg-message note: use option -std=c99 or -std=gnu99 to compile your
code note { target *-*-* } 10 }} */
+ /* { dg-error 'for' loop initial declarations are only allowed in C99 or
C11 mode declaration in for loop { target *-*-* } 10 } */
+ /* { dg-message note: use option -std=c99, -std=gnu99, -std=c11 or
-std=gnu11 to compile your code note { target *-*-* } 10 }} */
}
Marek
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 I'll fix, it's fall-out from the JUMP_TABLE_DATA change and thus my responsibility to fix. Btw. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 is also a fall-out from the JUMP_TABLE_DATA change. -Andreas-
[PATCH, libfortran]: Initialize result variable (+ other changes)
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
* config/fpu-387.h: Use __asm__ and __volatile__ consistently.
(get_fpu_except_flags): Initialize result.
Tested on x86_64-pc-linux-gnu {,-m32}.
OK for mainline?
Uros.
Index: config/fpu-387.h
===
--- config/fpu-387.h(revision 200163)
+++ config/fpu-387.h(working copy)
@@ -73,7 +73,7 @@ has_sse (void)
/* We need a single SSE instruction here so the handler can safely skip
over it. */
- __asm__ volatile (movaps %xmm0,%xmm0);
+ __asm__ __volatile__ (movaps\t%xmm0,%xmm0);
sigaction (SIGILL, oact, NULL);
@@ -100,7 +100,7 @@ void set_fpu (void)
{
unsigned short cw;
- asm volatile (fnstcw %0 : =m (cw));
+ __asm__ __volatile__ (fnstcw\t%0 : =m (cw));
cw |= (_FPU_MASK_IM | _FPU_MASK_DM | _FPU_MASK_ZM | _FPU_MASK_OM
| _FPU_MASK_UM | _FPU_MASK_PM);
@@ -112,13 +112,13 @@ void set_fpu (void)
if (options.fpe GFC_FPE_UNDERFLOW) cw = ~_FPU_MASK_UM;
if (options.fpe GFC_FPE_INEXACT) cw = ~_FPU_MASK_PM;
- asm volatile (fldcw %0 : : m (cw));
+ __asm__ __volatile__ (fldcw\t%0 : : m (cw));
if (has_sse())
{
unsigned int cw_sse;
- asm volatile (%vstmxcsr %0 : =m (cw_sse));
+ __asm__ __volatile__ (%vstmxcsr\t%0 : =m (cw_sse));
cw_sse = 0x;
cw_sse |= (_FPU_MASK_IM | _FPU_MASK_DM | _FPU_MASK_ZM | _FPU_MASK_OM
@@ -131,7 +131,7 @@ void set_fpu (void)
if (options.fpe GFC_FPE_UNDERFLOW) cw_sse = ~(_FPU_MASK_UM 7);
if (options.fpe GFC_FPE_INEXACT) cw_sse = ~(_FPU_MASK_PM 7);
- asm volatile (%vldmxcsr %0 : : m (cw_sse));
+ __asm__ __volatile__ (%vldmxcsr\t%0 : : m (cw_sse));
}
}
@@ -139,7 +139,7 @@ void set_fpu (void)
int
get_fpu_except_flags (void)
{
- int result;
+ int result = 0;
unsigned short cw;
__asm__ __volatile__ (fnstsw\t%0 : =a (cw));
@@ -147,27 +147,18 @@ get_fpu_except_flags (void)
if (has_sse())
{
unsigned int cw_sse;
+
__asm__ __volatile__ (%vstmxcsr\t%0 : =m (cw_sse));
+
cw |= cw_sse;
}
- if (cw _FPU_MASK_IM)
-result |= GFC_FPE_INVALID;
+ if (cw _FPU_MASK_IM) result |= GFC_FPE_INVALID;
+ if (cw _FPU_MASK_DM) result |= GFC_FPE_DENORMAL;
+ if (cw _FPU_MASK_ZM) result |= GFC_FPE_ZERO;
+ if (cw _FPU_MASK_OM) result |= GFC_FPE_OVERFLOW;
+ if (cw _FPU_MASK_UM) result |= GFC_FPE_UNDERFLOW;
+ if (cw _FPU_MASK_PM) result |= GFC_FPE_INEXACT;
- if (cw _FPU_MASK_ZM)
-result |= GFC_FPE_ZERO;
-
- if (cw _FPU_MASK_OM)
-result |= GFC_FPE_OVERFLOW;
-
- if (cw _FPU_MASK_UM)
-result |= GFC_FPE_UNDERFLOW;
-
- if (cw _FPU_MASK_DM)
-result |= GFC_FPE_DENORMAL;
-
- if (cw _FPU_MASK_PM)
-result |= GFC_FPE_INEXACT;
-
return result;
}
[PATCH] Remove LTO streamer cache pointer-map for LTO input
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 map.
LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-06-18 Richard Biener rguent...@suse.de
* tree-streamer.h (streamer_tree_cache_create): Adjust prototype.
* tree-streamer.c (streamer_tree_cache_create): Make maintaining
the map from cache entry to cache index optional.
(streamer_tree_cache_replace_tree): Adjust accordingly.
(streamer_tree_cache_append): Likewise.
(streamer_tree_cache_delete): Likewise.
* lto-streamer-in.c (lto_data_in_create): Do not maintain the
streamer cache map from cache entry to cache index.
* lto-streamer-out.c (create_output_block): Adjust.
lto/
* lto.c (lto_register_var_decl_in_symtab): Pass in cache index
and use it.
(lto_register_function_decl_in_symtab): Likewise.
(cmp_tree): New function.
(unify_scc): Instead of using the streamer cache map from entry
to cache index match up the two maps we have by sorting them.
Adjust calls to lto_register_var_decl_in_symtab and
lto_register_function_decl_in_symtab.
Index: gcc/tree-streamer.c
===
*** gcc/tree-streamer.c.orig2013-06-18 13:00:34.0 +0200
--- gcc/tree-streamer.c 2013-06-18 13:00:46.042791385 +0200
*** streamer_tree_cache_replace_tree (struct
*** 197,203
hashval_t hash = 0;
if (cache-hashes.exists ())
hash = streamer_tree_cache_get_hash (cache, ix);
! streamer_tree_cache_insert_1 (cache, t, hash, ix, false);
}
--- 197,206
hashval_t hash = 0;
if (cache-hashes.exists ())
hash = streamer_tree_cache_get_hash (cache, ix);
! if (!cache-node_map)
! streamer_tree_cache_add_to_node_array (cache, ix, t, hash);
! else
! streamer_tree_cache_insert_1 (cache, t, hash, ix, false);
}
*** streamer_tree_cache_append (struct strea
*** 208,214
tree t, hashval_t hash)
{
unsigned ix = cache-nodes.length ();
! streamer_tree_cache_insert_1 (cache, t, hash, ix, false);
}
/* Return true if tree node T exists in CACHE, otherwise false. If IX_P is
--- 211,220
tree t, hashval_t hash)
{
unsigned ix = cache-nodes.length ();
! if (!cache-node_map)
! streamer_tree_cache_add_to_node_array (cache, ix, t, hash);
! else
! streamer_tree_cache_insert_1 (cache, t, hash, ix, false);
}
/* Return true if tree node T exists in CACHE, otherwise false. If IX_P is
*** preload_common_nodes (struct streamer_tr
*** 319,331
/* Create a cache of pickled nodes. */
struct streamer_tree_cache_d *
! streamer_tree_cache_create (bool with_hashes)
{
struct streamer_tree_cache_d *cache;
cache = XCNEW (struct streamer_tree_cache_d);
! cache-node_map = pointer_map_create ();
cache-nodes.create (165);
if (with_hashes)
cache-hashes.create (165);
--- 325,338
/* Create a cache of pickled nodes. */
struct streamer_tree_cache_d *
! streamer_tree_cache_create (bool with_hashes, bool with_map)
{
struct streamer_tree_cache_d *cache;
cache = XCNEW (struct streamer_tree_cache_d);
! if (with_map)
! cache-node_map = pointer_map_create ();
cache-nodes.create (165);
if (with_hashes)
cache-hashes.create (165);
*** streamer_tree_cache_delete (struct strea
*** 347,353
if (c == NULL)
return;
! pointer_map_destroy (c-node_map);
c-nodes.release ();
c-hashes.release ();
free (c);
--- 354,361
if (c == NULL)
return;
! if (c-node_map)
! pointer_map_destroy (c-node_map);
c-nodes.release ();
c-hashes.release ();
free (c);
Index: gcc/tree-streamer.h
===
*** gcc/tree-streamer.h.orig2013-06-18 13:00:34.0 +0200
--- gcc/tree-streamer.h 2013-06-18 13:00:46.061791614 +0200
*** void streamer_tree_cache_append (struct
*** 98,104
hashval_t);
bool streamer_tree_cache_lookup (struct streamer_tree_cache_d *, tree,
unsigned *);
! struct streamer_tree_cache_d *streamer_tree_cache_create (bool);
void streamer_tree_cache_delete (struct streamer_tree_cache_d *);
/* Return the tree node at slot IX in CACHE. */
--- 98,104
hashval_t);
bool streamer_tree_cache_lookup (struct streamer_tree_cache_d *, tree,
unsigned *);
! struct streamer_tree_cache_d
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 which broke with r197266.
Comitted to mainline
Please revert this and find another solution. JUMP_TABLE_DATA is not
an active insn, and I will be removing it soon from active_insn_p.
I don't see which of the other iterators would fit here. So I'll need
my own. How do you intend to fix this for the other targets? Will
there be a new iterator available?
If you don't want me to use next_active_insn I probably have to do
something like this instead:
---
gcc/config/s390/s390.c | 30 ++
1 file changed, 22 insertions(+), 8 modifications(!)
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_mainpool_cancel (struct constant_po
*** 6792,6797
--- 6792,6819
s390_free_pool (pool);
}
+ /* Return true if LABEL is directly followed by a jump table insn. If
+JUMP_TABLE_INSN is non-null the jump table insn is returned
+there. */
+ static bool
+ s390_is_jumptable_label_p (rtx label, rtx *jump_table_insn)
+ {
+ while (label)
+ {
+ label = NEXT_INSN (label);
+
+ if (label == NULL_RTX || NONDEBUG_INSN_P (label))
+ return false;
+
+ if (JUMP_TABLE_DATA_P (label))
+ {
+ if (jump_table_insn != NULL)
+ *jump_table_insn = label;
+ return true;
+ }
+ }
+ return false;
+ }
/* Chunkify the literal pool. */
*** s390_chunkify_start (void)
*** 7012,7019
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
! rtx vec_insn = next_active_insn (insn);
! if (! vec_insn || ! JUMP_TABLE_DATA_P (vec_insn))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
--- 7034,7040
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
! if (!s390_is_jumptable_label_p (insn, NULL))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
*** s390_chunkify_start (void)
*** 7043,7050
{
/* Find the jump table used by this casesi jump. */
rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
! rtx vec_insn = next_active_insn (vec_label);
! if (vec_insn JUMP_TABLE_DATA_P (vec_insn))
{
rtx vec_pat = PATTERN (vec_insn);
int i, diff_p = GET_CODE (vec_pat) == ADDR_DIFF_VEC;
--- 7064,7072
{
/* Find the jump table used by this casesi jump. */
rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
! rtx vec_insn;
!
! if (s390_is_jumptable_label_p (vec_label, vec_insn))
{
rtx vec_pat = PATTERN (vec_insn);
int i, diff_p = GET_CODE (vec_pat) == ADDR_DIFF_VEC;
[ARM][Insn classification refactoring 1/N] Move mult/div attribute values from insn to type
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 division attribute values from insn to type. OK for trunk? - Thanks Sofiane arm-move-mult-div-insn.diff Description: Binary data
Re: [ARM][Insn classification refactoring 1/N] Move mult/div attribute values from insn to type
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 patch moves the multiplication and division attribute values from insn to type. OK for trunk? - Thanks Sofiane= OK. R.
Re: RFA: Fix rtl-optimization/57425
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 i686-pc-linux-gnu
finished, now regtesting.
On x86_64-pc-linux-gnu, bootstrap is still in progress I also still have
to verify if the pr57569.c testcase FAILs/PASSes for unpatched/patched
svn trunk.
Careful. The patch uses the wrong order of arguments in the call
to the new function:
/* Returns nonzero if a write to X might alias a previous read from
- (or, if WRITEP is nonzero, a write to) MEM. */
+ (or, if WRITEP is true, a write to) MEM.
+ If MEM_CANONCALIZED is nonzero, CANON_MEM_ADDR is the canonicalized
+ address of MEM, and MEM_MODE the mode for that access. */
static int
-write_dependence_p (const_rtx mem, const_rtx x, int writep)
+write_dependence_p (const_rtx mem, enum machine_mode mem_mode,
+ rtx canon_mem_addr, const_rtx x,
+ bool mem_canonicalized, bool writep)
So, first argument is the thing in question (the one that might be
clobbered), the second (or in the new interface the fourth) is the write
that might clobber it ...
/* Likewise, but we already have a canonicalized MEM_ADDR for MEM.
+ Also, consider MEM in MEM_MODE (which might be from an enclosing
+ STRICT_LOW_PART / ZERO_EXTRACT). */
+
+int
+canon_anti_dependence (const_rtx mem, enum machine_mode mem_mode,
+ rtx mem_addr, const_rtx x)
+{
+ return write_dependence_p (mem, mem_mode, mem_addr, x,
... same here, first the read, then the potentially destroying write ...
if (*x MEM_P (*x))
-return canon_true_dependence (d-exp, d-mode, d-addr, *x, NULL_RTX);
+return canon_anti_dependence (d-exp, d-mode, d-addr, *x);
else
... but here you use the same order as for true_dependence, to cite from
the function comment:
/* True dependence: X is read after store in MEM takes place. */
int
true_dependence (const_rtx mem, enum machine_mode mem_mode, const_rtx x)
So, first the potentially clobbering write, then the read. And indeed in
check_dependence d-exp is the write and x the read that is potentially
clobbered.
I.e. the arguments after your patch are exactly swapped. This is usually
harmless, but not always, so that should be corrected before check in.
The change in cselib.c:cselib_invalidate_mem has the same problem.
Generally I would prefer simple interfaces to the query functions,
dependence problems are hard enough to think about without functions
needing four arguments. Does it really save much to not canonicalize the
mem address for some calls?
Ciao,
Michael.
Re: Apply powerpc64le patches to gcc-4.8 branch?
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? http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01374.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00211.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00214.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00244.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00297.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00435.html http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00476.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00165.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00166.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00388.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00554.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00684.html http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00766.html All of the rs6000 parts are okay with me. Thanks, David
Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
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 is this a particular case with displacement addressing (register + constant). On SH displacements for byte addressing are 0..15, 0..31 for 16 bit words and 0..63 for 32 bit words. sh_legitimize_address (or rather sh_find_mov_disp_adjust) uses a fixed heuristic to satisfy the displacement constraint and splits out a plus insn if needed to adjust the base address. Of course that fixed heuristic doesn't work for some cases and thus sometimes results in unnecessary base address adjustments. I had the idea of replacing the current (partially defunct) auto-inc-dec RTL pass with a more generic addressing mode selection pass: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590 Any suggestions/comments/... are highly appreciated. In PR56590, is PR50749 the only one that correlate with auto-inc-dec? Others seem just problems of wrong addressing mode. Yes, PR 50749 was the initial description of auto-inc-dec defects. PR 52049 is also related to it, as the code examples there are candidates for post-inc addressing mode. In that case, if 'int' is replaced with 'float' on SH post-inc is the optimal mode, because it doesn't have displacement addressing for FPU loads, except than SH2A. Even then, using post-inc is better as it has a more compact instruction encoding. The current auto-inc-dec is not able to discover such opportunities if, for example, mem accesses are reordered by preceding optimization passes. And one point on PR50749, auto-inc-dec depends on ivopt to choose auto-increment candidate. Since you disabled ivopt, I bet GCC will miss lots of auto-increment opportunities. No, I haven't disabled ivopt. Cheers, Oleg
[PATCH] Fix mv?.C ICEs
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: g++.dg/ext/mv2.C -std=gnu++11 execution test FAIL: g++.dg/ext/mv5.C -std=gnu++98 execution test FAIL: g++.dg/ext/mv5.C -std=gnu++11 execution test Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2013-06-18 Richard Biener rguent...@suse.de * Makefile.in (cgraphunit.o): Add $(CFGLOOP_H) dependency. * cgraphunit.c: Include cfgloop.h. (init_lowered_empty_function): Initialize the loop tree. (assemble_thunk): Insert new BBs into loops. Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 200164) +++ gcc/Makefile.in (working copy) @@ -2903,7 +2903,7 @@ cgraphunit.o : cgraphunit.c $(CONFIG_H) $(TREE_FLOW_H) $(TREE_PASS_H) debug.h $(DIAGNOSTIC_H) \ $(FIBHEAP_H) output.h $(PARAMS_H) $(RTL_H) $(IPA_PROP_H) \ gt-cgraphunit.h tree-iterator.h $(COVERAGE_H) $(TREE_DUMP_H) \ - $(GIMPLE_PRETTY_PRINT_H) $(IPA_INLINE_H) $(IPA_UTILS_H) \ + $(GIMPLE_PRETTY_PRINT_H) $(IPA_INLINE_H) $(IPA_UTILS_H) $(CFGLOOP_H) \ $(LTO_STREAMER_H) output.h $(REGSET_H) $(EXCEPT_H) $(GCC_PLUGIN_H) plugin.h cgraphclones.o : cgraphclones.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ $(TREE_H) langhooks.h $(TREE_INLINE_H) toplev.h $(DIAGNOSTIC_CORE_H) $(FLAGS_H) $(GGC_H) \ Index: gcc/cgraphunit.c === --- gcc/cgraphunit.c(revision 200164) +++ gcc/cgraphunit.c(working copy) @@ -192,6 +192,7 @@ along with GCC; see the file COPYING3. #include ipa-utils.h #include lto-streamer.h #include except.h +#include cfgloop.h #include regset.h /* FIXME: For reg_obstack. */ /* Queue of cgraph nodes scheduled to be added into cgraph. This is a @@ -1196,18 +1197,24 @@ init_lowered_empty_function (tree decl, init_tree_ssa (cfun); init_ssa_operands (cfun); cfun-gimple_df-in_ssa_p = true; + cfun-curr_properties |= PROP_ssa; } DECL_INITIAL (decl) = make_node (BLOCK); DECL_SAVED_TREE (decl) = error_mark_node; - cfun-curr_properties |= -(PROP_gimple_lcf | PROP_gimple_leh | PROP_cfg | PROP_ssa | PROP_gimple_any); + cfun-curr_properties |= (PROP_gimple_lcf | PROP_gimple_leh | PROP_gimple_any + | PROP_cfg | PROP_loops); + + set_loops_for_fn (cfun, ggc_alloc_cleared_loops ()); + init_loops_structure (cfun, loops_for_fn (cfun), 1); + loops_for_fn (cfun)-state |= LOOPS_MAY_HAVE_MULTIPLE_LATCHES; /* Create BB for body of the function and connect it properly. */ bb = create_basic_block (NULL, (void *) 0, ENTRY_BLOCK_PTR); - make_edge (ENTRY_BLOCK_PTR, bb, 0); + make_edge (ENTRY_BLOCK_PTR, bb, EDGE_FALLTHRU); make_edge (bb, EXIT_BLOCK_PTR, 0); + add_bb_to_loop (bb, ENTRY_BLOCK_PTR-loop_father); return bb; } @@ -1452,6 +1459,9 @@ assemble_thunk (struct cgraph_node *node then_bb = create_basic_block (NULL, (void *) 0, bb); return_bb = create_basic_block (NULL, (void *) 0, then_bb); else_bb = create_basic_block (NULL, (void *) 0, else_bb); + add_bb_to_loop (then_bb, bb-loop_father); + add_bb_to_loop (return_bb, bb-loop_father); + add_bb_to_loop (else_bb, bb-loop_father); remove_edge (single_succ_edge (bb)); true_label = gimple_block_label (then_bb); stmt = gimple_build_cond (NE_EXPR, restmp,
Re: [PATCH] Re-write LTO type merging again, do tree merging
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 -- a...@linux.intel.com -- Speaking for myself only.
Re: [C++ Patch / RFC] PR 53211
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 think we need to consider whether the initializer is dependent here; if the array has no length and has an initializer, it must be that we couldn't determine its length in cp_complete_array_type because it is dependent. Eventually, we'll have to decide where we want to commit this: 56794 is fixed in 4.7 and 4.8 too, but it's true that the issue with the specific testcase attached by Jon isn't a regression. I think apply it to 4.8 as well. Jason
[PATCH] lto_tree_ref_encoder TLC
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 pointer-set.h dependency.
* lto-streamer.h: Include pointer-set.h.
(struct lto_decl_slot): Remove.
(struct lto_tree_ref_encoder): Make tree_hash_table a pointer-map.
Remove next_index entry.
(lto_hash_decl_slot_node, lto_eq_decl_slot_node,
lto_hash_type_slot_node, lto_eq_type_slot_node): Remove.
(lto_init_tree_ref_encoder): Adjust.
(lto_destroy_tree_ref_encoder): Likewise.
* lto-section-out.c (lto_hash_decl_slot_node, lto_eq_decl_slot_node,
lto_hash_type_slot_node, lto_eq_type_slot_node): Remove.
(lto_output_decl_index): Adjust.
(lto_new_out_decl_state): Likewise.
(lto_record_function_out_decl_state): Likewise.
* lto-streamer-out.c (copy_function): Likewise.
Index: gcc/lto-streamer.h
===
*** gcc/lto-streamer.h (revision 200165)
--- gcc/lto-streamer.h (working copy)
*** along with GCC; see the file COPYING3.
*** 33,38
--- 33,39
#include alloc-pool.h
#include gcov-io.h
#include diagnostic.h
+ #include pointer-set.h
/* Define when debugging the LTO streamer. This causes the writer
to output the numeric value for the memory address of the tree node
*** struct GTY(()) lto_tree_ref_table
*** 474,494
};
- /* Mapping between trees and slots in an array. */
- struct lto_decl_slot
- {
- tree t;
- int slot_num;
- };
-
-
/* The lto_tree_ref_encoder struct is used to encode trees into indices. */
struct lto_tree_ref_encoder
{
! htab_t tree_hash_table; /* Maps pointers to indices. */
! unsigned int next_index;/* Next available index. */
! vectree trees;/* Maps indices to pointers. */
};
--- 475,486
};
/* The lto_tree_ref_encoder struct is used to encode trees into indices. */
struct lto_tree_ref_encoder
{
! pointer_map_t *tree_hash_table; /* Maps pointers to indices. */
! vectree trees;/* Maps indices to pointers. */
};
*** extern void lto_value_range_error (const
*** 788,797
HOST_WIDE_INT) ATTRIBUTE_NORETURN;
/* In lto-section-out.c */
- extern hashval_t lto_hash_decl_slot_node (const void *);
- extern int lto_eq_decl_slot_node (const void *, const void *);
- extern hashval_t lto_hash_type_slot_node (const void *);
- extern int lto_eq_type_slot_node (const void *, const void *);
extern void lto_begin_section (const char *, bool);
extern void lto_end_section (void);
extern void lto_write_stream (struct lto_output_stream *);
--- 780,785
*** lto_tag_check_range (enum LTO_tags actua
*** 1007,1017
/* Initialize an lto_out_decl_buffer ENCODER. */
static inline void
! lto_init_tree_ref_encoder (struct lto_tree_ref_encoder *encoder,
! htab_hash hash_fn, htab_eq eq_fn)
{
! encoder-tree_hash_table = htab_create (37, hash_fn, eq_fn, free);
! encoder-next_index = 0;
encoder-trees.create (0);
}
--- 995,1003
/* Initialize an lto_out_decl_buffer ENCODER. */
static inline void
! lto_init_tree_ref_encoder (struct lto_tree_ref_encoder *encoder)
{
! encoder-tree_hash_table = pointer_map_create ();
encoder-trees.create (0);
}
*** lto_destroy_tree_ref_encoder (struct lto
*** 1023,1029
{
/* Hash table may be delete already. */
if (encoder-tree_hash_table)
! htab_delete (encoder-tree_hash_table);
encoder-trees.release ();
}
--- 1009,1015
{
/* Hash table may be delete already. */
if (encoder-tree_hash_table)
! pointer_map_destroy (encoder-tree_hash_table);
encoder-trees.release ();
}
Index: gcc/lto-section-out.c
===
*** gcc/lto-section-out.c (revision 200165)
--- gcc/lto-section-out.c (working copy)
*** static veclto_out_decl_state_ptr decl_
*** 48,107
generate the decl directory later. */
veclto_out_decl_state_ptr lto_function_decl_states;
- /* Returns a hash code for P. */
-
- hashval_t
- lto_hash_decl_slot_node (const void *p)
- {
- const struct lto_decl_slot *ds = (const struct lto_decl_slot *) p;
-
- /*
- return (hashval_t) DECL_UID (ds-t);
- */
- return (hashval_t) TREE_HASH (ds-t);
- }
-
-
- /* Returns nonzero if P1 and P2 are equal. */
-
- int
- lto_eq_decl_slot_node (const void *p1, const void *p2)
- {
- const struct lto_decl_slot *ds1 =
- (const struct lto_decl_slot *) p1;
- const struct lto_decl_slot *ds2 =
- (const struct lto_decl_slot *) p2;
-
- /*
Re: [C++ Patch / RFC] PR 53211
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 work, but I'm not
sure it's 100% correct.
I don't think we need to consider whether the initializer is dependent
here; if the array has no length and has an initializer, it must be
that we couldn't determine its length in cp_complete_array_type
because it is dependent.
Ah, fantastic. I really hoped we could say something like that but
seemed too easy ;) I'm finishing testing the below then.
Eventually, we'll have to decide where we want to commit this: 56794 is
fixed in 4.7 and 4.8 too, but it's true that the issue with the specific
testcase attached by Jon isn't a regression.
I think apply it to 4.8 as well.
Agreed.
Paolo.
Index: cp/parser.c
===
--- cp/parser.c (revision 200169)
+++ cp/parser.c (working copy)
@@ -9750,10 +9750,7 @@ cp_parser_range_for (cp_parser *parser, tree scope
range_expr = error_mark_node;
stmt = begin_range_for_stmt (scope, init);
finish_range_for_decl (stmt, range_decl, range_expr);
- if (range_expr != error_mark_node
- !type_dependent_expression_p (range_expr)
- /* The length of an array might be dependent. */
- COMPLETE_TYPE_P (complete_type (TREE_TYPE (range_expr)))
+ if (!type_dependent_expression_p (range_expr)
/* do_auto_deduction doesn't mess with template init-lists. */
!BRACE_ENCLOSED_INITIALIZER_P (range_expr))
do_range_for_auto_deduction (range_decl, range_expr);
Index: cp/pt.c
===
--- cp/pt.c (revision 200169)
+++ cp/pt.c (working copy)
@@ -20079,6 +20079,29 @@ type_dependent_expression_p (tree expression)
VAR_HAD_UNKNOWN_BOUND (expression))
return true;
+ /* An array of unknown bound depending on a variadic parameter, eg:
+
+ templatetypename... Args
+ void foo (Args... args)
+ {
+ int arr[] = { args... };
+ }
+
+ templateint... vals
+ void bar ()
+ {
+ int arr[] = { vals... };
+ }
+
+ If the array has no length and has an initializer, it must be that
+ we couldn't determine its length in cp_complete_array_type because
+ it is dependent. */
+ if (VAR_P (expression)
+ TREE_CODE (TREE_TYPE (expression)) == ARRAY_TYPE
+ !TYPE_DOMAIN (TREE_TYPE (expression))
+ DECL_INITIAL (expression))
+ return true;
+
if (TREE_TYPE (expression) == unknown_type_node)
{
if (TREE_CODE (expression) == ADDR_EXPR)
Index: testsuite/g++.dg/cpp0x/decltype55.C
===
--- testsuite/g++.dg/cpp0x/decltype55.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype55.C (working copy)
@@ -0,0 +1,20 @@
+// PR c++/53211
+// { dg-do compile { target c++11 } }
+
+templatetypename A, typename B
+ struct is_same { static const bool value = false; };
+
+templatetypename A
+ struct is_sameA, A { static const bool value = true; };
+
+templatetypename... Args
+void func(Args... args)
+{
+ int arr[] = { args... };
+ static_assert (is_samedecltype(arr), int[sizeof...(Args)]::value, );
+}
+
+int main()
+{
+ func(1, 2, 3, 4);
+}
[ARM][Insn classification refactoring 2/N] Update instruction classification documentation
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
Re: [PATCH] Add command line parsing of -fsanitize
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 Var(flag_sanitize) to the line after fsanitize= ?
I think that would create a string variable, whereas an integer is what's
wanted here.
We already have say:
Wstack-usage=
Common Joined RejectNegative UInteger Var(warn_stack_usage) Init(-1) Warning
Warn if stack usage might be larger than specified amount
that creates
#ifdef GENERATOR_FILE
extern int warn_stack_usage;
#else
int x_warn_stack_usage;
#define warn_stack_usage global_options.x_warn_stack_usage
#endif
so I guess UInteger Var(flag_sanitize) then would do the trick.
Nope, that would mean that argument to ‘-fsanitize=’ should be
a non-negative integer. So I'm keeping common.opt as it was...
Though, now looking at it, -fsanitize={address,thread} aren't
RejectNegative, so they accept also -fno-sanitize=address etc.
Marek, thus your patch should handle that properly too, say if you do:
-fsanitize=undefined -fno-sanitize=shift
it should first or into the flag_sanitize bitmask SANITIZE_UNDEFINED
and then and it with ~SANITIZE_SHIFT.
Ok, should be done now (together with other nit-fixes).
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-06-18 Marek Polacek pola...@redhat.com
* common.opt (flag_sanitize): Add variable.
(fsanitize=): Add option.
(fsanitize=thread): Remove option.
(fsanitize=address): Likewise.
* flag-types.h (sanitize_code): New enum.
* opts.c (common_handle_option): Parse command line arguments
of -fsanitize=.
* varasm.c (get_variable_section): Adjust.
(assemble_noswitch_variable): Likewise.
(assemble_variable): Likewise.
(output_constant_def_contents): Likewise.
(categorize_decl_for_section): Likewise.
(place_block_symbol): Likewise.
(output_object_block): Likewise.
* builtins.def: Likewise.
* toplev.c (compile_file): Likewise.
(process_options): Likewise.
* cppbuiltin.c: Likewise.
* tsan.c (tsan_pass): Likewise.
(tsan_gate): Likewise.
(tsan_gate_O0): Likewise.
* cfgexpand.c (partition_stack_vars): Likewise.
(expand_stack_vars): Likewise.
(defer_stack_allocation): Likewise.
(expand_used_vars): Likewise.
* cfgcleanup.c (old_insns_match_p): Likewise.
* asan.c (asan_finish_file): Likewise.
(asan_instrument): Likewise.
(gate_asan): Likewise.
--- gcc/opts.c.mp 2013-06-18 13:56:52.113609043 +0200
+++ gcc/opts.c 2013-06-18 13:57:50.595853767 +0200
@@ -1405,6 +1405,70 @@ common_handle_option (struct gcc_options
opts-x_exit_after_options = true;
break;
+case OPT_fsanitize_:
+ {
+ const char *p = arg;
+ while (*p != 0)
+ {
+ static const struct
+ {
+ const char *const name;
+ unsigned int flag;
+ size_t len;
+ } spec[] =
+ {
+ { address, SANITIZE_ADDRESS, sizeof address - 1 },
+ { thread, SANITIZE_THREAD, sizeof thread - 1 },
+ /* For now, let's hide this.
+ { shift, SANITIZE_SHIFT, sizeof shift - 1 },
+ { integer-divide-by-zero, SANITIZE_DIVIDE,
+ sizeof integer-divide-by-zero - 1 },
+ { undefined, SANITIZE_UNDEFINED, sizeof undefined - 1 },
+ */
+ { NULL, 0, 0 }
+ };
+ const char *comma;
+ size_t len, i;
+ bool found = false;
+
+ comma = strchr (p, ',');
+ if (comma == NULL)
+ len = strlen (p);
+ else
+ len = comma - p;
+ if (len == 0)
+ {
+ p = comma + 1;
+ continue;
+ }
+
+ /* Check to see if the string matches an option class name. */
+ for (i = 0; spec[i].name != NULL; ++i)
+ if (len == spec[i].len
+ memcmp (p, spec[i].name, len) == 0)
+ {
+ /* Handle both -fsanitize and -fno-sanitize cases. */
+ if (value)
+ flag_sanitize |= spec[i].flag;
+ else
+ flag_sanitize = ~spec[i].flag;
+ found = true;
+ break;
+ }
+
+ if (! found)
+ warning_at (loc, 0,
+ unrecognized argument to -fsanitize= option: %q.*s,
+ (int) len, p);
+
+ if (comma == NULL)
+ break;
+ p = comma + 1;
+ }
+
+ break;
+ }
+
case OPT_O:
case OPT_Os:
case OPT_Ofast:
--- gcc/varasm.c.mp 2013-06-18
[PATCH, ARM] Reintroduce minipool ranges for zero-extension insn patterns
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 (set (reg:SI 8 r8 [orig:197 s.4 ] [197])
(zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [7
S2 A16]))) [...] 161 {*arm_zero_extendhisi2_v6}
(nil))
The reasoning behind the cleanup was that the instructions in question
have no immediate constraints -- but the minipool code is used for more
than just immediates, e.g. in the above case where a symbol reference
(m) is loaded.
I don't have a test case for the problem on mainline at present, but I
believe it is still a latent bug. Tested with the default multilibs (ARM
Thumb mode) on arm-none-eabi, with no regressions. (The patch has
also been tested with more multilibs on our local branches for a while,
and I did ensure previously that it did not adversely affect Bernd's
patch linked above.)
OK to apply?
Thanks,
Julian
ChangeLog
gcc/
* arm.md (*thumb1_zero_extendhisi2, *arm_zero_extendhisi2)
(*arm_zero_extendhisi2_v6, *thumb1_zero_extendqisi2)
(*thumb1_zero_extendqisi2_v6, *arm_zero_extendqisi2)
(*arm_zero_extendqisi2_v6): Add pool_range, neg_pool_range
attributes.
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 200171)
+++ gcc/config/arm/arm.md (working copy)
@@ -5313,7 +5313,8 @@
[(if_then_else (eq_attr is_arch6 yes)
(const_int 2) (const_int 4))
(const_int 4)])
- (set_attr type simple_alu_shift, load_byte)]
+ (set_attr type simple_alu_shift, load_byte)
+ (set_attr pool_range *,60)]
)
(define_insn *arm_zero_extendhisi2
@@ -5324,7 +5325,9 @@
#
ldr%(h%)\\t%0, %1
[(set_attr type alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,256)
+ (set_attr neg_pool_range *,244)]
)
(define_insn *arm_zero_extendhisi2_v6
@@ -5335,7 +5338,9 @@
uxth%?\\t%0, %1
ldr%(h%)\\t%0, %1
[(set_attr predicable yes)
- (set_attr type simple_alu_shift,load_byte)]
+ (set_attr type simple_alu_shift,load_byte)
+ (set_attr pool_range *,256)
+ (set_attr neg_pool_range *,244)]
)
(define_insn *arm_zero_extendhisi2addsi
@@ -5405,7 +5410,8 @@
uxtb\\t%0, %1
ldrb\\t%0, %1
[(set_attr length 2)
- (set_attr type simple_alu_shift,load_byte)]
+ (set_attr type simple_alu_shift,load_byte)
+ (set_attr pool_range *,32)]
)
(define_insn *arm_zero_extendqisi2
@@ -5417,7 +5423,9 @@
ldr%(b%)\\t%0, %1\\t%@ zero_extendqisi2
[(set_attr length 8,4)
(set_attr type alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,4096)
+ (set_attr neg_pool_range *,4084)]
)
(define_insn *arm_zero_extendqisi2_v6
@@ -5428,7 +5436,9 @@
uxtb%(%)\\t%0, %1
ldr%(b%)\\t%0, %1\\t%@ zero_extendqisi2
[(set_attr type simple_alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,4096)
+ (set_attr neg_pool_range *,4084)]
)
(define_insn *arm_zero_extendqisi2addsi
Re: [PATCH, ARM] Reintroduce minipool ranges for zero-extension insn patterns
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 with instructions like:
(insn 77 53 87 (set (reg:SI 8 r8 [orig:197 s.4 ] [197])
(zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [7
S2 A16]))) [...] 161 {*arm_zero_extendhisi2_v6}
(nil))
The reasoning behind the cleanup was that the instructions in question
have no immediate constraints -- but the minipool code is used for more
than just immediates, e.g. in the above case where a symbol reference
(m) is loaded.
I don't have a test case for the problem on mainline at present, but I
believe it is still a latent bug. Tested with the default multilibs (ARM
Thumb mode) on arm-none-eabi, with no regressions. (The patch has
also been tested with more multilibs on our local branches for a while,
and I did ensure previously that it did not adversely affect Bernd's
patch linked above.)
OK to apply?
Pushing extending loads (particularly sign-extending loads) into the
minipools adversely affects freedom of pool placement (since the offset
ranges are limited).
And they shouldn't be happening anyway. I really don't think this is
the right solution to the problem you have.
R.
Thanks,
Julian
ChangeLog
gcc/
* arm.md (*thumb1_zero_extendhisi2, *arm_zero_extendhisi2)
(*arm_zero_extendhisi2_v6, *thumb1_zero_extendqisi2)
(*thumb1_zero_extendqisi2_v6, *arm_zero_extendqisi2)
(*arm_zero_extendqisi2_v6): Add pool_range, neg_pool_range
attributes.
ze-minipool-ranges-fsf-2.diff
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 200171)
+++ gcc/config/arm/arm.md (working copy)
@@ -5313,7 +5313,8 @@
[(if_then_else (eq_attr is_arch6 yes)
(const_int 2) (const_int 4))
(const_int 4)])
- (set_attr type simple_alu_shift, load_byte)]
+ (set_attr type simple_alu_shift, load_byte)
+ (set_attr pool_range *,60)]
)
(define_insn *arm_zero_extendhisi2
@@ -5324,7 +5325,9 @@
#
ldr%(h%)\\t%0, %1
[(set_attr type alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,256)
+ (set_attr neg_pool_range *,244)]
)
(define_insn *arm_zero_extendhisi2_v6
@@ -5335,7 +5338,9 @@
uxth%?\\t%0, %1
ldr%(h%)\\t%0, %1
[(set_attr predicable yes)
- (set_attr type simple_alu_shift,load_byte)]
+ (set_attr type simple_alu_shift,load_byte)
+ (set_attr pool_range *,256)
+ (set_attr neg_pool_range *,244)]
)
(define_insn *arm_zero_extendhisi2addsi
@@ -5405,7 +5410,8 @@
uxtb\\t%0, %1
ldrb\\t%0, %1
[(set_attr length 2)
- (set_attr type simple_alu_shift,load_byte)]
+ (set_attr type simple_alu_shift,load_byte)
+ (set_attr pool_range *,32)]
)
(define_insn *arm_zero_extendqisi2
@@ -5417,7 +5423,9 @@
ldr%(b%)\\t%0, %1\\t%@ zero_extendqisi2
[(set_attr length 8,4)
(set_attr type alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,4096)
+ (set_attr neg_pool_range *,4084)]
)
(define_insn *arm_zero_extendqisi2_v6
@@ -5428,7 +5436,9 @@
uxtb%(%)\\t%0, %1
ldr%(b%)\\t%0, %1\\t%@ zero_extendqisi2
[(set_attr type simple_alu_shift,load_byte)
- (set_attr predicable yes)]
+ (set_attr predicable yes)
+ (set_attr pool_range *,4096)
+ (set_attr neg_pool_range *,4084)]
)
(define_insn *arm_zero_extendqisi2addsi
Re: [PATCH] Re-write LTO type merging again, do tree merging
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 should have been lowered by this point. */ context = decl_function_context (exp); - gcc_assert (!context + gcc_assert (SCOPE_FILE_SCOPE_P (context) || context == current_function_decl || TREE_STATIC (exp) || DECL_EXTERNAL (exp) might fix it. Just confirmed with the small build. It does. Running the large build now. Please check in. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
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 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) +(plus:SI (plus:SI (match_dup 2) (match_dup 3)) + (geu:SI (reg:CC CC_REGNUM) (const_int 0]) + ... but what's this bit about? The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? -- Meador Inge CodeSourcery / Mentor Embedded
Re: [PATCH] Remove LTO streamer cache pointer-map for LTO input
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 patch makes it possible to not maintain that map. Cool! It also costs a lot of CPU cycles, according to my profiles. -Andi -- a...@linux.intel.com -- Speaking for myself only
PATCH: Fix a typo in comments in config/i386/i386.c
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 + + * config/i386/i386.c (initial_ix86_tune_features): Fix a typo + in comments. + 2013-06-18 Julian Brown jul...@codesourcery.com * config/arm/arm.c (neon_vector_mem_operand): Add strict argument. Index: config/i386/i386.c === --- config/i386/i386.c (revision 200173) +++ config/i386/i386.c (working copy) @@ -2085,7 +2085,7 @@ static unsigned int initial_ix86_tune_fe instructions. */ ~m_ATOM, - /* X86_SOFTARE_PREFETCHING_BENEFICIAL: Enable software prefetching + /* X86_TUNE_SOFTWARE_PREFETCHING_BENEFICIAL: Enable software prefetching at -O3. For the moment, the prefetching seems badly tuned for Intel chips. */ m_K6_GEODE | m_AMD_MULTIPLE,
Re: [patch] gcov intermediate format
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 testsuite/g++.dg/gcov directory. Thanks, Sharad Honza
Re: [Committed] S/390: PR57609 fix - use next_active_insn instead of next_real_insn
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 should work:
Index: s390.c
===
--- s390.c (revision 200173)
+++ s390.c (working copy)
@@ -7023,7 +7023,7 @@ s390_chunkify_start (void)
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
- rtx vec_insn = next_active_insn (insn);
+ rtx vec_insn = NEXT_INSN (insn);
if (! vec_insn || ! JUMP_TABLE_DATA_P (vec_insn))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
@@ -7054,7 +7054,7 @@ s390_chunkify_start (void)
{
/* Find the jump table used by this casesi jump. */
rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
- rtx vec_insn = next_active_insn (vec_label);
+ rtx vec_insn = NEXT_INSN (vec_label);
if (vec_insn JUMP_TABLE_DATA_P (vec_insn))
{
rtx vec_pat = PATTERN (vec_insn);
BTW I don't understand how a label satisfying the following can be
true for a label before a jump table:
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
LABEL_PRESERVE_P should never be set on a label before a
JUMP_TABLE_DATA, and LABEL_NAME should be NULL.
Better yet would be to use tablejump_p instead of examining the
pattern by hand, e.g.:
Index: s390.c
===
--- s390.c (revision 200173)
+++ s390.c (working copy)
@@ -7023,7 +7023,7 @@ s390_chunkify_start (void)
if (LABEL_P (insn)
(LABEL_PRESERVE_P (insn) || LABEL_NAME (insn)))
{
- rtx vec_insn = next_active_insn (insn);
+ rtx vec_insn = NEXT_INSN (insn);
if (! vec_insn || ! JUMP_TABLE_DATA_P (vec_insn))
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (insn));
}
@@ -7033,6 +7033,8 @@ s390_chunkify_start (void)
else if (JUMP_P (insn))
{
rtx pat = PATTERN (insn);
+ rtx table;
+
if (GET_CODE (pat) == PARALLEL XVECLEN (pat, 0) 2)
pat = XVECEXP (pat, 0, 0);
@@ -7046,28 +7048,18 @@ s390_chunkify_start (void)
bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (label));
}
}
- else if (GET_CODE (pat) == PARALLEL
- XVECLEN (pat, 0) == 2
- GET_CODE (XVECEXP (pat, 0, 0)) == SET
- GET_CODE (XVECEXP (pat, 0, 1)) == USE
- GET_CODE (XEXP (XVECEXP (pat, 0, 1), 0)) == LABEL_REF)
- {
- /* Find the jump table used by this casesi jump. */
- rtx vec_label = XEXP (XEXP (XVECEXP (pat, 0, 1), 0), 0);
- rtx vec_insn = next_active_insn (vec_label);
- if (vec_insn JUMP_TABLE_DATA_P (vec_insn))
- {
- rtx vec_pat = PATTERN (vec_insn);
- int i, diff_p = GET_CODE (vec_pat) == ADDR_DIFF_VEC;
-
- for (i = 0; i XVECLEN (vec_pat, diff_p); i++)
- {
- rtx label = XEXP (XVECEXP (vec_pat, diff_p, i), 0);
-
- if (s390_find_pool (pool_list, label)
- != s390_find_pool (pool_list, insn))
- bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (label));
- }
+ else if (tablejump_p (insn, NULL, table))
+ {
+ rtx vec_pat = PATTERN (table);
+ int i, diff_p = GET_CODE (vec_pat) == ADDR_DIFF_VEC;
+
+ for (i = 0; i XVECLEN (vec_pat, diff_p); i++)
+ {
+ rtx label = XEXP (XVECEXP (vec_pat, diff_p, i), 0);
+
+ if (s390_find_pool (pool_list, label)
+ != s390_find_pool (pool_list, insn))
+ bitmap_set_bit (far_labels, CODE_LABEL_NUMBER (label));
}
}
}
Ciao!
Steven
Re: [PATCH] Re-write LTO type merging again, do tree merging
Just confirmed with the small build. It does. Running the large build now. Large build worked too. Please check in.
