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 or
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 side.
On Thu, Mar 17, 2011 at 1:09 PM, Jeff Law 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.
>
>
This cau
On 02/06/2012 05:06 AM, Jakub Jelinek wrote:
> 2012-02-06 Jakub Jelinek
>
> 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 02/06/2012 05:39 AM, Uros Bizjak wrote:
> 2012-02-06 Uros Bizjak
>
> * config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Regenerated.
Ok.
r~
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.
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 tra
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/l
On 02/09/2012 03:47 PM, Uros Bizjak wrote:
> 2012-02-10 Uros Bizjak
>
> * 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, compatible
>
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
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
* config/sparc/sparc.c (sparc_flat_expand_prologue): Use emit_use.
* config/sparc/sparc.m
Seeing as how Uros is starting to go down the path of cleaning up the
flags handling for x86, I thought I'd go ahead and knock up the idea
that I've been tossing around to help automate the process of building
patterns that match both clobbering the flags and setting the flags to
a comparison.
Thi
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. Th
> 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.
--
Rainer Orth writes:
> Ian Lance Taylor 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 I tested on
>> has all these functio
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
* lra-int
On Fri, Feb 10, 2012 at 12:46 PM, Michael Meissner
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 << this_node->cmpbit) )
>
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 ch
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 = thi
> 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
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, OK?
Hi,
ChangeLog
2012-02-10 Kai Tietz
* 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
===
Jonathan Wakely 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 such
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 t
On Fri, Feb 10, 2012 at 9:55 AM, Uros Bizjak wrote:
> On Fri, Feb 10, 2012 at 6:42 PM, H.J. Lu 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.
>
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. Th
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.
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 lea
On Fri, Feb 10, 2012 at 6:42 PM, H.J. Lu 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
>
> PR target/
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.
Especiall
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. My
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
PR target/5
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
PR target/52146
* config/i386/i386.c (ix86_legitimate_address_p): Disallow
negative c
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 comment
On Fri, Feb 10, 2012 at 4:36 PM, William J. Schmidt
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
>> wrote:
>> > Jakub, thanks! Based on this, I believe the patch is correct in its
>> > handling of the STMT_VINFO_PA
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 x86_6
This patch adds two common shortcuts to the failure reproducer
script.
Committed to trunk.
2012-02-10 Diego Novillo
* repro_fail: Add --debug and --debug-tui flags.
diff --git a/contrib/repro_fail b/contrib/repro_fail
index 8100456..c55d080 100755
--- a/contrib/repro_fail
+++ b/con
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. Bootstr
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 st
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
> 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
On Fri, 2012-02-10 at 16:22 +0100, Richard Guenther wrote:
> On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
> 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 misi
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)
>
On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
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 vect_pattern_recog was saying:
> I thoug
On Fri, Feb 10, 2012 at 3:19 PM, Jakub Jelinek wrote:
> 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_ATOM
> "Kai" == Kai Tietz 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
2012/2/10 Richard Guenther :
> On Fri, Feb 10, 2012 at 9:36 AM, Kai Tietz wrote:
>> 2012/2/9 Richard Guenther :
>>> 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
>>>
>>> Ma
Jonathan Wakely 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.
>>
>>> On Mac
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, b
On Fri, Feb 10, 2012 at 2:13 PM, Jing Yu wrote:
> On Thu, Feb 9, 2012 at 12:54 AM, Carrot Wei 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 approve it for googl
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 cl
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",
Richard Guenther writes:
> On Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor wrote:
The master Go math library uses assembler code on 386 processors to take
advantage of 387 instructions. This
Rainer Orth 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
> /vol/gcc/src/hg/trunk/local/
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))
{
basic_
Ian Lance Taylor writes:
> Ian Lance Taylor 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
>> TLS variables, which
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
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
>
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
> wrote:
> > Following is a revision of yesterday's PR50031 patch submiss
On Fri, Feb 10, 2012 at 2:12 PM, Jonathan Wakely 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
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?
Kai Tietz 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 assert the presense of
> 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 com
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 Thu, Feb 9, 2012 at 5:56 PM, William J. Schmidt
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
> improvements in SPEC. OK for tr
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
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 reac
Hello Richard,
On 30.09.2011 19:21, Roman Zhuykov wrote:
2011/7/22 Richard Sandiford:
That's pre-approved (independently of the other patches) if it works.
...
Changed like the following. Will commit if no objections after a couple of days.
We forgot to commit this patch back in September,
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)
> /tmp/cc
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 offset
Committed as obvious.
Richard.
2012-02-10 Richard Guenther
PR translation/52193
* cgraphunit.c (cgraph_mark_functions_to_output): Fix typo.
Index: cgraphunit.c
===
--- cgraphunit.c(revision 184085)
+++ c
On Fri, Feb 10, 2012 at 9:36 AM, Kai Tietz wrote:
> 2012/2/9 Richard Guenther :
>> 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 invalid testcases. Who knows ... s
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 Thu, Feb 9, 2012 at 6:32 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> On Wed, Feb 8, 2012 at 8:38 PM, Ian Lance Taylor wrote:
>>> The master Go math library uses assembler code on 386 processors to take
>>> advantage of 387 instructions. This patch lets gccgo do the same thing
On Thu, 9 Feb 2012, Richard Henderson wrote:
> > From: rguenth at gcc dot 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 this may have gott
2012/2/9 Richard Guenther :
> On Thu, Feb 9, 2012 at 3:41 PM, Richard Guenther
> wrote:
>> On Thu, Feb 9, 2012 at 2:48 PM, Kai Tietz wrote:
>>> 2012/2/9 Richard Guenther :
On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
wrote:
> On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
>
75 matches
Mail list logo
