On Tue, Dec 10, 2013 at 11:59:16PM -0700, Jeff Law wrote:
> On 12/10/13 23:35, Bin.Cheng wrote:
> >I know little about GC, so when ggc_collect may be called (between two
> >passes)? If so, I have to call free_affine_expand_cache just after the
> >calling to tree_to_affine_combination_expand in SCEV
Hi!
fn_type_unification does:
/* We can't free this if a pending_template entry or
* last_error_tinst_level
is pointing at it. */
Hi!
If id->retvar isn't a decl (can happen for DECL_BY_REFERENCE returns),
then we can end up with invalid tree sharing because we reuse it more than
once (on the following testcase id->retvar is a COMPONENT_REF).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
On Wed, Dec 11, 2013 at 4:17 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 11:59:16PM -0700, Jeff Law wrote:
>> On 12/10/13 23:35, Bin.Cheng wrote:
>> >I know little about GC, so when ggc_collect may be called (between two
>> >passes)? If so, I have to call free_affine_expand_cache just after
Hi!
As discussed in the PR, range info as well as alignment info for pointers
can be position dependent, can be e.g. computed from VRP ASSERT_EXPRs,
so we can't blindly propagate it to SSA_NAMEs that the SSA_NAME with range
info has been set to. The following patch limits that to SSA_NAMEs define
On Wed, Dec 11, 2013 at 04:31:55PM +0800, Bin.Cheng wrote:
> Thank both of you for being patient on this patch.
> I went through the documentation quickly and realized that I have to
> modify pointer-map structure to make it recognized by GC (maybe more
Changing pointer_map at this point is IMHO n
Hi,
Recently I used --target=nds32be-elf to configure nds32 gcc,
it seems that the big endian is not set as default.
In the config.gcc, I notice that target_cpu_default is defined as:
nds32le-*-*)
target_cpu_default="0"
nds32be-*-*)
target_cpu_default="0|MASK_BIG_ENDIAN"
Bu
On Wed, 11 Dec 2013, Jakub Jelinek wrote:
> Hi!
>
> If id->retvar isn't a decl (can happen for DECL_BY_REFERENCE returns),
> then we can end up with invalid tree sharing because we reuse it more than
> once (on the following testcase id->retvar is a COMPONENT_REF).
>
> Fixed thusly, bootstrapped
On Wed, 11 Dec 2013, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, range info as well as alignment info for pointers
> can be position dependent, can be e.g. computed from VRP ASSERT_EXPRs,
> so we can't blindly propagate it to SSA_NAMEs that the SSA_NAME with range
> info has been set t
Backporting this patch to 4.8, 4.4 and 4.1 brougth some issues to
light. The new version of the patch optimizes some code and
warnings and adapts the test cases so that they run without
modifications on 4.8 and earlier.
Original message:
On Thu, Dec 05, 2013 at 09:06:31AM +0100, Dominik Vogt wrot
Richard Henderson writes:
> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>> Sorry, I don't understand. I never said it was invalid. I said
>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>> a single register. On a little-endian target, the offset cannot be
>> anything o
On 8 December 2013 16:53, Uros Bizjak wrote:
> On Fri, Dec 6, 2013 at 8:33 PM, Sriraman Tallam wrote:
>> Patch updated with two more tests to check if the vfmadd insn is being
>> produced when possible.
>>
>> Thanks
>> Sri
>>
>> On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam wrote:
>>> Hi,
>>>
On Wed, 11 Dec 2013, Bernhard Reutner-Fischer wrote:
> On 8 December 2013 16:53, Uros Bizjak wrote:
> > On Fri, Dec 6, 2013 at 8:33 PM, Sriraman Tallam wrote:
> >> Patch updated with two more tests to check if the vfmadd insn is being
> >> produced when possible.
> >>
> >> Thanks
> >> Sri
> >>
>
On Wed, Dec 11, 2013 at 7:54 AM, Jeff Law wrote:
>
> So for this source, compiled for x86_64 with -O3:
>
> typedef unsigned long int uint64_t;
> typedef long int int64_t;
> int summation_helper_1(int64_t* products, uint64_t count)
> {
> int s = 0;
> uint64_t i;
> for(i=0; i
On Wed, Dec 11, 2013 at 9:50 AM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 04:31:55PM +0800, Bin.Cheng wrote:
>> Thank both of you for being patient on this patch.
>> I went through the documentation quickly and realized that I have to
>> modify pointer-map structure to make it recognized by
Hi all,
I've added new tests for tsan from LLVM.
Tested on x86_64.
Ok to commit?
-Maxim
diff --git a/gcc/testsuite/c-c++-common/tsan/free_race2.c b/gcc/testsuite/c-c++-common/tsan/free_race2.c
new file mode 100644
index 000..3c15d2d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/tsan/free
On Wed, Dec 11, 2013 at 02:12:35PM +0400, Maxim Ostapenko wrote:
> I've added new tests for tsan from LLVM.
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tsan/aligned_vs_unaligned_race.C
> @@ -0,0 +1,31 @@
> +/* { dg-do run } */
> +
> +#include
> +#include
> +#include
> +
> +uint64_t Global[2];
Hi Uros!
Accommodated the changes that you mentioned.
Completed the bootstrap testing too.
Regards
Ganesh
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Wednesday, December 04, 2013 3:17 PM
To: Gopalasubramanian, Ganesh
Cc: gcc-patches@gcc.gnu.org; Richard Guenthe
Hi Vladimir,
I've some regressions on ARM after this SP elimination patch, and they
are execution failures. Here is the list:
g++.dg/cilk-plus/AN/array_test_ND_tplt.cc -O3 -fcilkplus
gcc.c-torture/execute/va-arg-22.c -O2
gcc.dg/atomic/c11-atomic-exec-5.c -O0
gfortran.dg/direct_io_12.f90 -O[2
Hi,
On Tue, 10 Dec 2013 16:14:43, Richard Biener wrote:
>
> On Tue, Dec 10, 2013 at 4:02 PM, Richard Biener
> wrote:
>> On Tue, Dec 10, 2013 at 11:53 AM, Eric Botcazou
>> wrote:
What we support is out of bounds accesses for heap vars if the var's type
has flexible array member or some
On Wed, Dec 11, 2013 at 11:27 AM, Gopalasubramanian, Ganesh
wrote:
> Accommodated the changes that you mentioned.
> Completed the bootstrap testing too.
Please provide updated ChangeLog.
The function comment is missing. Maybe you should also describe magic
number 32 here?
+static unsigned
+ix86
On Wed, Dec 11, 2013 at 10:15 AM, Bernhard Reutner-Fischer
wrote:
>>> Patch updated with two more tests to check if the vfmadd insn is being
>>> produced when possible.
>>>
>>> Thanks
>>> Sri
>>>
>>> On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam
>>> wrote:
Hi,
I have attac
> This test would fail on strict alignment targets.
Ok, we'll throw in a dg-skip-if.
> Why is the test C++ only though?
> Again, why C++ only?
> Ditto.
> Likewise.
I think main reason is having same versions of code with Clang. I had an
impression that minimization of changes would be preferre
On Wed, Dec 11, 2013 at 03:05:22PM +0400, Yury Gribov wrote:
> > This test would fail on strict alignment targets.
>
> Ok, we'll throw in a dg-skip-if.
>
> > Why is the test C++ only though?
> > Again, why C++ only?
> > Ditto.
> > Likewise.
>
> I think main reason is having same versions of code
Yvan,
On Wed, Dec 11, 2013 at 10:35 AM, Yvan Roux wrote:
> Hi Vladimir,
>
> I've some regressions on ARM after this SP elimination patch, and they
> are execution failures. Here is the list:
Pragmatically, I think it's time we turned LRA on by default now that
we are in stage3 and that would he
Hi,
I'm having problems with that patch.
I try to start at X86_64-linux-gnu, and I want to get the GCC running on
arm-linux-gnueabihf.
I grabbed system headers and libraries from the target and put it in the prefix
path.
In the first step I do
../gcc-4.9-20131208/configure --prefix=/home/ed/g
> I guess I can live with it as is, just was wondering why the tests
> were written so carelessly that when they don't really need to test
> any C++ features they are still written in C++.
Adding Kostya to comment.
-Y
On Thu, Dec 5, 2013 at 12:11 PM, dxq wrote:
> hi all,
>
> *We found that COND_EXEC is better than IF_THEN_ELSE when used as expressing
> condition move insns, because in sched, IF_THEN_ELSE insn has a dependence
> on itself, and COND_EXEC has not.
> * Besides, IF_THEN_ELSE is not good for SMS. som
What's wrong with C++? :)
Upstream we have 16 .c tests and 106 .cc tests in
compiler-rt/lib/tsan/lit_tests.
We typically prefer .cc because imo C++ is a better language (even
when using what looks like the C subset).
But we need some .c tests to make sure that tsan still works w/o C++ run-time.
-
On Wed, Dec 11, 2013 at 03:21:32PM +0400, Konstantin Serebryany wrote:
> What's wrong with C++? :)
> Upstream we have 16 .c tests and 106 .cc tests in
> compiler-rt/lib/tsan/lit_tests.
> We typically prefer .cc because imo C++ is a better language (even
That is a matter of opinion.
> when using
> Pragmatically, I think it's time we turned LRA on by default now that
> we are in stage3 and that would help with getting more issues out of
> the auto-testers quicker than anything else. Given we are now well
> into stage3, we should make sure that the LRA support gets as much
> testing as it ca
On Wed, Dec 11, 2013 at 3:27 PM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 03:21:32PM +0400, Konstantin Serebryany wrote:
>> What's wrong with C++? :)
>> Upstream we have 16 .c tests and 106 .cc tests in
>> compiler-rt/lib/tsan/lit_tests.
>> We typically prefer .cc because imo C++ is a bette
Hi,
here is the patch to turn LRA on by default on ARM, there is still
some regressions in the testsuite, as reported in the thread below,
but as Ramana said in the same thread, we now need to find the
remaining issue as fast as possible.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01074.html
T
On 11/12/13 11:47, Yvan Roux wrote:
> Hi,
>
> here is the patch to turn LRA on by default on ARM, there is still
> some regressions in the testsuite, as reported in the thread below,
> but as Ramana said in the same thread, we now need to find the
> remaining issue as fast as possible.
>
> http:/
On Wed, Dec 11, 2013 at 03:35:37PM +0400, Konstantin Serebryany wrote:
> >> when using what looks like the C subset).
> >
> > The question is why don't you limit to the subset of the two languages
> > when it doesn't cost anything.
>
> Mostly because of my (our) opinion above. :)
> GCC test suite
> Revised patch attached, your testcase passes on arm-eabi with it. Does it
> look OK to you? If so, I'll run a testing cycle on arm-vxworks and
> arm-eabi.
>
>
> * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
> arguments to push onto the stack and no varargs,
On 10/12/13 20:23, Kugan wrote:
gcc/
+2013-12-11 Kugan Vivekanandarajah
+ * configure.ac: Add check for aarch64 assembler -mabi support.
+ * configure: Regenerate.
+ * config.in: Regenerate.
+ * config/aarch64/aarch64-elf.h (ASM_MABI_SPEC): New define.
+ (ASM_SP
On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
> Hi,
>
> I'm having problems with that patch.
Sorry to hear that.
> I try to start at X86_64-linux-gnu, and I want to get the GCC running on
> arm-linux-gnueabihf.
> I grabbed system headers and libraries from the target and put i
Committed on Kugan's behalf as rev 205891.
On 11 December 2013 13:27, Marcus Shawcroft wrote:
> On 10/12/13 20:23, Kugan wrote:
>
>> gcc/
>>
>> +2013-12-11 Kugan Vivekanandarajah
>> + * configure.ac: Add check for aarch64 assembler -mabi support.
>> + * configure: Regenerate.
>> +
Hi all,
attached is a small patch which fixes accepts-invalid and
ICE-on-invalid problems on allocation with source. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-11 Janus Weil
PR fortran/58916
* resolve.c (conformable_arrays): Treat scalar 'e2'.
(re
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
> Richard Henderson writes:
>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>>> Sorry, I don't understand. I never said it was invalid. I said
>>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>>> a single registe
On Wed, 11 Dec 2013 23:11:46, Alan Modra wrote:
>
> On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> I'm having problems with that patch.
>
> Sorry to hear that.
>
Never mind.
I have similar patches, but I did not
>> I try to start at X86_64-linux-gnu, and I want to g
On 11 Dec 2013, at 13:11, Bernd Edlinger wrote:
> I did not have this one.
> What is it good for?
>
>> # Actual name to use when installing a native compiler.
>> GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
>> diff --git a/gcc/ada/gcc-interface/Make-lang.in
>> b/gcc/ada/
Dear Janus,
It looks good to me - OK for trunk.
Thanks for the patch.
Paul
On 11 December 2013 14:02, Janus Weil wrote:
> Hi all,
>
> attached is a small patch which fixes accepts-invalid and
> ICE-on-invalid problems on allocation with source. Regtested on
> x86_64-unknown-linux-gnu. Ok for t
> On 12/10/2013 04:48 AM, Jan Hubicka wrote:
> >The case where I played with local comdats was the following.
> >I made cgraph_body_availability to get context argument (i.e. instead of
> >saying
> >if something is available in current unit, it was saying if it is available
> >in current function/
> It looks good to me - OK for trunk.
Thanks, Paul. Committed as r205894.
Cheers,
Janus
> On 11 December 2013 14:02, Janus Weil wrote:
>> Hi all,
>>
>> attached is a small patch which fixes accepts-invalid and
>> ICE-on-invalid problems on allocation with source. Regtested on
>> x86_64-unknow
On 13-12-10 01:13 PM, Uros Bizjak wrote:
Hello!
2013-12-10 Ryan Mansfield
PR testsuite/59442
* gcc.target/i386/sse2-movapd-1.c: Fix alignment attributes.
* gcc.target/i386/sse2-movapd-2.c: Likewise.
* gcc.target/i386/avx-vmovapd-256-1.c: Likewise.
* gcc.target/i386/avx-vmovapd-256-2.c: Like
> I have some more fixes for Ada cross-builds that Eric commented on but need
> a little more work - will try to re-test this evening and re-post tomorrow.
It's also PR ada/55946. Would mind trying the attached patch?
--
Eric BotcazouIndex: gnattools/Makefile.in
Hello Eric,
I had made the mods to this and done some light testing - then got side-tracked
by other priorities.
however, since the topic has come up on the list:
On 6 Nov 2013, at 12:57, Eric Botcazou wrote:
>> I've been trying to improve the building and testing of Darwin for crosses
>> and n
On 12/11/13 02:51, Richard Biener wrote:
First of all phiopt runs unconditionally for -On with n > 0 but the conversion
is clearly not suitable for non-speed optimizations. Thus I'd guard it
with at least !optimize_size && optimize >= 2. As you are targeting
a worse transformation done by if-c
On 12/11/2013 08:55 AM, Jan Hubicka wrote:
+ /* Don't clone decls local to a comdat group. */
+ if (comdat_local_p (node))
+return false;
Why? It seems this should work if the clone becomes another comdat local?
Right, I think the problem was that the clone wasn't becoming comdat
local
On Wed, Dec 11, 2013 at 3:51 PM, Jeff Law wrote:
> On 12/11/13 02:51, Richard Biener wrote:
>>
>>
>> First of all phiopt runs unconditionally for -On with n > 0 but the
>> conversion
>> is clearly not suitable for non-speed optimizations. Thus I'd guard it
>> with at least !optimize_size && optim
"H.J. Lu" writes:
> On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
> wrote:
>> Richard Henderson writes:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
(subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) repr
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
>> wrote:
>>> Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understand. I never said it was invalid. I sai
Latest results for gcc 4.8.x.
This patch supersedes the previous one sent on 2013-11-03 as it was
never applied.
-tgc
Testresults for 4.8.2
arm-unknown-linux-gnueabi
i386-pc-solaris2.9
i686-pc-linux-gnu (2)
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
powe
On 12/11/2013 10:11 AM, Jason Merrill wrote:
So, it's probably possible to make it work to clone the comdat local
function into another comdat local function, but it's not useful, and
it's easier to just prevent it.
Well, not that much easier actually. I'm attaching both a delta from my
last
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
On 12/11/2013 11:24 AM, Jason Merrill wrote:
Well, not that much easier actually. I'm attaching both a delta from my
last patch and a complete patch against trunk.
Oops, forgot to remove the gimple-fold change, doing that now.
Jason
On 12/11/13 08:11, Richard Biener wrote:
Bah. That was supposed to be HONOR_SIGNED_ZEROS. Which as far as I can
tell is a property of the value being tested.
No, it's
invert_tree_comparison (enum tree_code code, bool honor_nans)
so indeed HONOR_NANS. And yes, on a conditional argument
(it
On Wed, Dec 11, 2013 at 8:26 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
>> wrote:
>>>
>>> "H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
>
> Richard Henderson writes:
>>
>> On 12
On 12/10/2013 06:03 PM, Iyer, Balaji V wrote:
Fixed patch and ChangeLog entries are attached. Is it Ok to install?
OK.
Jason
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 8:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford
The following patch fixes PR59466
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59466
LRA on PPC sometimes generates inefficient code
addis 9,2,.LC77@toc@ha
addi 9,9,.LC77@toc@l
ld 9,0(9)
instead of
addis 9,2,.LC77@toc@ha
ld 9,.LC77@toc@l(9)
I can not create a small test for this. The
It's only safe to free the targs if they weren't used to instantiate any
templates, so I lean toward option #1. Did you test this with strict gc?
Jason
On 12/11/13 02:51, Richard Biener wrote:
+ /* If inversion is needed, first try to invert the test since
+ that's cheapest. */
+ if (invert)
+{
+ enum tree_code new_code
+ = invert_tree_comparison (cond_code,
+ HONOR_NANS (TYPE_MODE (TREE_TYPE
> On 12/11/2013 08:55 AM, Jan Hubicka wrote:
> + /* Don't clone decls local to a comdat group. */
> + if (comdat_local_p (node))
> +return false;
> >>>
> >>>Why? It seems this should work if the clone becomes another comdat local?
> >>
> >>Right, I think the problem was that the
Hi all,
Following up on the crypto intrinsics for AArch32
(http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00365.html), here is a patch
adding C++ name mangling for the poly64x2_t container type. This of course
depends on the Crypto intrinsics patches going in.
Tested arm-none-eabi on a model.
> On 12/11/2013 10:11 AM, Jason Merrill wrote:
> >So, it's probably possible to make it work to clone the comdat local
> >function into another comdat local function, but it's not useful, and
> >it's easier to just prevent it.
>
> Well, not that much easier actually. I'm attaching both a delta
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
> Sent: Tuesday, December 10, 2013 1:03 PM
> To: Iyer, Balaji V
> Cc: 'Jakub Jelinek'; 'gcc-patches@gcc.gnu.org'
> Subject: Re: [PING]: [GOMP4] [PATCH] SIMD-Ena
On Wed, Dec 11, 2013 at 2:42 AM, Uros Bizjak wrote:
> On Wed, Dec 11, 2013 at 10:15 AM, Bernhard Reutner-Fischer
> wrote:
>
Patch updated with two more tests to check if the vfmadd insn is being
produced when possible.
Thanks
Sri
On Fri, Dec 6, 2013 at 11:12 AM,
On 12/11/13 09:31, Iyer, Balaji V wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
Sent: Tuesday, December 10, 2013 1:03 PM
To: Iyer, Balaji V
Cc: 'Jakub Jelinek'; 'gcc-patches@gcc.gnu.org'
Subject: Re: [P
Hi,
while thinking of the details on how to handle comdat locals through
ipa-cp/inliner/folding
I wonder, if we won't end up with better code going the oposite way.
We can declare those functions static first and then have post-inliner IPA pass
that will
travel the callgraph and mark all static f
On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> Declaring the edge_iterator inside the for() is not a good argument
> against FOR_EACH_EDGE. Of course, brownie points are up for grabs for
> the brave soul daring enough to make edge iterators be proper C++
> iterators... ;-)
So, I gave
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1)
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, December 11, 2013 12:38 PM
> To: Iyer, Balaji V
> Cc: 'Jakub Jelinek'; 'gcc-patches@gcc.gnu.org'
> Subject: Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly
> Elemental functions) for C
>
On 12/11/2013, 5:35 AM, Yvan Roux wrote:
Hi Vladimir,
I've some regressions on ARM after this SP elimination patch, and they
are execution failures. Here is the list:
g++.dg/cilk-plus/AN/array_test_ND_tplt.cc -O3 -fcilkplus
gcc.c-torture/execute/va-arg-22.c -O2
gcc.dg/atomic/c11-atomic-exec-
Can you investigate why it is creating multiple clones?
On Dec 11, 2013 10:06 AM, "Iyer, Balaji V" wrote:
>
>
>
> > -Original Message-
> > From: Aldy Hernandez [mailto:ald
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, December 11, 2013
Hi Aldy,
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, December 11, 2013 1:27 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; 'gcc-patches@gcc.gnu.org'
> Subject: RE: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly
> Elemental functions) for
On 11 December 2013 19:25, Vladimir Makarov wrote:
> On 12/11/2013, 5:35 AM, Yvan Roux wrote:
>>
>> Hi Vladimir,
>>
>> I've some regressions on ARM after this SP elimination patch, and they
>> are execution failures. Here is the list:
>>
>> g++.dg/cilk-plus/AN/array_test_ND_tplt.cc -O3 -fcilkplu
Hello Everyone,
Since we have _Cilk_spawn and _Cilk_sync support in C++ compiler, we
can enable the keyword usage in runtime. This patch should do so.
Is it Ok to install?
Here are the ChangeLog entries:
2013-12-11 Balaji V. Iyer
* Makefile.am (GENERAL_FLAGS): Remove
> Yes we do, even for struct { struct { int a; char a[1] } }; (note the not
> really "trailing" as there is padding after the trailing array). We do
> take size limitations from a DECL (if we see one) into account to limit the
> effect of this trailing-array-supporting, so it effectively only appl
On 12/11/2013 12:14 PM, Jan Hubicka wrote:
Is ipa_passes the right place to initialize calls_comdat_local?
The flag is probably needed in both early inliner and IPA inliner. A
conservative
place to initialize it would be in inline_analyze_function.
(early inliner analyze function twice, first
On 12/11/13 02:51, Richard Biener wrote:
That looks wrong - you want to look at HONOR_NANS on the mode
of one of the comparison operands, not of the actual value you want
to negate (it's integer and thus never has NaNs).
The rest of the patch looks ok to me.
Here's the updated version. It addr
On 12/11/13 12:04, Iyer, Balaji V wrote:
Hello Everyone,
Since we have _Cilk_spawn and _Cilk_sync support in C++ compiler, we
can enable the keyword usage in runtime. This patch should do so.
Is it Ok to install?
Here are the ChangeLog entries:
2013-12-11 Balaji V. Iyer
On 12/11/2013 12:45 PM, Jan Hubicka wrote:
I wonder, if we won't end up with better code going the oposite way.
We can declare those functions static first and then have post-inliner IPA pass
that will
travel the callgraph and mark all static functions/variables that are accessed
only from
one
> On 12/11/2013 12:45 PM, Jan Hubicka wrote:
> >I wonder, if we won't end up with better code going the oposite way.
> >We can declare those functions static first and then have post-inliner IPA
> >pass that will
> >travel the callgraph and mark all static functions/variables that are
> >accessed
> On 12/11/2013 12:14 PM, Jan Hubicka wrote:
> >>Is ipa_passes the right place to initialize calls_comdat_local?
> >
> >The flag is probably needed in both early inliner and IPA inliner. A
> >conservative
> >place to initialize it would be in inline_analyze_function.
> >(early inliner analyze fun
On Wed, Dec 11, 2013 at 11:04 AM, Iyer, Balaji V
wrote:
> Hello Everyone,
> Since we have _Cilk_spawn and _Cilk_sync support in C++ compiler, we
> can enable the keyword usage in runtime. This patch should do so.
>
> Is it Ok to install?
>
> Here are the ChangeLog entries:
>
> 201
Same message, but now with the correct patch attached. Sorry.
On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> Declaring the edge_iterator inside the for() is not a good argument
> against FOR_EACH_EDGE. Of course, brownie points are up for grabs for
> the brave soul daring enough to m
Hi all,
the PR in the subject line involves a module procedure whose result
has array bounds which contain a type-bound procedure call. Since the
procedure interface is written to the .mod file, also the TBP
expression needs to be written. This leads to an ICE, since it simply
has not been impleme
59446 is a missed-optimization error where we want to thread through
multiple loop exits and that request is being cancelled.
The problem is I was looking at changes in the loop_father as a proxy
for crossing loop headers. That was utterly dumb as we can test
directly for crossing a loop he
This patch to the Go frontend fixes a couple of problems with recover
thunks. First, it avoids name collisions when methods call recover;
previously if two different methods with the same name (for different
types) called recover, the assembler symbols would be the same. Second,
it avoids crashin
The only Go functions that may call recover are those that are
immediately deferred. This permits the correct handling of a panic in a
function called by a deferred function. In gccgo this is implemented by
recording the return address of a function that may call recover, and
checking that return
On Wed, Dec 11, 2013 at 02:11:49PM +0100, Bernd Edlinger wrote:
> We need the auto-build only to build something that translates .md files to
> .c,
> so I would'nt care about GMP, but some other things, like the right prototype
> for
> printf make a difference.
Right, but when you get some of th
This patch to the Go frontend and libgo implements method values in the
reflect package. Working with method values and reflect now works
correctly, at least on x86. This changes the type signature for type
methods in the reflect package to match the gc compiler. That in turn
required changing t
This patch is for the trunk, but it solves a problem that comes up for
wide-int. For wide-int we need to have the BITS_PER_UNIT available
earlier.So this patch sets the default value (8) in genmodes.c so
that it is available by anyone who includes insn-modes.h. The generator
for tm.h
The m32c part is OK.
On 12/11/2013 08:42 PM, DJ Delorie wrote:
The m32c part is OK.
thanks for the fast reply.
kenny
Go programs expect to be able to call runtime.Callers to get their call
stack. The libbacktrace library currently can not handle tail calls,
and it's not clear that it can ever be completely reliable in handling
tail calls. This patch to the Go frontend disables tail call
optimization, unless it
On 12/11/2013 03:53 PM, Jan Hubicka wrote:
Lets go with minimal version of patch that makes things working and I will take
care of solving the inliner limitations.
OK, this patch adjusts calls_comdat_local in compute_inline_parameters,
as you suggested. What do you think of the change to inli
1 - 100 of 107 matches
Mail list logo
