Kyrill Tkachov writes:
> Hi Bin,
>
> On 16/03/18 11:42, Bin Cheng wrote:
>> Hi,
>> This simple patch fixes test case failure for pr84682-2.c by returning
>> false on wrong mode rtx in aarch64_classify_address, rather than assert.
>>
>> Bootstrap and test on aarch64. Is it OK?
>>
>> Thanks,
>> bi
On Fri, Mar 16, 2018 at 9:23 PM, Jakub Jelinek wrote:
> Hi!
>
> We now have more than 32 enumerators in enum processor_type (well, we had
> 33 already before the icelake-* split, but the last one isn't really used),
> and while all the m_* macros were changed tom 1U< HOST_WIDE_INT_1U< vars weren't
The testcase ICEd for both SVE and AVX512 because we were trying
to vectorise a chain of COND_EXPRs as a reduction and getting
confused by reduc_index == -1.
We normally handle reduction chains by vectorising all statements
except the last one normally, but that wouldn't work here for the
reasons
This PR is another regression caused by the removal of the simple_iv
check in dr_analyze_innermost for BB analysis. Without splitting out
the step, we weren't able to find an underlying object whose alignment
could be increased.
As with PR81635, I think the simple_iv was only handling one special
We shouldn't substitute templates into short-circuited-out concepts
constraints, but we do, and to add insult to injury, we issue a
sorry() error when a concept that shouldn't even have been substituted
attempts to perform a multi-dimensional array initialization with a
new{} expression.
Although
As we go through each of the template parameters, substituting it with
corresponding template arguments, an incorrect argument list might
cause us to index argument vectors past their length (or fail in the
preceding tree checks). Avoid such dereferences and instead issue an
error (if requested) i
On Mar 17, 2018, Alexandre Oliva wrote:
> We shouldn't substitute templates into short-circuited-out concepts
> constraints, but we do, and to add insult to injury, we issue a
> sorry() error when a concept that shouldn't even have been substituted
> attempts to perform a multi-dimensional array
On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu wrote:
> On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen wrote:
>> "H.J. Lu" writes:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
>>> @@ -0,0 +1,11 @@
>>> +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
>>> +/* { dg
On March 17, 2018 11:21:18 AM GMT+01:00, Richard Sandiford
wrote:
>The testcase ICEd for both SVE and AVX512 because we were trying
>to vectorise a chain of COND_EXPRs as a reduction and getting
>confused by reduc_index == -1.
>
>We normally handle reduction chains by vectorising all statements
>
On Fri, Dec 8, 2017 at 5:02 AM, H.J. Lu wrote:
> On Tue, Oct 24, 2017 at 5:31 AM, H.J. Lu wrote:
>> PLT should be avoided with shadow stack in 32-bit mode if more than 2
>> parameters are passed in registers since only 2 parameters can be passed
>> in registers for external function calls via PLT
On 14 March 2018 at 23:01, Jonathan Wakely wrote:
> Here's a very different patch. This gets rid of the __ptr_rel_ops and
> just puts the special handling for pointers directly in the
> std::less<_Tp*> etc. specializations. Then std::less uses
> std::less for some pointer type P*. I've also added a
11 matches
Mail list logo
