On 07/15/2017 02:47 PM, Alexander Monakov wrote:
> Subtracting values to produce a -/0/+ comparison value only works when
> original values have limited range. Otherwise it leads to broken
> comparator that indicates 0 < 0x4000 < 0x8000 < 0.
>
> Yuri posted an equivalent patch just a few
On 07/18/2017 01:49 PM, Jakub Jelinek wrote:
On Tue, Jul 18, 2017 at 01:44:21PM +0200, Martin Liška wrote:
gcc/testsuite/ChangeLog:
2017-07-17 Martin Liska
PR sanitizer/63361
* c-c++-common/ubsan/float-cast-overflow-1.c: Add either
-ffloat-store or -mieee for targets
On 07/15/2017 02:47 PM, Alexander Monakov wrote:
> This qsort comparator lacks anti-commutativity and can indicate
> A < B < A if A and B have the same bitpos. Return 0 in that case.
>
> * gimple-ssa-store-merging.c (sort_by_bitpos): Return 0 on equal bitpos.
OK.
jeff
On 07/15/2017 02:47 PM, Alexander Monakov wrote:
> This comparator lacks anti-commutativity and can indicate
> A < B < A if both A and B satisfy non_spilled_static_chain_regno_p.
> Proceed to following tie-breakers in that case.
>
> (it looks like the code incorrectly assumes that at most one regi
On 07/02/2017 02:00 PM, Martin Sebor wrote:
> The attached patch enhances the -Wrestrict warning to detect more
> than just trivial instances of overlapping copying by sprintf and
> related functions.
>
> The meat of the patch is relatively simple but because it introduces
> dependencies between e
On 07/18/2017 01:36 PM, Segher Boessenkool wrote:
> ... if it is an IOR with a constant with all bits set in the mode
> that is truncated to, for example. Handle that case.
>
> With this patch the problematic situation for the PR81423 testcase
> isn't even reached; but the next patch fixes that a
On 07/04/2017 05:13 AM, Hurugalawadi, Naveen wrote:
> Hi,
>
> Thanks for the review and comments on the patch.
>
>>> The proposed patch handled both the same. This means the pattern
>>> shouldn't use range-info but instead match a more complex
>
> The patch handles as per the discussion by matc
On 07/03/2017 12:08 PM, Yuri Gribov wrote:
>>> 0001-Added-no_tail_call-attribute.patch
>>>
>>>
>>> From 1f4590e7a633c6335512b012578bddba7602b3c9 Mon Sep 17 00:00:00 2001
>>> From: Yury Gribov
>>> Date: Sun, 28 May 2017 21:02:20 +0100
>>> Subject: [PATCH] Added no_tail_call attribute.
>>>
>>> gcc/
On 07/07/2017 05:17 PM, John Marino wrote:
> Right after DragonFly 4.8 was released (27 Mar 2017), the signal
> trampoline was moved (twice) in response to a Ryzen bug. This broke
> GCC's unwind support for DragonFly.
>
> To avoid hardcoding the sigtramp location to avoid issues like this in
> th
Opps, I clearly attached the wrong file.
--
I don't think this patch changed in any significant way since V1.
--
One of the painful aspects of all this code is the amount of target
dependent bits that have to be written and tested.
I didn't want to be scanning assembly code or RTL for prologue
This time with the patch attached.
Forwarded Message
Subject: [PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2
Date: Tue, 18 Jul 2017 23:17:23 -0600
From: Jeff Law
To: gcc-patches
The biggest change since V1 of this patch is dropping the changes to
STACK_CHECK_MOVIN
I don't think this patch has changed in any significant way since the V1
patch.
I have tested a slightly different version which punts stack clash
protection for very large static stack frames -- otherwise tests which
have *huge* frames will timeout, run out of memory during compilation, etc.
--
I don't think this has changed in any significant way since V1.
--
This patch introduces x86 target specific bits to mitigate stack clash
attacks.
The key differences relative to the -fstack-check=specific expander are
that it never allocates more than PROBE_INTERVAL bytes at a time, it
probes i
These are the PPC bits for stack clash mitigation.
As noted before the PPC bits were larger/more complex than other ports.
Part of that was due to the PPC defining its own dynamic stack
allocation expander -- which in turn means we weren't using any of the
generic code in explow.c for stack c
So this patch has changed considerably since V1 as well.
First, we no longer track the bulk of the register stores in the
prologue. Those may be separately shrink wrapped and thus not executed
on all paths and as such are not candidates for implicit probes.
Second, per the discussions we've had
I don't think this has changed in any significant way since V1.
--
The prior patch introduced -fstack-clash-protection prologues for the
x86. And yet we still saw large allocations in our testing.
It turns out combine-stack-adjustments would take
allocate PROBE_INTERVAL
probe
allocate PROBE_I
I don't think this patch changed in any significant way since V1.
--
One of the painful aspects of all this code is the amount of target
dependent bits that have to be written and tested.
I didn't want to be scanning assembly code or RTL for prologues. Each
target would have to have its own sca
The biggest change since V1 of this patch is dropping the changes to
STACK_CHECK_MOVING_SP. They're not needed.
This patch also refactors a bit of the new code in explow.c. In
particular it pulls out 3 chunks of code for protecting dynamic stack
adjustments so they can be re-used by backends th
-fstack-clash-protection is now separate from -fstack-check=. But we
still want targets without stack-clash specific prologue support to be
able to get partial coverage from -fstack-clash-protection. This adds
the necessary checks for flag_stack_clash_protection to the appropriate
targets so we
The biggest change in this update to patch 01/08 is moving of stack
clash protection out of -fstack-check= and into its own option,
-fstack-clash-protection. I believe other issues raised by reviewers
have been addressed as well.
--
This patch introduces a new option -fstack-clash-protection de
So later than I wanted, here's the V2 of the stack clash mitigation work.
Probably the biggest change in this version was moving the protection
out of -fstack-check= and into its own option (-fstack-clash-protection)
This has been bootstrapped and regression tested on the same set of
targets {x8
On Tue, Jul 18, 2017 at 07:49:48AM -0700, H.J. Lu wrote:
> The difference is with --enable-default-pie, the gcc driver doesn't pass
> both -pie and -static ld when "-static -pie" is used. Does your change
> pass both -pie and -static ld when "-static -pie" is used?
Again, as I said in the origin
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00178.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01334.html
Thanks,
Naveen
On 19/07/17 01:17 +0100, Jonathan Wakely wrote:
This fixes a crash that happens in std::filebuf when a large read
consumes the entire get area and is followed by a write, which is then
synced to the file by a call to overflow.
The problem is that xsgetn calls _M_set_buffer(0) after reading from
This fixes a crash that happens in std::filebuf when a large read
consumes the entire get area and is followed by a write, which is then
synced to the file by a call to overflow.
The problem is that xsgetn calls _M_set_buffer(0) after reading from
the file (i.e. when in 'read' mode). As the comme
This patch by Than McIntosh changes the Go frontend, in
Func_expression::do_get_backend, when creating the backend
representation for a closure, to create a backend type conversion to
account for potential differences between the closure struct type
(where the number of fields is dependent on the n
Libgo had two identical copies of runtime_osinit. They set
runtime_ncpu, a variable that is no longer used. Removing that leaves
us with two lines. Inline those two lines in the two places the
function was called. This fixes GCC PR 81451. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.
The code in Named_type::do_get_backend in the Go frontend was not
passing the correct flag value for circular function types to
Backend::circular_pointer_type (it was always setting this flag to
false). This patch by Than McIntosh passes a true value if the type
being converted is a function type.
Hi!
On Mon, Jul 17, 2017 at 02:15:00PM -0500, Steven Munroe wrote:
> Correct the problems Segher found in review and added a changes to deal
> with the fallout from the __builtin_cpu_supports warning for older
> distros.
>
> Tested on P8 LE and P6/P7/P8 BE. No new tests failures.
>
> ./gcc/Chang
On Tue, 2017-07-18 at 16:54 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote:
> > After a resent GCC change the previously submitted BMI/BMI2 intrinsic
> > test started to fail with the following warning/error.
> >
> > ppc_cpu_supports_hw_av
This patch should fix PR 81324 filed against libgo. With some
versions of glibc and GNU/Linux ptrace_pseeksiginfo_args is defined in
both and . We don't actually care about
the struct, so use a #define to avoid a redefinition error.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Commi
Hi!
On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote:
> After a resent GCC change the previously submitted BMI/BMI2 intrinsic
> test started to fail with the following warning/error.
>
> ppc_cpu_supports_hw_available122373.c: In function 'main':
> ppc_cpu_supports_hw_available122373.
This patch modifies the change I made on July 12th. It modifies the test for
the __builtin_cpu_is and __builtin_cpu_supports built-in functions to use an
#ifdef instead of target-requires for doing the tests. One motavation is to
make the back port to GCC 6/7 easier, as I won't have to back port
* Jeff Law:
> On 06/28/2017 12:45 AM, Florian Weimer wrote:
>> * Richard Earnshaw:
>>
>>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt
>>> going on here. As Wilco points out, we can never defend against a
>>> function that is built without probe operations but skips t
On Sat, Jul 15, 2017 at 9:47 PM, Alexander Monakov wrote:
> The reload_pseudo_compare_func comparator, when used from assign_by_spills,
> can be non-transitive, indicating A < B < C < A if both A and C satisfy
> !bitmap_bit_p (&non_reload_pseudos, rAC), but B does not.
>
> This function was origin
We here have an AND of a SUBREG of an LSHIFTRT. If that SUBREG is
paradoxical, the extraction we form is the length of the size of the
inner mode, which includes some bits that should not be in the result.
Just give up in that case.
Tested on powerpc64-linux {-m32,-m64} and on x86_64-linux. Comm
... if it is an IOR with a constant with all bits set in the mode
that is truncated to, for example. Handle that case.
With this patch the problematic situation for the PR81423 testcase
isn't even reached; but the next patch fixes that anyway.
Bootstrapped and tested on powerpc64-linux {-m32,-m6
On 07/18/2017 06:59 PM, Jakub Jelinek wrote:
On Tue, Jul 18, 2017 at 06:48:56PM +0200, Tom de Vries wrote:
Hi,
this patch fixes PR81464, an ICE in ompexpssa.
The ICE occurs in expand_omp_for_static_chunk when we're trying to fix up a
loop exit phi:
...
# .MEM_88 = PHI <.MEM_86(46), .MEM_86(
On 18/07/2017 16:03, Ville Voutilainen wrote:
On 18 July 2017 at 16:31, Jonathan Wakely wrote:
This is quite a huge change, so I'd like to wait and see if anyone
else has any opinion on it.
Personally I think it's necessary (assuming I understand the PR
correctly) and so if nobody objects I th
On 07/14/2017 09:48 AM, Nathan Sidwell wrote:
This changes dbxout and dwarf2out.
Oh, the patch series survived a bootstrap on x86_64-linux.
Changes to the debug info files requires a gdb make check with and
without the patch to check for regressions. Since you are changing both
dbxout and
On Tue, Jul 11, 2017 at 11:24:43AM -0400, David Malcolm wrote:
> OK for trunk? (assuming the rest is approved)
This is ok. I'll have to play with this some more before I approve the C part.
Thanks,
Marek
On Mon, 17 Jul 2017, Alexander Monakov wrote:
> On Mon, 17 Jul 2017, Marc Glisse wrote:
> > > +/* Combine successive multiplications. Similar to above, but handling
> > > + overflow is different. */
> > > +(simplify
> > > + (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2)
> > > + (with {
> > > +
On Tue, Jul 18, 2017 at 06:48:56PM +0200, Tom de Vries wrote:
> Hi,
>
> this patch fixes PR81464, an ICE in ompexpssa.
>
> The ICE occurs in expand_omp_for_static_chunk when we're trying to fix up a
> loop exit phi:
> ...
> # .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)>
> ...
That is something tha
On Tue, Jul 18, 2017 at 10:47:37AM -0600, Martin Sebor wrote:
> On 07/18/2017 09:43 AM, Jakub Jelinek wrote:
> > On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote:
> > > > --- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200
> > > > +++ gcc/match.pd2017-07-18 12:32:52.8969
Hi,
this patch fixes PR81464, an ICE in ompexpssa.
The ICE occurs in expand_omp_for_static_chunk when we're trying to fix
up a loop exit phi:
...
# .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)>
...
It's a loop exit phi with equal arguments, which means that the variable
has the same value when
On 07/18/2017 09:43 AM, Jakub Jelinek wrote:
On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote:
--- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200
+++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200
@@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&
On Thu, 13 Jul 2017, Iain Buclaw wrote:
>> As per message on the D language being accepted, this adds myself as a
>> maintainer of the D front-end and libphobos runtime library.
> I may have to request a ping here.
I would commit this when the first bits of D go in. (Technically you
could commit
Hello!
Attached patch tightens rorx operand 2 predicate to allow only
const_int RTXes that are also allowed by the operand constraint. This
prevents combine to propagate unsupported const_ints to the pattern.
2017-07-18 Uros Bizjak
PR target/81471
* config/i386/i386.md (rorx_immediate
We ended up in infinite recursion between extract_muldiv_1 and
fold_plusminus_mult_expr, because one turns this expression into the other
and the other does the reverse:
((2147483648 / 0) * 2) + 2 <-> 2 * (2147483648 / 0 + 1)
I tried (unsuccessfully) to fix it in either extract_muldiv_1 or
fold_p
On Tue, 18 Jul 2017, Jakub Jelinek wrote:
On Tue, Jul 18, 2017 at 05:35:54PM +0200, Marc Glisse wrote:
On Tue, 18 Jul 2017, Jakub Jelinek wrote:
In the PR Marc noted that the optimization might be useful even for
constants other than 1, by transforming
x+C1 <= C2 if unsigned and C2-C1==INT_MA
On Tue, Jul 18, 2017 at 05:35:54PM +0200, Marc Glisse wrote:
> On Tue, 18 Jul 2017, Jakub Jelinek wrote:
>
> > In the PR Marc noted that the optimization might be useful even for
> > constants other than 1, by transforming
> > x+C1 <= C2 if unsigned and C2-C1==INT_MAX into (int)x > (int)(-1-C1).
>
On 07/13/2017 03:26 AM, Christophe Lyon wrote:
> I have executed a validation of your patch series on aarch64 and arm
> targets, and I have minor comments.
>
> On arm, all new tests are unsupported, as expected.
Good.
> On aarch64-linux, the new tests pass, but they fail on aarch64-elf:
> - FAI
On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote:
> > --- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200
> > +++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200
> > @@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > && wi::neg_p (@1, TYPE_SIGN (TREE_TYPE (@1)))
On Tue, 18 Jul 2017, Jakub Jelinek wrote:
In the PR Marc noted that the optimization might be useful even for
constants other than 1, by transforming
x+C1 <= C2 if unsigned and C2-C1==INT_MAX into (int)x > (int)(-1-C1).
(int)x >= (int)(-C1) might be easier (and more valid, except that the only
On Tue, Jul 18, 2017 at 05:21:42PM +0200, Marc Glisse wrote:
> On Tue, 18 Jul 2017, Jakub Jelinek wrote:
>
> > +/* X / C1 op C2 into a simple range test. */
> > +(for cmp (simple_comparison)
> > + (simplify
> > + (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
> > + (if (INTEGRAL_TYPE_P (TRE
--- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200
+++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200
@@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& wi::neg_p (@1, TYPE_SIGN (TREE_TYPE (@1
(cmp @2 @0))
+/* (X - 1U) <= INT_MAX-1U into (int) X
On Tue, 18 Jul 2017, Jakub Jelinek wrote:
+/* X / C1 op C2 into a simple range test. */
+(for cmp (simple_comparison)
+ (simplify
+ (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+ && integer_nonzerop (@1)
+ && !TREE_OVERFLOW (@1)
+
As I mentioned in my previous patch, we currently have
TYPE_{MIN,MAX}_VALUES for numeric types and TYPE_{MIN,MAX}VAL for
type-agnostic access.
This patch renames the latter to TYPE_{MIN,MAX}VAL_RAW, matching
TYPE_VALUES_RAW, which had a similar problem.
While renaming the macros, I reordered
On Tue, Jul 18, 2017 at 7:09 AM, Alan Modra wrote:
> On Tue, Jul 18, 2017 at 05:36:49AM -0700, H.J. Lu wrote:
>> I am working on compiling libc.a in glibc with -fPIE and building static
>> PIE. This creates static executable with PIE:
>>
>> gcc -nostdlib -nostartfiles -static -o
>> /export/build/
On Tue, Jul 18, 2017 at 05:36:49AM -0700, H.J. Lu wrote:
> I am working on compiling libc.a in glibc with -fPIE and building static
> PIE. This creates static executable with PIE:
>
> gcc -nostdlib -nostartfiles -static -o
> /export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/sln -pie
> -Wl
On 18 July 2017 at 16:31, Jonathan Wakely wrote:
> This is quite a huge change, so I'd like to wait and see if anyone
> else has any opinion on it.
>
> Personally I think it's necessary (assuming I understand the PR
> correctly) and so if nobody objects I think we should go with this
> change for
The following fixes SLP loads with gaps in the case of no permutation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
2017-06-18 Richard Biener
PR tree-optimization/81410
* tree-vect-stmts.c (vectorizable_load): Properly adjust for
Hi!
The following patch implements the:
/* Optimize (c>=1) && (c<=127) into (signed char)c > 0. */
if (integer_onep (low) && TREE_CODE (high) == INTEGER_CST)
{
int prec = TYPE_PRECISION (etype);
if (wi::mask (prec - 1, false, prec) == high)
{
if (TYPE_UNSIGN
Hi!
The following patch moves the fold_div_compare optimization from
generic folding only in fold-const.c to match.pd, so that it can be
excersized also when optimizing GIMPLE.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-07-18 Jakub Jelinek
PR tree-optim
On 18/07/17 14:31 +0100, Jonathan Wakely wrote:
On 17/07/17 22:54 +0200, François Dumont wrote:
This is quite a huge change, so I'd like to wait and see if anyone
else has any opinion on it.
Personally I think it's necessary (assuming I understand the PR
correctly) and so if nobody objects I thi
On 17/07/17 22:54 +0200, François Dumont wrote:
Hi
Here is the patch to fix libstdc++ versioned namespace.
Now versioned namespace is only at std and __gnu_cxx levels, not
anymore in nested namespaces.
PR libstdc++/81064
* include/bits/algorithmfwd.h: Reorganize versioned namespa
On 12/07/17 22:12 +0200, François Dumont wrote:
On 05/07/2017 17:22, Jonathan Wakely wrote:
It's mostly good, but I'd like to make a few suggestions ...
diff --git a/libstdc++-v3/include/bits/stl_list.h
b/libstdc++-v3/include/bits/stl_list.h
index 232885a..7e5 100644
--- a/libstdc++-v3/i
We currently have both TYPE_{MIN,MAX}VAL and TYPE_{MIN,MAX}_VALUE pairs
of accessors. This is confusing. The former is the tree-agnostic raw
field accessor, which I propose renaming TYPE_{MIN,MAX}VAL_RAW, as is
common with other raw accessors.
The latter pair are for accessing numeric types.
Hello,
I've received a complaint that GCC for AArch64 would generate
vectorized code relying on unaligned memory accesses even when using
-mstrict-align. This is a problem for code where such accesses lead to
memory faults.
A previous patch (r24) introduced
aarch64_builtin_support_vector_misa
On 16/07/17 17:54 -0400, Glen Fernandes wrote:
Implement pointer_traits::to_address as in P0653r0
* include/bits/allocated_ptr.h (allocated_ptr): Use
pointer_traits::to_address.
* include/bits/ptr_traits.h (pointer_traits): Implement to_address.
* include/ext/pointer.h (poin
On Tue, Jul 18, 2017 at 02:37:38PM +0200, Tom de Vries wrote:
> I'd like to backport this nvptx patch to the gcc-7-branch.
>
> The patch doesn't trivially fit into the category of regression or
> documentation fix.
>
> Without this patch, when building an nvptx offloading compiler and running
> t
[ was: Re: [nvptx, committed, PR81069] Insert diverging jump alap in
nvptx_single ]
On 07/17/2017 10:41 AM, Tom de Vries wrote:
Hi,
Consider nvptx_single:
...
/* Single neutering according to MASK. FROM is the incoming block and
TO is the outgoing block. These may be the same block. Inse
On Mon, Jul 17, 2017 at 9:02 PM, Alan Modra wrote:
> On Mon, Jul 17, 2017 at 06:01:47AM -0700, H.J. Lu wrote:
>> On Mon, Jul 17, 2017 at 5:33 AM, Alan Modra wrote:
>> > On Sat, Jul 15, 2017 at 06:32:40AM -0700, H.J. Lu wrote:
>> >> On Thu, Jun 22, 2017 at 8:28 AM, Alan Modra wrote:
>> >> > PR800
In addition to the user-declared checkers, we also have a couple of 'do
we have at all' predicates. Used exactly once when completing a struct
and determining the state of the appropriate LAZY flags.
Merged with the attached patch committed to trunk. Now the two
functions are stunningly simi
On Mon, Jul 3, 2017 at 10:45 AM, Richard Sandiford
wrote:
> General predictive commoning would play havoc with loop vectorisation,
> so the current pass order is clearly the right one. But running a very
> limited form of predictive commoning before vectorisation would allow us
> to vectorise thi
On Tue, Jul 18, 2017 at 01:44:21PM +0200, Martin Liška wrote:
> gcc/testsuite/ChangeLog:
>
> 2017-07-17 Martin Liska
>
> PR sanitizer/63361
> * c-c++-common/ubsan/float-cast-overflow-1.c: Add either
> -ffloat-store or -mieee for targets that need it.
> ---
> gcc/testsuite/c-
Hello.
This should address spotted in the PR, where I basically implemented what
I was recommended in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361#c14.
Ready for trunk?
Thanks,
Martin
>From 92ca98e49112cc164739ebd1f1a00bcc13704331 Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 17 Jul 201
Hello.
After we reverted both hunks in gimplify.c, I've just tested with
--enable-languages=all
that attached patch works.
May I ask you Eric to fix comment in:
/* The operand may be a void-valued expression such as SAVE_EXPRs
generated by the Java frontend for class initializati
> > It should be a match.pd rule that uses a match predicate, so expand in
> > gimple-match.c. but don't do this if the target doesn't have the
> > xorsign optab and don't do it if honouring SNAN.
>
> Note that this will trigger too early (IMHO), so unless you feel like
> inventing
> new infrastr
On Tue, Jul 18, 2017 at 11:13 AM, Bin.Cheng wrote:
> On Tue, Jul 18, 2017 at 9:31 AM, Richard Biener
> wrote:
>> On Tue, Jul 18, 2017 at 10:00 AM, Bin Cheng wrote:
>>> Hi,
>>> I removed unsafe loop optimization on TREE level last year, so GCC doesn't
>>> do unsafe
>>> loop optimizations on TREE
On Tue, 18 Jul 2017, Tamar Christina wrote:
>
> > I see. But the implementation challenge is that this interacts badly with
> > SSA
> > coalescing done before this and thus should really happen on GIMPLE before
> > that.
> >
> > And yes, I also like to see more of this, it's basically doing so
> I see. But the implementation challenge is that this interacts badly with SSA
> coalescing done before this and thus should really happen on GIMPLE before
> that.
>
> And yes, I also like to see more of this, it's basically doing some
> instruction
> selection on (late) GIMPLE. Ideally we'd
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators. The file is available at:
http://translationproject.org/latest/gcc/uk.po
(This file, 'gcc-7.1.0.uk.po', has ju
On 2017.07.18 at 09:54 +0200, Jan Hubicka wrote:
> Hi,
> this patch fixes ICE in estimate_bb_frequencies which triggers because we
> forget
> to compute probability for blocks whose count is earlier statically
> determined to be
> 0.
>
> Bootstrapped/regtested x86_64-linux, will commit it shortl
On Tue, 18 Jul 2017, Tamar Christina wrote:
> >
> > Why's this now done during RTL expansion rather than during late GIMPLE,
> > using match.pd and an internal function for xorsign?
> >
>
> Mainly because of Andrew's email on the 10th which stated:
>
> > But you should get the general idea. I
From: claziss
We miss the assembler testing if it supports gdwarf2 in our configure file.
Ok to apply?
Claudiu
gcc/
2017-06-21 Claudiu Zissulescu
* configure.ac: Add arc and check if assembler supports gdwarf2.
* configure: Regenerate.
---
gcc/configure| 6 +++---
gcc/c
https://gcc.gnu.org/r250301
https://gcc.gnu.org/r250302
Removed usage of INT8_MIN and friends as they are not available
in older C++ which leads to build failure.
Applied to trunk and v7 branch.
Johann
gcc/
Backport from 2017-07-18 trunk r250301.
PR target/81473
* conf
On 07/12/2017 05:11 PM, Robin Dapp wrote:
> gcc/ChangeLog:
>
> 2017-07-12 Robin Dapp
>
> * (vect_enhance_data_refs_alignment):
> Remove body_cost_vec from _vect_peel_extended_info.
> tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost):
> Do not set body_cost_vec.
>
> Why's this now done during RTL expansion rather than during late GIMPLE,
> using match.pd and an internal function for xorsign?
>
Mainly because of Andrew's email on the 10th which stated:
> But you should get the general idea. I would like to see more of these
> special expand patterns r
On Tue, Jul 18, 2017 at 9:31 AM, Richard Biener
wrote:
> On Tue, Jul 18, 2017 at 10:00 AM, Bin Cheng wrote:
>> Hi,
>> I removed unsafe loop optimization on TREE level last year, so GCC doesn't
>> do unsafe
>> loop optimizations on TREE now. All "unsafe loop optimizations" warnings
>> reported
On Mon, Jul 17, 2017 at 1:09 PM, Christophe Lyon
wrote:
> On 17 July 2017 at 12:06, Bin.Cheng wrote:
>> On Mon, Jul 10, 2017 at 10:32 AM, Christophe Lyon
>> wrote:
>>> Hi Bin,
>>>
>>> On 30 June 2017 at 12:43, Bin.Cheng wrote:
On Wed, Jun 28, 2017 at 2:09 PM, Bin.Cheng wrote:
> On Wed
On 05/07/17 16:14, Kyrill Tkachov wrote:
On 27/06/17 23:29, Jeff Law wrote:
On 06/06/2017 02:25 AM, Kyrill Tkachov wrote:
Hi all,
I'm trying to improve some of the RTL-level handling of vector lane
operations on aarch64 and that
involves dealing with a lot of vec_merge operations. One simpli
On 05/07/17 16:14, Kyrill Tkachov wrote:
On 27/06/17 23:28, Jeff Law wrote:
On 06/06/2017 02:35 AM, Kyrill Tkachov wrote:
Hi all,
Another vec_merge simplification that's missing is transforming:
(vec_merge (vec_duplicate x) (vec_concat (y) (z)) (const_int N))
into
(vec_concat x z) if N == 1
On Tue, Jul 18, 2017 at 8:45 AM, Jan Hubicka wrote:
>> Hi all,
>>
>> Currently all cases in switch statement are treated as having equal
>> probabilities which causes suboptimal code as demonstrated in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 . This patch
>> modifies expander to selec
On 07/17/2017 03:15 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 17 Jul 2017, Martin Liška wrote:
>
>> which does all the stack preparation (including the problematic call to
>> __asan_stack_malloc_N).
>>
>> Note that this code still should be placed before parm_birth_note as we
>> cant's say t
On Mon, 10 Jul 2017, Tamar Christina wrote:
> Hi All,
>
> I've re-spun the patch with the changes requested.
>
>
> This is only done when not honoring signaling NaNs.
> This transormation is done at expand time by using
> a new optab "xorsign". If the optab is not available
> then copysign is e
On Tue, Jul 18, 2017 at 10:00 AM, Bin Cheng wrote:
> Hi,
> I removed unsafe loop optimization on TREE level last year, so GCC doesn't do
> unsafe
> loop optimizations on TREE now. All "unsafe loop optimizations" warnings
> reported by
> TREE optimizers are simply missed optimizations. This pat
On Mon, Jul 17, 2017 at 10:27 AM, Jan Hubicka wrote:
>> Hi all,
>>
>> This is a new version of previous patch
>> (https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00020.html), fixed
>> after Rainer's remarks.
> Hi,
> the patch looks OK, but I wonder why you included can_be_discarded check?
> If funct
On Fri, Jul 14, 2017 at 7:59 AM, Marc Glisse wrote:
> On Thu, 13 Jul 2017, Alexander Monakov wrote:
>
>> On Thu, 13 Jul 2017, Marc Glisse wrote:
>>>
>>> I notice that we do not turn (X*10)*10 into X*100 in GIMPLE.
>>
>>
>> Sorry, could you clarify what you mean here? I think we certainly do
>> th
1 - 100 of 116 matches
Mail list logo
