Re: [gomp4 00/14] NVPTX: further porting

On 10/23/2015 12:16 PM, Jakub Jelinek wrote: On Thu, Oct 22, 2015 at 07:16:49PM +0200, Bernd Schmidt wrote: I'm not really familiar with OpenMP and what it allows, so take all my comments with a grain of salt. So [snip - really good example] Thanks! So what I was trying to describe

Re: [PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

On 10/13/2015 05:17 PM, Pierre-Marie de Rodat wrote: diff --git a/gcc/df-problems.c b/gcc/df-problems.c index c08ae36..56e1cf5 100644 --- a/gcc/df-problems.c +++ b/gcc/df-problems.c @@ -1464,9 +1464,12 @@ df_live_bb_local_compute (unsigned int bb_index) seen are included in the

Re: [PATCH] 2015-10-19 Benedikt Huber <benedikt.hu...@theobroma-systems.com> Philipp Tomsich <philipp.toms...@theobroma-systems.com>

On 10/22/2015 12:13 PM, Benedikt Huber wrote: https://gcc.gnu.org/contribute.html states "If you do not have write access and a patch of yours has been approved, but not committed, please advise the approver of that fact. You may want to point out lack of write access in your initial

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/21/2015 12:10 AM, Joseph Myers wrote: On Tue, 20 Oct 2015, Bernd Schmidt wrote: How about [2].a and [2].b I don't think either is valid. typedef struct FA5_7 { int i; char a5_7 [5][7]; } FA5_7; __builtin_offsetof (FA5_7, a5_7 [0][7]), // { dg-warning "

Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

On 10/12/2015 11:58 AM, Ulrich Weigand wrote: Index: gcc/configure.ac === --- gcc/configure.ac(revision 228530) +++ gcc/configure.ac(working copy) @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t fi if

Re: config header file reduction patch checked in.

On 10/23/2015 07:15 PM, Mike Stump wrote: On Oct 23, 2015, at 9:57 AM, Bernd Schmidt <bschm...@redhat.com> wrote: I'm guessing it's the CROSS_DIRECTORY_STRUCTURE macro which is used by darwin targets. It's also used for several other targets, so you may want to double check those. No

Re: [PATCH] Add missing INCLUDE_DEFAULTS_MUSL_LOCAL

On 10/21/2015 09:00 PM, Doug Evans wrote: I happened to notice local prefixes not working with musl. Fixes thusly. Index: config/linux.h === --- config/linux.h(revision 229130) +++ config/linux.h(working copy) @@ -174,6

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/23/2015 06:50 PM, Joseph Myers wrote: On Fri, 23 Oct 2015, Martin Sebor wrote: But now that I'm re-reading the answer above I see that Joseph was suggesting that a5_7[5][0] should be diagnosed when the patch accepts it as an extension. I think we do want to accept it because a5_7 is

Re: [PATCH] Add missing INCLUDE_DEFAULTS_MUSL_LOCAL

On 10/23/2015 07:36 PM, Doug Evans wrote: ​The only significant different AFAICT is that GCC_INCLUDE_DIR is moved to later (last). Why this is is briefly described in the intro comment: config/linux.h: ​ /* musl avoids problematic includes by rearranging the include directories. *

Re: config header file reduction patch checked in.

On 10/19/2015 05:53 PM, Andrew MacLeod wrote: interesting that none of the cross builds need diagnostics-core.h. I see it used in 7 different targets. Must be something on the native build command line that is defined which causes it to be needed. I'm guessing it's the

Re: FW: [PATCH] Target hook for disabling the delay slot filler.

On 10/23/2015 04:57 PM, Simon Dardis wrote: Patch below. Target hook renamed to TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P. Tested on mips-img-elf, no new regressions. As far as I'm concerned this is ok, and IIUC Jeff was on board too. This is assuming the test included a bootstrap, otherwise

Re: [gomp4 00/14] NVPTX: further porting

On 10/22/2015 08:08 PM, Alexander Monakov wrote: On Thu, 22 Oct 2015, Bernd Schmidt wrote: I'm not really familiar with OpenMP and what it allows, so take all my comments with a grain of salt. On 10/22/2015 06:41 PM, Alexander Monakov wrote: The second approach is to run all threads

Re: [gomp4 00/14] NVPTX: further porting

I'm not really familiar with OpenMP and what it allows, so take all my comments with a grain of salt. On 10/22/2015 06:41 PM, Alexander Monakov wrote: The second approach is to run all threads in the warp all the time, making sure they execute the same code with the same data, and thus build

Re: [OpenACC 2/11] PTX backend changes

On 10/22/2015 10:12 AM, Jakub Jelinek wrote: @@ -2129,6 +3242,19 @@ nvptx_file_end (void) FOR_EACH_HASH_TABLE_ELEMENT (*needed_fndecls_htab, decl, tree, iter) nvptx_record_fndecl (decl, true); fputs (func_decls.str().c_str(), asm_out_file); + + if (worker_bcast_hwm) +{ +

Re: [OpenACC 2/11] PTX backend changes

On 10/22/2015 04:24 PM, Nathan Sidwell wrote: + else +{ /* Parent will skip this parallel itself. */ } Here too - actually no need to have an empty else at all. I wanted somewhere clear for the comment to go. (Actually, I think this is the one the compiler warns about -- empty

Re: [OpenACC 2/11] PTX backend changes

On 10/21/2015 09:09 PM, Nathan Sidwell wrote: At the beginning of a partitioned region, we have to propagate live register state and stack frame from engine-zero to the other engines (just as would happen on a regular 'fork' call). This is something I'm not terribly happy about, but since I

Re: RFA/RFC: insns that do not start a source line

Hi Nick, On 10/22/2015 04:07 PM, Nick Clifton wrote: Sometimes gcc can generate instructions out of order with respect to lines of source code, and this can lead to problems for debuggers. For example, consider this source code snippet: v = 0; /* Line 31 */

Re: RFA/RFC: insns that do not start a source line

On 10/22/2015 05:08 PM, Bernd Schmidt wrote: So I'm not entirely sure yet what's supposed to happen here, but I think the problem could well be in the expansion phase. Forgot to mention another possibility that crossed my mind: don't compare locations for equality in fixup_reorder_chain

Re: RFA/RFC: insns that do not start a source line

On 10/22/2015 04:19 PM, Nick Clifton wrote: It is in cfgrtl.c:fixup_reorder_chain() nb = split_edge (e); if (!INSN_P (BB_END (nb))) BB_END (nb) = emit_insn_after_noloc (gen_nop (), BB_END (nb), nb); INSN_LOCATION (BB_END (nb)) =

Re: Change behavior of -fsched-verbose option

On 10/22/2015 05:38 PM, Nikolai Bozhenov wrote: Currently -fsched-verbose option redirects debugging dumps to stderr if there is no dump_file for the current pass. It would be fine if there were the only scheduling pass. But for example for AArch64 there are 3 scheduling passes in the default

Re: [gomp4 00/14] NVPTX: further porting

On 10/21/2015 05:18 PM, Alexander Monakov wrote: On Wed, 21 Oct 2015, Bernd Schmidt wrote: On 10/20/2015 08:34 PM, Alexander Monakov wrote: This patch series ports enough of libgomp.c to get warp-level parallelism working for OpenMP offloading. The overall approach is as follows. Could you

Re: [OpenACC] loop nesting check

On 10/21/2015 05:59 PM, Nathan Sidwell wrote: in preparing a patch set of the OpenACC execution model for trunk, I discovered some broken tests in the testsuite. We were failing to diagnose some incorrectly nested loops, and that led to ICEs in my patch set. This patch implements a check for

Re: [PATCH 1/9] ENABLE_CHECKING refactoring

On 10/21/2015 06:18 PM, Jeff Law wrote: To avoid conditionally compiled code. I'm of the opinion we should be stomping out as much as we reasonably can. Yeah, I get that, but the point I'm trying to make is that if you get rid of all conditional compilation, you don't need either

Re: [PATCH 1/9] ENABLE_CHECKING refactoring

On 10/21/2015 05:56 PM, Jeff Law wrote: The problem is the existing ENABLE_CHECKING conditions. Anything which is #ifdef ENABLE_CHECKING will have its behavior changed if we change things so that ENABLE_CHECKING is always defined with a value. So if we wanted to continue to use

Re: [Patch, MIPS] Frame header optimization for MIPS (part 2)

On 10/21/2015 07:38 PM, Mike Stump wrote: On Oct 20, 2015, at 3:55 PM, Bernd Schmidt <bschm...@redhat.com> wrote: There are many unnecessary parentheses in this patch which should be removed. I can smell a -Wall patch. :-) Not really, because -Wall isn't in the business of enf

