1) fixes the problem, so 5 and 4 are now in the same partition. The fix
is quite trivial, as with attached.
That looks obviously correct to me. I can't approve it, but I'd have
committed it as obvious.
Thanks, I'll make the formal request, after checking forthe unexpected
side effects
This bug is exposed by this patch.
On Thu, Sep 13, 2012 at 1:20 AM, Dehao Chen de...@google.com wrote:
There is another bug in the patch (not covered by unittests,
discovered through spec benchmarks).
When we remove unused locals, we do not mark the block as used for
debug stmt, but
I can reproduce the error. For large applications, the 32bit integer
will overflow (not enough to encode the locations). The following
patch can fix the problem. I'm still doing integration tests, and will
send out a integral patch tomorrow.
Thanks,
Dehao
diff --git a/libcpp/line-map.c
Can I get this commited please?
Thanks,
K.
-Original Message-
From: Mike Stump [mailto:mikest...@comcast.net]
Sent: 11 September 2012 18:41
To: Kyrylo Tkachov
Cc: 'Jakub Jelinek'; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, TESTSUITE] Add -fno-short-enums to pr51712
On Sep 11, 2012, at
On 09/13/12 09:12, Kyrylo Tkachov wrote:
Can I get this commited please?
Now applied with a minor tweak to the changelog.
2012-09-12 Kyrylo Tkachov kyrylo.tkac...@arm.com
* c-c++-common/pr51712.c: Handle for short-enum targets.
Thanks,
ramana
On Thu, Aug 23, 2012 at 01:54:38PM -0700, Mike Stump wrote:
I think:
# 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
Il 13/09/2012 10:46, Jakub Jelinek 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
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00330.html
Christophe.
On 6 September 2012 00:14, Christophe Lyon christophe.l...@linaro.org wrote:
Hello,
Although the recent optimization I have committed to use Neon vext
instruction for suitable builtin_shuffle calls does not support
Hi Uros,
Thank you for the review comments.
Committed to trunk at http://gcc.gnu.org/viewcvs?view=revisionrevision=191245
Regards,
Venkat.
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Wednesday, September 12, 2012 9:14 PM
To: Kumar, Venkataramanan
Cc:
Hi,
On Wed, Sep 12, 2012 at 04:17:45PM +0200, Michael Matz wrote:
Hi,
On Wed, 12 Sep 2012, Michael Matz wrote:
Hm, but we shouldn't end up streaming any BLOCKs at this point (nor
local TYPE_DECLs). Those are supposed to be in the local function
sections only where no
On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai sing...@google.com wrote:
Thanks for your comments. Please see my responses inline.
On Wed, Sep 12, 2012 at 5:37 PM, Eric Botcazou ebotca...@adacore.com wrote:
This is the PR about the useless spilling to memory of structures that are
returned in registers. It was essentially addressed last year by Easwaran
with
an enhancement of the RTL DSE pass, but Easwaran also noted
On Wed, Sep 12, 2012 at 8:27 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This patch cleans up some things that annoyed me in ipa-reference.c
and ipa-pure-const.c. These two passes are very important but they
show all the signs of being developed when GCC's IPA infrastructure
was
On Wed, Sep 12, 2012 at 11:53 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch makes inliner to realize that it is good idea to inline when loop
stride becomes constant. This is mostly to help fortran testcases where
it is important to inline to get array descriptors.
I think the same
On Thu, Sep 13, 2012 at 12:10 AM, Oleg Endo oleg.e...@t-online.de wrote:
Hello,
On Sun, 2012-09-02 at 01:19 +0200, Oleg Endo wrote:
On Sat, 2012-09-01 at 18:25 +0200, Oleg Endo wrote:
On Sat, 2012-09-01 at 16:17 +, Joseph S. Myers wrote:
On Sat, 1 Sep 2012, Oleg Endo wrote:
Hi Kaz,
The failure turned out to be issues with the profile count and handling
or region partitioning. So, I prefer to handle those separately,
For now, I disable shrink-wrap when partitioning, even if the problem
seems to have disappeared with the more constrained heuristics. This is
probably
On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen de...@google.com wrote:
There is another bug in the patch (not covered by unittests,
discovered through spec benchmarks).
When we remove unused locals, we do not mark the block as used for
debug stmt, but gimple-streamer-out will still stream out
On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen de...@google.com wrote:
Now I think we are facing a more complex problem. The data
On Wed, Sep 12, 2012 at 10:44 PM, Dehao Chen de...@google.com wrote:
Attached is the memory consumption report for a very large source
file. Looks like this patch actually reduced the memory consumption by
2%.
Please make sure to test large C++ expression template users. Large
regular
Hi,
I have just merged upstream trunk on the aarch64-branch up to r191124.
As a result, I have also updated the AArch64 backend with the attached
patch.
Thanks
Sofiane
aarch64-191124-rebase.patch
Description: Binary data
Hi,
I've just committed the attached patch on the branches
ARM/aarch64-branch
ARM/aarch64-4.7-branch
to fix the target ordering in supported_defaults in config.gcc.
Thank you
Sofiane
This unifies the two code paths that try to figure out which
VN handling routines are responsible for value-numbering. It
also fixes ADDR_EXPR handling so that we handle those properly.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-09-13 Richard Guenther
On Tue, May 24, 2011 at 1:35 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Here's a small patch to expand pow(x,n) for integer n using the
powi(x,n) logic in the cse_sincos pass. OK for trunk?
For the next patch, I'll plan on expanding pow(x,n) for n in
{0.5, 0.25, 0.75, 1./3.,
+/* Compute X = Y, taking into account the possibility that
+ X may become the maximum set. */
Hmm, how can X become the maximum set if it was not the maximum set
before? Thus, shouldn't this simply be
if (y == all_module_statics)
/* do nothing */;
else
...
?
No. The local
Hi,
the attached testcase triggers a memory exhaustion at -O2 during the cunrolli
pass on the mainline and 4.7 branch. The problem is that the size estimates
disregard induction variable computations on the ground that they will be
folded later. But they aren't folded between the iterations
Christian Bruel christian.br...@st.com wrote:
The failure turned out to be issues with the profile count and handling
or region partitioning. So, I prefer to handle those separately,
For now, I disable shrink-wrap when partitioning, even if the problem
seems to have disappeared with the more
Hi,
Jon noticed that for this testcase we don't warn at all even with -Wall,
whereas the code doesn't really make much sense. Turns out that the
warning is currently controlled both by warn_init_self (not part of
-Wall) and OPT_Wuninitialized. Thus Manuel proposes to simply remove the
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted. In practice, gdb for me is so weak in handling
-O1 or -O2, that if I want to debug
On Thu, Sep 13, 2012 at 3:11 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
the attached testcase triggers a memory exhaustion at -O2 during the cunrolli
pass on the mainline and 4.7 branch. The problem is that the size estimates
disregard induction variable computations on the ground
On Thu, Sep 13, 2012 at 3:08 PM, Steven Bosscher stevenb@gmail.com wrote:
+/* Compute X = Y, taking into account the possibility that
+ X may become the maximum set. */
Hmm, how can X become the maximum set if it was not the maximum set
before? Thus, shouldn't this simply be
if (y
On 09/13/2012 09:28 AM, Paolo Carlini wrote:
Jon noticed that for this testcase we don't warn at all even with -Wall,
whereas the code doesn't really make much sense. Turns out that the
warning is currently controlled both by warn_init_self (not part of
-Wall) and OPT_Wuninitialized. Thus Manuel
On Thu, Sep 13, 2012 at 2:29 PM, Jan Hubicka hubi...@ucw.cz wrote:
+/* Get the set of nodes for the cycle in the reduced call graph starting
+ from NODE. */
+
+VEC (cgraph_node_p, heap) *
+ipa_get_nodes_in_cycle (struct cgraph_node *node)
I never really like the api of SCC searching that
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted. In practice, gdb for
Hello!
The mode of address_operand predicate is ignored in ix86_legitimate_address_p.
2012-08-13 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (prefetch): Do not assert mode of operand 0.
(*prefetch_sse_mode): Do not set mode of address_operand predicate.
Rename
On 9/13/2012 9:38 AM, Jakub Jelinek wrote:
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
Indeed somewhat simple-minded - when originally fixing a similar testcase
(heh ...) I improved things by improving CFG cleanup to fold some more
conditions by looking at SSA defs, that improved things a lot. I also
thought the real fix should involve some scalar optimization on a
sub-range
On 09/11/2012 06:53 PM, Gabriel Dos Reis wrote:
On Tue, Sep 11, 2012 at 10:37 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Sep 11, 2012 at 05:29:12PM +0200, Paolo Carlini wrote:
PS: slightly interesting, in a couple of cases -
write_unnamed_type_name, wrap_cleanups_r - the parameters were
On Thu, Sep 13, 2012 at 4:00 PM, Eric Botcazou ebotca...@adacore.com wrote:
Indeed somewhat simple-minded - when originally fixing a similar testcase
(heh ...) I improved things by improving CFG cleanup to fold some more
conditions by looking at SSA defs, that improved things a lot. I also
On Thu, Sep 13, 2012 at 9:00 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 09/11/2012 06:53 PM, Gabriel Dos Reis wrote:
On Tue, Sep 11, 2012 at 10:37 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Sep 11, 2012 at 05:29:12PM +0200, Paolo Carlini wrote:
PS: slightly interesting, in
The updated patched is attached. Is it OK?
Yes, OK for mainline.
--
Eric Botcazou
Hello,
This patch fixes a couple of assertions while building libgcc, when
configured with --enable-checking=all.
OK for trunk ?
thanks
Christian
2012-09-13 Christian Bruel christian.br...@st.com
* config/sh/predicates.md (t_reg_operand): Check REG_P for SUBREG.
* config/sh/sh.c
On 08/31/2012 06:20 PM, Marc Glisse wrote:
this patch copies some more vector extensions from the C front-end to
the C++ front-end. There seemed to be some reluctance to add those, but
I guess a patch is the best way to ask
What was the reluctance? It seems clear to me that if we support the
Hi,
On 09/13/2012 03:38 PM, Jason Merrill wrote:
On 09/13/2012 09:28 AM, Paolo Carlini wrote:
Jon noticed that for this testcase we don't warn at all even with -Wall,
whereas the code doesn't really make much sense. Turns out that the
warning is currently controlled both by warn_init_self (not
OK.
Jason
When a parenthesized initializer has dependent elements, we leave it as
a TREE_LIST. We shouldn't let that confuse us into thinking that it
isn't value-dependent.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 26bd4898faf6a74d3e5f1531790cabd1a5d25d8a
Author: Jason Merrill
Instantiating an anonymous union was problematic because we don't set up
a mapping between the fake variables that point to the different
members. This patch fixes that by doing name lookup to find the
corresponding fake variable in the instantiation, and then adding it to
the hash table for
On 13/09/2012 14:35, Tobias Burnus wrote:
gfortran wrongly marks some procedures as implicit_pure which aren't
pure. implicit_pure exists since 2011-01-08 (= GCC 4.6), but was only
used internally (FE optimization and trans*.c to avoid temporaries).
Since 2012-08-28, implicit_pure also implies
We weren't requiring the result of an INDIRECT_REF to be a constant
because we could end up taking its address again later, so in this case
we ended up trying to handle a non-constant expression as a constant and
failing. But since we have the addr parameter we know whether or not
we will end
That is a good point. Currently I am making a distinction between dump
flags and opt-info flags, but it is not necessary since the opt-info
flags can be thought of an extension of dump flags.
I will update the patch so that -fdump-tree-vect-optimized also works.
Thanks,
Sharad
On Thu, Sep 13,
Is -fopt-info-rtl-all also accepted?
Currently it is accepted. However, based on the recent comments, I am
going to remove the pass name from the flags.
It would be useful to have a good default for -fopt-info so that users
can get high level info about optimizations without having to
On 13 September 2012 15:38, Jason Merrill ja...@redhat.com wrote:
I think my preference would be to add -Winit-self to -Wall for C++; people
can use -Wno-init-self if they don't want the warning.
But then the warning should report Winit-self (that is, use
OPT_Winit_self for warning) and not
Hi!
This ICE is because c_finish_return calls convert after c_fully_fold
is performed on the argument, and doesn't call it again, thus we need
in_late_binary_op.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.7?
2012-09-13 Jakub Jelinek ja...@redhat.com
On Thu, 13 Sep 2012, Jason Merrill wrote:
On 08/31/2012 06:20 PM, Marc Glisse wrote:
this patch copies some more vector extensions from the C front-end to
the C++ front-end. There seemed to be some reluctance to add those, but
I guess a patch is the best way to ask
What was the reluctance?
Hi!
The fma-*.c testcase show that these intrinsics probably mean to preserve
the high elements (other than the lowest) of the first argument of the
fmaintrin.h *_s{s,d} intrinsics in the destination (the HW insn preserve
there the destination register, but that varies - for 132 and 213 it is the
On Thu, Sep 13, 2012 at 10:53:23AM +0200, Paolo Bonzini wrote:
Il 13/09/2012 10:46, Jakub Jelinek ha scritto:
# Remove the -O2: for historical reasons, unless bootstrapping we prefer
# optimizations to be activated explicitly by the toplevel.
case
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar de...@adacore.com wrote:
On 9/13/2012 8:00 AM, Richard
Will it help
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
It won't help everywhere, since it's only for architectures that return
structures in registers, so x86-64 but not x86 for example.
54315 pertains to single-fielded unions and
Yes, indeed.
thanks,
David
On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12,
On Thu, Sep 13, 2012 at 8:02 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen
Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
Can we get this change in? The current state is terribly annoying.
Yes, please go ahead.
Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
additionally tested on --disable-bootstrap tree, both by make cc1 inside of
gcc
On 9/13/2012 12:07 PM, Xinliang David Li wrote:
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
Yes, of course, and for sure -g cannot affect optimized code,
The following patch fixes a problem exposed in LIPO random stress
testing with large module groups -- the error is that multiple copies
compiler generated static functions (ctor of class in anonymous
namespace) get emitted.
David
Index: cgraphunit.c
Hi, the google/gcc-main fails to linking anything (on x86-generic chromeos).
By looking into specs file, it seems that 'link_emulation' section is
missing in specs.
The problem is in config/i386/linux.h, SUBTARGET_EXTRA_SPECS (which is
not empty for chrome x86-generic) is overridden by
Robert == Robert Dewar de...@adacore.com writes:
Robert Sometimes I wonder whether the insistence on -g not changing code
Robert generation is warranted. In practice, gdb for me is so weak in handling
Robert -O1 or -O2, that if I want to debug something I have to recompile
Robert with -O0 -g,
Dehao == Dehao Chen de...@google.com writes:
Dehao + static htab_t location_adhoc_data_htab;
Dehao + static source_location curr_adhoc_loc;
Dehao + static struct location_adhoc_data *location_adhoc_data;
Dehao + static unsigned int allocated_location_adhoc_data;
libcpp was written to allow
On 9/13/2012 12:46 PM, Tom Tromey wrote:
Robert == Robert Dewar de...@adacore.com writes:
Robert Sometimes I wonder whether the insistence on -g not changing code
Robert generation is warranted. In practice, gdb for me is so weak in handling
Robert -O1 or -O2, that if I want to debug something
On Thu, 13 Sep 2012, Jakub Jelinek wrote:
Hi!
This ICE is because c_finish_return calls convert after c_fully_fold
is performed on the argument, and doesn't call it again, thus we need
in_late_binary_op.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for
On Sep 13, 2012, at 2:45 AM, Christophe Lyon christophe.l...@linaro.org wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00330.html
So, two things I thought I'd ask about:
+/* __attribute__ ((noinline)) is currently required, otherwise the
+ generated code computes wrong results
On Sep 13, 2012, at 8:47 AM, Marc Glisse marc.gli...@inria.fr wrote:
What was the reluctance? It seems clear to me that if we support the type,
we should support these operations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
In comments 1 and 7, Richard Guenther didn't seem too
Here is a patch to add a new mips*-mti-elf target to GCC. This is similar
to the mips*-mti-linux-gnu target but for bare metal instead of linux.
The main difference between this new target and the existing mips*-sde-elf
target is that this version does not get built for as many different mips
On Sep 13, 2012, at 6:52 AM, Robert Dewar de...@adacore.com wrote:
Sure, it is obvious that you don't want -g to affect -O1 or -O2 code,
but I think if you have -Og (if and when we have that), it would not
be a bad thing for -g to affect that.
No, instead think of -Og as affecting the -g
On Thu, Sep 13, 2012 at 5:52 PM, Jakub Jelinek ja...@redhat.com wrote:
The fma-*.c testcase show that these intrinsics probably mean to preserve
the high elements (other than the lowest) of the first argument of the
fmaintrin.h *_s{s,d} intrinsics in the destination (the HW insn preserve
On Sep 13, 2012, at 9:51 AM, Robert Dewar de...@adacore.com wrote:
I routinely debugged code at -O1, but then the
compiler got better at optimization, and things deteriorated so much
at -O1 that now I don't even attempt it.
An example of a non-feature for me would be the reordering of
On Thu, Sep 13, 2012 at 07:42:17PM +0200, Uros Bizjak wrote:
Can we introduce additional *fmai_fmadd_mode_1 pattern (and
others) that would cover missing 231 alternative?
Sure. Will cook up a patch soon.
2012-09-13 Jakub Jelinek ja...@redhat.com
PR target/54564
*
Hello,
this patch is a minor cleanup of my previous forwprop patches for vectors.
I have known about get_prop_source_stmt from the beginning, but for some
reason I always used SSA_NAME_DEF_STMT. This makes the source code
slightly shorter, and together with PR 54565 it should help get some
On Thu, Sep 13, 2012 at 07:42:17PM +0200, Uros Bizjak wrote:
Can we introduce additional *fmai_fmadd_mode_1 pattern (and
others) that would cover missing 231 alternative?
Here is the patch for that. But, I don't see how it would ever match
(unless perhaps x is equal to z, but then the other
On 09/13/2012 08:52 AM, Jakub Jelinek wrote:
The following patch fixes it, by tweaking the header so that the first
argument is not negated (we negate the second one instead), as we don't want
to negate the high elements if e.g. for whatever reason combiner doesn't
match it. It fixes the
On 09/13/2012 10:42 AM, Uros Bizjak wrote:
Can we introduce additional *fmai_fmadd_mode_1 pattern (and
others) that would cover missing 231 alternative?
I really don't think that's necessary. For that you'd need to
be computing fma(x, y, x), at which point vfmadd213 matches as well.
r~
Sounds like a good cleanup to me.
Thanks. I managed to screw up the computation of the new right end of the
memory access in adjust_address_1 so I'll fix and retest.
--
Eric Botcazou
On Thu, Sep 13, 2012 at 11:28:11AM -0700, Richard Henderson wrote:
On 09/13/2012 10:42 AM, Uros Bizjak wrote:
Can we introduce additional *fmai_fmadd_mode_1 pattern (and
others) that would cover missing 231 alternative?
I really don't think that's necessary. For that you'd need to
be
On Thu, Sep 13, 2012 at 11:25:42AM -0700, Richard Henderson wrote:
On 09/13/2012 08:52 AM, Jakub Jelinek wrote:
The following patch fixes it, by tweaking the header so that the first
argument is not negated (we negate the second one instead), as we don't want
to negate the high elements if
On Thu, Sep 13, 2012 at 11:25:42AM -0700, Richard Henderson wrote:
(2) It's not the best match if we were to extend these builtins to FMA4.
There we really do have 4 inputs. Thus
How could you extend these builtins to FMA4 BTW? Doesn't FMA4 zero up the
high elements? In that case you'd
On 09/13/2012 11:49 AM, Jakub Jelinek wrote:
On Thu, Sep 13, 2012 at 11:25:42AM -0700, Richard Henderson wrote:
(1) Negating the second argument is arguably non-canonical rtl.
That is why I've put in the *fmai_fnm{add,sub}_mode patterns
operands 2 with the neg as first operand of the FMA
On 09/13/2012 12:03 PM, Jakub Jelinek wrote:
How could you extend these builtins to FMA4 BTW? Doesn't FMA4 zero up the
high elements?
Duh. You're absolutely right. I'd mis-read the document as clearing the
high lane of the %ymm register only.
r~
On Thu, Sep 13, 2012 at 8:00 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen de...@google.com wrote:
There is another bug in the patch (not covered by unittests,
discovered through spec benchmarks).
When we remove unused locals, we do not
On 2012-09-11 18:53 , Ian Lance Taylor wrote:
2012-09-11 Ian Lance Taylor i...@google.com
* Initial implementation.
OK.
Diego.
On 2012-09-11 18:54 , Ian Lance Taylor wrote:
2012-09-11 Ian Lance Taylor i...@google.com
* MAINTAINERS (Various Maintainers): Add libbacktrace.
* configure.ac (host_libs): Add libbacktrace.
(target_libraries): Add libbacktrace.
* Makefile.def (host_modules):
On 2012-09-12 10:48 , Ian Lance Taylor wrote:
On Tue, Sep 11, 2012 at 3:55 PM, Ian Lance Taylor i...@google.com wrote:
This patch is the actual implementation of libbacktrace.
This is the updated version of this patch with a state parameter.
This is OK.
Thank you so much for doing this!
Because there is no enthusiastic support for a full libtool update,
here is a minimal version that adds a new slim-lto-bootstrap
build-config.
Comments are welcome.
Thanks.
Tested on x86_64-pc-linux-gnu
2012-09-13 Markus Trippelsdorf mar...@trippelsdorf.de
* Makefile.in
On 09/13/2012 11:47 AM, Marc Glisse wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
In comments 1 and 7, Richard Guenther didn't seem too enthusiastic about
any vector-related extension to the C++ front-end.
Some users (other PRs) asked instead that we make vector types
class-like so
On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
for a followup (and I bet sth else than PRE blows up at -O2 as well).
Actually, the only thing that really blows up is that enemy of scalability,
VRP.
FWIW, this appears to be
Markus Trippelsdorf mar...@trippelsdorf.de writes:
Because there is no enthusiastic support for a full libtool update,
here is a minimal version that adds a new slim-lto-bootstrap
build-config.
Can you split the two patches? libtool and ltmain? Thanks for extracting
those out.
Looks good to
On Thu, 13 Sep 2012, Jason Merrill wrote:
I don't know either.
+ if (TREE_TYPE (type0) != TREE_TYPE (type1))
I think this should use same_type_ignoring_top_level_qualifiers_p.
Hmm, I assume you mean
same_type_ignoring_top_level_qualifiers_p (type0, type1)
which would replace both
Now that TImode support is enabled on SPARC 64-bit, let's implement it. :-)
This is modeled on the TFmode support and, consequently, inherits its relative
verbosity. A future cleanup could simplify it a little and unify it with the
TFmode support, as e.g. for Alpha.
Bootstrapped/regtested on
Christian Bruel christian.br...@st.com wrote:
This patch fixes a couple of assertions while building libgcc, when
configured with --enable-checking=all.
OK for trunk ?
OK.
Regards,
kaz
Here are some changes in support of a little-endian soft-core
implementation of moxie. We now build multilibs for both endians.
Corresponding binutils changes have already been committed and I am
checking this in. (note: it does include what I believe are
trivially correct doc changes -
On Thu, 13 Sep 2012, Jason Merrill wrote:
Furthermore, this builtin support would be useful for implementing
a C++ class for vector arithmetic, just as it is with std::complex. I'm not
aware of any other portable way to implement such a class.
I forgot to say: it is always possible to do
Hi,
include/random has
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
#include cstdint // For uint_fast32_t, uint_fast64_t, uint_least32_t
#include bits/random.h
#include bits/random.tcc
#endif // _GLIBCXX_USE_C99_STDINT_TR1
random_device is defined in bits/random.h. But src/c++11/random.cc
has
#include
Hi,
There is no reason why --eh-frame-hdr can't be used with static
executable on Linux. This patch enables --eh-frame-hdr for static
executable on Linux and adds an exception test for static executable.
Other platforms may also work correctly. But I can't verify it.
Tested on Linux/x86-64.
On Fri, Sep 14, 2012 at 12:49 AM, Tom Tromey tro...@redhat.com wrote:
Dehao == Dehao Chen de...@google.com writes:
Dehao + static htab_t location_adhoc_data_htab;
Dehao + static source_location curr_adhoc_loc;
Dehao + static struct location_adhoc_data *location_adhoc_data;
Dehao + static
100 matches
Mail list logo
