This patch adds an intermediate gcov text format which does not require
source code. This format can be used by lcov or other tools.
I have bootstrapped it on x86 and all tests pass. Okay for main?
Thanks,
Sharad
2011-06-13 Sharad Singhai sing...@google.com
Google Ref 3
The patch will be committed to google/main to fix a problem in LIPO model
that leads to 'reference to discarded comdat section' ld warning. The problem
is caused by inconsistent comdat groups between primary and aux modules because
thunks were skipped in aux module.
2011-06-14 David Li
On Tue, Jun 14, 2011 at 06:51, jerry DeLisle jvdeli...@charter.net wrote:
It should be easy to implement:
After the switch between F and E editing, we just need to shift the
decimal point and decrement the exponent. No new rounding is required,
because we keep the number of significant
Revital Eres revital.e...@linaro.org wrote on 13/06/2011 10:29:06 AM:
From: Revital Eres revital.e...@linaro.org
To: Ayal Zaks/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Patch Tracking patc...@linaro.org
Date: 13/06/2011 10:29 AM
Subject: [PATCH, SMS] Fix violation of memory dependence
On Mon, 13 Jun 2011, Jason Merrill wrote:
On 06/13/2011 06:51 AM, Richard Guenther wrote:
But I suppose you want the array-ref be folded to a constant eventually?
Right.
I'm not going to keep arguing about VIEW_CONVERT_EXPR, but that brings me back
to my original question: is it OK to
On Mon, 13 Jun 2011, Jakub Jelinek wrote:
Hi!
As the testcase shows, the
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02945.html
patch looks wrong, MEM_ATTRS matters quite a lot for the
alias oracle, so ignoring it leads to miscompilations.
Instead of just reverting the patch, this
On 06/14/2011 10:43 AM, Richard Guenther wrote:
The patch that reverted the MEM_ATTR comparison didn't come
with a single testcase (ugh, I realize I approved it though ;)).
Bernd, do you have any testcases?
It was a missed-optimization problem, but I think it only showed up with
a modified
On Tue, Jun 14, 2011 at 11:10:13AM +0200, Eric Botcazou wrote:
This limits this testcase to i?86/x86_64 (moving to gcc.target/ would
be harder because it relies on all the weirdo vectorization options to be
passed), because apparently on strict alignment targets we don't handle
aligned (1)
Except or the fortran/java bits (committed), this patch hasn't been
reviewed for five weeks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
On Tue, 14 Jun 2011, Bernd Schmidt wrote:
On 06/14/2011 10:43 AM, Richard Guenther wrote:
The patch that reverted the MEM_ATTR comparison didn't come
with a single testcase (ugh, I realize I approved it though ;)).
Bernd, do you have any testcases?
It was a missed-optimization
On Mon, Jun 13, 2011 at 2:45 PM, Georg-Johann Lay a...@gjlay.de wrote:
Ping #1 for:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00746.html
Ok.
THanks,
Richard.
Georg-Johann Lay:
This patch fixes testsuite failures because the testcases assume
sizeof(int) = 4.
*
On Mon, Jun 13, 2011 at 2:54 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
by accident I noticed that BINFO_VIRTUALs streaming is really expensive. It
about doubles amount of IL and types streamed by Mozilla.
One obvious optimization is to not stream into ltrans unit where it is
too late to do
On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke amyl...@spamcop.net wrote:
Except or the fortran/java bits (committed), this patch hasn't been
reviewed for five weeks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
A patch doing s/CUMULATIVE_ARGS*/cumulative_args_t/ only
is ok.
On 14 June 2011 13:02, Richard Guenther richard.guent...@gmail.com wrote:
On Mon, Jun 13, 2011 at 2:43 PM, Ira Rosen ira.ro...@linaro.org wrote:
On 10 June 2011 12:14, Richard Guenther richard.guent...@gmail.com wrote:
In the end I think we should not generate the pattern stmt during
pattern
Ping^4 for the C6X port.
Additional preliminary scheduler tweaks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html
Allow alternatives in attr predicable:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00094.html
regrename across basic block boundaries:
Quoting Richard Guenther richard.guent...@gmail.com:
On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke amyl...@spamcop.net wrote:
Except or the fortran/java bits (committed), this patch hasn't been
reviewed for five weeks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
A patch doing
On 14 June 2011 14:27, Richard Guenther richard.guent...@gmail.com wrote:
/* Mark the stmts that are involved in the pattern. */
- gsi_insert_before (si, pattern_stmt, GSI_SAME_STMT);
set_vinfo_for_stmt (pattern_stmt,
new_stmt_vec_info (pattern_stmt, loop_vinfo,
On Tue, Jun 14, 2011 at 1:38 PM, Ira Rosen ira.ro...@linaro.org wrote:
On 14 June 2011 14:27, Richard Guenther richard.guent...@gmail.com wrote:
/* Mark the stmts that are involved in the pattern. */
- gsi_insert_before (si, pattern_stmt, GSI_SAME_STMT);
set_vinfo_for_stmt
On 06/14/2011 01:29 PM, Richard Guenther wrote:
On Tue, Jun 14, 2011 at 1:16 PM, Joern Rennecke amyl...@spamcop.net wrote:
Quoting Richard Guenther richard.guent...@gmail.com:
On Tue, Jun 14, 2011 at 11:40 AM, Joern Rennecke amyl...@spamcop.net
wrote:
Except or the fortran/java bits
Index: ipa-cp.c
===
--- ipa-cp.c(revision 174905)
+++ ipa-cp.c(working copy)
@@ -818,7 +828,7 @@ ipcp_iterate_stage (void)
/* Some lattices have changed from IPA_TOP to IPA_BOTTOM.
This
On Tue, Jun 14, 2011 at 3:16 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Jun 14, 2011 at 12:13:47PM +0200, Richard Guenther wrote:
On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng changpeng.f...@amd.com
wrote:
The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which
This patch for AMD64 targets running GNU/kFreeBSD has been approved
already, would anyone be so kind to commit it? I'm afraid I don't have
write perms currently.
See: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00884.html
Thank you very much :-)
2011/6/10 Richard Henderson r...@redhat.com:
On 06/14/2011 02:53 PM, Joern Rennecke wrote:
Quoting Bernd Schmidt ber...@codesourcery.com:
I'm not getting the point of the use of attribute((transparent_union)).
Without that attribute, lots of ABIs add a lot of overhead for function
argument and return value passing.
* These functions
On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
snip
Loss of aliasing information
The new g++.dg/torture/pr48954.C testcase FAILs on alpha-dec-osf5.1b:
FAIL: g++.dg/torture/pr48954.C -O0 (test for excess errors)
Excess errors:
cc1plus: error: LTO support has not been enabled in this configuration
The following test fixes this, tested with the appropriate runtest
invocation,
On Fri, Jun 10, 2011 at 8:44 PM, Xinliang David Li davi...@google.com wrote:
This is the revised patch as suggested.
How does it look?
}
+static void
+execute_function_dump (void *data ATTRIBUTE_UNUSED)
function needs a comment.
Ok with that change.
Please always specify how you tested
On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote:
On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
When I first did a Solaris 11/x86 bootstrap with gld after checking in
my ENABLE_EXECUTE_STACK patch, I found that several acats and gnat.dg
tests were failing. This hadn't happened with Sun ld.
Reghunting revealed that this had been introduced by that patch.
Fortunately, not the code itself was
I think we also suggested at some point that -O1 optimizations
shouldn't interfere with debugging too much. But if it is what we did before
it's certainly fine.
FWIW we have some evidences that -finline-functions-called-once really help
at -O1 in terms of performances (with the 4.5 back-end)
On Tue, Jun 14, 2011 at 4:18 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote:
On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Tue, 2011-06-07 at 16:49 +0200, Richard Guenther wrote:
On Tue, Jun 14, 2011 at 11:49:08AM +0200, Richard Guenther wrote:
So I'd say we revert your patch for now and if somebody feels like
implementing the above ...
Ok, here is what I've bootstrapped/regtested on x86_64-linux and i686-linux
and committed to trunk and 4.6 branch:
2011-06-14 Jakub
The following patch has remained unreviewed for a week:
[libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00644.html
It needs a libffi maintainer or global reviewer.
Thanks.
Rainer
--
Hello!
This patch for AMD64 targets running GNU/kFreeBSD has been approved
already, would anyone be so kind to commit it? I'm afraid I don't have
write perms currently.
I have committed your patch to SVN mainline after bootstrapping it on
x86_64-pc-linux-gnu.
Thanks,
Uros.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This version incorporates suggestions from Bernd. Basically we have
reload1.c set reload_completed internally rather than deferring it into
ira.c. That allows the call to reload() to return whether or not a DCE
pass is desirable at the end of
On 14.06.11 17:22, Rainer Orth wrote:
The following patch has remained unreviewed for a week:
[libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00644.html
It needs a libffi maintainer or global reviewer.
From the test suite
Hi!
As detailed in the PR, when gdb attempts to print originally passed
values to parameters instead of current values using call site info,
if the parameter is modified already before the first real instruction
in the function, it will find there already the modified value.
E.g. void foo (int x)
On Jun 14, 2011, at 2:20 AM, Georg-Johann Lay wrote:
testsuite/
* gcc.c-torture/execute/cmpsi-2.c: Undo 172757.
Please always include the PR number in the changelog entries when there is one.
This autolinks the work to the PR. Use the exact formatting found in the
changelog file.
On Tue, Jun 14, 2011 at 04:52:18PM +0200, Eric Botcazou wrote:
Well, Steve has a patch for non_strict_align effective_target
in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00673.html
(with s/strict_align/non_strict_align/g ), I was hoping it would be
reviewed and I'd just adjust the
Hi,
RTL-based forward propagation pass shouldn't propagate hard register.
OK for trunk?
Thanks.
H.J.
---
2011-06-14 H.J. Lu hongjiu...@intel.com
PR middle-end/47449
* fwprop.c (forward_propagate_subreg): Don't propagate hard
register nor zero/sign extended hard
Andrew Haley a...@redhat.com writes:
On 06/14/2011 04:22 PM, Rainer Orth wrote:
The following patch has remained unreviewed for a week:
I think it wasn't cc'd to libffi-disc...@sourceware.org
Right, I hadn't known/had forgotten about that since all my libffi fixes
happen in GCC context. I'd
Hi,
long may be 32bit for x86-64. But long long is always 64bit. This
patch uses long long builtin for 64bit. OK for trunk?
Thanks.
H.J.
---
2011-06-14 H.J. Lu hongjiu...@intel.com
* longlong.h (count_leading_zeros): Use long long builtin for
x86-64.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As I've noted in prior messages; I'm looking to improve our path
isolation to improve code generation and reduce false positives from
warnings.
The patch that's been in my queue for some time now (and I suspect it's
the final patch to our current
On Tue, 2011-06-14 at 17:21 +0200, Richard Guenther wrote:
On Tue, Jun 14, 2011 at 4:18 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
On Tue, 2011-06-14 at 15:39 +0200, Richard Guenther wrote:
On Fri, Jun 10, 2011 at 5:11 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com
Backported r174930 to google/main.
David
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/11 09:51, Jakub Jelinek wrote:
Hi!
As detailed in the PR, when gdb attempts to print originally passed
values to parameters instead of current values using call site info,
if the parameter is modified already before the first real
On Tue, Jun 14, 2011 at 8:11 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, Jun 12, 2011 at 6:28 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jun 12, 2011 at 7:33 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jun 12, 2011 at 7:00 AM, H.J. Lu hjl.to...@gmail.com wrote:
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/11 13:18, Easwaran Raman wrote:
I am not sure I understand the problem here. If there is a wild read
from asm, the instruction has the wild_read flag set. The if statement
checks if that flag is set and if so it clears the bitmap - which
On Wed, May 25, 2011 at 12:21 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Here is a revised version of my patch
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01779.html to create
the common hooks structure. Tested in the same way as the original
patch. OK to commit?
2011-05-25
On Fri, May 27, 2011 at 9:13 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
2011-05-27 Joseph Myers jos...@codesourcery.com
* target-def.h (TARGET_HAVE_NAMED_SECTIONS): Move to
common/common-target-def.h.
* target.def (default_target_flags, handle_option,
In this testcase, we were hitting an assert that I put in to make sure
that fold_indirect_ref_1 was doing its job and folding everything that
ought to be folded. But fold_indirect_ref_1 doesn't want to mess with
type identity, so it can't fold if, say, the array element type has
different
We were forgetting to propagate cv-quals from 'this' to the result along
one code path. Fixed by moving the cv-qual propagation up so it's
shared by all code paths.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.6.
commit a7eeb9dc7b67d159f46e9d8e7976332bd73332ca
Author: Jason Merrill
On Tue, Jun 14, 2011 at 6:04 PM, H.J. Lu hongjiu...@intel.com wrote:
long may be 32bit for x86-64. But long long is always 64bit. This
patch uses long long builtin for 64bit. OK for trunk?
Thanks.
H.J.
---
2011-06-14 H.J. Lu hongjiu...@intel.com
* longlong.h
PR 49117 complains that the error message given on conversion failure
regressed from 4.5 to 4.6 in that it no longer prints the source type.
So I've added it back in.
While I was at it, I've also tweaked the compiler to also print the
typedef-stripped version of a type when appropriate, which
Many tests in gcc.target/arm that specify -march= fail compilation
when multilib flags include -mcpu= due to warnings about conflicts in
switches, but then go on to pass the remainder of the test. This patch
causes some of those tests to ignore that compiler warning; I'll get to
the rest later.
On Sun, Jun 05, 2011 at 12:54:41PM -0700, H.J. Lu wrote:
Hi,
I'd like to start submitting a series of patches to enable x32:
https://sites.google.com/site/x32abi/
The GCC x32 branch is very stable. There are no unexpected failures in
C, C++, Fortran and Objective C testsuites. SPEC CPU
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
2011-06-14 Paolo Carlini paolo.carl...@oracle.com
* include/std/valarray (~valarray): Use noexcept.
* include/bits/unique_ptr.h (~unique_ptr): Likewise.
*
On Tue, Jun 14, 2011 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Jun 14, 2011 at 6:04 PM, H.J. Lu hongjiu...@intel.com wrote:
long may be 32bit for x86-64. But long long is always 64bit. This
patch uses long long builtin for 64bit. OK for trunk?
Thanks.
H.J.
---
Fix three ARM tests so they are skipped for multilibs that don't support
THUMB. OK for trunk and 4.6?
Janis
2011-06-14 Janis Johnson jani...@codesourcery.com
* gcc.target/arm/pr45701-1.c: Require thumb support.
* gcc.target/arm/pr45701-2.c: Likewise.
*
We weren't reading in shadowed labels properly.
The local variable *sl also turned out to be useless, the compiler just didn't
mention it until now as it was used by the bad VEC_iterate call.
This doesn't fix any currently exposed pph bugs, but does help with me with
the patch I'm currently
If the object expression is an rvalue, the result should be as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 93619457bb3756b091d86a13d1aa72880bb1ac62
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 13 22:19:24 2011 -0400
PR c++/49389
* typeck2.c
In C++0x mode, without this patch, calls to a user-defined trunc() function
with an argument in namespace std and a parameter type that has an implicit
conversion from the argument's type, cause infinite recursion in std::trunc().
This patch also includes
On Jun 14, 2011, at 10:47 AM, Janis Johnson wrote:
Many tests in gcc.target/arm that specify -march= fail compilation
when multilib flags include -mcpu= due to warnings about conflicts in
switches, but then go on to pass the remainder of the test.
OK for trunk and 4.6?
Ok. As usual, please
On Tue, Jun 14, 2011 at 14:45, Jeffrey Yasskin jyass...@google.com wrote:
In C++0x mode, without this patch, calls to a user-defined trunc() function
with an argument in namespace std and
a parameter type that has an implicit conversion from the argument's type,
cause infinite recursion in
Committed after Bootstrapping and regression testing on x86-64/linux.
The follow up patch will come soon.
Thanks,
David
On Tue, Jun 14, 2011 at 8:57 AM, Xinliang David Li davi...@google.com wrote:
On Tue, Jun 14, 2011 at 6:58 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun
On Tue, Jun 14, 2011 at 12:38 PM, Diego Novillo dnovi...@google.com wrote:
On Tue, Jun 14, 2011 at 14:45, Jeffrey Yasskin jyass...@google.com wrote:
In C++0x mode, without this patch, calls to a user-defined trunc() function
with an argument in namespace std and
a parameter type that has an
On Tue, Jun 14, 2011 at 15:59, Jeffrey Yasskin jyass...@google.com wrote:
It's already in trunk, so my impression was that it was going to be
automatically merged to google/main. I only need a manual merge to get
it into our release branches.
Yeah, in this case it's not too different since
On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote:
That's not exactly an example - I can't think of how you want or need
to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
you would need anything special for the _argument_ of said instruction.
Oh, I completely
On 06/14/2011 07:34 AM, Alexander Monakov wrote:
Hello,
Quoting myself from the PR audit trail,
It's a rare bug in sel-sched: we fail to schedule some code in non-pipelining
mode. The root cause is that we put bookkeeping instructions above a fence
that is placed on the last insn (uncond.
I made other changes to these tests earlier today, then the patch to
ignore warnings for conflicting options was approved. I've committed
this to trunk.
Janis
2011-06-14 Janis Johnson jani...@codesourcery.com
* gcc.target/arm/pr45701-1.c: Ignore warnings about conflicting
switches.
These tests apparently require thumb2 support (I don't yet know much
about ARM). OK for trunk, and later 4.6?
Janis
2011-06-14 Janis Johnson jani...@codesourcery.com
* gcc.target/arm/pr42879.c: Skip if no thumb2 support, ignore
compiler warning about switch conflicts.
Hi,
the patch below fixes PR 48613 which is an ICE with -O0
-findirect-inlining. Rather than adding optimize here and there,
at this place we can easily see whether there is something to do or
not by testing ipa_node_params_vector for NULL. And the
flag-triggering combinations can -and are -
Sorry, Rietveld didn't send out the updated patch along with my mail.
Here it is.
Sharad
2011-06-14 Sharad Singhai sing...@google.com
Google Ref 3
* doc/gcov.texi: Document gcov intermediate format.
* gcov.c (get_gcov_file_intermediate_name): New function.
On 06/06/2011 07:26 AM, Bernd Schmidt wrote:
Ping^3 for the C6X port. Now with extra patches:
Additional preliminary scheduler tweaks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html
It is ok for me. Thanks, Bernd.
Allow alternatives in attr predicable:
Denis Chertykov schrieb:
2011/6/14 Georg-Johann Lay a...@gjlay.de:
Denis Chertykov schrieb:
2011/6/13 Georg-Johann Lay a...@gjlay.de:
So you think is is pointless/discouraged to give a more realistic
description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead
of
Hello,
HFS+, the FS on Darwin, is case insensitive. So this patch adjusts
filename_cmp.c to ignore the casing when comparing filenames on Darwin.
This is visible in GDB when trying to break on a file whose name
is, say 'Mixed_Case.adb', but was compiled using 'mixed_case.adb'
as the filename.
Looks OK to me.
On Tue, Jun 14, 2011 at 2:33 PM, Joel Brobecker brobec...@adacore.com wrote:
Hello,
HFS+, the FS on Darwin, is case insensitive. So this patch adjusts
filename_cmp.c to ignore the casing when comparing filenames on Darwin.
This is wrong as not all FSs are case insensitive. In fact HFS+ can
On Wed, Jun 8, 2011 at 9:49 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
Target HAVE_INITFINI_ARRAY support was added by:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00387.html
Unfortunately, it checks if host supports init_array/fini_array
sections, not target. It will generate wrong
I missed the noexcept qualifier off this function when I added it recently.
2011-06-14 Jonathan Wakely jwakely@gmail.com
* include/bits/ptr_traits.h (pointer_traitsT*::pointer_to): Use
noexcept.
Tested x86_64-linux and committed to trunk
Index: include/bits/ptr_traits.h
Hi,
the patch below fixes PR 48613 which is an ICE with -O0
-findirect-inlining. Rather than adding optimize here and there,
at this place we can easily see whether there is something to do or
not by testing ipa_node_params_vector for NULL. And the
flag-triggering combinations can -and
On 06/14/2011 02:29 PM, Georg-Johann Lay wrote:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html
It does look like a step in the right direction.
I tested on some handcrafted examples and on the code attached to
PR46278. The generated code looked very good and so I started
regression
On Tue, Jun 14, 2011 at 3:41 PM, Fang, Changpeng changpeng.f...@amd.com wrote:
It probably should go to the 4.6 branch as well.
H.J. Lu's original patch that splits unaligned load and store was checked in
gcc 4.7
trunk. We found that, splitting unaligned store is beneficial to bdver1,
Attached the patch.
David
On Tue, Jun 14, 2011 at 4:21 PM, Xinliang David Li davi...@google.com wrote:
This is the second (hopefully the last in the series of dumper
changes) follow-up patch.
It adds a control so that verbosity of the dump can be greatly reduced
(and hopefully simplify gcc
On Tue, Jun 14, 2011 at 4:59 PM, Fang, Changpeng changpeng.f...@amd.com wrote:
So, is it OK to commit this patch to trunk, and H.J's original patch + this
to 4.6 branch?
I have no problems on -mtune=Bulldozer. But I object -mtune=generic
change and did suggest a different approach for
84 matches
Mail list logo