Re: [Patch, MIPS] Frame header optimization for MIPS (part 2)

On 10/21/2015 11:29 PM, Joseph Myers wrote: On Wed, 21 Oct 2015, Steve Ellcey wrote: Hm, how about a separate warning that wasn't part of -Wall but could still be used by GCC or other products that wanted to enforce a 'no unnecessary parenthesis' coding style. Not that I'm volunteering.

Re: [gomp4 06/14] omp-low: copy omp_data_o to shared memory on NVPTX

On 10/21/2015 11:07 AM, Alexander Monakov wrote: In PTX, stack storage is in .local address space -- and that memory is thread-private. A thread can make a pointer to its own stack memory and successfully dereference it, but dereferencing that pointer from other threads does not work (I

Re: [gomp4 00/14] NVPTX: further porting

On 10/20/2015 08:34 PM, Alexander Monakov wrote: This patch series ports enough of libgomp.c to get warp-level parallelism working for OpenMP offloading. The overall approach is as follows. Could you elaborate a bit what you mean by this just so we understand each other in terms of

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

On 10/20/2015 12:02 PM, Jakub Jelinek wrote: I'd like to defer review of the driver bits, can Joseph or Bernd please have a look at those? Last time around I think I asked for some minor changes, like updated documentation for give_switch. Other than that, I'm ok with the patch iff you are

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

On 10/20/2015 01:17 PM, Thomas Schwinge wrote: As explained a few times already: GOMP_offload_register_ver constructors will only be generated if there actually are offloaded code regions, but for example: #include int main() { __builtin_printf("%d\n",

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/20/2015 05:31 PM, Martin Sebor wrote: On 10/20/2015 07:20 AM, Bernd Schmidt wrote: On 10/16/2015 09:34 PM, Martin Sebor wrote: Thank you for the review. Attached is an updated patch that hopefully addresses all your comments. I ran the check_GNU_style.sh script on it to make sure I

Re: [PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

Do you refer to this comment? (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790#c20) I do have to say that I am still uncomfortable with changing RRE to use a MUST problem rather than a MAY problem. I see this as dumbing down the compiler to provide the semantics of uninitialized variables

Re: [gomp4 04/14] nvptx: fix output of _Bool global variables

On 10/20/2015 08:34 PM, Alexander Monakov wrote: Due to special treatment of types, emitting variables of type _Bool in global scope is impossible: extern references are emitted with .u8, but definitions use .u64. This patch fixes the issue by treating boolean type as integer types. *

Re: [gomp4 03/14] nvptx: expand support for address spaces

On 10/20/2015 11:04 PM, Alexander Monakov wrote: On Tue, 20 Oct 2015, Bernd Schmidt wrote: On 10/20/2015 08:34 PM, Alexander Monakov wrote: This allows to emit decls in 'shared' memory from the middle-end. * config/nvptx/nvptx.c (nvptx_legitimate_address_p): Adjust prototype

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/20/2015 06:53 PM, Joseph Myers wrote: On Tue, 20 Oct 2015, Martin Sebor wrote: I think -Warray-bounds should emit consistent diagnostics for invalid array references regardless of the contexts. I.e., given struct S { int A [5][7]; int x; } s; these should

Re: [gomp4 03/14] nvptx: expand support for address spaces

On 10/20/2015 08:34 PM, Alexander Monakov wrote: This allows to emit decls in 'shared' memory from the middle-end. * config/nvptx/nvptx.c (nvptx_legitimate_address_p): Adjust prototype. (nvptx_section_for_decl): If type of decl has a specific address space, return it.

Re: [gomp4 09/14] libgomp: provide barriers on NVPTX

On 10/20/2015 08:34 PM, Alexander Monakov wrote: On NVPTX, there's 16 hardware barriers for each thread team, each barrier has a variable waiter count. The instruction 'bar.sync N, M;' allows to wait on barrier number N until M threads have arrived. M should be pre-multiplied by warp width.

Re: [gomp4 07/14] libgomp nvptx plugin: launch target functions via gomp_nvptx_main

On 10/20/2015 11:13 PM, Alexander Monakov wrote: On Tue, 20 Oct 2015, Bernd Schmidt wrote: On 10/20/2015 08:34 PM, Alexander Monakov wrote: 2. Make gomp_nvptx_main a device (.func) function. To have that work, we'd need to additionally emit a "trampoline" of sorts in the NVP

Re: [gomp4 03/14] nvptx: expand support for address spaces

On 10/20/2015 11:41 PM, Cesar Philippidis wrote: Was it this one that you're referring to Bernd? I think this is the patch that introduces the "oacc ganglocal" attribute. It has bitrot significantly though. Yeah, the bits in nvptx.c are the ones I was referring to. Thanks! What are you

Re: [gomp4 11/14] libgomp: avoid variable-length stack allocation in team.c

On 10/20/2015 11:36 PM, Alexander Monakov wrote: Thanks, NVPTX will need a low buf_fixed size, perhaps 64 bytes or so. What about the generic case, should it use a more generous threshold, or revert to existing unbounded alloca? Any ideas how big is the required allocation size is in practice?

Re: [gomp4 11/14] libgomp: avoid variable-length stack allocation in team.c

On 10/20/2015 08:34 PM, Alexander Monakov wrote: NVPTX does not support alloca or variable-length stack allocations, thus heap allocation needs to be used instead. I've opted to make this a generic change instead of guarding it with an #ifdef: libgomp usually leaves thread stack size up to

Re: [gomp4 07/14] libgomp nvptx plugin: launch target functions via gomp_nvptx_main

On 10/20/2015 08:34 PM, Alexander Monakov wrote: The approach I've taken in libgomp/nvptx is to have a single entry point, gomp_nvptx_main, that can take care of initial allocation, transferring control to target region function, and finalization. At the moment it has the prototype: void

Re: [Patch, MIPS] Frame header optimization for MIPS (part 2)

On 10/16/2015 10:21 PM, Steve Ellcey wrote: Here is the second part of the MIPS frame header optimization patch. I'll leave reviewing the functionality to the MIPS maintainers. But... + return TARGET_OLDABI && flag_frame_header_optimization && (optimize > 0); + if ((fn != NULL)

Re: [gomp4 05/14] omp-low: set 'omp target entrypoint' only on entypoints

On 10/20/2015 08:34 PM, Alexander Monakov wrote: (note to reviewers: I'm not sure what we're after here, on the high level; will be happy to rework the patch in a saner manner based on feedback, or even drop it for now) At the moment the attribute setting logic in omp-low.c is such that if a

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On 10/15/2015 12:37 PM, H.J. Lu wrote: On Thu, Oct 15, 2015 at 1:44 AM, Richard Biener wrote: On Wed, Oct 14, 2015 at 6:21 PM, H.J. Lu wrote: By default, there is no visibility on builtin functions. When there is explicitly declared

Re: [gomp4 01/14] nvptx: emit kernels for 'omp target entrypoint' only for OpenACC

On 10/20/2015 08:34 PM, Alexander Monakov wrote: The NVPTX backend emits each functions either as .func (callable only from the device code) or as .kernel (entry point for a parallel region). OpenMP lowering adds "omp target entrypoint" attribute to functions outlined from target regions.

Re: [gomp4 06/14] omp-low: copy omp_data_o to shared memory on NVPTX

On 10/20/2015 08:34 PM, Alexander Monakov wrote: (This patch serves as a straw man proposal to have something concrete for discussion and further patches) On PTX, stack memory is private to each thread. When master thread constructs 'omp_data_o' on its own stack and passes it to other threads

Re: [PATCH] Don't allow FSM threader to create irreducible loops unless it eliminates a multi-way branch

On 10/21/2015 02:03 AM, Hans-Peter Nilsson wrote: If you're using Thunderbird, you can quote non-inline patches by selecting the parts you want to quote before replying. Bernd

Re: [gomp4 09/14] libgomp: provide barriers on NVPTX

On 10/20/2015 11:51 PM, Alexander Monakov wrote: On Tue, 20 Oct 2015, Bernd Schmidt wrote: My experience has been that there is practically no way of using bar.sync reliably, since we can't control warp divergence and reconvergence at the ptx level but the hardware bar.sync instruction only

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/16/2015 09:34 PM, Martin Sebor wrote: Thank you for the review. Attached is an updated patch that hopefully addresses all your comments. I ran the check_GNU_style.sh script on it to make sure I didn't miss something. I've also added replies to a few of your comments below. Ok, thanks.

Re: [PATCH 7/9] ENABLE_CHECKING refactoring: middle-end, LTO FE

diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c - -#ifdef ENABLE_CHECKING - verify_flow_info (); -#endif + checking_verify_flow_info (); This looks misindented. -#ifdef ENABLE_CHECKING cgraph_edge *e; gcc_checking_assert ( !(e =

Re: [PATCH 1/9] ENABLE_CHECKING refactoring

On 10/18/2015 08:17 AM, Mikhail Maltsev wrote: On 10/12/2015 11:57 PM, Jeff Law wrote: -#ifdef ENABLE_CHECKING +#if CHECKING_P I fail to see the point of this change. I'm guessing (and Mikhail, please correct me if I'm wrong), but I think he's trying to get away from ENABLE_CHECKING and

Re: [PATCH][simplify-rtx][2/2] Use constants from pool when simplifying binops

On 10/19/2015 03:57 PM, Kyrill Tkachov wrote: This second patch teaches simplify_binary_operation to return the dereferenced constants from the constant pool in the binary expression if other simplifications failed. This, combined with the 1/2 patch for aarch64

Re: [PATCH v10][aarch64] Implemented reciprocal square root (rsqrt) estimation in -ffast-math

On 01/04/1970 01:02 AM, Benedikt Huber wrote: This tenth revision of the patch: * Removes unnecessary enum. Please fix your clock. Bernd

Re: PING^2: [PATCH] Limit alignment on error_mark_node variable

On 10/20/2015 12:07 AM, H.J. Lu wrote: On Thu, Jul 09, 2015 at 03:57:31PM +0200, Richard Biener wrote: I don't see why the C FE would need to invoke finish_decl twice here. [...] So I'd rather have the C frontend not invoke rest_of_decl_compilation on this in the first place. Your patch

Re: refactoring TARGET_PTRMEMFUNC_VBIT_LOCATION checks

On 10/16/2015 12:48 PM, Christian Bruel wrote: I'm not sure. at each point of the macro, we have the current alignment == FUNCTION_BOUNDARY, because we are just returning from the sequence build_lang_decl/make_node so it looks like DECL_ALIGN (fn) = MAX (MINIMUM_METHOD_BOUNDARY, DECL_ALIGN

Re: OpenACC (gomp-4_0-branch) patch review

On 10/16/2015 11:44 AM, Thomas Schwinge wrote: Lately, Bernd has stepped up a few times to review OMP patches (many thanks, Bernd!), but also he sometimes stated that even though a patch appears fine to him, he'd like "Jakub to have a look". I'll just comment on this briefly. In general I'll

Re: OpenACC (gomp-4_0-branch) patch review

On 10/16/2015 11:44 AM, Thomas Schwinge wrote: Lately, Bernd has stepped up a few times to review OMP patches (many thanks, Bernd!), but also he sometimes stated that even though a patch appears fine to him, he'd like "Jakub to have a look". I'll just comment on this briefly. In general I'll

Re: refactoring TARGET_PTRMEMFUNC_VBIT_LOCATION checks

On 10/16/2015 10:01 AM, Christian Bruel wrote: - - if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn - && DECL_ALIGN (fn) < 2 * BITS_PER_UNIT) -DECL_ALIGN (fn) = 2 * BITS_PER_UNIT; - + DECL_ALIGN (fn) = MINIMUM_METHOD_BOUNDARY; This looks like a change in behaviour. You

Re: [PATCH] i386: Use the STC bb-reorder algorithm at -Os (PR67864)

On 10/16/2015 02:53 PM, Segher Boessenkool wrote: For x86, STC still gives better results for optimise-for-size than "simple" does. So use STC at -Os as well. For how many targets is this true, and for the others, what is the biggest win from "simple"? If the list of targets which get

Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

On 10/09/2015 04:55 AM, Martin Sebor wrote: Gcc attempts to diagnose invalid offsetof expressions whose member designator is an array element with an out-of-bounds index. The logic in the function that does this detection is incomplete, leading to false negatives. Since the result of the

Re: [PATCH][haifa-sched] model load/store multiples properly in autoprefetcher scheduling

On 10/15/2015 11:40 AM, Kyrill Tkachov wrote: The code that analyzes the offsets of the loads/stores doesn't try to handle load/store-multiple insns. These appear rather frequently in memory streaming workloads on aarch64 in the form of load-pair/store-pair instructions i.e. ldp/stp. In RTL,

Re: [PATCH 2/6] always define SETUP_FRAME_ADDRESSES

On 10/15/2015 04:13 AM, Trevor Saunders wrote: On Mon, Oct 12, 2015 at 12:19:08PM +0200, Bernd Schmidt wrote: If we go to the trouble of changing this, could we convert macros to target hooks instead while we're there? REVERSE_CONDITION, SETUP_FRAME_ADDRESSES and FRAME_ADDR_RTX all seem

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/14/2015 07:43 PM, Jeff Law wrote: Obviously some pessimization relative to current code is necessary to fix some of the problems WRT thread safety and avoiding things like introducing faults in code which did not previously fault. Huh? This patch is purely an (attempt at) optimization,

Re: libgomp testsuite: Remove some explicit acc_device_nvidia usage

On 10/09/2015 05:11 PM, Thomas Schwinge wrote: On Wed, 22 Jul 2015 16:39:54 +0200, I wrote: [...] cleanup; committed to gomp-4_0-branch in r226072: [...] OK for trunk? I think all three patches here look OK. Bernd

Re: [PR libgomp/65437, libgomp/66518] Initialize runtime in acc_update_device, acc_update_self

On 10/09/2015 05:14 PM, Thomas Schwinge wrote: Hi! On Fri, 19 Jun 2015 09:47:41 +0200, I wrote: On Tue, 5 May 2015 11:43:20 +0200, I wrote: On Mon, 4 May 2015 10:20:14 -0400, John David Anglin wrote: FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c

Re: [PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

On 10/13/2015 05:17 PM, Pierre-Marie de Rodat wrote: The first attached patch is the second attempt to fix PR rtl-optimization/66790 (see ). The second one is a fix for some inconsistency noticed while working on the original bug. This

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 02:02 PM, Dominik Vogt wrote: When "#pragma GCC pop_options" is used on a platform without support for "#pragma GCC target", Gcc emits a warning. As pop_options is useful on targets without the target pragma to restore optimizations flags, the warning should be removed. The

Re: [PR debug/67192] Fix C loops' back-jump location

On 10/12/2015 04:04 PM, Andreas Arnez wrote: Since r223098 ("Implement -Wmisleading-indentation") the backward-jump generated for a C while- or for-loop can get the wrong line number. This is because the check for misleading indentation peeks ahead one token, advancing input_location to after

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 03:31 PM, Dominik Vogt wrote: On Tue, Oct 13, 2015 at 02:28:37PM +0200, Bernd Schmidt wrote: On 10/13/2015 02:02 PM, Dominik Vogt wrote: When "#pragma GCC pop_options" is used on a platform without support for "#pragma GCC target", Gcc emits a warning. As p

Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register

On 10/13/2015 04:50 PM, Chen Gang wrote: OK, under the bugzilla, the maintainer treated it as expected behavior (not a bug). For me, we need more explanation for it (why we treat it as expected behavior). A global register is under control of the user. If the compiler uses it as a frame

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 05:03 PM, Dominik Vogt wrote: On Tue, Oct 13, 2015 at 04:33:42PM +0200, Bernd Schmidt wrote: Looks like ix86_pragma_target_parse has a "! args" test to determine if it has a pop, maybe the default function could do the same. All right, this solution is way better.

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

_Potentially_ so, yes. However, GCC is free to put the allocation into an otherwise-unused part of the stack frame. Well, I looked at code generation changes, and it usually seems to come with an increase in stack frame size - sometimes causing extra instructions to be emitted. However,

Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register

On 10/11/2015 05:16 PM, Chen Gang wrote: For some architectures (e.g. bfin), when this case occurs, they will use another instructions instead of frame pointer (e.g. LINK for bfin), so they can still generate correct output assembly code. What is "this case"? I don't think you have explained

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

On 10/12/2015 12:56 PM, Christian Bruel wrote: yes I see, I was hoping to avoid a new hook, but as you said it seems mandatory for the mere declaration case. Here is one proposal, it defaults to nothing and the ARM implementation does not need to handle the vptr bit setting. so that simplifies

Re: [PATCH 2/6] always define SETUP_FRAME_ADDRESSES

On 10/11/2015 02:25 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-10-10 Trevor Saunders * defaults.h (SETUP_FRAME_ADDRESSES): New default definition. * builtins.c

Re: [PATCH, 4/5] Support DEFPARAMENUM in params.def

On 10/10/2015 02:05 PM, Tom de Vries wrote: On 10/10/15 13:06, Tom de Vries wrote: OK, I'll repost with the patch split up, as follows: 1Handle simple latch in expand_omp_for_generic 2Add missing phis in expand_omp_for_generic 3Handle original loop tree in

Re: [PATCH, 2/5] Add missing phis in expand_omp_for_generic

On 10/10/2015 01:49 PM, Tom de Vries wrote: On 10/10/15 13:06, Tom de Vries wrote: OK, I'll repost with the patch split up, as follows: 1Handle simple latch in expand_omp_for_generic 2Add missing phis in expand_omp_for_generic 3Handle original loop tree in

Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic

On 10/10/2015 01:58 PM, Tom de Vries wrote: Handle original loop tree in expand_omp_for_generic 2015-09-10 Tom de Vries PR tree-optimization/67476 * omp-low.c (expand_omp_for_generic): Handle original loop tree. This one I find slightly confusing. -

Re: [PATCH, 1/5] Handle simple latch in expand_omp_for_generic

On 10/10/2015 01:24 PM, Tom de Vries wrote: On 10/10/15 13:06, Tom de Vries wrote: OK, I'll repost with the patch split up, as follows: 1Handle simple latch in expand_omp_for_generic 2Add missing phis in expand_omp_for_generic 3Handle original loop tree in

Re: Test for __cxa_thread_atexit_impl when cross-compiling libstdc++ for GNU targets

On 10/10/2015 01:18 AM, Joseph Myers wrote: I noticed that when testing glibc with a cross compiler I got UNSUPPORTED: nptl/tst-thread_local1 because the libstdc++-v3 configuration for cross compiling defaulted to __cxa_thread_atexit_impl not being available. This patch fixes

Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic

Does this version look better? In terms of clarity, yes. Only one thing: + if (/* If we already have a loop struct for the original loop, don't +allocate a new one. */ + !orig_loop_has_loop_struct Don't really like the formatting with this comment. I'd pull it in

Re: [nvptx] fix some c++ tests

On 10/09/2015 07:55 AM, Thomas Schwinge wrote: Hi Nathan! Thanks for looking into this. When I reported this, , quite a lot of testcases had been failing -- with recent GCC trunk, the number is smaller

Re: [PATCH] bb-reorder: Improve the simple algorithm for -Os (PR67864)

On 10/08/2015 06:57 PM, Segher Boessenkool wrote: As the PR points out, the "simple" reorder algorithm makes bigger code than the STC algorithm did, for -Os, for x86. I now tested it for many different targets and it turns out to be worse everywhere. That's somewhat disappointing. Wasn't it

Re: [patch 0/6] scalar-storage-order merge (2)

On 10/06/2015 12:57 PM, Eric Botcazou wrote: this is a repost of the diff of the scalar-storage-order branch vs mainline. It contains the fixes suggested by Joseph for the C front-end and the doc, fixes for the handling of complex types, the new pragma scalar_storage_order and associated

Re: PING: [PATCH] PR target/35514: Gcc shoud generate symbol type for undefined symbol

On 10/08/2015 01:10 PM, H.J. Lu wrote: On Wed, Jul 8, 2015 at 1:35 PM, H.J. Lu wrote: On Sun, Jul 5, 2015 at 2:54 PM, H.J. Lu wrote: On Sun, Jul 5, 2015 at 11:14 AM, H.J. Lu wrote: Update default_elf_asm_output_external to also

Re: libgomp: Guard all devices/num_devices/num_devices_openmp access by register_lock

On 09/28/2015 10:52 AM, Thomas Schwinge wrote: On Fri, 25 Sep 2015 19:49:50 +0300, Ilya Verbin wrote: Looks like you're right, and this scenario is possible. Thanks for your review! Jakub, OK to commit the patch I had posted? Then, in context of a similar scenario, I

Re: [Patch ifcvt costs 0/3] Introduce a new target hook for ifcvt costs.

On 10/01/2015 11:37 AM, Bernd Schmidt wrote: On 09/29/2015 04:31 PM, James Greenhalgh wrote: On the other side of the equation, we want a cost for the converted sequence. We can build a cost of the generated rtl sequence, but for targets like AArch64 this is going to be wildly off. AArch64

Re: Offloading: libgfortran, libm dependencies

On 10/02/2015 05:20 PM, Thomas Schwinge wrote: How should we handle libgfortran and libm dependencies in offloaded code? As the linking requirements especially regarding libgfortran may be different for each offloading target (shared and/or static libraries supported, static linking enforced,

Re: [PATCH 1/9] Change default of non-overlapping address space conversion

On 10/08/2015 06:59 AM, Richard Henderson wrote: The current default of making all undefined coversions being set to null is not useful. It has caused all users to lie and say that spaces are subsets when they are not, just so that they can override the conversion. * expr.c

Re: [RFC][PATCH] Preferred rename register in regrename pass

Hi Robert, gcc/ * regrename.c (create_new_chain): Initialize terminated_dead, renamed and tied_chain. (find_best_rename_reg): Pick and check register from the tied chain. (regrename_do_replace): Mark head as renamed. (scan_rtx_reg): Tie chains in move

Re: PING: [PATCH] PR target/35514: Gcc shoud generate symbol type for undefined symbol

On 10/09/2015 02:45 PM, H.J. Lu wrote: What kind of diagnostic message? The ELF linker seems to have managed to do without for a long time. Is there some discussion of this on the binutils list that you can point to? https://groups.google.com/forum/#!topic/generic-abi/_ZPPq_c8FSQ Hmm, near

Re: [PATCH 9/9] Fix PR 66768

On 10/08/2015 07:17 AM, Bin.Cheng wrote: On Thu, Oct 8, 2015 at 12:59 PM, Richard Henderson wrote: This is the patch that richi includes in the PR. There will need to be an additional patch to solve an ICE for the AVR backend, as noted in the PR, but this is good enough to

Re: [PATCH] A tweak for debug_ops_vector

On 10/08/2015 10:57 AM, Marek Polacek wrote: I've been playing with reassoc recently and what bothers me is that dump_ops_vector doesn't print a newline after each element, so it prints e.g. "Op 0 -> rank: 5, tree: a_1(D)Op 1 -> rank: 4, tree: c_3(D)" which isn't really all that readable to me.

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

On 10/08/2015 03:14 PM, Christian Bruel wrote: Probably at the time of start_decl, because DECL_ALIGN will have the boundary given by the global target_flags at that time. But this shouldn't be a problem since what matters is the DECL_ALIGN recomputed with the definition when there is something

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

+ /* We must copy the insns between the start of the THEN block + and the set of 'a', if they exist, since they may be needed + for the converted code as well, but we must not copy a + start-of-BB note if one is present, nor debug "insn"s. */ + + for (rtx_insn* insn = BB_HEAD (then_bb);

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

On 10/08/2015 03:50 PM, Christian Bruel wrote: Humm, I don't know what kind of alignment optimization for functions we have based on a declaration only. greping DECL_ALIGN on functions there are some bits in the ipa-icf code that seems to merge code using this information, but I think we have a

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/08/2015 01:29 AM, Abe wrote: Attached please find my revised patch to the RTL if converter. This patch enables the if-conversion of half-hammocks with a store in them that the internal GCC machinery otherwise considers too hazardous to if-convert. This is made safe by using the

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

On 10/08/2015 04:01 PM, Christian Bruel wrote: OK, Similar pattern occurs at many other places, that changed also in the attached proposal. Not fully tested (in particular the java part) and no ChangeLog. Just to make sure that we agree on the interface first. That looks like a plain diff

Re: Move some bit and binary optimizations in simplify and match

On 10/07/2015 11:54 AM, Hurugalawadi, Naveen wrote: Move Fold X & (X ^ Y) as X & ~Y to match.pd. Move Fold X & (Y ^ X) as ~Y & X to match.pd. I wonder if we shouldn't try to autogenerate patterns such as these. I did something like that for a different project a long time ago.

<    8   9   10   11   12   13   14   15   16   17   >