Re: Reviving SH FDPIC target
On Fri, Sep 04, 2015 at 06:04:15PM -0500, Segher Boessenkool wrote: > On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote: > > One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces > > different (less efficient) code from just gcc -mfdpic, which seems > > wrong, but agrees with sh.c which has a number of checks for flag_pic > > not matched with a TARGET_FDPIC check. > > Generic code tests flag_pic in important places as well. Hmm, these are probably correct: things like default TLS model, whether external functions defined in the same TU are subject to interposition, etc. So ignoring -fPIC would be incorrect, and in fact the different/less-efficient codegen might be correct. But if -fPIE is generating different code, that's probably a bug (or at least unwanted). > > I'm thinking all of these > > should either be flag_pic||TARGET_PIC or flag_pic&&!TARGET_FDPIC, > > depending on whether the code applies to all PIC or is specific to the > > non-FDPIC PIC model where r12 is call-saved. Does this sound correct? > > I think we need spurious -fPIC to work (although it could be handled > > with spec magic) and not pessimize code, since most library builds > > will use -fPIC. > > If you never want -fPIC (or -fpic) if fdpic is enabled, you can disable > it (in sh_option_override)? Even if it weren't needed for the above reasons, having it generate an error would be very problematic from a standpoint of being able to build packages unmodified. So I probably just need to have all the conditionals in sh.c right (checking either ||TARGET_FDPIC or &&!TARGET_FDPIC). Rich
Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
2015-09-05 1:50 GMT+03:00 Mike Stump : > > On Sep 4, 2015, at 2:45 PM, Ilya Verbin wrote: > >> 2015-09-04 22:27 GMT+03:00 Mike Stump : >>> On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas >>> wrote: >>> * intelmic-mkoffload.c (prepare_target_image): Fix if the temp path >>> contains a '-‘. >>> >>> So, out of curiosity, did you test all characters other than null? If - >>> doesn’t work, there is a good chance that no such test has been done, and >>> there is a small hoard of bugs, all the same in there. >> >> Good point. Objcopy in bfd/binary.c creates symbol names this way: >> >> for (p = buf; *p; p++) >>if (! ISALNUM (*p)) >> *p = '_’; > > So, this code can’t be the code in question, as - is ! ALNUM, and then should > have been a _, meaning ‘-‘ would not have to be handled. Since the code is > handling ‘-‘, this can’t be the code in question? When we run "objcopy /tmp-1/liba.so", this code in bfd/binary.c creates a symbol called "_binary__tmp_1_liba_so_start". Then intelmic-mkoffload.c wants to rename it to "__offload_image_intelmic_start". To do this, it prepares a string "--redefine-sym _binary__tmp_1_liba_so_start=__offload_image_intelmic_start", therefore it should replace all ! ISALNUM chars in the name, as objcopy does. -- Ilya
Re: Reviving SH FDPIC target
On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote: > One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces > different (less efficient) code from just gcc -mfdpic, which seems > wrong, but agrees with sh.c which has a number of checks for flag_pic > not matched with a TARGET_FDPIC check. Generic code tests flag_pic in important places as well. > I'm thinking all of these > should either be flag_pic||TARGET_PIC or flag_pic&&!TARGET_FDPIC, > depending on whether the code applies to all PIC or is specific to the > non-FDPIC PIC model where r12 is call-saved. Does this sound correct? > I think we need spurious -fPIC to work (although it could be handled > with spec magic) and not pessimize code, since most library builds > will use -fPIC. If you never want -fPIC (or -fpic) if fdpic is enabled, you can disable it (in sh_option_override)? Segher
[PATCH] [graphite] Remove limit_scops
This patch removes graphite-scop-detection.c:limit_scops function and fix related issues arising because of that. The functionality limit_scop was added as an intermediate step to discard the loops which graphite could not handle. Removing limit_scop required handling of different cases of loops and surrounding code. The scop is now larger so most test cases required 'number of scops detected' to be fixed. By increasing the size of scop we can now optimize loops which are 'siblings' of each other. This could enable loop fusion on a number of loops. Since in the graphite framework we mostly want to opimize loop-nests/adjacent-loops, we now discard scops with less than 2 loops. We also discard scops without any data references. Essentially: - Remove limite_scops. - Only select scops when there are at least two loops (loop nest or, side by side). - Discard loops without data-refs. - Fix test cases. Passes bootstrap and reg-test. gcc/ChangeLog: 2015-09-02 Aditya Kumar Sebastian Pop * graphite-isl-ast-to-gimple.c (gcc_expression_from_isl_ast_expr_id): Return the parameter if it was saved in corresponding parameter_rename_map of the region. (copy_def): Copy def from sese region to the newly created region. (copy_internal_parameters): Copy all the internal parameters defined within a region to the newly created region. (graphite_regenerate_ast_isl): Copy parameters to the new region before translating isl to gimple. * graphite-scop-detection.c (graphite_can_represent_loop): Bail out if the loop-nest does not have any data-references. (build_graphite_scops): Create a scop only when there is at least one loop inside it. (contains_only_close_phi_nodes): Deleted. (print_graphite_scop_statistics): Remove printing of scop-statistics before limit_scops. (limit_scops): Deleted. (build_scops): Removed call to limit_scops. * sese.c (new_sese): Construct. (free_sese): Destruct. (sese_add_exit_phis_edge): update_stmt after exit phi edge has been added. (set_rename): Pass sese region so that parameters inside the region can be added to its parameter_rename_map. (rename_uses): Pass sese region. (graphite_copy_stmts_from_block): Do not copy parameters that have been generated in the header of the scop. For each SSA_NAME in the parameter_rename_map rename its usage. (invariant_in_sese_p_rec): Return false if tree t is defined outside sese region. (scalar_evolution_in_region): If the tree t is invariant just return t. * sese.h: Added a parameter renamne map (parameter_rename_map_t) to struct sese to keep track of all the parameters which need renaming. * tree-data-ref.c (loop_nest_has_data_refs): Check if a loop nest has any data-refs. * tree-data-ref.h: Declaration of loop_nest_has_data_refs. gcc/testsuite/ChangeLog: 2015-09-02 Aditya Kumar Sebastian Pop * gcc.dg/graphite/block-0.c: Modifed test case to match current output. * gcc.dg/graphite/block-1.c: Same. * gcc.dg/graphite/block-5.c: Same. * gcc.dg/graphite/block-6.c: Same. * gcc.dg/graphite/interchange-1.c: Same. * gcc.dg/graphite/interchange-10.c: Same. * gcc.dg/graphite/interchange-11.c: Same. * gcc.dg/graphite/interchange-13.c: Same. * gcc.dg/graphite/interchange-14.c: Same. * gcc.dg/graphite/interchange-3.c: Same. * gcc.dg/graphite/interchange-4.c: Same. * gcc.dg/graphite/interchange-7.c: Same. * gcc.dg/graphite/interchange-8.c: Same. * gcc.dg/graphite/interchange-9.c: Same. * gcc.dg/graphite/isl-codegen-loop-dumping.c: Same. * gcc.dg/graphite/pr35356-1.c (foo): Same. * gcc.dg/graphite/pr37485.c: Same. * gcc.dg/graphite/scop-0.c (int toto): Same. * gcc.dg/graphite/scop-1.c: Same. * gcc.dg/graphite/scop-10.c: Same. * gcc.dg/graphite/scop-11.c: Same. * gcc.dg/graphite/scop-12.c: Same. * gcc.dg/graphite/scop-13.c: Same. * gcc.dg/graphite/scop-16.c: Same. * gcc.dg/graphite/scop-17.c: Same. * gcc.dg/graphite/scop-18.c: Same. * gcc.dg/graphite/scop-2.c: Same. * gcc.dg/graphite/scop-21.c (int test): Same. * gcc.dg/graphite/scop-22.c (void foo): Same. * gcc.dg/graphite/scop-4.c: Same. * gcc.dg/graphite/scop-5.c: Same. * gcc.dg/graphite/scop-6.c: Same. * gcc.dg/graphite/scop-7.c: Same. * gcc.dg/graphite/scop-8.c: Same. * gcc.dg/graphite/scop-9.c: Same. * gcc.dg/graphite/scop-mvt.c (void mvt): Introduced dependency so that data-refs remain inside the inner loop. * gcc.dg/graphite/uns-block-1.c: Modifed test case to match o/p.
Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
On Sep 4, 2015, at 2:45 PM, Ilya Verbin wrote: > 2015-09-04 22:27 GMT+03:00 Mike Stump : >> On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas >> wrote: >> * intelmic-mkoffload.c (prepare_target_image): Fix if the temp path >> contains a '-‘. >> >> So, out of curiosity, did you test all characters other than null? If - >> doesn’t work, there is a good chance that no such test has been done, and >> there is a small hoard of bugs, all the same in there. > > Good point. Objcopy in bfd/binary.c creates symbol names this way: > > for (p = buf; *p; p++) >if (! ISALNUM (*p)) > *p = '_’; So, this code can’t be the code in question, as - is ! ALNUM, and then should have been a _, meaning ‘-‘ would not have to be handled. Since the code is handling ‘-‘, this can’t be the code in question?
Re: [PATCH, fortran] PR 53379 Backtrace on error termination
> 2015-09-05 Janne Blomqvist > >PR fortran/53579 >* libgfortran.h (exit_error): New prototype. >* runtime/error.c (exit_error): New function. >(os_error): Call exit_error instead of exit. >(runtime_error): Likewise. >(runtime_error_at): Likewise. >(internal_error): Likewise. >(generate_error): Likewise. >(notify_std): Likewise. >* runtime/stop.c (error_stop_string): Likewise. >(error_stop_numeric): Likewise. OK, except that the PR number is wrong in the ChangeLog). (Related: I’ve just closed PR 63930 as WONTFIX.) Thanks for the patch! FX
[PATCH, fortran] PR 53379 Backtrace on error termination
Hi,
the consesus in PR 53379 seems to be that a backtrace is desired in
case of error termination. The attached patch implements this.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
2015-09-05 Janne Blomqvist
PR fortran/53579
* libgfortran.h (exit_error): New prototype.
* runtime/error.c (exit_error): New function.
(os_error): Call exit_error instead of exit.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(internal_error): Likewise.
(generate_error): Likewise.
(notify_std): Likewise.
* runtime/stop.c (error_stop_string): Likewise.
(error_stop_numeric): Likewise.
--
Janne Blomqvist
diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index 3eb0d85..81240e5 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -675,6 +675,9 @@ internal_proto(show_backtrace);
extern _Noreturn void sys_abort (void);
internal_proto(sys_abort);
+extern _Noreturn void exit_error (int);
+internal_proto(exit_error);
+
extern ssize_t estr_write (const char *);
internal_proto(estr_write);
diff --git a/libgfortran/runtime/error.c b/libgfortran/runtime/error.c
index 4aabe4a..d357edb 100644
--- a/libgfortran/runtime/error.c
+++ b/libgfortran/runtime/error.c
@@ -74,15 +74,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
2.3.5 also explains how co-images synchronize during termination.
- In libgfortran we have two ways of ending a program. exit(code) is
- a normal exit; calling exit() also causes open units to be
- closed. No backtrace or core dump is needed here. When something
- goes wrong, we have sys_abort() which tries to print the backtrace
- if -fbacktrace is enabled, and then dumps core; whether a core file
- is generated is system dependent. When aborting, we don't flush and
- close open units, as program memory might be corrupted and we'd
- rather risk losing dirty data in the buffers rather than corrupting
- files on disk.
+ In libgfortran we have three ways of ending a program. exit(code)
+ is a normal exit; calling exit() also causes open units to be
+ closed. No backtrace or core dump is needed here. For error
+ termination, we have exit_error(status), which prints a backtrace
+ if backtracing is enabled, then exits. Finally, when something
+ goes terribly wrong, we have sys_abort() which tries to print the
+ backtrace if -fbacktrace is enabled, and then dumps core; whether a
+ core file is generated is system dependent. When aborting, we don't
+ flush and close open units, as program memory might be corrupted
+ and we'd rather risk losing dirty data in the buffers rather than
+ corrupting files on disk.
*/
@@ -181,6 +183,23 @@ sys_abort (void)
}
+/* Exit in case of error termination. If backtracing is enabled, print
+ backtrace, then exit. */
+
+void
+exit_error (int status)
+{
+ if (options.backtrace == 1
+ || (options.backtrace == -1 && compile_options.backtrace == 1))
+{
+ estr_write ("\nError termination. Backtrace:\n");
+ show_backtrace (false);
+}
+ exit (status);
+}
+
+
+
/* gfc_xtoa()-- Integer to hexadecimal conversion. */
const char *
@@ -326,7 +345,7 @@ os_error (const char *message)
estr_write ("\n");
estr_write (message);
estr_write ("\n");
- exit (1);
+ exit_error (1);
}
iexport(os_error);
@@ -345,7 +364,7 @@ runtime_error (const char *message, ...)
st_vprintf (message, ap);
va_end (ap);
estr_write ("\n");
- exit (2);
+ exit_error (2);
}
iexport(runtime_error);
@@ -364,7 +383,7 @@ runtime_error_at (const char *where, const char *message,
...)
st_vprintf (message, ap);
va_end (ap);
estr_write ("\n");
- exit (2);
+ exit_error (2);
}
iexport(runtime_error_at);
@@ -402,7 +421,7 @@ internal_error (st_parameter_common *cmp, const char
*message)
because hopefully it doesn't happen too often). */
stupid_function_name_for_static_linking();
- exit (3);
+ exit_error (3);
}
@@ -574,7 +593,7 @@ generate_error (st_parameter_common *cmp, int family, const
char *message)
estr_write ("Fortran runtime error: ");
estr_write (message);
estr_write ("\n");
- exit (2);
+ exit_error (2);
}
iexport(generate_error);
@@ -636,7 +655,7 @@ notify_std (st_parameter_common *cmp, int std, const char *
message)
estr_write ("Fortran runtime error: ");
estr_write (message);
estr_write ("\n");
- exit (2);
+ exit_error (2);
}
else
{
diff --git a/libgfortran/runtime/stop.c b/libgfortran/runtime/stop.c
index 5c5483b..8b8a41f 100644
--- a/libgfortran/runtime/stop.c
+++ b/libgfortran/runtime/stop.c
@@ -145,7 +145,7 @@ error_stop_string (const char *string, GFC_INTEGER_4 len)
(void) write (STDERR_FILENO, string, len);
estr_write ("\n");
- exit (1);
+ exit_error (1);
}
@@ -159,5 +159,5 @@ error_stop_numeric (GFC_INTEGER_4 code)
{
report_exception ();
st_printf ("ERROR STOP %d\n", (int
Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
2015-09-04 22:27 GMT+03:00 Mike Stump : > On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas > wrote: >* intelmic-mkoffload.c (prepare_target_image): Fix if the temp path >contains a '-‘. > > So, out of curiosity, did you test all characters other than null? If - > doesn’t work, there is a good chance that no such test has been done, and > there is a small hoard of bugs, all the same in there. Good point. Objcopy in bfd/binary.c creates symbol names this way: for (p = buf; *p; p++) if (! ISALNUM (*p)) *p = '_'; We should do the same in intelmic-mkoffload.c. I will prepare a patch. -- Ilya
Re: [PATCH] Tweak INTTYPE_MINIMUM to avoid warning
On 09/04/2015 05:01 AM, Marek Polacek wrote: While looking into something else I spotted this UB. I rewrote this to use another UB, but I'd say left-shifting into the sign bit isn't such an anathema as it was. It's -Wshift-negative-value that warns on this. The reason why we haven't seen the warning before is due to a bug I'm fixing in the other patch. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-09-03 Marek Polacek * system.h (INTTYPE_MINIMUM): Rewrite to avoid shift warning. * system.h (INTTYPE_MINIMUM): Rewrite to avoid shift warning. OK. jeff
Re: [RFC] Try vector as a new representation for vector masks
On 09/01/2015 07:08 AM, Ilya Enkovich wrote: On 27 Aug 09:55, Richard Biener wrote: I suggest you try modifying those parts first according to this scheme that will most likely uncover issues we missed. Thanks, Richard. I tried to implement this scheme and apply it for MASK_LOAD and MASK_STORE. There were no major issues (for now). So do we have enough confidence in this representation that we want to go ahead and commit to it? I had to introduce significant number of new patterns in i386 target to support new optabs. The reason was vector compare was never expanded separately and always was a part of a vec_cond expansion. One could argue we should have fixed this already, so I don't see the new patterns as a bad thing, but instead they're addressing a long term mis-design. For now I still don't disable bool patterns, thus new masks apply to masked loads and stores only. Patch is also not tested and tried on several small tests only. Could you please look at what I currently have and say if it's in sync with your view on vector masking? I'm going to let Richi run with this for the most part -- but I will chime in with a thank you for being willing to bounce this around a bit while we figure out the representational issues. jeff
Re: [PATCH] -fopenmp-simd LTO ICE fix (PR middle-end/67452)
On 09/04/2015 09:27 AM, Jakub Jelinek wrote: Hi! This patch is a fix for gomp4.1 branch ICEs on FAIL libgomp.c/for-5.c FAIL libgomp.c++/for-13.C that can be reproduced with intelmic emul offloading even on the trunk with the attached testcase. The problem is that LTO streaming doesn't really like earlier unreferenced VAR_DECLs to be streamed late during output_function (from output_cfg). The patch fixes it by clearing loop->simduid when optimizations removed all IL uses of the var and remove_unused_locals is about to nuke it from cfun->local_decls. Ok for trunk/5.3 if it passes bootstrap/regtest? 2015-09-04 Jakub Jelinek PR middle-end/67452 * tree-ssa-live.c: Include cfgloop.h. (remove_unused_locals): Clear loop->simduid if simduid is about to be removed from cfun->local_decls. * gcc.dg/lto/pr67452_0.c: New test. OK. jeff
Re: [PATCH] Don't ICE on invalid asm memory input (PR inline-asm/67448)
On 09/04/2015 08:29 AM, Marek Polacek wrote: In this PR, we were crashing on an invalid asm. I think let's just reject MODIFY_EXPRs as memory inputs - I'll wager those aren't meant to be supported anyway. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-09-04 Marek Polacek PR inline-asm/67448 * gimplify.c (gimplify_asm_expr): Don't allow MODIFY_EXPR as a memory input. * gcc.dg/asm-10.c: New test. OK. Do we need a corresponding doc update too? If so, consider that pre-approved. jeff
Re: [PATCH 02/10] dse.c: remove some typedefs that hide pointerness
On 09/02/2015 11:26 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-09-02 Trevor Saunders * dse.c (store_info_t): Remove typedef. (group_info_t): Likewise. (const_group_info_t): Likewise. (deferred_change_t): Likewise. (get_group_info): Adjust. (free_store_info): Likewise. (canon_address): Likewise. (clear_rhs_from_active_local_stores): Likewise. (record_store): Likewise. (replace_read): Likewise. (check_mem_read_rtx): Likewise. (scan_insn): Likewise. (remove_useless_values): Likewise. (dse_step1): Likewise. (dse_step2_init): Likewise. (dse_step2_nospill): Likewise. (scan_stores_nospill): Likewise. (scan_reads_nospill): Likewise. (dse_step3_exit_block_scan): Likewise. (dse_step3): Likewise. (dse_step5_nospill): Likewise. (dse_step6): Likewise. Given its highly mechanical nature, I'm going to approve the rest of this 10 part series. Future changes of this nature can be considered pre-approved as well. jeff
Re: [PATCH 01/10] don't typedef alias_set_entry and unhide pointerness
On 09/02/2015 11:26 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2015-09-02 Trevor Saunders * alias.c (alias_set_entry_d): Rename to alias_set_entry. (alias_set_entry): Remove typedef. (alias_set_subset_of): Adjust. (alias_sets_conflict_p): Likewise. (init_alias_set_entry): Likewise. (get_alias_set): Likewise. (new_alias_set): Likewise. (record_alias_subset): Likewise. OK. jeff
Re: [PATCH 00/10] removal of typedefs that hide pointerness episode 1
On 09/02/2015 11:26 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders Hi, Personally I think hiding that variables are pointers is confusing, and I believe consensus is we should move away from this style. So this series starts to do that. patches individually bootstrapped + regtested on x86_64-linux-gnu, ok? That's the consensus as I remember it. Removing it for gimple will a huge mega-patch ;-) jeff
Re: Remove redundant test for global_regs
On 09/02/2015 05:02 PM, Georg-Johann Lay wrote: Anatoliy Sokolov schrieb: Hi. The fixed_reg_set contain all fixed and global registers. This patch change code "fixed_regs[r] || global_regs[r]" with "TEST_HARD_REG_BIT (fixed_reg_set, r)". Even though technically a no-op change TEST_HARD_REG_BIT (fixed_reg_set, r) appears to be a test for r being a fixed register and not for being fixed-or-global register, so the old style fixed_regs[r] || global_regs[r] seems to be less error prone. Perhaps, but it's always been the case that a global register must always be considered fixed. It'd be fairly difficult to implement global registers with the current semantics without those registers being fixed. This invariant is currently enforced by globalize_reg. I wouldn't be at all surprised if there are places that are currently just testing fixed_regs. Johann Bootstrapped and reg-tested on x86_64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. OK for trunk? 2015-08-24 Anatoly Sokolov * cse.c (FIXED_REGNO_P): Don't check global_regs. Use fixed_reg_set instead of fixed_regs. * df-problems.c (can_move_insns_across): Ditto. * postreload.c (reload_combine_recognize_pattern): Ditto. * recog.c (peep2_find_free_register): Ditto. * regcprop.c (copy_value): Ditto. * regrename.c (check_new_reg_p, rename_chains): Ditto. * sel-sched.c (init_regs_for_mode, mark_unavailable_hard_regs): Perhaps a better choice would be to use a macro that implies the register is neither fixed nor global, but only checks if its fixed (with an appropriate comment indicating why this is safe). THen in globalize_reg reference add a comment indicating the macro must be changed if we ever want to support global registers that are not fixed. Ditto. Index: gcc/cse.c === --- gcc/cse.c(revision 226953) +++ gcc/cse.c(working copy) @@ -463,7 +463,7 @@ A reg wins if it is either the frame pointer or designated as fixed. */ #define FIXED_REGNO_P(N) \ ((N) == FRAME_POINTER_REGNUM || (N) == HARD_FRAME_POINTER_REGNUM \ - || fixed_regs[N] || global_regs[N]) + || TEST_HARD_REG_BIT (fixed_reg_set, N)) So why not continue to test fixed_regs here (ie, just drop the global_regs test)? It's a single memory reference and a test against zero. Using TEST_HARD_REG_BIT likely still hits memory, but then on many architectures you're then going to have to do masking/shifting to get the bit you want to look at. That seems to me like a step backwards. Jeff
Re: Reviving SH FDPIC target
On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote: > On Thu, Sep 03, 2015 at 02:58:39PM +, Joseph Myers wrote: > > On Wed, 2 Sep 2015, Rich Felker wrote: > > > > > So if __fpscr_values was the only reason for patch 1/3 in the FDPIC > > > patchset, I think we can safely drop it. And patch 2/3 was already > > > committed, so 3/3, the one I was originally looking at, seems to be > > > all we need. It was approved at the time, so I'll proceed with merging > > > it with 5.2.0. > > > > Well, obviously if trying dropping patch 1/3 you need to remove everything > > related to use_initial_val (the feature added in patch 1/3) from patch > > 3/3. > > As far as I can tell, the only "use" of use_initial_val is defining > the pseudo-instruction in the md file, which causes the code in patch > 1/3 to use it. I see no other references to it. As I understand, the > breakage from not having it (in the original 4.5-era patch) would be > when introducing references to __fpscr_values later, and no longer > having the GOT pointer, but that code is gone now. I have this basically working -- obviously no heavy testing yet, and the specs glue is not sufficient to make it practical for others to try it yet, so it'll be a little longer til I have something to post. One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces different (less efficient) code from just gcc -mfdpic, which seems wrong, but agrees with sh.c which has a number of checks for flag_pic not matched with a TARGET_FDPIC check. I'm thinking all of these should either be flag_pic||TARGET_PIC or flag_pic&&!TARGET_FDPIC, depending on whether the code applies to all PIC or is specific to the non-FDPIC PIC model where r12 is call-saved. Does this sound correct? I think we need spurious -fPIC to work (although it could be handled with spec magic) and not pessimize code, since most library builds will use -fPIC. Rich
Re: Fix reload1.c warning for some targets
On 09/03/2015 02:39 AM, Richard Sandiford wrote: It sounds like Jeff has a much more radical rewrite in mind, Certainly not anything on the immediate horizon. The amount of block copying that'd be needed to isolate the jump threading path would be significant. I do wonder if we should be looking at a way to mark paths which have jump threading opportunities, but which we do not optimize and exploit that information in the uninit and other analysis. Bodik had a paper on those concepts as well. He was mostly looking at how to account for those paths in code coverage analysis, but there may be something useful in there. so for now how about just turning -Wmaybe-uninitialized into a warning for this function? The patch will mean that it becomes a warning even if someone turns off warnings on the command line, but I don't think that's important. Bootstrapped and regression-tested on x86_64-linux-gnu. Also tested with a cross-compiler to sparc-linux-gnu (which also triggered the warning for me). Tested that clang could still compile the file. OK to install? gcc/ * reload1.c (elimination_costs_in_insn): Locally turn -Wmaybe-uninitialized into a warning. I can live with this. Though I'd appreciate it if someone could reduce the sparcv9 testcase and create a bug to track it too. jeff
[fortran,committed] Trivial MVBITS cleanup
The attached patch, committed as rev. 227502 after regtesting on x86_64-apple-darwin15, removes an unused simplify function for MVBITS. FX z.diff Description: Binary data
Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
On Sep 4, 2015, at 4:10 AM, Hahnfeld, Jonas wrote: * intelmic-mkoffload.c (prepare_target_image): Fix if the temp path contains a '-‘. So, out of curiosity, did you test all characters other than null? If - doesn’t work, there is a good chance that no such test has been done, and there is a small hoard of bugs, all the same in there.
Re: [testsuite] Clean up effective_target cache
On Sep 4, 2015, at 8:02 AM, H.J. Lu wrote: >> It's OK for me, but I can't approve it. > > I will check it in as an obvious fix. Thanks, my 12/24 core box will appreciate it.
Re: [PATCH] -fopenmp-simd LTO ICE fix (PR middle-end/67452)
On September 4, 2015 5:27:27 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>This patch is a fix for gomp4.1 branch ICEs on
>FAIL libgomp.c/for-5.c
>FAIL libgomp.c++/for-13.C
>that can be reproduced with intelmic emul offloading even on the trunk
>with the attached testcase. The problem is that LTO streaming doesn't
>really like earlier unreferenced VAR_DECLs to be streamed late during
>output_function (from output_cfg).
>
>The patch fixes it by clearing loop->simduid when optimizations removed
>all IL uses of the var and remove_unused_locals is about to nuke it
>from
>cfun->local_decls.
>
>Ok for trunk/5.3 if it passes bootstrap/regtest?
OK.
Thanks,
Richard.
>2015-09-04 Jakub Jelinek
>
> PR middle-end/67452
> * tree-ssa-live.c: Include cfgloop.h.
> (remove_unused_locals): Clear loop->simduid if simduid is about
> to be removed from cfun->local_decls.
>
> * gcc.dg/lto/pr67452_0.c: New test.
>
>--- gcc/tree-ssa-live.c.jj 2015-08-24 18:27:19.738209359 +0200
>+++ gcc/tree-ssa-live.c2015-09-04 17:16:53.620321240 +0200
>@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.
> #include "tree-ssa.h"
> #include "cgraph.h"
> #include "ipa-utils.h"
>+#include "cfgloop.h"
>
> #ifdef ENABLE_CHECKING
> static void verify_live_on_entry (tree_live_info_p);
>@@ -820,6 +821,14 @@ remove_unused_locals (void)
> }
> }
>
>+ if (cfun->has_simduid_loops)
>+{
>+ struct loop *loop;
>+ FOR_EACH_LOOP (loop, 0)
>+ if (loop->simduid && !is_used_p (loop->simduid))
>+loop->simduid = NULL_TREE;
>+}
>+
> cfun->has_local_explicit_reg_vars = false;
>
> /* Remove unmarked local and global vars from local_decls. */
>--- gcc/testsuite/gcc.dg/lto/pr67452_0.c.jj2015-09-04
>17:12:34.636045313 +0200
>+++ gcc/testsuite/gcc.dg/lto/pr67452_0.c 2015-09-04 17:13:18.473414952
>+0200
>@@ -0,0 +1,23 @@
>+/* { dg-lto-do link } */
>+/* { dg-lto-options { { -O2 -flto -fopenmp-simd } } } */
>+
>+float b[3][3];
>+
>+__attribute__((used, noinline)) void
>+foo ()
>+{
>+ int v1, v2;
>+#pragma omp simd collapse(2)
>+ for (v1 = 0; v1 < 3; v1++)
>+for (v2 = 0; v2 < 3; v2++)
>+ b[v1][v2] = 2.5;
>+}
>+
>+int
>+main ()
>+{
>+ asm volatile ("" : : "g" (b) : "memory");
>+ foo ();
>+ asm volatile ("" : : "g" (b) : "memory");
>+ return 0;
>+}
>
> Jakub
Re: [gomp4.1] Various accelerator updates from OpenMP 4.1
On Fri, Sep 04, 2015 at 09:07:02PM +0300, Ilya Verbin wrote:
> It seems that there is a bug some here:
Thanks, will look at it on Monday.
> Here is the reproducer:
>
> #pragma omp declare target
> int a[1];
> #pragma omp end declare target
>
> void foo ()
> {
> #pragma omp target map(to: a[0:1])
> a;
> }
Jakub
Re: [gomp4.1] Various accelerator updates from OpenMP 4.1
Hi!
It seems that there is a bug some here:
On Wed, Jul 29, 2015 at 19:19:07 +0200, Jakub Jelinek wrote:
> @@ -12918,6 +12989,28 @@ lower_omp_target (gimple_stmt_iterator *
> var = var2;
> }
>
> + if (offloaded
> + && OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER)
> + {
> + if (TREE_CODE (TREE_TYPE (var)) == ARRAY_TYPE)
> + {
> + tree type = build_pointer_type (TREE_TYPE (var));
> + tree new_var = lookup_decl (var, ctx);
> + x = create_tmp_var_raw (type, get_name (new_var));
> + gimple_add_tmp_var (x);
> + x = build_simple_mem_ref (x);
> + SET_DECL_VALUE_EXPR (new_var, x);
> + DECL_HAS_VALUE_EXPR_P (new_var) = 1;
> + }
> + continue;
> + }
> +
> + if (offloaded && OMP_CLAUSE_MAP_PRIVATE (c))
> + {
> + map_cnt++;
> + continue;
> + }
> +
> if (!maybe_lookup_field (var, ctx))
> continue;
>
Here is the reproducer:
#pragma omp declare target
int a[1];
#pragma omp end declare target
void foo ()
{
#pragma omp target map(to: a[0:1])
a;
}
lookup_decl (var, ctx) tries to lookup for 'a', but ctx->cb.decl_map->get ()
returns null-pointer.
$ gcc -fopenmp -c test.c
test.c: In function ‘foo’:
test.c:7:11: internal compiler error: Segmentation fault
#pragma omp target map(to: a[0:1])
^
0xd27276 crash_signal
gcc/toplev.c:352
0xbae3fa lookup_decl
gcc/omp-low.c:1056
0xbe208c lower_omp_target
gcc/omp-low.c:13362
0xbe8464 lower_omp_1
gcc/omp-low.c:14504
0xbe8911 lower_omp
gcc/omp-low.c:14592
0xbe8017 lower_omp_1
gcc/omp-low.c:14436
0xbe8911 lower_omp
gcc/omp-low.c:14592
0xbe808b lower_omp_1
gcc/omp-low.c:14445
0xbe8911 lower_omp
gcc/omp-low.c:14592
0xbe8ad9 execute_lower_omp
gcc/omp-low.c:14630
0xbe8b7e execute
gcc/omp-low.c:14667
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
-- Ilya
RE: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation
All: Thanks Jeff for the review comments. The patch attached incorporate all the review comments given below. Bootstrapped on i386 and Microblaze and the Deja GNU tests for Microblaze results looks fine. [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation. Added a new pass on path splitting on tree SSA representation. The path splitting optimization does the CFG transformation when the two execution paths of the IF-THEN-ELSE merge at the latch node of loop, then duplicate the merge mode into two paths preserving the SSA semantics. ChangeLog: 2015-09-05 Ajit Agarwal * Makefile.in (OBJS): Add tree-ssa-path-split.o * common.opt (ftree-path-split): Add the new flag. * opts.c (default_options_table) : Add an entry for Path splitting optimization at -O2 and above. * passes.def (path_split): Add new path splitting pass. * timevar.def (TV_TREE_PATH_SPLIT): New. * tree-pass.h (make_pass_path_split): New declaration. * tree-ssa-path-split.c: New file. * tracer.c (transform_duplicate): New function. * tracer.h: New header file. * doc/invoke.texi (ftree-path-split): Document. (fdump-tree-path_split): Document. * testsuite/gcc.dg/path-split-1.c: New. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Thursday, August 20, 2015 3:16 AM To: Ajit Kumar Agarwal; Richard Biener Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation On 08/15/2015 11:01 AM, Ajit Kumar Agarwal wrote: > > > From cf2b64cc1d6623424d770f2a9ea257eb7e58e887 Mon Sep 17 00:00:00 > 2001 > From: Ajit Kumar Agarwal > Date: Sat, 15 Aug 2015 18:19:14 +0200 > Subject: [PATCH] [Patch,tree-optimization]: Add new path Splitting pass on > tree ssa representation. > > Added a new pass on path splitting on tree SSA representation. The > path splitting optimization does the CFG transformation of join block > of the if-then-else same as the loop latch node is moved and merged > with the predecessor blocks after preserving the SSA representation. > > ChangeLog: > 2015-08-15 Ajit Agarwal > > * gcc/Makefile.in: Add the build of the new file > tree-ssa-path-split.c Instead: * Makefile.in (OBJS): Add tree-ssa-path-split.o. > * gcc/opts.c (OPT_ftree_path_split) : Add an entry for > Path splitting pass with optimization flag greater and > equal to O2. * opts.c (default_options_table): Add entry for path splitting optimization at -O2 and above. > * gcc/passes.def (path_split): add new path splitting pass. Capitalize "add". > * gcc/tree-ssa-path-split.c: New. Use "New file". > * gcc/tracer.c (transform_duplicate): New. Use "New function". > * gcc/testsuite/gcc.dg/tree-ssa/path-split-2.c: New. > * gcc/testsuite/gcc.dg/path-split-1.c: New. These belong in gcc/testsuite/ChangeLog and remove the "gcc/testsuite" prefix. > * gcc/doc/invoke.texi > (ftree-path-split): Document. > (fdump-tree-path_split): Document. Should just be two lines instead of three. And more generally, there's no need to prefix ChangeLog entries with "gcc/". Now that the ChangeLog nits are out of the way, let's get to stuff that's more interesting. > > Signed-off-by:Ajit agarwalajit...@xilinx.com > --- > gcc/Makefile.in | 1 + > gcc/common.opt | 4 + > gcc/doc/invoke.texi | 16 +- > gcc/opts.c | 1 + > gcc/passes.def | 1 + > gcc/testsuite/gcc.dg/path-split-1.c | 65 ++ > gcc/testsuite/gcc.dg/tree-ssa/path-split-2.c | 60 + > gcc/timevar.def | 1 + > gcc/tracer.c | 37 +-- > gcc/tree-pass.h | 1 + > gcc/tree-ssa-path-split.c| 330 > +++ > 11 files changed, 503 insertions(+), 14 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/path-split-1.c > create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/path-split-2.c > create mode 100644 gcc/tree-ssa-path-split.c > > diff --git a/gcc/common.opt b/gcc/common.opt > index e80eadf..1d02582 100644 > --- a/gcc/common.opt > +++ b/gcc/common.opt > @@ -2378,6 +2378,10 @@ ftree-vrp > Common Report Var(flag_tree_vrp) Init(0) Optimization > Perform Value Range Propagation on trees > > +ftree-path-split > +Common Report Var(flag_tree_path_split) Init(0) Optimization > +Perform Path Splitting Maybe "Perform Path Splitting for loop backedges" or something which is a little more descriptive. The above isn't exactly right, so don't use it as-is. > @@
Re: [Patch, avr] Fix PR65210
Committed.
2015-09-02 10:51 GMT+03:00 Senthil Kumar Selvaraj
:
> Hi,
>
> This (rather trivial) patch fixes PR65210. The ICE happens because code
> wasn't handling io_low attribute where it is supposed to.
>
> If this is ok, could someone commit please? I don't have commit
> access.
>
> Regards
> Senthil
>
> gcc/ChangeLog
>
> 2015-09-02 Senthil Kumar Selvaraj
>
> PR target/65210
> * config/avr/avr.c (avr_eval_addr_attrib): Look for io_low
> attribute as well.
>
> gcc/testsuite/ChangeLog
>
> PR target/65210
> * gcc.target/avr/pr65210.c: New test.
>
> diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
> index bec9a8b..9f5bc88 100644
> --- gcc/config/avr/avr.c
> +++ gcc/config/avr/avr.c
> @@ -9069,6 +9069,8 @@ avr_eval_addr_attrib (rtx x)
>if (SYMBOL_REF_FLAGS (x) & SYMBOL_FLAG_IO)
> {
> attr = lookup_attribute ("io", DECL_ATTRIBUTES (decl));
> + if (!attr || !TREE_VALUE (attr))
> + attr = lookup_attribute ("io_low", DECL_ATTRIBUTES (decl));
> gcc_assert (attr);
> }
>if (!attr || !TREE_VALUE (attr))
> diff --git gcc/testsuite/gcc.target/avr/pr65210.c
> gcc/testsuite/gcc.target/avr/pr65210.c
> new file mode 100644
> index 000..1aed441
> --- /dev/null
> +++ gcc/testsuite/gcc.target/avr/pr65210.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +
> +/* This testcase exposes PR65210. Usage of the io_low attribute
> + causes assertion failure because code only looks for the io
> + attribute if SYMBOL_FLAG_IO is set. */
> +
> +volatile char q __attribute__((io_low,address(0x81)));
Re: [patch] libstdc++/65704 portable timed_mutex and recursive_timed_mutex
On 04/09/15 11:18 +0100, Jonathan Wakely wrote:
Tested powerpc64le-linux as normal, and again with #undef
_GTHREAD_USE_MUTEX_TIMEDLOCK to test the new code.
Argh, my testing with the 'undef didn't work because was
included after I had #undef'd it, so I wasn't testing the new code at
all, and it didn't even compile.
This fixes those silly errors, and is really tested now.
Committed to trunk.
commit 293051bb60d30d3da6af6324e13484dc250d8385
Author: Jonathan Wakely
Date: Fri Sep 4 17:06:23 2015 +0100
fix darwin bootstrap errors due to .
PR libstdc++/65704
* include/std/mutex (recursive_timed_mutex): Fix uses of _Can_lock.
diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
index 47141d9..38950b6 100644
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -368,9 +368,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Predicate type that tests whether the current thread can lock a mutex.
struct _Can_lock
{
- _Can_lock(const recursive_timed_mutex* __mx)
- : _M_mx(__mx), _M_caller(this_thread::get_id()) { }
-
// Returns true if the mutex is unlocked or is locked by _M_caller.
bool
operator()() const noexcept
@@ -391,7 +388,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void
lock()
{
- _Can_lock __can_lock{this};
+ auto __id = this_thread::get_id();
+ _Can_lock __can_lock{this, __id};
unique_lock __lk(_M_mut);
_M_cv.wait(__lk, __can_lock);
if (_M_count == -1u)
@@ -403,7 +401,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
try_lock()
{
- _Can_lock __can_lock{this};
+ auto __id = this_thread::get_id();
+ _Can_lock __can_lock{this, __id};
lock_guard __lk(_M_mut);
if (!__can_lock())
return false;
@@ -418,9 +417,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
try_lock_for(const chrono::duration<_Rep, _Period>& __rtime)
{
- _Can_lock __can_lock{this};
+ auto __id = this_thread::get_id();
+ _Can_lock __can_lock{this, __id};
unique_lock __lk(_M_mut);
- if (!_M_cv.wait_for(__lk, __rtime, __can_lock);
+ if (!_M_cv.wait_for(__lk, __rtime, __can_lock))
return false;
if (_M_count == -1u)
return false;
@@ -433,9 +433,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
try_lock_until(const chrono::time_point<_Clock, _Duration>& __atime)
{
- _Can_lock __can_lock{this};
+ auto __id = this_thread::get_id();
+ _Can_lock __can_lock{this, __id};
unique_lock __lk(_M_mut);
- if (!_M_cv.wait_until(__lk, __atime, __can_lock);
+ if (!_M_cv.wait_until(__lk, __atime, __can_lock))
return false;
if (_M_count == -1u)
return false;
[PATCH] -fopenmp-simd LTO ICE fix (PR middle-end/67452)
Hi!
This patch is a fix for gomp4.1 branch ICEs on
FAIL libgomp.c/for-5.c
FAIL libgomp.c++/for-13.C
that can be reproduced with intelmic emul offloading even on the trunk
with the attached testcase. The problem is that LTO streaming doesn't
really like earlier unreferenced VAR_DECLs to be streamed late during
output_function (from output_cfg).
The patch fixes it by clearing loop->simduid when optimizations removed
all IL uses of the var and remove_unused_locals is about to nuke it from
cfun->local_decls.
Ok for trunk/5.3 if it passes bootstrap/regtest?
2015-09-04 Jakub Jelinek
PR middle-end/67452
* tree-ssa-live.c: Include cfgloop.h.
(remove_unused_locals): Clear loop->simduid if simduid is about
to be removed from cfun->local_decls.
* gcc.dg/lto/pr67452_0.c: New test.
--- gcc/tree-ssa-live.c.jj 2015-08-24 18:27:19.738209359 +0200
+++ gcc/tree-ssa-live.c 2015-09-04 17:16:53.620321240 +0200
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.
#include "tree-ssa.h"
#include "cgraph.h"
#include "ipa-utils.h"
+#include "cfgloop.h"
#ifdef ENABLE_CHECKING
static void verify_live_on_entry (tree_live_info_p);
@@ -820,6 +821,14 @@ remove_unused_locals (void)
}
}
+ if (cfun->has_simduid_loops)
+{
+ struct loop *loop;
+ FOR_EACH_LOOP (loop, 0)
+ if (loop->simduid && !is_used_p (loop->simduid))
+ loop->simduid = NULL_TREE;
+}
+
cfun->has_local_explicit_reg_vars = false;
/* Remove unmarked local and global vars from local_decls. */
--- gcc/testsuite/gcc.dg/lto/pr67452_0.c.jj 2015-09-04 17:12:34.636045313
+0200
+++ gcc/testsuite/gcc.dg/lto/pr67452_0.c2015-09-04 17:13:18.473414952
+0200
@@ -0,0 +1,23 @@
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -O2 -flto -fopenmp-simd } } } */
+
+float b[3][3];
+
+__attribute__((used, noinline)) void
+foo ()
+{
+ int v1, v2;
+#pragma omp simd collapse(2)
+ for (v1 = 0; v1 < 3; v1++)
+for (v2 = 0; v2 < 3; v2++)
+ b[v1][v2] = 2.5;
+}
+
+int
+main ()
+{
+ asm volatile ("" : : "g" (b) : "memory");
+ foo ();
+ asm volatile ("" : : "g" (b) : "memory");
+ return 0;
+}
Jakub
[PATCH] [MIPS] Fix wrong instruction in the delay slot
Hi,
The attached test case that uses __builtin_unreachable in the default case
in a switch statement triggers a situation where a wrong instruction is placed
in the delay slot by the eager delay slot filler.
The issue should be reproducible with ToT compiler with -mips32r2 -G0
-mno-abicalls -O2.
It appears that a possibly related issue is already reported to Bugzilla (bug
51513)
where the branch is not optimized away, leaving the compare and branch
instructions.
It would also appear that this should be fixed at the tree level, however,
handling
a special case when a branch is generated, pointing to 'nowhere' block, is
probably
more suitable.
Without the fix, the generated assembly is following:
...
addiu $2,$3,-3
sltu$4,$2,33
.setnoreorder
.setnomacro
beq $4,$0,$L22
lw $4,%lo(mips_cm_is64)($4)
.setmacro
.setreorder
sll $4,$2,2
...
The load instruction should not be placed in the delay slot as it is a part of
the taken branch with an undefined behaviour. The 'sll' was expected to be in
the slot.
This is a series of unfortunate events that causes this to happen:
1. After the expansion, the 'nowhere' block is placed after the switch
statement and
behaves as a fallthrough case with a diamond shape.
2. The block reordering pass randomly rearranges the nowhere block and it
happens to be
placed before the load instruction.
3. The eager delay slot filler firstly redirects jumps by skipping consecutive
labels
(ignoring barriers), pointing directly to the load. The analysis is doomed
to failure at this
stage as the own thread is analysed and the shift instruction is rejected as
it uses
conflicting resources (most likely because $4 is referenced in the load) but
the opposite
thread succeeds partly because the set and needed registers sets do not
intersect when
the resources are being computed by mark_target_live_regs ().
IMO, the fix is to recognize the empty basic block that has a code_label
followed by
a barrier (ignoring notes and debug_insns), forbid going beyond the barrier if
the empty block
is found in skip_consecutive_labels () and first_active_target_insn ().
The patch was cross tested on mips-img-linux-gnu and sparc-linux-gnu.
Regards,
Robert
gcc/
* reorg.c (label_with_barrier_p): New function.
(skip_consecutive_labels): Use it. Don't skip the label if an empty
block is found.
(first_active_target_insn): Likewise. Don't ignore the empty
block when searching for the next active instruction.
gcc/testsuite
* gcc.target/mips/builtin-unreachable-bug-1.c: New test.
---
gcc/reorg.c| 28 +++
.../gcc.target/mips/builtin-unreachable-bug-1.c| 90 ++
2 files changed, 118 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/mips/builtin-unreachable-bug-1.c
diff --git a/gcc/reorg.c b/gcc/reorg.c
index cdaa60c..269f666 100644
--- a/gcc/reorg.c
+++ b/gcc/reorg.c
@@ -145,6 +145,30 @@ along with GCC; see the file COPYING3. If not see
These functions are now only used here in reorg.c, and have therefore
been moved here to avoid inadvertent misuse elsewhere in the compiler. */
+/* Return true iff a LABEL is followed by a BARRIER. Ignore notes and debug
+ instructions. */
+
+static bool
+label_with_barrier_p (rtx_insn *label)
+{
+ bool empty_bb = true;
+
+ if (GET_CODE (label) != CODE_LABEL)
+empty_bb = false;
+ else
+label = NEXT_INSN (label);
+
+ while (!BARRIER_P (label) && empty_bb)
+ {
+if (!(DEBUG_INSN_P (label)
+ || NOTE_P (label)))
+ empty_bb = false;
+label = NEXT_INSN (label);
+ }
+
+ return empty_bb;
+}
+
/* Return the last label to mark the same position as LABEL. Return LABEL
itself if it is null or any return rtx. */
@@ -159,6 +183,8 @@ skip_consecutive_labels (rtx label_or_return)
rtx_insn *label = as_a (label_or_return);
for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn))
+if (LABEL_P (insn) && label_with_barrier_p (insn))
+ break;
if (LABEL_P (insn))
label = insn;
@@ -267,6 +293,8 @@ first_active_target_insn (rtx insn)
{
if (ANY_RETURN_P (insn))
return insn;
+ if (LABEL_P (insn) && label_with_barrier_p (as_a (insn)))
+return NULL_RTX;
return next_active_insn (as_a (insn));
}
diff --git a/gcc/testsuite/gcc.target/mips/builtin-unreachable-bug-1.c
b/gcc/testsuite/gcc.target/mips/builtin-unreachable-bug-1.c
new file mode 100644
index 000..65eb9a3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/builtin-unreachable-bug-1.c
@@ -0,0 +1,90 @@
+/* { dg-options "-mcompact-branches=never -G0 -mno-abicalls" } */
+/* { dg-final { scan-assembler-not
"beq\t\\\$4,\\\$0,\\\$L\[0-9\]+\n
[PATCH] Minor cleanup of const_and_copies stack
I've been meaning to push this for a while. Primarily it removes two
set but never used private fields from the class and simplifies the
constructor in the obvious way. It also fixes a couple minor formatting
glitches, adds some missing comments, etc. It's ultimately related to
getting the threader in shape to handle BZ47679.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. FWIW,
am I the only one having trouble with libgfortran not finding
backtrace-supported.h during the stage3 build? It's quite annoying.
I'm hacking around locally right now.
Installed on the trunk.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a3d8e60..a6f9f8f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,18 @@
+2015-09-04 Jeff Law
+
+ * tree-ssa-scopedtables.c (const_and_copies::const_and_copies): Remove
+ unnecessary constructor. It's now trivial and implemented inside...
+ * tree-ssa-scopedtables.h (const_and_copies): Implement trivial
+ constructor. Add comments to various methods. Remove unused
+ private fields.
+ * tree-ssa-dom.c (pass_dominator::execute): Corresponding changes.
+ * tree-vrp.c (identify_jump_threads): Likewise.
+ * tree-ssa-threadedge.c (thread_through_normal_block): Fix minor
+ indentation issues.
+ (thread_across_edge): Similarly.
+ (record_temporary_equivalences_from_stmts_at_dest): Remove unused
+ arguments in constructor call.
+
2015-09-04 Jonas Hahnfeld
* config/i386/intelmic-mkoffload.c (prepare_target_image): Fix if the
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index a26ae55..f0b19ff 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1168,7 +1168,7 @@ pass_dominator::execute (function *fun)
/* Create our hash tables. */
avail_exprs = new hash_table (1024);
avail_exprs_stack.create (20);
- const_and_copies = new class const_and_copies (dump_file, dump_flags);
+ const_and_copies = new class const_and_copies ();
need_eh_cleanup = BITMAP_ALLOC (NULL);
need_noreturn_fixup.create (0);
diff --git a/gcc/tree-ssa-scopedtables.c b/gcc/tree-ssa-scopedtables.c
index 41bf887..1fea69a 100644
--- a/gcc/tree-ssa-scopedtables.c
+++ b/gcc/tree-ssa-scopedtables.c
@@ -28,13 +28,6 @@ along with GCC; see the file COPYING3. If not see
#include "tree-ssa-scopedtables.h"
#include "tree-ssa-threadedge.h"
-const_and_copies::const_and_copies (FILE *file, int flags)
-{
- stack.create (20);
- dump_file = file;
- dump_flags = flags;
-}
-
/* Pop entries off the stack until we hit the NULL marker.
For each entry popped, use the SRC/DEST pair to restore
SRC to its prior value. */
diff --git a/gcc/tree-ssa-scopedtables.h b/gcc/tree-ssa-scopedtables.h
index bc30ee6..564c24d 100644
--- a/gcc/tree-ssa-scopedtables.h
+++ b/gcc/tree-ssa-scopedtables.h
@@ -23,18 +23,31 @@ along with GCC; see the file COPYING3. If not see
class const_and_copies
{
public:
- const_and_copies (FILE *, int);
+ const_and_copies (void) { stack.create (20); };
~const_and_copies (void) { stack.release (); }
+
+ /* Push the unwinding marker onto the stack. */
void push_marker (void) { stack.safe_push (NULL_TREE); }
+
+ /* Restore the const/copies table to its state whe the last marker
+ was pushed. */
void pop_to_marker (void);
+
+ /* Record a single const/copy pair that can be unwound. */
void record_const_or_copy (tree, tree);
+
+ /* Special entry point when we want to provide an explicit previous
+ value for the first argument. Try to get rid of this in the future. */
void record_const_or_copy (tree, tree, tree);
+
+ /* When threading we need to invalidate certain equivalences after
+ following a loop backedge. The entries we need to invalidate will
+ always be in this unwindable stack. This entry point handles
+ finding and invalidating those entries. */
void invalidate (tree);
private:
vec stack;
- FILE *dump_file;
- int dump_flags;
};
#endif /* GCC_TREE_SSA_SCOPED_TABLES_H */
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 451dc2e..0ad2483 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -432,7 +432,8 @@ record_temporary_equivalences_from_stmts_at_dest (edge e,
if (cached_lhs
&& (TREE_CODE (cached_lhs) == SSA_NAME
|| is_gimple_min_invariant (cached_lhs)))
- const_and_copies->record_const_or_copy (gimple_get_lhs (stmt),
cached_lhs);
+ const_and_copies->record_const_or_copy (gimple_get_lhs (stmt),
+ cached_lhs);
else if (backedge_seen)
const_and_copies->invalidate (gimple_get_lhs (stmt));
}
@@ -1208,7 +1209,8 @@ thread_through_normal_block (edge e,
/* Now walk each statement recording any context sensitive
temporary equivalences we can detect. */
gimple stmt
-= record_temporary_equivalences_from_stmts_at_dest (e, const_and_copi
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 7:59 AM, Christophe Lyon
wrote:
> On 4 September 2015 at 16:54, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 7:52 AM, Christophe Lyon
>> wrote:
>>> On 4 September 2015 at 15:58, H.J. Lu wrote:
On Fri, Sep 4, 2015 at 6:15 AM, Christophe Lyon
wrote:
> On 4 September 2015 at 14:13, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
> wrote:
>> On 3 September 2015 at 13:31, H.J. Lu wrote:
>>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>>> wrote:
On 1 September 2015 at 16:04, Christophe Lyon
wrote:
> On 25 August 2015 at 17:31, Mike Stump
> wrote:
>> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
>> wrote:
>>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>>> TEST_ALWAYS_FLAGS and perform effective_target support tests
>>> using
>>> these modified flags.
>>
>>> This patch adds a new function 'clear_effective_target_cache',
>>> which
>>> is called at the end of every .exp file which overrides
>>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>>
>> So, a simple English directive somewhere that says, if one
>> changes ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do
>> a clear_effective_target_cache at the end as the target cache
>> can make decisions based upon the flags, and those decisions
>> need to be redone when the flags change would be nice.
>>
>> I do wonder, do we need to reexamine when setting the flags?
>> I’m thinking of a sequence like: non-thumb default, is_thumb,
>> set flags (thumb), is_thumb. Anyway, safe to punt this until
>> someone discovers it or is reasonable sure it happens.
>>
>> Anyway, all looks good. Ok.
>>
> Here is what I have committed (r227372).
Hmmm, in fact this was r227401.
>>>
>>> It caused:
>>>
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element
>>> in array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element
>>> in array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element
>>> in array
>>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such
>>> element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(label_values,value)": no such element
>>> in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
>>> array
>>> ...
>>>
>>> on Linux/x86-64:
>>>
>>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>>
>>
>> I'll have a look.
>> That's the configuration I used to check before committing, but I am
>> going to re-check.
>
> proc check_cached_effective_target { prop args } {
> global et_cache
> global et_prop_list
>
> set target [current_target_name]
> if {![info exists et_cache($prop,target)]
> || $et_cache($prop,target) != $target} {
> verbose "check_cached_effective_target $prop: checking
> $target" 2
> set et_cache($prop,target) $target
> set et_cache($prop,value) [uplevel eval $args]
> lappend et_prop_list $prop
> ^^
Re: [testsuite] Clean up effective_target cache
On 4 September 2015 at 16:54, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 7:52 AM, Christophe Lyon
> wrote:
>> On 4 September 2015 at 15:58, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 6:15 AM, Christophe Lyon
>>> wrote:
On 4 September 2015 at 14:13, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
wrote:
> On 3 September 2015 at 13:31, H.J. Lu wrote:
>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>> wrote:
>>> On 1 September 2015 at 16:04, Christophe Lyon
>>> wrote:
On 25 August 2015 at 17:31, Mike Stump
wrote:
> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
> wrote:
>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>> TEST_ALWAYS_FLAGS and perform effective_target support tests
>> using
>> these modified flags.
>
>> This patch adds a new function 'clear_effective_target_cache',
>> which
>> is called at the end of every .exp file which overrides
>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>
> So, a simple English directive somewhere that says, if one
> changes ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do
> a clear_effective_target_cache at the end as the target cache can
> make decisions based upon the flags, and those decisions need to
> be redone when the flags change would be nice.
>
> I do wonder, do we need to reexamine when setting the flags? I’m
> thinking of a sequence like: non-thumb default, is_thumb, set
> flags (thumb), is_thumb. Anyway, safe to punt this until someone
> discovers it or is reasonable sure it happens.
>
> Anyway, all looks good. Ok.
>
Here is what I have committed (r227372).
>>>
>>> Hmmm, in fact this was r227401.
>>>
>>
>> It caused:
>>
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such
>> element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(label_values,value)": no such element
>> in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
>> array
>> ...
>>
>> on Linux/x86-64:
>>
>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>
>
> I'll have a look.
> That's the configuration I used to check before committing, but I am
> going to re-check.
proc check_cached_effective_target { prop args } {
global et_cache
global et_prop_list
set target [current_target_name]
if {![info exists et_cache($prop,target)]
|| $et_cache($prop,target) != $target} {
verbose "check_cached_effective_target $prop: checking
$target" 2
set et_cache($prop,target) $target
set et_cache($prop,value) [uplevel eval $args]
lappend et_prop_list $prop
Aren't you appending $pop to et_prop_list even if it may be already
on the list?
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 7:52 AM, Christophe Lyon
wrote:
> On 4 September 2015 at 15:58, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 6:15 AM, Christophe Lyon
>> wrote:
>>> On 4 September 2015 at 14:13, H.J. Lu wrote:
On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
>>> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
>>> wrote:
On 3 September 2015 at 13:31, H.J. Lu wrote:
> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
> wrote:
>> On 1 September 2015 at 16:04, Christophe Lyon
>> wrote:
>>> On 25 August 2015 at 17:31, Mike Stump
>>> wrote:
On Aug 25, 2015, at 1:14 AM, Christophe Lyon
wrote:
> Some subsets of the tests override ALWAYS_CXXFLAGS or
> TEST_ALWAYS_FLAGS and perform effective_target support tests using
> these modified flags.
> This patch adds a new function 'clear_effective_target_cache',
> which
> is called at the end of every .exp file which overrides
> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
So, a simple English directive somewhere that says, if one changes
ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
clear_effective_target_cache at the end as the target cache can
make decisions based upon the flags, and those decisions need to
be redone when the flags change would be nice.
I do wonder, do we need to reexamine when setting the flags? I’m
thinking of a sequence like: non-thumb default, is_thumb, set
flags (thumb), is_thumb. Anyway, safe to punt this until someone
discovers it or is reasonable sure it happens.
Anyway, all looks good. Ok.
>>> Here is what I have committed (r227372).
>>
>> Hmmm, in fact this was r227401.
>>
>
> It caused:
>
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
> array
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
> array
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
> array
> ERROR: can't unset "et_cache(dfp,value)": no such element in array
> ERROR: can't unset "et_cache(fsanitize_address,value)": no such
> element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(label_values,value)": no such element in
> array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
> array
> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
> array
> ...
>
> on Linux/x86-64:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>
I'll have a look.
That's the configuration I used to check before committing, but I am
going to re-check.
>>>
>>> proc check_cached_effective_target { prop args } {
>>> global et_cache
>>> global et_prop_list
>>>
>>> set target [current_target_name]
>>> if {![info exists et_cache($prop,target)]
>>> || $et_cache($prop,target) != $target} {
>>> verbose "check_cached_effective_target $prop: checking $target"
>>> 2
>>> set et_cache($prop,target) $target
>>> set et_cache($prop,value) [uplevel eval $args]
>>> lappend et_prop_list $prop
>>>
>>>
>>> Aren't you appending $pop to et_prop_list even if it may be already
>>> on the list?
>>>
>>> verbose "check_cached_effective_target cached list is now:
>>> $et_prop_list" 2
>>> }
>>> set value $et_cache($prop,value)
>>>
Re: [testsuite] Clean up effective_target cache
On 4 September 2015 at 15:58, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 6:15 AM, Christophe Lyon
> wrote:
>> On 4 September 2015 at 14:13, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
>> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
>> wrote:
>>> On 3 September 2015 at 13:31, H.J. Lu wrote:
On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
wrote:
> On 1 September 2015 at 16:04, Christophe Lyon
> wrote:
>> On 25 August 2015 at 17:31, Mike Stump wrote:
>>> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
>>> wrote:
Some subsets of the tests override ALWAYS_CXXFLAGS or
TEST_ALWAYS_FLAGS and perform effective_target support tests using
these modified flags.
>>>
This patch adds a new function 'clear_effective_target_cache',
which
is called at the end of every .exp file which overrides
ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>>>
>>> So, a simple English directive somewhere that says, if one changes
>>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
>>> clear_effective_target_cache at the end as the target cache can
>>> make decisions based upon the flags, and those decisions need to be
>>> redone when the flags change would be nice.
>>>
>>> I do wonder, do we need to reexamine when setting the flags? I’m
>>> thinking of a sequence like: non-thumb default, is_thumb, set flags
>>> (thumb), is_thumb. Anyway, safe to punt this until someone
>>> discovers it or is reasonable sure it happens.
>>>
>>> Anyway, all looks good. Ok.
>>>
>> Here is what I have committed (r227372).
>
> Hmmm, in fact this was r227401.
>
It caused:
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
array
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
array
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
array
ERROR: can't unset "et_cache(dfp,value)": no such element in array
ERROR: can't unset "et_cache(fsanitize_address,value)": no such
element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(label_values,value)": no such element in
array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
array
ERROR: can't unset "et_cache(ptr32plus,value)": no such element in
array
...
on Linux/x86-64:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>>
>>> I'll have a look.
>>> That's the configuration I used to check before committing, but I am
>>> going to re-check.
>>
>> proc check_cached_effective_target { prop args } {
>> global et_cache
>> global et_prop_list
>>
>> set target [current_target_name]
>> if {![info exists et_cache($prop,target)]
>> || $et_cache($prop,target) != $target} {
>> verbose "check_cached_effective_target $prop: checking $target" 2
>> set et_cache($prop,target) $target
>> set et_cache($prop,value) [uplevel eval $args]
>> lappend et_prop_list $prop
>>
>>
>> Aren't you appending $pop to et_prop_list even if it may be already
>> on the list?
>>
>> verbose "check_cached_effective_target cached list is now:
>> $et_prop_list" 2
>> }
>> set value $et_cache($prop,value)
>> verbose "check_cached_effective_target $prop: returning $value for
>> $target" 2
>> return $value
>> }
>>
>
> Like this?
>
> --
> H.J.
>
Re: [PATCH] PR bootstrap/67385: READELF_FOR_TARGET isn't used in gcc configure
On Fri, Aug 28, 2015 at 8:50 AM, H.J. Lu wrote:
> Similar to as, ld, nm and objdump, gcc configure should check
> $READELF_FOR_TARGET for readelf.
>
> OK for trunk?
>
> H.J.
> ---
> PR bootstrap/67385
> * configure.ac (gcc_cv_readelf): Check $READELF_FOR_TARGET.
> * configure: Regenerated.
> ---
> gcc/configure| 6 --
> gcc/configure.ac | 4 +++-
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/configure b/gcc/configure
> index 0d31383..4d16140 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -22232,9 +22232,11 @@ if test -f $gcc_cv_binutils_srcdir/configure.ac \
> gcc_cv_readelf=../binutils/readelf$build_exeext
> elif test -x readelf$build_exeext; then
> gcc_cv_readelf=./readelf$build_exeext
> +elif ( set dummy $READELF_FOR_TARGET; test -x $2 ); then
> +gcc_cv_readelf="$READELF_FOR_TARGET"
> else
> -# Extract the first word of "readelf", so it can be a program name
> with args.
> -set dummy readelf; ac_word=$2
> +# Extract the first word of "$READELF_FOR_TARGET", so it can be a
> program name with args.
> +set dummy $READELF_FOR_TARGET; ac_word=$2
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> $as_echo_n "checking for $ac_word... " >&6; }
> if test "${ac_cv_path_gcc_cv_readelf+set}" = set; then :
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 846651d..81aba21 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -2367,8 +2367,10 @@ if test -f $gcc_cv_binutils_srcdir/configure.ac \
> gcc_cv_readelf=../binutils/readelf$build_exeext
> elif test -x readelf$build_exeext; then
> gcc_cv_readelf=./readelf$build_exeext
> +elif ( set dummy $READELF_FOR_TARGET; test -x $[2] ); then
> +gcc_cv_readelf="$READELF_FOR_TARGET"
> else
> -AC_PATH_PROG(gcc_cv_readelf, readelf)
> +AC_PATH_PROG(gcc_cv_readelf, $READELF_FOR_TARGET)
> fi])
>
> AC_MSG_CHECKING(what readelf to use)
> --
> 2.4.3
>
Any comments, objections, feedbacks?
--
H.J.
[PATCH] Don't ICE on invalid asm memory input (PR inline-asm/67448)
In this PR, we were crashing on an invalid asm. I think let's just reject
MODIFY_EXPRs as memory inputs - I'll wager those aren't meant to be supported
anyway.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-09-04 Marek Polacek
PR inline-asm/67448
* gimplify.c (gimplify_asm_expr): Don't allow MODIFY_EXPR as
a memory input.
* gcc.dg/asm-10.c: New test.
diff --git gcc/gimplify.c gcc/gimplify.c
index c8f2718..b7a918b 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -5210,7 +5210,8 @@ gimplify_asm_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p)
if (TREE_CODE (inputv) == PREDECREMENT_EXPR
|| TREE_CODE (inputv) == PREINCREMENT_EXPR
|| TREE_CODE (inputv) == POSTDECREMENT_EXPR
- || TREE_CODE (inputv) == POSTINCREMENT_EXPR)
+ || TREE_CODE (inputv) == POSTINCREMENT_EXPR
+ || TREE_CODE (inputv) == MODIFY_EXPR)
TREE_VALUE (link) = error_mark_node;
tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
is_gimple_lvalue, fb_lvalue | fb_mayfail);
diff --git gcc/testsuite/gcc.dg/asm-10.c gcc/testsuite/gcc.dg/asm-10.c
index e69de29..e6c03c6 100644
--- gcc/testsuite/gcc.dg/asm-10.c
+++ gcc/testsuite/gcc.dg/asm-10.c
@@ -0,0 +1,12 @@
+/* PR inline-asm/67448 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+f (int i)
+{
+ asm ("" : : "m"(i += 1)); /* { dg-error "not directly addressable" } */
+ asm ("" : : "m"(i++)); /* { dg-error "not directly addressable" } */
+ asm ("" : : "m"(++i)); /* { dg-error "not directly addressable" } */
+ asm ("" : : "m"(i = 0)); /* { dg-error "not directly addressable" } */
+}
Marek
RE: [PATCH] Disable -mbranch-likely for -Os when targetting generic architecture
Hi,
> Richard Sandiford writes:
> > Robert Suchanek writes:
> > > The patch below disables generation of the branch likely instructions for
> > > -
> Os
> > > but only for generic architecture. The branch likely may result in some
> > > code size reduction but the cost of running the code on R6 core is
> significant.
> >
> > How about instead splitting PTF_AVOID_BRANCHLIKELY into
> > PTF_AVOID_BRANCHLIKELY_SPEED and PTF_AVOID_BRANCHLIKELY_SIZE?
> > We could have PTF_AVOID_BRANCHLIKELY_ALWAYS as an OR of the two.
>
> This sounds OK and is nicer.
>
> > Anything that does string ops on the architecture is suspicious :-)
>
> You can blame me for this. I advocated the string comparison approach as I
> had
> to
> do the same thing in gas IIRC for some feature and couldn't think of anything
> better to suggest.
Here is an updated version that use the suggested method. Ok to apply?
Regards,
Robert
gcc/
* config/mips/mips-cpus.def: Replace PTF_AVOID_BRANCHLIKELY with
PTF_AVOID_BRANCHLIKELY_ALWAYS for generic architecture and with
PTF_AVOID_BRANCHLIKELY_SPEED for others.
(mips2, mips3, mips4): Add PTF_AVOID_BRANCHLIKELY_SIZE to tune flags.
* config/mips/mips.c (mips_option_override): Enable the branch likely
depending on the tune flags and optimization level.
* config/mips/mips.h (PTF_AVOID_BRANCHLIKELY): Remove.
(PTF_AVOID_BRANCHLIKELY_SPEED): Define.
(PTF_AVOID_BRANCHLIKELY_SIZE): Likewise.
(PTF_AVOID_BRANCHLIKELY_ALWAYS): Likewise.
---
gcc/config/mips/mips-cpus.def | 56 +--
gcc/config/mips/mips.c| 6 +++--
gcc/config/mips/mips.h| 20
3 files changed, 47 insertions(+), 35 deletions(-)
diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def
index e0c77f8..52f9900 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -34,28 +34,28 @@ along with GCC; see the file COPYING3. If not see
/* Entries for generic ISAs. */
MIPS_CPU ("mips1", PROCESSOR_R3000, 1, 0)
-MIPS_CPU ("mips2", PROCESSOR_R6000, 2, 0)
-MIPS_CPU ("mips3", PROCESSOR_R4000, 3, 0)
-MIPS_CPU ("mips4", PROCESSOR_R1, 4, 0)
+MIPS_CPU ("mips2", PROCESSOR_R6000, 2, PTF_AVOID_BRANCHLIKELY_SIZE)
+MIPS_CPU ("mips3", PROCESSOR_R4000, 3, PTF_AVOID_BRANCHLIKELY_SIZE)
+MIPS_CPU ("mips4", PROCESSOR_R1, 4, PTF_AVOID_BRANCHLIKELY_SIZE)
/* Prefer not to use branch-likely instructions for generic MIPS32rX
and MIPS64rX code. The instructions were officially deprecated
in revisions 2 and earlier, but revision 3 is likely to downgrade
that to a recommendation to avoid the instructions in code that
isn't tuned to a specific processor. */
-MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY_ALWAYS)
/* mips32r3 is micromips hense why it uses the M4K processor.
mips32r5 should use the p5600 processor, but there is no definition
for this yet, so in the short term we will use the same processor entry
as mips32r2. */
-MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("mips32r5", PROCESSOR_P5600, 36, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r5", PROCESSOR_P5600, 36, PTF_AVOID_BRANCHLIKELY_ALWAYS)
MIPS_CPU ("mips32r6", PROCESSOR_I6400, 37, 0)
-MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY_ALWAYS)
/* ??? For now just tune the generic MIPS64r2 and above for 5KC as well. */
-MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("mips64r3", PROCESSOR_5KC, 66, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("mips64r5", PROCESSOR_5KC, 68, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips64r3", PROCESSOR_5KC, 66, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips64r5", PROCESSOR_5KC, 68, PTF_AVOID_BRANCHLIKELY_ALWAYS)
MIPS_CPU ("mips64r6", PROCESSOR_I6400, 69, 0)
/* MIPS I processors. */
@@ -80,8 +80,8 @@ MIPS_CPU ("r4650", PROCESSOR_R4650, 3, 0)
MIPS_CPU ("r4700", PROCESSOR_R4700, 3, 0)
MIPS_CPU ("r5900", PROCESSOR_R5900, 3, 0)
/* ST Loongson 2E/2F processors. */
-MIPS_CPU ("loongson2e", PROCESSOR_LOONGSON_2E, 3, PTF_AVOID_BRANCHLIKELY)
-MIPS_CPU ("loongson2f", PROCESSOR_LOONGSON_2F, 3, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("loongson2e", PROCESSOR_LOONGSON_2E, 3, PTF_AVOID_BRANCHLIKELY_SPEED)
+MIPS_CPU ("loongson2f", PROCESSOR_LOONGSON_2F, 3, PTF_AVOID_BRANCHLIKELY_SPEED)
/* MIPS IV processors. */
MIPS_CPU ("r8000", PROCESSOR_R8000, 4, 0)
@@ -91,7 +91,7 @@ MIPS_CPU ("r14000", PROCESSOR_R1, 4, 0)
MIPS_CPU ("r16000", PROCESSOR_R1, 4, 0)
MIPS_CPU ("
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 6:15 AM, Christophe Lyon
wrote:
> On 4 September 2015 at 14:13, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
> wrote:
>> On 3 September 2015 at 13:31, H.J. Lu wrote:
>>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>>> wrote:
On 1 September 2015 at 16:04, Christophe Lyon
wrote:
> On 25 August 2015 at 17:31, Mike Stump wrote:
>> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
>> wrote:
>>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>>> TEST_ALWAYS_FLAGS and perform effective_target support tests using
>>> these modified flags.
>>
>>> This patch adds a new function 'clear_effective_target_cache', which
>>> is called at the end of every .exp file which overrides
>>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>>
>> So, a simple English directive somewhere that says, if one changes
>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
>> clear_effective_target_cache at the end as the target cache can make
>> decisions based upon the flags, and those decisions need to be
>> redone when the flags change would be nice.
>>
>> I do wonder, do we need to reexamine when setting the flags? I’m
>> thinking of a sequence like: non-thumb default, is_thumb, set flags
>> (thumb), is_thumb. Anyway, safe to punt this until someone
>> discovers it or is reasonable sure it happens.
>>
>> Anyway, all looks good. Ok.
>>
> Here is what I have committed (r227372).
Hmmm, in fact this was r227401.
>>>
>>> It caused:
>>>
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such element
>>> in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(label_values,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>>> ...
>>>
>>> on Linux/x86-64:
>>>
>>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>>
>>
>> I'll have a look.
>> That's the configuration I used to check before committing, but I am
>> going to re-check.
>
> proc check_cached_effective_target { prop args } {
> global et_cache
> global et_prop_list
>
> set target [current_target_name]
> if {![info exists et_cache($prop,target)]
> || $et_cache($prop,target) != $target} {
> verbose "check_cached_effective_target $prop: checking $target" 2
> set et_cache($prop,target) $target
> set et_cache($prop,value) [uplevel eval $args]
> lappend et_prop_list $prop
>
>
> Aren't you appending $pop to et_prop_list even if it may be already
> on the list?
>
> verbose "check_cached_effective_target cached list is now:
> $et_prop_list" 2
> }
> set value $et_cache($prop,value)
> verbose "check_cached_effective_target $prop: returning $value for
> $target" 2
> return $value
> }
>
Like this?
--
H.J.
---
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index aad45f9..a6c16fe 100644
--- a/gcc/testsuite/lib/target-supports.exp
>>>
Re: [C++ PATCH] Set C++ standard earlier
OK. Jason
Re: [testsuite] Clean up effective_target cache
On 4 September 2015 at 14:13, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
>>> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
wrote:
> On 3 September 2015 at 13:31, H.J. Lu wrote:
>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>> wrote:
>>> On 1 September 2015 at 16:04, Christophe Lyon
>>> wrote:
On 25 August 2015 at 17:31, Mike Stump wrote:
> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
> wrote:
>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>> TEST_ALWAYS_FLAGS and perform effective_target support tests using
>> these modified flags.
>
>> This patch adds a new function 'clear_effective_target_cache', which
>> is called at the end of every .exp file which overrides
>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>
> So, a simple English directive somewhere that says, if one changes
> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
> clear_effective_target_cache at the end as the target cache can make
> decisions based upon the flags, and those decisions need to be redone
> when the flags change would be nice.
>
> I do wonder, do we need to reexamine when setting the flags? I’m
> thinking of a sequence like: non-thumb default, is_thumb, set flags
> (thumb), is_thumb. Anyway, safe to punt this until someone discovers
> it or is reasonable sure it happens.
>
> Anyway, all looks good. Ok.
>
Here is what I have committed (r227372).
>>>
>>> Hmmm, in fact this was r227401.
>>>
>>
>> It caused:
>>
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such element
>> in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(label_values,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>> ...
>>
>> on Linux/x86-64:
>>
>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>
>
> I'll have a look.
> That's the configuration I used to check before committing, but I am
> going to re-check.
proc check_cached_effective_target { prop args } {
global et_cache
global et_prop_list
set target [current_target_name]
if {![info exists et_cache($prop,target)]
|| $et_cache($prop,target) != $target} {
verbose "check_cached_effective_target $prop: checking $target" 2
set et_cache($prop,target) $target
set et_cache($prop,value) [uplevel eval $args]
lappend et_prop_list $prop
Aren't you appending $pop to et_prop_list even if it may be already
on the list?
verbose "check_cached_effective_target cached list is now:
$et_prop_list" 2
}
set value $et_cache($prop,value)
verbose "check_cached_effective_target $prop: returning $value for
$target" 2
return $value
}
>>>
>>> Like this?
>>>
>>> --
>>> H.J.
>>> ---
>>> diff --git a/gcc/testsuite/lib/target-supports.exp
>>> b/gcc/testsuite/lib/target-supports.exp
>>> index aad45f9..a6c16fe 100644
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -125,7 +125,9 @@ proc check_cached_effective_target { prop args } {
>>> verbose "check_cached_effective_target $prop
Re: [ubsan PATCH] Don't instrument static initializers (PR sanitizer/67279)
On Fri, Sep 04, 2015 at 01:31:09PM +0200, Jakub Jelinek wrote: > On Fri, Sep 04, 2015 at 01:28:38PM +0200, Marek Polacek wrote: > > I think it really doesn't make sense to instrument static initializers; we > > wouldn't be able to error at run-time anyway. Besides, it causes a > > compile-time > > error. Generally, I think *compiling* with -fsanitize=undefined shouldn't > > add > > any new compile-time errors. Yes, I know it does in some other cases; this > > is > > just an incremental improvement. > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > 2015-09-04 Marek Polacek > > > > PR sanitizer/67279 > > * c-typeck.c (build_binary_op): Don't instrument static initializers. > > > > * gcc.dg/ubsan/pr67279.c: New test. > > Ok, but please make sure it is handled similarly in the C++ FE too (perhaps > incrementally). cc1plus doesn't reject this particular testcase, so I didn't touch the C++ FE this time. Thanks. Marek
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 4:47 AM, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
>> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
>>> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
>>> wrote:
On 3 September 2015 at 13:31, H.J. Lu wrote:
> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
> wrote:
>> On 1 September 2015 at 16:04, Christophe Lyon
>> wrote:
>>> On 25 August 2015 at 17:31, Mike Stump wrote:
On Aug 25, 2015, at 1:14 AM, Christophe Lyon
wrote:
> Some subsets of the tests override ALWAYS_CXXFLAGS or
> TEST_ALWAYS_FLAGS and perform effective_target support tests using
> these modified flags.
> This patch adds a new function 'clear_effective_target_cache', which
> is called at the end of every .exp file which overrides
> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
So, a simple English directive somewhere that says, if one changes
ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
clear_effective_target_cache at the end as the target cache can make
decisions based upon the flags, and those decisions need to be redone
when the flags change would be nice.
I do wonder, do we need to reexamine when setting the flags? I’m
thinking of a sequence like: non-thumb default, is_thumb, set flags
(thumb), is_thumb. Anyway, safe to punt this until someone discovers
it or is reasonable sure it happens.
Anyway, all looks good. Ok.
>>> Here is what I have committed (r227372).
>>
>> Hmmm, in fact this was r227401.
>>
>
> It caused:
>
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
> ERROR: can't unset "et_cache(dfp,value)": no such element in array
> ERROR: can't unset "et_cache(fsanitize_address,value)": no such element
> in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ia32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
> ERROR: can't unset "et_cache(label_values,value)": no such element in
> array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(lp64,value)": no such element in array
> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
> ...
>
> on Linux/x86-64:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>
I'll have a look.
That's the configuration I used to check before committing, but I am
going to re-check.
>>>
>>> proc check_cached_effective_target { prop args } {
>>> global et_cache
>>> global et_prop_list
>>>
>>> set target [current_target_name]
>>> if {![info exists et_cache($prop,target)]
>>> || $et_cache($prop,target) != $target} {
>>> verbose "check_cached_effective_target $prop: checking $target" 2
>>> set et_cache($prop,target) $target
>>> set et_cache($prop,value) [uplevel eval $args]
>>> lappend et_prop_list $prop
>>>
>>>
>>> Aren't you appending $pop to et_prop_list even if it may be already
>>> on the list?
>>>
>>> verbose "check_cached_effective_target cached list is now:
>>> $et_prop_list" 2
>>> }
>>> set value $et_cache($prop,value)
>>> verbose "check_cached_effective_target $prop: returning $value for
>>> $target" 2
>>> return $value
>>> }
>>>
>>
>> Like this?
>>
>> --
>> H.J.
>> ---
>> diff --git a/gcc/testsuite/lib/target-supports.exp
>> b/gcc/testsuite/lib/target-supports.exp
>> index aad45f9..a6c16fe 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -125,7 +125,9 @@ proc check_cached_effective_target { prop args } {
>> verbose "check_cached_effective_target $prop: checking $target" 2
>> set et_cache($prop,target) $target
>> set et_cache($prop,value) [uplevel eval $args]
>> - lappend et_prop_list $prop
>> + if {[lsearch $et_prop_list $prop
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 4:27 AM, H.J. Lu wrote:
> On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
>> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
>> wrote:
>>> On 3 September 2015 at 13:31, H.J. Lu wrote:
On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
wrote:
> On 1 September 2015 at 16:04, Christophe Lyon
> wrote:
>> On 25 August 2015 at 17:31, Mike Stump wrote:
>>> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
>>> wrote:
Some subsets of the tests override ALWAYS_CXXFLAGS or
TEST_ALWAYS_FLAGS and perform effective_target support tests using
these modified flags.
>>>
This patch adds a new function 'clear_effective_target_cache', which
is called at the end of every .exp file which overrides
ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>>>
>>> So, a simple English directive somewhere that says, if one changes
>>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
>>> clear_effective_target_cache at the end as the target cache can make
>>> decisions based upon the flags, and those decisions need to be redone
>>> when the flags change would be nice.
>>>
>>> I do wonder, do we need to reexamine when setting the flags? I’m
>>> thinking of a sequence like: non-thumb default, is_thumb, set flags
>>> (thumb), is_thumb. Anyway, safe to punt this until someone discovers
>>> it or is reasonable sure it happens.
>>>
>>> Anyway, all looks good. Ok.
>>>
>> Here is what I have committed (r227372).
>
> Hmmm, in fact this was r227401.
>
It caused:
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
ERROR: can't unset "et_cache(dfp,value)": no such element in array
ERROR: can't unset "et_cache(fsanitize_address,value)": no such element in
array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ia32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(ilp32,value)": no such element in array
ERROR: can't unset "et_cache(label_values,value)": no such element in array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(lp64,value)": no such element in array
ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
...
on Linux/x86-64:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>>
>>> I'll have a look.
>>> That's the configuration I used to check before committing, but I am
>>> going to re-check.
>>
>> proc check_cached_effective_target { prop args } {
>> global et_cache
>> global et_prop_list
>>
>> set target [current_target_name]
>> if {![info exists et_cache($prop,target)]
>> || $et_cache($prop,target) != $target} {
>> verbose "check_cached_effective_target $prop: checking $target" 2
>> set et_cache($prop,target) $target
>> set et_cache($prop,value) [uplevel eval $args]
>> lappend et_prop_list $prop
>>
>>
>> Aren't you appending $pop to et_prop_list even if it may be already
>> on the list?
>>
>> verbose "check_cached_effective_target cached list is now:
>> $et_prop_list" 2
>> }
>> set value $et_cache($prop,value)
>> verbose "check_cached_effective_target $prop: returning $value for
>> $target" 2
>> return $value
>> }
>>
>
> Like this?
>
> --
> H.J.
> ---
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index aad45f9..a6c16fe 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -125,7 +125,9 @@ proc check_cached_effective_target { prop args } {
> verbose "check_cached_effective_target $prop: checking $target" 2
> set et_cache($prop,target) $target
> set et_cache($prop,value) [uplevel eval $args]
> - lappend et_prop_list $prop
> + if {[lsearch $et_prop_list $prop] < 0} {
> +lappend et_prop_list $prop
> + }
> verbose "check_cached_effective_target cached list is now: $et_prop_list" 2
> }
> set value $et_cache($prop
[ubsan PATCH] Don't instrument static initializers (PR sanitizer/67279)
I think it really doesn't make sense to instrument static initializers; we
wouldn't be able to error at run-time anyway. Besides, it causes a compile-time
error. Generally, I think *compiling* with -fsanitize=undefined shouldn't add
any new compile-time errors. Yes, I know it does in some other cases; this is
just an incremental improvement.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-09-04 Marek Polacek
PR sanitizer/67279
* c-typeck.c (build_binary_op): Don't instrument static initializers.
* gcc.dg/ubsan/pr67279.c: New test.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c622a90..dc22396 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -11292,7 +11292,8 @@ build_binary_op (location_t location, enum tree_code
code,
if ((flag_sanitize & (SANITIZE_SHIFT | SANITIZE_DIVIDE
| SANITIZE_FLOAT_DIVIDE))
&& do_ubsan_in_current_function ()
- && (doing_div_or_mod || doing_shift))
+ && (doing_div_or_mod || doing_shift)
+ && !require_constant_value)
{
/* OP0 and/or OP1 might have side-effects. */
op0 = c_save_expr (op0);
diff --git gcc/testsuite/gcc.dg/ubsan/pr67279.c
gcc/testsuite/gcc.dg/ubsan/pr67279.c
index e69de29..5b5db42 100644
--- gcc/testsuite/gcc.dg/ubsan/pr67279.c
+++ gcc/testsuite/gcc.dg/ubsan/pr67279.c
@@ -0,0 +1,14 @@
+/* PR sanitizer/67279 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined -w" } */
+
+#define INT_MIN (-__INT_MAX__ - 1)
+
+void
+foo (void)
+{
+ static int a1 = 1 << 31;
+ static int a2 = 10 << 30;
+ static int a3 = 100 << 28;
+ static int a4 = INT_MIN / -1;
+}
Marek
Re: [ubsan PATCH] Don't instrument static initializers (PR sanitizer/67279)
On Fri, Sep 04, 2015 at 01:28:38PM +0200, Marek Polacek wrote: > I think it really doesn't make sense to instrument static initializers; we > wouldn't be able to error at run-time anyway. Besides, it causes a > compile-time > error. Generally, I think *compiling* with -fsanitize=undefined shouldn't add > any new compile-time errors. Yes, I know it does in some other cases; this is > just an incremental improvement. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2015-09-04 Marek Polacek > > PR sanitizer/67279 > * c-typeck.c (build_binary_op): Don't instrument static initializers. > > * gcc.dg/ubsan/pr67279.c: New test. Ok, but please make sure it is handled similarly in the C++ FE too (perhaps incrementally). Jakub
RE: Fix intelmic-mkoffload.c if the temp path contains a '-'
> -Original Message- > From: Ilya Verbin [mailto:iver...@gmail.com] > Sent: Friday, September 04, 2015 1:23 PM > To: Hahnfeld, Jonas; Jakub Jelinek > Cc: gcc-patches@gcc.gnu.org; Kirill Yukhin > Subject: Re: Fix intelmic-mkoffload.c if the temp path contains a '-' > > On Fri, Sep 04, 2015 at 11:10:13 +, Hahnfeld, Jonas wrote: > > *ping* > > I don't have write access to the repository... > > I've committed it to trunk: > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227489 > > What about gcc-5-branch? > > -- Ilya Thanks! The bug exists in GCC 5.x as well so the fix should be included in 5.3 if there will be such a version... Greetings, Jonas smime.p7s Description: S/MIME cryptographic signature
Re: [patch] libstdc++/65704 portable timed_mutex and recursive_timed_mutex
On 04/09/15 11:18 +0100, Jonathan Wakely wrote: This provides alternative implementations of std::timed_mutex and std::recursive_timed_mutex for targets that don't support the _POSIX_TIMEOUTS option (darwin and maybe HPUX). Committed to trunk now.
Re: [testsuite] Clean up effective_target cache
On Fri, Sep 4, 2015 at 4:18 AM, H.J. Lu wrote:
> On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
> wrote:
>> On 3 September 2015 at 13:31, H.J. Lu wrote:
>>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>>> wrote:
On 1 September 2015 at 16:04, Christophe Lyon
wrote:
> On 25 August 2015 at 17:31, Mike Stump wrote:
>> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
>> wrote:
>>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>>> TEST_ALWAYS_FLAGS and perform effective_target support tests using
>>> these modified flags.
>>
>>> This patch adds a new function 'clear_effective_target_cache', which
>>> is called at the end of every .exp file which overrides
>>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>>
>> So, a simple English directive somewhere that says, if one changes
>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
>> clear_effective_target_cache at the end as the target cache can make
>> decisions based upon the flags, and those decisions need to be redone
>> when the flags change would be nice.
>>
>> I do wonder, do we need to reexamine when setting the flags? I’m
>> thinking of a sequence like: non-thumb default, is_thumb, set flags
>> (thumb), is_thumb. Anyway, safe to punt this until someone discovers it
>> or is reasonable sure it happens.
>>
>> Anyway, all looks good. Ok.
>>
> Here is what I have committed (r227372).
Hmmm, in fact this was r227401.
>>>
>>> It caused:
>>>
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such element in
>>> array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>>> ERROR: can't unset "et_cache(label_values,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>>> ...
>>>
>>> on Linux/x86-64:
>>>
>>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>>
>>
>> I'll have a look.
>> That's the configuration I used to check before committing, but I am
>> going to re-check.
>
> proc check_cached_effective_target { prop args } {
> global et_cache
> global et_prop_list
>
> set target [current_target_name]
> if {![info exists et_cache($prop,target)]
> || $et_cache($prop,target) != $target} {
> verbose "check_cached_effective_target $prop: checking $target" 2
> set et_cache($prop,target) $target
> set et_cache($prop,value) [uplevel eval $args]
> lappend et_prop_list $prop
>
>
> Aren't you appending $pop to et_prop_list even if it may be already
> on the list?
>
> verbose "check_cached_effective_target cached list is now:
> $et_prop_list" 2
> }
> set value $et_cache($prop,value)
> verbose "check_cached_effective_target $prop: returning $value for
> $target" 2
> return $value
> }
>
Like this?
--
H.J.
---
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index aad45f9..a6c16fe 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -125,7 +125,9 @@ proc check_cached_effective_target { prop args } {
verbose "check_cached_effective_target $prop: checking $target" 2
set et_cache($prop,target) $target
set et_cache($prop,value) [uplevel eval $args]
- lappend et_prop_list $prop
+ if {[lsearch $et_prop_list $prop] < 0} {
+lappend et_prop_list $prop
+ }
verbose "check_cached_effective_target cached list is now: $et_prop_list" 2
}
set value $et_cache($prop,value)
Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
On Fri, Sep 04, 2015 at 11:10:13 +, Hahnfeld, Jonas wrote: > *ping* > I don't have write access to the repository... I've committed it to trunk: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227489 What about gcc-5-branch? -- Ilya
Re: [testsuite] Clean up effective_target cache
On Thu, Sep 3, 2015 at 8:03 AM, Christophe Lyon
wrote:
> On 3 September 2015 at 13:31, H.J. Lu wrote:
>> On Wed, Sep 2, 2015 at 7:02 AM, Christophe Lyon
>> wrote:
>>> On 1 September 2015 at 16:04, Christophe Lyon
>>> wrote:
On 25 August 2015 at 17:31, Mike Stump wrote:
> On Aug 25, 2015, at 1:14 AM, Christophe Lyon
> wrote:
>> Some subsets of the tests override ALWAYS_CXXFLAGS or
>> TEST_ALWAYS_FLAGS and perform effective_target support tests using
>> these modified flags.
>
>> This patch adds a new function 'clear_effective_target_cache', which
>> is called at the end of every .exp file which overrides
>> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS.
>
> So, a simple English directive somewhere that says, if one changes
> ALWAYS_CXXFLAGS or TEST_ALWAYS_FLAGS then they should do a
> clear_effective_target_cache at the end as the target cache can make
> decisions based upon the flags, and those decisions need to be redone
> when the flags change would be nice.
>
> I do wonder, do we need to reexamine when setting the flags? I’m
> thinking of a sequence like: non-thumb default, is_thumb, set flags
> (thumb), is_thumb. Anyway, safe to punt this until someone discovers it
> or is reasonable sure it happens.
>
> Anyway, all looks good. Ok.
>
Here is what I have committed (r227372).
>>>
>>> Hmmm, in fact this was r227401.
>>>
>>
>> It caused:
>>
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>> ERROR: can't unset "et_cache(arm_neon_ok,value)": no such element in array
>> ERROR: can't unset "et_cache(dfp,value)": no such element in array
>> ERROR: can't unset "et_cache(fsanitize_address,value)": no such element in
>> array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ia32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(ilp32,value)": no such element in array
>> ERROR: can't unset "et_cache(label_values,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(lp64,value)": no such element in array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>> ERROR: can't unset "et_cache(ptr32plus,value)": no such element in array
>> ...
>>
>> on Linux/x86-64:
>>
>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00167.html
>>
>
> I'll have a look.
> That's the configuration I used to check before committing, but I am
> going to re-check.
proc check_cached_effective_target { prop args } {
global et_cache
global et_prop_list
set target [current_target_name]
if {![info exists et_cache($prop,target)]
|| $et_cache($prop,target) != $target} {
verbose "check_cached_effective_target $prop: checking $target" 2
set et_cache($prop,target) $target
set et_cache($prop,value) [uplevel eval $args]
lappend et_prop_list $prop
Aren't you appending $pop to et_prop_list even if it may be already
on the list?
verbose "check_cached_effective_target cached list is now:
$et_prop_list" 2
}
set value $et_cache($prop,value)
verbose "check_cached_effective_target $prop: returning $value for
$target" 2
return $value
}
--
H.J.
Re: [v3 PATCH] Add C++11
On 14/08/15 12:01 -0400, Ed Smith-Rowland wrote:
OK.
This tested clean because it didn't install the headers.
So Jonathan. I am going to throw in the sponge on the configury.
Could you have a look and carry this over the finish line?
The main problem was in acinclude.m4:
+ GLIBCXX_CONDITIONAL(ENABLE_CUCHAR, test $enable_libstdcxx_cuchar =
yes)
Nothing set enable_libstdcxx_cuchar, so the conditional was false, and
so the headers weren't installed due to:
+if ENABLE_CUCHAR
+c_base_cuchar_header = ${c_base_srcdir}/cuchar
+c_compatibility_cuchar_header = ${c_compatibility_srcdir}/uchar.h
+else
+c_base_cuchar_header =
+c_compatibility_cuchar_header =
+endif
I've attached what I'm committing, which has a few tweaks but is
substantially the same as your last patch. Thanks for adding this
missing feature!
Tested powerpc64le-linux, committed to trunk.
commit 7a0a6889a1e348c1bc3980e0417dc3b4fbf2192d
Author: Jonathan Wakely
Date: Fri Sep 4 11:27:08 2015 +0100
Add C++11 header .
2015-09-04 Edward Smith-Rowland <3dw...@verizon.net>
Jonathan Wakely
* acinclude.m4 (GLIBCXX_CHECK_UCHAR_H): Define.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for .
* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/c/cuchar: New.
* include/c_compatibility/uchar.h: New.
* include/c_global/cuchar: New.
* include/c_std/cuchar: New.
* include/precompiled/stdc++.h: Include .
* testsuite/17_intro/headers/c++200x/stdc++.cc: Include .
* testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc:
Include .
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 789bc58..64c9b7e 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1809,6 +1809,52 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
])
dnl
+dnl Check for uchar.h and usability.
+dnl
+AC_DEFUN([GLIBCXX_CHECK_UCHAR_H], [
+
+ # Test uchar.h.
+ AC_CHECK_HEADERS(uchar.h, ac_has_uchar_h=yes, ac_has_uchar_h=no)
+
+ AC_LANG_SAVE
+ AC_LANG_CPLUSPLUS
+ ac_save_CXXFLAGS="$CXXFLAGS"
+ CXXFLAGS="$CXXFLAGS -std=c++11"
+
+ if test x"$ac_has_uchar_h" = x"yes"; then
+AC_MSG_CHECKING([for ISO C11 support for ])
+AC_TRY_COMPILE([#include
+ #ifdef __STDC_UTF_16__
+ long i = __STDC_UTF_16__;
+ #endif
+ #ifdef __STDC_UTF_32__
+ long j = __STDC_UTF_32__;
+ #endif
+ namespace test
+ {
+ using ::c16rtomb;
+ using ::c32rtomb;
+ using ::mbrtoc16;
+ using ::mbrtoc32;
+ }
+ ],
+ [], [ac_c11_uchar_cxx11=yes], [ac_c11_uchar_cxx11=no])
+ else
+ac_c11_uchar_cxx11=no
+ fi
+ AC_MSG_RESULT($ac_c11_uchar_cxx11)
+ if test x"$ac_c11_uchar_cxx11" = x"yes"; then
+AC_DEFINE(_GLIBCXX_USE_C11_UCHAR_CXX11, 1,
+ [Define if C11 functions in should be imported into
+ namespace std in .])
+ fi
+
+ CXXFLAGS="$ac_save_CXXFLAGS"
+ AC_LANG_RESTORE
+])
+
+
+dnl
dnl Check whether "/dev/random" and "/dev/urandom" are available for the
dnl random_device of "TR1" (Chapter 5.1, "Random number generation").
dnl
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 96ff16f..3456348 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -181,6 +181,7 @@ GLIBCXX_ENABLE_VTABLE_VERIFY([no])
# Checks for operating systems support that doesn't require linking.
GLIBCXX_CHECK_STDIO_PROTO
GLIBCXX_CHECK_SYSTEM_ERROR
+GLIBCXX_CHECK_UCHAR_H
# For the streamoff typedef.
GLIBCXX_CHECK_INT64_T
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 41fc4af..e579b22 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -710,6 +710,7 @@ c_base_headers = \
${c_base_srcdir}/cstring \
${c_base_srcdir}/ctgmath \
${c_base_srcdir}/ctime \
+ ${c_base_srcdir}/cuchar \
${c_base_srcdir}/cwchar \
${c_base_srcdir}/cwctype
@@ -752,6 +753,7 @@ c_compatibility_headers = \
${c_compatibility_srcdir}/string.h \
${c_compatibility_srcdir}/tgmath.h \
${c_compatibility_srcdir}/time.h \
+ ${c_compatibility_srcdir}/uchar.h \
${c_compatibility_srcdir}/wchar.h \
${c_compatibility_srcdir}/wctype.h
endif
diff --git a/libstdc++-v3/include/c/cuchar b/libstdc++-v3/include/c/cuchar
new file mode 100644
index 000..dd50c47
--- /dev/null
+++ b/libstdc++-v3/include/c/cuchar
@@ -0,0 +1,47 @@
+// -*- C++ -*- forwarding header.
+
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILI
RE: Fix intelmic-mkoffload.c if the temp path contains a '-'
> -Original Message-
> From: Hahnfeld, Jonas
> Sent: Tuesday, September 01, 2015 1:54 PM
> To: 'Jakub Jelinek'
> Cc: gcc-patches@gcc.gnu.org; Ilya Verbin; Kirill Yukhin
> Subject: RE: Fix intelmic-mkoffload.c if the temp path contains a '-'
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Tuesday, September 01, 2015 1:50 PM
> > To: Hahnfeld, Jonas
> > Cc: gcc-patches@gcc.gnu.org; Ilya Verbin; Kirill Yukhin
> > Subject: Re: Fix intelmic-mkoffload.c if the temp path contains a '-'
> >
> > On Tue, Sep 01, 2015 at 11:35:15AM +, Hahnfeld, Jonas wrote:
> > > >From 884b6199179e7a604474bc6a828a6861d3ff4501 Mon Sep 17
> 00:00:00
> > > >2001
> > > From: Jonas Hahnfeld
> > > Date: Thu, 20 Aug 2015 12:13:55 +0200
> > > Subject: [PATCH] Fix intelmic-mkoffload.c if the temp path contains a
> '-'
> > >
> > > 2015-08-20 Jonas Hahnfeld
> > >
> > > * intelmic-mkoffload.c (prepare_target_image): Fix if the temp path
> > > contains a '-'.
> > > ---
> > > gcc/config/i386/intelmic-mkoffload.c |2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/gcc/config/i386/intelmic-mkoffload.c
> > > b/gcc/config/i386/intelmic-mkoffload.c
> > > index ca15868..c9327cf 100644
> > > --- a/gcc/config/i386/intelmic-mkoffload.c
> > > +++ b/gcc/config/i386/intelmic-mkoffload.c
> > > @@ -460,7 +460,7 @@ prepare_target_image (const char
> > *target_compiler,
> > > int argc, char **argv)
> > >for (size_t i = 0; i <= symbol_name_len; i++)
> > > {
> > >char c = target_so_filename[i];
> > > - if ((c == '/') || (c == '.'))
> > > + if ((c == '/') || (c == '.') || (c == '-'))
> >
> > The ()s around the comparisons are unnecessary, but it is preexisting,
so
> the
> > fix is ok for trunk with or without the removal of those ()s.
> >
> > Jakub
>
> Could you commit the patch for me as I don't have commit access?
> And also consider backporting this trivial fix for 'gcc-5-branch'?
>
> Thanks,
> Jonas
*ping*
I don't have write access to the repository...
Thanks,
Jonas
smime.p7s
Description: S/MIME cryptographic signature
[C++ PATCH] Set C++ standard earlier
I noticed that -Wshift-overflow isn't on by default even though now we're
defaulting to C++14. The reason is that at the time we set warn_shift_overflow
the cxx_dialect is still cxx_unset. So let's set the default C++ standard
earlier in that function, before be enable/disable the warnings.
(A two other patches are prerequisite before this may go in.)
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-09-04 Marek Polacek
* c-opts.c (c_common_post_options): Set C++ standard earlier, before
setting various warnings.
diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
index 3239a85..f358b62 100644
--- gcc/c-family/c-opts.c
+++ gcc/c-family/c-opts.c
@@ -800,6 +800,10 @@ c_common_post_options (const char **pfilename)
&& flag_no_builtin)
flag_tree_loop_distribute_patterns = 0;
+ /* Set C++ standard to C++14 if not specified on the command line. */
+ if (c_dialect_cxx () && cxx_dialect == cxx_unset)
+set_std_cxx14 (/*ISO*/false);
+
/* -Woverlength-strings is off by default, but is enabled by -Wpedantic.
It is never enabled in C++, as the minimum limit is not normative
in that standard. */
@@ -887,10 +891,6 @@ c_common_post_options (const char **pfilename)
if (flag_abi_version == 0)
flag_abi_version = 10;
- /* Set C++ standard to C++14 if not specified on the command line. */
- if (c_dialect_cxx () && cxx_dialect == cxx_unset)
-set_std_cxx14 (/*ISO*/false);
-
if (cxx_dialect >= cxx11)
{
/* If we're allowing C++0x constructs, don't warn about C++98
Marek
[PATCH] Fix a few UB when left-shifting
This patch fixes a few -Wshift-negative-value warnings in the code. It
oughtn't to cause any functional changes. This will be needed for the
bootstrap to pass after I commit some other patch.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-09-03 Marek Polacek
* c-common.c (warn_for_sign_compare): Cast to unsigned when shifting
a negative value.
* c-typeck.c (set_nonincremental_init_from_string): Use
HOST_WIDE_INT_M1U when shifting a negative value.
* rtlanal.c (split_double): Cast to unsigned when shifting a negative
value.
* sched-int.h (UNKNOWN_DEP_COST): Likewise.
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 7691035..16d8346 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -12142,7 +12142,7 @@ warn_for_sign_compare (location_t location,
if (bits < TYPE_PRECISION (result_type)
&& bits < HOST_BITS_PER_LONG && unsignedp)
{
- mask = (~ (HOST_WIDE_INT) 0) << bits;
+ mask = (~ (unsigned HOST_WIDE_INT) 0) << bits;
if ((mask & constant) != mask)
{
if (constant == 0)
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index e8c8189..04947a5 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -8250,7 +8250,7 @@ set_nonincremental_init_from_string (tree str,
{
if (val[0] & (((HOST_WIDE_INT) 1) << (bitpos - 1)))
{
- val[0] |= ((HOST_WIDE_INT) -1) << bitpos;
+ val[0] |= HOST_WIDE_INT_M1U << bitpos;
val[1] = -1;
}
}
@@ -8261,8 +8261,7 @@ set_nonincremental_init_from_string (tree str,
}
else if (val[1] & (((HOST_WIDE_INT) 1)
<< (bitpos - 1 - HOST_BITS_PER_WIDE_INT)))
- val[1] |= ((HOST_WIDE_INT) -1)
- << (bitpos - HOST_BITS_PER_WIDE_INT);
+ val[1] |= HOST_WIDE_INT_M1U << (bitpos - HOST_BITS_PER_WIDE_INT);
}
value = wide_int_to_tree (type,
diff --git gcc/rtlanal.c gcc/rtlanal.c
index ef98f4b..b1be4db 100644
--- gcc/rtlanal.c
+++ gcc/rtlanal.c
@@ -5805,9 +5805,9 @@ split_double (rtx value, rtx *first, rtx *second)
if (BITS_PER_WORD < HOST_BITS_PER_LONG && BITS_PER_WORD == 32)
{
if (l[0] & ((long) 1 << 31))
- l[0] |= ((long) (-1) << 32);
+ l[0] |= ((unsigned long) (-1) << 32);
if (l[1] & ((long) 1 << 31))
- l[1] |= ((long) (-1) << 32);
+ l[1] |= ((unsigned long) (-1) << 32);
}
#endif
diff --git gcc/sched-int.h gcc/sched-int.h
index 61825ce..800262c 100644
--- gcc/sched-int.h
+++ gcc/sched-int.h
@@ -240,7 +240,7 @@ struct _dep
int cost:20;
};
-#define UNKNOWN_DEP_COST (-1<<19)
+#define UNKNOWN_DEP_COST ((int) ((unsigned int) -1 << 19))
typedef struct _dep dep_def;
typedef dep_def *dep_t;
Marek
[PATCH] Tweak INTTYPE_MINIMUM to avoid warning
While looking into something else I spotted this UB. I rewrote this to use another UB, but I'd say left-shifting into the sign bit isn't such an anathema as it was. It's -Wshift-negative-value that warns on this. The reason why we haven't seen the warning before is due to a bug I'm fixing in the other patch. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-09-03 Marek Polacek * system.h (INTTYPE_MINIMUM): Rewrite to avoid shift warning. * system.h (INTTYPE_MINIMUM): Rewrite to avoid shift warning. diff --git gcc/gcc/system.h gcc/gcc/system.h index 9ca5b5f..78ad609 100644 --- gcc/gcc/system.h +++ gcc/gcc/system.h @@ -307,7 +307,7 @@ extern int errno; /* The outer cast is needed to work around a bug in Cray C 5.0.3.0. It is necessary at least when t == time_t. */ #define INTTYPE_MINIMUM(t) ((t) (INTTYPE_SIGNED (t) \ - ? ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1) : (t) 0)) + ? (t) 1 << (sizeof (t) * CHAR_BIT - 1) : (t) 0)) #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t))) /* Use that infrastructure to provide a few constants. */ diff --git gcc/libcpp/system.h gcc/libcpp/system.h index b18d658..a2e8c26 100644 --- gcc/libcpp/system.h +++ gcc/libcpp/system.h @@ -230,7 +230,7 @@ extern int errno; /* The outer cast is needed to work around a bug in Cray C 5.0.3.0. It is necessary at least when t == time_t. */ #define INTTYPE_MINIMUM(t) ((t) (INTTYPE_SIGNED (t) \ - ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0)) + ? (t) 1 << (sizeof (t) * CHAR_BIT - 1) : (t) 0)) #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t))) /* Use that infrastructure to provide a few constants. */ Marek
[hsa] Class refactoring of hsa_insn_basic
Hello.
Following patch is a refactoring of ISA hierarchy related to
hsa_insn_basic class.
Thanks,
Martin
>From 9679925a23976db153b431d55f0f9cf7131f3886 Mon Sep 17 00:00:00 2001
From: mliska
Date: Thu, 3 Sep 2015 22:58:45 +0200
Subject: [PATCH 3/4] HSA: follow-up and refactoring of hsa_insn_basic class
hierarchy.
gcc/ChangeLog:
2015-09-04 Martin Liska
* hsa-brig.c (emit_memory_insn): Use get_op.
(emit_signal_insn): Use operand_count.
(emit_atomic_insn): Use get_op and operand_count.
(emit_addr_insn): Likewise.
(emit_segment_insn): Likewise.
(emit_cmp_insn): Likewise.
(emit_branch_insn): Likewise.
(emit_cvt_insn): Likewise.
(emit_queue_insn): Likewise.
(emit_basic_insn): Likewise.
* hsa-dump.c (dump_hsa_operands): Likewise.
(dump_hsa_insn): Likewise.
* hsa-gen.c (hsa_function_representation::get_shadow_reg):
(hsa_insn_basic::set_op): Set definition for just a unset register.
(hsa_insn_basic::get_op): New function.
(hsa_insn_basic::get_op_addr): Likewise.
(hsa_insn_basic::operand_count): Likewise.
(hsa_insn_basic::hsa_insn_basic): Use set_op.
(hsa_insn_phi::hsa_insn_phi): Likewise.
(hsa_insn_br::hsa_insn_br): Do not push to uses vector.
(hsa_insn_mem::hsa_insn_mem): Add new arguments to ctor.
(hsa_bb::append_insn): Use operand_count function.
(hsa_reg_for_gimple_ssa_reqtype): Use newly added ctor.
(gen_address_calculation): Do not push to uses vector.
(add_addr_regs_if_needed): Use set_op.
(gen_hsa_addr): Likewise.
(gen_hsa_addr_insns): Use set_op.
(hsa_reg_or_immed_for_gimple_op): Remove one argument.
(hsa_build_append_simple_mov): Use ctor.
(gen_hsa_insns_for_bitfield_load): Do not set definition and do not
push to uses vector.
(gen_hsa_insns_for_load): Likewise.
(gen_hsa_insns_for_store): Likewise.
(gen_hsa_memory_copy): Likewise.
(gen_hsa_insns_for_single_assignment): Update call of a function.
(hsa_spill_in): Use ctor.
(hsa_spill_out): Likewise.
(gen_hsa_cmp_insn_from_gimple): Use set_op.
(gen_hsa_unary_operation): Do not set definition and do not
push to uses vector.
(gen_hsa_binary_operation): Likewise.
(gen_hsa_insns_for_operation_assignment): Likewise.
(gen_hsa_insns_for_direct_call): Use ctor.
(gen_hsa_insns_for_return): Likewise.
(gen_hsa_insns_for_kernel_call): Do not set definition.
(gen_hsa_unaryop_for_builtin): Update call of a function.
(gen_hsa_ternary_atomic_for_builtin): Likewise.
(gen_hsa_phi_from_gimple_phi): Use set_op.
(gen_function_def_parameters): Do not set definition.
* hsa-regalloc.c (naive_process_phi): Use operand_count.
(insn_reg_addr): Use get_op_addr and get_op.
(rewrite_code_bb): Likewise.
(linear_scan_regalloc): Likewise.
* hsa.h (class hsa_op_reg): Add declarations of new functions.
---
gcc/hsa-brig.c | 88 ++---
gcc/hsa-dump.c | 54
gcc/hsa-gen.c | 374 -
gcc/hsa-regalloc.c | 30 ++---
gcc/hsa.h | 40 +++---
5 files changed, 254 insertions(+), 332 deletions(-)
diff --git a/gcc/hsa-brig.c b/gcc/hsa-brig.c
index 7daae33..728430c 100644
--- a/gcc/hsa-brig.c
+++ b/gcc/hsa-brig.c
@@ -1103,7 +1103,7 @@ emit_memory_insn (hsa_insn_mem *mem)
BrigOperandOffset32_t operand_offsets[2];
uint32_t byteCount;
- hsa_op_address *addr = as_a (mem->operands[1]);
+ hsa_op_address *addr = as_a (mem->get_op (1));
/* This is necessary because of the erroneous typedef of
BrigMemoryModifier8_t which introduces padding which may then contain
@@ -1115,8 +1115,8 @@ emit_memory_insn (hsa_insn_mem *mem)
repr.base.opcode = htole16 (mem->opcode);
repr.base.type = htole16 (mem->type);
- operand_offsets[0] = htole32 (enqueue_op (mem->operands[0]));
- operand_offsets[1] = htole32 (enqueue_op (mem->operands[1]));
+ operand_offsets[0] = htole32 (enqueue_op (mem->get_op (0)));
+ operand_offsets[1] = htole32 (enqueue_op (mem->get_op (1)));
/* We have two operands so use 4 * 2 for the byteCount. */
byteCount = htole32 (4 * 2);
@@ -1148,7 +1148,7 @@ emit_signal_insn (hsa_insn_signal *mem)
{
struct BrigInstSignal repr;
BrigOperandOffset32_t *operand_offsets = XCNEWVEC (BrigOperandOffset32_t,
- mem->operands.length ());
+ mem->operand_count ());
uint32_t byteCount;
/* This is necessary because of the erroneous typedef of
@@ -1161,15 +1161,15 @@ emit_signal_insn (hsa_insn_signal *mem)
repr.base.opcode = htole16 (mem->opcode);
repr.base.type = htole16 (mem->type);
- for (unsigned i = 0; i < mem->operands.length (); i++)
-operand_offsets[i] = htole32 (enqueue_op (mem->operands[i]));
+ for (unsigned i = 0; i < mem->operand_count (); i++)
+operand_offsets[i] = htole32 (enqueue_op (mem->get_op (i)));
/* We have N operands so use 4 * N for the byteCount. */
- byteCount = htole32 (4 * mem->operands.length ());
+ byteCount = htole32 (4 * mem->operand_count ());
repr.base.operands = htole32 (brig_data.add (&byteCount, sizeof (byteCount)));
brig_data.add (op
[hsa] Create HSA clones
Hello.
Following patch adds a new IPA pass that creates clones intended to be
expanded to HSAIL. The pass is capable of LTO stuff.
Thanks,
Martin
>From 8cbddf693f93328f117dc48588deee924d2df6cd Mon Sep 17 00:00:00 2001
From: mliska
Date: Tue, 1 Sep 2015 14:10:24 +0200
Subject: [PATCH 1/4] HSA: create HSA clones.
gcc/c-family/ChangeLog:
2015-09-03 Martin Liska
* c-common.c (handle_hsa_attribute): Do not handle hsakernel attribute.
gcc/lto/ChangeLog:
2015-09-03 Martin Liska
* lto-partition.c (add_symbol_to_partition_1): For an HSA clone, append
also all dependencies to a LTO partition.
libgomp/ChangeLog:
2015-09-03 Martin Liska
* plugin/plugin-hsa.c (GOMP_OFFLOAD_load_image): Enable having a module
without kernels (can contain HSA functions).
gcc/ChangeLog:
2015-09-03 Martin Liska
* Makefile.in: Add new source file and remove hsa-gen.c from list
of GT files.
* cgraph.h: Remove hsa_imp_of property of cgraph_node.
* hsa-brig.c (brig_init): Append LTRANS name to a BRIG module name.
(emit_function_directives): Add new argument.
(emit_function_declaration): Use it.
(emit_call_insn): Fill up offsets of functions that should be filled
before a BRIG module is done.
(hsa_brig_emit_function): Emit declarations before a function
is defined/declared.
(hsa_output_kernel_mapping): An HSA brig module can have zero kernels.
(hsa_output_brig): Process functions linkage that fills up correct
code list references.
* hsa-dump.c: Add new include files due to function_summary.
* hsa-gen.c (hsa_get_gpu_function): New function.
(hsa_get_host_function): New function.
(gen_hsa_insns_for_direct_call): Small refactoring.
(gen_hsa_insns_for_known_library_call): Likewise.
(hsa_generate_function_declaration): Sanitize function name.
(generate_hsa): Remove unused return value.
(init_hsa_functions): Remove.
(insert_store_range_dim): Likewise.
(wrap_hsa_kernel_call): Likewise.
(wrap_all_hsa_calls): Likewise.
(pass_gen_hsail::execute): Emit code just for cgraph_nodes that
is hsa_summaries.
* hsa-regalloc.c: Include additional header files.
* hsa.c (hsa_get_declaration_name): Use asm_name as name of function.
(hsa_register_kernel): New function.
* hsa.h (enum hsa_function_kind): New enum.
(struct hsa_function_summary): New.
(hsa_summary_t::link_functions): Likewise.
* ipa-hsa.c: New file.
* lto-section-in.c: Add new section name.
* lto-streamer.h (enum lto_section_type): Likewise.
* omp-low.c (expand_parallel_call): Fill up HSA function summary.
(expand_target_kernel_body): Likewise.
* passes.c (execute_one_pass): Terminate pass queue if stop execution
TODO is returned.
(execute_pass_list_1): Likewise.
(execute_ipa_pass_list): Likewise.
* passes.def: Add new IPA pass.
* timevar.def: Likewise.
* tree-pass.h: Likewise.
---
gcc/Makefile.in | 2 +-
gcc/c-family/c-common.c | 9 --
gcc/cgraph.h| 4 -
gcc/hsa-brig.c | 89 +---
gcc/hsa-dump.c | 40 +-
gcc/hsa-gen.c | 267 +++
gcc/hsa-regalloc.c | 27 +++-
gcc/hsa.c | 28
gcc/hsa.h | 62 +
gcc/ipa-hsa.c | 330
gcc/lto-section-in.c| 3 +-
gcc/lto-streamer.h | 1 +
gcc/lto/lto-partition.c | 48 +++
gcc/omp-low.c | 16 ++-
gcc/passes.c| 18 ++-
gcc/passes.def | 1 +
gcc/timevar.def | 1 +
gcc/tree-pass.h | 2 +
libgomp/plugin/plugin-hsa.c | 2 -
19 files changed, 681 insertions(+), 269 deletions(-)
create mode 100644 gcc/ipa-hsa.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 1a37630..ea8750b 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1314,6 +1314,7 @@ OBJS = \
ipa-icf.o \
ipa-icf-gimple.o \
ipa-reference.o \
+ ipa-hsa.o \
ipa-ref.o \
ipa-utils.o \
ipa.o \
@@ -2371,7 +2372,6 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h $(srcdir)/coretypes.h \
$(srcdir)/ipa-devirt.c \
$(srcdir)/internal-fn.h \
$(srcdir)/hsa.c \
- $(srcdir)/hsa-gen.c \
@all_gtfiles@
# Compute the list of GT header files from the corresponding C sources,
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index a8775ab..df7819f 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -667,10 +667,6 @@ const struct attribute_spec c_common_attribute_table[] =
handle_noinline_attribute, false },
{ "noclone",0, 0, true, false, false,
handle_noclone_attribute, false },
- { "hsa",0, 0, true, false, false,
- handle_hsa_attribute, false },
- { "hsakernel", 0, 0, true, false, false,
- handle_hsa_attribute, false },
{ "hsafunc",0, 0, true, false, false,
handle_hsa_attribute, false },
{ "no_icf", 0, 0, true, false, fal
Re: [gomp4.1] Depend clause support for offloading
On Thu, Sep 03, 2015 at 04:16:50PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 02, 2015 at 05:58:54PM +0200, Jakub Jelinek wrote:
> > Here is the start of the async offloading support I've talked about,
> > but nowait is not supported on the library side yet, only depend clause
> > (and for that I haven't added a testcase yet).
>
> Added testcase revealed two (small) issues, here is a fix for that together
> with the testcase.
There has been a bug in the testcase (missing map(from:err) in 3 places),
which hid a problem that on target constructs with depend clause (what about
just nowait?) we have to avoid using GOMP_FIRSTPRIVATE_INT or copy value
into temporary and take temporary's address for GOMP_FIRSTPRIVATE unless
we can prove other tasks can't modify the value while waiting for
dependencies (if it is addressable or shared with other threads/tasks,
then we have to use GOMP_FIRSTPRIVATE with address of the real variable,
so that if other tasks change it, we pick up the right values).
2015-09-04 Jakub Jelinek
* omp-low.c (lower_omp_target): If target has depend
clauses, avoid using GOMP_MAP_FIRSTPRIVATE_INT unless the
var is non-addressable and private in the current task.
Even for GOMP_MAP_FIRSTPRIVATE, if the var is non-addressable,
but shared or threadprivate, take address of the shared var
rather than initializing a temporary with the current value.
* testsuite/libgomp.c/target-25.c (main): Add missing
map(from: err) clauses to target constructs.
--- gcc/omp-low.c.jj2015-09-03 16:36:31.0 +0200
+++ gcc/omp-low.c 2015-09-04 11:34:45.512416693 +0200
@@ -13236,6 +13236,7 @@ lower_omp_target (gimple_stmt_iterator *
location_t loc = gimple_location (stmt);
bool offloaded, data_region;
unsigned int map_cnt = 0;
+ bool has_depend = false;
offloaded = is_gimple_omp_offloaded (stmt);
switch (gimple_omp_target_kind (stmt))
@@ -13268,6 +13269,7 @@ lower_omp_target (gimple_stmt_iterator *
dep_bind = gimple_build_bind (NULL, NULL, make_node (BLOCK));
lower_depend_clauses (gimple_omp_target_clauses_ptr (stmt),
&dep_ilist, &dep_olist);
+ has_depend = true;
}
tgt_bind = NULL;
@@ -13719,9 +13721,44 @@ lower_omp_target (gimple_stmt_iterator *
type = TREE_TYPE (ovar);
if (is_reference (ovar))
type = TREE_TYPE (type);
+ bool use_firstprivate_int, force_addr;
+ use_firstprivate_int = false;
+ force_addr = false;
if ((INTEGRAL_TYPE_P (type)
- && TYPE_PRECISION (type) <= POINTER_SIZE)
+&& TYPE_PRECISION (type) <= POINTER_SIZE)
|| TREE_CODE (type) == POINTER_TYPE)
+ use_firstprivate_int = true;
+ if (has_depend)
+ {
+ if (is_reference (var))
+ use_firstprivate_int = false;
+ else if (is_gimple_reg (var))
+ {
+ if (DECL_HAS_VALUE_EXPR_P (var))
+ {
+ tree v = get_base_address (var);
+ if (DECL_P (v) && TREE_ADDRESSABLE (v))
+ {
+ use_firstprivate_int = false;
+ force_addr = true;
+ }
+ else
+ switch (TREE_CODE (v))
+ {
+ case INDIRECT_REF:
+ case MEM_REF:
+ use_firstprivate_int = false;
+ force_addr = true;
+ break;
+ default:
+ break;
+ }
+ }
+ }
+ else
+ use_firstprivate_int = false;
+ }
+ if (use_firstprivate_int)
{
tkind = GOMP_MAP_FIRSTPRIVATE_INT;
tree t = var;
@@ -13734,7 +13771,7 @@ lower_omp_target (gimple_stmt_iterator *
}
else if (is_reference (var))
gimplify_assign (x, var, &ilist);
- else if (is_gimple_reg (var))
+ else if (!force_addr && is_gimple_reg (var))
{
tree avar = create_tmp_var (TREE_TYPE (var));
mark_addressable (avar);
@@ -13867,9 +13904,40 @@ lower_omp_target (gimple_stmt_iterator *
type = TREE_TYPE (var);
if (is_reference (var))
type = TREE_TYPE (type);
+ bool use_firstprivate_int;
+ use_firstprivate_int = false;
if ((INTEGRAL_TYPE_P (type)
&& TYPE_PRECISION (type) <= POINTER_SIZE)
|| TREE_CODE (type) == POINTER_TYPE)
+ use_firstprivate_int = true;
+ if (has_depen
[patch] libstdc++/65704 portable timed_mutex and recursive_timed_mutex
This provides alternative implementations of std::timed_mutex and
std::recursive_timed_mutex for targets that don't support the
_POSIX_TIMEOUTS option (darwin and maybe HPUX).
The new versions need to use std::condition_variable, which depends on
std::mutex, so I have moved std::mutex, std::lock_guard, and
std::unique_lock into a new header, so that can
do:
#include
#if ! _GTHREAD_USE_MUTEX_TIMEDLOCK
# include
# include
#endif
...
#if _GTHREAD_USE_MUTEX_TIMEDLOCK
// existing implementations using pthread_mutex_t
#else
// new implementations using std::condition_variable
#endif
The new smaller header has the advantage that other
libstdc++ headers which only need std::mutex and the scoped locks can
include . We should only include when we need
timed or recursive mutexes, or std::call_once.
Tested powerpc64le-linux as normal, and again with #undef
_GTHREAD_USE_MUTEX_TIMEDLOCK to test the new code.
commit 03a2d83efd54483a1b19d3fa499757fbd40cf8ef
Author: Jonathan Wakely
Date: Fri Sep 4 10:39:42 2015 +0100
Add portable timed_mutex and recursive_timed_mutex.
PR libstdc++/65704
* include/Makefile.am: Add .
* include/Makefile.in: Regenerate.
* include/bits/mutex.h (__mutex_base, mutex, lock_guard, unique_lock):
New file containing types moved from .
* include/std/condition_variable: Include instead of
.
* include/std/mutex (__mutex_base, mutex, lock_guard, unique_lock):
Move to .
* testsuite/30_threads/recursive_timed_mutex/cons/1.cc: Remove
dg-require-gthreads-timed.
* testsuite/30_threads/recursive_timed_mutex/cons/assign_neg.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/cons/copy_neg.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/dest/
destructor_locked.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/lock/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/lock/2.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/unlock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/assign_neg.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/copy_neg.cc: Likewise.
* testsuite/30_threads/timed_mutex/dest/destructor_locked.cc:
Likewise.
* testsuite/30_threads/timed_mutex/lock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/requirements/standard_layout.cc:
Likewise.
* testsuite/30_threads/timed_mutex/try_lock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/3.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Likewise.
* testsuite/30_threads/timed_mutex/unlock/1.cc: Likewise.
* testsuite/30_threads/unique_lock/cons/5.cc: Likewise.
* testsuite/30_threads/unique_lock/cons/6.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/3.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/4.cc: Likewise.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 41fc4af..3edb914 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -122,6 +122,7 @@ bits_headers = \
${bits_srcdir}/mask_array.h \
${bits_srcdir}/memoryfwd.h \
${bits_srcdir}/move.h \
+ ${bits_srcdir}/mutex.h \
${bits_srcdir}/ostream.tcc \
${bits_srcdir}/ostream_insert.h \
${bits_srcdir}/parse_numbers.h \
diff --git a/libstdc++-v3/include/bits/mutex.h b/libstdc++-v3/include/bits/mutex.h
new file mode 100644
index 000..43f5b0b
--- /dev/null
+++ b/libstdc++-v3/include/bits/mutex.h
@@ -0,0 +1,360 @@
+// std::mutex implementation -*- C++ -*-
+
+// Copyright (C) 2003-2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
Re: [PATCH 11/15][AArch64] vreinterpret(q?), vget_(low|high), vld1(q?)_dup
On Mon, Aug 24, 2015 at 10:17:19AM +0100, Alan Lawrence wrote: > James Greenhalgh wrote: > > > > Did you check that these actually emit the expected instruction? > > > > Applying your patch set I see some fairly unpleasant code generation, > > but I might have made an error, or perhaps you have another patch in > > waiting? > > > > Thanks, > > James > > > > Yes, you are right, some of the code generation here is a bit grotty. However > I think we should go for correctness and tests first, performance second. > (There will be some tweaks to the iterators in aarch64-simd.md.) In that case, these should be implemented as inline assembly blocks. As it stands, the code generation for these intrinsics will be very poor with this patch applied. I'm going to hold off OKing this until I see a follow-up to fix the code generation, either replacing those particular intrinsics with inline asm, or doing the more comprehensive fix in the back-end. Thanks, James
Re: [PATCH 12/15][AArch64] Add vcvt(_high)?_f32_f16 intrinsics, with BE RTL fix
On Tue, Aug 25, 2015 at 11:47:02AM +0100, Alan Lawrence wrote: > James Greenhalgh wrote: > >> > >> - VAR1 (UNOP, vec_unpacks_hi_, 10, v4sf) > >> + VAR2 (UNOP, vec_unpacks_hi_, 10, v4sf, v8hf) > > > > Should this not use the appropriate "BUILTIN_..." iterator? > > Indeed; BUILTIN_VQ_HSF it is. > > >>VAR1 (BINOP, float_truncate_hi_, 0, v4sf) > >>VAR1 (BINOP, float_truncate_hi_, 0, v8hf) > > I could also use BUILTIN_VQ_HSF here (these two were added in a previous > patch, before the VQ_HSF iterator was introduced). However, that goes against > the principle that we should use the same iterator as the pattern (the > pattern uses the attribute of the VDF iterator), so I'm not sure > whether that would be preferable (i.e. as a separate patch)? > > >> - VAR1 (UNOP, float_extend_lo_, 0, v2df) > >> + VAR2 (UNOP, float_extend_lo_, 0, v2df, v4sf) > > > > Likewise. > > Similarly, the required iterator does not exist, as float_extend_lo_ is named > after the attribute of the VDF iterator. The nearest equivalents I can > see use two VAR1's rather than a VAR2, so I've updated the patch to do that > too. > > OK with those two changes? (patch attached and bootstrapped+check-gcc on > aarch64-none-linux-gnu) OK. Thanks, James
Re: [PATCH, ARM]: Add TARGET_OPTION[RESTORE,SAVE,PRINT] hooks
Hi Christian,
Thanks again for working on this!
On 02/09/15 10:11, Christian Bruel wrote:
Hi,
This patch uses TARGET_OPTION_RESTORE and SAVE to switch the attribute
target dependent params between functions.
This is more efficient than arm_option_params_internal, and prepares the
ground for the other machine target attributes.
To be honest, I'm reluctant to take this approach.
The design I'd like to see is for us to figure out the minimal set
of TargetSave variables (and options in arm.opt that require the tag Save)
and use them to 'package' the backend state whenever needed, with the help
of TARGET_OPTION_SAVE when appropriate.
Then during TARGET_OPTION_RESTORE we would call arm_option_override_internal
and arm_option_params_internal to restore all the different backend
variables that we need.
In my opinion that is the approach that would give the most maintainability.
In any case, I see arm_option_params_internal is not particularly complicated
at the moment, so I don't think your patch would show any noticeable speed
improvement
(unless you can share data to demonstrate that :))
Maybe we can make the roadmap for this more concrete if you post a description
of
what parameters you'd like to save and restore to achieve this goal and we can
discuss
that. Some that come to mind would be: CPU we're tuning for, architecture, FPU,
and
basically any option in arm.opt which we want to allow to vary on a
per-function basis
(i.e. no ABI-changing options).
Hope this helps,
Kyrill
P.S.
I recently implemented this functionality in the aarch64 backend.
Maybe the implementation of these hooks over there could be of some help
(though I appreciate the arm backend is more complicated with more legacy and
option variations)
No regressions. OK for trunk ?
many thanks
Christian
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 227366)
+++ gcc/config/arm/arm.c(working copy)
@@ -245,9 +245,14 @@
static void arm_expand_builtin_va_start (tree, rtx);
static tree arm_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
static void arm_option_override (void);
+static void arm_option_print (FILE *, int, struct cl_target_option *);
static void arm_set_current_function (tree);
static bool arm_can_inline_p (tree, tree);
static bool arm_valid_target_attribute_p (tree, tree, tree, int);
+static void arm_function_specific_save (struct cl_target_option *,
+ struct gcc_options *);
+static void arm_function_specific_restore (struct gcc_options *,
+ struct cl_target_option *);
I'd rather call them arm_option_save and arm_option_restore.
That way it's easy to deduce that they implement TARGET_OPTION_{SAVE,RESTORE}.
Re: [patch] libstdc++/65473 Make define libstdc++ version macros.
On 03/09/15 13:22 -0600, Martin Sebor wrote: On 09/03/2015 04:58 AM, Jonathan Wakely wrote: This change would allow including to be used to check for __GLIBCXX__ and detect whether youre using libstdc++ or not. Howard Hinnant recommends including that header for libc++ because it has no other effects in C++. We could make every header include so that any of them can be used, but I can't be bothered doing that change! This makes it work for the one header that is recommended to be used, but of course that doesn't help people using older versions of libstdc++, who still need to include some other header. Is this worth doing? I'd say it's worth doing consistently, in every header. Users are told by others (e.g., on various discussion forums) to expect to be able to check what C++ library implementation they're using by including any C++ standard header and testing the known version macros. OK, here's a patch to add to all the headers that don't have it. Tested powerpc64le-linux, committed to trunk. I must admit I don't understand why many of the headers include the header and outside the include guard ... AFAIK it's only needed for , and will lead to headers being unnecessarily re-opened if included twice, but I'm not going to change that. :1:18: fatal error: cuchar: No such file or directory compilation terminated. 0 Ed sent a patch to add which I'm going to tidy up and commit. commit a4a655dacdcfadfac3f90777e574e14acfdbc973 Author: Jonathan Wakely Date: Fri Sep 4 10:02:43 2015 +0100 Make all headers include PR libstdc++/65473 * include/c/cassert: Include . * include/c/cerrno: Likewise. * include/c/cfloat: Likewise. * include/c/ciso646: Likewise. * include/c/climits: Likewise. * include/c_global/cassert: Likewise. * include/c_global/cerrno: Likewise. * include/c_global/cfloat: Likewise. * include/c_global/ciso646: Likewise. * include/c_global/climits: Likewise. * include/c_std/cassert: Likewise. * include/c_std/cerrno: Likewise. * include/c_std/cfloat: Likewise. * include/c_std/ciso646: Likewise. * include/c_std/climits: Likewise. diff --git a/libstdc++-v3/include/c/cassert b/libstdc++-v3/include/c/cassert index 46e4172..3965d16 100644 --- a/libstdc++-v3/include/c/cassert +++ b/libstdc++-v3/include/c/cassert @@ -30,4 +30,5 @@ #pragma GCC system_header +#include #include_next diff --git a/libstdc++-v3/include/c/cerrno b/libstdc++-v3/include/c/cerrno index 1d56cb4..6ea1d4c 100644 --- a/libstdc++-v3/include/c/cerrno +++ b/libstdc++-v3/include/c/cerrno @@ -40,6 +40,7 @@ #pragma GCC system_header +#include #include_next // Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998 diff --git a/libstdc++-v3/include/c/cfloat b/libstdc++-v3/include/c/cfloat index 25cfa64..282eb31 100644 --- a/libstdc++-v3/include/c/cfloat +++ b/libstdc++-v3/include/c/cfloat @@ -31,6 +31,7 @@ #pragma GCC system_header +#include #include_next #endif diff --git a/libstdc++-v3/include/c/ciso646 b/libstdc++-v3/include/c/ciso646 index 125f166..6eca274 100644 --- a/libstdc++-v3/include/c/ciso646 +++ b/libstdc++-v3/include/c/ciso646 @@ -27,6 +27,12 @@ * in your programs, rather than any of the "*.h" implementation files. * * This is the C++ version of the Standard C Library header @c iso646.h, - * and its contents are (mostly) the same as that header, but are all - * contained in the namespace @c std. + * which is empty in C++. */ +#ifndef _GLIBCXX_CISO646 +#define _GLIBCXX_CISO646 + +#pragma GCC system_header + +#include +#endif diff --git a/libstdc++-v3/include/c/climits b/libstdc++-v3/include/c/climits index f8b19d5..5333af9 100644 --- a/libstdc++-v3/include/c/climits +++ b/libstdc++-v3/include/c/climits @@ -31,6 +31,7 @@ #pragma GCC system_header +#include #include_next #endif diff --git a/libstdc++-v3/include/c_global/cassert b/libstdc++-v3/include/c_global/cassert index e555a38..f404560 100644 --- a/libstdc++-v3/include/c_global/cassert +++ b/libstdc++-v3/include/c_global/cassert @@ -40,4 +40,5 @@ #pragma GCC system_header +#include #include diff --git a/libstdc++-v3/include/c_global/cerrno b/libstdc++-v3/include/c_global/cerrno index 7060b1e..9f173c5 100644 --- a/libstdc++-v3/include/c_global/cerrno +++ b/libstdc++-v3/include/c_global/cerrno @@ -38,6 +38,7 @@ #pragma GCC system_header +#include #include #ifndef _GLIBCXX_CERRNO diff --git a/libstdc++-v3/include/c_global/cfloat b/libstdc++-v3/include/c_global/cfloat index 2c4ae28..50f7d3d 100644 --- a/libstdc++-v3/include/c_global/cfloat +++ b/libstdc++-v3/include/c_global/cfloat @@ -38,6 +38,7 @@ #pragma GCC system_header +#include #include #ifndef _GLIBCXX_CFLOAT diff --git a/libstdc++-v3/include/c_global/ciso646 b/libstdc++-v3/include/c_global/ciso646 index 818db67..93fded4 100644 --- a/libstdc++-v3/include/c_global/ciso646 +++ b/libstdc++-v3/include/c_global/ciso646 @
RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI
Steve Ellcey writes: > Here is an update of my MIPS frame header optimization patch. This is > actually only one part of the patch but I would like to get this approved > and checked in before proceeding with the second half. > > The O32 ABI on MIPS requires that calling functions allocate space on the > stack for arguments that are passed in registers. That way if the address > of an argument passed in a register is needed, the called function can write > it out to this space. The new MIPS ABIs have the called functions allocate > this space and they are unaffected by this patch. > > This patch looks at what functions a function calls and if none of them > use the allocated stack space to store arguments then the the calling function > does not allocate this stack space. In general this optimization is not going > to save any time because the calling function will still need to allocate > stack space for the return address if nothing else, but it does save space. > Using a callers allocated space to save the return address if it is not > needed for arguments will be the second part of this optimization. > > There is one major restriction on when this optimization will not happen, and > that is for PIC code. There is something about accessing global variables > in PIC code on MIPS, with its ghost instructions and global symbol accesses, > that conflict with this optimization, so I skip it for PIC code. I think it > only needs to be skipped in functions where the global pointer register is > saved and restored but we don't know which those are until very late in the > compilation (thus the ghost instructions) and that is after we need to > determine whether or not we can do this optimization. OK. If it is ever desirable then considering what to do with PIC code later sounds fine. I suppose we could eventually have it use the caller's argument space to store GP even if GP is needed much like the next round of work will store SP into that space. > I did some testing with this optimization turned on by default at -O2 and > did not have any regressions but this patch does not turn the option on > by default at -O2 (or any other optimization level). While that may be a > reasonable thing to do, personally, I think I would like to get this checked > in and have it available to more users before turning it on by default. OK. I am keen to turn this on as soon as possible though. Perhaps stress it a bit with a round of benchmarks etc and then get it turned on. We have several months before next release so it is a reasonable time to get this kind of thing in and enabled. A few comments below. I found some of the comments a bit hard to parse but have not attempted any rewording. I'd like Catherine to comment too as I have barely any experience at the gimple level to know if this accounts for any necessary subtleties. > diff --git a/gcc/config/mips/frame-header-opt.c > b/gcc/config/mips/frame-header-opt.c > index e69de29..5db5385 100644 > --- a/gcc/config/mips/frame-header-opt.c > +++ b/gcc/config/mips/frame-header-opt.c > +#include "config.h" > +#include "system.h" > +#include "coretypes.h" > +#include "backend.h" > +#include "cfghooks.h" > +#include "tree.h" > +#include "gimple.h" > +#include "rtl.h" > +#include "df.h" > +#include "regs.h" > +#include "insn-config.h" > +#include "conditions.h" > +#include "insn-attr.h" > +#include "recog.h" > +#include "output.h" > +#include "alias.h" > +#include "fold-const.h" > +#include "varasm.h" > +#include "stringpool.h" > +#include "stor-layout.h" > +#include "calls.h" > +#include "flags.h" > +#include "expmed.h" > +#include "dojump.h" > +#include "explow.h" > +#include "emit-rtl.h" > +#include "stmt.h" > +#include "expr.h" > +#include "insn-codes.h" > +#include "optabs.h" > +#include "libfuncs.h" > +#include "reload.h" > +#include "tm_p.h" > +#include "gstab.h" > +#include "debug.h" > +#include "target.h" > +#include "common/common-target.h" > +#include "langhooks.h" > +#include "cfgrtl.h" > +#include "cfganal.h" > +#include "lcm.h" > +#include "cfgbuild.h" > +#include "cfgcleanup.h" > +#include "sched-int.h" > +#include "internal-fn.h" > +#include "gimple-fold.h" > +#include "tree-eh.h" > +#include "gimplify.h" > +#include "diagnostic.h" > +#include "target-globals.h" > +#include "opts.h" > +#include "tree-pass.h" > +#include "context.h" > +#include "cgraph.h" > +#include "builtins.h" > +#include "rtl-iter.h" > +#include "ssa.h" > +#include "gimple-iterator.h" > +#include "gimple-walk.h" > +#include "print-tree.h" > +#include "function.h" This might be worth reducing a bit. I'm not sure all of these look necessary. > +/* Return true if this function will use the stack space allocated by its > + caller or if we cannot determine for certain that it does not. */ > + > +static bool > +needs_stack_space (function *fn) This is about the frame header rather than stack space. I think it would allow a leaf function to use the stack as long as it does not use t
Re: patch for PR61578
On 3 September 2015 at 20:28, Vladimir Makarov wrote: > On 09/03/2015 11:00 AM, Vladimir Makarov wrote: >> >> On 09/02/2015 11:32 AM, Christophe Lyon wrote: >>> >>> Hi Vladimir, >>> >>> >>> >>> On 1 September 2015 at 21:39, Vladimir Makarov >>> wrote: The following patch is for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 The patch was bootstrapped and tested on x86 and x86-64. Committed as rev. 227382. >>> Since this patch, I can see: >>>gcc.dg/vect/slp-perm-5.c (internal compiler error) >>>gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects (internal compiler >>> error) >>> >>> on arm* targets. >>> > Christophe, I can not reproduce it on my arm board (odroid xu4). Could you > provide more info (target, configure options). Thanks. > For instance, you can try --target=arm-none-linux-gnueabihf --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16
