Thomas Schwinge wrote:
> This is about sh and sh64 GDB sim testing for the whole toolchain. (I
> also do have sh4a hardware available, where testing is working fine.)
> Kaz, could you please have a look whether this looks basically sane, that
> my assumptions and the results I'm getting are about
Hi,
thank you for your reply. So I cannot use the Helgrind tool without disabling
the futexes. Do you know if exist a open source thread analyzer?
Thank you
Hi!
This is about sh and sh64 GDB sim testing for the whole toolchain. (I
also do have sh4a hardware available, where testing is working fine.)
Kaz, could you please have a look whether this looks basically sane, that
my assumptions and the results I'm getting are about right, etc.?
On Wed, 22
On 22 February 2012 19:05, James Courtier-Dutton wrote:
> On 22 February 2012 13:34, 嘉谟 wrote:
>> 2012/2/22 James Courtier-Dutton :
>>> The order that function parameters are evaluated is undefined. Therefore it
>>> is wise to ensure that no matter what order they are evaluated, the result
>>> sh
On 22 February 2012 13:34, 嘉谟 wrote:
> 2012/2/22 James Courtier-Dutton :
>> The order that function parameters are evaluated is undefined. Therefore it
>> is wise to ensure that no matter what order they are evaluated, the result
>> should be the same. It is the ++ that breaks it in this case. Did
On 02/22/2012 05:15 PM, Henderson, Stuart wrote:
>> Make an exception for BImode and small_register_classes_for_mode_p
>> (BImode).
>
> Thanks Bernd.
>
> Would this be acceptable:
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 8d81c89..e4e13ab 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
>
>Make an exception for BImode and small_register_classes_for_mode_p
>(BImode).
Thanks Bernd.
Would this be acceptable:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 8d81c89..e4e13ab 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2295,7 +2295,9 @@ noce_get_condition (rtx jump, rtx *earliest, bool
On 02/22/2012 01:23 PM, Henderson, Stuart wrote:
> The problem with noce_get_condition is that if the condition variable
> is a MODE_INT register it will return it and set earliest as the jump
> insn itself. I'm not sure why this is the case, but it seems like
> something we don't want to be doing
2012/2/22 James Courtier-Dutton :
> The order that function parameters are evaluated is undefined. Therefore it
> is wise to ensure that no matter what order they are evaluated, the result
> should be the same. It is the ++ that breaks it in this case. Didn't you get
> a compiler warning?
Yes you
>Not really. I think in dead_or_predicable you need to check in the
> /* Try the NCE path if the CE path did not result in any changes. */
>block (I assume this is where we end up in this testcase) that none of
>the live hard regs at the point where we are going to insert the insns
>are in small
On Wed, Feb 22, 2012 at 12:19 PM, Georg-Johann Lay wrote:
> toplev.c emits __gnu_lto markers to assembler:
>
> /* Emit LTO marker if LTO info has been previously emitted. This is
> used by collect2 to determine whether an object file contains IL.
> We used to emit an undefined reference
toplev.c emits __gnu_lto markers to assembler:
/* Emit LTO marker if LTO info has been previously emitted. This is
used by collect2 to determine whether an object file contains IL.
We used to emit an undefined reference here, but this produces
link errors if an object file with I
On Wed, Feb 22, 2012 at 2:15 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Richard Guenther
>> Sent: Tuesday, February 21, 2012 6:19 PM
>> To: Jiangning Liu
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: A problem a
13 matches
Mail list logo
