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

On 10/28/2015 05:54 PM, Alexander Monakov wrote: --- a/gcc/config/nvptx/nvptx.c +++ b/gcc/config/nvptx/nvptx.c @@ -1893,7 +1893,7 @@ init_output_initializer (FILE *file, const char *name, const_tree type, && TREE_CODE (type) != REAL_TYPE) || sz < 0 || sz > HOST_BITS_PER_

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

On 10/28/2015 06:34 PM, Alexander Monakov wrote: I didn't; a simple test exercising pointer fields appears to fail, indeed. So what's the way forward here? I didn't quite get why you felt a need to change this? Your previous mail didn't seem to include a testcase, just that you get "the desir

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

On 10/28/2015 06:51 PM, Alexander Monakov wrote: On Wed, 28 Oct 2015, Bernd Schmidt wrote: I didn't quite get why you felt a need to change this? Your previous mail didn't seem to include a testcase, just that you get "the desired behaviour". Hm? I said, There&

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

On 10/28/2015 07:06 PM, Alexander Monakov wrote: On Wed, 28 Oct 2015, Bernd Schmidt wrote: Ok, so adjust the if condition for non-integral types - make it false if the size of the struct is smaller than the pointer type. I'm afraid it's an insufficient fix: it would remain broken f

Re: PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

On 10/29/2015 02:10 AM, H.J. Lu wrote: On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote: So I'll ask again, why did you commit a patch which you clearly knew did not meet the conditions Bernd set forth for approval? I believed that aarch64 backend didn't properly handle -fno-plt, which should

Re: PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

On 10/29/2015 02:14 AM, H.J. Lu wrote: On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote: On 10/29/2015 02:10 AM, H.J. Lu wrote: On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote: So I'll ask again, why did you commit a patch which you clearly knew did not meet the conditions Bern

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

On 10/28/2015 08:29 PM, Alexander Monakov wrote: Anything wrong with the simple fix: pick an integer type with the largest size dividing the original struct type size? Try it and run it through the testsuite. Bernd

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

On 10/23/2015 11:14 AM, Andreas Arnez wrote: This patch adds a new parameter to c_finish_loop that expclitly specifies the location to be used for the loop iteration. All calls to c_finish_loop are adjusted accordingly. I think the general principle of this is probably ok. + bool is_braced

Re: Robustify REAL_MODE_FORMAT

