On Jun 9, 2017, at 6:57 AM, Simon Wright wrote:
>
> This PR was raised because of a bootstrap failure on Darwin.
> A question: I've checked for x86_64-apple-darwin*, is this OK or
> should it be more restrictive?
That seems ok.
Ok.
If anyone sees any fallout from this, please speak up. I'm h
Hi Carl,
On Wed, Jun 28, 2017 at 08:37:35AM -0700, Carl Love wrote:
> The following patch adds support for the vec_signed, vec_signede,
> vec_signedo and vec_signed2 builtins.
Are those names ABI-dictated?
> * config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPSXWS, UNSPEC_VSX_XVCVSPSXDS,
> UNSP
On Wed, Jun 28, 2017 at 2:02 AM, Kugan Vivekanandarajah
wrote:
> Hi Ramana,
>
> On 27 June 2017 at 18:01, Ramana Radhakrishnan
> wrote:
>> On 27/06/17 02:20, Kugan Vivekanandarajah wrote:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html added this
>>> workaround to get kernel bui
On Wed, Jun 28, 2017 at 09:42:46AM -0600, Kelvin Nilsen wrote:
> Is the attached refinement of this patch previously applied to mainline
> ok for backport to gcc 6? I have bootstrapped and tested without
> regressions on powerpc64le-unknown-linux-gnu.
After 6.4 please.
Segher
On Wed, Jun 28, 2017 at 05:04:37PM -0400, Michael Meissner wrote:
> > Why did you use check_runtime_nocache btw? Is that just copy-paste?
>
> Just copy-paste.
>
> Like the target_clones stuff, right now, it is only x86 and PowerPC that
> supports __builtin_cpu*.
>
> I don't really see the point
On 06/27/2017 03:56 AM, Chung-Lin Tang wrote:
> On 2017/6/27 6:45 AM, Cesar Philippidis wrote:
>>> (1) Instead of essentially implementing the entire OpenACC async support
>>> inside the plugin, we now use an opaque 'goacc_asyncqueue' implemented
>>> by the plugin, along with core 'test', 'synchron
Hi Carl,
On Wed, Jun 28, 2017 at 10:57:52AM -0700, Carl Love wrote:
> The vec_reve builtin test builtins-3-vec_reve-runnable did not have a
> minimum Power processor specified. The thought was the instructions for
> the builtin were available on all the older processors. Unfortunately,
> it turn
On Wed, 2017-03-15 at 16:35 -0400, Jason Merrill wrote:
> On Tue, Mar 14, 2017 at 9:05 PM, David Malcolm
> wrote:
> > OK for trunk now, or should this wait until stage 1?
>
> Stage 1.
>
> > + cp_token *close_paren = cp_parser_require (parser,
> > CPP_CLOSE_PAREN,
> > +
On Wed, Jun 28, 2017 at 03:21:49PM -0500, Aaron Sawdey wrote:
> > It is probably nicer to have a separate function for
> > toc_relative_expr_p
> > and one to pull the base/offset out. And maybe don't keep it cached
> > for
> > the output function either? It has all info it needs, right, the
> > f
On Fri, Jun 16, 2017 at 8:39 AM, Denis Khalikov
wrote:
> Hello everyone,
>
> This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
>
> Can some one please review attached patch.
Sorry to take so long about this. It's a lot to look at.
> diff --git a/libbacktrace/ChangeLog b/l
On 06/28/2017 11:41 AM, Joseph Myers wrote:
On Wed, 28 Jun 2017, Martin Sebor wrote:
I don't think there is an equivalent, dedicated trait in C++ to
do that either. One would have to be composed of the lower-level
ones. There also is no trait that would remove all type qualifiers
(including e
With the fix to PR51513 and follow on fixes for PR80707, PR80775 and PR80823,
we can now end up with switch statements that contain nothing but a default
case statement. The expand_case() function contains code that assumes we
have at least one non-default case statement, leading to the ICE report
Hi,
The code (m1 > m2) * d code should be optimized as m1> m2 ? d : 0.
The patch optimizes it inside tree-vrp.c when simplifying with the range
inside simplify_stmt_using_ranges. If a multiply is found and either side
has a range [0,1], then transform it.
Ex:- d * c where d has a range of [0,1]
101 - 113 of 113 matches
Mail list logo
