On Thu, 2014-01-09 at 10:36 +0100, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
> > Yeah, if i386 is changed into SWITCHABLE_TARGET, then I'd strongly encourage
> > rs6000 and nios folks to follow the suit.
>
> Ok for me. Hope they read this thread...
The rs600 patch
On Thu, Jan 09, 2014 at 12:11:12PM +0100, Richard Biener wrote:
> On Thu, Jan 9, 2014 at 11:24 AM, Jakub Jelinek wrote:
> > On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
> >> It looks like a correct fix, but the memcpy is going to be pretty
> >> expensive, since in most cases
On Thu, Jan 9, 2014 at 11:24 AM, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
>> It looks like a correct fix, but the memcpy is going to be pretty
>> expensive, since in most cases there will be no difference.
>
> Perhaps we should add another tree code
On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
> It looks like a correct fix, but the memcpy is going to be pretty
> expensive, since in most cases there will be no difference.
Perhaps we should add another tree code, which would represent the
combination of TARGET_OPTION_NODE
On Thu, Jan 09, 2014 at 10:36:43AM +0100, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
> >
> > On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
> >>> I think Jakub's patch will fix this case, but I did not try.
> >>> However even if the i368 is now cle
On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
>
> On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
>>> I think Jakub's patch will fix this case, but I did not try.
>>> However even if the i368 is now clean, there are
>>> still many targets that use target_reinit() in
>>> targe
On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
> > I think Jakub's patch will fix this case, but I did not try.
> > However even if the i368 is now clean, there are
> > still many targets that use target_reinit() in
> > target_set_current_function.
>
> FWIW I only see three oth
Bernd Edlinger writes:
> I found another test case that still fails with today's trunk:
>
> #include
>
> __m256 a[10], b[10], c[10];
>
> void __attribute__((target ("sse2"), optimize (3)))
> foo (void)
> {
> }
>
> void __attribute__((target ("avx"), optimize (3)))
> bar (void)
> {
> a[0] = _mm2
Hi,
On Tue, 7 Jan 2014 15:10:20, Richard Biener wrote:
>
> On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
> wrote:
>> Bernd Edlinger writes:
How about this patch for the big comment?
>>>
>>> The comment should say that target_set_current_function()
>>> cannot call target_reinit() be
On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
wrote:
> Bernd Edlinger writes:
>>> How about this patch for the big comment?
>>>
>>
>> The comment should say that target_set_current_function()
>> cannot call target_reinit() because:
>>
>> target_reinit()=>lang_dependent_init_target()
>> =>init
Bernd Edlinger writes:
>> How about this patch for the big comment?
>>
>
> The comment should say that target_set_current_function()
> cannot call target_reinit() because:
>
> target_reinit()=>lang_dependent_init_target()
> =>init_optabs()=>init_all_optabs(this_fn_optabs);
>
> uses this_fn_optabs
On Mon, 6 Jan 2014 19:16:57, Richard Saniford wrote:
>
> Bernd Edlinger writes:
>>>
>>> Jakub Jelinek wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
> Of course, IMO, the cleanest fix would be to use switchable targets
> for i386...
We IMHO want tha
Bernd Edlinger writes:
>>
>> Jakub Jelinek wrote:
>>>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
>>>
>>>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
>>>to
>>
>
> Jakub Jelinek wrote:
>>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>>> Of course, IMO, the cleanest fix would be to use switchable targets
>>> for i386...
>>
>>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
>>to
>>compile because even with just a
Jakub Jelinek wrote:
>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>> Of course, IMO, the cleanest fix would be to use switchable targets
>> for i386...
>
>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
>to
>compile because even with just a few routin
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
> Of course, IMO, the cleanest fix would be to use switchable targets
> for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons to
compile because even with just a few routines in a CU there are hundreds
Bernd Edlinger writes:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
> This happens because invoke_se
On Sun, Nov 3, 2013 at 11:25 AM, Bernd Edlinger
wrote:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
On Tue, 19 Nov 2013 06:21:22, H.J. Lu wrote:
>
> On Sun, Nov 3, 2013 at 2:25 AM, Bernd Edlinger
> wrote:
>> Hello,
>>
>> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
>> because of
>> an internal compiler error, see PR58155.
>>
>> The reason for this is that the optab CO
On Sun, Nov 3, 2013 at 2:25 AM, Bernd Edlinger
wrote:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
20 matches
Mail list logo
