>> 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 e
This bug is exposed by this patch.
On Thu, Sep 13, 2012 at 1:20 AM, Dehao Chen 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
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 b/libcpp/l
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
* 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*) ;;
> *) CFL
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=`e
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00330.html
Christophe.
On 6 September 2012 00:14, Christophe Lyon wrote:
> Hello,
>
> Although the recent optimization I have committed to use Neon vext
> instruction for suitable builtin_shuffle calls does not support
> big-endian yet, I have
Hi Uros,
Thank you for the review comments.
Committed to trunk at http://gcc.gnu.org/viewcvs?view=revision&revision=191245
Regards,
Venkat.
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Wednesday, September 12, 2012 9:14 PM
To: Kumar, Venkataramanan
Cc: gcc-
> 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
> > > > se
On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li wrote:
> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
> wrote:
>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wrote:
>>> Thanks for your comments. Please see my responses inline.
>>>
>>> On Tue, Sep 11, 2012 at 1:16 PM, Xinliang David
On Wed, Sep 12, 2012 at 5:37 PM, Eric Botcazou 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 that we still
> spi
On Wed, Sep 12, 2012 at 8:27 PM, Steven Bosscher 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 still (or at lea
On Wed, Sep 12, 2012 at 11:53 PM, Jan Hubicka 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 applies to upp
On Thu, Sep 13, 2012 at 12:10 AM, Oleg Endo 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:
>> > >
>> > > > Ping
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 la
On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen 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 blocks for
> d
On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li wrote:
> On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
> wrote:
>> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
>>> Now I think we are facing a more complex problem. The data structure
>>> we use to store the location_adhoc_data are fi
On Wed, Sep 12, 2012 at 10:44 PM, Dehao Chen 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 programs do not stres
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
> 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 still (or at least even more than today) in its infancy: Walking
yeah,
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 DECL_PURE_P. The later
change exposes a b
On Tue, May 24, 2011 at 1:35 PM, William J. Schmidt
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., 1./6.}. This logic will
> +/* 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.
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 o
Christian Bruel 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 constrained heuristi
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
former,
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 some
On Thu, Sep 13, 2012 at 3:11 PM, Eric Botcazou 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 that they will be
>
On Thu, Sep 13, 2012 at 3:08 PM, Steven Bosscher 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 == all
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 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 made us
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, gd
Hello!
The mode of address_operand predicate is ignored in ix86_legitimate_address_p.
2012-08-13 Uros Bizjak
* config/i386/i386.md (prefetch): Do not assert mode of operand 0.
(*prefetch_sse_): Do not set mode of address_operand predicate.
Rename to ...
(*prefe
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
gener
> 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-ran
On 09/11/2012 06:53 PM, Gabriel Dos Reis wrote:
On Tue, Sep 11, 2012 at 10:37 AM, Jakub Jelinek 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
actually used.
On Thu, Sep 13, 2012 at 4:00 PM, Eric Botcazou 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
>> thought the real
On Thu, Sep 13, 2012 at 9:00 AM, Paolo Carlini wrote:
> On 09/11/2012 06:53 PM, Gabriel Dos Reis wrote:
>>
>> On Tue, Sep 11, 2012 at 10:37 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Sep 11, 2012 at 05:29:12PM +0200, Paolo Carlini wrote:
PS: slightly interesting, in a couple of cases -
>>
> 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
* config/sh/predicates.md (t_reg_operand): Check REG_P for SUBREG.
* config/sh/sh.c (sequence_insn_p: Check INSNP_P
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
Date:
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 l
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 impl
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 en
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, 20
> 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 spe
On 13 September 2012 15:38, Jason Merrill 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 OPT_Wuninitializ
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
PR c/54559
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? I
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.
> >> >
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 wrote:
> On 9/13/2012 8:00 AM, Richard Guenther wrote:
>
>> Be
> 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 an
Yes, indeed.
thanks,
David
On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
>> wrote:
>>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wrote:
Thanks for your comm
On Thu, Sep 13, 2012 at 8:02 PM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 6:39 PM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
>> wrote:
>>> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
Now I think we are facing a more complex problem. The d
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
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, see
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
"LINUX_GRT
> "Robert" == Robert Dewar 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, which cau
> "Dehao" == Dehao Chen 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 multiple p
On 9/13/2012 12:46 PM, Tom Tromey wrote:
"Robert" == Robert Dewar 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 re
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
"Manuel López-Ibáñez" ha scritto:
>But then the warning should report Winit-self (that is, use
>OPT_Winit_self for warning) and not OPT_Wuninitialized. Because it is
>what people should use to disabled it.
Ok, I'll do the change.
Thanks,
Paolo
On Sep 13, 2012, at 2:45 AM, Christophe Lyon 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 in big-endian. */
and:
On Sep 13, 2012, at 8:47 AM, Marc Glisse 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 enthusiastic abou
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
arc
On Sep 13, 2012, at 6:52 AM, Robert Dewar 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 output itself. If i
On Thu, Sep 13, 2012 at 5:52 PM, Jakub Jelinek 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
> there the destina
On Sep 13, 2012, at 9:51 AM, Robert Dewar 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 instructions by
schedu
On Thu, Sep 13, 2012 at 07:42:17PM +0200, Uros Bizjak wrote:
> Can we introduce additional "*fmai_fmadd__1" pattern (and
> others) that would cover missing 231 alternative?
Sure. Will cook up a patch soon.
> > 2012-09-13 Jakub Jelinek
> >
> > PR target/54564
> > * config/i386/
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
op
On Thu, Sep 13, 2012 at 07:42:17PM +0200, Uros Bizjak wrote:
> Can we introduce additional "*fmai_fmadd__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 ins
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 e
On 09/13/2012 10:42 AM, Uros Bizjak wrote:
> Can we introduce additional "*fmai_fmadd__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__1" pattern (and
> > others) that would cover missing 231 alternative?
>
> I really don't think that's necessary. For that you'd need to
> b
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 elemen
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}_ patterns
> operands 2 with the neg as first operand of the FMA rt
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
wrote:
> On Wed, Sep 12, 2012 at 7:20 PM, Dehao Chen 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 s
On 2012-09-11 18:53 , Ian Lance Taylor wrote:
2012-09-11 Ian Lance Taylor
* Initial implementation.
OK.
Diego.
On 2012-09-11 18:54 , Ian Lance Taylor wrote:
2012-09-11 Ian Lance Taylor
* MAINTAINERS (Various Maintainers): Add libbacktrace.
* configure.ac (host_libs): Add libbacktrace.
(target_libraries): Add libbacktrace.
* Makefile.def (host_modules): Add libbacktrace
On 2012-09-12 10:48 , Ian Lance Taylor wrote:
On Tue, Sep 11, 2012 at 3:55 PM, Ian Lance Taylor 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! This will help r
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
* Makefile.in (configure-build-fixincludes): Pass
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 u
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
Markus Trippelsdorf 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 me, but eventually
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 th
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 SP
Christian Bruel 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 - apologi
On Fri, 14 Sep 2012, Marc Glisse wrote:
While checking my facts for the previous paragraph, I got an ICE :-(
typedef int vec __attribute__((vector_size(16)));
vec const f(vec x,vec y){return xThe same program compiles with gcc (prepare_cmp_insn isn't called), but ICEs
with g++. Looking at the
1 - 100 of 106 matches
Mail list logo
