On Thu, 9 Feb 2012, Richard Henderson wrote:
From: rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
the __transaction_atomic // SUBCODE=[ GTMA_HAVE_STORE ] statement
looks like an overly optimistic way to start a transaction in my quick view.
Indeed. At some point this worked, but
On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor i...@google.com wrote:
The master Go math library uses assembler code on 386 processors to take
advantage of 387
Hello All,
When running cc1 in verbose mode, the announce_function from gcc/toplevel.c
displays the name of the function. However, it never emits any newline
characters. As a result, the stderr stream may contains very long lines,
which is visually unpleasant and tend to block Emacs when running
On Fri, Feb 10, 2012 at 9:36 AM, Kai Tietz ktiet...@googlemail.com wrote:
2012/2/9 Richard Guenther richard.guent...@gmail.com:
Works apart from
Running target unix/
FAIL: ext/pb_ds/regression/trie_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_set_rand.cc execution test
Maybe
Committed as obvious.
Richard.
2012-02-10 Richard Guenther rguent...@suse.de
PR translation/52193
* cgraphunit.c (cgraph_mark_functions_to_output): Fix typo.
Index: cgraphunit.c
===
--- cgraphunit.c
This weak I investigated GCC trunk fails to compile test 186.crafty
from SPECINT2000
on ARM. File validate.c compilation leads to this:
/tmp/ccXFsLlG.s: Assembler messages:
/tmp/ccXFsLlG.s:3411: Error: bad immediate value for offset (4112)
/tmp/ccXFsLlG.s:7069: Error: bad immediate value for
On 10/02/12 11:39, Roman Zhuykov wrote:
This weak I investigated GCC trunk fails to compile test 186.crafty
from SPECINT2000
on ARM. File validate.c compilation leads to this:
/tmp/ccXFsLlG.s: Assembler messages:
/tmp/ccXFsLlG.s:3411: Error: bad immediate value for offset (4112)
Hi,
this PR is about bug in my update to predict_paths_for_bb when handing abnormal
edges.
Abnormal edges can not be predicted and thus the funcition is trying to predict
paths
leading to the source BB of the edge instead. This however may lead to infinite
loop
when two regions are mutually
On Fri, Feb 10, 2012 at 01:00:16PM +0100, Jan Hubicka wrote:
Does this belong to the patch? It isn't mentioned in the ChangeLog,
nor I see how it is related...
*** libcpp/macro.c(revision 184016)
--- libcpp/macro.c(working copy)
*** tokens_buff_last_token_ptr (_cpp_buff
On Thu, Feb 9, 2012 at 5:56 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Following is a revision of yesterday's PR50031 patch submission,
modified per Richard's comments. Bootstrapped and tested with no
regressions on powerpc64-linux. I've confirmed the same performance
Ping.
Ayal, please review this patch and these three patches too:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00505.html
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00506.html
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01800.html
--
Roman Zhuykov
zhr...@ispras.ru
On Fri, Feb 10, 2012 at 01:00:16PM +0100, Jan Hubicka wrote:
Does this belong to the patch? It isn't mentioned in the ChangeLog,
nor I see how it is related...
No, it does not. I diffed toplevel dir and this is hack for some warning
that got stuck there for months. It is not what I
Kai Tietz ktiet...@googlemail.com writes:
Hmm, I see in libstdc++'s file include/bits/boost_concept_check.h some
use of '*__i++ = *__i;' and '*__i-- = *__i;', which seems to cause
part of this failure.
I don't think those __constraints functions are ever executed. They are
only present to
On 10 February 2012 10:35, Richard Guenther wrote:
Works apart from
Running target unix/
FAIL: ext/pb_ds/regression/trie_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_set_rand.cc execution test
What does libstdc++.log show for those failures?
On Fri, Feb 10, 2012 at 2:12 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 10 February 2012 10:35, Richard Guenther wrote:
Works apart from
Running target unix/
FAIL: ext/pb_ds/regression/trie_map_rand.cc execution test
FAIL: ext/pb_ds/regression/trie_set_rand.cc execution test
What
Richard, thanks. I can answer most of your questions, but for the last
one I will have to ask Ira to weigh in.
On Fri, 2012-02-10 at 13:06 +0100, Richard Guenther wrote:
On Thu, Feb 9, 2012 at 5:56 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Following is a revision of
On Fri, 2012-02-10 at 07:31 -0600, William J. Schmidt wrote:
Richard, thanks. I can answer most of your questions, but for the last
one I will have to ask Ira to weigh in.
On Fri, 2012-02-10 at 13:06 +0100, Richard Guenther wrote:
On Thu, Feb 9, 2012 at 5:56 PM, William J. Schmidt
On Fri, Feb 10, 2012 at 07:31:01AM -0600, William J. Schmidt wrote:
From the commentary at the end of tree-vect-patterns.c, only the main
statement in the pattern (the last one) is flagged as
STMT_VINFO_IN_PATTERN_P. So this is finding the new replacement
statement which has been created but
Ian Lance Taylor i...@google.com writes:
Ian Lance Taylor i...@google.com writes:
Right now it looks like there is a bug, or at least an incompatibility,
in the 64-bit versions of getcontext and setcontext. It looks like
calling setcontext on the 32-bit version does not change the value of
I've played with
Index: tree-ssa.c
===
--- tree-ssa.c (revision 184088)
+++ tree-ssa.c (working copy)
@@ -944,6 +944,11 @@ verify_ssa (bool check_modified_stmt)
if (!gimple_nop_p (stmt))
{
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
* On Solaris 8/x86 with native TLS, SETCONTEXT_CLOBBERS_TLS was
incorrectly defined, causing a proc.c compilation failure:
/vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:105:4: error: #error unknown
case for SETCONTEXT_CLOBBERS_TLS
Richard Guenther richard.guent...@gmail.com writes:
On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor i...@google.com wrote:
The master Go math library uses assembler
Hi!
These builtins are:
DEF_SYNC_BUILTIN (BUILT_IN_ATOMIC_ALWAYS_LOCK_FREE,
__atomic_always_lock_free,
BT_FN_BOOL_SIZE_CONST_VPTR, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_SYNC_BUILTIN (BUILT_IN_ATOMIC_IS_LOCK_FREE,
__atomic_is_lock_free,
Hi!
As discussed in the PR, this is a verification ICE if a call stmt
calls a same_body_alias (__comp_ctor) and IPA-CP decides to clone the
ctor, it clones the function with the body (__base_ctor), but
before the call stmts are updated, the checking fails because
the clone isn't clone or former
On Fri, Feb 10, 2012 at 2:13 PM, Jing Yu jin...@google.com wrote:
On Thu, Feb 9, 2012 at 12:54 AM, Carrot Wei car...@google.com wrote:
Hi Richard and Jakub
Since 4.6 contains the same bug, I would like to back port it to 4.6
branch. Could you approve it for 4.6?
Jing and Doug
Could you
Jakub, thanks! Based on this, I believe the patch is correct in its
handling of the STMT_VINFO_PATTERN_DEF_SEQ logic, without any double
counting.
I misinterpreted what the commentary for vect_pattern_recog was saying:
I thought that all replacements were hung off of the last pattern
statement,
Jonathan Wakely jwakely@gmail.com writes:
On 6 February 2012 19:24, Mike Stump wrote:
On Feb 5, 2012, at 12:26 PM, Jonathan Wakely wrote:
PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
with the Pthreads static initializer macros such as
PTHREAD_MUTEX_INITIALIZER.
2012/2/10 Richard Guenther richard.guent...@gmail.com:
On Fri, Feb 10, 2012 at 9:36 AM, Kai Tietz ktiet...@googlemail.com wrote:
2012/2/9 Richard Guenther richard.guent...@gmail.com:
Works apart from
Running target unix/
FAIL: ext/pb_ds/regression/trie_map_rand.cc execution test
FAIL:
Kai == Kai Tietz ktiet...@googlemail.com writes:
Kai * include/gc_config_macros.h (GC_DLL): Define it for
Kai mingw-targets only, if
Kai we are actual in boehm-gc's build and DLL_EXPORT macro is defined.
This is ok. Thanks.
Tom
On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Jakub, thanks! Based on this, I believe the patch is correct in its
handling of the STMT_VINFO_PATTERN_DEF_SEQ logic, without any double
counting.
I misinterpreted what the commentary for
On Fri, 10 Feb 2012, Richard Guenther wrote:
I've played with
Index: tree-ssa.c
===
--- tree-ssa.c (revision 184088)
+++ tree-ssa.c (working copy)
@@ -944,6 +944,11 @@ verify_ssa (bool check_modified_stmt)
if
On Fri, 2012-02-10 at 16:22 +0100, Richard Guenther wrote:
On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Jakub, thanks! Based on this, I believe the patch is correct in its
handling of the STMT_VINFO_PATTERN_DEF_SEQ logic, without any double
On Fri, Feb 10, 2012 at 04:22:32PM +0100, Richard Guenther wrote:
On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Jakub, thanks! Based on this, I believe the patch is correct in its
handling of the STMT_VINFO_PATTERN_DEF_SEQ logic, without any double
On Fri, Feb 10, 2012 at 09:36:01AM -0600, William J. Schmidt wrote:
Per Jakub's explanation, the replacement statements are distributed over
the original pattern statements. Visiting STMT_VINFO_RELATED_STMT for a
statement marked STMT_VINFO_IN_PATTERN_P will find zero or one
replacement
This patch to the libgo garbage collector ensures that we save all the
registers on the stack when starting a GC. Otherwise we could sometimes
miss a value held in a register while scanning the stack of the
goroutine running the GC. This never happened on x86, but it did happen
on SPARC.
This patch adds two common shortcuts to the failure reproducer
script.
Committed to trunk.
2012-02-10 Diego Novillo dnovi...@google.com
* repro_fail: Add --debug and --debug-tui flags.
diff --git a/contrib/repro_fail b/contrib/repro_fail
index 8100456..c55d080 100755
---
This patch to libgo records the top of the g0 goroutine stack correctly
when not using -fsplit-stack. Without this patch the garbage collector
would scan beyond the top of the stack when looking at the g0 stack,
which could cause segmentation violations. Bootstrapped and ran Go
testsuite on
On Fri, Feb 10, 2012 at 4:36 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Fri, 2012-02-10 at 16:22 +0100, Richard Guenther wrote:
On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Jakub, thanks! Based on this, I believe the patch is
Updated the extra parameter to __atomic_{is,always}_lock_free , and bkoz
noted that the __atomic_compare_exchange documentation did not document
the 'weak' parameter.
Fixed as such, seems to format fine. OK for mainline?
Andrew
PR c/52190
* doc/extend.texi : Update
Hi,
Since constant address in x32 is signed extended to 64bit, negative
displacement without base nor index is out of range. OK for trunk?
Thanks.
H.J.
---
gcc/
2012-02-10 H.J. Lu hongjiu...@intel.com
PR target/52146
* config/i386/i386.c (ix86_legitimate_address_p):
On Fri, Feb 10, 2012 at 09:25:06AM -0800, H.J. Lu wrote:
Hi,
Since constant address in x32 is signed extended to 64bit, negative
displacement without base nor index is out of range. OK for trunk?
Here is a different patch.
H.J.
---
gcc/
2012-02-10 Uros Bizjak ubiz...@gmail.com
On Fri, 10 Feb 2012, Andrew MacLeod wrote:
Updated the extra parameter to __atomic_{is,always}_lock_free , and bkoz noted
that the __atomic_compare_exchange documentation did not document the 'weak'
parameter.
Fixed as such, seems to format fine. OK for mainline?
OK.
--
Joseph S. Myers
On 02/10/2012 01:44 AM, Richard Guenther wrote:
What is the reason to keep a GIMPLE_TRANSACTION stmt after
TM lowering and not lower it to a builtin function call?
Because real optimization hasn't happened yet, and we hold
out hope that we'll be able to delete stuff as unreachable.
Especially
On Fri, Feb 10, 2012 at 6:42 PM, H.J. Lu hongjiu...@intel.com wrote:
Since constant address in x32 is signed extended to 64bit, negative
displacement without base nor index is out of range. OK for trunk?
Here is a different patch.
H.J.
---
gcc/
2012-02-10 Uros Bizjak
On 10 February 2012 14:48, Rainer Orth wrote:
I've also noticed one feature of your patch that I don't like:
__GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
pthread_{mutex,cond}_init_function instead of passing them on as all
other gthr-posix.h functions do. This might lead
On 10 February 2012 14:48, Rainer Orth wrote:
Bootstrapped without regressions on alpha-dec-osf5.1b, ok for mainline?
Yes, this is OK, thanks for your help testing and getting all of this working.
Jon,
On 10 February 2012 14:48, Rainer Orth wrote:
I've also noticed one feature of your patch that I don't like:
__GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
pthread_{mutex,cond}_init_function instead of passing them on as all
other gthr-posix.h functions do. This might
On Fri, Feb 10, 2012 at 9:55 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Feb 10, 2012 at 6:42 PM, H.J. Lu hongjiu...@intel.com wrote:
Since constant address in x32 is signed extended to 64bit, negative
displacement without base nor index is out of range. OK for trunk?
Here is a
On 10 February 2012 18:20, Rainer Orth wrote:
Jon,
On 10 February 2012 14:48, Rainer Orth wrote:
I've also noticed one feature of your patch that I don't like:
__GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
pthread_{mutex,cond}_init_function instead of passing them on as
Jonathan Wakely jwakely@gmail.com writes:
I didn't like that feature of the patch much either, but the signature
of the mutex_init function is specified in gthr.h:
__GTHREAD_MUTEX_INIT_FUNCTION
some systems can't initialize a mutex without a
function call. On
Hi,
ChangeLog
2012-02-10 Kai Tietz kti...@redhat.com
* src/x86/ffi.c (ffi_prep_raw_closure_loc): Add thiscall
support for X86_WIN32.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and x86_64-unknown-linux-gnu.
Ok for apply?
Regards,
Kai
Index: src/x86/ffi.c
On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lead to a random insn being scheduled between a cc0
setter and user. The patch below fixes it,
I have no immediate plans. If you have time to knock something
together for Sparc, that would be fantastic.
Btw, any particular reason why the libgomp-copied linking scheme seems to be
only half-implemented?
# Set up the set of libraries that we need to link against for libitm.
# Note that
I was looking at the routelookup EEMBC benchmark and it has code of the form:
while ( this_node-cmpbit next_node-cmpbit )
{
this_node = next_node;
if ( proute-dst_addr (0x1 this_node-cmpbit) )
next_node = this_node-rlink;
else
next_node =
This patch backports the two recent trunk fixes for powerpc64
vectorization degradations. The fixes are largely identical to their
4.7 counterparts except that (a) the logic for
STMT_VINFO_PATTERN_DEF_SEQ does not apply in 4.6, and (b) the changes to
vectorizable_conversion in 4.7 correspond to
On Fri, Feb 10, 2012 at 12:46 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I was looking at the routelookup EEMBC benchmark and it has code of the form:
while ( this_node-cmpbit next_node-cmpbit )
{
this_node = next_node;
if ( proute-dst_addr (0x1
The following patch fixes arm bootstrap for LRA. The problem was in
pseudo live
range splitting and wrong assignment to multi-registers pseudos with the
same value.
The patch was successfully bootstrapped on x86/x86-64 and ARM.
Committed as rev. 184109.
2012-02-10 Vladimir Makarov
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Ian Lance Taylor i...@google.com writes:
Fixed with the appended patch, which also gathers up all the possibly
missing functions that I noticed. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu, which proves little as the system
Can you try to extract a testcase (assuming it's just a single case?).
We shouldn't
warn for layout-compatible types (but we may do so if for example struct
nesting differs).
It's more basic than that: for example, we map pointers on the C side to
addresses (integers) on the Ada side.
--
This libgo patch fixes the channel code to work correctly on big-endian
systems. The older version of the code did this right, but I forgot to
handle it in the new version. This patch also fixes the memory
structure built for the select statement to work correctly on strict
alignment systems.
It was introduced in the course of the -mflat rewrite, but can be replaced by a
single line.
Tested on SPARC/Solaris w/ and w/o -mflat, applied on the mainline.
2012-02-10 Eric Botcazou ebotca...@adacore.com
* config/sparc/sparc.c (sparc_flat_expand_prologue): Use emit_use.
The gccgo implementation of panic/recover uses the return address of a
function which called recover in order to see if that function was
invoke directly by defer. It does this by passing the address of a
label which immediately follows the function call. This requires a
small heuristic, because
On 02/09/2012 03:47 PM, Uros Bizjak wrote:
2012-02-10 Uros Bizjak ubiz...@gmail.com
* compare-elim.c (find_comparisons_in_bb): Eliminate only compares
having mode compatible with the mode of previous compare. Substitute
compare mode of previous compare with the mode,
On 02/09/2012 03:24 PM, Benjamin Kosnik wrote:
This is the rest of 51798, completing the conversion to C++11 atomics
in libstdc++. This is now a complete transition, modulo documentation
which I plan to finish as a separate patch once I am back from the ISO
C++ meeting.
tested x86_64/linux
On 02/08/2012 08:28 AM, Andrew Stubbs wrote:
Unfortunately, these don't work in Thumb mode (no IT block), and I'd have to
add arith-shift variants, I think, for ARM mode to work.
H ... I'll try again.
Does it work to simply use branches initially, and rely on post-reload
ifcvt to
On 02/04/2012 02:06 AM, Richard Sandiford wrote:
Actually I had that idea of a link-once function too, but it turned out
quite complicated to do without rewriting some generic parts of GCC as it
is currently not prepared to emit link-once functions outside C++
compilations. It's been
On 02/06/2012 05:39 AM, Uros Bizjak wrote:
2012-02-06 Uros Bizjak ubiz...@gmail.com
* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Regenerated.
Ok.
r~
On 02/06/2012 05:06 AM, Jakub Jelinek wrote:
2012-02-06 Jakub Jelinek ja...@redhat.com
PR debug/52132
* reg-stack.c (subst_stack_regs_in_debug_insn): Don't use
get_true_reg.
* gcc.dg/pr52132.c: New test.
Ok.
r~
On Thu, Mar 17, 2011 at 1:09 PM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I had pulled the patch for 37273 during the 4.6 cycle due to exposing
several latent problems. I've just reinstalled it and will (of course)
keep an eye out for any problems.
Hi Eric,
Can you try to extract a testcase (assuming it's just a single case?).
We shouldn't
warn for layout-compatible types (but we may do so if for example struct
nesting differs).
It's more basic than that: for example, we map pointers on the C side to
addresses (integers) on the Ada
The FFI documentation doesn't mention it, but it turns out that the FFI
library promotes integer result types. That is, if a function is
declared as returning short, FFI will actually store the result as an
int. The code in libgo was getting away with not supporting this
because allocating one
71 matches
Mail list logo