On 10/29/2015 04:30 PM, Richard Sandiford wrote: Make sure that REAL_MODE_FORMAT aborts if it is passed an invalid mode, rather than stepping beyond the bounds of an array. It turned out that some code was passing non-float modes to the real.h routines. gcc/ * real.h (REAL_MODE_FORMAT

Re: Fix real_2expN mode arguments in fixed-value.c

On 10/29/2015 04:28 PM, Richard Sandiford wrote: * fixed-value.c (check_real_for_fixed_mode, fixed_from_string) (fixed_to_decimal, fixed_convert_from_real) (real_convert_from_fixed): Fix mode arguments to real_2expN. Passing VOIDmode rather than the real mode is a bit of

Re: [PATCH 00/16] Unit tests framework (v3)

On 10/29/2015 08:21 PM, Jeff Law wrote: Excellent point. I think this is worth some serious thought. Given the state of GCC's sources, tests of this nature are going to be inherently tied to implementation details/sources rather than interfaces. That's obviously not ideal, but it is where we a

Re: [PATCH 5/5] remove usage of ADJUST_FIELD_ALIGN in encoding.c

On 10/30/2015 12:48 PM, tbsaunde+...@tbsaunde.org wrote: -#ifdef ADJUST_FIELD_ALIGN - desired_align = ADJUST_FIELD_ALIGN (type, desired_align); +#if defined __arc__ || defined _AIX + if (TYPE_MODE (strip_array_types (TREE_TYPE (type))) == DFmode) +desired_align = MIN (desired_align, 32); +#

Re: [PATCH 1/5] 2015-01-25 Paul Thomas

On 10/30/2015 12:48 PM, tbsaunde+...@tbsaunde.org wrote: From: pault PR fortran/67171 * trans-array.c (structure_alloc_comps): On deallocation of class components, reset the vptr to the declared type vtable and reset the _len field of unlimited polymorphic compon

Re: [PATCH 5/5] remove usage of ADJUST_FIELD_ALIGN in encoding.c

it's not target independent code. Are you suggesting to add a config/ to libobjc? IMHO for a not really mantained frontend / target lib that's an excessive requirement. If necessary, then yes that would be a better solution. Even just keeping the abstraction of the macro and putting definiti

Re: [PATCH 5/5] remove usage of ADJUST_FIELD_ALIGN in encoding.c

On 10/30/2015 01:47 PM, Richard Biener wrote: On Fri, Oct 30, 2015 at 1:28 PM, Bernd Schmidt wrote: it's not target independent code. Are you suggesting to add a config/ to libobjc? IMHO for a not really mantained frontend / target lib that's an excessive requirement. If neces

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

The following patch passes testing with make -k check-c DEJAGNU=.../dejagnu.exp RUNTESTFLAGS=--target_board=nvptx-none-run with no new regressions, and fixes 1 test: -FAIL: gcc.dg/compat/struct-align-1 c_compat_x_tst.o-c_compat_y_tst.o execute Ok. Thanks! Bernd

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

(Jakub Cc'd because of code he added for PR23567). On 10/27/2015 11:35 PM, Abe wrote: Thanks for all your feedback. I have integrated as much of it as I could in the available time. Unfortunately not all of it - I still think we need to have a better strategy of selecting a scratchpad than a

Re: [PATCH] replace BITS_PER_UNIT with __CHAR_BIT__ in target libs

On 10/30/2015 06:10 PM, DJ Delorie wrote: $subject as far as I am aware these are the same on all supported targets. The documentation for __CHAR_BIT__ says not to use it... @item __CHAR_BIT__ Defined to the number of bits used in the representation of the @code{char} data type. It e

Re: [PATCH][RFC] Remove warning for SET VOIDmode -> BLKmode.

On 11/03/2015 06:09 PM, Dominik Vogt wrote: The attached patch removes the messages "warning: source missing a mode?" and "warning: operand ... missing mode?" (genrecog.c) for the case that the DEST of a SET rtx has BKLmode and SRC has void mode. The mvcle instruction on s390 has a pretty weird

Re: [OpenACC] internal fn folding

On 11/02/2015 02:56 PM, Nathan Sidwell wrote: On 10/28/15 14:40, Nathan Sidwell wrote: Richard, this patch adds folding for the new GOACC_DIM_POS and GOACC_DIM_SIZE internal functions. IIUC gimple_fold_call is the right place to add this. The size of a compute dimension is very often a compile

Re: [Patch ifcvt] Teach RTL ifcvt to handle multiple simple set instructions

On 10/30/2015 07:03 PM, James Greenhalgh wrote: + i = tmp_i; <- Should be cleaned up Maybe reword as "Subsequent passes are expected to clean up the extra moves", otherwise it sounds like a TODO item. + read back in anotyher SET, as might occur in a swap idiom or Typo. +

Re: [2/3] OpenACC reductions

On 11/02/2015 05:35 PM, Nathan Sidwell wrote: +/* Size of buffer needed for worker reductions. This has to be Maybe "description" rather than "Size" since there's really four variables we're covering with the comment. + worker_red_size = (worker_red_size + worker_red_align - 1) +

Re: [PATCH] Better error messages for merge-conflict markers (v3)

On 10/30/2015 04:16 PM, David Malcolm wrote: The idea is to more gracefully handle merger conflict markers in the source code being compiled. Specifically, in the C and C++ frontends, if we're about to emit an error, see if the source code is at a merger conflict marker, and if so, emit a more s

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

On 11/04/2015 05:17 PM, Andreas Arnez wrote: gcc/c/ChangeLog: PR debug/67192 * c-parser.c (c_parser_while_statement): Finish the loop before parsing ahead for misleading indentation. (c_parser_for_statement): Likewise. This is OK. Does C++ have similar issues?

Re: [ping] Change behavior of -fsched-verbose option

On 11/05/2015 09:11 AM, Nikolai Bozhenov wrote: Please commit if it is OK for trunk. Hmm, do you have a copyright assignment on file? Bernd

Re: [PATCH/RFC/RFA] Machine modes for address printing (all targets)

On 11/04/2015 01:54 PM, Julian Brown wrote: That's not all targets by any means, but may be enough to warrant a change in the interface. I propose that: * The output_address function should have a machine_mode argument added. Bare addresses (e.g. the 'a' case in final.c) should pass "VOIDm

Re: [PATCH] Use subreg_regno instead of subreg_regno_offset

On 11/02/2015 11:29 PM, Anatoly Sokolov wrote: @@ -5522,12 +5516,7 @@ op0 = SUBREG_REG (op0); code0 = GET_CODE (op0); if (code0 == REG && REGNO (op0) < FIRST_PSEUDO_REGISTER) - op0 = gen_rtx_REG (word_mode, - (REGNO (op0) + -

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

On 11/05/2015 12:33 PM, Andreas Arnez wrote: Thanks again for reviewing. Are you going to look at patch #2 as well? Yeah, still thinking about that one. Does C++ have similar issues? Not this particular issue, AFAIK. But I've just looked at how C++ fares with the enhanced version of pr67

Re: Merge of HSA branch

On 11/05/2015 10:51 PM, Martin Jambor wrote: Individual changes are described in slightly more detail in their respective messages. If you are interested in how the HSAIL generation works in general, I encourage you to have a look at my Cauldron slides or presentation, only very few things have

Re: [PATCH] PR driver/67613 - spell suggestions for misspelled command line options

On 11/04/2015 03:53 PM, David Malcolm wrote: This patch adds hints to the option-not-found error in the driver, using the Levenshtein distance implementation posted here: "[PATCH 0/2] Levenshtein-based suggestions (v3)" https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03379.html It splits out th

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 06/17/2015 07:11 PM, Sandra Loosemore wrote: Index: gcc/regrename.c === --- gcc/regrename.c (revision 224532) +++ gcc/regrename.c (working copy) @@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he int r

regrename: Fix for earlyclobber operands

I have a patch which makes use of the renamer more often, and this exposed a bug with earlyclobber operands. The code that does the terminate_write step has the following comment: /* Step 5: Close open chains that overlap writes. Similar to step 2, we hide in-out operand

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/06/2015 12:43 AM, Abe wrote: Feedback from Bernd has also been applied. But inconsistently, and I think not quite in the way I meant it in one case. -/* Return true if a write into MEM may trap or fault. */ - static bool noce_mem_write_may_trap_or_fault_p (const_rtx mem) { - rtx

Re: Merge of HSA branch

On 11/06/2015 11:30 AM, Richard Biener wrote: On Fri, 6 Nov 2015, Bernd Schmidt wrote: Realistically we're probably not going to reject this work, but I still want to ask whether the approach was acked by the community before you started. I'm really not exactly thrilled about

regrename: don't overflow insn_rr_info

This one is a fix for something that could currently only affect c6x, but I have code that exposes it on i386. When optionally gathering operand info in regrename, we can overflow the array in certain situations. This can occur when we have a situation where a value is constructed in multiple

Re: [hsa 10/12] HSAIL BRIG description header file (hopefully not a licensing issue)

On 11/05/2015 11:05 PM, Martin Jambor wrote: Initially, I have created the file by copying out pieces of PDF documentation but the latest version of the file (describing final HSAIL 1.0) is actually taken from the HSAIL (dis)assembler developed by HSA foundation and released by "University of Ill

Re: regrename: don't overflow insn_rr_info

On 11/06/2015 12:17 PM, Ramana Radhakrishnan wrote: On 06/11/15 11:08, Bernd Schmidt wrote: This one is a fix for something that could currently only affect c6x, but I have code that exposes it on i386. When optionally gathering operand info in regrename, we can overflow the array in certain

Re: [hsa 10/12] HSAIL BRIG description header file (hopefully not a licensing issue)

On 11/06/2015 12:29 PM, Bernd Schmidt wrote: David Cc'ed so he can take the necessary steps. Initially, I have created the file by copying out pieces of PDF documentation but the latest version of the file (describing final HSAIL 1.0) is actually taken from the HSAIL (dis)assembler deve

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

Sanity-checked by running the libgomp testsuite. I realize the #ifdef in internal-fn.c is not appropriate: it's there to make the patch smaller, I'll replace it with a target hook if otherwise this approach is ok. FWIW, no objections from me regarding the approach. Bernd

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

On 10/30/2015 05:44 PM, Alexander Monakov wrote: + /* Ignore "omp target entrypoint" here: OpenMP target region functions are + called from gomp_nvptx_main. The corresponding kernel entry is emitted + from write_omp_entry. */ } I'm probably confused, but didn't we agree that this s

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

On 11/06/2015 03:08 PM, Jakub Jelinek wrote: On Fri, Nov 06, 2015 at 03:05:05PM +0100, Bernd Schmidt wrote: This patch creates a new "omp target entrypoint" annotation that appears not to be used - it would be better to just not annotate a function if it's not going to need entry

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/06/2015 03:10 PM, Sebastian Pop wrote: On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote: Formatting problem, here and in a few other places. I didn't fully read the patch this time around. I'm probably not reviewing further patches because I don't see this progres

Re: Move c_getstr to fold-const.c

On 11/06/2015 04:05 PM, Richard Sandiford wrote: Upcoming patches to fold-const-call.c want to use c_getstr, which is currently defined in builtins.c. The function doesn't really do anything related to built-ins, and I'd rather not make fold-const-call.c depend on builtins.c and builtins.c depen

Re: Don't treat rint as setting errno

On 11/06/2015 04:02 PM, Richard Sandiford wrote: builtins.def says that rint sets errno, but it looks like this might be a mistake. C99 says that rint doesn't set errno and the builtins.c expansion code doesn't try to keep errno up to date. [snip explanation of the history] FWIW the manpage h

Re: Handle constant fp classifications in fold-const-call.c

On 11/06/2015 04:08 PM, Richard Sandiford wrote: Move the constant "is finite", "is infinite" and "is nan" queries to fold-const-call.c. I kind of missed it when that file was added, but I'm assuming it's the correct direction for things to move. Ok. Bernd

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/06/2015 04:52 PM, Sebastian Pop wrote: opinion). If you want a half-finished redzone allocator, I can send you a patch. Yes please. Let's get it work. Here you go. This is incomplete and does not compile, but it shows the direction I have in mind and isn't too far off. I had a simila

Remove noce_mem_write_may_trap_or_fault_p in ifcvt

The ifcvt scratchpad patch had some modifications to the function noce_mem_write_may_trap_or_fault_p in ifcvt, but as far as I can tell, that function itself makes no sense whatsoever. It returns true for MEM_READONLY_P which is sensible, but then it also goes on an unreliable search through th

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/06/2015 07:39 PM, Jeff Law wrote: Given the name "..may_trap_or_fault_p" ISTM that its mode of operation should be to return true (the safe value) unless we can prove the write will not fault. The more cases we can prove true, the better AFAICT. The PLUS case looks totally wrong. Though

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/06/2015 08:04 PM, Steve Ellcey wrote: When I made this change I had one regression in the GCC testsuite (gcc.dg/fixed-point/convert-sat.c). I tracked this down to the fact that emit_library_call_value_1 does not do any argument promotion because it does not have the original tree type inf

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/06/2015 08:27 PM, Steve Ellcey wrote: Are you thinking of a simple function that is called on all targets or a target specific function? Maybe a target specific function would be safer. No, I think just what you have there is probably sufficient. Bernd

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/06/2015 08:20 PM, Jeff Law wrote: So maybe what noce_mem_write_may_trap_or_fault_p is really trying to do is take objects where may_trap_or_fault_p returns false, but which in fact may fault if we write that memory? ie, working around lameness in may_trap_or_fault_p not knowing the context

Re: regrename: Fix for earlyclobber operands

On 11/06/2015 08:30 PM, Jeff Law wrote: * regrename.c (record_out_operands): Terminate earlyclobbered operands here. Do you want to terminate those chains after step 6 is complete so that the earlyclobber output conflicts with all the other outputs? I'm not sure what you mean by your q

Re: [PATCH][RFC] Remove warning for SET VOIDmode -> BLKmode.

On 11/06/2015 10:45 PM, Jeff Law wrote: On 11/03/2015 10:16 AM, Dominik Vogt wrote: * genrecog.c (validate_pattern): Allow "set VOIDmode -> BLKmode" without warnings. First, for reference, I was initially concerned the patterns were bogus, but these are reasonably canonical ways to impl

Re: Add a combined_fn enum

On 11/07/2015 01:22 PM, Richard Sandiford wrote: I'm working on a patch series that needs to be able to treat built-in functions and internal functions in a similar way. This patch adds a new enum, combined_fn, that combines the two together. It also adds utility functions for seeing which co

Re: Add a combined_fn enum

On 11/09/2015 11:24 AM, Richard Sandiford wrote: Bernd Schmidt writes: I see it's already acked, but have you considered just doing away with the builtin/internal function distinction? I think they're too different to be done away with entirely. built-in functions map directly to

Re: [PATCH PR52272]Be smart when adding iv candidates

On 11/08/2015 10:11 AM, Richard Biener wrote: On November 8, 2015 3:58:57 AM GMT+01:00, "Bin.Cheng" wrote: +inline bool +iv_common_cand_hasher::equal (const iv_common_cand *ccand1, + const iv_common_cand *ccand2) +{ + return ccand1->hash == ccand2->hash +&& op

Re: Add a combined_fn enum

On 11/09/2015 03:57 PM, Richard Sandiford wrote: I'm not sure what you mean by "fix" though. I don't think we can change any of the constraints above. I don't see why they couldn't be relaxed. What's stopping us from defining some builtins independently of the frontends, and don't all langu

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

On 11/09/2015 02:32 PM, Robert Suchanek wrote: The results below were generated for CSiBE benchmark and the numbers in columns express bytes in format 'net (gain/loss)' to show the difference with and without the patch when -frename-registers switch is used. I'm not entirely sure what the numbe

Re: RFC: Incomplete Draft Patches to Correct Errors in Loop Unrolling Frequencies (bugzilla problem 68212)

On 11/07/2015 03:44 PM, Kelvin Nilsen wrote: This is a draft patch to partially address the concerns described in bugzilla problem report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212). The patch is incomplete in the sense that there are some known shortcomings with nested loops which I am s

Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-11-09 Trevor Saunders * defaults.h (EH_RETURN_HANDLER_RTX): New default definition. * df-scan.c (df_get_exit_block_use_set): Adjust. * except.c (expand_eh_return): Lik

Re: [PATCH 05/12] always define VMS_DEBUGGING_INFO

In general I think the _DEBUGGING_INFO patches are going to be OK, modulo Jeff's comment about stage 1. I think they shouldn't have been split - it causes numerous unnecessary extra changes, and the intermediate stages look very inconsistent. -#ifdef VMS_DEBUGGING_INFO - else if (write_symbo

Re: [PATCH 12/12] always define ENABLE_OFFLOADING

On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote: -#ifdef ENABLE_OFFLOADING /* If the user didn't specify any, default to all configured offload targets. */ if (offload_targets == NULL) handle_foffload_option (OFFLOAD_TARGETS); -#endif This one I would keep guarded

Re: [PATCH 11/12] always define HAVE_AS_LEB128

-#ifdef HAVE_AS_LEB128 +#if HAVE_AS_LEB128 This patch doesn't seem to actually remove any conditional compilation? Bernd

Re: [PATCH 02/12] remove EXTENDED_SDB_BASIC_TYPES

The last target using this was i960, which was removed many years ago, so there's no reason to keep it. gcc/ChangeLog: 2015-11-09 Trevor Saunders * gsyms.h (enum sdb_type): Remove code for EXTENDED_SDB_BASIC_TYPES. (enum sdb_masks): Likewise. * sdbout.c (plai

Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

On 11/09/2015 07:42 PM, Jeff Law wrote: On 11/09/2015 11:27 AM, Bernd Schmidt wrote: On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-11-09 Trevor Saunders * defaults.h (EH_RETURN_HANDLER_RTX): New default definition. * df-scan.c

Re: [PATCH 01/12] reduce conditional compilation for HARD_FRAME_POINTER_IS_ARG_POINTER

On 11/09/2015 05:47 PM, tbsaunde+...@tbsaunde.org wrote: +++ b/gcc/dbxout.c @@ -3076,10 +3076,8 @@ dbxout_symbol_location (tree decl, tree type, const char *suffix, rtx home) || (REG_P (XEXP (home, 0)) && REGNO (XEXP (home, 0)) != HARD_FRAME_POINTER_REGNUM

Re: [PATCH 05/12] always define VMS_DEBUGGING_INFO

On 11/09/2015 08:29 PM, Trevor Saunders wrote: as I said in 0/12 this did go through config-list.mk, and checking again this does build on alpha-dec-vms. The question I have is - why does it build on any other target? It's the reference that's unconditional, not the definition. Do we have enou

Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

On 11/09/2015 07:52 PM, Trevor Saunders wrote: yeah, that's more or less my thought, and this makes hookization easier since you can now mechanically add a hook for each thing in defaults.h that invokes the macro. Then for each target you can go through and replace the macro with an override of

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/09/2015 05:59 PM, Steve Ellcey wrote: Here is a version with the code moved into a new function. How does this look? 2015-11-09 Steve Ellcey * optabs.c (prepare_libcall_arg): New function. (expand_fixed_convert): Add call to prepare_libcall_arg. Hold on a moment - I

Re: [PATCH 01/12] reduce conditional compilation for HARD_FRAME_POINTER_IS_ARG_POINTER

On 11/09/2015 09:58 PM, Trevor Saunders wrote: With the exception of the emit-rtl.c hunk I think I've correctly convinced myself this macro is just an optimization. I also looked at that one and initially thought that it can simply go away, but the earlier test for FRAME_POINTER_REGNUM also ha

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/09/2015 10:10 PM, Steve Ellcey wrote: emit_library_call_value_1 has no way of knowing if the promotion should be signed or unsigned because it has a mode (probably QImode or HImode) that it knows may need to be promoted to SImode but it has no way to know if that should be a signed or unsig

Re: Use combined_fn in tree-vrp.c

On 11/07/2015 01:46 PM, Richard Sandiford wrote: @@ -3814,8 +3817,8 @@ extract_range_basic (value_range *vr, gimple *stmt) break; /* Both __builtin_ffs* and __builtin_popcount return [0, prec]. */ - CASE_INT_FN (BUILT_IN_FFS): - CASE_INT_FN (BUILT_IN_

Re: [PATCH PR52272]Be smart when adding iv candidates

On 11/10/2015 09:25 AM, Bin.Cheng wrote: Thanks for reviewing. I haven't committed it yet, could you please point out which quoted piece is so that I can update patch? Sorry, I thought it was pretty obvious... +{ + return ccand1->hash == ccand2->hash +&& operand_equal_p (ccand1->bas

Re: RFC: Incomplete Draft Patches to Correct Errors in Loop Unrolling Frequencies (bugzilla problem 68212)

On 11/10/2015 10:56 AM, Bernhard Reutner-Fischer wrote: On November 9, 2015 6:35:20 PM GMT+01:00, Bernd Schmidt wrote: I think something that starts with bb->loop_father and iterates outwards would be more efficient. flow_bb_inside_loop_p() ? Ah thanks. I knew there must be one bu

Re: [PATCH 1/2] simplify-rtx: Simplify trunc of and of shiftrt

On 11/09/2015 08:33 AM, Segher Boessenkool wrote: If we have (truncate:M1 (and:M2 (lshiftrt:M2 (x:M2) C) C2)) we can write it instead as (and:M1 (lshiftrt:M1 (truncate:M1 (x:M2)) C) C2) + /* Likewise (truncate:QI (and:SI (lshiftrt:SI (x:SI) C) C2)) into + (and:QI (lshift

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

On 11/09/2015 02:32 PM, Robert Suchanek wrote: @@ -1707,6 +1749,8 @@ build_def_use (basic_block bb) scan_rtx (insn, &XEXP (note, 0), ALL_REGS, mark_read, OP_INOUT); + terminated_this_insn = NULL; + /* Step 4: Close chains for registers that

Re: [PATCH 01/02] PR/62314: add ability to add fixit-hints

On 11/10/2015 05:35 PM, David Malcolm wrote: + /* Nasty workaround to convince the linker to add + rich_location::add_fixit_insert + rich_location::add_fixit_remove + rich_location::add_fixit_replace + to cc1 for use by diagnostic_plugin_test_show_locus, + before anything

Re: [PATCH 1/2] simplify-rtx: Simplify trunc of and of shiftrt

On 11/10/2015 06:44 PM, Segher Boessenkool wrote: Yes I know. All the rest of the code around is it like this though. Do you want this written in a saner way? I won't object to leaving it as-is for now, but in the future it would be good to keep this in mind. I'm not entirely sure what th

Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

On 11/09/2015 11:53 PM, Trevor Saunders wrote: I don't really know him, but I don't really disagree with where he wants to get to. However I think we work fairly different ways, and review things differently. When I review patches (mostly for stuff more directly related to Mozilla my standards

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

On 11/10/2015 11:33 PM, Robert Suchanek wrote: The reason behind the failures is that the terminated_this_insn had a different number of consecutive registers (and mode) to the input operand in a move currently being considered for tying. In the fix, I allow tying only if there is matching numbe

Re: [patch] Fix PR target/67265

On 11/11/2015 12:38 PM, Eric Botcazou wrote: this is an ICE on an asm statement requiring a lot of registers, when compiled in 32-bit mode on x86/Linux with -O -fstack-check -fPIC: pr67265.c:10:3: error: 'asm' operand has impossible constraints The issue is that, since stack checking defines ST

Re: [ptx] partitioning optimization

On 11/10/2015 11:33 PM, Nathan Sidwell wrote: I've committed this patch to trunk. It implements a partitioning optimization for a loop partitioned over both vector and worker axes. We can elide the inner vector partitioning state propagation, if there are no intervening instructions in the worke

Re: [patch] Fix PR target/67265

On 11/11/2015 01:31 PM, Eric Botcazou wrote: Yes, it probably should, thanks for spotting it, revised patch attached. PR target/67265 * ira.c (ira_setup_eliminable_regset): Do not necessarily create the frame pointer for stack checking if non-call exceptions aren't us

Re: [C/C++ PATCH] Reject declarators with huge arrays (PR c/68107, c++/68266)

On 11/11/2015 01:31 PM, Marek Polacek wrote: Certainly I'm in favor of sharing code between C and C++ FEs, though in this case it didn't seem too important/obvious, because of the extra != error_mark_node check + I don't really like the new function getting *type and setting it there. Make it

Re: Enable pointer TBAA for LTO

On 11/11/2015 10:21 AM, Richard Biener wrote: On Tue, 10 Nov 2015, Jan Hubicka wrote: The reason is that TYPE_CANONICAL is initialized in get_alias_set that may be called before we finish all merging and then it is more fine grained than what we need here (i.e. TYPE_CANONICAL of pointers to two

Re: [ptx] partitioning optimization

On 11/11/2015 02:59 PM, Nathan Sidwell wrote: That's not the problem. How to conditionally enable the test is the difficulty. I suspect porting something concerning accel_compiler from the libgomp testsuite is needed? Maybe a check_effective_target_offload_nvptx which tries to see if -fofflo

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/10/2015 10:35 PM, Abe wrote: I wrote: What I'm saying is I don't see a reason for a "definitely always unsafe" state. Why would any access not be made safe if a scratchpad is used? Because the RTL if-converter doesn`t "know" how to convert {everything that can be made safe using a scratc

Re: [PATCH 04/N] Fix big memory leak in ix86_valid_target_attribute_p

On 11/12/2015 12:29 PM, Richard Biener wrote: +static bool opts_obstack_initialized = false; + +/* Initialize opts_obstack if not initialized. */ + +void +init_opts_obstack (void) +{ + if (!opts_obstack_initialized) +{ + opts_obstack_initialized = true; + gcc_obstack_init (&opts_o

Re: [PATCH] nvptx: implement automatic storage in custom stacks

I'm proposing the following patch as a step towards resolving the issue with inaccessibility of stack storage (.local memory) in PTX to other threads than the one using that stack. The idea is to have preallocated stacks, and have __nvptx_stacks[] array in shared memory hold current stack pointer

Re: [PATCH] nvptx: implement automatic storage in custom stacks

On 11/12/2015 03:59 PM, Alexander Monakov wrote: On Thu, 12 Nov 2015, Bernd Schmidt wrote: I've run it through make -k check-c regtesting. These are new fails, all mysterious: These would have to be investigated first. Any specific suggestions? The PTX code emitted from GCC differs

Re: [PATCH] Make disabled-optimization warning more informative; increase default max-gcse-memory

The expanded warning allowed me to see how much memory really was needed to apply gcse to some of my routines, and 128MB fixes my problem. The limit has been 50MB for over 10 years, I think we can up it a bit now. { + unsigned int memory_request = n_basic_blocks_for_fn (cfun) +* SBITMAP_SE

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 11/06/2015 08:51 PM, Jeff Law wrote: I think the change is fine for the trunk, though I'm still curious about how the code as-is resulted in a comparison failure. I've been retesting and I think this was a case of something else triggering an random failure - the patch made it go away on th

Re: [PATCH 0/2] Levenshtein-based suggestions (v3)

On 11/13/2015 04:11 PM, Marek Polacek wrote: Sorry, I changed my mind. Since QUAL_UNION_TYPE is Ada-only thing and we check (RECORD_TYPE || UNION_TYPE) in a lot of places in the C FE, introducing RECORD_OR_UNION_TYPE_P everywhere would unnecessarily slow things down. I don't think so, the thre

Re: [nvptx] complex vector reductions

On 11/13/2015 04:11 PM, Nathan Sidwell wrote: I noticed that we weren't supporting reductions of complex type, particularly complex double. I've committed this patch to add support for vector reductions. We split the complex type apart and process each half before sticking it back together agai

Re: [ptx] partitioning optimization

On 11/13/2015 09:06 PM, Nathan Sidwell wrote: On 11/11/15 09:19, Bernd Schmidt wrote: On 11/11/2015 02:59 PM, Nathan Sidwell wrote: That's not the problem. How to conditionally enable the test is the difficulty. I suspect porting something concerning accel_compiler from the libgomp test

[1/2] i386 ROP mitigation: make more of regrename callable

This just creates a new function in regrename.c, which I need for the 2/2 patch that I'll submit in a moment. Bootstrapped and tested on x86_64-linux. Ok? Bernd * regrename.h (regrename_find_superclass): Declare. (regrename_find_superclass): New function, code moved from ... (rename_chains)

[2/2] i386 ROP mitigation

This adds a new -mmitigate-rop option to the i386 port. The idea is to mitigate against certain forms of attack called "return oriented programming" that some of our security folks are concerned about. The basic idea is that the stack gets smashed and then, just by chaining function returns and

Re: [C PATCH] Use RECORD_OR_UNION_TYPE_P macro

On 11/13/2015 07:09 PM, Marek Polacek wrote: As promised & discussed in the thread here: . diffstat shows: c/c-decl.c | 38 +-- c/c-typeck.c | 81 +++---

Re: [PATCH, x86] Fix posix_memalign declaration in mm_malloc.h

On 11/13/2015 06:11 PM, Szabolcs Nagy wrote: Followup to https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01433.html The posix_memalign declaration is incompatible with musl libc in C++, because of the exception specification (matters with -std=c++11 -pedantic-errors). It also pollutes the namespa

Re: Automatic openacc loop partitioning

+ this_mask = (this_mask & -this_mask); Unnecessary parens. + if (!this_mask && noisy) + warning_at (loop->loc, 0, + "insufficient partitioning available to parallelize loop"); Should this really be an unconditional warning? Isn't sequential execution a val

<    1   2   3   4   5   6   7   8   9   10   >