Hi,
On 5 September 2017 at 13:40, Uros Bizjak wrote:
> On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote:
>> On Mon, 4 Sep 2017, Uros Bizjak wrote:
>>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>>>
>>> New failures:
>>> FAIL: gcc.target/i386/pr71245-1.c scan-asse
On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote:
> On Mon, 4 Sep 2017, Uros Bizjak wrote:
>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>>
>> New failures:
>> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild)
>> FAIL: gcc.target/i386/pr71245-2.c sc
On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote:
> On Mon, 4 Sep 2017, Uros Bizjak wrote:
>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>>
>> New failures:
>> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild)
>> FAIL: gcc.target/i386/pr71245-2.c sc
On Mon, 4 Sep 2017, Uros Bizjak wrote:
> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>
> New failures:
> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild)
> FAIL: gcc.target/i386/pr71245-2.c scan-assembler-not movlps
Sorry. I suggest that the tests be XFAI
> On 09/01/2017 12:26 AM, Alexander Monakov wrote:
>> On Thu, 31 Aug 2017, Jeff Law wrote:
>>> This is OK.
>>>
>>> What's the point of the delete_insns_since calls in patch #3?
>>
>> Deleting the first barrier when maybe_expand_insn failed.
>> Other functions in the file use a similar approach.
> T
On 09/01/2017 12:26 AM, Alexander Monakov wrote:
> On Thu, 31 Aug 2017, Jeff Law wrote:
>> This is OK.
>>
>> What's the point of the delete_insns_since calls in patch #3?
>
> Deleting the first barrier when maybe_expand_insn failed.
> Other functions in the file use a similar approach.
Thanks for
On Thu, 31 Aug 2017, Jeff Law wrote:
> This is OK.
>
> What's the point of the delete_insns_since calls in patch #3?
Deleting the first barrier when maybe_expand_insn failed.
Other functions in the file use a similar approach.
Thanks.
Alexander
On 08/28/2017 06:05 AM, Alexander Monakov wrote:
> Ping (for this and patch 3/3 in the thread).
>
> On Wed, 2 Aug 2017, Alexander Monakov wrote:
>
>> Similar to mem_thread_fence issue from the patch 1/3, RTL representation of
>> __atomic_signal_fence must be a compiler barrier. We have just one
Ping (for this and patch 3/3 in the thread).
On Wed, 2 Aug 2017, Alexander Monakov wrote:
> Similar to mem_thread_fence issue from the patch 1/3, RTL representation of
> __atomic_signal_fence must be a compiler barrier. We have just one backend
> offering this pattern, and it does not place a co
