Re: PING: Re: [patch 6/10] debug-early merge: Java front-end

On 20/05/15 23:32, Aldy Hernandez wrote: > Perhaps I should've sent this to the java-patches list. > > PING. OK, I believe it. Andrew.

Re: [nvptx] Re: Mostly rewrite genrecog

Hi! On Thu, 7 May 2015 11:14:37 +0200, Jakub Jelinek wrote: > On Thu, May 07, 2015 at 10:59:01AM +0200, Thomas Schwinge wrote: > > build/genrecog [...]/source-gcc/gcc/common.md > > [...]/source-gcc/gcc/config/nvptx/nvptx.md \ > >insn-conditions.md > tmp-recog.c > > -[...

Re: [match-and-simplify] reject expanding operator-list to implicit 'for'

On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > On 20 May 2015 at 18:18, Richard Biener wrote: > > On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > > > >> On 20 May 2015 at 17:01, Richard Biener wrote: > >> > On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > >> > > >> >> On 20 May 2015 at 16:

Re: OpenACC: initialization with unsupported acc_device_t

On Thu, May 21, 2015 at 08:55:59AM +0200, Thomas Schwinge wrote: > Thanks, looks good to me -- Jakub? Ok for trunk. > > libgomp/ > > * oacc-init.c (resolve_device): Add FAIL_IS_ERROR argument. Update > > function comment. Only call gomp_fatal if new argument is true. > > (acc_dev_

Re: [obvious fix] fix off-by-one error when printing the caret character

Manuel López-Ibáñez writes: > Index: ChangeLog > === > --- ChangeLog (revision 223445) > +++ ChangeLog (working copy) > @@ -1,3 +1,8 @@ > +2015-05-20 Manuel López-Ibáñez > + > + * diagnostic.c (diagnostic_print_caret_li

Re: [patch, libgomp] Re-factor GOMP_MAP_POINTER handling

Ping x2. On 15/5/11 7:19 PM, Chung-Lin Tang wrote: > Ping. > > On 2015/4/21 08:21 PM, Chung-Lin Tang wrote: >> Hi, >> while investigating some issues in the variable mapping code, I observed >> that the GOMP_MAP_POINTER handling is essentially duplicated under the PSET >> case. >> This patch abs

[PATCH, CHKP] Fix PR middle-end/66221: lto1: error: type variant has different TYPE_ARG_TYPES

Hi, This patch fixes PR66221 by using build_distinct_type_copy instead of copy_node to copy a function type for instrumented function. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for gcc-5? Thanks, Ilya -- gcc/ 2015-05-21 Ilya Enkovich PR

Re: [Patch AArch64] PR target/66200 - gcc / libstdc++ TLC for weak memory models.

And here's an additional patch for the testsuite which was missed in the original posting. This is a testism that's testing code generation as per TARGET_RELAXED_ORDERING being false and therefore needs to be adjusted as attached. Ramana PR target/66200 * g++.dg/abi/aarch64_guard1.C: Adjust

Re: [patch, testsuite, ARM] don't try to execute simd.exp tests on targets without NEON

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 multilibs. Inspired by what vect.exp does and my other patch

Re: [PATCH] [PATCH][ARM] Fix sibcall testcases.

On Wed, May 20, 2015 at 9:11 PM, Joseph Myers wrote: > On Wed, 20 May 2015, Alex Velenko wrote: > >> Hi, >> >> This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c >> testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed. > > arm_thumb1_ok means "this is an ARM

Re: [patch, testsuite] don't specify "dg-do run" explicitly for vect test cases

On Thu, May 21, 2015 at 7:12 AM, Sandra Loosemore wrote: > On targets such as ARM, some arches are compatible with options needed to > enable compilation with vectorization, but the specific hardware (or > simulator or BSP) available for execution tests may not implement or enable > those features

Re: [RFA] Restore combine.c split point for multiply-accumulate instructions

On Thu, May 21, 2015 at 7:38 AM, Jeff Law wrote: > > find_split_point will tend to favor splitting complex insns in such a way as > to encourage multiply-add insns. It does this by splitting an > unrecognizable insn at the (plus (mult)). > > Now that many MULTs are canonicalized as ASHIFT, that c

Re: [PATCH, CHKP] Fix PR middle-end/66221: lto1: error: type variant has different TYPE_ARG_TYPES

On Thu, May 21, 2015 at 10:38 AM, Ilya Enkovich wrote: > Hi, > > This patch fixes PR66221 by using build_distinct_type_copy instead of > copy_node to copy a function type for instrumented function. Bootstrapped > and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is it OK for > gc

[gomp4.1] Taskloop support

Hi! This patch finishes the C #pragma omp taskloop support on the gomp 4.1 branch, including library support. 2015-05-21 Jakub Jelinek * tree.h (OMP_STANDALONE_CLAUSES): Adjust to cover OMP_TARGET_{ENTER,EXIT}_DATA. (OMP_CLAUSE_SHARED_FIRSTPRIVATE): Define. * g

[Patch ARM] Fix PR target/65937

Testism introduced by last commit to fix PR26702 on arm-*-linux* targets. The fix is to restore target selector to arm*-*-eabi* as the target macro changes only affect arm*-*-eabi* Applied to trunk as obvious Ramana * gcc.target/arm/pr26702.c: Adjust target selector. Index: gcc.target/arm/pr2

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

Hello! >> From: Jeff Law [mailto:l...@redhat.com] >> Sent: Wednesday, May 13, 2015 4:05 AM >> OK for the trunk. >> >> Thanks for your patience, > > Thanks. Committed with the added "PR rtl-optimization/64616" to both > ChangeLog entries. This patch caused PR66236 [1]. [1] https://gcc.gnu.org/bug

Re: Add statistics to alias.c

On Thu, 21 May 2015, Jan Hubicka wrote: > Hi, > this patch extends statistics from tree-ssa-alias to also cover TBAA oracle. > This is useful to keep track of aliasing effectivity. For example the hack > in alias.c putting globbing all pointers to one costs about 20% of all > answers on firefox.

Re: [patch, testsuite, ARM] don't try to execute advsimd-intrinsics tests on hardware without NEON

On 21 May 2015 at 07:33, Sandra Loosemore wrote: > ARM testing shares the AArch64 advsimd-intrinsics execution tests. On ARM, > though, the NEON support being tested is optional -- some arches are > compatible with the NEON compilation options but hardware available for > testing might or might n

Re: Demangle symbols in debug assertion messages

On 20/05/15 21:45 +0200, François Dumont wrote: On 20/05/2015 12:19, Jonathan Wakely wrote: Does this fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65392 ? With the patch this code of the bug report generates the following debug message: /home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/li

Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)

I'm pinging the C++ parts. Thanks, > On Thu, May 07, 2015 at 06:22:40PM +0200, Marek Polacek wrote: > > This (third) version of the patch entails the change in tsubst_enum Ed > > suggested + new testcase. > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > 2015-05-07 Marek Po

Re: [Patch AArch64] Add cpu_defines.h for AArch64.

On 19/05/15 17:03, Ramana Radhakrishnan wrote: > On Tue, May 19, 2015 at 4:54 PM, wrote: >>> On May 19, 2015, at 5:54 AM, Ramana Radhakrishnan >>> wrote: >>> Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to >>> false as integer divide instructions do not trap. >>> >>>

Re: acc_on_device for device_type_host_nonshm

Hi! On Thu, 7 May 2015 19:32:26 +0100, Julian Brown wrote: > Here's a new version of the patch [...] > OK for trunk? Makes sense to me (with just a request to drop the testsuite changes, see below), to get the existing regressions under control. Jakub? > PR libgomp/65742 > > gcc/ >

Re: acc_on_device for device_type_host_nonshm

On Thu, May 21, 2015 at 01:02:12PM +0200, Thomas Schwinge wrote: > Hi! > > On Thu, 7 May 2015 19:32:26 +0100, Julian Brown > wrote: > > Here's a new version of the patch [...] > > > OK for trunk? > > Makes sense to me (with just a request to drop the testsuite changes, see > below), to get the

Re: [nvptx] Re: Mostly rewrite genrecog

On 05/21/2015 09:12 AM, Thomas Schwinge wrote: OK to commit? gcc/ * config/nvptx/nvptx.md (allocate_stack): Rename to... (allocate_stack_): ... this, and add :P on both match_operand and unspec. (allocate_stack): New expander. If you really want to. It

[gomp4] Vector-single predication

This uses the patch I committed yesterday which introduces warp broadcasts to implement the vector-single predication needed for OpenACC. Outside a loop with vector parallelism, only one of the threads representing a vector must execute, the others follow along. So we skip the real work in each

Re: [gomp4] Vector-single predication

On Thu, May 21, 2015 at 01:42:11PM +0200, Bernd Schmidt wrote: > This uses the patch I committed yesterday which introduces warp broadcasts > to implement the vector-single predication needed for OpenACC. Outside a > loop with vector parallelism, only one of the threads representing a vector > must

Re: [PATCH 4/7] don't compare ARG_FRAME_POINTER_REGNUM and FRAME_POINTER_REGNUM with the preprocessor

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-05-20 Trevor Saunders * *.c: Remove comparison of ARG_FRAME_POINTER_REGNUM and FRAME_POINTER_REGNUM with the preprocessor. This only hits a handful of files. If you could go

Re: [PATCH 5/7] always define HAVE_conditional_move

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-05-20 Trevor Saunders * genconfig.c (main): Always define HAVE_conditional_move. * *.c: Don't check if HAVE_conditional_move is defined. Again, you're hitting just a handful of files,

Re: [PATCH 6/7] remove #if HAVE_conditional_move

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-05-20 Trevor Saunders * *.c, *.h: DOn't check HAVE_conditional_move with the preprocessor. You know what I'm going to say here :-) FWIW, I think just mentioning the filename is fine

Re: [PATCH 3/7] move default for STACK_PUSH_CODE to defaults.h

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-05-20 Trevor Saunders * defaults.h: Add default for STACK_PUSH_CODE. * expr.c: Don't redefine STACK_PUSH_CODE. * recog.c: Likewise. OK. jeff

Re: [PATCH 2/7] remove most ifdef STACK_GROWS_DOWNWARD

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/c-family/ChangeLog: 2015-05-20 Trevor Saunders * c-cppbuiltin.c (c_cpp_builtins): Use if instead of #if with STACK_GROWS_DOWNWARD. gcc/ChangeLog: 2015-05-20 Trevor Saunders * *.

Re: [PATCH 1/7] always define STACK_GROWS_DOWNWARD

On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/c-family/ChangeLog: 2015-05-20 Trevor Saunders * c-cppbuiltin.c (c_cpp_builtins): Check the value of STACK_GROWS_DOWNWARD rather than if it is defined. gcc/ChangeLog: 2015-05-20 Trevor Sau

Re: [patch, testsuite] don't specify "dg-do run" explicitly for vect test cases

On 05/20/2015 11:12 PM, Sandra Loosemore wrote: On targets such as ARM, some arches are compatible with options needed to enable compilation with vectorization, but the specific hardware (or simulator or BSP) available for execution tests may not implement or enable those features. The vect.exp

Re: [SH][committed] Fix gcc.target/sh/pr54236-2.c failures

On Tue, 2015-05-19 at 10:04 +0200, Oleg Endo wrote: > Since a recent change to the tree optimizers > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00089.html > some related SH patterns stopped working. The attached patch fixes > this. > > Tested briefly with 'make all' and with > make -k check-gc

[Patch]: libbacktrace - add support of PE/COFF

Hello, this patch adds basic support to libbacktrace for PE32 and PE32+ (Windows and Windows64 object formats). Support is ‘basic’ because neither DLL nor PIE (if that exists) are handled. Furthermore, there is no windows versions of mmapio.c and mmap.c Finally, I have disabled the support of d

[PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

X32 doesn't support indirect branch via 32-bit memory slot since indirect branch will load 64-bit address from 64-bit memory slot. Since x32 GOT slot is 64-bit, we should allow indirect branch via GOT slot for x32. I am testing it on x32. OK for master if there is no regression? Thanks. H.J. -

Re: [patch, libgomp] Re-factor GOMP_MAP_POINTER handling

Hi! Jakub, for avoidance of doubt, the proposed refactoring makes sense to me, but does need your approval: On Thu, 21 May 2015 16:30:40 +0800, Chung-Lin Tang wrote: > Ping x2. > > On 15/5/11 7:19 PM, Chung-Lin Tang wrote: > > Ping. > > > > On 2015/4/21 08:21 PM, Chung-Lin Tang wrote: > >> Hi

Re: [gomp4] Vector-single predication

On Thu, 21 May 2015 13:57:00 +0200 Jakub Jelinek wrote: > On Thu, May 21, 2015 at 01:42:11PM +0200, Bernd Schmidt wrote: > > This uses the patch I committed yesterday which introduces warp > > broadcasts to implement the vector-single predication needed for > > OpenACC. Outside a loop with vector

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: > X32 doesn't support indirect branch via 32-bit memory slot since > indirect branch will load 64-bit address from 64-bit memory slot. > Since x32 GOT slot is 64-bit, we should allow indirect branch via GOT > slot for x32. > > I am testing it on x32.

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

Ping 2015-05-05 14:05 GMT+03:00 Ilya Enkovich : > 2015-04-21 8:52 GMT+03:00 Jeff Law : >> On 04/17/2015 02:34 AM, Ilya Enkovich wrote: >>> >>> On 15 Apr 14:07, Ilya Enkovich wrote: 2015-04-14 8:22 GMT+03:00 Jeff Law : > > On 03/15/2015 02:30 PM, Richard Sandiford wrote: >> >>

[PATCH] Fix PR66211

The following papers over the C++ FE issue that it doesn't track lvalueness before folding stuff. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2015-05-21 Richard Biener PR c++/66211 * match.pd: Guard pattern optimzing (int)(float)int

Re: [gomp4] Vector-single predication

On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > OpenACC handles function calls specially (calling them "routines" -- of > varying sorts, gang, worker, vector or seq, affecting where they can be > invoked from). The plan is that all threads will call such routines -- > and then some

[Ada] Allow constants in SPARK contracts

This patch permits constants to appear in the following SPARK annotations: Depends Global Initializes Part_Of Refined_Depends Refined_Global Refined_State -- Source -- -- legal_usage.ads package Legal_Usage with SPARK_Mode, Abstract_State

Re: [patch, libgomp] Re-factor GOMP_MAP_POINTER handling

On Thu, May 21, 2015 at 03:00:16PM +0200, Thomas Schwinge wrote: > Jakub, for avoidance of doubt, the proposed refactoring makes sense to > me, but does need your approval: This is ok for trunk. Jakub

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 6:11 AM, Uros Bizjak wrote: > On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: >> X32 doesn't support indirect branch via 32-bit memory slot since >> indirect branch will load 64-bit address from 64-bit memory slot. >> Since x32 GOT slot is 64-bit, we should allow indirect

Re: [gomp4] Vector-single predication

On Thu, 21 May 2015 15:21:54 +0200 Jakub Jelinek wrote: > On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > > OpenACC handles function calls specially (calling them "routines" > > -- of varying sorts, gang, worker, vector or seq, affecting where > > they can be invoked from). The pl

Re: [RFA] Restore combine.c split point for multiply-accumulate instructions

On Wed, May 20, 2015 at 11:38:44PM -0600, Jeff Law wrote: > I've also verified this is one of the changes ultimately necessary to > resolve the code generation regressions caused by Venkat's combine.c > change on the PA across my 300+ testfiles for a PA cross compiler. How much does it help, do

Re: [gomp4] Vector-single predication

On Thu, 21 May 2015 14:38:19 +0100 Julian Brown wrote: > On Thu, 21 May 2015 15:21:54 +0200 > Jakub Jelinek wrote: > > > On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > > > OpenACC handles function calls specially (calling them "routines" > > > -- of varying sorts, gang, worker,

[C++ PATCH] Minor fix for warn_args_num

I've just noticed that we print "note: declared here" even for builtins. E.g.: void foo (void) { __builtin_return (); } q.cc: In function ‘void foo()’: q.cc:4:21: error: too few arguments to function ‘void __builtin_return(void*)’ __builtin_return (); ^ : note: declared

Re: [gomp4] Vector-single predication

On Thu, May 21, 2015 at 02:38:19PM +0100, Julian Brown wrote: > > All functions will behave that way, or just some using some magic > > attribute etc.? Say will newlib functions behave this way (math > > functions, printf, ...)? > > It's actually unclear at this point if "regular" functions are

[PATCH][1/n] Reduction vectorization improvements

I'm at the moment tearing apart a large patch that adds support for vectorizing reductions in basic-blocks as well as making loop vectorizing reduction chains with patterns work. This is a first piece - allow the reduction patterns be detected when reduction detection didn't run and remove an ass

Re: [RFA] Restore combine.c split point for multiply-accumulate instructions

On 05/21/2015 07:40 AM, Segher Boessenkool wrote: On Wed, May 20, 2015 at 11:38:44PM -0600, Jeff Law wrote: I've also verified this is one of the changes ultimately necessary to resolve the code generation regressions caused by Venkat's combine.c change on the PA across my 300+ testfiles for a P

[PATCH[2/n] Reduction vectorization improvements

This is part #2, fixes wrong-code because of bogus reduction op used and factors out common code (which I'd otherwise need to duplicate once more...). Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2015-05-21 Richard Biener * tree-vect-loop.c (get_reduction_op):

Re: Fix alignment propagation

Hi, I have not managed to ping this, get it approved and commit it in time for gcc 5 but it is a useful cleanup that clarifies a number of things and something I'd like to base further cleanups on. It still applies cleanly and I have re-tested and re-bootstrapped the patch on x86_64-linux without

[PATCH, fixincludes] AIX headers and extern "C"

The AIX port of GCC is one of the few ports that does not define NO_IMPLICIT_EXTERN_C. A user reported a problem that we tracked to an AIX header that explicitly used C++ features (bracketed by #ifdef __cplusplus). AIX headers have included some C++ features, mostly protected by #if defined (__c

Re: [C++ PATCH] Minor fix for warn_args_num

On 05/21/2015 09:44 AM, Marek Polacek wrote: + if (!DECL_BUILT_IN (fndecl)) I think you want DECL_IS_BUILTIN. OK with that change. Jason

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

"H.J. Lu" writes: > Here is the complete patch. Tested on Linux/x86-64. It is also > available on hjl/pie/master branch in git mirror. As always, please keep generated files like configure and config.in out of the submission: it simplifies review. diff --git a/gcc/Makefile.in b/gcc/Makefile.i

Re: [PATCH, fixincludes] AIX headers and extern "C"

OK. You might consider updating autogen. It seems 5.18 doesn't handle the version test quite right. Any 5.18.n should do fine. I guess I didn't test the version test with older versions. :) On Thu, May 21, 2015 at 6:58 AM, David Edelsohn wrote: > The AIX port of GCC is one of the few ports th

[PATCH][AArch64] Add __extension__ and __always_inline__ to crypto intrinsics

Hi all, The crypto intrinsics are missing an __extension__ and an __always_inline__ attribute that all the other intrinsics have. I don't see any reason for them to be different and the always_inline attribute will be needed if we decide to wrap the intrinsics inside a target SIMD pragma. Test

Re: [C++ PATCH] Minor fix for warn_args_num

On Thu, May 21, 2015 at 10:11:41AM -0400, Jason Merrill wrote: > On 05/21/2015 09:44 AM, Marek Polacek wrote: > >+ if (!DECL_BUILT_IN (fndecl)) > > I think you want DECL_IS_BUILTIN. OK with that change. Right. With DECL_IS_BUILTIN we print q.c:1:5: note: declared here int printf (const c

Re: RFA: PATCH to use -std=c++98 in stage 1 of bootstrap

On 05/20/2015 06:11 PM, Alexandre Oliva wrote: The only serious problem with the patch is that it changes Makefile.in, but not the corresponding part of Makefile.tpl from which it is generated. Ok with that change. Now, if you'd also update the comments just before it, that still suggest we bui

v3 PATCH to avoid -Wsized-deallocation warnings with C++14 compiler

When GCC defaults to C++14, it gives -Wsized-deallocation warnings for the non-sized operator deletes. We dealt with this for the sized ones by passing -Wno-sized-deallocation on the command line, but using #pragma GCC diagnostic seems cleaner to me. Applying to trunk. commit 35cc1a3b6855a3e2

Re: [PATCH] PR target/66224 _GLIBC_READ_MEM_BARRIER

On Wed, 2015-05-20 at 14:40 -0400, David Edelsohn wrote: > The current definition of _GLIBC_READ_MEM_BARRIER in libstdc++ is too > weak for an ACQUIRE FENCE, which is what it is intended to be. The > original code emitted an "isync" instead of "lwsync". > > All of the guard acquire and set code ne

[RFA] Fix combine to canonicalize (mult X pow2)) more often

When combine needs to split a complex insn, it will canonicalize a simple (mult X (const_int Y)) where Y is a power of 2 into the expected (ashift X (const_int Y')) if the (mult ...) is selected as a split point. However if the split point is (plus (mult (X (const_int Y)) Z) combine fails to

[PATCH] Fix (ocvt (icvt@1 @0)) simplification (PR tree-optimization/66233)

Hi! We ICE on the following testcase at -O3 on x86_64-linux, because gimple folding attempts to simplify FLOAT_EXPR conversion of signed V4SI to V4SF feeding FIX_TRUNC_EXPR to unsigned V4SI into a FIX_TRUNC_EXPR with unsigned V4SI lhs and signed V4SI rhs1, which is invalid GIMPLE. All the other si

[committed] Tweak inform_declaration

See for the rationale. Bootstrapped/regtested on x86_64-linux, applying to trunk. 2015-05-21 Marek Polacek * c-typeck.c (inform_declaration): Use DECL_IS_BUILTIN instead of DECL_BUILT_IN. diff --git gcc/c/c-typeck.c g

Re: Don't dump low gimple functions in gimple dump

Hi! It's just been a year. ;-P In early March, I (hopefully correctly) adapted Tom's patch to apply to then-current GCC trunk sources; posting this here. Is the general approach OK? On Tue, 20 May 2014 10:16:45 +0200, Tom de Vries wrote: > Honza, > > Consider this program: > ... > int > main

Re: Cleanup and improve canonical type construction in LTO

> On Wed, 20 May 2015, Jan Hubicka wrote: > > > Richard, > > this is my attempt to make sense of TYPE_CANONICAL at LTO. My > > undrestanding is > > that gimple_canonical_types_compatible_p needs to return true for all pairs > > of > > types that are considered compatible across compilation unit

Re: [PATCH] Fix memory orders description in atomic ops built-ins docs.

On 19/05/15 20:20, Torvald Riegel wrote: On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote: Hello, On 15/05/15 17:22, Torvald Riegel wrote: This patch improves the documentation of the built-ins for atomic operations. The "memory model" to "memory order" change does improve things but I

Re: [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning

Hi Julian! On Tue, 19 May 2015 11:36:58 +0100, Julian Brown wrote: > This patch fixes an oversight whereby if the CUDA libraries are > available for some reason on a system that doesn't actually contain an > nVidia card, an OpenACC program will raise an error if the NVPTX > backend is picked as

Re: [PATCH] Fix (ocvt (icvt@1 @0)) simplification (PR tree-optimization/66233)

On May 21, 2015 5:28:14 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >We ICE on the following testcase at -O3 on x86_64-linux, because >gimple folding attempts to simplify FLOAT_EXPR conversion of >signed V4SI to V4SF feeding FIX_TRUNC_EXPR to unsigned V4SI >into a FIX_TRUNC_EXPR with unsigned V4SI l

[PATCH 1/3][AArch64] Strengthen barriers for sync-fetch-op builtins.

On Aarch64, the __sync builtins are implemented using the __atomic operations and barriers. This makes the the __sync builtins inconsistent with their documentation which requires stronger barriers than those for the __atomic builtins. The difference between __sync and __atomic builtins is that t

[AArch64][PATCH 2/3] Strengthen barriers for sync-compare-swap builtins.

This patch changes the code generated for __sync_type_compare_and_swap to ldxr reg; cmp; bne label; stlxr; cbnz; label: dmb ish; mov .., reg This removes the acquire-barrier from the load and ends the operation with a fence to prevent memory references appearing after the __sync operation from

[PATCH 3/3][Aarch64] Add tests for __sync_builtins.

This patch adds tests for the code generated by the Aarch64 backend for the __sync builtins. Tested aarch64-none-linux-gnu with check-gcc. Ok for trunk? Matthew gcc/testsuite/ 2015-05-21 Matthew Wahab * gcc.target/aarch64/sync-comp-swap.c: New. * gcc.target/aarch64/sync-comp

Fix hashing of basetypes of methods

Hi, this patch drops TYPE_METHOD_BASETYPE from hash_canonical_type. It is not compared by gimple_canonical_types_compatible_p and thus it can only corrupt the hashtable by having two entries that are equal but having different hash. Theoretically we may want later distinguish the method pointer b

Re: [patch, testsuite] don't specify "dg-do run" explicitly for vect test cases

On 05/21/2015 03:08 AM, Richard Biener wrote: On Thu, May 21, 2015 at 7:12 AM, Sandra Loosemore wrote: On targets such as ARM, some arches are compatible with options needed to enable compilation with vectorization, but the specific hardware (or simulator or BSP) available for execution tests m

Do not compare type attributes in gimple_canonical_types_compatible_p

Hi, this patch removes call to comp_type_attributes (wich happens for METHOD_TYPE and FUNCTION_TYPE only). This does not make sense, because type attributes may change in variants and pointers should be considered compatible. We did not get any trouble from this only because we do not really use c

RE: Fix PR48052: loop not vectorized if index is "unsigned int"

I tested this patch and it passes bootstrap and no extra failures. Thanks -Aditya Symbolically evaluate conditionals, and subtraction when additional constraints are provided. Adding this evaluation mechanism helps vectorize some loops on 64bit machines because on 64bit, a typecast appears w

Re: [patch, testsuite, ARM] don't try to execute advsimd-intrinsics tests on hardware without NEON

On 05/21/2015 03:48 AM, Christophe Lyon wrote: On 21 May 2015 at 07:33, Sandra Loosemore wrote: ARM testing shares the AArch64 advsimd-intrinsics execution tests. On ARM, though, the NEON support being tested is optional -- some arches are compatible with the NEON compilation options but hardw

Re: Fix hashing of basetypes of methods

On May 21, 2015 6:02:27 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch drops TYPE_METHOD_BASETYPE from hash_canonical_type. It is >not >compared by gimple_canonical_types_compatible_p and thus it can only >corrupt the hashtable by having two entries that are equal but having >different >hash.

Re: Do not compare type attributes in gimple_canonical_types_compatible_p

On May 21, 2015 6:06:18 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch removes call to comp_type_attributes (wich happens for >METHOD_TYPE and FUNCTION_TYPE only). This does not make sense, because >type attributes may change in variants and pointers should be >considered >compatible. > >We did

[AArch64][TLSLE][5/N] Recognize -mtls-size

This patch add -mtls-size option for AArch64. This option let user to do finer control on code generation for various TLS model on AArch64. For example, for TLS LE, user can specify smaller tls-size, for example 4K which is quite usual, to let AArch64 backend generate more efficient instruction s

[gomp4.1] Add taskloop-4.c testcase

Hi! I've committed another testcase, which tests the computation of number of iterations for each task and number of tasks. 2015-05-21 Jakub Jelinek * testsuite/libgomp.c/taskloop-4.c: New test. --- libgomp/testsuite/libgomp.c/taskloop-4.c(revision 0) +++ libgomp/testsuite/libgom

[AArch64][TLSLE][N/N] Implement local executable mode for all memory model

4 instruction sequences can be implemented for AArch64 TLS LE model based on relocations provided. These instruction sequences are the same for tiny/small/large, We just need to choose the most efficient one to use accoding to tls size. the 12bit version give us 4K TLS size, 24bit give us 16M, 3

Re: [PATCH 1/7] always define STACK_GROWS_DOWNWARD

This patch needs to update tm.texi.in and regenerate tm.texi to describe the new semantics of STACK_GROWS_DOWNWARD. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH][DRIVER] Wrong C++ include paths when configuring with "--with-sysroot=/"

On Thu, 21 May 2015, Yvan Roux wrote: > There is this old patch submitted by Matthias on that same issue, if > its logic is the right one for you Joseph I can rebase/validate it > Joseph. > > https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00320.html Yes, that seems better. -- Joseph S. Myers jo

Re: [PATCH][ARM] Handle UNSPEC_VOLATILE in rtx costs and don't recurse inside the unspec

Ping^3. Thanks, Kyrill On 12/05/15 10:08, Kyrill Tkachov wrote: Ping^2. Thanks, Kyrill On 30/04/15 13:01, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01047.html Thanks, Kyrill On 20/04/15 17:28, Kyrill Tkachov wrote: Hi all, A pet project of mine is to get to

Re: [PATCH][ARM/AArch64] Properly cost rev16 operand

Ping. Thanks, Kyrill On 12/05/15 10:07, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00013.html Thanks, Kyrill On 01/05/15 09:24, Kyrill Tkachov wrote: Hi all, It occurs to me that in the IOR-of-shifts form of the rev16 operation we should be costing the operand

Re: [PATCH][ARM][stage-1] Initialise cost to COSTS_N_INSNS (1) and increment in arm rtx costs

Ping^3. Thanks, Kyrill On 12/05/15 10:09, Kyrill Tkachov wrote: Ping^2. Thanks, Kyrill On 30/04/15 13:00, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01130.html Thanks, Kyrill On 21/04/15 10:11, Kyrill Tkachov wrote: Hi all, This is the first of a series to

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 6:33 AM, H.J. Lu wrote: > On Thu, May 21, 2015 at 6:11 AM, Uros Bizjak wrote: >> On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: >>> X32 doesn't support indirect branch via 32-bit memory slot since >>> indirect branch will load 64-bit address from 64-bit memory slot. >>>

Re: Check canonical types in verify_type

> > Hmm, I see, interesting hack. For the first part of comment, I see that > > qualifiers needs to be ignored, but I do not see why we put > > short * and int * pointers to same class. > > For the reason that people are very lazy. For example GCC has code > punning void ** and void * and void *

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Thu, 21 May 2015, Rainer Orth wrote: > @@ -1864,6 +1873,12 @@ libgcc.mvars: config.status Makefile specs > xgcc$(exeext) > echo GCC_CFLAGS = '$(GCC_CFLAGS)' >> tmp-libgcc.mvars > echo INHIBIT_LIBC_CFLAGS = '$(INHIBIT_LIBC_CFLAGS)' >> tmp-libgcc.mvars > echo TARGET_SYSTEM_ROOT

Avoid non-canonical RTL in splitter for adding a large constant to register on the PA

The PA has a splitter to optimize the addition of certain constants to a register. One of the cases the splitter handles is when the constant requires 2 insns to generate, is divisible by 2, 4, or 8 and if divided by 2, 4 or 8 it only needs a single insn to generate the constant. Obviously

Re: [PATCH][AArch64] Add __extension__ and __always_inline__ to crypto intrinsics

On Thu, May 21, 2015 at 03:42:33PM +0100, Kyrill Tkachov wrote: > Hi all, > > The crypto intrinsics are missing an __extension__ and an __always_inline__ > attribute that all the other intrinsics have. I don't see any reason for them > to be different and the always_inline attribute will be needed

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Thu, May 21, 2015 at 7:13 AM, Rainer Orth wrote: > "H.J. Lu" writes: > >> Here is the complete patch. Tested on Linux/x86-64. It is also >> available on hjl/pie/master branch in git mirror. > > As always, please keep generated files like configure and config.in out > of the submission: it si

Ping ** 0.5 patch, fortran] Inline matmul with conjugate complex numbers

Am 18.05.2015 um 00:05 schrieb Thomas Koenig: > this patch extends the inline matmul functionality to conjugate > complex numbers. > > Regression-tested. OK for trunk? OK (with the trivial change in the follow-up e-mail)? I'd like to start extending this to TRANSPOSE(CONJG(A)) :-) Thoma

Re: [AArch64][TLSLE][4/N] Recognize -mtls-size

Jiong Wang writes: > This patch add -mtls-size option for AArch64. This option let user to do > finer control on code generation for various TLS model on AArch64. > > For example, for TLS LE, user can specify smaller tls-size, for example > 4K which is quite usual, to let AArch64 backend generate

Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)

On 05/07/2015 12:22 PM, Marek Polacek wrote: - mark_used (decl); + mark_used (decl, 0); This should use tf_none rather than 0. + build_enumerator (DECL_NAME (decl), value, newtag, + DECL_ATTRIBUTES (decl), DECL_SOURCE_LOCATION (decl)); This is assuming t

Re: [patch] testsuite enable PIE tests on FreeBSD

On 20.05.15 22:30, Jeff Law wrote: On 05/20/2015 11:04 AM, Andreas Tobler wrote: Hi, the attached patch enables some PIE tests on FreeBSD. Ok for trunk? Thanks, Andreas 2015-05-20 Andreas Tobler * gcc.target/i386/pr32219-1.c: Enable test on FreeBSD. * gcc.target/i386/pr32219-

Calculate TYPE_CANONICAL only for types that can be accessed in memory

Hi, this is next part of the series. It disables canonical type calculation for incomplete types with exception of arrays based on claim that we do not have good notion of those. I can botostrap this with additional checks in alias.c that canonical types are always present with LTO but I need fix

  1   2   >