On Fri, Aug 24, 2012 at 10:46 PM, Richard Sandiford
wrote:
> Andrew Pinski writes:
>> On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski wrote:
>>> On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
>>> wrote:
On 08/21/2012 02:23 PM, Richard Sandiford wrote:
>
>
> Would be nice to
Andrew Pinski writes:
> On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski wrote:
>> On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
>> wrote:
>>> On 08/21/2012 02:23 PM, Richard Sandiford wrote:
Would be nice to add a compile test for -mabi=64 just to make sure
that Pmode ==
Hello Everyone,
When I was GDBing cc1, the skip tree.h line was giving me error. When I
replaced it with "skip file tree.h" it seem to work fine. Here is a patch to
fix it.
Thanks,
Balaji V. Iyer.
Index: gcc/gdbinit.in
==
On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski wrote:
> On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
> wrote:
>> On 08/21/2012 02:23 PM, Richard Sandiford wrote:
>>>
>>>
>>> Would be nice to add a compile test for -mabi=64 just to make sure
>>> that Pmode == DImode works. A copy of an exis
On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
wrote:
> On 08/21/2012 02:23 PM, Richard Sandiford wrote:
>>
>>
>> Would be nice to add a compile test for -mabi=64 just to make sure
>> that Pmode == DImode works. A copy of an existing test like
>> code-readable-1.c would be fine.
>
>
> I'm havi
I noticed that the earlier work on access control SFINAE didn't handle
default template arguments; we weren't checking their access against the
right declarations at all. In order to do that, we need to generate the
DECL to compare against in fn_type_unification, when we still know what
access
OK.
Jason
Now that TREE_LANG_FLAG_0 doesn't work for TREE_VEC, we shouldn't try to
use it.
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
commit 3a2398e3485f19d74cd9ea74301ef9da62680be8
Author: Jason Merrill
Date: Fri Aug 24 16:37:51 2012 -0400
* print-tree.c (print_node): Don't check
Another change I have been working on was causing some error messages to
be associated with different lines. To maintain good locations, I've
changed a few places to make sure that some expressions have a location,
and use those locations more consistently during instantiation. Since
this mea
On Thu, 23 Aug 2012, Mingjie Xing wrote:
> A very small patch. OK?
>
> 2012-08-23 Mingjie Xing
>
> * doc/gty.texi: Fix typo.
By the way, changes of this kind, you can just commit and post
the patch; they do not require approval.
(When in doubt feel free to ask, of course.)
Gerald
On Fri, Aug 24, 2012 at 3:56 PM, wrote:
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
> File gcc/gcov-io.h (right):
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
> gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
> table
Hello,
This patch restores the old invariant that every GIMPLE switch has a
default case. This invariant is only broken by the SJLJ exception
dispatch code, and it's resulted in some code accepting a switch
without a default while others still assume there is _always_ a
default case. The patch enf
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
File gcc/gcov-io.h (right):
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
table index */
On 2012/08/24 22:30:30, davidxl wrote:
Is t
Forgot to attach the patch.
-- Andrew
On Fri, Aug 24, 2012 at 3:42 PM, Andrew Pinski wrote:
> Hi,
> I decided to split this patch from the other patch which uses
> emit_conditional_add in expand as that part of the patch needs some
> work. This part of the patch can be applied separately and
Hi,
I decided to split this patch from the other patch which uses
emit_conditional_add in expand as that part of the patch needs some
work. This part of the patch can be applied separately and it fixes a
few things dealing with conditional adds.
First the documentation is wrong for the pattern
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
File gcc/gcov-io.h (right):
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
table index */
Is this field necessary?
http://codereview.
On 2012/08/24 21:51:24, cmang wrote:
Fixed formatting issues.
The gcov.c is still not uploaded properly.
===
--- gcc/gcov.c (revision 190359)
+++ gcc/gcov.c (working copy)
@@ -222,6 +222,7 @@ typedef struct pmu_data
{
ll_
Hi,
a rather simple issue. In mainline we have machinery to detect broken
uses of auto variables before deduction, for which mark_used is designed
to error out and return false to the caller. However, in the specific
cases pointed out in this PR the error recovery is not Ok, because
mark_used
Fixed formatting issues.
The patch should be applied to google/main
Tested with crosstools.
2012-08-24 Chris Manghane
* libgcc/pmu-profile.c
(gcov_write_load_latency_infos): Removed unused function.
(gcov_write_branch_mispredict_infos): Ditto.
(destroy_load_l
On Aug 12, 2012, at 1:15 PM, Diego Novillo wrote:
> + Second, the GCC conding conventions prefer explicit conversion,
Spelling... coding
On Fri, 24 Aug 2012, Jakub Jelinek wrote:
> Hi!
>
> On this testcase, we ICE in optimize_compound_literals_in_ctor
> because init isn't CONSTRUCTOR, but the recursive call relies on it
> being a CONSTRUCTOR.
>
> Either we can add that check as the patch does, making the optimization
> tiny bit m
On Fri, 24 Aug 2012, Jakub Jelinek wrote:
> 2012-08-23 Jakub Jelinek
>
> PR c/54355
> * c-decl.c (c_parser_label): Pass true as nested and fix up comments
> for nested and empty_ok arguments in the call to
> c_parser_declaration_or_fndef.
>
> * gcc.dg/pr54355.c:
I don't see any code where a string table is declared nor created ...
David
On Fri, Aug 24, 2012 at 2:26 PM, Chris Manghane wrote:
> Also, what did you mean by there being missing string table management code?
>
>
> On Fri, Aug 24, 2012 at 2:23 PM, wrote:
>>
>>
>> Ok, I fixed most of the probl
Hi!
On this testcase, we ICE in optimize_compound_literals_in_ctor
because init isn't CONSTRUCTOR, but the recursive call relies on it
being a CONSTRUCTOR.
Either we can add that check as the patch does, making the optimization
tiny bit more robust (the rest of the gimplifier handles non-CONSTRUC
Hi!
When the c_parser_declaration_or_fndef call has been added for error
handling of invalid label followed by decl, the comments for the two
arguments were swapped, and I believe nested needs to be passed as true,
this is inside of another function. Testing revealed that empty_ok=true
is also de
Ok, I fixed most of the problem you found. I'm not sure what happened
with gcov.c, but I'll try uploading it again.
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c
File gcc/gcov-io.c (right):
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c#newcode280
gcc/gcov-io.c:28
On 08/23/2012 08:05 PM, Joey Ye wrote:
> Ssa-dom-thread-3.c has following code to trigger a warning on ARM. Add
> -fno-short-enums to suppress it.
> struct tree_base
> {
> enum tree_code code:16;
> };
>
> OK to trunk and 4.7?
OK.
Janis
> 2012-08-15 Joey Ye
>
> * gcc.dg/tree-ssa/ssa-dom
Hi Robert,
If you are going to defer, then:
On Fri, Aug 24, 2012 at 1:20 PM, rbmj wrote:
> diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
> index e73aed9..de7be35 100755
> --- a/fixincludes/fixinc.in
> +++ b/fixincludes/fixinc.in
> @@ -128,6 +128,18 @@ fi
>
> # # # # # # # # # # # #
Where is the string table management code? The gcov.c file is not
properly uploaded either.
David
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c
File gcc/gcov-io.c (right):
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c#newcode280
gcc/gcov-io.c:280: gcov_read_pmu
I have two candidate patches. I've tested both and either can supersede
the original 0001-fixincludes-machine_name patch.
The first is the original proposed sed expression:
---
fixincludes/mkfixinc.sh |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fixincludes/mkf
On Aug 24, 2012, at 5:35 AM, Jakub Jelinek wrote:
> You haven't built your compiler with --disable-bootstrap, so you aren't
> seeing what Mike is complaining about.
Actually, I'm not using disable Just a normal cross compile.
On 08/24/12 11:50, rbmj wrote:
On 8/22/2012 8:52 PM, Bruce Korb wrote:
However I think it might be simpler to tweak mkfixinc.sh to
sed '/if test -s .{MACRO_LIST}/s/$/ && false/' \
${srcdir}/fixinc.in > ${target}
for vxworks rather than all that configury rigmarole.
That would eliminate
Hi,
This patch was approved by Ian:
http://sourceware.org/ml/binutils/2012-08/msg00447.html
I have synced plugin-api.h with the following patch:
* plugin-api.h (ld_plugin_allow_unique_segment_for_sections):
New interface.
(ld_plugin_unique_segment_for_sections): New in
Dear Alessandro,
Alessandro Fanfarillo wrote:
there are some problems with the final-wrapper-v2.diff patch; I get
Internal Error at (1):
gfc_code2string(): Bad code
for every test case that I use; in attachment final2.f90.
Fixed by the patch below. However, note that the current patch only
im
While looking at another issue, I found the special case in get_bindings
for unifying the template with itself odd; the places where we have been
using it can just use coerce_template_parms instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 521c93c5aef7a96f9506ade3fb4759ac1cc7fdc0
A
Another patch I'm working on revealed a couple of latent issues in
specialization matching.
First, check_specialization_namespace takes the template as an argument,
not the specialization; fixing this improves the error location on spec25.C.
Second, allowing determine_specialization to match
On 8/22/2012 8:52 PM, Bruce Korb wrote:
However I think it might be simpler to tweak mkfixinc.sh to
sed '/if test -s .{MACRO_LIST}/s/$/ && false/' \
${srcdir}/fixinc.in > ${target}
for vxworks rather than all that configury rigmarole.
That would eliminate changes to gcc/configure.ac and
On 2012-08-23 23:08 , Diego Novillo wrote:
I've tested this patch on x86_64 and ppc64 with all languages plus
ada, go and obj-c++. I am going to be offline for several days
starting on Saturday, so I will not commit it until I return.
I've also done memory and time comparisons to make sure I
On Fri, Aug 24, 2012 at 6:33 PM, Thomas Quinot wrote:
> * common.opt (-fada-spec-parent): Define new command line switch.
Why here instead of in c-family/c.opt?
Ciao!
Steven
On Fri, Aug 24, 2012 at 11:08 AM, Diego Novillo wrote:
> On 2012-08-24 12:03 , Gabriel Dos Reis wrote:
>
>> I would just use C++ standard function `at()' (e.g. as found in vector)
>> for this.
>
>
> Sure. For regular functions, using default-valued arguments would be fine.
> But I think the mecha
The following proposed change adds a new command line switch
-fada-spec-parent allowing the user to specify a parent unit
for all units generated by -fdump-ada-spec.
* common.opt (-fada-spec-parent): Define new command line switch.
* c-family/c-ada-spec.c (get_ada_package): When -f
> "Dimitris" == Dimitrios Apostolou writes:
Dimitris> [...] since I broke things like the static assert in
Dimitris> libcpp/identifiers.c, that I don't even understand:
Dimitris> /* We don't need a proxy since the hash table's identifier comes
first
Dimitris> in cpp_hashnode. However,
On 2012-08-24 12:03 , Gabriel Dos Reis wrote:
I would just use C++ standard function `at()' (e.g. as found in vector)
for this.
Sure. For regular functions, using default-valued arguments would be
fine. But I think the mechanism would be much more transparent if the
compiler did the heavy
On Fri, Aug 24, 2012 at 10:50 AM, Marc Glisse wrote:
> On Thu, 23 Aug 2012, Diego Novillo wrote:
>
>> There is another issue that I need to address and I'm not quite
>> sure how to go about it: with the macro-based API, we make use of
>> pre-processor trickery to insert __FILE__, __LINE__ and
>> _
On Thu, 23 Aug 2012, Diego Novillo wrote:
There is another issue that I need to address and I'm not quite
sure how to go about it: with the macro-based API, we make use of
pre-processor trickery to insert __FILE__, __LINE__ and
__FUNCTION__ into the argument list of functions.
When I change VEC
Currently the new gcc.target/i386/asm-dialect-1.c testcase is failing on
darwin due the absence of support for -masm=intel on that target. The attached
patch skips this test on darwin. Tested on x86_64-apple-darwin12...
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02042.html
Okay for gcc t
> "Dodji" == Dodji Seketeli writes:
Dodji> With these changes, the libcpp parts look OK to me if they still
Dodji> boostrap post c++ conversion. I am not a maintainer so I a deferring to
Dodji> Tom and the other maintainers.
I agree. Dodji, thanks for looking at this.
Dmitris, thanks for w
> OK.
>
Checked in
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00626.html
Thanks, K
Patch number 3 handled scalar assignments like:
scalar_some_type = some_type(...)
Patch number 4 handled array assignments like:
array_some_type = (/some_type :: .../)
This takes care of assignments like:
array_some_type = some_type(...)
i.e. scalar to array assignments. As all the infrastructur
With array constructors, there is the same type problem as with structure
constructor: we don't know whether we want the non-restricted or the
restricted variant.
Array constructors are translated from somewhere deep inside the scalarizer,
so we have to pass the information there down to gfc_conv_e
This patch makes the LTO failures go away.
It propagates the information that we want (non-)restrict types from
gfc_trans_assignment_1 (where we have access to the LHS) down to
gfc_conv_structure (where the type specialization happens).
The call graph is roughly as follows (to be seen with a fixed
This patch comes from Richi. Self explanatory.
OK?
2012-08-22 Richard Guenther
PR fortran/45586
* trans-expr.c (gfc_nonrestricted_type): Make the non-restrict type
distinct from the original type.
diff --git a/trans-types.c b/trans-types.c
index a6e5d99..189f597 100644
This patch avoids fold_convert bombing when the types are not variants of the
same base type. It is necessary to avoid regressing with the next patch.
It tries to take the VIEW_CONVERT_EXPR path only when it is necessary and
use the usual fold_convert otherwise. I use gfc_nonrestricted_type in on
Hello,
here come several patches to fix the infamous PR 45586. The main issue is
the middle-end expecting variant types to share the fields, thus one field
cannot be restrict qualified in one type, and not restrict qualified in one
of its variants.
The fix, as per Richi's suggestion, makes the t
Jack Howarth writes:
> ===
> --- gcc/testsuite/gcc.target/i386/asm-dialect-1.c (revision 190647)
> +++ gcc/testsuite/gcc.target/i386/asm-dialect-1.c (working copy)
> @@ -1,4 +1,5 @@
> /* { dg-options "-masm=intel" } */
> +/*
Dear Tobias,
there are some problems with the final-wrapper-v2.diff patch; I get
the following error
final2.f90:71.15:
end module test
1
Internal Error at (1):
gfc_code2string(): Bad code
for every test case that I use; in attachment final2.f90.
Regards
Alessandro
2012/8/19 To
On Fri, 24 Aug 2012, Simon Baldwin wrote:
> gcc/ChangeLog
> 2012-08-24 Simon Baldwin
>
> * dwarf2out.c (gen_producer_string): Omit command line switch if
> CL_NO_DWARF_RECORD flag set.
> * opts.h (CL_NO_DWARF_RECORD): New.
> * opt-functions.awk (switch_flags): Add NoDWA
Currently the new gcc.target/i386/asm-dialect-1.c testcase is failing on
darwin due the absence of support for -masm=intel on that target. The attached
patch skips this test on darwin. Tested on x86_64-apple-darwin12...
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02042.html
Okay for gcc t
On 2012-08-17 11:32 , Sofiane Naci wrote:
Hi,
I've just committed the attached patch on the AArch64 branch to fix a style
issue related to mixing statements with declarations.
Thanks
Sofiane
-
r190486 | sofiane | 2012-08-17 16:26:47 +0100 (Fri, 17 Aug 2012) | 7 lines
2012-08-17 Marcus S
On Fri, Aug 24, 2012 at 7:13 AM, Rainer Orth
wrote:
> Jack Howarth writes:
>
>>Currently the new testcase for gcc.target/i386/pr53249.c is failing
>> on darwin due to the absence of -mx32 support on that target. The following
>> patch skips this testcase on darwin. Tested on x86_64-apple-darw
Jack Howarth writes:
>Currently the new testcase for gcc.target/i386/pr53249.c is failing
> on darwin due to the absence of -mx32 support on that target. The following
> patch skips this testcase on darwin. Tested on x86_64-apple-darwin12...
This also fails on Solaris/x86 (cf. PR testsuite/5
On 2012-08-22 20:56 , David Stone wrote:
I hope this can get looked at, thanks.
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01208.html
Please send your patches as unified or context diffs (see
http://gcc.gnu.org/contribute.html).
You say that you have sent your copyright paperwork. Is the
Jack Howarth writes:
> ===
> --- gcc/testsuite/gcc.target/i386/asm-dialect-1.c (revision 190647)
> +++ gcc/testsuite/gcc.target/i386/asm-dialect-1.c (working copy)
> @@ -1,4 +1,5 @@
> /* { dg-options "-masm=intel" } */
> +/*
On 2012-08-23 06:55 , 陳韋任 (Wei-Ren Chen) wrote:
I think this is much clear than before. The word "modes" in "CFG takes
various different modes" means different forms, GIMPLE or RTL, right?
Right.
Diego.
Currently the new testcase for gcc.target/i386/pr53249.c is failing
on darwin due to the absence of -mx32 support on that target. The following
patch skips this testcase on darwin. Tested on x86_64-apple-darwin12...
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02042.html
Okay for gcc trunk
Currently the new gcc.target/i386/asm-dialect-1.c testcase is failing on
darwin due the absence of support for -masm=intel on that target. The attached
patch skips this test on darwin. Tested on x86_64-apple-darwin12...
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02042.html
Okay for gcc t
Hi,
On Wed, Aug 22, 2012 at 03:37:48PM +0200, Richard Guenther wrote:
> On Wed, Aug 22, 2012 at 3:04 PM, Martin Jambor wrote:
> > On Tue, Aug 21, 2012 at 01:30:47PM +0200, Richard Guenther wrote:
> >> On Tue, Aug 21, 2012 at 1:27 PM, Martin Jambor wrote:
> >> > On Wed, Aug 15, 2012 at 05:21:04PM
On 2012-08-24 08:35 , Jakub Jelinek wrote:
You haven't built your compiler with --disable-bootstrap, so you aren't
seeing what Mike is complaining about.
Ah, Mike failed to mention that detail.
Mike, it is unlikely that I will be able to work on a fix before I
leave. It does not look like a
On Fri, Aug 24, 2012 at 08:30:36AM -0400, Diego Novillo wrote:
> On 2012-08-23 16:54 , Mike Stump wrote:
> >On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
> >>Other than the bootstrap change, the patches make no functional
> >>changes to the compiler. Everything should build as it does now in
>
On 2012-08-23 16:54 , Mike Stump wrote:
On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
Other than the bootstrap change, the patches make no functional
changes to the compiler. Everything should build as it does now in
trunk.
In my gcc/Makefile, I see:
CFLAGS = -g CXXFLAGS = -g -O2
Odd.
On Wed, Aug 22, 2012 at 8:49 AM, Zhenqiang Chen wrote:
>> The patch is to enable bbro for -Os. When optimizing for size, it
>> * avoid duplicating block.
>> * keep its original order if there is no chance to fall through.
>> * ignore edge frequency and probability.
>> * handle predecessor first if
2012/8/23 Georg-Johann Lay :
> Denis Chertykov wrote:
>> 2012/8/13 Georg-Johann Lay:
>>> Denis Chertykov wrote:
2012/8/11 Georg-Johann Lay:
> Weddington, Eric schrieb:
>>> From: Georg-Johann Lay
>>>
>>>
>>> The first step would be to bisect and find the patch that lead to
>
Il 23/08/2012 21:37, rbmj ha scritto:
>> In gcc/gcov-io.c, the call to open() only has two arguments. This
>> is fine, as long as the system open() is standards compliant.
So you have to add another fixincludes hack, adding a macro indirection
like the one you have for ioctl:
#d
On 21 August 2012 17:18, Joseph S. Myers wrote:
>
> On Tue, 21 Aug 2012, Simon Baldwin wrote:
>
> > Index: gcc/doc/options.texi
> > ===
> > --- gcc/doc/options.texi (revision 190535)
> > +++ gcc/doc/options.texi (working cop
On Thu, 23 Aug 2012, Diego Novillo wrote:
> I think I would like to explore the idea of implement a stack
> unwinder that's used by gcc_assert(). This way: (a) we do not
> need to uglify all the APIs with these extra arguments, (b) we
> can control how much of the call stack we show on an asserti
Thank you for testing.
> With commenting out "if (i != mode)" of the hunk
I changed type of transp and added this checking because if we reset
transp[mode], then later in the loop
FOR_EACH_BB (bb)
sbitmap_not (kill[bb->index], transp[i][bb->index]);
we set kill of the bb for that
... because they're not partitioned anyway, so they just confuse the dumps:
Will bootstrap&test, and commit if nothing strange shows up.
Ciao!
Steven
* tree-ssa-live.c (dump_var_map): Do not dump the partition
map of virtual operands.
Index: tree-ssa-live.c
=
> I've tried the patch on sh4-unknown-linux-gnu. I see new failures
> with it:
Here is a reduced test case for sh4-unknown-linux-gnu.
volatile double gd[32];
volatile float gf[32];
int main ()
{
int i;
for (i = 0; i < 32; i++)
gd[i] = i * 4, gf[i] = i;
for (i = 0; i < 32; i++)
i
On Sat, Apr 28, 2012 at 08:11:14AM -0700, H.J. Lu wrote:
> arg_pointer and frame_pointer are handled as special cases in
> based_loc_descr.
>
> (plus:DI (reg/f:DI 16 argp)
> (const_int -20 [0xffec]))
>
> is perfectly valid when Pmode == DImode and DWARF2_ADDR_SIZE is 32bit
> with
On Aug 24, 2012, at 12:24 AM, Paolo Bonzini wrote:
> Agreed, patch is preapproved. This is not really done to aid debugging
> though, it is to avoid optimization bugs when compiling stage1.
Ah, but building a non-bootstrap compiler from the top-level builds -O2 and
when built from the gcc subtre
On 24 August 2012 10:40, Richard Earnshaw wrote:
>
> Has this been tested for big-endian?
>
> R.
No. I'll give a look at it and let you know.
Christophe.
On 24/08/12 08:45, Christophe Lyon wrote:
> Hi,
>
> The patch below enables GCC for ARM to implement relevant constant
> vector permutations using the Neon vext instruction, by extending the
> support currently in place for vrev, vzip, vunzip and vtrn.
>
> For the cases where vext and vrev would
Hi,
The patch below enables GCC for ARM to implement relevant constant
vector permutations using the Neon vext instruction, by extending the
support currently in place for vrev, vzip, vunzip and vtrn.
For the cases where vext and vrev would lead to the same result, I
have chosen to keep using vre
On Fri, Aug 24, 2012 at 9:22 AM, Igor Zamyatin wrote:
> Following change enables look ahead feature in the code scheduler for
> Atom processors. This gives quite reasonable gain for some benchmarks
> for mobile market.
>
> Overall compile time increase for SPEC2000 is about 1%.
>
> Regtested for
Il 23/08/2012 22:54, Mike Stump ha scritto:
>
> # Remove the -O2: for historical reasons, unless bootstrapping we prefer
>
> # optimizations to be activated explicitly by the toplevel.
>
> case "$CC" in
> */prev-gcc/xgcc*) ;;
> *) CFLAGS=`echo $CFLAGS | sed "s/
Hi!
Following change enables look ahead feature in the code scheduler for
Atom processors. This gives quite reasonable gain for some benchmarks
for mobile market.
Overall compile time increase for SPEC2000 is about 1%.
Regtested for x86_64 and also bootstrapped with "--with-arch=core2
--with-cpu
86 matches
Mail list logo
