On Wed, Aug 28, 2013 at 11:20 AM, Teresa Johnson wrote:
> On Wed, Aug 28, 2013 at 9:58 AM, Jan Hubicka wrote:
>> Hi,
>> with Martin we did bit of progress on analyzing the problems. We now have
>> COMDAT profile merging for FDO
>
> Great! Is this the LTO merging you were talking about in an ear
On Thu, Aug 29, 2013 at 03:58:45PM +0200, Jan Hubicka wrote:
> > > Said that, I now have the fork() patch in all my trees and enjoy 50%
> > > faster
> > > WPA times. I changed my mind about claim that stremaing should be disk
> > > bound -
> > > it is hard to hope for disk boundness for somethin
Ok. Do consider generalize it with 1) more inline hints (how the
parameters are used in callee); and 2) more parameter type (such as
addr_k, non_null_k, range_k etc you have proposed before) in the
future.
thanks,
David
On Thu, Aug 29, 2013 at 11:24 AM, Easwaran Raman wrote:
> On Tue, Aug 20,
Richard,
Do you want me to commit everything but the insert_stmt_after hunk
now? There are more similar failures reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 and I have attached
the updated patch there. Shall I send that for review? Apart from the
debug statement issue, almost all
I was debugging a runtime failure of SPEC06 xalancbmk built with LIPO.
Using -fdisable- option pinpoints the problem in slp vectorize
pass on a particular function. dbgcnt support is added to to track
down the individual BB, but it fails even when the dbg count is set
to 0.
It turns out that no B
On 29-Aug-13, at 6:52 PM, Steven Bosscher wrote:
I haven't tried to see what goes on in the compiler, but it feels like
your.patch just fixes a symptom. Might be just reload behaving like
reload, but it just seems to me that the problem is not that you
cannot create new pseudos at the point of t
On 29-Aug-13, at 6:52 PM, Steven Bosscher wrote:
Can the target make the move I'm asking
for without introducing new registers...
Yes, it can execute extract and insert instructions using the same
source and target register.
Of course, this clobbers the source.
Dave
--
John David Anglin
On Thu, Aug 29, 2013 at 2:14 AM, John David Anglin wrote:
> As expected, your patch doesn't fix the PR.
Hmm, unfortunate. The reason why I proposed it is because it would
revert to the way this code worked before http://gcc.gnu.org/r104371
The idea was to make "force" false, and let the normal ba
Hello world,
the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
within DO CONCURRENT.
Regression-tested. OK for trunk?
Regards
Thomas
2013-08-29 Thomas Koenig
PR fortran/PR56519
* gfortran.h: Declare gfc_do_concurrent_flag as extern.
* r
Fixed
FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
on
mips64-unknown-linux-gnu
Index: gcc/tree.c
===
--- gcc/tree.c (revision 202088)
+++ gcc/tree.c (working copy)
@@ -8531,11 +8531,11 @@ bool
int_fits_t
On Thu, Aug 29, 2013 at 4:06 PM, Adam Butcher wrote:
> On 29.08.2013 21:59, Gabriel Dos Reis wrote:
>>
>> On Thu, Aug 29, 2013 at 3:57 PM, Adam Butcher
>> wrote:
>>>
>>> From: abutcher
>>>
>>> * error.c (dump_lambda_function): New function, dependent on ...
>>> (dump_substitution
On 29.08.2013 21:59, Gabriel Dos Reis wrote:
On Thu, Aug 29, 2013 at 3:57 PM, Adam Butcher
wrote:
From: abutcher
* error.c (dump_lambda_function): New function, dependent on
...
(dump_substitution): ... this new function, factored out of
...
(subst_to_string): ... h
On Thu, Aug 29, 2013 at 3:57 PM, Adam Butcher wrote:
> From: abutcher
>
> * error.c (dump_lambda_function): New function, dependent on ...
> (dump_substitution): ... this new function, factored out of ...
> (subst_to_string): ... here and ...
> (dump_function_decl)
From: abutcher
* error.c (dump_lambda_function): New function, dependent on ...
(dump_substitution): ... this new function, factored out of ...
(subst_to_string): ... here and ...
(dump_function_decl): ... here. Updated to early-out with call to
dump_lambd
On Thu, Aug 29, 2013 at 2:49 AM, Ian Lance Taylor wrote:
> Uros tracked down a problem with the section used for immutable structs:
> the value of compute_reloc_for_constant would change between the time
> immutable_struct_set_init would call it and the time that
> get_variable_section would call
On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm wrote:
> * gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
> (gt_pch_nx (gimple)): Likewise.
GIMPLE isn't supposed to end up in a PCH. Can you please make this
function simply call gcc_unreachable()?
FWIW 1: I really
On 08/29/2013 11:24 AM, Paolo Carlini wrote:
+ if ((complain & tf_error)
+ && (flags & LOOKUP_DELEGATING_CONS)
+ && name == complete_ctor_identifier
+ && TREE_CODE (ret) == CALL_EXPR
+ && (DECL_ABSTRACT_ORIGIN (TREE_OPERAND (CALL_EXPR_FN (ret), 0))
+ == current_functi
Indeed, I check the Standard about const_pointer, so here is another
attempt.
Tested under Linux x86_64.
2013-08-29 François Dumont
PR libstdc++/58148
* include/debug/functions.h (__foreign_iterator_aux4): Use
sequence const_pointer as common type to compare pointers. Add a
On Thu, Aug 29, 2013 at 1:51 PM, Adam Butcher wrote:
> * error.c (dump_lambda_function): New function, dependent on ...
> (maybe_dump_with_clause): ... this new function, factored out of ...
> (subst_to_string): ... here and ...
> (dump_function_decl): ... here. Up
On Aug 29, 2013, at 12:36 AM, Richard Biener wrote:
> On Wed, 28 Aug 2013, Mike Stump wrote:
>
>> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
>>> Btw, rtl.h still wastes space with
>>>
>>> struct GTY((variable_size)) hwivec_def {
>>> int num_elem; /* number of elements */
>>> HOS
This fixes a build error in trunk. Before:
# cat gcc/REVISION
[trunk
trunk revision 202083]
and after:
$ cat gcc/REVISION
[trunk revision 202083]
$ svn info
Path: .
Working Copy Root Path: /Users/mrs/net/gcc
URL: svn+ssh://m...@gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root:
On Thu, 2013-08-29 at 20:51 +0200, Jakub Jelinek wrote:
> On Thu, Aug 29, 2013 at 08:45:33PM +0200, Oleg Endo wrote:
> > Sorry for the delay. I've just backported the 2 patches to 4.8.
> > Tested with 'make all-gcc' for SH and PPC cross compilers.
> > Committed as rev 202083.
>
> Please fix the o
On Thu, Aug 29, 2013 at 08:45:33PM +0200, Oleg Endo wrote:
> Sorry for the delay. I've just backported the 2 patches to 4.8.
> Tested with 'make all-gcc' for SH and PPC cross compilers.
> Committed as rev 202083.
Please fix the overly long lines as a follow-up.
> +struct insn_gen_fn
> +{
> + ty
* error.c (dump_lambda_function): New function, dependent on ...
(maybe_dump_with_clause): ... this new function, factored out of ...
(subst_to_string): ... here and ...
(dump_function_decl): ... here. Updated to early-out with call to
dump_lambda_function a
On Wed, 2013-08-07 at 21:24 +0200, Oleg Endo wrote:
> On Wed, 2013-08-07 at 15:08 -0400, Michael Meissner wrote:
> > On Tue, Aug 06, 2013 at 11:45:40PM +0200, Oleg Endo wrote:
> > > On Mon, 2013-08-05 at 13:25 -1000, Richard Henderson wrote:
> > > > On 08/05/2013 12:32 PM, Oleg Endo wrote:
> > > >
> Fixed.
>
> It's not fully tested. I just run the 28_regex testcases. I'll do a
> full test before committing.
Committed.
--
Tim Shen
changelog
Description: Binary data
regex-locale.patch
Description: Binary data
On Wed, Aug 21, 2013 at 6:47 AM, Teresa Johnson wrote:
>> +/* Knob to control hot-caller heuristic. 0 means it is turned off, 1 means
>> + it is always applied, and 2 means it is applied only if the footprint is
>> + smaller than PARAM_HOT_CALLER_CODESIZE_THRESHOLD. */
>> DEFPARAM (PARAM_INL
On Tue, Aug 20, 2013 at 9:35 PM, Xinliang David Li wrote:
> Do you need to guard the jump function access with check if
> (ipa_node_params_vector.exists ())?
I believe it is not necessary since, for example, ipa_analyze_node
calls ipa_check_create_node_params that calls create. But I see it is
use
On 29.08.2013 16:25, Gabriel Dos Reis wrote:
On Thu, Aug 29, 2013 at 9:20 AM, Adam Butcher
wrote:
* error.c (dump_lambda_function): New function, dependent on
...
(maybe_dump_template_bindings): ... this new function,
factored out of
...
(dump_function_decl): .
This patch is 110KB in size, so to avoid mailing-list size limits I've uploaded
it to:
http://dmalcolm.fedorapeople.org/gcc/large-patches/a89d361b4f95dd216e1d29cb44fbaf90372c48b8-0003-Autogenerated-conversion-of-gimple-to-C.patch
The ChangeLog entry and diffstat follow:
gcc/
Patch auto
* gimple-streamer-in.c (input_gimple_stmt): Port from union
access to use of as_a.
* gimple.c (gimple_build_asm_1): Likewise.
(gimple_build_try): Likewise. Also, return a specific subclass
rather than just gimple.
(gimple_build_resx): Port from union
* gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
(gt_pch_nx (gimple)): Likewise.
(gt_pch_nx (gimple, gt_pointer_operator, void *)): Likewise.
* gimple.h (gt_ggc_mx (gimple)): Declare.
(gt_pch_nx (gimple)): Declare.
(gt_pch_nx (gimple
* gimple.h (is_a_helper ::test): New.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
---
gcc/gimple.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 43573a1..e2c
* gimple.h (gimple_use_ops): Port from union to usage of
dyn_cast.
(gimple_set_use_ops): Port from union to usage of as_a.
(gimple_set_vuse): Likewise.
(gimple_set_vdef): Likewise.
(gimple_call_internal_fn): Port from union to a static_cast,
g
* coretypes.h (union gimple_statement_d): Remove declaration.
(gimple): Convert from being a "union gimple_statement_d *"
to a "struct gimple_statement_base *".
(const_gimple): Likewise (with "const").
* ggc.h (ggc_alloc_cleared_gimple_statement_d_stat): Repl
The various gimple types are currently implemented using a hand-coded
C inheritance scheme, with a "union gimple_statement_d" holding the
various possible structs for a statement.
The following series of patches convert it to a C++ class
hierarchy, using the existing structs, eliminating the union
On Wed, Aug 28, 2013 at 7:09 AM, Teresa Johnson wrote:
>> The inline stuff should be split and re-sent, it's non-obvious to me (extra
>> function parameters are not documented for example). I'd rather have
>> inline_and_report_call () for example instead of an extra bool parameter.
>> But let's i
Hi,
thus I have this simple patch which at least catches pure
self-delegation (no cycles). Better than nothing, I would say, given its
simplicity ;)
At first I thought I would put the check in expand_default_init but then
I noticed that in case of, eg, virtual bases, the simple pattern
matc
On Thu, Aug 29, 2013 at 9:20 AM, Adam Butcher wrote:
> * error.c (dump_lambda_function): New function, dependent on ...
> (maybe_dump_template_bindings): ... this new function, factored out of
> ...
> (dump_function_decl): ... here. Updated to early-out with call t
On Thu, Aug 29, 2013 at 3:04 AM, Richard Biener
wrote:
New patch below that removes this global variable, and also outputs
the node->symbol.order (in square brackets after the function name so
as to not clutter it). Inline messages with profile data look look:
test.c:8:3:
* error.c (dump_lambda_function): New function, dependent on ...
(maybe_dump_template_bindings): ... this new function, factored out of
...
(dump_function_decl): ... here. Updated to early-out with call to
dump_lambda_function after determining template bind
> > Said that, I now have the fork() patch in all my trees and enjoy 50% faster
> > WPA times. I changed my mind about claim that stremaing should be disk
> > bound -
> > it is hard to hope for disk boundness for something that should fit in
> > cache.
>
> It should at least limit its fork rate
Ok.
Richard.
On Thu, Aug 29, 2013 at 3:18 PM, Teresa Johnson wrote:
> On Wed, Aug 28, 2013 at 9:07 AM, Teresa Johnson wrote:
>> On Wed, Aug 28, 2013 at 7:09 AM, Teresa Johnson wrote:
>>> On Wed, Aug 28, 2013 at 4:01 AM, Richard Biener
>>> wrote:
On Wed, Aug 7, 2013 at 7:23 AM, Teresa Joh
On Thu, 29 Aug 2013, Jan Hubicka wrote:
> Jakub,
> I am adding you to CC since I put my current toughts on LTO and debug info
> in here.
> > > Fork-fire-forget is really a much simpler choice here IMO; no worries
> > > about shared resources, less debug hassle.
> >
> > It might be not as cheap a
On Thu, Aug 29, 2013 at 3:05 AM, Richard Biener
wrote:
Does
'make newlines consitent' avoid all the spurious vertical spacing I see
with
-fopt-info?
>>>
>>> Well, it helps get us there. The problem was that before, since
>>> dump_loc was not consistently emitting newlines, the
On 08/28/2013 05:08 AM, Richard Biener wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was n
On Thu, Aug 29, 2013 at 03:05:59PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 29, 2013 at 02:56:58PM +0200, Marek Polacek wrote:
> > --- gcc/Makefile.in.mp 2013-08-29 14:24:49.839578625 +0200
> > +++ gcc/Makefile.in 2013-08-29 14:54:39.354258737 +0200
> > @@ -2273,7 +2273,7 @@ tsan.o : $(CONFIG
On Wed, Aug 28, 2013 at 9:07 AM, Teresa Johnson wrote:
> On Wed, Aug 28, 2013 at 7:09 AM, Teresa Johnson wrote:
>> On Wed, Aug 28, 2013 at 4:01 AM, Richard Biener
>> wrote:
>>> On Wed, Aug 7, 2013 at 7:23 AM, Teresa Johnson wrote:
On Tue, Aug 6, 2013 at 9:29 AM, Teresa Johnson
wrote
Hi,
On Thu, 29 Aug 2013, Richard Biener wrote:
> > Fork-fire-forget is really a much simpler choice here IMO; no worries
> > about shared resources, less debug hassle.
>
> It might be not as cheap as it is on Linux hosts on other hosts of
> course.
Sure. Don't use it there then. Not a reason
On 28/08/13 08:00, bin.cheng wrote:
> Hi,
>
> This patch refines scaled address expression on ARM. It supports
> "base+index*scale" in arm_legitimate_address_outer_p. It also tries to
> legitimize "base + index * scale + offset" with "reg <- base + offset; reg
> + index * scale" by introducing
On Thu, Aug 29, 2013 at 02:56:58PM +0200, Marek Polacek wrote:
> --- gcc/Makefile.in.mp2013-08-29 14:24:49.839578625 +0200
> +++ gcc/Makefile.in 2013-08-29 14:54:39.354258737 +0200
> @@ -2273,7 +2273,7 @@ tsan.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_
> intl.h cfghooks.h output.h options.h
> On Thu, Aug 29, 2013 at 02:47:46PM +0200, Paolo Carlini wrote:
> > On 08/29/2013 02:19 PM, Jan Hubicka wrote:
> > >So my belief is that it is safe to drop those symbols from
> > >libstdc++. Every program/DSO using them have to define its own
> > >copy of those symbols, so I believe removing them
On Thu, 29 Aug 2013, Jakub Jelinek wrote:
> Hi!
>
> I've bootstrapped/regtested on x86_64-linux and i686-linux these 3 backports
> (last patch is actually combined from 3 separate commits), all applied
> cleanly to 4.8 branch.
>
> Ok for 4.8?
Ok.
Thanks,
Richard.
The following fixes PR58246 by fixing a dominator check.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-29 Richard Biener
PR tree-optimization/58246
* tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Properly
handle the dominan
On Wed, Aug 28, 2013 at 03:37:31PM +0200, Jakub Jelinek wrote:
> On Wed, Aug 28, 2013 at 03:30:46PM +0200, Marek Polacek wrote:
> > >From a quick look, it doesn't seem like we do. (I was searching for
> > something about pointer_map in ggc* and gen* files.)
>
> If we can't make it GC aware easily
On Thu, Aug 29, 2013 at 02:47:46PM +0200, Paolo Carlini wrote:
> On 08/29/2013 02:19 PM, Jan Hubicka wrote:
> >So my belief is that it is safe to drop those symbols from
> >libstdc++. Every program/DSO using them have to define its own
> >copy of those symbols, so I believe removing them from libst
> Hi,
>
> On 08/29/2013 02:19 PM, Jan Hubicka wrote:
> >So my belief is that it is safe to drop those symbols from
> >libstdc++. Every program/DSO using them have to define its own
> >copy of those symbols, so I believe removing them from libstdc++
> >won't cause issues.
> Really, you should check
Jakub,
I am adding you to CC since I put my current toughts on LTO and debug info
in here.
> > Fork-fire-forget is really a much simpler choice here IMO; no worries
> > about shared resources, less debug hassle.
>
> It might be not as cheap as it is on Linux hosts on other hosts of
> course. Als
Hi,
On 08/29/2013 02:19 PM, Jan Hubicka wrote:
So my belief is that it is safe to drop those symbols from libstdc++.
Every program/DSO using them have to define its own copy of those
symbols, so I believe removing them from libstdc++ won't cause issues.
Really, you should check with Jakub befor
Hi!
I've bootstrapped/regtested on x86_64-linux and i686-linux these 3 backports
(last patch is actually combined from 3 separate commits), all applied
cleanly to 4.8 branch.
Ok for 4.8?
Jakub
2013-08-29 Jakub Jelinek
Backported from mainline
2013-05-27 Richard Biene
Richard, Jason,
I would apprechiate your opinion on this patch. It blocks all the code that
makes
use of ipa-devirt post LTO streaming.
The main part that I would like to know your opinion on is the ODR rule
implementation
by vtable comparsion (it looks obvious but I got it wrong once already)
On 08/29/2013 04:42 AM, Richard Biener wrote:
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have rand
M
> Hi,
>
> On 08/29/2013 10:11 AM, Jan Hubicka wrote:
> >Paolo,
> >there seems to be one extra issue about this patch. It causes quite a twist
> >in libstdc++ exported symbols.
> >It is purpose of the patch to remove those that are going to be generated in
> >user programs, too.
> >I am however
Hello,
> Testing in progress, is it ok for trunk if pass?
I forgot to add clobber to split of andn,
so testing fail. Fixed.
Updated patch in the bottom.
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 & 2006 build show no regressions both with and without -mavx5
This makes sure we cleanup at least some of the spurious copies
that can be introduced for example by jump-threading and that confuse
uninitialized var analysis.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-29 Richard Biener
PR middle-end/57287
Recently support for LEON3 specific instructions were added to GCC.
Make this support available for RTEMS.
This patch should be committed to GCC 4.9.
gcc/ChangeLog
2013-08-29 Sebastian Huber
* config/sparc/t-rtems: Add leon3 multilibs.
---
gcc/config/sparc/t-rtems |4 ++--
1 file
On Wed, Aug 28, 2013 at 08:30:19AM -0700, H.J. Lu wrote:
> On Wed, Aug 28, 2013 at 2:37 AM, Jakub Jelinek wrote:
> > On Wed, Aug 14, 2013 at 09:03:24AM +0200, Uros Bizjak wrote:
> >> The implementation for x86 is technically OK, but I wonder if these
> >> sequences should be documented in some aut
On Wed, Aug 28, 2013 at 8:14 PM, Xinliang David Li wrote:
> Fixed as requested. I don't like the extra newline either, but I will
> leave that to Teresa.
>
> basic3.c:8:foo: note: loop vectorized
>
> basic3.c:8:foo: note: loop versioned for vectorization because of
> possible aliasing
>
> basic3.c
On Wed, Aug 28, 2013 at 7:02 PM, Mike Stump wrote:
> On Aug 28, 2013, at 2:34 AM, Richard Biener
> wrote:
>> Huh? Why should wide-int need to be marked GTY at all?!
>
> Can I answer with a question? Why would nb_iter_bound be GTYed?
Because it references a GIMPLE stmt which resides in GC memo
On Wed, Aug 28, 2013 at 5:20 PM, Xinliang David Li wrote:
> On Wed, Aug 28, 2013 at 7:09 AM, Teresa Johnson wrote:
>> On Wed, Aug 28, 2013 at 4:01 AM, Richard Biener
>> wrote:
>>> On Wed, Aug 7, 2013 at 7:23 AM, Teresa Johnson wrote:
On Tue, Aug 6, 2013 at 9:29 AM, Teresa Johnson
wr
On Wed, Aug 28, 2013 at 4:09 PM, Teresa Johnson wrote:
> On Wed, Aug 28, 2013 at 4:01 AM, Richard Biener
> wrote:
>> On Wed, Aug 7, 2013 at 7:23 AM, Teresa Johnson wrote:
>>> On Tue, Aug 6, 2013 at 9:29 AM, Teresa Johnson wrote:
On Tue, Aug 6, 2013 at 9:01 AM, Martin Jambor wrote:
> H
On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger
wrote:
> The lim pass (aka loop invariant motion) can move conditional expressions
> with possible undefined behavior out of the if statement inside a loop which
> may cause the loop optimization to silently generate wrong code as PR
> tree-optim
Hi,
On 08/29/2013 10:11 AM, Jan Hubicka wrote:
Paolo,
there seems to be one extra issue about this patch. It causes quite a twist in
libstdc++ exported symbols.
It is purpose of the patch to remove those that are going to be generated in
user programs, too.
I am however bit confused about bad
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
>
> > > >Note that the bits above the precision are not defined and the
> > > >algorithms used here are careful not to depend on their value. In
> > > >particular, values that come in from rtx constants may have random
> > > >bits.
> > W
Jeff Law writes:
> >* cse.c (fold_rtx) : If prev_insn_cc0 is NULL
> >don't call equiv_constant on it.
> I can't help but feel something different needs to be done here. It's
> always been the case that those two insns are expected to be contiguous
> and there's going to be code all
Hello Bill and Jakub
On 08/22/2013 07:47 PM, Jakub Jelinek wrote:
> On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
>> Hi Christian and Jakub,
>>
>> I'm curious whether there was ever any resolution for:
>> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
>
Sorry for not hav
Paolo,
there seems to be one extra issue about this patch. It causes quite a twist in
libstdc++ exported symbols.
It is purpose of the patch to remove those that are going to be generated in
user programs, too.
I am however bit confused about bad array. Perhaps it is an optimization
difference d
This fixes PR57685 - exponential behavior in VRP assert expression
insertion. The fix below cuts off in the simplest possible way.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-28 Richard Biener
PR tree-optimization/57685
* tree-vrp.c (regis
On Wed, 28 Aug 2013, Mike Stump wrote:
> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
> > Btw, rtl.h still wastes space with
> >
> > struct GTY((variable_size)) hwivec_def {
> > int num_elem; /* number of elements */
> > HOST_WIDE_INT elem[1];
> > };
> >
> > struct GTY((chain_ne
On Wed, 28 Aug 2013, Michael Matz wrote:
> Hi,
>
> On Wed, 21 Aug 2013, Richard Biener wrote:
>
> > I also fail to see why threads should not work here. Maybe simply
> > annotate gcc with openmp?
>
> Threads simply don't work here, because the whole streamer infrastructure
> (or anything els
80 matches
Mail list logo
