On 22/05/14 22:18, Richard Earnshaw wrote:
On 22/05/14 00:44, Kugan wrote:
Compiling some applications with -mgeneral-regs-only produces better
code (runs faster) compared to not using it. The difference here is that
when -mgeneral-regs-only is not used, floating point register are also
Hi Richard,
Please refer to the attached patch files.
gcc-p5600-noMSA.patch
TARGET_P5600 has been removed
gcc-p5600-noMSA-msched-weight.patch
Per-instruction structure has been created to store both GP and VEC pressures.
We are using size of a mode to differentiate GP and VEC registers.
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems (whose system compiler
is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
it’s the right call,
Ping?
Thanks!
-Zhenqiang
On 22 May 2014 17:52, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
On 21 May 2014 20:43, Steven Bosscher stevenb@gmail.com wrote:
On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
Hi,
The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
Hi,
I was surprised that GCC didn't support addressing modes like
[REG+OFF]/[REG_REG] for instructions ldr/str in vectorization scenarios.
The generated assembly is bad since all address expressions have to be
computed outside of memory reference. The root cause is because aarch64
effectively
Hi!
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen'
On Tue, May 27, 2014 at 05:04:52PM -0500, Peter Bergner wrote:
On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
It's being called form basically two files:
[bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find .
Missing patch.
On Wed, May 28, 2014 at 3:02 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
I was surprised that GCC didn't support addressing modes like
[REG+OFF]/[REG_REG] for instructions ldr/str in vectorization scenarios.
The generated assembly is bad since all address expressions have to be
Hi!
On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha asolo...@gmx.com wrote:
Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets.
I hit this, too.
The
proposed patch disables building libsanitizer
Hi DJ,
This is OK. Thanks! Do you need someone to commit it for you?
Thanks, I can commit these changes.
+MULTILIB_DIRNAMES = g10 64-bit-double
I assume this should be doubles not double though...
Yes, will make that change and commit it.
Best Regards,
Kaushik
On Tue, May 27, 2014 at 10:29 PM, Eric Botcazou ebotca...@adacore.com wrote:
This is an old bug in div_and_round_double for ROUND_DIV_EXPR: when the code
detects that it needs to adjust the quotient, it needs to decide whether it
increases or decreases it by 1. This only depends on the
You shouldn't need to declare __builtin_* functions anyway. And if a
function can be represented directly with GNU C vector extensions, it's
preferred to implement it that way inline in the header rather than having
built-in functions duplicating existing GNU C functionality. (Look at
what
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems (whose system
compiler is clang-based). Since PR
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems
On May 28, 2014, at 1:03 AM, Matthew Fortune matthew.fort...@imgtec.com wrote:
You shouldn't need to declare __builtin_* functions anyway. And if a
function can be represented directly with GNU C vector extensions, it's
preferred to implement it that way inline in the header rather than
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can support it.
I guess that what is happening is that we see we have Neon, so start
* rtl.h (set_for_reg_notes): Declare.
* emit-rtl.c (set_for_reg_notes): New function.
(set_unique_reg_note): Use it.
* optabs.c (add_equal_note): Likewise.
This is fine.
checked-in as revision 210998.
Thanks Jeff :-)
Olivier
Hi,
I modified prior patch so that it uses the new predicate sibcall_memory_operand
to extend sibcall_insn_operand.
Just one change in i386.c remains about x86_output_mi_thunk. Later one isn't
pretty much essential. Nevertheless it makes
code equivalent to none-memory-case for potential
Ping^3
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Monday, May 19, 2014 2:40 PM
To: Bin Cheng
Cc: Richard Earnshaw; gcc-patches List
Subject: Re: [PATCH ARM] Improve ARM memset inlining
Ping^2
Thanks,
bin
On Mon, May 12, 2014 at 11:17 AM,
Hi,
But the coment previously read
/* A constant address in TO_RTX can have VOIDmode, we must not try
to call force_reg for that case. Avoid that case. */
and you are removing that check. So I guess you want to retain
GET_MODE (XEXP (to_rtx, 0)) != VOIDmode
or investigate why we don't
This fixes PR61335 - symbolic range propagation in VRP is so weak
that we didn't notice this very old serious bug ... compare_values
can return don't know which is -2, but PHI node visiting handles
it the same as -1 (less than...). Oops.
Bootstrap and regtest running on
On Wed, May 28, 2014 at 9:30 AM, Richard Earnshaw rearn...@arm.com wrote:
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can
On Wed, May 28, 2014 at 10:24 AM, FX fxcoud...@gmail.com wrote:
Yeah, a portable (C and C++) static assert would be nice. And also pushing
this to gmp then.
In the meantime I see nothing wrong in merging from GMP.
One question, one comment:
1. can I count your “I see nothing wrong” as an
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
On May 26, 2014, at 2:22
Jaydeep Patil jaydeep.pa...@imgtec.com writes:
Please refer to the attached patch files.
gcc-p5600-noMSA.patch
TARGET_P5600 has been removed
Sorry, noticed one other thing:
+bool
+mips_fmadd_bypass (rtx out_insn, rtx in_insn)
+{
+ int dst_reg, src_reg;
+
+ gcc_assert
On Wed, May 28, 2014 at 11:40 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek ja...@redhat.com wrote:
On
On Wed, May 28, 2014 at 11:02 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi,
But the coment previously read
/* A constant address in TO_RTX can have VOIDmode, we must not try
to call force_reg for that case. Avoid that case. */
and you are removing that check. So I guess you want
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at 11:40 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
On Wed, May 28, 2014 at 10:24 AM, FX fxcoud...@gmail.com wrote:
Yeah, a portable (C and C++) static assert would be nice. And also pushing
this to gmp then.
In the meantime I see nothing wrong in merging from GMP.
One
On May 27, 2014, at 5:27 PM, Nathan Sidwell wrote:
ok
Great! Committed as rev 211011.
Thanks Nathan :-)
Olivier
On 05/27/2014 04:57 PM, Richard Biener wrote:
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt ber...@codesourcery.com wrote:
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to
set it for
On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
On Wed, May 28, 2014 at 10:24 AM, FX fxcoud...@gmail.com wrote:
Yeah, a portable (C and C++) static assert would be nice. And also
pushing
this to gmp
On Wed, May 28, 2014 at 12:03 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
On Wed, May 28, 2014 at 10:24 AM, FX fxcoud...@gmail.com wrote:
Yeah, a
On Wed, May 28, 2014 at 12:07:41PM +0200, Richard Biener wrote:
#ifndef GCC_VERSION
+/* Some compilers pretend to be GCC, even when they are not. */
+#if defined(__clang__) || defined(__INTEL_COMPILER)
+#define GCC_VERSION 0
+#else
#define GCC_VERSION (__GNUC__ * 1000 +
I suppose you also install on branches?
No plan to do so since this isn't a regression, unless you insist. :-)
--
Eric Botcazou
On Wed, May 28, 2014 at 11:49 AM, Richard Sandiford
rsand...@linux.vnet.ibm.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Wed, May 28, 2014 at 11:40 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
... turns out, I can avoid fiddling with in_decl (which, I realized, is
meant to be used for diagnostics). The below version also passes testing.
Thanks,
Paolo.
/
Index: cp/pt.c
===
--- cp/pt.c (revision
On Wed, May 28, 2014 at 12:00 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 05/27/2014 04:57 PM, Richard Biener wrote:
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY
On Wed, May 28, 2014 at 12:17 PM, Eric Botcazou ebotca...@adacore.com wrote:
I suppose you also install on branches?
No plan to do so since this isn't a regression, unless you insist. :-)
Well, a wrong-code bug plus a very obvious fix certainly qualifies.
Richard.
--
Eric Botcazou
On Wed, May 28, 2014 at 12:03:39PM +0200, Richard Biener wrote:
Any other compilers that define __GNUC__?
Every one I guess. ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.
For ICC it seems to depend on the ICC version, newer ICC versions
report newer __GNUC_MINOR__.
That said, ICC doesn't
Well, a wrong-code bug plus a very obvious fix certainly qualifies.
Fine with me, onto which branch(es) do you want me to put it?
--
Eric Botcazou
On Wed, May 28, 2014 at 12:23 PM, Eric Botcazou ebotca...@adacore.com wrote:
Well, a wrong-code bug plus a very obvious fix certainly qualifies.
Fine with me, onto which branch(es) do you want me to put it?
Where you have tested it already, no need to spend extra cycles.
Richard.
--
Eric
Does the following fix ok?
2014-05-28 Evgeny Stupachenko evstu...@gmail.com
* gcc.dg/vect/pr52252-ld.c: Fix target and options for the test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..57e8468 100644
---
On Wed, May 28, 2014 at 02:51:57PM +0400, Evgeny Stupachenko wrote:
Does the following fix ok?
2014-05-28 Evgeny Stupachenko evstu...@gmail.com
* gcc.dg/vect/pr52252-ld.c: Fix target and options for the test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
missed some line tails. Correct patch below:
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..57e8468 100644
--- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
@@ -1,6 +1,6 @@
/* { dg-do compile }
On 27/05/14 04:03, Jan Hubicka wrote:
Jan,
The IPA patch broke bootstrap on AIX with multiple failures.
The tail of the build log is attached.
Thanks,
I will give it a try at gcc111, good to have reproducible testcase.
FWIW, I'm seeing the same error when building arm-none-linux-gnueabihf
On Wed, May 28, 2014 at 12:18:13PM +0200, Richard Biener wrote:
ATM we get the testing coverage for i686 and ppc32 hosts. So TBH I'd
prefer to keep it simple and just bump the version number.
Works for me (though see Jakubs idea on the other thread, so please
wait until we settled on a
Ok. Fixed. Test still passes on x86:
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
index 6e3cb52..e37b177 100644
--- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
@@ -1,6 +1,5 @@
/* { dg-do compile } */
-/* {
On Wed, May 28, 2014 at 03:33:15PM +0400, Evgeny Stupachenko wrote:
Ok. Fixed. Test still passes on x86:
Ok.
--- a/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-ld.c
@@ -1,6 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -g -ftree-vectorize -mssse3
The following fixes bogus folding (introducing signed overflow)
for the X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 transform
where we let through a sign-change of the remaining constant operand.
Fixed as follows, bootstrap and regtest running on
x86_64-unknown-linux-gnu.
Richard.
2014-05-28
Mike Stump mikest...@comcast.net writes:
On May 27, 2014, at 1:04 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
It's been a week since I've submitted the patch, so far having received
approval for the testsuite parts only.
So, I read the doc bits, and they look fine. I’m not a doc
The following patch makes the VRP dump less vertical space noisy.
It also makes handling of the two forms of copies,
a_1 = b_2;
and
a_1 = PHI b_2
behave more similar by also copying VR_UNDEFINED ranges in the
first case and by creating a [b_2, b_2] symbolic range in
the second case (if
Hi,
The patch introduces alternative way of permutations for load groups
of size 2 and 3 which should be faster on architectures with low
parallelism.
The patch gives 2 times gain on Silvermont to the test from PR52252
(in addition to already committed 3 times gain).
Patch passes bootstrap on
After lengthy IRC discussions, what Richard and I can live with is
!defined(__clang__) in this particular case that uses longlong.h
in GCC sources, with a comment why.
I’ll test this patch and commit if there is no problem. But right now, current
trunk doesn’t build on x86_64-apple-darwin
Ping.
Test is modified according to the fix in the test for loads.
diff --git a/gcc/testsuite/gcc.dg/vect/pr52252-st.c
b/gcc/testsuite/gcc.dg/vect/pr52252-st.c
new file mode 100644
index 000..e7161f7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr52252-st.c
@@ -0,0 +1,21 @@
+/* { dg-do
Hi all,
Here's a patch for optional Asan instrumentation of inline assembly.
This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
of arguments with memory constraints (m, o, etc.) with fixed size.
Instrumentation is turned off by default.
This was successfully
On Wed, May 28, 2014 at 3:15 PM, FX fxcoud...@gmail.com wrote:
After lengthy IRC discussions, what Richard and I can live with is
!defined(__clang__) in this particular case that uses longlong.h
in GCC sources, with a comment why.
I’ll test this patch and commit if there is no problem. But
On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
On Wed, May 28, 2014 at 3:15 PM, FX fxcoud...@gmail.com wrote:
After lengthy IRC discussions, what Richard and I can live with is
!defined(__clang__) in this particular case that uses longlong.h
in GCC sources, with a comment
The patch also fixes the arm-none-eabi build failures I've seen.
Thanks,
Yufeng
On 05/27/14 16:07, Richard Sandiford wrote:
Richard Sandifordrdsandif...@googlemail.com writes:
Richard Sandifordrsand...@linux.vnet.ibm.com writes:
Does the following patch help?
Bah, it won't of course: %i1
On Wed, May 28, 2014 at 04:00:32PM +0200, Jakub Jelinek wrote:
Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
or not, but using PRIx64 etc. unconditionally is just wrong, either
HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
not, and then
I have reverted the following for now.
Richard.
2014-05-28 Richard Biener rguent...@suse.de
Revert
2014-05-28 Richard Biener rguent...@suse.de
* hwint.h (HOST_WIDE_INT_PRINT_*): Define in terms of PRI*64.
Index: gcc/hwint.h
On Tue, 27 May 2014, Mike Stump wrote:
So, I read the doc bits, and they look fine. I’m not a doc reviewer,
but, the changes are usual and customary for a port, and trivial.
Yes, and I'd like to emphasize this point: Just because a file
matches *.texi doesn't mean that ports, middle, front,
I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do
similar errors happen elsewhere?
I don’t think you can cast to uint64_t, as host wide int might be some other
type, no?
There are others:
../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’:
Hi Philipp,
These changes look good to me.
We'll try them out on the benchmarks that caused us to add prefetching in the
first place.
If you are OK, I would like to get these changes upstreamed.
-Ganesh
-Original Message-
From: Dr. Philipp Tomsich
On 28/05/14 09:03, Matthew Fortune wrote:
You shouldn't need to declare __builtin_* functions anyway. And if a
function can be represented directly with GNU C vector extensions, it's
preferred to implement it that way inline in the header rather than having
built-in functions duplicating
On 28 May 2014, at 16:25 , Gopalasubramanian, Ganesh
ganesh.gopalasubraman...@amd.com wrote:
Hi Philipp,
These changes look good to me.
We'll try them out on the benchmarks that caused us to add prefetching in
the first place.
If you are OK, I would like to get these changes
On 27/05/14 17:31, Richard Sandiford wrote:
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 17:09, Richard Sandiford wrote:
Richard Earnshaw rearn...@arm.com writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+TREE_CODE (t) == METHOD_TYPE
+TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could be nested as a
template argument. And
After lengthy IRC discussions, what Richard and I can live with is
!defined(__clang__) in this particular case that uses longlong.h
in GCC sources, with a comment why.
If we get too many of these workarounds, we should reconsider.
Committed as revision 211023, after bootstrap on
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Dmitry,
You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
http://llvm.org/viewvc/llvm-project?view=revisionrevision=173332
Do you mind to change it to atomic_uintptr_t?
There is of
Hi,
On 05/28/2014 05:14 PM, Jason Merrill wrote:
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+ TREE_CODE (t) == METHOD_TYPE
+ TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could be
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to struct Xint, class_of_this_parm is struct X
template-parameter-1-1 .
Right, it needs to be the
On Wed, May 28, 2014 at 1:43 AM, Kai Tietz kti...@redhat.com wrote:
Hi,
I modified prior patch so that it uses the new predicate
sibcall_memory_operand to extend sibcall_insn_operand.
Just one change in i386.c remains about x86_output_mi_thunk. Later one isn't
pretty much essential.
We were getting confused by applying LOOKUP_NO_TEMP_BIND to the nested
list-initializations, which is wrong; in aggregate initialization the
elements are copy-initialized without regard to the enclosing context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
Hi,
This patch keeps instrumented and original versions together and preserve
tranparent alias chain during symbol name privatization.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2013-05-28 Ilya Enkovich ilya.enkov...@intel.com
* lto/lto-partition.c
Hi,
On 05/28/2014 05:49 PM, Jason Merrill wrote:
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to struct Xint, class_of_this_parm is struct X
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe i...@codesourcery.com
Catherine Moore c...@codesourcery.com
Sandra Loosemore san...@codesourcery.com
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
function alignment once
Daveed from EDG pointed out this bug to me.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 912eae71d30adf6c07dbdf1b4741fd7ffd5a05ff
Author: Jason Merrill ja...@redhat.com
Date: Wed May 28 11:50:50 2014 -0400
* pt.c (tsubst) [ARRAY_TYPE]: Check for array of array of unknown
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign myself, for now,
and work on some other pending
Hi,
On 05/28/2014 06:33 PM, Jason Merrill wrote:
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign
On 05/28/2014 01:43 AM, Kai Tietz wrote:
+ if (GET_CODE (op) == CONST)
+op = XEXP (op, 0);
+ return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
without having to look through the CONST at all.
Otherwise this looks ok.
r~
On 05/27/14 23:20, Jan Hubicka wrote:
here we have decl and its local alias:
(gdb) p debug_tree (sect-named.decl)
var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
typearray_type 70dd8840
typepointer_type 700f5840 __vtbl_ptr_type typefunction_type 700f57e0
On May 28, 2014, at 7:27 AM, Richard Earnshaw rearn...@arm.com wrote:
Speed of implementation. We're gradually replacing these with proper
builtins, but that takes a lot more work.
As an owner of a port with more builtins that yours, I can offer a
technological solution to reduce the cost
On Wed, May 28, 2014 at 5:33 PM, Marat Zakirov m.zaki...@samsung.com wrote:
Hi all,
Here's a patch for optional Asan instrumentation of inline assembly.
This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
of arguments with memory constraints (m, o, etc.) with fixed
Sandra Loosemore san...@codesourcery.com writes:
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe i...@codesourcery.com
Catherine Moore c...@codesourcery.com
Sandra Loosemore san...@codesourcery.com
gcc/
* config/mips/mips.c
On 05/28/14 11:22, Richard Henderson wrote:
On 05/28/2014 01:43 AM, Kai Tietz wrote:
+ if (GET_CODE (op) == CONST)
+op = XEXP (op, 0);
+ return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
without having to look through the CONST
Thanks for the review.
Jeff Law l...@redhat.com writes:
On 05/26/14 13:21, Richard Sandiford wrote:
If we're going to change it, then clearly the docs need to change and
ideally we'd statically check the port's constraints during the build
process to ensure they meet the tighter definition.
On 05/27/14 23:20, Jan Hubicka wrote:
here we have decl and its local alias:
(gdb) p debug_tree (sect-named.decl)
var_decl 70f7d060 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
typearray_type 70dd8840
typepointer_type 700f5840 __vtbl_ptr_type typefunction_type
Hi again,
On 05/28/2014 07:06 PM, Paolo Carlini wrote:
(In case I would have also to double check something weird I was
seeing if the injection happens for all method types...)
In the meanwhile I investigated the reason of all those regressions I
was seeing when injecting in all METHOD_TYPEs:
Honza,
I try to build this configuration:
../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64
--target=arm-linux-gnueabihf --enable-languages=c,c++,fortran,ada
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
but make fails:
libtool:
While working on patches to speed up the handling of constraints,
I hit some behaviour in ira_get_dup_out_num that looked unintentional:
- the check for output operands was part of the !ignored_p condition
so would be skipped if the first alternative is disabled/excluded.
- the first
When I debug and set a breakpoint in varasm.c line 314 it looks as if
the flag SECTION_RELRO is different. This flag is set in
I see, it is the same message, but different reason from AIX.
categorize_decl_for_section where it depends on
TREE_CODE(decl), and if it is a VAR_DECL also on
In two places when a struct demangle_component is of type
DEMANGLE_COMPONENT_FIXED_TYPE we fall back to accessing the default
s_binary member of the union rather than the s_fixed member. This is
incorrect and can cause the demangler to crash.
In d_dump I've changed the code to only access the
Hi!
Does that look appropriate (for trunk)?
gcc/c/c-parser.c | 2 +-
gcc/c/c-typeck.c | 2 ++
gcc/cp/parser.c | 2 +-
gcc/cp/semantics.c| 2 ++
- Original Message -
On 05/28/14 11:22, Richard Henderson wrote:
On 05/28/2014 01:43 AM, Kai Tietz wrote:
+ if (GET_CODE (op) == CONST)
+op = XEXP (op, 0);
+ return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
Honza,
I'm glad that you're making progress.
David, this looks like a bug in the AIX target output macros. I get:
.set
_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si.localalias.69,_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si
(this is correct since localalias is really an alias)
On Thu, Mar 27, 2014 at 10:33 AM, James Greenhalgh
james.greenha...@arm.com wrote:
Hi,
Next, comparisons, flag setting operations and IF_THEN_ELSE.
Tested on aarch64-none-elf.
Ok for stage 1?
This broke building the Linux kernel.
A simple testcase:
unsigned
On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
Yes, I missed the plus-part.
I am just running bootstrap with regression testing for altering predicate to:
(define_predicate sibcall_memory_operand
(match_operand 0 memory_operand)
{
op = XEXP (op, 0);
if (GET_CODE (op)
On 05/28/14 15:52, Jakub Jelinek wrote:
On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
Yes, I missed the plus-part.
I am just running bootstrap with regression testing for altering predicate to:
(define_predicate sibcall_memory_operand
(match_operand 0 memory_operand)
{
op =
Hi!
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g.,
darwin10.
../../_clean/gcc/lto-cgraph.c:976:68:
1 - 100 of 122 matches
Mail list logo
