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 m.ostape...@partner.samsung.com
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack
protection.
On Tue, Dec 17, 2013 at 1:37 PM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com
PR
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
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu hongjiu...@intel.com 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
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu hongjiu...@intel.com 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
On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu hongjiu...@intel.com 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
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 architecture
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 Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu hongjiu...@intel.com wrote:
cpu_names in i386.c is only used by ix86_function_specific_print which
accesses it
On Tue, Dec 24, 2013 at 6:38 AM, Allan Sandfeld Jensen
carew...@gmail.com 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
On Tue, Dec 24, 2013 at 6:50 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24, 2013 at 2:08 PM, H.J. Lu hongjiu...@intel.com wrote:
cpu_names in
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 good
On Tue, Dec 24, 2013 at 6:55 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 24, 2013 at 6:50 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24, 2013 at 3:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 24, 2013 at 6:12 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 24,
On Thu, Oct 24, 2013 at 7:33 AM, Richard Biener rguent...@suse.de 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
On Fri, Dec 6, 2013 at 9:38 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Dec 6, 2013 at 2:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Dec 6, 2013 at 10:38 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu,
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
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 hongjiu...@intel.com
PR target/59588
*
17 matches
Mail list logo
