Ping?
Thanks!
-Zhenqiang
On 22 May 2014 17:52, Zhenqiang Chen wrote:
> On 21 May 2014 20:43, Steven Bosscher 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
>>> test case tends to check a peepho
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 reje
Hi!
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski wrote:
> On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres
> wrote:
> > r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
> >
> > ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in
> > th
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]
Missing patch.
On Wed, May 28, 2014 at 3:02 PM, bin.cheng 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
> computed out
Hi!
On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha 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 for powerpc*-*-
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 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 expected sign of the
> quo
> 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
> w
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>> On May 26, 2014, at 2:22 AM, FX wrote:
>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>> >> compiler is clang-based). Since PR 61146 was resolved as INV
Richard Biener writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>>> On May 26, 2014, at 2:22 AM, FX wrote:
>>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>>> > compiler is clang-based). Since
On May 28, 2014, at 1:03 AM, 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 funct
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 to
>> * 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 tail-s
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:1
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 w
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 x86_64-unknown-linux-gn
On Wed, May 28, 2014 at 9:30 AM, Richard Earnshaw 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 support it.
>
>
On Wed, May 28, 2014 at 10:24 AM, FX 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 approv
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
>>> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
On May 26, 2014, at 2:22 AM, FX wrote:
>> This causes GCC bootstrap to fail on D
Jaydeep Patil 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 (get_attr_type (in_insn) ==
On Wed, May 28, 2014 at 11:40 AM, Richard Biener
wrote:
> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2
On Wed, May 28, 2014 at 11:02 AM, Bernd Edlinger
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 to retain
Richard Biener writes:
> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
> wrote:
>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump w
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 10:24 AM, FX 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 que
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 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 COMPLEX_CST). That was confusing th
On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>> >> Yeah, a portable (C and C++) static assert would be nice. And also
>> >> pushing
>> >> this to gmp then.
>> >>
>> >> In t
On Wed, May 28, 2014 at 12:03 PM, Richard Biener
wrote:
> On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
>> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>>> >> Yeah, a portable (C and C++) static assert would be nice. An
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__ * 10
> 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
wrote:
> Richard Biener writes:
>> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>> wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek
... 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 211
On Wed, May 28, 2014 at 12:00 PM, Bernd Schmidt wrote:
> On 05/27/2014 04:57 PM, Richard Biener wrote:
>>
>> On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt
>> wrote:
>>>
>>> I noticed that string constants built by the Fortran frontend don't set
>>> TREE_READONLY for STRING_CST (and subsequently
On Wed, May 28, 2014 at 12:17 PM, Eric Botcazou 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
> 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 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 Botcazou
Does the following fix ok?
2014-05-28 Evgeny Stupachenko
* 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
--- a/gcc/testsuite/gcc.dg/vect/pr52252-l
On Wed, May 28, 2014 at 02:51:57PM +0400, Evgeny Stupachenko wrote:
> Does the following fix ok?
>
> 2014-05-28 Evgeny Stupachenko
>
>* 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/
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 o
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 } */
-/* { d
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 -ms
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 R
Mike Stump writes:
> On May 27, 2014, at 1:04 AM, Rainer Orth
> 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 reviewer, but,
> the changes are usual and
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
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 b_2 ha
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 x86
> 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-darwi
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 compil
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 bootst
On Wed, May 28, 2014 at 3:15 PM, FX 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 right now,
On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 3:15 PM, FX 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.
> >
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 Sandiford writes:
Richard Sandiford writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested that
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 t
I have reverted the following for now.
Richard.
2014-05-28 Richard Biener
Revert
2014-05-28 Richard Biener
* hwint.h (HOST_WIDE_INT_PRINT_*): Define in terms of PRI*64.
Index: gcc/hwint.h
===
*** gcc
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)’:
../../trunk/
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 [mailto:philipp.toms...@theobrom
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 duplicati
On 28 May 2014, at 16:25 , Gopalasubramanian, Ganesh
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 upstreamed.
Sorry for the delay
On 27/05/14 17:31, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 27/05/14 17:09, Richard Sandiford wrote:
>>> Richard Earnshaw 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 15:08, Richard
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.
> 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 x86_64-
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
wrote:
> Dmitry,
> You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
> http://llvm.org/viewvc/llvm-project?view=revision&revision=173332
> Do you mind to change it to atomic_uintptr_t?
> There is of course a chance of overflow
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
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 X", class_of_this_parm is "struct X<
>".
Right, it needs to be the substituted this para
On Wed, May 28, 2014 at 1:43 AM, Kai Tietz 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. Nevertheless it
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 916172d3d6e115b94f1a902aebca4
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
* lto/lto-partition.c (add_symbol_to_partition_1): Keep orig
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 X", class_of_this_parm is "struct X<
>"
On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
2014-05-19 Iain Sandoe
Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_set_current_function): Choose
function alignment once the current mode is known.
gcc/testsuite/
* gcc.target
Daveed from EDG pointed out this bug to me.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 912eae71d30adf6c07dbdf1b4741fd7ffd5a05ff
Author: Jason Merrill
Date: Wed May 28 11:50:50 2014 -0400
* pt.c (tsubst) [ARRAY_TYPE]: Check for array of array of unknown
bound.
diff --git
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 issues
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 mys
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)
unsigned SI
size
unit size
align 32 symtab 45 alias set 3 canonical type 700f5840
pointer_to_this>
BLK
On May 28, 2014, at 7:27 AM, Richard Earnshaw 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 of builtins to:
On Wed, May 28, 2014 at 5:33 PM, Marat Zakirov 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 size.
>
> Ins
Sandra Loosemore writes:
> On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
>>
>> 2014-05-19 Iain Sandoe
>> Catherine Moore
>> Sandra Loosemore
>>
>> gcc/
>> * config/mips/mips.c (mips_set_current_function): Choose
>> function alignment once the current mode
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 a
Thanks for the review.
Jeff Law 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.
>>
>> O
> On 05/27/14 23:20, Jan Hubicka wrote:
> >>
> >>here we have decl and its local alias:
> >>(gdb) p debug_tree (sect->named.decl)
> >> >> type >> type >> 700f57e0>
> >> unsigned SI
> >> size
> >> unit size
> >> align 32 symtab 45 alias s
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: w
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: compil
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 disabled/e
>
> 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 s_f
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 ++
gcc/testsuite/c-
- 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 CONS
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 ali
Richard Biener writes:
> The following changes the configury to insist on [u]int64_t being
> available and removes the very old __int64 case. Autoconf doesn't
> check for it, support came in via a big merge in Dec 2002, r60174,
> and it was never used on the libcpp side until I fixed that with
>
On Thu, Mar 27, 2014 at 10:33 AM, James Greenhalgh
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 grab_cache_page_write_begin(unsigned flags, unsign
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 (
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")
{
o
> Hi!
>
> On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski wrote:
> > On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres
> > wrote:
> > > r210901 breaks bootstrap on targets not supporting strnlen, e.g.,
> > > darwin10.
> > >
> > > ../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was
> Any update?
>
> I've managed to generate a simple test case from
> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
> ARM that Ramana has reported previously:
>
>
> template struct char_traits;
>
> template
> class basic_ios
> {
> };
>
> template >
> class basic_istream : v
On Wed, May 28, 2014 at 03:54:58PM -0600, Jeff Law wrote:
> >Why not get rid of all the above 4 lines and just keep:
> >
> >> return CONSTANT_P (op);
> >
> >? CONST matches CONSTANT_P, and what is inside of CONST should be
> >fine, and (plus (symbol_ref) (const_int)) not surrounded by CONST
> >i
1 - 100 of 123 matches
Mail list logo
