Hi all,
As discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 only a
subset of libubsan should be built with RTTI support. Attached patch
adds custom build rules for relevant files.
-Y
diff --git a/libsanitizer/ubsan/Makefile.am b/libsanitizer/ubsan/Makefile.am
index e98984a..eaab
On 2013.11.20 at 15:43 +0100, Markus Trippelsdorf wrote:
> On 2013.11.20 at 14:41 +0100, Paolo Bonzini wrote:
> > Note that you need to regenerate all users of libtool.m4. Please post a
> > patch _with_ the regeneration so that whoever applies it won't screw up.
Ping.
Can you please have look, Pa
On Fri, Nov 22, 2013 at 10:54:16AM +0100, Marek Polacek wrote:
> Hi!
>
> Working virtually out of Pago Pago.
>
> The following is the implementation of the signed integer overflow
> checking for the UndefinedBehaviorSanitizer. I wrote some of the
> generic bits; Jakub did the i?86 handlind/optab
Here is the patch series that had been posted in Sep that is aimed to
isolate the Android support from targets that actually don't have that
support (We discussed the need of it with Jakub here
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html):
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg0
Hi Richard,
> I don't think it's good to have long lists of targets on generic tests.
> Can we factor this out into a target-supports option?
I have updated the patch as per your recommendation. Please let me
know if it is fine.
2013-11-26 Venkataramanan Kumar
* configure.ac (gcc_cv_
Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
Done.
Thanks for fixing Richard's and Jakub's comments and parts of mine.
+have the same meaning as described in @option{fvect-cost-model} and by
+default a cost model defined with @option{fvect-cost-model} is used.
As mentioned before, pleae a
Ping?
Thanks!
-Zhenqiang
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
> Sent: Friday, November 08, 2013 10:51 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan
> Subject: [PATCH, ARM, testcase] S
> I think you are right, this flag is no longer necessary, and removing
> this code path would simplify everything. Therefore I'd like to propose
> to remove the "keep_aligning" parameter of get_inner_reference as
> a split-out patch.
>
> Boot-strapped (with languages=all,ada,go) and
> regression-
On Mon, 25 Nov 2013, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 11:08:41AM +0100, Richard Biener wrote:
> > The expr.c hunk is also ok independently of the patch.
>
> This is committed now.
>
> > Ah, here is the stuff moved from. I suppose the IPA param re-org
> > is ok for trunk separately
On Wed, 27 Nov 2013, Tobias Burnus wrote:
> Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
> > Done.
> >
>
> Thanks for fixing Richard's and Jakub's comments and parts of mine.
>
> > +have the same meaning as described in @option{fvect-cost-model} and by
> > +default a cost model defined with
2013-11-27 Chen Liqin
* config/score/score.h (REG_CLASS_FROM_LETTER): Delete.
Index: gcc/config/score/score.h
===
--- gcc/config/score/score.h(revision 205384)
+++ gcc/config/score/score.h(working copy)
@@ -395,9
On Fri, 22 Nov 2013, Cong Hou wrote:
> Hi
>
> Currently in GCC vectorization, some loop invariant may be detected
> after aliasing checks, which can be hoisted outside of the loop. The
> current method in GCC may break the information built during the
> analysis phase, causing some crash (see PR5
On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote:
> Am 13.06.2013 11:42, schrieb Richard Sandiford:
> > "Bernhard Reutner-Fischer" writes:
> >> On 12 June 2013 20:20:50 Richard Sandiford
> >> wrote:
> >>> Matthias Klose writes:
> Index: config/mips/t-linux64
> ==
Ping
On 18 November 2013 09:40, Yvan Roux wrote:
> Ping.
>
> On 7 November 2013 15:56, Yvan Roux wrote:
>> Hi,
>>
>> this patch fixed an LRA cycling due to secondary reload (Thumb mode).
>> Notice that this patch is a prerequisite to turn on LRA by default on
>> ARM. Bootstrapped on a9 and a15
Ping.
On 19 November 2013 09:52, Yvan Roux wrote:
>> yep, all good performance-wise :)
>
> Great, Thanks Kyrill.
>
> Ok for trunk ?
>
> Yvan
Ping.
On 20 November 2013 10:22, Yvan Roux wrote:
> Hi,
>
> as Richard said, only a subset of rclass is allowed to be returned by
> preferred_reload_class. I've tested the attached patched in Thumb
> mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
>
> Yvan
>
> 2013-11-20 Yvan R
Hi,
On 11/26/2013 08:10 PM, Jason Merrill wrote:
On 11/26/2013 11:43 AM, Paolo Carlini wrote:
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your convenience - which trigger the assert !really_overloaded_fn
(t) ... What do you suggest?
Aha. Well, in that case we
This was meant only as a TLC, but it also fixes PR59306. Using
walk_gimple_op was an overkill; gimple_{store,assign_load}_p is
enough. As a side effect, it also fixes the bug because now we
better restrict what goes into instrument_member_call.
Bootstrapped, ran ubsan testsuite on x86_64-linux,
From: Max TenEyck Woodbury
Copyright 2013 assigned to the Free Software Foundation.
---
gcc/testsuite/gcc.dg/cpp/line4.c | 19 +++
libcpp/directives.c | 9 -
libcpp/internal.h| 1 +
libcpp/macro.c | 3 +++
4 files changed,
On Wed, Nov 27, 2013 at 10:58:30AM +0100, Richard Biener wrote:
> On Wed, 27 Nov 2013, Tobias Burnus wrote:
>
> > Am 27.11.2013 08:22, schrieb Sergey Ostanevich:
> > > Done.
> > >
> >
> > Thanks for fixing Richard's and Jakub's comments and parts of mine.
> >
> > > +have the same meaning as des
Hi,
When unwinding the stack, the unwind code checks for two opcodes that
denote a registrations of a signal handler. This is broken on BE as
the opcodes will be in the wrong byte-order as insns are always LE.
Add the correct checks when compiling for AArch64 big endian.
This patch fixes all gli
On Wed, Nov 27, 2013 at 05:29:22AM -0500, mtewoodb...@gmail.com wrote:
> From: Max TenEyck Woodbury
This patch is badly missing a description. You also want to mention
the PR number, if this fixes a bug. I guess this is to fix PR58687.
> Copyright 2013 assigned to the Free Software Foundation
On Tue, Nov 26, 2013 at 5:33 PM, Kenneth Zadeck
wrote:
> Richi,
>
> patch ping
Ok.
Thanks,
Richard.
> also two more pieces of information.With further testing, this seems to
> fix
>
> Tests that now work, but didn't before:
> ===
> ext/random/hypergeometric_distribution/operator
Hi,
On 27 Nov 2013 10:43:59, Eric Botcazou wrote:
>
>> I think you are right, this flag is no longer necessary, and removing
>> this code path would simplify everything. Therefore I'd like to propose
>> to remove the "keep_aligning" parameter of get_inner_reference as
>> a split-out patch.
>>
>> B
On Wed, Nov 27, 2013 at 11:29:21AM +0100, Marek Polacek wrote:
> This was meant only as a TLC, but it also fixes PR59306. Using
> walk_gimple_op was an overkill; gimple_{store,assign_load}_p is
> enough. As a side effect, it also fixes the bug because now we
> better restrict what goes into instr
On Tue, Nov 26, 2013 at 10:42 PM, Jeff Law wrote:
> On 11/26/13 02:58, Richard Biener wrote:
>>>
>>> What is the rationale behind one for over the other? Or is it arbitrary?
>>> I
>>> can easily make a case for either form based on what we're trying to
>>> optimize. In general, it seems to me th
> Well, I did that. Apologies for not mentioning that.
OK, on which strict-alignment platform did you test it with Ada enabled?
> The change on the ada interface is actually not critical, because all
> invocations of get_inner_reference there used keep_aligning == false, as
> did the majority of
On Tue, Nov 26, 2013 at 11:37 PM, Jeff Law wrote:
> On 11/26/13 02:26, Richard Biener wrote:
>
>> But only necessary if this threading returned true, no?
>
> Correct. Fix for that spinning overnight.
>
>
>
>> Also
>> how "likely" did it scramble the loop? I see that thread_block_1
>> already can
On Wed, Nov 27, 2013 at 2:07 AM, Kenneth Zadeck
wrote:
> We will of course measure it but the only thing that is different because of
> the conversion is that timode integers are packaged differently
Yeah, the slowness is due to generic code modification, not a port
using CONST_WIDE_INT or not.
On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
> Hmm. I'm still thinking that we should handle this during the regular
> transform step.
I wonder if it can't be done instead just in vectorizable_load,
if LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo) and the load is
invariant, j
All 64-bit gcc.dg/atomic and c-c++-common/cilk-plus/CK execution tests
were FAILing on Solaris 10 and 11/x86:
ld.so.1: c11-atomic-exec-1.exe: fatal:
/var/gcc/regression/trunk/10-gcc-gas/build/./gcc/libgcc_s.so.1: wrong ELF
class: ELFCLASS32
ld.so.1: fib.exe: fatal:
/var/gcc/regression/trunk/10
On Wed, Nov 27, 2013 at 10:43 AM, Eric Botcazou wrote:
>> I think you are right, this flag is no longer necessary, and removing
>> this code path would simplify everything. Therefore I'd like to propose
>> to remove the "keep_aligning" parameter of get_inner_reference as
>> a split-out patch.
>>
>
Jakub Jelinek writes:
> On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
>> In fact, I would suggest that anyone with a pending patch from prior
>> to stage1 close that hasn't gotten feedback by midnight Tuesday ping
>> their patch. I'd like to have a sense of everything that is
>> outs
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
> In fact, I would suggest that anyone with a pending patch from prior
> to stage1 close that hasn't gotten feedback by midnight Tuesday ping
> their patch. I'd like to have a sense of everything that is
> outstanding sooner rather than lat
On Wed, 27 Nov 2013, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
> > Hmm. I'm still thinking that we should handle this during the regular
> > transform step.
>
> I wonder if it can't be done instead just in vectorizable_load,
> if LOOP_REQUIRES_VERSION
On 27 November 2013 11:10, Aurelien Jarno wrote:
> On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote:
>> Am 13.06.2013 11:42, schrieb Richard Sandiford:
>> > "Bernhard Reutner-Fischer" writes:
>> >> On 12 June 2013 20:20:50 Richard Sandiford
>> >> wrote:
>> >>> Matthias Klose writ
On Wed, 27 Nov 2013 12:47:19, Richard Biener wrote:
>
> On Wed, Nov 27, 2013 at 10:43 AM, Eric Botcazou wrote:
>>> I think you are right, this flag is no longer necessary, and removing
>>> this code path would simplify everything. Therefore I'd like to propose
>>> to remove the "keep_aligning" par
On Wed, Nov 27, 2013 at 12:55:54PM +0100, Bernhard Reutner-Fischer wrote:
> On 27 November 2013 11:10, Aurelien Jarno wrote:
> > On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote:
> >> Am 13.06.2013 11:42, schrieb Richard Sandiford:
> >> > "Bernhard Reutner-Fischer" writes:
> >> >> O
On Mon, Nov 25, 2013 at 7:02 PM, Jakub Jelinek wrote:
> On Mon, Nov 25, 2013 at 06:53:59PM +0400, Alexey Samsonov wrote:
>> > In GCC, libbacktrace is built as a libtool convenience library only and
>> > then linked into whatever libraries want to use it. So indeed, the plan
>> > is to link libbac
On Wed, Nov 27, 2013 at 12:54:14PM +0100, Richard Biener wrote:
> On Wed, 27 Nov 2013, Jakub Jelinek wrote:
>
> > On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
> > > Hmm. I'm still thinking that we should handle this during the regular
> > > transform step.
> >
> > I wonder if
Ping^2
Thanks,
bin
On Fri, Nov 22, 2013 at 3:32 PM, bin.cheng wrote:
> PING.
> Hi, there is a patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01353.html which slipped away.
>
> Thanks,
> bin
>
>
>
--
Best Regards.
On 27 November 2013 06:53, Jeff Law wrote:
> On 11/25/13 17:29, Kugan wrote:
[...]
>> Thanks for the review. Is this OK for trunk now?
>
> Yes. Please install.
>
> jeff
>
Thanks, committed on Kugan's behalf as r205444.
On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote:
> > Sure, worst case you keep it untested in your LLVM copy of libsanitizer
> > and we'll just need to fix it up during merges if something breaks.
> > If it will be used for GCC (and we have a P1 bug so it is a release blocker
> > if
On Wed, 27 Nov 2013, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 12:54:14PM +0100, Richard Biener wrote:
> > On Wed, 27 Nov 2013, Jakub Jelinek wrote:
> >
> > > On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
> > > > Hmm. I'm still thinking that we should handle this during th
On Wed, Nov 27, 2013 at 4:20 PM, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote:
>> > Sure, worst case you keep it untested in your LLVM copy of libsanitizer
>> > and we'll just need to fix it up during merges if something breaks.
>> > If it will be used for
Hi,
ping...
this patch still open: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02291.html
Note: it does, as it is, _not_ depend on the keep_aligning patch.
And it would fix some really nasty wrong code generation issues.
Thanks
Bernd.
> Date: Tue, 19 Nov 2013 15:39:39 +0100
>
> Hello,
>
>
>
> I'm fine with reverting it for now (you were in CC of the patch submission
> but silent on it, I asked for the patch to start simplifying the way
> mems are expanded - ultimately to avoid the recursion and mem-attribute
> compute by the recursion).
Because I'm totally lost in this thread and its
> In fact, I would suggest that anyone with a pending patch from prior to
> stage1 close that hasn't gotten feedback by midnight Tuesday ping their
> patch. I'd like to have a sense of everything that is outstanding
> sooner rather than later and wrap up any loose ends as quickly as possible.
Imp
On Wed, Nov 27, 2013 at 1:29 PM, Eric Botcazou wrote:
>> I'm fine with reverting it for now (you were in CC of the patch submission
>> but silent on it, I asked for the patch to start simplifying the way
>> mems are expanded - ultimately to avoid the recursion and mem-attribute
>> compute by the r
> Ah, get_object_alignment used keep_aligning ...
Yes, the patch contains the rather explicit hunks:
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 204101)
+++ gcc/builtins.c (working copy)
@@ -315,7 +315,7 @@ get_o
On Wed, Nov 27, 2013 at 04:31:48PM +0400, Alexey Samsonov wrote:
> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
> standard tells that compilation unit entries "may have" attributes
> specifying the
> address range, but doesn't tell they are obligatory.
> DWARF consumer
On Wed, Nov 27, 2013 at 4:51 PM, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 04:31:48PM +0400, Alexey Samsonov wrote:
>> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
>> standard tells that compilation unit entries "may have" attributes
>> specifying the
>> address
> I don't like the unconditional -lrt added for -static-lib*san (note,
you need it for both -static-lib{a,t}san).
Makes sense.
> Perhaps it is time for libsanitizer.spec filled in during configure
of libsanitizer
> that the spec would source in?
Draft patch is attached, let's see if I unders
ext/random/hypergeometric_distribution/operators/values.cc fails to
compile on Solaris 9 which lacks full C99 support in libc/libm:
FAIL: ext/random/hypergeometric_distribution/operators/values.cc (test for
excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/ext/rand
On 27 November 2013 14:14, Rainer Orth wrote:
>
> Ok for mainline?
OK, thanks.
On Wed, Nov 27, 2013 at 1:29 PM, Bernd Edlinger
wrote:
> Hi,
>
> ping...
>
> this patch still open: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02291.html
>
> Note: it does, as it is, _not_ depend on the keep_aligning patch.
> And it would fix some really nasty wrong code generation issues.
I'll
This fixes the cgraph machinery wrt internal calls and makes LTO
and the recent OMP work regarding vectorization work (to some extent).
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-27 Richard Biener
PR middle-end/58723
* cgraphbuild.c (b
Hi,
On 11/27/2013 03:14 PM, Rainer Orth wrote:
hypergeometric_pdf is defined in testsuite/util/testsuite_random.h
inside _GLIBCXX_USE_C99_MATH_TR1, but used unconditionally. Fixed which
the following patch which allows the test to compile and pass on
i386-pc-solaris2.9. On i386-pc-solaris2.11,
On 11/27/2013 05:22 AM, Paolo Carlini wrote:
Thus something like the below? Passes testing.
Yep. With a comment that we can only get there in checking mode via
build_non_dependent_expr, because any expression that calls or takes the
address of the function will have pull a FUNCTION_DECL out
On Tue, Nov 26, 2013 at 09:25:40PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The problem on this testcase is that we have
> (debug_insn 30 29 31 7 (var_location:HI D#1 (subreg:HI (reg/v:SI 93 [ p ])
> 0)) pr59166.c:20 -1
> (nil))
> and split_live_ranges_for_shrink_wrap decides to replace
> SImod
"Iyer, Balaji V" writes:
> c_finish_omp_declare_simd (c_parser *parser, tree fndecl, tree parms,
> vec clauses)
> {
> +
> + if (flag_enable_cilkplus
> + && clauses.exists () && !vec_safe_is_empty (parser->elem_fn_tokens))
> +{
> + error ("%<#pragma omp de
On 11/27/2013 04:35 PM, Jason Merrill wrote:
On 11/27/2013 05:22 AM, Paolo Carlini wrote:
Thus something like the below? Passes testing.
Yep. With a comment that we can only get there in checking mode via
build_non_dependent_expr, because any expression that calls or takes
the address of th
On 20/11/13 09:22, Yvan Roux wrote:
> Hi,
>
> as Richard said, only a subset of rclass is allowed to be returned by
> preferred_reload_class. I've tested the attached patched in Thumb
> mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
>
> Yvan
>
> 2013-11-20 Yvan Roux
>
>
Hi Paolo,
> On 11/27/2013 03:14 PM, Rainer Orth wrote:
>> hypergeometric_pdf is defined in testsuite/util/testsuite_random.h
>> inside _GLIBCXX_USE_C99_MATH_TR1, but used unconditionally. Fixed which
>> the following patch which allows the test to compile and pass on
>> i386-pc-solaris2.9. On i3
On Wed, 27 Nov 2013, mtewoodb...@gmail.com wrote:
> Copyright 2013 assigned to the Free Software Foundation.
FWIW I don't see this in copyright.list yet. If you sent the paperwork
(whether paper mail or scans) to the FSF over a week ago and haven't had
it acknowledged, please chase up ass...@g
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the first half of the rtl code.
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2336,15 +2336,23 @@ hash_rtx_cb (
Here is the test I've committed as rev. 205451 for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57410
2013-11-27 Vladimir Makarov
PR rtl-optimization/57410
* gcc.target/i386/pr57410.c: New.
Index: testsuite/gcc.target/i386/pr57410.c
===
On 11/27/13 04:28, Richard Biener wrote:
Ick ;) Loop fixup isn't able to recover the original loop here, it
discovers a "new" one, the one just covering looping through the
default: case of the switch.
I wouldn't expect it to. I don't have the transformed CFG in front of
me right now, but as
On 11/27/13 02:05, Zhenqiang Chen wrote:
Ping?
Thanks for including the actual patch you're pinging, it helps :-)
Hi,
lp1243022.c will fail with options: -mfpu=neon -mfloat-abi=hard.
Logs show it does not generate auto-incremental instruction in pass
auto_inc_dec. In this case, the check of
On 11/27/13 02:52, Liqin Chen wrote:
2013-11-27 Chen Liqin
* config/score/score.h (REG_CLASS_FROM_LETTER): Delete.
Installed on the trunk. Thanks.
jeff
committed as revision 205448 to trunk.
committed as revision 205455 to wide-int branch.
On 11/27/2013 05:50 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 5:33 PM, Kenneth Zadeck
wrote:
Richi,
patch ping
Ok.
Thanks,
Richard.
also two more pieces of information.With further testing,
On 11/26/2013 12:23 PM, Iyer, Balaji V wrote:
Did you get a chance to look at my _Cilk_for patch for C?
BTW, I think pinging less than 24 hours after you send the patch is a
bit excessive. :)
Jason
On 11/25/2013 11:03 PM, Iyer, Balaji V wrote:
On a broad note, I think there's a lot of OpenMP code you could be
reusing here rather than writing it all again. And that way Cilk code
will benefit from improvements to OpenMP handling, and vice versa. It
probably makes sense to turn Cilk_for i
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33).
Obviously the latter's not very likely for vecto
On Tue, Nov 26, 2013 at 02:15:58PM -0700, Jeff Law wrote:
> On 11/26/13 13:33, Jakub Jelinek wrote:
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >I'll try to create a testcase for 4.8 branch tomorrow.
I've managed to create a testcase which reproduces this on 4.8 t
On 11/27/13 01:01, Yury Gribov wrote:
Hi all,
As discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 only a
subset of libubsan should be built with RTTI support. Attached patch
adds custom build rules for relevant files.
Wasn't that already checked in?
commit 5e0d610a433356af747fded
On 11/27/13 03:18, Yvan Roux wrote:
Ping
On 18 November 2013 09:40, Yvan Roux wrote:
Ping.
On 7 November 2013 15:56, Yvan Roux wrote:
Hi,
this patch fixed an LRA cycling due to secondary reload (Thumb mode).
Notice that this patch is a prerequisite to turn on LRA by default on
ARM. Bootst
On 11/27/13 03:18, Yvan Roux wrote:
Ping.
On 19 November 2013 09:52, Yvan Roux wrote:
yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Please include either the patch you are pinging or at the least a link
to it in the archives.
jeff
On 11/27/13 04:39, Rainer Orth wrote:
All 64-bit gcc.dg/atomic and c-c++-common/cilk-plus/CK execution tests
were FAILing on Solaris 10 and 11/x86:
ld.so.1: c11-atomic-exec-1.exe: fatal:
/var/gcc/regression/trunk/10-gcc-gas/build/./gcc/libgcc_s.so.1: wrong ELF
class: ELFCLASS32
ld.so.1: fib.e
> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Wednesday, November 27, 2013 6:39 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: [testsuite] Properly set ld_library_path in cilk-plus tests
>
> All 64-bit gcc.dg/atomic and c-c++-co
> Please include either the patch you are pinging or at the least a link to it
> in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p.
diff --git a/gcc/
On 11/27/2013 12:06 PM, Jason Merrill wrote:
On 11/26/2013 12:23 PM, Iyer, Balaji V wrote:
Did you get a chance to look at my _Cilk_for patch for C?
BTW, I think pinging less than 24 hours after you send the patch is a
bit excessive. :)
Ah, I see, you were pinging the non-C++ parts.
Ja
On 11/27/13 05:30, Eric Botcazou wrote:
In fact, I would suggest that anyone with a pending patch from prior to
stage1 close that hasn't gotten feedback by midnight Tuesday ping their
patch. I'd like to have a sense of everything that is outstanding
sooner rather than later and wrap up any loose
On 11/27/13 04:48, Rainer Orth wrote:
Jakub Jelinek writes:
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
In fact, I would suggest that anyone with a pending patch from prior
to stage1 close that hasn't gotten feedback by midnight Tuesday ping
their patch. I'd like to have a sens
From 6c95593f684c120a0ea7ef6178401283f63250b7 Mon Sep 17 00:00:00 2001
From: Max TenEyck Woodbury
Date: Sun, 24 Nov 2013 09:48:09 -0500
Subject: [PATCH] Postpone __LINE__ evaluation to the end of #line directives
To: gcc-patches@gcc.gnu.org
Copyright 2013 assigned to the Free Software Foundation
On 11/25/2013 10:50 AM, Iyer, Balaji V wrote:
I have fixed this issue. My function to map the variable's context from the
spawner to the spawn helper function was going into the lambda function. I made
it stop by adding a language specific copy_tree_body (basically stop going into
the lambda
On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov wrote:
>
> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
> standard tells that compilation unit entries "may have" attributes
> specifying the
> address range, but doesn't tell they are obligatory.
> DWARF consumers prob
On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
One small thing that I have not done that Jakub and several other have asked me
before is that, there are no tests in c-c++-common for _Cilk_for. The reason being
that the syntax between C and C++ implementations are different. In C++, the
inductio
> How can that be correct?
>
> The secondary reload macros/hooks define cases where additional registers
> are needed to reload certain forms of rtl. I doubt the use of LRA
> completely eliminates the need for secondary reloads.
Vladimir explained me that in that case on arm, secondary reload hoo
On Wed, Nov 27, 2013 at 12:48:11PM -0500, Jason Merrill wrote:
> On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
> >One small thing that I have not done that Jakub and several other have asked
> >me before is that, there are no tests in c-c++-common for _Cilk_for. The
> >reason being that the synta
On 27/11/13 17:49, Yvan Roux wrote:
>> How can that be correct?
>>
>> The secondary reload macros/hooks define cases where additional registers
>> are needed to reload certain forms of rtl. I doubt the use of LRA
>> completely eliminates the need for secondary reloads.
>
> Vladimir explained me t
On 11/27/2013, 12:16 PM, Jeff Law wrote:
On 11/27/13 03:18, Yvan Roux wrote:
Ping
On 18 November 2013 09:40, Yvan Roux wrote:
Ping.
On 7 November 2013 15:56, Yvan Roux wrote:
Hi,
this patch fixed an LRA cycling due to secondary reload (Thumb mode).
Notice that this patch is a prerequisite
On 11/27/13 10:54, Jakub Jelinek wrote:
On Wed, Nov 27, 2013 at 12:48:11PM -0500, Jason Merrill wrote:
On 11/15/2013 02:23 PM, Iyer, Balaji V wrote:
One small thing that I have not done that Jakub and several other have asked me
before is that, there are no tests in c-c++-common for _Cilk_for.
On 11/27/13 01:28, Alexander Ivchenko wrote:
Here is the patch series that had been posted in Sep that is aimed to
isolate the Android support from targets that actually don't have that
support (We discussed the need of it with Jakub here
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html):
Eric,
Let me make one high level comment here and the low level comments will
be responded to when i fix the patch.
CONST_DOUBLE has two hwis in it. So in practice, you get 128 bits and
that is it.a CONST_WIDE_INT has an array of HWIs that has as many
elements as it needs to represent
On Wed, Nov 27, 2013 at 9:44 PM, Ian Lance Taylor wrote:
> On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov wrote:
>>
>> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
>> standard tells that compilation unit entries "may have" attributes
>> specifying the
>> address ra
On 27 November 2013 18:58, Vladimir Makarov wrote:
> On 11/27/2013, 12:16 PM, Jeff Law wrote:
>>
>> On 11/27/13 03:18, Yvan Roux wrote:
>>>
>>> Ping
>>>
>>> On 18 November 2013 09:40, Yvan Roux wrote:
Ping.
On 7 November 2013 15:56, Yvan Roux wrote:
>
> Hi,
>
On Wed, Nov 27, 2013 at 7:45 AM, Gopalasubramanian, Ganesh
wrote:
>> Hopefully someone from AMD will provide tests that are mysteriously missing
>> from XOP testsuite.
>
> As pointed out by Marc, I added myself to the bug later.
> I was bit confused about the "internal insn representation" with
On 11/27/13 10:30, Yvan Roux wrote:
Please include either the patch you are pinging or at the least a link to it
in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_f
HI Aldy and Jakub,
Attached, please find a fixed patch. I have fixed all the changes you
have mentioned below. Is this OK to install?
Here are the ChangeLog entries:
gcc/ChangeLog
2013-11-27 Balaji V. Iyer
* config/i386/i386.c (ix86_simd_clone_compute_vecsize_and_simdlen):
1 - 100 of 168 matches
Mail list logo