> I don't expect that this will be back ported to GCC 4.8. You also need
> Binutils 2.24 for this.
>From a SPARC maintainership viewpoint, I'd think that this is backportable for
the upcoming 4.8.2 release, and the patches are essentially SPARC-specific,
but perhaps the RMs are of a different o
Hi Kaz, Oleg,
On 09/19/2013 01:15 AM, Kaz Kojima wrote:
> Christian Bruel wrote:
>> && (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"
>>
>> is necessary ?
> It looks an another hack to allow the 2nd and 3rd alternatives only
> when reloading. If so, it might be a bit cl
On 2013-09-19 09:23, Eric Botcazou wrote:
I don't expect that this will be back ported to GCC 4.8. You also need
>Binutils 2.24 for this.
From a SPARC maintainership viewpoint, I'd think that this is backportable for
the upcoming 4.8.2 release, and the patches are essentially SPARC-specific,
bu
Hi,
On 09/19/2013 05:46 AM, Marc Glisse wrote:
Hello,
I did not touch the regular basic_string because Paulo usually says
not to touch it, but I could do it as well if wanted.
If you like, please go ahead, there are no ABI issues in this case.
Indeed, in the current implementation the move co
Hi,
On Thu, 2013-09-19 at 10:44 +0200, Christian Bruel wrote:
> Hi Kaz, Oleg,
>
> On 09/19/2013 01:15 AM, Kaz Kojima wrote:
> > Christian Bruel wrote:
> >> && (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"
> >>
> >> is necessary ?
> > It looks an another hack to allow t
On 09/19/2013 10:50 AM, Paolo Carlini wrote:
Hi,
On 09/19/2013 05:46 AM, Marc Glisse wrote:
Hello,
I did not touch the regular basic_string because Paulo usually says
not to touch it, but I could do it as well if wanted.
If you like, please go ahead, there are no ABI issues in this case.
Ind
Hi Jakub,
Thanks for the explanation, it's getting a bit clearer, though I still have some
questions.
> __OPENMP_TARGET__ would be a linker plugin inserted symbol at the start of
> some linker plugin created data section, which would start with some header
> and then data.
> Say
> uleb128 number_
On 18/09/13 10:45, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 27, 2013 8:18 PM
>> To: Richard Earnshaw
>> Cc: Zhenqiang Chen; GCC Patches
>> Subject: Re: [PATCH 1/n] Add conditional compare support
>>
>
On Thu, Sep 19, 2013 at 12:58:28PM +0400, Michael V. Zolotukhin wrote:
> Thanks for the explanation, it's getting a bit clearer, though I still have
> some
> questions.
>
> > __OPENMP_TARGET__ would be a linker plugin inserted symbol at the start of
> > some linker plugin created data section, wh
Hi!
If sections construct has all section directives non-fallthru, as in
the attached testcase, including the case where they can be all or some of
them cancelled, we generate too large argument for GOMP_sections_start,
so if there are more threads than section directives (including the implicit
f
Jeff Law wrote:
>On 09/18/2013 11:17 AM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 18 Sep 2013, Jeff Law wrote:
>>
>>> On 09/18/2013 10:24 AM, Michael Matz wrote:
I'm irritated by the member name uglification (e.g. equiv_stack_
>with
trailing underscore). I know that's a certain sty
Hi,
Richard pointed out to me that we use speculative flag before we initialize
it.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 202739)
+++ ChangeLog (working copy)
@@ -1,3
I find it amazing to look at code I wrote in the past, the occasional
WTF always makes it worth it.
The code to manage the temporary expression & const/copies tables in
tree-ssa-dom.c around jump threading looks overly convoluted. In
particular the code reused an existing unwind point for t
On 18/09/13 20:37, Paul Pluzhnikov wrote:
Richard,
I am seeing ICEs in libstdc++ make check that I didn't see yesterday:
I'm also seeing these on arm and aarch64.
Kyrill
spawn /home/ppluzhnikov/Archive/gcc-svn/build/./gcc/xg++
-shared-libgcc -B/home/ppluzhnikov/Archive/gcc-svn/build/./gcc
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
> > I know, and I don't like it there either.
>
> Well, as Ian pointed out, it is in our recommended style guidelines and
> you'll find uses in the vec class as well.
As I said, yes; I also said those were pre-existing from the C times
already, so they
First attempt bounced from gcc-patches for some reason trying one
more time.
I'm looking at pulling ssa specific bits out of gimple.c so that it
doesn't require the ssa headers, and can concentrate on basic gimple
support. I stumbled across the "new" build interface in gimple.c
consisti
Hello,
This patch fixes the aforementioned PR by refusing FPUL_REG to be an
acceptable reg for any arithmetic_operand on TARGET_SH4. (This was a
strange SH4 singularity with regards to the SH family).
The only impacted insn is movsf_ie used for reg-fpreg transfers. So the
condition now mentions e
Ping~
Thanks,
Yufeng
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00774.html
On 09/10/13 18:12, Yufeng Zhang wrote:
Oops, now attach the correct patch and change log.
Thanks,
Yufeng
gcc/
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args):
Call aarch64_simd_expan
On Wed, Sep 18, 2013 at 1:39 PM, Jan Hubicka wrote:
>
> when generic model was introduced, the 32bit only CPUs was still common on the
> market. It would be stupid to tune 64bit code for CPUs that will never run
> it.
> We thus introduced two models - generic32 that was considering needs
> of 32
>
>
> decide_alg is being called from ix86_expand_movmem, from
> expand_builtin_memcpy, for the call at line 61 of go-append.c.
> __builtin_memcpy (n, a.__values, a.__count * element_size);
>
> I'm continuing to look.
Indeed it is problem of this patch - the issue is that generic64 had
du
On Thu, Sep 19, 2013 at 8:38 AM, Jan Hubicka wrote:
>>
>>
>> decide_alg is being called from ix86_expand_movmem, from
>> expand_builtin_memcpy, for the call at line 61 of go-append.c.
>> __builtin_memcpy (n, a.__values, a.__count * element_size);
>>
>> I'm continuing to look.
>
> Indeed it i
Maybe it'd be worth noting in changes.html that GCC now has the
ubsan...
Ok to apply?
--- www/htdocs/gcc-4.9/changes.html.mp 2013-09-19 16:54:32.113724993 +0200
+++ www/htdocs/gcc-4.9/changes.html 2013-09-19 17:07:05.418030738 +0200
@@ -38,6 +38,14 @@
AddressSanitizer, a fast memory err
Christian Bruel writes:
> Index: gcc/config/sh/sh.md
> ===
> --- gcc/config/sh/sh.md (revision 202699)
> +++ gcc/config/sh/sh.md (working copy)
> @@ -6894,9 +6894,11 @@ label:
> ;; reloading MAC subregs otherwise. For th
Hi Jakub,
Updated patch and my answers are below.
> The OpenMP standard has the omp_is_initial_device () function that can be
> used to query whether the code is offloaded or not. So I don't think we
> need to do the logging. For the device 257 hack we of course don't return
> that as true, but
Hi
Here is an updated version.
Changelog:
* gcc.dg/builtin-apply2.c: skip test on arm hardfloat ABI targets
* gcc.dg/tls/pr42894.c: Remove options, forcing -mthumb fails
with hardfloat, and test is not thumb-specific
* gcc,target/arm/thumb-ltu.c: Avoid test failure with
h
On Thu, Sep 19, 2013 at 03:23:21PM +0200, Michael Matz wrote:
> > I don't see anything in Trevor's work that requires jumping through
> > hoops.
>
> Me neither, from that perspective it's okay. It's merely that I doubt the
> value of any syntactic privatization like it's implemented in C++, you
Hi!
I've committed the following patch to trunk (except for the testcase, which
went to gomp-4_0-branch only), the tree-vect-stmts.c hunks as obvious,
inv_p has been used uninitialized for simd lane accesses, the omp-low.c
change to fix -Wuninitialized on simd code.
2013-09-19 Jakub Jelinek
The Go frontend was inconsistent in determining whether a struct could
use memcmp for the == operator. This could cause one package to decide
that it could use == and a package importing that one to determine that
it could not. The effect was an undefined symbol at link time. This
patch fixes th
Thanks, patch updated:
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 202725)
+++ gcc/Makefile.in (working copy)
@@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
auto-profile.o : auto-profile.c $(CON
ok.
David
On Thu, Sep 19, 2013 at 10:10 AM, Dehao Chen wrote:
> Thanks, patch updated:
>
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in (revision 202725)
> +++ gcc/Makefile.in (working copy)
> @@ -2960,7 +2960,7 @@ coverage.o
On Sep 19, 2013, at 6:23 AM, Michael Matz wrote:
> Me neither, from that perspective it's okay. It's merely that I doubt the
> value of any syntactic privatization like it's implemented in C++, you can
> #define it away, hence the compiler can't make use of that information for
> code generati
* lambda.c (maybe_add_lambda_conv_op): Don't check for instantiated
callop in the case of generic lambdas.
---
gcc/cp/lambda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index b04448b..2ffa7e0 100644
--- a/gcc/cp/lambda.c
+
Hi all,
The following series contain a few miscellaneous updates to generic lambdas and
implicit function templates.
[1/4]: Use translation-unit-global rather than parameter-list-local counter for
generic type names to facilitate nested implicit function
templates.
Using functio
* parser.c (add_implicit_template_parms): Set the canonical type of a
generic parameter to be that of the newly generated type such that it is
unique.
---
gcc/cp/parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7e9ade2.
* parser.c (make_generic_type_name): Spell generic type names ''
rather than '__GenN'.
---
gcc/cp/parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 148e2f2..a54496a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
Michael Matz writes:
> What's the benefit of reading and writing such noisy lines? :
>
> *out_mode = mode_;
> mode_ = GET_MODE_WIDER_MODE (mode_);
> count_++;
>
> The uglification merely makes code harder to write and read, it should be
> used in cases where you _don't_ want dev
On 09/19/2013 09:24 AM, Andrew MacLeod wrote:
I think this is of most use to ssa passes that need to construct code
snippets, so I propose we make this ssa specific and put it in
tree-ssa.c (renaming it ssa_build_assign), *OR* we could leave it
general purpose and put it in its own set of fi
* parser.c (make_generic_type_name): Use static count rather than
parameter and ...
(add_implicit_template_parms): ... propagate interface change here.
---
gcc/cp/parser.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/gcc/cp
__attribute__((used)) is meant to be used only on VAR_DECLs that are
TREE_STATIC, but the documentation does not say that. Thus fixed.
Ok?
2013-09-19 Marek Polacek
PR other/58467
* doc/extend.texi: Document that attribute used is meant to be used
on variables with sta
I merged revision 202754 from the GCC 4.8 branch to the gccgo branch.
Ian
this looks fine to me.
On 09/19/2013 02:56 PM, Richard Sandiford wrote:
It turns out that gcc20's version of binutils is too old for the LTO plugin,
so the tests I'd been running hadn't exercised it. This patch fixes a
regression that Kenny pointed out.
The problem was that build_int_cst and bu
This patch fixes two issues:
a) It could happen that no code change has happened. In that case, the
one freed an expression which still should be used.
b) In my previous patch, I used a pointer assignment to the temporary of
the LHS (after its allocation) [only if the LHS was initially
unass
>
> I did some experiment with code alignment. I found
> -fno-align-loops -fno-align-functions -fno-align-jumps
> had no negative performance impacts on current
> Intel processors while reducing code sizes by 1-2%.
> Should we use
>
> {&generic_cost, 0, 0, 0, 0, 0},
>
> instead?
Good, revisitin
Looks good.
David
On Thu, Sep 19, 2013 at 1:15 PM, Dehao Chen wrote:
> This patch sets cgraph_node count during AutoFDO annotation, otherwise
> execute_fixup_cfg will clear all the BB counts.
>
> bootstrapped and passed regression test.
>
> OK for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index
It turns out that gcc20's version of binutils is too old for the LTO plugin,
so the tests I'd been running hadn't exercised it. This patch fixes a
regression that Kenny pointed out.
The problem was that build_int_cst and build_int_cst_type were using
the signedness of the type to decide how the H
This patch sets cgraph_node count during AutoFDO annotation, otherwise
execute_fixup_cfg will clear all the BB counts.
bootstrapped and passed regression test.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
-
This patch complete the last two parts of the whole regex module, but
two problems left:
1) regex_traits<>::transform_primary [28.7.7]. I don't know how to
implement it correctly. Can anyone give some advice?
2) Digraph support. Is it need to be done, since the standard doesn't
specify it?
Teste
Christian Bruel wrote:
> This patch fixes the aforementioned PR by refusing FPUL_REG to be an
> acceptable reg for any arithmetic_operand on TARGET_SH4. (This was a
> strange SH4 singularity with regards to the SH family).
>
> The only impacted insn is movsf_ie used for reg-fpreg transfers. So th
On Thu, Sep 19, 2013 at 7:36 AM, Marek Polacek wrote:
> __attribute__((used)) is meant to be used only on VAR_DECLs that are
> TREE_STATIC, but the documentation does not say that. Thus fixed.
>
> Ok?
>
> 2013-09-19 Marek Polacek
>
> PR other/58467
> * doc/extend.texi: Document
Christian Bruel wrote:
> (define_insn "*mov_reg_reg"
> - [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
> - (match_operand:QIHI 1 "register_operand" "r,*z,m"))]
> - "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)"
> + [(set (match_operand:QIHI 0 "general_movdst_operand" "=r,
> Christian Bruel wrote:
>> (define_insn "*mov_reg_reg"
>> - [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
>> -(match_operand:QIHI 1 "register_operand" "r,*z,m"))]
>> - "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)"
>> + [(set (match_operand:QIHI 0 "general_movdst_operand
This patch has caused 6 new libstdc++ failures on AIX. All look like:
/home/dje/src/src/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:49:1:
internal compiler error: in build_polynomial_chrec, at
tree-chrec.h:148
}
- David
I did not catch this in the last review. The cleanup CFG should be
done before afdo_annotate_cfg and just after call statement fixup.
Otherwise the cfg cleanup will zero out all profile counts. After
moving this up, you don't need the follow up patch which sets the
cgraph node's count -- that shoul
Hi Janus, hi all,
On August 15, 2013, Janus Weil wrote:
Hi Mikael,
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
This looks good to me
but I let Tobias have the final word as he
expressed some concerns in the PR audit trail.
Sorry for the very belated replay. I played with the pat
54 matches
Mail list logo
