On Wed, Oct 1, 2014 at 12:13 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
expand_vselect for some reason ignores the expander.
Does it work with expanders?
The comment talks about insn only:
/* Construct (set target (vec_select op0 (parallel perm))) and
return true if that's a valid
On 30 September 2014 20:20, Teresa Johnson tejohn...@google.com wrote:
On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law l...@redhat.com wrote:
On 09/29/14 08:19, Teresa Johnson wrote:
Just an update - I found some good test cases by compiling the
c-torture tests with profile feedback with and
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to support Tsan testsuite.
Tested on x86_64-pc-linux-gnu, ok to commit?
-Maxim
ChangeLog:
Joseph S. Myers jos...@codesourcery.com writes:
And, while C++14 requires plain int bit-fields to be signed,
Thanks, noted for the future.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something
Hi Andreas,
OK, I will fix this.
Thanks,
David Sherwood.
-Original Message-
From: Andreas Schwab [mailto:sch...@suse.de]
Sent: 01 October 2014 08:27
To: Joseph S. Myers
Cc: Richard Earnshaw; David Sherwood; gcc-patches@gcc.gnu.org;
vmaka...@redhat.com; Richard
Sandiford
Subject: Re:
On Wed, Oct 01, 2014 at 08:26:27AM +0200, Uros Bizjak wrote:
On Wed, Oct 1, 2014 at 12:13 AM, Evgeny Stupachenko evstu...@gmail.com
wrote:
expand_vselect for some reason ignores the expander.
Does it work with expanders?
The comment talks about insn only:
/* Construct (set target
Adding Joseph S. Myers as bug reporter.
On 10/01/2014 11:09 AM, Maxim Ostapenko wrote:
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to
On 01/10/14 01:00, Jiong Wang wrote:
On 27/09/14 22:20, Kugan wrote:
On 23/09/14 01:58, Jiong Wang wrote:
On 22/09/14 16:43, Kugan wrote:
AArch64 has the same issue ARM had where the LR register was not
used in
leaf functions. This was reported in
Hi,
On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
Ville asked for help with the necessary compiler intrinsics for the is_trivially_*
C++11 library traits. The first patch cleans up a few oddities I noticed with
the
Great. I think this can be as well marked as PR c++/26099.
There's also
Hi!
In r215749, I have committed a merge from trunk r215707 (2014-09-30) into
gomp-4_0-branch.
Grüße,
Thomas
pgppaJDkOxiPC.pgp
Description: PGP signature
Hi again,
On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
The intrinsics still fail to support certain variadic cases, such as
template class T, class... Args void bar() {
static_assert(__is_trivially_constructible(T, Args...), ); }
... depending on your arrangements with Jason you may or
Hi,
Returning to this old thread,
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02285.html
here is a patch after a few rounds of review comments, specifically:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02248.html
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02285.html
On 30/09/14 21:30, Eric Christopher wrote:
On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 22 September 2014 19:41, Carrot Wei car...@google.com wrote:
Hi
The extended register width in add/adds/sub/subs/cmp instructions is
not always the same as
On 1 October 2014 11:11, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi again,
On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
The intrinsics still fail to support certain variadic cases, such as
template class T, class... Args void bar() {
static_assert(__is_trivially_constructible(T,
On 30/09/14 20:33, Mike Stump wrote:
On Sep 30, 2014, at 9:15 AM, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 30 Sep 2014, Richard Earnshaw wrote:
GCC is written in C++ these days, so technically, you need the C++
standard :-)
And, while C++14 requires plain int bit-fields to be
Hi Ramana,
Your patch https://gcc.gnu.org/ml/gcc-patches/2012-02/msg01492.html
seems to have not been applied for 4.10. Are there any stoppers or is it
an omission ?
Many Thanks
Christian
Hi,
It would be handy to see the reason(s) why target-supports errors out.
I have been using this patch for a while now and it helps tremendously
to quickly grok why a test isn't being run.
In the meantime a couple of new tests were added (cas_char, cas_int, ...)
and i'd be happy to follow-up
Use the (abbreviated) proprocessor condition for #error instead of FOO
so one can see the test issued.
gcc/testsuite/ChangeLog
2012-12-01 Bernhard Reutner-Fischer al...@gcc.gnu.org
* lib/target-supports.exp: error out with preprocessor condition
instead of FOO everywhere.
Hi!
I'd like to create 4.9.2-rc1 soon (anyone has any pending patches
for 4.9 branch?), so I've bootstrapped/regtested following 3
backports on x86_64-linux and i686-linux.
Ok for 4.9?
Is the new PR63306 testcase ok for trunk too?
Jakub
2014-10-01 Jakub Jelinek ja...@redhat.com
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00154.html
Thanks,
Kyrill
On 02/09/14 16:34, Kyrill Tkachov wrote:
Hi all,
The store_minmaxsi produces a cmp + ite + 2 conditional stores and is
thus inappropriate when the ARMv8-A IT block rules are in place.
Previously we had disabled it
Getting back to initial patch, is it ok?
It fixes gcc.target/i386/pr52252-atom.c for AVX2 make check.
X86 bootstrap is also ok.
2014-10-01 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
*
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
Getting back to initial patch, is it ok?
IMO, we should start with Jakub's proposed patch [1]
[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00010.html
Uros.
It fixes gcc.target/i386/pr52252-atom.c for AVX2 make
On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
Getting back to initial patch, is it ok?
IMO, we should start with Jakub's proposed patch [1]
[1]
Similar patch is under discussion at another mail thread:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00025.html
The main point is that each expand function called in order to number
of expanded insns starting from 1. expand_vec_perm_palignr is expected
to produce not more than 2 insns.
palignr
On Wed, Oct 1, 2014 at 10:03 AM, Christian Bruel christian.br...@st.com wrote:
Hi Ramana,
Your patch https://gcc.gnu.org/ml/gcc-patches/2012-02/msg01492.html
seems to have not been applied for 4.10. Are there any stoppers or is it
an omission ?
Short answer, no, not an omission. It could
This is not a fix for the case { 1, 2, 3, ..., 31, 0 }. This patch is
an extension of expand_vec_perm_palignr on AVX2 case.
For the case { 1, 2, 3, ..., 31, 0 } we should use separate
function/pattern. I like split as it is similar to already handled SSE
byte rotate {1,2,3,.,15, 0}:
On Wed, Oct 01, 2014 at 12:35:14PM +0200, Jakub Jelinek wrote:
On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
Getting back to initial patch, is it ok?
IMO, we should start with Jakub's
On Wed, Oct 1, 2014 at 1:38 PM, Jakub Jelinek ja...@redhat.com wrote:
That doesn't compile, will post a new version; got interrupted when
I found that in
GCC_TEST_RUN_EXPENSIVE=1 make check-gcc
RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
one test is miscompiled even
OK, thanks for the update. partitioning would be very important for my
current work so I'd like to understand what is so special with ARM that
it's the only target that can't achieve that (on the V7 at least ).
Christophe, Mathew, did you have a test case (I don't have a direct
access to the
On 30/09/14 22:18 +0200, François Dumont wrote:
Hi
I prefer to submit this patch to you cause I am not very
comfortable with Python stuff.
I simply rely on Python cast feature. It doesn't really matter but
is it going to simply consider the debug iterator as a normal one or
Yes.
On Wed, Oct 01, 2014 at 01:45:54PM +0200, Uros Bizjak wrote:
OK.
Thanks. Second step is a tiny optimization, for the
simplified 122 (now 24) vshuf-v4di.c testcase:
typedef unsigned long long V __attribute__ ((vector_size (32)));
V a, b, c, d;
int
main ()
{
int i;
for (i = 0; i 4; ++i)
On Oct 1, 2014, at 1:50 AM, Richard Earnshaw rearn...@arm.com wrote:
Isn't that exactly what I suggested?
However, since
GCC is supposed to bootstrap using a portable ISO C++ compiler, there's
an argument for removing the ambiguity entirely by being explicit.”
I think one can read that and
On Oct 1, 2014, at 2:10 AM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
It would be handy to see the reason(s) why target-supports errors out.
Ok for the trunk?
Ok.
On Wed, Oct 1, 2014 at 2:17 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Oct 01, 2014 at 01:45:54PM +0200, Uros Bizjak wrote:
OK.
Thanks. Second step is a tiny optimization, for the
simplified 122 (now 24) vshuf-v4di.c testcase:
typedef unsigned long long V __attribute__ ((vector_size
On 10/01/2014 11:09 AM, Maxim Ostapenko wrote:
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to support Tsan testsuite.
Tested on
On 12/09/14 14:34 +0100, Jonathan Wakely wrote:
Swapping an object with itself is pointless, and asserts in debug mode
(but we should probably remove that check from debug mode, since it
can happen in reasonable code).
Tested x86_64-linux, committed to trunk.
I think this makes sense for the
On 22/09/14 17:01 +0100, Jonathan Wakely wrote:
Include missing header, and add tests.
Tested x86_64-linux, committed to trunk.
... and the 4.9 branch.
Include bits/uses_allocator.h in stack and queue.
* include/bits/stl_queue.h: Include missing header.
*
On 22/09/14 15:54 +0100, Jonathan Wakely wrote:
When I fixed std::try_lock a few years ago I misread the spec,
exceptions should not be caught and turned into a return value.
Tested x86_64-linux, committed to trunk.
... and also the 4.9 branch.
* include/std/mutex (try_lock): Do not
On 25/09/14 13:14 +0100, Jonathan Wakely wrote:
With C++11 allocator semantics the swap() member might also replace
the allocator, which is only allowed in specific circumstances.
Even though the worst that could happen is we replace the allocator
with an equal one, we should avoid using swap
Committed to the 4.9 branch.
commit e653a57aa442cea124feaf67b65b9d80ca2e7ec6
Author: redi redi@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Oct 1 12:34:28 2014 +
* doc/xml/manual/status_cxx2011.xml: Corrections.
* doc/html/manual/status.html: Regenerate.
git-svn-id:
On Wed, Oct 01, 2014 at 05:31:46AM -0700, Mike Stump wrote:
On 10/01/2014 11:09 AM, Maxim Ostapenko wrote:
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is
On Wed, Oct 01, 2014 at 02:25:01PM +0200, Uros Bizjak wrote:
OK.
And now the expand_vec_perm_palignr improvement, tested
with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
E.g.
typedef unsigned long long V __attribute__ ((vector_size
On 02/09/14 16:34, Kyrill Tkachov wrote:
Hi all,
The store_minmaxsi produces a cmp + ite + 2 conditional stores and is
thus inappropriate when the ARMv8-A IT block rules are in place.
Previously we had disabled it for speed optimisations, but it should be
disabled completely when
On 1 October 2014 14:21, Mike Stump mikest...@comcast.net wrote:
On Oct 1, 2014, at 2:10 AM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
It would be handy to see the reason(s) why target-supports errors out.
Ok for the trunk?
Ok.
Installed as r215759.
Thanks!
On Wed, Oct 1, 2014 at 2:56 PM, Jakub Jelinek ja...@redhat.com wrote:
And now the expand_vec_perm_palignr improvement, tested
with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
E.g.
typedef unsigned long long V __attribute__
Sorry, yes, will try to reproduce.
Teresa
On Wed, Oct 1, 2014 at 12:03 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 30 September 2014 20:20, Teresa Johnson tejohn...@google.com wrote:
On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law l...@redhat.com wrote:
On 09/29/14 08:19, Teresa Johnson
Committed to the 4.8 branch.
commit 68b51473c3eb66b5a53e216579a8000a86c5cfd9
Author: redi redi@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Oct 1 12:34:28 2014 +
* doc/xml/manual/status_cxx2011.xml: Corrections.
* doc/html/manual/status.html: Regenerate.
diff --git
Hi Jeff,
as you know, this test case takes too long to complete if the test suite is run
with
this command line:
MALLOC_PERTURB_=237 make -k check
The reason was found in libcpp/charset.c, where a reallocation is done one byte
at a time.
It seems to be in the macro expansion of this
Hi!
On Mon, 29 Sep 2014 20:13:38 +0200, I wrote:
On Wed, 9 Oct 2013 18:32:11 +, Iyer, Balaji V balaji.v.i...@intel.com
wrote:
[libcilkrts]
Here is a patch to have libcilkrts use AC_USE_SYSTEM_EXTENSIONS (as other
libraries are doing) instead of manually fiddling with the _GNU_SOURCE
On Tue, Sep 30, 2014 at 5:06 PM, Aldy Hernandez al...@redhat.com wrote:
On 09/30/14 03:23, Richard Biener wrote:
On Mon, Sep 29, 2014 at 8:54 PM, Aldy Hernandez al...@redhat.com wrote:
I'm rearranging some code in Michael's original patch to minimize the
difference with mainline.
It seems
On Wed, Oct 1, 2014 at 6:20 AM, Teresa Johnson tejohn...@google.com wrote:
Sorry, yes, will try to reproduce.
Teresa
On Wed, Oct 1, 2014 at 12:03 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 30 September 2014 20:20, Teresa Johnson tejohn...@google.com wrote:
On Mon, Sep 29, 2014
2014-09-18 18:00 GMT+04:00 Ilya Enkovich enkovich@gmail.com:
On 17 Sep 20:51, Uros Bizjak wrote:
On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich enkovich@gmail.com
wrote:
On 16 Sep 12:22, Uros Bizjak wrote:
On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich enkovich@gmail.com
The problem arose in our internal build which is a (relatively) simple
Makefile. Now that I know what AC_USE_SYSTEM_EXTENSIONS is doing I can adjust
it accordingly.
Thanks.
- Barry
-Original Message-
From: Thomas Schwinge [mailto:tho...@codesourcery.com]
Sent: Wednesday, October
On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
2014-10-01 Jakub Jelinek ja...@redhat.com
* config/i386/i386.c (expand_vec_perm_palignr): Handle
256-bit vectors for TARGET_AVX2.
Please mention PR 62128 and include the testcase from the PR. Also,
please
On Mon, Sep 29, 2014 at 5:36 PM, Jan Hubicka hubi...@ucw.cz wrote:
Why not just make all anonymous types their own canonical type?
(of course considering type variants)
If C++ FE sets canonical type always to main variant, it should work.
Is it always the case? I noticed you do this for
On Wed, Oct 1, 2014 at 4:12 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
2014-10-01 Jakub Jelinek ja...@redhat.com
* config/i386/i386.c (expand_vec_perm_palignr): Handle
256-bit vectors for TARGET_AVX2.
Please
On Wed, Oct 1, 2014 at 11:39 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
I'd like to create 4.9.2-rc1 soon (anyone has any pending patches
for 4.9 branch?), so I've bootstrapped/regtested following 3
backports on x86_64-linux and i686-linux.
Ok for 4.9?
Is the new PR63306 testcase ok for
Hi,
at the moment, the only check in SRA for volatility is of the DECLs
themselves. As PR 63375 shows, there can be volatile references to a
non-volatile declaration which must not be ignored, otherwise SRA can
loose the volatility of the reference. Since the point of SRA is to
produce
On 30 September 2014 15:27, Christophe Lyon christophe.l...@linaro.org wrote:
On 10 July 2014 12:12, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 1 July 2014 11:05, Christophe Lyon christophe.l...@linaro.org wrote:
* documentation (README)
* dejanu driver (neon-intrinsics.exp)
*
On Wed, Oct 1, 2014 at 4:10 PM, Ilya Enkovich enkovich@gmail.com wrote:
+;; Return true if size of VALUE can be stored in a sign
+;; extended immediate field.
+(define_predicate x86_64_immediate_size_operand
+ (match_code symbol_ref)
+{
+ if (!TARGET_64BIT)
+return true;
+
+
On 2014-10-01 5:39 AM, Jakub Jelinek wrote:
Hi!
I'd like to create 4.9.2-rc1 soon (anyone has any pending patches
for 4.9 branch?), so I've bootstrapped/regtested following 3
backports on x86_64-linux and i686-linux.
Ok for 4.9?
Yes, my patch is ok. Thanks for backporting it, Jakub.
Christophe Lyon wrote:
Since this commit, I can see all my builds for arm*linux* and
aarch64*linux* fail while building glibc:
/tmp/3496222_18.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
iso-2022-cn.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Win
line
On 10/01/14 07:04, Richard Biener wrote:
No, checking -gimple_df would be odd indeed. The check seems to be coming from
Michas patch-set?
Correct.
On 1 October 2014 17:22, Sebastian Pop seb...@gmail.com wrote:
Christophe Lyon wrote:
Since this commit, I can see all my builds for arm*linux* and
aarch64*linux* fail while building glibc:
/tmp/3496222_18.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
Hi!
On Sat, 20 Sep 2014 01:59:25 +0200, Jan Hubicka hubi...@ucw.cz wrote:
Bootstrapped/regtested x86_64-linux, comitted.
(In r215409.)
PR c++/61825
* c-family/c-common.c (handle_alias_ifunc_attribute): Check
that visibility change is possible
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 214680)
+++ include/bits/stl_function.h (working
I got the preprocessed source. With the aarch64 cross-compiler I built
I am able to reproduce the ICE. Looking at it now.
Thanks,
Teresa
On Wed, Oct 1, 2014 at 8:25 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 1 October 2014 17:22, Sebastian Pop seb...@gmail.com wrote:
Christophe
Christophe Lyon wrote:
I did it in a followup mail, but the list server rejected it because
it was too large.
I suppose Teresa did receive it though.
Not sure whether I can attach it in .xz format? Is this allowed?
You can open a bug report and attach the preprocessed file there.
Thanks,
If you have posted a MIPS patch that needs to be reviewed, please send a link
to the original patch and copy Matthew and I.
We may not be aware that your patch is outstanding.
Thanks,
Catherine
On 26 Sep 22:02, Joseph S. Myers wrote:
Any patch adding new configure options needs to add documentation of the
semantics of those options in install.texi. I see no such documentation
in this patch.
Done.
On 30 Sep 13:16, Thomas Schwinge wrote:
Doesn't that comment belong to
On 30 Sep 13:40, Thomas Schwinge wrote:
As just discussed for the libgcc changes in
http://news.gmane.org/find-root.php?message_id=%3C87d2ad73ze.fsf%40schwinge.name%3E,
just some suggestions regarding the terminology, where I think that the
term »target« might be confusing in comments or
On Wed, Oct 1, 2014 at 8:29 AM, Teresa Johnson tejohn...@google.com wrote:
I got the preprocessed source. With the aarch64 cross-compiler I built
I am able to reproduce the ICE. Looking at it now.
It may also cause:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--
H.J.
On Wed, Oct 1, 2014 at 9:20 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Oct 1, 2014 at 8:29 AM, Teresa Johnson tejohn...@google.com wrote:
I got the preprocessed source. With the aarch64 cross-compiler I built
I am able to reproduce the ICE. Looking at it now.
It may also cause:
Hi,
in this issue Daniel argued that the value of a noexcept expression
should not depend on constructor elision. Then, in the audit trail Marc
tentatively suggested something like the parser.c hunk below, which just
disables our -felide-constructors optimization when parsing the noexcept
On 10/01/14, Jonathan Wakely wrote:
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 214680)
+++
On Fri, Sep 26, 2014 at 10:11:13AM +0100, Richard Biener wrote:
On Thu, Sep 25, 2014 at 4:57 PM, James Greenhalgh
james.greenha...@arm.com wrote:
Given the special value to note the default for the new --params is
zero a user cannot disable scalarization that way.
I still somehow dislike
Ok, then here it is a new patch (tested and bootstrapped on linux).
On linux with --disable-tls now all libgomp make check tests pass; for
Android I've patched toolchain and tried test from one of the
mentioned bugs, test passes too.
Is there some benchmark to check performance?
2014-10-01
This patch removes some asserts my jump threading patch r215739 added.
An upstream pass (copyrename2) is introducing some bogus profile
counts, so we can't assert that counts are 0 when there is no profile
data for the function.
Tested on testcase attached to PR63422. Currently running gcc
2014-10-01 19:17 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
On Wed, Oct 1, 2014 at 4:10 PM, Ilya Enkovich enkovich@gmail.com wrote:
+;; Return true if size of VALUE can be stored in a sign
+;; extended immediate field.
+(define_predicate x86_64_immediate_size_operand
+ (match_code
Probably need to file a bug to track the copyrename2 problem.
David
On Wed, Oct 1, 2014 at 9:59 AM, Teresa Johnson tejohn...@google.com wrote:
This patch removes some asserts my jump threading patch r215739 added.
An upstream pass (copyrename2) is introducing some bogus profile
counts, so we
On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw rearn...@arm.com wrote:
On 30/09/14 21:30, Eric Christopher wrote:
On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 22 September 2014 19:41, Carrot Wei car...@google.com wrote:
Hi
The extended register
On 09/30/2014 06:48 PM, Ville Voutilainen wrote:
Ville asked for help with the necessary compiler intrinsics for the is_trivially_*
C++11 library traits. The first patch cleans up a few oddities I noticed with
the
Great. I think this can be as well marked as PR c++/26099.
There's also PR
On 1 October 2014 20:20, Jason Merrill ja...@redhat.com wrote:
Here are two more patches: the first fixes trivial_fn_p for a defaulted
default constructor overloaded with a template default constructor, and the
second fixes the variadic case above.
Excellent, thank you very much. Paolo, feel
On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw rearn...@arm.com wrote:
On 30/09/14 21:30, Eric Christopher wrote:
On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 22 September 2014 19:41, Carrot Wei car...@google.com wrote:
Hi
The extended register
On Wed, Oct 1, 2014 at 7:02 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-10-01 19:17 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
On Wed, Oct 1, 2014 at 4:10 PM, Ilya Enkovich enkovich@gmail.com wrote:
+;; Return true if size of VALUE can be stored in a sign
+;; extended immediate
Ok, as Jason explained this wouldn't work, so we indeed need to stream
TYPE_CANONICAL in this case (and also properly SCC-walk it!)
Yep, my patch streams and SCC walks them when they are anonymous.
By incremental patch I plan to handle all ODR and component types,
so basically stream
On 2014-09-25 5:46 AM, Ilya Enkovich wrote:
2014-09-25 1:51 GMT+04:00 Ilya Enkovich enkovich@gmail.com:
2014-09-24 23:09 GMT+04:00 Jeff Law l...@redhat.com:
On 09/24/14 07:13, Ilya Enkovich wrote:
I tried to generate PARALLEL with all regs set by call. Here is a
memset call I got:
On Wed, Oct 1, 2014 at 2:56 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Oct 01, 2014 at 02:25:01PM +0200, Uros Bizjak wrote:
OK.
And now the expand_vec_perm_palignr improvement, tested
with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
RUNTESTFLAGS='--target_board=unix/-mavx2
On October 1, 2014 4:46:42 PM CEST, Martin Jambor mjam...@suse.cz wrote:
Hi,
at the moment, the only check in SRA for volatility is of the DECLs
themselves. As PR 63375 shows, there can be volatile references to a
non-volatile declaration which must not be ignored, otherwise SRA can
loose the
The block frequencies are very small in this case leading to rounding
errors when computing the edge frequency. The rounding error was then
propagated into the recomputed probabilities, leading to insanities in
the outgoing edge probabilities on the jump threading path. Eventually
during rtl
Hi!
Since r214899 we ICE on the following testcase, because when
mem_loc_descriptor gives up on a complex TLS related address that
can't be (easily) delegitimized, we try to build location description
from MEM_EXPR, but in this case it is a TARGET_MEM_REF which wasn't handled.
I've implemented
On Wed, Oct 01, 2014 at 04:12:15PM +0200, Jakub Jelinek wrote:
For PR62128, IMHO the right fix is attached. Note, this is again covered
in vshuf-*.c tests (test 22 in both vshuf-v32*.c and vshuf-v16*.c).
With that attached patch, pr62128.c (aka test_22 in vshuf-v32qi.c), changes:
-
On 10/01/2014 04:39 PM, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok except for the MEM_REF change for 4.9/4.8 (where the mem_loc_descriptor
fix also went)?
Yes.
Jason
I've been looking at reflection, and support for non-x86 targets.
In mainline, there's some support for using libffi, but I wasn't completely
confident that things are working correctly. It doesn't help that the
testsuite still has conditionals like
func TestMakeFunc(t *testing.T) {
Hi!
I'd like to create 4.9.2-rc1 soon (anyone has any pending patches
for 4.9 branch?), so I've bootstrapped/regtested following 3
backports on x86_64-linux and i686-linux.
Ok for 4.9?
Is the new PR63306 testcase ok for trunk too?
Jakub
2014-10-01 Jakub Jelinek
On Wed, Oct 01, 2014 at 11:22:14PM +0200, Jan Hubicka wrote:
Hi!
I'd like to create 4.9.2-rc1 soon (anyone has any pending patches
for 4.9 branch?), so I've bootstrapped/regtested following 3
backports on x86_64-linux and i686-linux.
Ok for 4.9?
Is the new PR63306 testcase ok for
While hunting another bug, I noticed that the namespace code dumping
early debug information was only dumping statics. Ooops... The patch
below fixes this oversight.
Jason also suggested that we could look into emitting debug info for
DECLs directly in rest_of_decl_compilation as we
On Wed, Oct 1, 2014 at 2:14 PM, Richard Henderson r...@redhat.com wrote:
I've been looking at reflection, and support for non-x86 targets.
In mainline, there's some support for using libffi, but I wasn't completely
confident that things are working correctly. It doesn't help that the
I don't want to implement Fortran 90's implicit none, which is of course
already supported. However, I would like to implement as vendor extension:
IMPLICIT NONE (external)
which forces at that least an external or procedure is used or an
explicit interface available, if one tries to invoke
This was inspired by a discussion with Felix who was making changes in
this area.
Basically this promotes the init_insns field within struct equivalence
from an rtx to an rtx_insn_list.
The only thing that's really interesting here is the old code exploits
the fact that we could put any
1 - 100 of 122 matches
Mail list logo
