> The testcase will fail due to several problems:
> - warning: large integer implicitly truncated to unsigned type [-Woverflow]
> - warning: AVX vector argument without AVX enabled changes the ABI [-Wpsabi]
> - missing int128 effective target check
> - missing runtime checks for BMI2 ISA support
A
Hi,
Please find attached the proposed patch for Bug 69687:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
* Limiting the length of the mangled string to 264k characters.
* Limiting the loop iterations to 256 (max. of C++ function parameters).
--- a/libiberty/cplus-dem.c
+++ b/libiberty/cplu
On 2 March 2016 at 00:12, Jeff Law wrote:
>
> This patch clamps the number of statements to copy when not threading across
> a loop backedge in the FSM/backwards threader. This fixes the bulk of the
> regression in 69196. I'm still evaluating whether or not 69196 can be
> closed, but at the leas
Hi!
When testing ASan on large system, I've noticed that sometimes it
crashes with SEGV in Libbacktrace when trying to symbolize stripped PIE
(compiled with -pie -fPIC) binaries in fully stripped environment (this
means that all dependent libraries are also stripped). Here a scenario
I've obs
The following fix from Uros properly (not) handles XFmode vectors in
type_natural_mode.
Bootstrapped and tested on x86_64-unknown-linux-gnu by Uros, applied.
Richard.
2016-03-02 Richard Biener
Uros Bizjak
PR target/67278
* config/i386/i386.c (type_natural_mode): Ha
On Wed, Mar 2, 2016 at 9:54 AM, Richard Biener wrote:
>
> The following fix from Uros properly (not) handles XFmode vectors in
> type_natural_mode.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu by Uros, applied.
>
> Richard.
>
> 2016-03-02 Richard Biener
> Uros Bizjak
>
>
> Index: gcc/config/i386/i386.c
> ===
> --- gcc/config/i386/i386.c(revision 233897)
> +++ gcc/config/i386/i386.c(working copy)
> @@ -7794,6 +7794,10 @@ type_natural_mode (const_tree type, cons
> {
> machine_mode i
On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote:
> On 1 March 2016 at 10:51, James Greenhalgh wrote:
> > On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
> >> On Mon, 29 Feb 2016, James Greenhalgh wrote:
> >>
> >> > On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard B
On Tue, 1 Mar 2016, Richard Henderson wrote:
> This is similar to Mark Gilsse's patch in the OP, except that it ensures that
> the expression will fold back to a single condition. I did include Richi's
> patch from #c6 to make it more likely to trigger asap.
>
> I'd appreciate feedback on the ma
On 2 March 2016 at 10:16, James Greenhalgh wrote:
> On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote:
>> On 1 March 2016 at 10:51, James Greenhalgh wrote:
>> > On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> >> On Mon, 29 Feb 2016, James Greenhalgh wrote:
>> >>
>
Hi DJ,
> Ok.
Thanks - patch committed. (I know that you have now deprecated the MeP port,
but at least with this patch in place the toolchain can now be built if obsolete
targets are enabled).
Cheers
Nick
On Wed, 2 Mar 2016, Uros Bizjak wrote:
> On Wed, Mar 2, 2016 at 9:54 AM, Richard Biener wrote:
> >
> > The following fix from Uros properly (not) handles XFmode vectors in
> > type_natural_mode.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu by Uros, applied.
> >
> > Richard.
> >
> >
PING ^ 2. The patch is sitting without comments for 4+ months.
--
Maxim Kuvyrkov
www.linaro.org
> On Dec 10, 2015, at 4:47 PM, Maxim Kuvyrkov wrote:
>
>> On Nov 11, 2015, at 7:56 PM, Maxim Kuvyrkov
>> wrote:
>>
>> Hi,
>>
>> This patch fixes an obscure cross-testing problem that crashed (
On Wed, 2 Mar 2016, Richard Biener wrote:
On Tue, 1 Mar 2016, Richard Henderson wrote:
This is similar to Mark Gilsse's patch in the OP, except that it ensures that
the expression will fold back to a single condition. I did include Richi's
patch from #c6 to make it more likely to trigger asap
On Wed, 2 Mar 2016, Marc Glisse wrote:
> On Wed, 2 Mar 2016, Richard Biener wrote:
>
> > On Tue, 1 Mar 2016, Richard Henderson wrote:
> >
> > > This is similar to Mark Gilsse's patch in the OP, except that it ensures
> > > that
> > > the expression will fold back to a single condition. I did in
On Tue, Mar 1, 2016 at 10:46 PM, Jeff Law wrote:
>
>
> Another step along the path to fixing 69196. As I was investigating the
> regression, one of the things that became quite clear was that we'd greatly
> increased the number of PHIs and many of the PHI arguments were constants
> (which in turn
On Tue, Mar 1, 2016 at 5:48 PM, Kumar, Venkataramanan
wrote:
> Hi Richard,
>
> As discussed in PR, tried to adjust the test case by initializing array, but
> looks like for building with -fpic it needs visibility to be set a hidden.
> The below patch does that.
Making the array 'static' would al
The following fixes the pattern recognition code-gen for GIMPLE
[VEC_]COND_EXPR which can have either a SSA name condition or
an embedded GENERIC expression (ugh).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress (we
don't have any pattern matching the condition part).
Richard.
201
On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote:
> On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
>> I got
>>
>> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for
>> warnings, line 17)
>> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for
>> warnings, line
On Tue, Mar 01, 2016 at 09:22:39AM -0700, Jeff Law wrote:
> Two additional regression tests for problems exposed by the 69740
> patches. They tickle a different path than the test HJ already
> checked in. Obviously the idea is to have these in place so that
> when we attack 69740 again, we don't r
Hello!
Apparently, this test was intended to be a runtime test.
2016-03-02 Uros Bizjak
* gcc.target/i386/bmi2-bzhi-2.c: Change to runtime test.
Tested on x86_64-linux-gnu, will be committed to mainline SVN.
Uros.
diff --git a/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c
b/gcc/testsuite/
On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote:
> On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote:
> > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
> >> I got
> >>
> >> FAIL: c-c++-common/vector-compare-4.c -Wc++-compat (test for
> >> warnings, line 17)
> >> FAI
On Wed, Mar 02, 2016 at 01:10:51PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote:
> > On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote:
> > > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
> > >> I got
> > >>
> > >> FAIL: c-c++-common/ve
Hi there,
This patch series adds support for the recently announced ARM core
Cortex-R8.
Andre Vieira(2)
Add support for Cortex-R8
Fix testcases after introduction of Cortex-R8
Tested by comparing regression runs of Cortex-R7 vs Cortex-R8 for both
ARM and THUMB modes.
Is this OK?
Cheers,
Andre
Hi!
As mentioned in the PR, kmovb/w uses 8/16 bit memory or %k? register,
only if it uses GPR it uses 32-bit register.
Therefore, this patch ensures that %k[01] is only used if the operand
matches "r" constraint, but not when it matches "m" constraint ("k"
constraint has not been using that alread
gcc/ChangeLog:
2016-03-02 Andre Vieira
* config/arm/arm-cores.def (cortex-r8): New.
* config/arm/arm-tables.opt (cortex-r8): New.
* config/arm/arm-tune.md: Regenerate.
* gcc/doc/invoke.texi: Add cortex-r8 to list of cpu values.
>From 8d10507bd80fd0a1db221669a67785f57ffc304
Hi,
Tests used to check for "r8" which will not work because cortex-r8
string is now included in the assembly. Fixed by checking for "[^\-]r8".
Is this Ok?
Cheers,
Andre
gcc/testsuite/ChangeLog:
2016-03-02 Andre Vieira
* gcc.target/arm/pr45701-1.c: Change assembler scan to not
tr
On Wed, Mar 02, 2016 at 01:07:37PM +0100, Uros Bizjak wrote:
> Apparently, this test was intended to be a runtime test.
>
> 2016-03-02 Uros Bizjak
>
> * gcc.target/i386/bmi2-bzhi-2.c: Change to runtime test.
>
> Tested on x86_64-linux-gnu, will be committed to mainline SVN.
LGTM, thanks.
On Wed, Mar 2, 2016 at 1:00 PM, Dominik Vogt wrote:
> On Tue, Mar 01, 2016 at 09:22:39AM -0700, Jeff Law wrote:
>> Two additional regression tests for problems exposed by the 69740
>> patches. They tickle a different path than the test HJ already
>> checked in. Obviously the idea is to have these
On Wed, Mar 2, 2016 at 1:10 PM, Jakub Jelinek wrote:
> On Wed, Mar 02, 2016 at 12:43:07PM +0100, Richard Biener wrote:
>> On Thu, Jan 28, 2016 at 8:33 PM, Marek Polacek wrote:
>> > On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
>> >> I got
>> >>
>> >> FAIL: c-c++-common/vector-compare-4
On Wed, Mar 2, 2016 at 1:19 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, kmovb/w uses 8/16 bit memory or %k? register,
> only if it uses GPR it uses 32-bit register.
> Therefore, this patch ensures that %k[01] is only used if the operand
> matches "r" constraint, but not when it matc
The attached patch fixes a test failure of go.test/test/env.go on
s390x biarch. Bootstrapped and regression tested on s390x biarch
and s390.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69766
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
* go.test/go-test.
On Wed, Mar 02, 2016 at 01:59:04PM +0100, Uros Bizjak wrote:
> > --- gcc/testsuite/gcc.target/i386/pr70028.c.jj 2016-03-01
> > 20:11:09.142593365 +0100
> > +++ gcc/testsuite/gcc.target/i386/pr70028.c 2016-03-01
> > 20:13:52.122377175 +0100
> > @@ -0,0 +1,19 @@
> > +/* PR target/70028 */
> >
Hi all,
I'm seeing the fails:
FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+,
r[0-9]+, \\[r[0-9]+\\] 1
FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+,
r[0-9]+, \\[r[0-9]+\\] 1
FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\
On 21/05/15 10:01, Kyrill Tkachov wrote:
> Hi Sandra,
>
> On 21/05/15 06:43, Sandra Loosemore wrote:
>> This is another patch aimed at fixing bugs relating to trying to execute
>> NEON code on a target that doesn't support it revealed by my
>> arm-none-eabi testing on a gazillion different multili
On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li wrote:
> Hi Richard,
>
>
> On 01/03/16 09:16, Richard Biener wrote:
>>
>> On Mon, Feb 29, 2016 at 5:13 PM, Renlin Li wrote:
>>>
>>> Hi all,
>>>
>>> The gcc.dg/lto/pr54709, pr61526, pr64415 linking testcases keep failing
>>> on
>>> arm/aarch64 bare-metal t
On Tue, 1 Mar 2016, Alan Modra wrote:
> This patch cures a problem with ICF of read-only variables at the
> intersection of -fsection-anchors, -ftree-loop-vectorize, and targets
> with alignment restrictions. The testcase results in
> /usr/local/powerpc64le-linux/bin/ld: pack.o: In function `main
Ping*3.
Thanks,
Kyrill
On 24/02/16 13:48, Kyrill Tkachov wrote:
Ping*2
Thanks,
Kyrill
On 17/02/16 10:12, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00634.html
As mentioned before, this is actually a fix for PR target/69538.
I got confused when writing the cover
On Wed, Mar 2, 2016 at 12:51 AM, Maxim Ostapenko
wrote:
>
> When testing ASan on large system, I've noticed that sometimes it crashes
> with SEGV in Libbacktrace when trying to symbolize stripped PIE (compiled
> with -pie -fPIC) binaries in fully stripped environment (this means that all
> depende
On 02/03/16 16:59, Ian Lance Taylor wrote:
On Wed, Mar 2, 2016 at 12:51 AM, Maxim Ostapenko
wrote:
When testing ASan on large system, I've noticed that sometimes it crashes
with SEGV in Libbacktrace when trying to symbolize stripped PIE (compiled
with -pie -fPIC) binaries in fully stripped envi
On 29 February 2016 at 05:28, kugan wrote:
>
>> That looks better, but I think the unordered_remove will break operand
>> sorting
>> and thus you probably don't handle x + x + x + x + y + y + y + y + y +
>> y + z + z + z + z
>> optimally.
>>
>> I'd say you simply want to avoid the recursion and co
On Wed, Mar 2, 2016 at 6:21 AM, Maxim Ostapenko
wrote:
> On 02/03/16 16:59, Ian Lance Taylor wrote:
>>
>> On Wed, Mar 2, 2016 at 12:51 AM, Maxim Ostapenko
>> wrote:
>>>
>>> When testing ASan on large system, I've noticed that sometimes it crashes
>>> with SEGV in Libbacktrace when trying to symbo
On 01-03-16 10:45, Richard Biener wrote:
On Tue, 1 Mar 2016, Tom de Vries wrote:
Hi,
this patch fixes graphite PR68659, which is a 6 regression.
The patch fixes two things:
- by handling new_expr == NULL_TREE in collect_all_ssa_names, it handles a
COMPONENT_REF where operand 2 is NULL_TREE
On Wed, 2 Mar 2016, Tom de Vries wrote:
> On 01-03-16 10:45, Richard Biener wrote:
> > On Tue, 1 Mar 2016, Tom de Vries wrote:
> >
> > > Hi,
> > >
> > > this patch fixes graphite PR68659, which is a 6 regression.
> > >
> > > The patch fixes two things:
> > > - by handling new_expr == NULL_TREE
On 29 February 2016 at 18:48, Kyrill Tkachov
wrote:
> Hi all,
>
> Now that we've moved to pragmas guarding the various intrinsics in
> arm_neon.h I think we should still
> throw a #error if someone tries to include the header while compiling for
> -mfloat-abi=soft.
>
> This gives a more helpful er
Hi Richard,
On 02/03/16 13:35, Richard Biener wrote:
On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li wrote:
Hi Richard,
On 01/03/16 09:16, Richard Biener wrote:
On Mon, Feb 29, 2016 at 5:13 PM, Renlin Li wrote:
Hi all,
The gcc.dg/lto/pr54709, pr61526, pr64415 linking testcases keep failing
on
Hi,
This patch fixes mask type determination for boolean values comparison. That
avoid incorrect application of masks conversion pattern. Bootstrapped and
tested on x86_64-pc-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2016-03-02 Ilya Enkovich
* tree-vect-patterns.c (search_ty
Hi.
Following patch fixes the PR, regtested on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2016-03-02 Martin Liska
* tree-vect-loop.c (optimize_mask_stores): Move iterator to
previous statement if we see a debug statement.
gcc/testsuite/ChangeLog:
2016
On Tue, Mar 01, 2016 at 02:29:19PM +, Kyrill Tkachov wrote:
> This test was reported as starting to fail a scan-assembler check with
> -mtune=thunderx.
> The compiler decided to move the result back into the integer registers and
> perform the shift there
> rather than do it on the SIMD side.
H.J. Lu wrote:
> + if (type && type_is_empty_type_p (type))
> +{
> + if (warn_empty_type_p)
> + warn_empty_type ();
> + return NULL;
> +}
If I understand the problem correctly, for C code empty types
already were handled correctly, the problem occured just for
C++ code (sin
On Wed, Mar 02, 2016 at 05:17:17PM +0100, Martin Liška wrote:
> 2016-03-02 Martin Liska
>
Missing
PR tree-optimization/70043
(both in gcc/ and gcc/testsuite/ ChangeLog entry).
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/vect/pr70043.f90
> @@ -0,0 +1,14 @@
> +! { dg-additional-op
On 01-03-16 12:37, Jakub Jelinek wrote:
On Tue, Mar 01, 2016 at 06:24:58PM +0100, Tom de Vries wrote:
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -3715,6 +3715,14 @@ check_omp_nesting_restrictions (gimple *stmt,
omp_context *ctx)
kind == OMP_CLAUSE_DEPEND_SOURCE ? "source"
On Mar 2, 2016, at 12:33 AM, Marcel Böhme wrote:
> Please find attached the proposed patch for Bug 69687:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
>
> * Limiting the length of the mangled string to 264k characters.
No. This isn’t in the spirit of GNU software.
> * Limiting the loo
I had a look at the costs issues in this PR. I think I've found a fair
number of bugs, but fixing those alone doesn't solve the issue; one
additional tweak is needed.
As for the bugs, they are primarily in the mechanism of recording cost
updates and restoring them. When adjusting costs for pre
On Wed, Mar 2, 2016 at 8:25 AM, Ulrich Weigand wrote:
> H.J. Lu wrote:
>
>> + if (type && type_is_empty_type_p (type))
>> +{
>> + if (warn_empty_type_p)
>> + warn_empty_type ();
>> + return NULL;
>> +}
>
> If I understand the problem correctly, for C code empty types
> alrea
On Mar 2, 2016, at 2:08 AM, Maxim Kuvyrkov wrote:
> PING ^ 2. The patch is sitting without comments for 4+ months.
So the libstdc++ people are usually pretty active and responsive, I usually let
them review these sorts of patches as domain experts. I only kick in if they
are unreasonably abse
On Mon, Feb 15, 2016 at 9:42 AM, Patrick Palka wrote:
> On Mon, Feb 8, 2016 at 12:19 AM, Patrick Palka wrote:
>> Here, we are calling template_class_depth on a FIELD_DECL corresponding
>> to a lambda that is used inside variable template. template_class_depth
>> however does not see that this FI
On 02/24/2016 11:01 PM, Jeff Law wrote:
As Vlad noted, the test is definitely a pathological case. I think
Bernd's patch is a very reasonable approach to address the current
problem. Namely that LRA can be making progress on a pathological
testcase, but it gets terminated by the anti-looping cl
On Sat, Feb 20, 2016 at 5:22 PM, Patrick Palka wrote:
> The problem here is that when processing_template_decl, the non-compound
> MODOP_EXPRs we build (i.e. a = b and not a += b) are given a NULL
> TREE_TYPE even if none of its operands are dependent. This causes
> decltypes such as "decltype (a
On 03/02/2016 05:43 AM, Richard Biener wrote:
On Wed, Mar 2, 2016 at 1:00 PM, Dominik Vogt wrote:
On Tue, Mar 01, 2016 at 09:22:39AM -0700, Jeff Law wrote:
Two additional regression tests for problems exposed by the 69740
patches. They tickle a different path than the test HJ already
checked i
On 03/02/2016 05:43 AM, Richard Biener wrote:
On Wed, Mar 2, 2016 at 1:00 PM, Dominik Vogt wrote:
On Tue, Mar 01, 2016 at 09:22:39AM -0700, Jeff Law wrote:
Two additional regression tests for problems exposed by the 69740
patches. They tickle a different path than the test HJ already
checked i
On 03/02/2016 03:51 AM, Richard Biener wrote:
On Tue, Mar 1, 2016 at 10:46 PM, Jeff Law wrote:
Another step along the path to fixing 69196. As I was investigating the
regression, one of the things that became quite clear was that we'd greatly
increased the number of PHIs and many of the PHI
Hi!
Like the recent patch for kmovw, vpextr{b,w} is another instruction
with output being r32/m{8,16} rather than r32/m32, so we shouldn't use %k0
for "m" constraint.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-03-02 Jakub Jelinek
PR target/70049
Hi!
I've committed following fix for various OpenMP gimplification and lowering
issues with privatization of C++ references to VLAs, after
bootstrapping/regtesting it on x86_64-linux and i686-linux.
2016-03-02 Jakub Jelinek
PR libgomp/69555
* gimplify.c (gimplify_decl_expr): F
On Wed, 2016-03-02 at 07:36 +0100, Dominik Vogt wrote:
> On Mon, Feb 01, 2016 at 02:18:48PM +0100, Dominik Vogt wrote:
> > The attached patch adds the a target specific attribute via the
> > new target macro TARGET_BEGIN_TRANSACTION_ATTRIBUTE to the
> > function begin_transaction(). S/390 uses thi
Hi!
This patch fixes two issues:
1) reverts part of https://gcc.gnu.org/ml/gcc-patches/2011-06/msg02183.html
changes, my understanding is that we don't emit or support what has been
mentioned as rationale for that, now that we can stick multiple pattern
stmts into a sequence; without this
Pre-approved by Jeff here: https://gcc.gnu.org/ml/gcc-help/2016-03/msg6.html
Committed as revision 233914.
Index: ChangeLog
===
--- ChangeLog (revision 233913)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-03-02 Manuel L
On 02/03/16 04:20, Patrick Palka wrote:
Using this wording order makes it seem that the problem is with the if
statement, because we emit a warning about it and then emit "only" a
note for the misleadingly-indented goto statement.
... on second thought, I may be overthinking the semantic differ
On 03/02/2016 11:58 AM, Jeff Law wrote:
I think this doesn't quite work, to make it match the comment you'd
have to add
a SSA_NAME_VAR (dst) != NULL_TREE check as otherwise all anonymous
SSA names count as "the same value we're tracking". Shouldn't you simply
compare the SSA names themselves but
On Wed, 2016-03-02 at 00:10 +0100, Gerald Pfeifer wrote:
> Hi David,
>
> On Tue, 1 Mar 2016, David Malcolm wrote:
> > The attached patch adds "id" attributes to every h2, h3 and h4
> > element
> > in the page, so that people can create URLs that reference specific
> > subsections of the guide.
>
On Wed, Mar 2, 2016 at 12:18 PM, Manuel López-Ibáñez
wrote:
> Pre-approved by Jeff here:
> https://gcc.gnu.org/ml/gcc-help/2016-03/msg6.html
>
> Committed as revision 233914.
I checked in this missing patch.
--
H.J.
--
Index: ChangeLog
==
On 03/02/2016 12:29 PM, Bernd Schmidt wrote:
I had a look at the costs issues in this PR. I think I've found a fair
number of bugs, but fixing those alone doesn't solve the issue; one
additional tweak is needed.
As for the bugs, they are primarily in the mechanism of recording cost
updates an
On Wed, 2 Mar 2016, David Malcolm wrote:
> Committed to CVS, and it appears to be live on the website, so links
> like the following now work:
> https://gcc.gnu.org/gcc-6/porting_to.html#Wmisleading-indentation
Yes. Updates to gcc.gnu.org happen instantaneously, whereas
the site at www.gnu.org/so
On 02/29/2016 04:51 AM, Yuri Rumyantsev wrote:
Hi All,
Here is a simple patch for gcc.dg/ifcvt5.c test - detect "6 basic
blocks" string in rtl dump also to accept speculative motion of
else-part of if-stmt before test-part aka IF-CASE-2.
Is it OK for trunk?
ChanageLog:
2016-02-29 Yuri Rumyant
Is there anything else we should say?
I thought about recommending that distributions not install the libffi shared
library from gcc and instead use upstream source. But that doesn't really help
one way or the other, so I dropped that language.
r~
Index: changes.html
===
[ Ho hum. Re-send due to spam rejection.
Trying again with compressed patch. ]
As discussed in the PR, let's take the opportunity while bumping the soname to
add symbol versioning.
Versioning is complicated by the fact that there are several pieces of API that
are "optional" based on the
Hi,
Please find attached the patch that enhances the existing pattern.
Please review the patch at the following link and let me know
if there should be any modifications in it:-
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01035.html
Thanks,
Naveen
On Tue, Mar 01, 2016 at 09:04:54PM +0100, Eric Botcazou wrote:
> When stack checking is entirely done by the middle-end (default if no
> specific
> back-end support or forced by -fstack-check=generic), the checking for the
> prologue is actually done in the caller with a default range and the ho
On Thu, Mar 03, 2016 at 07:46:49AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 01, 2016 at 09:04:54PM +0100, Eric Botcazou wrote:
> > When stack checking is entirely done by the middle-end (default if no
> > specific
> > back-end support or forced by -fstack-check=generic), the checking for the
>
I have attached a new patch which hopefully address Richard's concerns.
I modified the predicate on operand 1 to to "arm_rhs_operand" to be
consistent with the constraints. I retained the split into two patterns;
one for arm and another for thumb2. I thought this was cleaner.
Okay for trunk?
80 matches
Mail list logo
