On Thu, Aug 17, 2017 at 5:43 PM, Alexander Monakov wrote:
> On Thu, 17 Aug 2017, Wilco Dijkstra wrote:
>
>> This patch simplifies pow (C, x) into exp (x * C1) if C > 0, C1 = log (C).
>
> Note this changes the outcome for C == +Inf, x == 0 (pow is specified to
> return 1.0 in that case, but x * C1
There are several places that test whether:
TYPE_PRECISION (t) == GET_MODE_PRECISION (TYPE_MODE (t))
for some integer type T. With SVE variable-length modes, this would
need to become:
TYPE_PRECISION (t) == GET_MODE_PRECISION (SCALAR_TYPE_MODE (t))
(or SCALAR_INT_TYPE_MODE, it doesn't
This patch adds a partial_integral_type_p function, to go along
with the full_integral_type_p added by the previous patch.
Of the changes that didn't previously have an INTEGRAL_TYPE_P check:
- the convert_to_integer_1 hunks are dominated by a case version
of INTEGRAL_TYPE_P.
- the merge_range
On 4 August 2017 at 15:52, Yvan Roux wrote:
> On 11 July 2017 at 12:25, Yvan Roux wrote:
>> On 3 July 2017 at 11:21, Yvan Roux wrote:
>>> On 23 June 2017 at 15:44, Yvan Roux wrote:
Hello,
Fortran parts of libgomp (omp_lib.mod, openacc.mod, etc...) are
missing in a canadian c
On 4 August 2017 at 15:52, Yvan Roux wrote:
> On 13 July 2017 at 14:02, Yvan Roux wrote:
>> Hi,
>>
>> as discussed in the PR, this patch adds a new reduced testcase which
>> doesn't rely on c++17 features, this is a prereq to the backport of
>> the fix into GCC 6 branch which is impacted by this
Hi,
As a followup patch for fix to PR81832, this patch considers internal function
call to
IFN_LOOP_DIST_ALIAS and IFN_LOOP_VECTORIZED as expensive. Or interpreted
in another way: return false since we shouldn't be asked the question? Any
comments?
BTW, I have no problem to drop this if not app
On Fri, Aug 18, 2017 at 10:45 AM, Bin Cheng wrote:
> Hi,
> As a followup patch for fix to PR81832, this patch considers internal
> function call to
> IFN_LOOP_DIST_ALIAS and IFN_LOOP_VECTORIZED as expensive. Or interpreted
> in another way: return false since we shouldn't be asked the question?
On Tue, Aug 15, 2017 at 2:37 PM, Martin Liška wrote:
> On 08/14/2017 10:32 AM, Richard Biener wrote:
>> Hmm, but the existing "lowering" part is called from the
>> switch-conversion pass. So
>> I'm not sure a new file is good.
>
> Good, I'm not against having that in a single file. So new version
On Wed, Aug 16, 2017 at 3:32 PM, Georg-Johann Lay wrote:
> On 28.07.2017 09:34, Richard Biener wrote:
>>
>> On Thu, Jul 27, 2017 at 3:32 PM, Georg-Johann Lay wrote:
>>>
>>> On 27.07.2017 14:34, Richard Biener wrote:
On Thu, Jul 27, 2017 at 2:29 PM, Georg-Johann Lay wrote:
>
>>
On Tue, Aug 15, 2017 at 1:16 PM, Richard Biener
wrote:
> On Sat, Aug 12, 2017 at 11:09 AM, Pierre-Marie de Rodat
> wrote:
>> On 08/11/2017 11:29 PM, Jason Merrill wrote:
>>>
>>> OK.
>>
>>
>> Committed. Thank you for your sustained review effort, Jason. :-)
>
> The way you use decl_ultimate_origin
On 08/15/2017 02:45 PM, Martin Liška wrote:
> Hi.
>
> As shown in the PR, remove_prefix function is written wrongly. It does not
> distinguish
> in between a node in linked list and pprefix->plist. So I decide to rewrite
> it.
> Apart from that, I identified discrepancy in between do_add_prefix
On 08/18/2017 11:30 AM, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 2:37 PM, Martin Liška wrote:
>> On 08/14/2017 10:32 AM, Richard Biener wrote:
>>> Hmm, but the existing "lowering" part is called from the
>>> switch-conversion pass. So
>>> I'm not sure a new file is good.
>>
>> Good, I'm no
On Thu, Aug 17, 2017 at 2:24 PM, Bin.Cheng wrote:
> On Thu, Aug 17, 2017 at 12:35 PM, Richard Sandiford
> wrote:
>> "Bin.Cheng" writes:
>>> On Wed, Aug 16, 2017 at 6:50 PM, Richard Sandiford
>>> wrote:
"Bin.Cheng" writes:
> On Wed, Aug 16, 2017 at 5:00 PM, Richard Sandiford
> wro
On Fri, Aug 18, 2017 at 12:30 PM, Richard Biener
wrote:
> On Thu, Aug 17, 2017 at 2:24 PM, Bin.Cheng wrote:
>> On Thu, Aug 17, 2017 at 12:35 PM, Richard Sandiford
>> wrote:
>>> "Bin.Cheng" writes:
On Wed, Aug 16, 2017 at 6:50 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>>
On Fri, Aug 18, 2017 at 10:10 AM, Richard Sandiford
wrote:
> There are several places that test whether:
>
> TYPE_PRECISION (t) == GET_MODE_PRECISION (TYPE_MODE (t))
>
> for some integer type T. With SVE variable-length modes, this would
> need to become:
>
> TYPE_PRECISION (t) == GET_MOD
Richard Biener writes:
> On Fri, Aug 18, 2017 at 10:10 AM, Richard Sandiford
> wrote:
>> There are several places that test whether:
>>
>> TYPE_PRECISION (t) == GET_MODE_PRECISION (TYPE_MODE (t))
>>
>> for some integer type T. With SVE variable-length modes, this would
>> need to become:
>>
On Thu, 17 Aug 2017, Martin Sebor wrote:
> PPS To make use of this checking (and compile without the new
> warnings) Glibc needs the following patch:
This should be submitted to libc-alpha (independently of the GCC patch,
presuming existing GCC versions accept the correct types).
--
Joseph S.
On Fri, Aug 18, 2017 at 1:04 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Aug 18, 2017 at 10:10 AM, Richard Sandiford
>> wrote:
>>> There are several places that test whether:
>>>
>>> TYPE_PRECISION (t) == GET_MODE_PRECISION (TYPE_MODE (t))
>>>
>>> for some integer type T
On Thu, Aug 17, 2017 at 02:17:31PM +, Joseph Myers wrote:
> On Thu, 17 Aug 2017, Marek Polacek wrote:
>
> > I've been itching to remove this code for some time now. The comment
> > suggests
> > that the code is actually unused, so I replaced the body of that "else if"
> > with
> > gcc_unrea
Alexander Monakov wrote:
>
> Note this changes the outcome for C == +Inf, x == 0 (pow is specified to
> return 1.0 in that case, but x * C1 == NaN). There's another existing
> transform with the same issue, 'pow(expN(x), y) -> expN(x*y)', so this is
> not a new problem.
>
> The whole set of these
On 17/08/17 21:21 -0600, Martin Sebor wrote:
Joseph, while looking into implementing enhancement your request
pr81824 I noticed that GCC silently accepts incompatible alias
declarations (pr81854) so as sort of a proof-concept for the
former I enhanced the checking already done for other kinds of
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, August 15, 2017 3:43 PM
> To: Tsimbalist, Igor V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
>
> On Tue, Aug 1, 2017 at 10:56 AM, Tsimbali
On Fri, Aug 18, 2017 at 2:47 PM, Wilco Dijkstra wrote:
> Alexander Monakov wrote:
>>
>> Note this changes the outcome for C == +Inf, x == 0 (pow is specified to
>> return 1.0 in that case, but x * C1 == NaN). There's another existing
>> transform with the same issue, 'pow(expN(x), y) -> expN(x*y)
On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 15, 2017 3:43 PM
>> To: Tsimbalist, Igor V
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: 0001-Part-1.-Add-generic-part-for
On 16/08/17 16:38 -0600, Martin Sebor wrote:
Jon,
Attached is the libstdc++ only patch to remove the pointless
const attribute from __pool::_M_destroy_thread_key(void*).
https://gcc.gnu.org/ml/gcc/2017-08/msg00027.html
I only belatedly now broke it out of the larger patch under
review here:
On Mon, Jul 31, 2017 at 7:35 AM, Jeff Law wrote:
> This patch introduces the stack clash protection options
>
> Changes since V2:
>
> Adds two new params. The first controls the size of the guard area.
> This controls the threshold for when a function prologue requires
> probes. The second contr
On Mon, Jul 31, 2017 at 7:38 AM, Jeff Law wrote:
>
> This patch introduces generic mechanisms to protect the dynamically
> allocated stack space against stack-clash attacks.
>
> Changes since V2:
>
> Dynamic allocations can be emitted as unrolled inlined probes or with a
> rotated loop. Blockage
This libgo patch by Tony Reix fixes the cgo tests for AIX.
Bootstrapped and ran testsuite on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 251179)
+++ gcc
On Mon, Jul 31, 2017 at 7:41 AM, Jeff Law wrote:
> This patch introduces some routines for logging of stack clash
> protection actions.
>
> I don't think this patch changed at all relative to V2.
Ok.
Richard.
>
> Jeff
>
>
> * function.c (dump_stack_clash_frame_info): New function.
>
On 18.08.2017 12:01, Richard Biener wrote:
On Wed, Aug 16, 2017 at 3:32 PM, Georg-Johann Lay wrote:
On 28.07.2017 09:34, Richard Biener wrote:
On Thu, Jul 27, 2017 at 3:32 PM, Georg-Johann Lay wrote:
On 27.07.2017 14:34, Richard Biener wrote:
On Thu, Jul 27, 2017 at 2:29 PM, Georg-Johann La
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, August 18, 2017 3:53 PM
> To: Tsimbalist, Igor V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
>
> On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalis
The current implementation does miss a lot of constexpr in
basic_string_view. (Bug 70483)
The patch adds the missing constexpr's as required by C++17. I did run
the the stdlibc++-v3 testsuite and got no errors. I didn't changes the
basic_string_view test cases, because I couldn't find a pattern in
This patch adds some documentation on asm memory constraints, aimed
especially at constraints for arrays. I may have invented something
new here as I've never seen "=m" (*(T (*)[]) ptr) used before.
So this isn't simply a documentation patch. It needs blessing from a
global maintainer, I think, a
On 08/18/2017 07:10 AM, Jonathan Wakely wrote:
On 17/08/17 21:21 -0600, Martin Sebor wrote:
Joseph, while looking into implementing enhancement your request
pr81824 I noticed that GCC silently accepts incompatible alias
declarations (pr81854) so as sort of a proof-concept for the
former I enhanc
Hi,
This is a friendly reminder asking for a review of the suggested patch!
Thanks,
- Daniel
2017-07-30 15:01 GMT+02:00 Daniel Krügler :
> 2017-07-28 22:40 GMT+02:00 Daniel Krügler :
>> 2017-07-28 22:29 GMT+02:00 Daniel Krügler :
>>> 2017-07-28 22:25 GMT+02:00 Tim Song :
On Fri, Jul 28, 20
On 18/08/17 08:54 -0600, Martin Sebor wrote:
On 08/18/2017 07:10 AM, Jonathan Wakely wrote:
On 17/08/17 21:21 -0600, Martin Sebor wrote:
Joseph, while looking into implementing enhancement your request
pr81824 I noticed that GCC silently accepts incompatible alias
declarations (pr81854) so as s
We introduced a regression in r214986 when changing the _Hashtable
range constructor to delegate to another constructor. That change
means that the object has completed construction after the target
constructor completes, and so if an exception is thrown in the
delegating constructor then the dest
> #01 of #08:
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01971.html
>
> #02 of #08:
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01972.html
>
> #03 of #08:
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01974.html
>
> Need to reach some kind of closure on these, then I can start pinging
While fixing PR 81891 I noticed that _Hashtable always creates a
__value_alloc_type for constructing and destroying the elements, which
is unnecessary. https://wg21.link/lwg2218 confirmed that.
We can avoid constructing new allocators just for these calls and can
call them directly on the stored
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81488 reports a problem with SLSR
where
too many memory resources are required to complete SLSR processing of
conditional
candidates. The code in question contains large trees of PHI dependencies that
must
be examined in order to find all candid
Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
PowerPC, we should do something similar for aarch64. This pattern
does show up in SPEC CPU 2006 in astar but I did not look into
performance improvement of it though.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regres
On 08/18/2017 10:48 AM, Jonathan Wakely wrote:
On 18/08/17 08:54 -0600, Martin Sebor wrote:
On 08/18/2017 07:10 AM, Jonathan Wakely wrote:
On 17/08/17 21:21 -0600, Martin Sebor wrote:
Joseph, while looking into implementing enhancement your request
pr81824 I noticed that GCC silently accepts i
On 28/07/17 18:42 +0200, François Dumont wrote:
Hi
Completing execution of the testsuite revealed a bug. So here is
the correct version of this patch.
François
On 21/07/2017 19:14, François Dumont wrote:
Hi
Here is a proposal for 2 optimizations in the std::list
implementation.
According to GCC PR 81893 the code that dumps the registers for PPC
only works for little-endian. This patch fixes it to only be used in
that case. Bootstrapped on x86_64-pc-linux-gnu, for what that's
worth. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
On Wed, Aug 16, 2017 at 06:59:50PM -0400, Michael Meissner wrote:
> This patch enables -mfloat128 to be the default on PowerPC Linux VSX systems.
>
> This patch depends on the libquadmatch/81848 patch being approved and
> installed:
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00977.html
That
On Thu, Aug 17, 2017 at 09:18:54AM -0500, Will Schmidt wrote:
> Add some testcase coverage for the vec_sums() built-in.
>
> Tested across power platforms (p6 and newer). OK for trunk?
Okay, thanks!
Segher
> * gcc.target/powerpc/fold-vec-sums-int.c: New.
On Thu, Aug 17, 2017 at 09:19:17AM -0500, Will Schmidt wrote:
> Add testcase coverage for the vec_ld intrinsic builtins.
>
> Tested across power platforms (p6 and newer). OK for trunk?
> * gcc.target/powerpc/fold-vec-ld-char.c: New.
> * gcc.target/powerpc/fold-vec-ld-double.c: New.
>
Hi Will,
On Thu, Aug 17, 2017 at 09:19:23AM -0500, Will Schmidt wrote:
> Add some Testcase coverage for the vector permute intrinsics.
>
> Tested across power platforms. OK for trunk?
> * gcc.target/powerpc/fold-vec-perm-char.c: New.
> * gcc.target/powerpc/fold-vec-perm-double.c: Ne
On Thu, 2017-08-17 at 00:47 -0500, Segher Boessenkool wrote:
> On Wed, Aug 16, 2017 at 03:50:55PM -0500, Steven Munroe wrote:
> > This it part 3/3 for contributing PPC64LE support for X86 SSE
> > instrisics. This patch includes testsuite/gcc.target tests for the
> > intrinsics included by xmmintrin
k.
This breaks gfortran.dg/alloc_comp_auto_array_2.f90 on aarch64 with
-mabi=ilp32 (only for -O3):
FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g (test for excess errors)
Excess errors:
/opt/gcc/gcc-20170818/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90:33:0:
Warning: '__built
Hi!
On Thu, Aug 17, 2017 at 07:48:54PM -0400, Michael Meissner wrote:
> This patch deletes some of the debug switches that I've added over the years,
> and now don't use any more.
>
> I did bootstrap builds and make check runs on a little endian power8 system.
> There were no regressions. Can I
On Thu, Aug 17, 2017 at 07:02:14PM -0500, Peter Bergner wrote:
> PR target/80210 exposes a problem in rs6000_set_current_function() where
> is fails to correctly clear the rs6000_previous_fndecl cache correctly.
> With the test case, we notice that rs6000_previous_fndecl is set (when it
> shouldn't
On Thu, Aug 17, 2017 at 08:40:34PM -0500, Steven Munroe wrote:
> > > +/* Convert the lower SPFP value to a 32-bit integer according to the
> > > current
> > > + rounding mode. */
> > > +extern __inline int __attribute__((__gnu_inline__, __always_inline__,
> > > __artificial__))
> > > +_mm_cvts
The C reproducers generated by gcc_jit_context_dump_reproducer_to_file
contain numerous pointer values (from %p) to ensure uniqueness of the
identifiers, but this makes them less readable than they could be.
This patch updates reproducer::make_identifier so that the pointer
is only added if it's n
On Thu, 2017-08-17 at 11:51 -0400, David Malcolm wrote:
> On Thu, 2017-08-17 at 09:15 +1200, Michael Cree wrote:
> > On Wed, Aug 16, 2017 at 10:01:57AM -0400, David Malcolm wrote:
> > > On Wed, 2017-08-16 at 21:58 +1200, Michael Cree wrote:
> > > >
> > > > But I have hit a problem which I suspect
On Fri, Aug 18, 2017 at 04:49:44PM -0500, Steven Munroe wrote:
> On Thu, 2017-08-17 at 00:47 -0500, Segher Boessenkool wrote:
> > On Wed, Aug 16, 2017 at 03:50:55PM -0500, Steven Munroe wrote:
> > > This it part 3/3 for contributing PPC64LE support for X86 SSE
> > > instrisics. This patch includes
The previous patch uncovered a bug in how c_parser_expr_list builds the
vec: it was only using the location of the first token
within each assignment-expression in the expr-list.
This shows up in e.g. this -Wformat warning, where only part of the
2nd param is underlined:
printf("hello %i", (lo
This patch passes along the vec of argument locations
at a callsite from the C frontend to check_function_arguments and
from there to c-format.c, so that we can underline the pertinent
argument to mismatched format codes even for tree codes like decls
and constants which lack a location_t for their
On 8/18/17 6:27 PM, Segher Boessenkool wrote:
> On Thu, Aug 17, 2017 at 07:02:14PM -0500, Peter Bergner wrote:
>> This is also broken in GCC 7, GCC 6 and GCC 5. Ok for those after this
>> has been on trunk for a little while and assuming testing passes?
>
> Okay for trunk and all branches. Thank
59 matches
Mail list logo
