On Thu, 2013-09-19 at 08:15 +0900, Kaz Kojima wrote:
Christian Bruel christian.br...@st.com 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
On 2013-09-18 19:37, Ralf Corsépius wrote:
On 09/17/2013 08:12 PM, Joel Sherrill wrote:
Committed to the head.
Is this too radical to also go on the 4.8 branch?
We would need to discuss it on the RTEMS side but it
only impacts us if the multilib is there for sparc-elf
on 4.8.
Not quite. The
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
Hi Kaz, Oleg,
On 09/19/2013 01:15 AM, Kaz Kojima wrote:
Christian Bruel christian.br...@st.com 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
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,
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
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 christian.br...@st.com wrote:
(!can_create_pseudo_p () REG_P (operands[0]) REG_P (operands[1]))
is necessary ?
It looks an another hack to allow
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.
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
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 Tue, Aug
Jeff Law l...@redhat.com 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 style to
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
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
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
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
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
On Wed, Sep 18, 2013 at 1:39 PM, Jan Hubicka hubi...@ucw.cz 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
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
dummy
On Thu, Sep 19, 2013 at 8:38 AM, Jan Hubicka hubi...@ucw.cz 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 is
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 @@
liAddressSanitizer, a fast memory
Christian Bruel christian.br...@st.com 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
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
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 can
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
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
ok.
David
On Thu, Sep 19, 2013 at 10:10 AM, Dehao Chen de...@google.com wrote:
Thanks, patch updated:
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 202725)
+++ gcc/Makefile.in (working copy)
@@ -2960,7 +2960,7 @@
On Sep 19, 2013, at 6:23 AM, Michael Matz m...@suse.de 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
* 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
* 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
* parser.c (make_generic_type_name): Spell generic type names 'autoN'
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
+++
Michael Matz m...@suse.de 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_
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
* 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
__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 pola...@redhat.com
PR other/58467
* doc/extend.texi: Document that attribute used is meant to be used
on
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
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
Looks good.
David
On Thu, Sep 19, 2013 at 1:15 PM, Dehao Chen de...@google.com 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
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
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?
Tested
Christian Bruel christian.br...@st.com 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
On Thu, Sep 19, 2013 at 7:36 AM, Marek Polacek pola...@redhat.com 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 pola...@redhat.com
PR other/58467
Christian Bruel christian.br...@st.com wrote:
(define_insn *movmode_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
Christian Bruel christian.br...@st.com wrote:
(define_insn *movmode_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
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
52 matches
Mail list logo
