The global variables generated to store this_image/num_images were wrong
in several ways:
- translation-unit (TU) dependent name (could be same or different)
- variable generated in every TU - and not only in one
- not pushed - which could cause already failures with one TU
Now, the variable
On May 3, 2011, Revital1 Eres e...@il.ibm.com wrote:
Please let me know if you need any further info.
No, thanks, that was all I needed.
I think this will restore proper functioning to SMS in the presence of
debug insns. A while ago, we'd never generate deps of non-debug insns
on debug
* gcc-interface/decl.c (intrin_arglists_compatible_p): Use iterators
instead of accessing TYPE_ARG_TYPES directly.
* gcc-interface/utils.c (handle_nonnull_attribute): Likewise.
Probably fine, but please patch the C front-end first. I'm afraid that the
coverage of this part
On Tue, May 3, 2011 at 16:39, Chris Demetriou c...@google.com wrote:
It is also OK if you s/__i686/__x86/ to correspond to your earlier
change. Either way is OK.
Well, that change is not in trunk.
Should that change move to trunk, yes, it's appropriate to change this
as well (though
Well, let's look at the users of copy_tree_r.
cp/tree.c (bot_manip): The case I want to fix.
Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
sensible one and its callers should cope, as almost all already do it seems.
--
Eric Botcazou
Hello,
The following is a summary of discussion I had with Ayal regarding the patch:
Some background: currently, SMS supports only targets where the doloop
pattern is decoupled from the rest of the loop's instructions (for example
PowerPC) (we'll call it 'case decoupled' for simplicity) In this
My apologies, the previous email refers to the patch:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00350.html
- Support closing_branch_deps
and not to 'Avoid considering debug_insn when calculating SCCs' as
the title implies.
Thanks,
Revital
Hi,
on the heels of the discussion with Joseph, the attached patch removes the
error issued by variable_size, as it appears to be totally useless at this
point. FEs should be responsible for catching errors here.
Tested on x86_64-suse-linux, OK for the mainline?
2011-05-04 Eric Botcazou
Well - the errors in variable_size aren't used by C any more (since 4.5),
but I don't know whether any other languages use them.
Apparently not, let's remove them.
And pending sizes are used to a limited extent for C (to handle side effects
in sizes of array parameters, as described in the
On May 4, 2011, Alexandre Oliva aol...@redhat.com wrote:
I think this will restore proper functioning to SMS in the presence of
debug insns. A while ago, we'd never generate deps of non-debug insns
on debug insns. I introduced them to enable sched to adjust (reset)
debug insns when
On Tue, May 3, 2011 at 8:34 PM, Jason Merrill ja...@redhat.com wrote:
On 04/28/2011 03:50 PM, Diego Novillo wrote:
This patch from Silvius Rus adds a new flag (-fstrict-enum-precision).
While porting the patch to 4.6, I noticed that the C++ FE now has a
similar flag that seems to have similar
On Tue, May 3, 2011 at 10:36 PM, Dodji Seketeli do...@seketeli.org wrote:
FWIW, this was posted to
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00949.html
-- Forwarded message --
From: Dodji Seketeli do...@redhat.com
To: Jason Merrill ja...@redhat.com
Date: Wed, 16 Mar
On 05/03/2011 09:06 PM, Nathan Froyd wrote:
Testing in progress on x86_64-unknown-linux-gnu. OK to commit if
testing successful?
The Fortran part is OK. Thanks for the janitorial work.
Tobias
gcc/
* tree.h (build_function_type_array): Declare.
Hi!
And here are 3 backports to 4.4 branch, bootstrapped/regtested on
x86_64-linux and i686-linux, committed to gcc-4_4-branch.
Jakub
2011-05-04 Jakub Jelinek ja...@redhat.com
Backported from mainline
2011-05-03 Uros Bizjak ubiz...@gmail.com
Jakub
On Tue, May 3, 2011 at 11:57 PM, Xinliang David Li davi...@google.com wrote:
On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li davi...@google.com wrote:
On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
On Wed, May 4, 2011 at 12:20 AM, Matthias Klose d...@ubuntu.com wrote:
On 05/02/2011 09:53 PM, Diego Novillo wrote:
Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.
Fixed with this. OK for google/gcc-4_6?
Google ref
Hello Alexandre
I think this will restore proper functioning to SMS in the presence of
debug insns. A while ago, we'd never generate deps of non-debug insns
on debug insns. I introduced them to enable sched to adjust (reset)
debug insns when non-debug insns were moved before them. I
On Wed, May 4, 2011 at 4:51 AM, David Edelsohn dje@gmail.com wrote:
On Tue, May 3, 2011 at 5:27 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
When I added VSX support to the powerpc, I overlooked passing and return
V2DImode arguments, since the only machine operation that
On Tue, May 3, 2011 at 6:15 PM, Xinliang David Li davi...@google.com wrote:
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka hubi...@ucw.cz wrote:
Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become
quite impossible
So I would like to know what testcase
On Wed, May 4, 2011 at 11:22 AM, Tobias Burnus bur...@net-b.de wrote:
On 05/03/2011 09:06 PM, Nathan Froyd wrote:
Testing in progress on x86_64-unknown-linux-gnu. OK to commit if
testing successful?
The Fortran part is OK. Thanks for the janitorial work.
The middle-end parts are also ok.
On Mon, 2011-04-25 at 19:39 +0400, Dmitry Melnik wrote:
Hi All,
The attached patch changes the reload class for NEON constant vectors
from GENERAL_REGS to NO_REGS.
The issue was found on this code from libevas:
void
_op_blend_p_caa_dp(unsigned *s, unsigned* e, unsigned *d, unsigned c)
Umm, I think most of them (if not all) are just bogus. If a FE doesn't
want to fold some stuff when at global scope it should not call fold.
That isn't so easy because fold is invoked on sizes of types by stor-layout.c
and these sizes can be variable (at least in Ada). So I think that the
Hello!
Oh well... some broken assemblers got confused with movq %reg, %xmm
DImode move mnemonic. movd works correctly as well, so use this form
instead.
2011-05-04 Uros Bizjak ubiz...@gmail.com
PR target/48860
* config/i386/i386.md (*movdi_internal_rex64) Use %vmovd
On Wed, May 04, 2011 at 12:02:17PM +0200, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu, committed to mainline SVN. I will audit
movq usage in other release branches as well.
s/reqire/require/g
--- config/i386/i386.md (revision 173353)
+++ config/i386/i386.md (working copy)
On Tue, 3 May 2011, Gerald Pfeifer wrote:
On Wed, 27 Apr 2011, Michael Witten wrote:
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I
Hi,
I always considered the cgrpah_node_set/varpool_node_set to be
overengineered
but they also turned out to be quite ineffective since we do quite a
lot of
queries into them during stremaing out.
This patch moves them to pointer_map, like I did for streamer cache.
While
doing so I
On Wed, 4 May 2011, Eric Botcazou wrote:
That isn't so easy because fold is invoked on sizes of types by stor-layout.c
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b)
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
for language semantics (e.g. constant expressions). If you want to
optimize
On Wed, May 4, 2011 at 12:00 PM, Eric Botcazou ebotca...@adacore.com wrote:
Umm, I think most of them (if not all) are just bogus. If a FE doesn't
want to fold some stuff when at global scope it should not call fold.
That isn't so easy because fold is invoked on sizes of types by
Joseph S. Myers jos...@codesourcery.com writes:
The most obvious other low-hanging fruit in the circumstances would be to
stop these files being built for non-native as a fix for bug 3746, so that
all-targets cross builds of make all-gcc (e.g. through Joern's
config-list.mk, which is
This patch separates cases disabling newlib and libgloss for various
target OSes from the main toplevel case statement over targets.
By doing so, the logic is significantly simplified; there is now a
single case for all *-*-linux* targets that disables newlib and
libgloss for them, for example.
On Tue, May 3, 2011 at 18:20, Matthias Klose d...@ubuntu.com wrote:
On 05/02/2011 09:53 PM, Diego Novillo wrote:
Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.
Fixed with this. OK for google/gcc-4_6?
Google ref
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
for language semantics (e.g. constant expressions).
Why? Isn't it
Joseph S. Myers jos...@codesourcery.com writes:
What is so hard about running grep when removing/renaming symbols???
Generically, the presence of lots of nonobvious places that may turn out
to use a symbol - ada/gcc-interface/, go/gofrontend, config/ for what one
thinks of as front-end
This patch implements the simpler parts of stopping
rs6000_handle_option from using global state. Many options are
converted to use .opt features such as Var and Enum, replacing
explicit code, while other code is changed to use the opts and
opts_set pointers. -mabi=, -mcpu= and -mtune= will be
Hi,
On Wed, 4 May 2011, Richard Guenther wrote:
It prevents save_expr from being called at global level, since you
cannot create SAVE_EXPRs outside functions. Likewise in
variable_size.
I see several places in fold-const.c that are not properly guarded then.
But anyway, if it is
As the example in the PR shows, using -fno-protect parens can make a
huge difference. As -fno-protect is in the spirit of -Ofast, enable it
with that option.
Build on x86-64-linux.
OK for the trunk?
Tobias
gcc/
2011-05-04 Tobias Burnus bur...@net-b.de
PR fortran/48864
* doc/invoke.texi
On Wed, 4 May 2011, Rainer Orth wrote:
Your expansion of the wiki page on toplevel libgcc migration is
certainly welcome: I hadn't seen before that *-unwind.h files and
related macros can be moved over as well.
I've no idea whether they can be moved *at present*, but certainly the
eventual
On Wed, May 4, 2011 at 1:56 PM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 4 May 2011, Richard Guenther wrote:
It prevents save_expr from being called at global level, since you
cannot create SAVE_EXPRs outside functions. Likewise in
variable_size.
I see several places in
While checking the current german tanslations I noticed that
mep_validate_vliw passes the syntax description directly to inform and thus
they appear in the message catalogue which is IMO bogus. This patch makes
the syntax descriptions untanslkatable.
OK to check in?
2011-05-04 Philipp Thomas
On Wed, May 4, 2011 at 07:44, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote:
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the literature.
Sure, in the sorts of examples you mention where there's a level
On Wed, May 4, 2011 at 08:30, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in
On 27 April 2011 17:26, Andrew Stubbs a...@codesourcery.com wrote:
On 21/04/11 16:58, Joseph S. Myers wrote:
You need to add
%inherit GCC_4.7.0 GCC_4.6.0
GCC_4.7.0 {
}
Ok, done. Is this OK now?
I can't approve the target independent parts of this but as I said on
IRC based on a brief
This is the C family parts, bootstrapped and tested on
x86_64-unknown-linux-gnu.
Ok for trunk?
Thanks,
Richard.
2011-05-04 Richard Guenther rguent...@suse.de
* c-decl.c (check_bitfield_type_and_width): Do not pass NULL
to build_int_cst.
* c-typeck.c
Hello,
the new gcc.c-torture/compile/pr48767.c test cases were all crashing the
compiler on SPU, for a similar reason as on the SH where this problem
was originally found.
Fixed by calling the common code pass_by_reference routine instead of
calling spu_pass_by_reference directly. The common
Fortran parts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress,
ok if it passes?
Thanks,
Richard.
2011-05-04 Richard Guenther rguent...@suse.de
* trans-array.c (gfc_trans_array_constructor_value): Use
size_int for bounds of range types.
Hi,
On Wed, 4 May 2011, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the literature.
Sure, in
On 05/04/2011 02:49 PM, Richard Guenther wrote:
Fortran parts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress,
ok if it passes?
OK. Thanks for doing the janitorial work.
Tobias
2011-05-04 Richard Guentherrguent...@suse.de
* trans-array.c
On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the
On Wed, May 4, 2011 at 09:19, Nathan Froyd froy...@codesourcery.com wrote:
On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For
I think we may be talking at different levels. It's my impression
that Richard K. was referring to local transformations like a - a -
0 once we are in the middle end. I agree that doing that
transformation close to the FE is undesirable, but once we are in the
middle end that should be
On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the attached patch uses the existing promote_function_mode hook. For
a libcall neither TYPE nor FNTYPE is available so I had to change a
few related function in order to deal with that.
The patch also
2011/5/4 Richard Guenther richard.guent...@gmail.com:
On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the attached patch uses the existing promote_function_mode hook. For
a libcall neither TYPE nor FNTYPE is available so I had to change a
few related
On Wed, May 04, 2011 at 11:22:02AM +0200, Tobias Burnus wrote:
On 05/03/2011 09:06 PM, Nathan Froyd wrote:
Testing in progress on x86_64-unknown-linux-gnu. OK to commit if
testing successful?
The Fortran part is OK. Thanks for the janitorial work.
Thanks for the review! We'll see if the
On Wed, May 4, 2011 at 3:45 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/5/4 Richard Guenther richard.guent...@gmail.com:
On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
Hi,
the attached patch uses the existing promote_function_mode hook. For
a
Hi,
-Ofast is intended to be -O3 plus -ffast-math. For the compiler proper
this works, but under -ffast-math we add crtfastmath.o (or some
equivalent) to the link command line on some targets. As usual for our
specs this uses matching on command line arguments, hence we'll
explicitely have
On 04/18/2011 10:26 AM, Andreas Krebbel wrote:
If it is not for ABI differences anymore what's the reason for
handling libcalls differently from normal calls anymore? Couldn't we
get rid of all the special handling and deal with them like normal
calls?
That would be desirable IMO.
Bernd
On Wed, 4 May 2011, Richard Guenther wrote:
2011-05-04 Richard Guenther rguent...@suse.de
* c-decl.c (check_bitfield_type_and_width): Do not pass NULL
to build_int_cst.
* c-typeck.c (really_start_incremental_init): Use bitsize_int
for constructor indices.
Hi Michael,
-Ofast is intended to be -O3 plus -ffast-math. For the compiler proper
this works, but under -ffast-math we add crtfastmath.o (or some
equivalent) to the link command line on some targets. As usual for our
specs this uses matching on command line arguments, hence we'll
And I'm not sure you can't do SAVE_EXPRs outside of functions - you
could simply emit global temporaries.
How do you initialize global temporaries with non-trivial initializers?
--
Eric Botcazou
2011-05-03 Richard Guenther rguent...@suse.de
* expmed.c (expand_variable_shift): Rename to ...
(expand_shift_1): ... this. Take an expanded shift amount.
For rotates recurse directly not building trees for the shift amount.
(expand_variable_shift): Wrap around
On 05/04/2011 05:08 AM, Richard Guenther wrote:
On Tue, May 3, 2011 at 10:10 PM,jason.merr...@gmail.com wrote:
As I commented on the -Wnonnull patch, rather than complain about people
getting the argument number wrong we should ignore 'this' (and other
artificial parms) for attribute argument
On Wed, 4 May 2011, Eric Botcazou wrote:
2011-05-03 Richard Guenther rguent...@suse.de
* expmed.c (expand_variable_shift): Rename to ...
(expand_shift_1): ... this. Take an expanded shift amount.
For rotates recurse directly not building trees for the shift amount.
This patch to the Go frontend uses the backend interface for named
types, and also array type. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2011-05-04 Ian Lance Taylor i...@google.com
* go-gcc.cc (Gcc_backend::struct_type): Call
On 05/04/2011 04:12 AM, Eric Botcazou wrote:
Well, let's look at the users of copy_tree_r.
cp/tree.c (bot_manip): The case I want to fix.
Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
sensible one and its callers should cope, as almost all already do it seems.
On Wed, May 4, 2011 at 5:10 PM, Eric Botcazou ebotca...@adacore.com wrote:
And I'm not sure you can't do SAVE_EXPRs outside of functions - you
could simply emit global temporaries.
How do you initialize global temporaries with non-trivial initializers?
Actually it turns out that it doesn't
I think I did it that way because the old code tried to re-construct
the type of the original amount. I can surely simply use op1 here
if that is preferred.
Right, but it used the value of OP1 so I think the new code should as well.
Btw, do you happen to know any target that would excercise
Following recent discussions of variable_size, this patch stops the C
front end from using the global pending_sizes list, instead using the
existing grokdeclarator support for tracking size expressions in the
one case where pending sizes were still needed. c_variable_size is
replaced by a call to
Hi Tobias,
As the example in the PR shows, using -fno-protect parens can make a
huge difference. As -fno-protect is in the spirit of -Ofast, enable it
with that option.
Build on x86-64-linux.
OK for the trunk?
OK.
Out of curiosity: Why do you do
gfc_option.flag_protect_parens =
As $SUBJECT suggests. The patch is somewhat larger than it needs to be
due to reindenting c-common.c:check_main_parameter_types.
Tested on x86_64-unknown-linux. OK to commit?
-Nathan
gcc/c-family/
* c-common.c (check_main_parameter_types): Reindent. Don't use
TYPE_ARG_TYPES
On Wed, 4 May 2011, Nathan Froyd wrote:
As $SUBJECT suggests. The patch is somewhat larger than it needs to be
due to reindenting c-common.c:check_main_parameter_types.
Tested on x86_64-unknown-linux. OK to commit?
Since you're reindenting you should also wrap the pedwarn calls in the
On 05/04/2011 06:43 PM, Thomas Koenig wrote:
Out of curiosity: Why do you do
gfc_option.flag_protect_parens = optimize_fast ? 0 : 1;
instead of
gfc_option.flag_protect_parens = optimize_fast;
I found it more clearer than = !optimize_fast (note the !), but
that's seemingly not the case.
Actually it turns out that it doesn't matter. If we arrive here with
something that needs a SAVE_EXPR we have to be able to generate code
for it somewhere, where there would be obviously the possibility to
also generate code for a SAVE_EXPR.
The transformations done in fold are optimizations
As promised in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00211.html .
Tested by building f951. Committed as r173386.
-Nathan
gcc/fortran/
* trans.h (gfc_chainon_list): Delete.
* trans.c (gfc_chainon_list): Delete.
Index: gcc/fortran/ChangeLog
Joseph I don't know if Fortran, Java or Go use variable-size types at
Joseph all.
Java doesn't have variable-size types.
AFAIK, gcj does not generate them internally for anything, either.
Tom
On Wed, 2011-05-04 at 11:33 +0200, Richard Guenther wrote:
On Wed, May 4, 2011 at 4:51 AM, David Edelsohn dje@gmail.com wrote:
On Tue, May 3, 2011 at 5:27 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
This patch fixes that so that V2DImode values are passed and returned
Hi Anatoly,
Sorry for my mistake. I think that the patch is obvious, but I have no
capability to test it.
* config/sparc/sol.h (ASM_OUTPUT_CALL): Use print_operand target
hook.
Index: gcc/config/sparc/sol2.h
Should DW_OP_bra be restricted to integral types? Several other opcodes
are restricted in this way, and it seems like an oversight to me that
DW_OP_bra is lacking this restriction. (I've added this restriction in
GDB.)
Yes, that was an oversight.
Currently, the comparison operators are
On May 4, 2011, at 3:08 AM, Joseph S. Myers wrote:
On Tue, 3 May 2011, Gerald Pfeifer wrote:
On Wed, 27 Apr 2011, Michael Witten wrote:
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
On Wed, 4 May 2011, Joseph S. Myers wrote:
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
I think we *should* make such formatting cleanups (not just trailing
whitespace
On 04/02/2011 10:15 AM, Alexandre Oliva wrote:
Some targets delayed the var-tracking pass to run it after
machine-specific transformations. The introduction of option saving and
restoring broke this, because the machine-specific overriding took place
too late for it to be saved, so, after
On Wed, 4 May 2011, Gerald Pfeifer wrote:
On Wed, 4 May 2011, Joseph S. Myers wrote:
I believe we usually don't do whitespace changes just for the sake
of cleaning up things.
Unless someone else indicates otherwise, I believe this patch is
rejected.
I think we *should* make such
Hello!
This patch increases/decreases array sizes a bit to prevent loop
unrolling and adds appropriate -no-* ABI flags.
2011-05-04 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/recip-vec-divf.c: Decrease array sizes.
* gcc.target/i386/recip-vec-sqrtf.c: Ditto.
*
Hi.
This patch remove some unused macros from sparc.h. The RTX_OK_FOR_OFFSET_P
and RTX_OK_FOR_OLO10_P macros is used only in sparc_legitimate_address_p
function and moved to sparc.c.
Bootstrapped on sparc64-unknown-linux-gnu.
OK to install?
* config/sparc/sparc.h
In http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00061.html I noted a
couple of bits of code in the toplevel configure.ac that appeared to
be doing things that are properly the responsibility of autoconf.
This patch removes them. OK to commit?
(Along with
Diego,
Testing w/ ubuntu lucid native bootstrap + check (C/C++), with --with-pic
and numerous other flags, looking good.
OK for google/main (assuming tests succeed)?
chris
--
[libgcc/ChangeLog.google-main]
2011-05-04 Chris Demetriou c...@google.com
Backport from trunk r173391:
Jakub == Jakub Jelinek ja...@redhat.com writes:
Tom Should DW_OP_bra be restricted to integral types? Several other opcodes
Jakub Yes. If you want to test other types, just compare them against 0
Jakub using DW_OP_ne etc.
Great, thanks.
Tom Currently, the comparison operators are all
This patch adds a new streamer hook to populate the streamer cache
with common nodes.
The nodes we populate for GIMPLE in lto_get_common_nodes is not
sufficient for C++, unsurprisingly.
The patch fixes these regressions in pph.exp:
FAIL: g++.dg/pph/p1stdlib.cc -fpph-map=pph.map -I. (test for
On 05/04/2011 09:12 PM, Joseph S. Myers wrote:
-# hpux11 in 64bit mode has libraries in a weird place. Arrange to find
-# them automatically.
-
-# The Solaris /usr/ucb/cc compiler does not appear to work.
Ok.
Paolo
Following recent discussions of variable_size, this patch stops the C
front end from using the global pending_sizes list, instead using the
existing grokdeclarator support for tracking size expressions in the
one case where pending sizes were still needed. c_variable_size is
replaced by a
On Wed, May 4, 2011 at 15:50, Chris Demetriou c...@google.com wrote:
2011-05-04 Chris Demetriou c...@google.com
Backport from trunk r173391:
2011-05-04 Chris Demetriou c...@google.com
* config/i386/morestack.S (__i686.get_pc_thunk.bx): Rename to...
On Wed, May 4, 2011 at 15:35, Sriraman Tallam tmsri...@google.com wrote:
* tree-pass.h (pass_tree_convert_builtin_dispatch): New pass.
(pass_ipa_multiversion_dispatch): New pass.
* builtin-types.def (BT_PTR_FN_INT): New pointer type.
I submitted the patch.
Thanks,
-Sri.
On Wed, May 4, 2011 at 3:13 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, May 4, 2011 at 15:35, Sriraman Tallam tmsri...@google.com wrote:
* tree-pass.h (pass_tree_convert_builtin_dispatch): New pass.
(pass_ipa_multiversion_dispatch):
I can think of some more-or-less obvious high-level forms, one would
for example simply stick a new DISPATCH tree into gimple_call_fn
(similar to how we can have OBJ_TYPE_REF there), the DISPATCH
tree would be of variable length, first operand the selector function
and further operands
The problem was that fixed_type_or_null was looking closely at things
that aren't meant to be looked at closely when we're in templates,
namely a COMPONENT_REF where operand 1 is an IDENTIFIER. In a template
we're going to discard the conversion anyway once we decide it's OK, so
we might as
Hi,
this patch makes inliner more selective about when to test can_inline_edge_p
and when to reset edge caches. The first appears quite hot in Mozilla LTO
build profiles
now, since we used to do way too many resets even when not neccesary.
After inlining function A to B, we need:
1) reset
Well, I disagree. STATEMENT_LISTs are just another kind of thing you
encounter in an expression; if a caller wants special handling, they can
arrange for it.
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of
Hi,
Marc kindly contributed the below rewrite of std::ratio_add (and
ratio_less), algorithmically derived from the macro __udiv_qrnnd_c in
gcc's longlong.h, which amounts to the best behavior in terms of
accepted inputs: a pair of std::ratio is *never* rejected unless the
resulting
Is this patch ok for trunk?
Allowing relative path in -fprofile-generate= is very useful when
running the program remotely -- the profile data will be just dumped
in the dir relative to the working dir in the remote machine. Using
GCOV_PREFIX_STRIP can workaround the problem, but it is not always
1 - 100 of 106 matches
Mail list logo
