On Thu, Dec 12, 2013 at 08:25:15AM +0100, Tobias Burnus wrote:
> A rather simple patch to ensure that the die is generated. Without,
> one runs into an ICE. That's a follow up to my namelist debug patch
> (and the ICE is caused by it).
>
> Build on x86-64-gnu-linux and lightly tested. Full regtest
Hi!
A rather simple patch to ensure that the die is generated. Without, one
runs into an ICE. That's a follow up to my namelist debug patch (and the
ICE is caused by it).
Build on x86-64-gnu-linux and lightly tested. Full regtest currently
running.
OK for the trunk, when it succeeds?
Tobia
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> Hi, all
>>
>> This is the new patch for gcov-tool (previously profile-tool).
>>
>> Honza: can you comment on the new merge interface? David posted some
>> comments in an earlier email and we want to know what's your opinion.
>>
>> Test patch ha
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, December 11, 2013 6:04 PM
> To: Jakub Jelinek
> Cc: Bin.Cheng; Jeff Law; Bin Cheng; gcc-patches List
> Subject: Re: [PATCH PR41488]Recognize more induction variables by
> simplifying PEELED
On Wed, Dec 11, 2013 at 1:21 AM, Martin Liška wrote:
> Hello,
>I prepared a collection of systemtap graphs for GIMP.
>
> 1) just my profile-based function reordering: 550 pages
> 2) just -freorder-blocks-and-partitions: 646 pages
> 3) just -fno-reorder-blocks-and-partitions: 638 pages
>
> Plea
Hi,
On 12/12/2013 05:01 AM, Jason Merrill wrote:
Hmm, what if we make lookup_base handle incomplete types better?
I'm leaving for a few days of vacations, then I can certainly look into
that, per se should be very doable. To be honest, I didn't consider that
possibility because I feared it cou
Hmm, what if we make lookup_base handle incomplete types better?
Jason
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
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 08:42 PM, DJ Delorie wrote:
The m32c part is OK.
thanks for the fast reply.
kenny
The m32c part is OK.
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
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
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
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
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
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
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
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
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
> 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 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: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/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/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/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
> 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
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
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
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 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
> -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/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)
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
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 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
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,
> -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 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
>
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 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
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
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
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
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
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
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/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 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
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 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
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 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
"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 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
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 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
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
> 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
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
> 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 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/
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 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/
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 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
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
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.
>> +
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
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
> 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 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
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:/
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 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
> 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 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
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 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
> 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
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
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
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
> 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 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
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
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
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 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
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 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 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
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, 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 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,
>>>
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
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
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
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
1 - 100 of 107 matches
Mail list logo
