Hi Honza,
We have combined generic32 and generic64 into generic. There is no need
to check "generic" anymore. Also we shouldn't change -mtune=i686 into
-mtune=generic. OK to install?
Thanks.
H.J.
---
gcc/
2013-12-24 H.J. Lu
PR target/59588
* config/i386/i386.c (ix86_opti
On Fri, Dec 20, 2013 at 7:30 PM, Jeff Law wrote:
>
> So here's an alternate approach to fixing 59285. I still think attacking
> this in rtl_merge_blocks is better, but with nobody else chiming in to break
> the deadlock Steven and myself are in, I'll go with Steven's preferred
> solution (fix the
On Fri, Dec 6, 2013 at 9:38 AM, H.J. Lu wrote:
> On Fri, Dec 6, 2013 at 2:44 AM, Uros Bizjak wrote:
>> On Fri, Dec 6, 2013 at 10:38 AM, Richard Biener
>> wrote:
>>> On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
wrote:
> Hi,
>
On Thu, Oct 24, 2013 at 7:33 AM, Richard Biener wrote:
>
> This finally computes a valid partition ordering (or if not possible
> merge partitions again) in loop distribution. This is the only
> place where data dependences are relevant, so we delay computing them
> (and also do not compute all N
On Tue, Dec 24, 2013 at 6:55 AM, H.J. Lu wrote:
> On Tue, Dec 24, 2013 at 6:50 AM, Uros Bizjak wrote:
>> On Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu wrote:
>>> On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak wrote:
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
> cpu_names in i386.c i
On Tuesday 24 December 2013, H.J. Lu wrote:
>
> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
> Should we use a single definition for both i386.c and libgcc?
Currently they need to be in the same patch. But yes, moving the definition
out to a common header would probably be a goo
On Tue, Dec 24, 2013 at 6:50 AM, Uros Bizjak wrote:
> On Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu wrote:
>> On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak wrote:
>>> On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
>>>
cpu_names in i386.c is only used by ix86_function_specific_print which
a
On Tue, Dec 24, 2013 at 6:38 AM, Allan Sandfeld Jensen
wrote:
> On Monday 23 December 2013, H.J. Lu wrote:
>>
>> If you use
>>
>> {"corei7-avx", M_INTEL_COREI7_SANYBRIDGE},
>> {"core-avx2", M_INTEL_COREI7_HASWELL},
>> will it cause any problems? When there are both
>>
> Actually I seems I don't n
On Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu wrote:
> On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak wrote:
>> On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
>>
>>> cpu_names in i386.c is only used by ix86_function_specific_print which
>>> accesses it with enum processor_type index. But cpu_names is
Hi,
I just updated my patch according your suggestion.
Thank you for committing it for me!
All you guys have a nice Xmas break!
Kind regards,
Renlin Li
On 04/12/13 11:23, Ramana Radhakrishnan wrote:
Sorry about the slow response. Been on holiday.
On 20/11/13 16:27, Renlin Li wrote:
Hi all,
On Monday 23 December 2013, H.J. Lu wrote:
>
> If you use
>
> {"corei7-avx", M_INTEL_COREI7_SANYBRIDGE},
> {"core-avx2", M_INTEL_COREI7_HASWELL},
>
> will it cause any problems? When there are both
>
Actually I seems I don't need these definitions any more after your clean-up
of Intel archite
On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak wrote:
> On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
>
>> cpu_names in i386.c is only used by ix86_function_specific_print which
>> accesses it with enum processor_type index. But cpu_names is defined as
>> array with enum target_cpu_default index.
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
> cpu_names in i386.c is only used by ix86_function_specific_print which
> accesses it with enum processor_type index. But cpu_names is defined as
> array with enum target_cpu_default index. This patch adds processor
> names to processor_target_tab
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu wrote:
> cpu_names in i386.c is only used by ix86_function_specific_print which
> accesses it with enum processor_type index. But cpu_names is defined as
> array with enum target_cpu_default index. This patch adds processor
> names to processor_target_tab
Hi,
cpu_names in i386.c is only used by ix86_function_specific_print which
accesses it with enum processor_type index. But cpu_names is defined as
array with enum target_cpu_default index. This patch adds processor
names to processor_target_table and uses processor_target_table instead
of cpu_nam
On Tue, Dec 17, 2013 at 1:37 PM, Jakub Jelinek wrote:
> Hi!
>
> I forgot to update_stmt stmts I've changed.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> committed to trunk as obvious.
>
> 2013-12-17 Jakub Jelinek
>
> PR tree-optimization/59523
> * t
On 12/19/2013 04:27 PM, Jakub Jelinek wrote:
On Thu, Dec 19, 2013 at 04:02:47PM +0400, Maxim Ostapenko wrote:
Sorry, ChangeLog and patch, of course.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack
protection.
Too long lines in ChangeLog, w
17 matches
Mail list logo
