[PR58463][Backport to 4.8] Adjust dumping for ref nodes
Can we please backport this to 4.8 (it will fix PR58463)? I attach Richard's patch to master, let me know if instead I should create one specific for 4.8.1. I tested this against 4.8 branch and everything looks fine. 2013-03-27 Richard Biener PR tree-optimization/56716 * tree-ssa-structalias.c (perform_var_substitution): Adjust dumping for ref nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c Paulo Matos pr58463.patch Description: pr58463.patch
[PR58463] New testcase for pr58463
Please find the patch attached. I have added the test to gcc.c-torture, please let me know if this is not the right place. 2013-09-20 Paulo Matos * gcc.c-torture/pr58463.c: New testcase. Paulo Matos pr58463-testcase.patch Description: pr58463-testcase.patch
RE: [PR58463] New testcase for pr58463
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: 20 September 2013 16:50
> To: Paulo Matos
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PR58463] New testcase for pr58463
>
> That is not the right place (and, note the ChangeLog entry refers to a
> different path than the testcase, and doesn't have space before <.), such
> test should go into gcc.dg/. But, more importantly, the test doesn't
> cleanup after itself. I bet it is enough to test just one dump that
> was actually crashing rather than all of them, so please change that
> to -fdump-tree--all and add corresponding:
> /* { dg-final { cleanup-tree-dump "" } } */
> line. Or, if you really want to test more than one pass dump, add
> the individual -fdump-tree-pass1-all -fdump-tree-otherpass2-all
> and corresponding cleanup-tree-dump lines for each of them. I don't think
> there is a way to get all dumps cleaned up.
>
> Jakub
Thanks for all your comments Jakub, I will format a new patch and submit it
under a new thread.
Paulo Matos
[PATCH middle-end/58463] New testcase
2013-09-20 Paulo Matos * gcc.c-torture/pr58463.c: New testcase for pr58463 Paulo Matos 0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch Description: 0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch
RE: [PATCH middle-end/58463] New testcase
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: 23 September 2013 14:49 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH middle-end/58463] New testcase > > The testcase looks good, the ChangeLog entry is still wrong. Should > be > 2013-09-23 Paulo Matos > > PR middle-end/58463 > * gcc.dg/pr58463.c: New test. > > Note: current date, space between name and e-mail, PR on separate line, > correct path in the entry, end entry with dot. > > Ok with that change (after the corresponding fix is committed > to 4.8 branch, even there). > > Jakub Again, thanks for the helpful comments. This was a bug in 4.8 branch so I guess the testcase should be committed there even if it is in master as well? Also, I suppose now I just wait until someone commits the patch or is there anything else I can do? Paulo
[PATCH] Fix typo in check for null
This is a patch for master, where in number_of_loops, we want to check if the loops (returned by loops_for_fn) is non-null but instead we are using fn, which is the function argument. I haven't opened a bug report, please let me know if I need to do that before submitting patches. 2013-09-23 Paulo Matos * gcc/cfgloop.h (number_of_loops): Fix typo in check for null Paulo Matos 0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch Description: 0001-2013-09-23-Paulo-Matos-pmatos-broadcom.com.patch
RE: [PR58463][Backport to 4.8] Adjust dumping for ref nodes
Ping on this patch. Note I don't have write access. Paulo Matos > -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 23 September 2013 09:00 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PR58463][Backport to 4.8] Adjust dumping for ref nodes > > On Fri, Sep 20, 2013 at 5:39 PM, Paulo Matos wrote: > > > > Can we please backport this to 4.8 (it will fix PR58463)? > > I attach Richard's patch to master, let me know if instead I should create > one specific for 4.8.1. I tested this against 4.8 branch and everything looks > fine. > > Ok. > > Thanks, > Richard. > > > > > 2013-03-27 Richard Biener > > > > PR tree-optimization/56716 > > * tree-ssa-structalias.c (perform_var_substitution): Adjust > > dumping for ref nodes. > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/tree-ssa-structalias.c > > > > Paulo Matos > > > >
RE: [PATCH] Fix typo in check for null
> -Original Message- > From: Marek Polacek [mailto:pola...@redhat.com] > Sent: 24 September 2013 13:57 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix typo in check for null > > On Mon, Sep 23, 2013 at 02:03:02PM +, Paulo Matos wrote: > > This is a patch for master, where in number_of_loops, we want to check if > the loops (returned by loops_for_fn) is non-null but instead we are using fn, > which is the function argument. I haven't opened a bug report, please let me > know if I need to do that before submitting patches. > > > > 2013-09-23 Paulo Matos > > > > * gcc/cfgloop.h (number_of_loops): Fix typo in check for null > > The CL should have two spaces (twice) between the date and the > date and the e-mail, plus please drop the gcc/ prefix and add a full stop at > the end of the sentence. > > Marek Thanks for the comments Marek, will fix it. 2013-09-24 Paulo Matos * cfgloop.h (number_of_loops): Fix typo in check for null.
RE: [PATCH] Fix typo in check for null
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 24 September 2013 10:03 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix typo in check for null > > On Mon, Sep 23, 2013 at 4:03 PM, Paulo Matos wrote: > > This is a patch for master, where in number_of_loops, we want to check if > the loops (returned by loops_for_fn) is non-null but instead we are using fn, > which is the function argument. I haven't opened a bug report, please let me > know if I need to do that before submitting patches. > > Patch is ok. > > Thanks, > Richard. Will submit once I get a reply from the write access request. Cheers, Paulo
RE: [PATCH] Fix typo in check for null
> -Original Message- > From: Marek Polacek [mailto:pola...@redhat.com] > Sent: 24 September 2013 14:52 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix typo in check for null > > On Tue, Sep 24, 2013 at 01:44:30PM +, Paulo Matos wrote: > > Thanks for the comments Marek, will fix it. > > > > 2013-09-24 Paulo Matos > >^^ > Two spaces between name and . Sorry for nitpicking like > this. Thanks! > > Marek It's fine. :) 2013-09-24 Paulo Matos * cfgloop.h (number_of_loops): Fix typo in check for null.
RE: [PING] 3 patches waiting for approval/review
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Andreas Krebbel > Sent: 01 October 2013 10:18 > To: gcc-patches@gcc.gnu.org > Subject: [PING] 3 patches waiting for approval/review > > [RFC] Allow functions calling mcount before prologue to be leaf functions > http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html > > [PATCH] PR57377: Fix mnemonic attribute > http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html > > [PATCH] Doc: Add documentation for the mnemonic attribute > http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01436.html > > Bye, > > -Andreas- > Documentation patch has a typo: + specific checks in e.g. the pipleline description. ^ Cheers, Paulo Matos
Add IDENTIFIER_NODE to description of TARGET_ASM_NAMED_SECTION
As a followup to: http://gcc.gnu.org/ml/gcc/2012-10/msg00276.html 2012-10-19 Paulo Matos * tm.texi, tm.texi.in: Add IDENTIFIER_NODE as an alternative possibility to possible values of decl. Paulo Matos doc.patch Description: doc.patch
[PATCH] Fix PR58682
This is a patch for trunk. It should be backported to 4_8, once it thaws. OK for trunk? 2013-10-10 Paulo Matos PR gcov-profile/58682 * ipa-inline.c (inline_small_functions): Update max_count if new edges are added after inline_call. Paulo Matos pr58682.patch Description: pr58682.patch
RE: [PATCH] Fix PR58682
> -Original Message-
> From: Kyrill Tkachov [mailto:kyrylo.tkac...@arm.com]
> Sent: 10 October 2013 17:15
> To: Paulo Matos
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix PR58682
>
> Hi Paul,
>
> On 10/10/13 17:10, Paulo Matos wrote:
> > - inline_call (edge, true, &new_indirect_edges, &overall_size, true);
> > + if (inline_call (edge, true, &new_indirect_edges, &overall_size,
> true))
> > +{
> > + /* Update max_count if new edges were found */
> Comments end in full stop and two spaces.
>
> Also, a regression test to add to the testsuite would be nice...
>
Thanks, fixed patch attached.
Working on how to submit a testcase for this given that I need to submit 5
files + compile with profile-generate + execute + compile with profile-use to
generate the ICE.
--
Paulo Matos
pr58682.patch
Description: pr58682.patch
[PATCH] Fix comment in tree-prof.exp
Hi, Here's a patch to fix a comment in tree-prof.exp. OK to apply? 2013-10-14 Paulo Matos * testsuite/gcc.dg/tree-prof/tree-prof.exp: Fix comment. -- Paulo Matos tree-prof_comment.patch Description: tree-prof_comment.patch
RE: [PATCH] Fix comment in tree-prof.exp
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Paulo Matos > Sent: 14 October 2013 10:31 > To: gcc-patches@gcc.gnu.org > Subject: [PATCH] Fix comment in tree-prof.exp > > Hi, > > Here's a patch to fix a comment in tree-prof.exp. OK to apply? > > 2013-10-14 Paulo Matos > > * testsuite/gcc.dg/tree-prof/tree-prof.exp: Fix comment. Just noticed a patch by Richard where his changelog didn't include the testsuite/ bit so it should be: 2013-10-14 Paulo Matos * gcc.dg/tree-prof/tree-prof.exp: Fix comment. -- Paulo Matos
RE: [PATCH] Fix PR58682
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Paulo Matos > Sent: 11 October 2013 08:55 > To: Kyrill Tkachov > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH] Fix PR58682 > > > Thanks, fixed patch attached. > Working on how to submit a testcase for this given that I need to submit 5 > files + compile with profile-generate + execute + compile with profile-use to > generate the ICE. > > -- > Paulo Matos OK, testcase generated. Patch attached but there are a few issues and need some comments. * The test includes 6 additional sources and 3 headers. This feels like it pollutes the test directory a lot. Should I at least submit preprocessed sources, so that the headers disappear? * The sources come from CoreMark, does anybody know if their license allows us to include this test in GCC? Also, the code if formatted with CoreMark formatting, should I just use indent to properly format the patch? * Last, but not least, this patch only causes an ICE on 4_8, but not because trunk is fixed. Instead trunk generates edge counts in such a way that they never happen to be higher than max_count when a call is inlined. Is it still worth it to get it into trunk (even though trunk should still be patched?) In 4_8: $ make -j8 RUNTESTFLAGS="tree-prof.exp=core_list_join.c" check-gcc ... FAIL: gcc.dg/tree-prof/core_list_join.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error) === gcc Summary === # of expected passes2 # of unexpected failures1 # of unresolved testcases 1 /projects/firepath_tools1_scratch/pmatos/tmp/GCC/builds/gcc-4_8/gcc/xgcc version 4.8.2 20131010 (prerelease) (GCC) -- Paulo Matos
RE: [PATCH] Fix PR58682
> -Original Message- > From: Kyrill Tkachov [mailto:kyrylo.tkac...@arm.com] > Sent: 14 October 2013 11:44 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org; mikest...@comcast.net > Subject: Re: [PATCH] Fix PR58682 > > I'd think there would be legal issues adding coremark to the testsuite but > I'm > not an expert on this. In any case, I think it's too big of a testcase. Any > way > we could reduce it? > I agree it's too big but since it's necessary to compile/execute/compile it's very hard to reduce it without eliminating the resulting ICE. I will give it a try though. -- Paulo Mato
[PATCH] tree_code_name wrapper
Hi, Find attached the patch for trunk that creates a wrapper for tree_code_name to ensure that no invalid tree code is passed on to tree_code_name. All occurrences of tree_code_name use now use get_tree_code_name. Touched mep, frv, rs6000, iq2000 backends. Comments? Ok to submit? 2013-10-14 Paulo Matos * tree.h: Prototype for new function get_tree_code_name. * tree.c: Make tree_code_name static. Define new function wrapper get_tree_code_name. (dump_tree_statistics, tree_check_failed, tree_not_check_failed, tree_class_check_failed, tree_range_check_failed, tree_not_class_check_failed, omp_clause_check_failed, tree_contains_struct_check_failed, tree_operand_check_failed): Use new wrapper get_tree_code_name instead of calling tree_code_name directly. * tree-vrp.c (dump_asserts_for): Use new wrapper get_tree_code_name. * tree-dump.c (dequeue_and_dump): Use new wrapper get_tree_code_name. * tree-pretty-print.c (do_niy, dump_generic_node): Use new wrapper get_tree_code_name. * tree-pretty-print.h (pp_unsupported_tree): Use new wrapper get_tree_code_name. * cp/error.c (code_to_string): Use new wrapper get_tree_code_name. * cp/cxx-pretty-print.c (pp_cxx_assignment_operator): Use new wrapper get_tree_code_name. * cp/pt.c (tsubst): Use new wrapper get_tree_code_name. * cp/semantics.c (cxx_eval_constant_expression, potential_constant_expression_1): Use new wrapper get_tree_code_name. * cp/mangle.c (MANGLE_TRACE_TREE, dump_substitution_candidates, add_substitution, find_substitution): Use new wrapper get_tree_code_name. * lto-streamer-out.c (lto_write_tree, DFS_write_tree): Use new wrapper get_tree_code_name. * tree-ssa-dom.c (print_expr_hash_elt): Use new wrapper get_tree_code_name. * gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs, dump_ternary_rhs, dump_gimple_assign, dump_gimple_cond, dump_gimple_omp_for): Use new wrapper get_tree_code_name. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Use new wrapper get_tree_code_name. * tree-ssa-pre.c (print_pre_expr): Use new wrapper get_tree_code_name. * ipa-prop.c (ipa_print_node_jump_functions_for_edge): Use new wrapper get_tree_code_name. * print-tree.c (print_node_brief, print_node): Use new wrapper get_tree_code_name. * gimple.c (gimple_check_failed): Use new wrapper get_tree_code_name. * tree-core.h: Remove extern declaration of tree_code_name. * config/frv/frv.c (frv_init_cumulative_args): Use new wrapper get_tree_code_name. * config/mep/mep.c (mep_validate_vliw): Use new wrapper get_tree_code_name. * config/iq2000/iq2000.c (init_cumulative_args): Use new wrapper get_tree_code_name. * config/rs6000/rs6000.c (init_cumulative_args): Use new wrapper get_tree_code_name. * lto-streamer.c (lto_tag_name, print_lto_report): Use new wrapper get_tree_code_name. -- Paulo Matos tree_code_name.patch Description: tree_code_name.patch
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Paulo Matos > Sent: 14 October 2013 16:43 > To: gcc-patches@gcc.gnu.org > Subject: [PATCH] tree_code_name wrapper > > Hi, > > Find attached the patch for trunk that creates a wrapper for tree_code_name > to ensure that no invalid tree code is passed on to tree_code_name. All > occurrences of tree_code_name use now use get_tree_code_name. Touched mep, > frv, rs6000, iq2000 backends. > > Comments? Ok to submit? > > Forgot to mention that I ran the testsuite on x86_64-unknown-linux-gnu and there was no change. -- Paulo Matos
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 15 October 2013 10:12 > To: Paolo Carlini > Cc: Paulo Matos; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > > Apart from this please make sure to properly use tabs to indent: > > @@ -9098,7 +9098,8 @@ dump_tree_statistics (void) >fprintf (stderr, "Code Nodes\n"); >fprintf (stderr, "\n"); >for (i = 0; i < (int) MAX_TREE_CODES; i++) > - fprintf (stderr, "%-20s %7d\n", tree_code_name[i], > tree_code_counts[i]); > + fprintf (stderr, "%-20s %7d\n", get_tree_code_name ((enum tree_code) > i), > + tree_code_counts[i]); >fprintf (stderr, "\n"); > > (maybe in other places, too). > > Also we write the shorter > > * tree-vrp.c (dump_asserts_for): Use new wrapper get_tree_code_name. > * tree-dump.c (dequeue_and_dump): Likewise. > > instead of duplicating the same sentence. > > Ok with that changes. > Thanks, regarding the indentation I was convinced we used 2 space indentation with maximum line length of 80 characters. I am not sure what the problem is with the hunk you copied above. Should I also submit several change logs to gcc-patches like: For gcc/ 2013-10-15 Paulo Matos * ... For gcc/cp/ 2013-10-15 Paulo Matos * ... -- Paulo Matos
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: 15 October 2013 10:51 > To: Paulo Matos > Cc: Richard Biener; Paolo Carlini; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > On Tue, Oct 15, 2013 at 09:42:17AM +, Paulo Matos wrote: > > Thanks, regarding the indentation I was convinced we used 2 space > > indentation with maximum line length of 80 characters. > > We do, however 8 consecutive spaces in the indentation should be always > replaced by a tab. > This means that every sequence of 8 spaces should be converted into tabs? So, if we indent something 4 times, that becomes a tab instead of 4 times 2 spaces. Just to confirm so I can setup my emacs to use this. Thanks, -- Paulo Matos
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Richard Biener > Sent: 15 October 2013 14:34 > To: Paulo Matos > Cc: Jakub Jelinek; Paolo Carlini; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > On Tue, Oct 15, 2013 at 3:19 PM, Paulo Matos wrote: > >> -Original Message- > >> From: Jakub Jelinek [mailto:ja...@redhat.com] > >> Sent: 15 October 2013 10:51 > >> To: Paulo Matos > >> Cc: Richard Biener; Paolo Carlini; gcc-patches@gcc.gnu.org > >> Subject: Re: [PATCH] tree_code_name wrapper > >> > >> On Tue, Oct 15, 2013 at 09:42:17AM +, Paulo Matos wrote: > >> > Thanks, regarding the indentation I was convinced we used 2 space > >> > indentation with maximum line length of 80 characters. > >> > >> We do, however 8 consecutive spaces in the indentation should be always > >> replaced by a tab. > >> > > > > This means that every sequence of 8 spaces should be converted into tabs? > So, if we indent something 4 times, that becomes a tab instead of 4 times 2 > spaces. > > Correct. > > Richard. > Thanks. Updated patch attached. Ok to submit? 2013-10-15 Paulo Matos gcc/ * tree-core.h: Remove extern declaration of tree_code_name. * tree.h: Prototype for new function get_tree_code_name. * tree.c: Make tree_code_name static. Define new function wrapper get_tree_code_name. (dump_tree_statistics, tree_check_failed, tree_not_check_failed, tree_class_check_failed, tree_range_check_failed, tree_not_class_check_failed, omp_clause_check_failed, tree_contains_struct_check_failed, tree_operand_check_failed): Use new wrapper get_tree_code_name instead of calling tree_code_name directly. * tree-vrp.c (dump_asserts_for): Likewise. * tree-dump.c (dequeue_and_dump): Likewise. * tree-pretty-print.c (do_niy, dump_generic_node): Likewise. * tree-pretty-print.h (pp_unsupported_tree): Likewise. * lto-streamer-out.c (lto_write_tree, DFS_write_tree): Likewise. * tree-ssa-dom.c (print_expr_hash_elt): Likewise. * gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs, dump_ternary_rhs, dump_gimple_assign, dump_gimple_cond, dump_gimple_omp_for): Likewise. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Likewise. * tree-ssa-pre.c (print_pre_expr): Likewise. * ipa-prop.c (ipa_print_node_jump_functions_for_edge): Likewise. * print-tree.c (print_node_brief, print_node): Likewise. * gimple.c (gimple_check_failed): Likewise. * lto-streamer.c (lto_tag_name, print_lto_report): Likewise. gcc/cp/ * error.c (code_to_string): Use new wrapper get_tree_code_name. * cxx-pretty-print.c (pp_cxx_assignment_operator): Likewise. * pt.c (tsubst): Likewise. * semantics.c (cxx_eval_constant_expression, potential_constant_expression_1): Likewise. * mangle.c (MANGLE_TRACE_TREE, dump_substitution_candidates, add_substitution, find_substitution): Likewise. gcc/config/ * frv/frv.c (frv_init_cumulative_args): Use new wrapper get_tree_code_name. * mep/mep.c (mep_validate_vliw): Likewise. * iq2000/iq2000.c (init_cumulative_args): Likewise. * rs6000/rs6000.c (init_cumulative_args): Likewise. tree_code_name-v2.patch Description: tree_code_name-v2.patch
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Jakub Jelinek > Sent: 15 October 2013 15:45 > To: Paulo Matos > Cc: Richard Biener; Paolo Carlini; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > The ChangeLog is still wrong: > OK, sorry. If this is ok now I will open a bottle of champagne. Thank you all for your time reviewing this. Ok to submit? 2013-10-15 Paulo Matos gcc/ * tree-core.h (tree_code_name): Remove. * tree.h (get_tree_code_name): New prototype. * tree.c (tree_code_name): Make static. (get_tree_code_name): New function. (dump_tree_statistics, tree_check_failed, tree_not_check_failed, tree_class_check_failed, tree_range_check_failed, tree_not_class_check_failed, omp_clause_check_failed, tree_contains_struct_check_failed, tree_operand_check_failed): Use new wrapper get_tree_code_name instead of calling tree_code_name directly. * tree-vrp.c (dump_asserts_for): Likewise. * tree-dump.c (dequeue_and_dump): Likewise. * tree-pretty-print.c (do_niy, dump_generic_node): Likewise. * tree-pretty-print.h (pp_unsupported_tree): Likewise. * lto-streamer-out.c (lto_write_tree, DFS_write_tree): Likewise. * tree-ssa-dom.c (print_expr_hash_elt): Likewise. * gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs, dump_ternary_rhs, dump_gimple_assign, dump_gimple_cond, dump_gimple_omp_for): Likewise. * tree-vect-data-refs.c (vect_create_data_ref_ptr): Likewise. * tree-ssa-pre.c (print_pre_expr): Likewise. * ipa-prop.c (ipa_print_node_jump_functions_for_edge): Likewise. * print-tree.c (print_node_brief, print_node): Likewise. * gimple.c (gimple_check_failed): Likewise. * lto-streamer.c (lto_tag_name, print_lto_report): Likewise. * config/frv/frv.c (frv_init_cumulative_args): Likewise. * config/mep/mep.c (mep_validate_vliw): Likewise. * config/iq2000/iq2000.c (init_cumulative_args): Likewise. * config/rs6000/rs6000.c (init_cumulative_args): Likewise. gcc/cp/ * error.c (code_to_string): Use new wrapper get_tree_code_name. * cxx-pretty-print.c (pp_cxx_assignment_operator): Likewise. * pt.c (tsubst): Likewise. * semantics.c (cxx_eval_constant_expression, potential_constant_expression_1): Likewise. * mangle.c (MANGLE_TRACE_TREE, dump_substitution_candidates, add_substitution, find_substitution): Likewise. -- Paulo Matos
RE: [PATCH] Fix PR58682
> -Original Message- > From: Mike Stump [mailto:mikest...@comcast.net] > Sent: 14 October 2013 20:46 > To: Kyrill Tkachov > Cc: Paulo Matos; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix PR58682 > > In this case, I've reviewed the license I suspect you have, and I suspect it > does > not have a grant of enough rights to allow it to be contributed to gcc. > Assuming we cannot get the testcase into GCC, can we get the patch into trunk? If you try it locally you can definitely see the ICE and that the patch fixes it. -- Paulo Matos
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: Paolo Carlini [mailto:paolo.carl...@oracle.com] > Sent: 16 October 2013 12:54 > To: Richard Biener; Paulo Matos > Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > Hi, > > bootstrap is currently broken, I'm going to test and commit the below if > everything goes well. > > Thanks, > Paolo. > > /// Please do. I can't understand how I compiled and ran the tests successfully with that issue. Paulo Matos
RE: [PATCH] tree_code_name wrapper
> -Original Message- > From: Paolo Carlini [mailto:paolo.carl...@oracle.com] > Sent: 16 October 2013 12:54 > To: Richard Biener; Paulo Matos > Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] tree_code_name wrapper > > Hi, > > bootstrap is currently broken, I'm going to test and commit the below if > everything goes well. > Sorry all, it might be because I did --enable-languages=c and that was in the C++ part, even though with g++ being used to bootstrap I would have expected it to break the build anyway. Thanks Paolo for fixing it. -- Paulo Matos
RE: Teaching emacs about GCC coding conventions (was Re: [PATCH] tree_code_name wrapper)
For me it worked with: (add-hook 'c-mode-hook 'gcc-c-mode) (defun gcc-c-mode() ;; set gnu style. (c-set-style "gnu") ;; TAB offset set to 2 (setq c-basic-offset 2) ;; Tabs should be 8 (setq indent-tabs-mode t) ) Then I simply edit all my software as if it was GCC (haven't found a way to say : 'only use this for GCC sources'). I am just missing a good mode for .md files. Paulo Matos > -Original Message- > From: David Malcolm [mailto:dmalc...@redhat.com] > Sent: 16 October 2013 16:33 > To: Paulo Matos > Cc: Jakub Jelinek; Richard Biener; Paolo Carlini; gcc-patches@gcc.gnu.org > Subject: Teaching emacs about GCC coding conventions (was Re: [PATCH] > tree_code_name wrapper) > > On Tue, 2013-10-15 at 13:19 +, Paulo Matos wrote: > > > -Original Message- > > > From: Jakub Jelinek [mailto:ja...@redhat.com] > > > Sent: 15 October 2013 10:51 > > > To: Paulo Matos > > > Cc: Richard Biener; Paolo Carlini; gcc-patches@gcc.gnu.org > > > Subject: Re: [PATCH] tree_code_name wrapper > > > > > > On Tue, Oct 15, 2013 at 09:42:17AM +, Paulo Matos wrote: > > > > Thanks, regarding the indentation I was convinced we used 2 space > > > > indentation with maximum line length of 80 characters. > > > > > > We do, however 8 consecutive spaces in the indentation should be always > > > replaced by a tab. > > > > > > > This means that every sequence of 8 spaces should be converted into tabs? > > So, > if we indent something 4 times, that becomes a tab instead of 4 times 2 > spaces. > > > > Just to confirm so I can setup my emacs to use this. > > Probably a silly question, but what's the invocation in emacs to do > this, and is it possible to set up the source tree so that this happens > automatically for everyone? > > (I've been using whitespace-mode and manually copying-and-pasting tab > characters, which is clearly suboptimal). >
RE: Teaching emacs about GCC coding conventions (was Re: [PATCH] tree_code_name wrapper)
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Mike Stump > Sent: 16 October 2013 23:06 > To: Paulo J.Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: Teaching emacs about GCC coding conventions (was Re: [PATCH] > tree_code_name wrapper) > > First, we like to wait and let patches bake on mainline before considering > back > porting, this has no bake time yet in our tree. Second, only patches that > impact > quality enough should be back ported. I tend to think that this one does not > impact quality enough to worry about. Also, you should develop on trunk, not > 4_8. Arguably, I would say no. Now, a release manager can always review > approve > it; it should be very, very low risk. > Makes sense. Thanks for the clarification. -- Paulo Matos
RE: [PATCH] Fix PR58682
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Paulo Matos > Sent: 16 October 2013 09:42 > To: Mike Stump; Kyrill Tkachov > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH] Fix PR58682 > > > -Original Message- > > From: Mike Stump [mailto:mikest...@comcast.net] > > Sent: 14 October 2013 20:46 > > To: Kyrill Tkachov > > Cc: Paulo Matos; gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH] Fix PR58682 > > > > In this case, I've reviewed the license I suspect you have, and I suspect it > does > > not have a grant of enough rights to allow it to be contributed to gcc. > > > > Assuming we cannot get the testcase into GCC, can we get the patch into trunk? > If you try it locally you can definitely see the ICE and that the patch fixes > it. > ping. Paulo Matos
RE: [PATCH] Fix PR58682
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 18 October 2013 13:12
> To: Paulo Matos
> Cc: Mike Stump; Kyrill Tkachov; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix PR58682
>
> Please re-post the latest version of the patch and CC Honza.
>
> Richard.
>
Patch attached. OK to submit?
Bootstrapped x86_64-unknown-linux-gnu.
2013-10-21 Paulo Matos
* ipa-inline.c (inline_small_functions): Update max_count if new edges
are found after inlining.
--
Paulo Matos
pr58682.patch
Description: pr58682.patch
RE: [PATCH] Fix PR58682
> -Original Message- > From: Jan Hubicka [mailto:hubi...@ucw.cz] > Sent: 21 October 2013 13:21 > To: Paulo Matos > Cc: Richard Biener; Mike Stump; Kyrill Tkachov; gcc-patches@gcc.gnu.org; Jan > Hubicka (hubi...@ucw.cz) > Subject: Re: [PATCH] Fix PR58682 > > This won't work - the max_count is there to get things correctly scaled by > badness calculation. > Changing max_count would mean the need to recompute all badnesses in the > fibheap > keys. > I would just cap the edge_count in badness calculation. > > Honza > Makes sense. Thanks for the comment. I have created a new patch. Now attached. 2013-10-21 Paulo Matos * ipa-inline.c (edge_badness): Cap edge->count at max_count for badness calculations. -- PMatos pr58682-v2.patch Description: pr58682-v2.patch
[PATCH] fix combine.c:reg_nonzero_bits_for_combine where last_set_mode is narrower than mode
Please find patch for bug discussed in: http://gcc.gnu.org/ml/gcc/2013-11/msg00571.html Bootstrapped successfully in x86_64. 2013-11-29 Paulo Matos Eric Botcazou * combine.c (reg_nonzero_bits_for_combine): Apply mask transformation as applied to nonzero_sign_valid fixing bug when last_set_mode has less precision than mode. OK to submit? Paulo Matos reg_nonzero_bits_for_combine.patch Description: reg_nonzero_bits_for_combine.patch
Re: [PATCH] fix combine.c:reg_nonzero_bits_for_combine where last_set_mode is narrower than mode
On 30/11/13 11:38, Eric Botcazou wrote: 2013-11-29 Paulo Matos Eric Botcazou * combine.c (reg_nonzero_bits_for_combine): Apply mask transformation as applied to nonzero_sign_valid fixing bug when last_set_mode has less precision than mode. Applied, thanks. Excellent. :) Thanks for submitting. -- PMatos
[PATCH] Fix typo
OK to commit?
2015-05-10 Paulo Matos
* configure.ac: Fix typo.
* configure: Regenerate.
diff --git a/configure b/configure
index a3f66ba..8ee279f 100755
--- a/configure
+++ b/configure
@@ -7423,7 +7423,7 @@ fi
# multilib is not explicitly enabled.
case "$target:$have_compiler:$host:$target:$enable_multilib" in
x86_64-*linux*:yes:$build:$build:)
-# Make sure we have a developement environment that handles 32-bit
+# Make sure we have a development environment that handles 32-bit
dev64=no
echo "int main () { return 0; }" > conftest.c
${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
@@ -7434,7 +7434,7 @@ case "$target:$have_compiler:$host:$target:
$enable_multilib" in
fi
rm -f conftest*
if test x${dev64} != xyes ; then
- as_fn_error "I suspect your system does not have 32-bit
developement libraries (libc and headers). If you have them, rerun
configure with --enable-multilib. If you do not have them, and want to
build a 64-bit-only compiler, rerun configure with --disable-multilib."
"$LINENO" 5
+ as_fn_error "I suspect your system does not have 32-bit
development libraries (libc and headers). If you have them, rerun
configure with --enable-multilib. If you do not have them, and want to
build a 64-bit-only compiler, rerun configure with --disable-multilib."
"$LINENO" 5
fi
;;
esac
diff --git a/configure.ac b/configure.ac
index 987dfab..4081fb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3063,7 +3063,7 @@ fi
# multilib is not explicitly enabled.
case "$target:$have_compiler:$host:$target:$enable_multilib" in
x86_64-*linux*:yes:$build:$build:)
-# Make sure we have a developement environment that handles 32-bit
+# Make sure we have a development environment that handles 32-bit
dev64=no
echo "int main () { return 0; }" > conftest.c
${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
@@ -3074,7 +3074,7 @@ case "$target:$have_compiler:$host:$target:
$enable_multilib" in
fi
rm -f conftest*
if test x${dev64} != xyes ; then
- AC_MSG_ERROR([I suspect your system does not have 32-bit
developement libraries (libc and headers). If you have them, rerun
configure with --enable-multilib. If you do not have them, and want to
build a 64-bit-only compiler, rerun configure with --disable-multilib.])
+ AC_MSG_ERROR([I suspect your system does not have 32-bit
development libraries (libc and headers). If you have them, rerun
configure with --enable-multilib. If you do not have them, and want to
build a 64-bit-only compiler, rerun configure with --disable-multilib.])
fi
;;
esac
[PATCH] Add myself to MAINTAINERS
Somehow I never added myself to the MAINTAINERS file. Apologies for that. OK to commit? 2015-05-10 Paulo Matos * MAINTAINERS: Add myself as commit after approval. diff --git a/MAINTAINERS b/MAINTAINERS index 7dc4c8f..c5d6c99 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -483,6 +483,7 @@ David Malcolm Mikhail Maltsev Simon Martin Ranjit Mathew +Paulo Matos Michael Matz Greg McGary Roland McGrath
Re: [PATCH] Fix typo
On Sun, 10 May 2015 22:07:53 -0600, Jeff Law wrote: > On 05/10/2015 03:00 PM, Paulo Matos wrote: > Yes. This would fall under the obvious rule and can be committed > without waiting for approvals. > > jeff Thanks. Committed. -- Paulo Matos
Re: [PATCH] Add myself to MAINTAINERS
On Sun, 10 May 2015 21:08:04 +, Paulo Matos wrote: > Somehow I never added myself to the MAINTAINERS file. > Apologies for that. OK to commit? > > 2015-05-10 Paulo Matos > > * MAINTAINERS: Add myself as commit after approval. > > diff --git a/MAINTAINERS b/MAINTAINERS index 7dc4c8f..c5d6c99 100644 --- > a/MAINTAINERS +++ b/MAINTAINERS @@ -483,6 +483,7 @@ David Malcolm > > Mikhail Maltsev > > Simon Martin > > Ranjit Mathew > +Paulo Matos > Michael Matz > Greg McGary > Roland McGrath Committed as obvious. -- Paulo Matos
[PATCH] Improve patch regexp to ensure that numbers like 3000 do not match
2012-10-19 Paulo Matos * gcc/testsuite/gcc.dg/tree-ssa/vector-3.c: Ensure we are looking for 0.0 and not for something like 3000, which matches current 0.0 pattern. 0001-Improve-regexp-to-ensure-that-numbers-like-3000-do-n.patch Description: 0001-Improve-regexp-to-ensure-that-numbers-like-3000-do-n.patch
[PATCH] Fix documentation typo: pr50345
Fixes an LTO documentation typo in gcc internals. 08-05-2013 Paulo Matos * gcc/doc/lto.texi: Fix typo. Paulo Matos lto_docfix_pr50345.patch Description: lto_docfix_pr50345.patch
[PATCH] Vector mode addresses
As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. Bootstrapped and tested on x86_64-unknown-linux-gnu. 2014-01-30 Paulo Matos * simplify-rtx.c (simplify_subreg): Do not adjust address if memory address has vector mode. OK to submit? Paulo Matos vector-mode.patch Description: vector-mode.patch
RE: [PATCH] Vector mode addresses
> -Original Message- > From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > Sent: 30 January 2014 12:43 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Vector mode addresses > > Paulo Matos writes: > > As a followup of the thread: > > http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html > > > > consider the attached patch for submission. It fixes an ICE in case > > you try to use vector mode addresses and do not have it as mode > > dependent target hook. As discussed in the thread adding > > VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard > > S. mentioned it's more general to patch GCC up. > > But like I said, I think the VECTOR_MODE_P check should be in > mode_dependent_address_p (recog.c) rather than here. If vector > addresses are supported then they are mode-dependent, since the > number of elements in the address mode must match the number of > elements in the MEM mode. Have I misunderstood what you said: "If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there." From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: "I'd just prefer it to be in generic code because I think it's a target-independent rule." Apologies if I completely misunderstood you. > > Thanks, > Richard
Re: [PATCH] Vector mode addresses
On 30/01/14 14:01, Richard Biener wrote: I'm curious on where you are seeing MEMs with a vector mode address. What does that MEM even mean? Yes, it looks strange but it was the way we came up with to implement an instruction that loads from a pair of addresses. From what I wrote previously to Richard. "We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index. So, r1 <- [r0, r2] means: low(r1) = [r0 + low(r2)] high(r1) = [r0 + high(r2)]" From the referenced mail: new_rtx: (mem:V4SI (plus:V4SI (vec_concat:V4SI (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0])) (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0]))) that should be invalid and somehow lacks the subreg:DI. The bug is where that got lost. I don't think it got lost. GCC was trying to simplify it. That's why my patch was in simplify_subreg. GCC was trying to simplify a subreg in DImode with this mem rtx as SUBREG_REG and offset 8. -- Paulo Matos
Re: [PATCH] Vector mode addresses
On 30/01/14 17:10, Richard Sandiford wrote: Right, in the context: Just in case: the point I was trying to make in the second paragraph was that the code in the patch only triggers (as you say) because the address isn't seen as mode-dependent. But this kind of address does look mode-dependent to me, since it only works for MEM modes that have the same number of elements as the index vector. So this does sound like a case where mode_dependent_address_p ought to return true. If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. http://gcc.gnu.org/ml/gcc/2014-01/msg00242.html I.e. there == mode_dependent_address_p (defined in recog.c). From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: "I'd just prefer it to be in generic code because I think it's a target-independent rule." No, I meant that I'd prefer it to be done in the target-independent mode_dependent_address_p function. This was in response to: Well, isn't it the case that a mem with vector mode is always mode dependent, in which case adding VECTOR_MODE_P to mode-dependent target hook would be enough making the patch not so useful? http://gcc.gnu.org/ml/gcc/2014-01/msg00248.html where it sounded like you were instead going to add the check to your target's TARGET_MODE_DEPENDENT_ADDRESS_P hook. I don't think it makes sense to defer the VECTOR_MODE_P check to the target hook since I don't know how target-independent code could attach any meaning to something like (mem:V4HI (reg:V4SI ...)) -> (mem:DI (reg:V4SI ...)). Again, this is all on the basis that vector-mode addresses really are supported. Now I understand what you mean. I was pretty confused by what you meant by target-independent mode_dependent_address_p because initially I had the feeling that targetm.mode_dependent_address_p was being called in simplify_rtx but there's actually a mode_dependent_address_p in recog.c and there is where you suggested to add the check _if_ vector modes are supported. Got it. I apologize for my misunderstanding and thank you for your patience. -- Paulo Matos Thanks, Richard
Re: [PATCH] Vector mode addresses
On 30/01/14 20:47, Jakub Jelinek wrote: On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote: Yes, it looks strange but it was the way we came up with to implement an instruction that loads from a pair of addresses. From what I wrote previously to Richard. "We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index. So, r1 <- [r0, r2] means: low(r1) = [r0 + low(r2)] high(r1) = [r0 + high(r2)]" That sounds like gather instruction e.g. i?86 AVX2/AVX512F has. I don't like using vector mode for the address though, i?86 uses UNSPECs and IMNSHO you should too. Or express it as vec_concat of two MEM loads where address of each one will be the base + vec_select of the vector register. Jakub I will take a closer look at our pattern and how i?86 implements it. Thanks for the advice. Paulo Matos
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 05/03/2014 11:51, Richard Biener wrote: On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres wrote: Revision 208312 causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Uhm. pointer comparison against double_type_node ... I'd say we want to revert the patch. Paulo, please do that. Let's do the alternate approach of marking -fshort-double eligible for LTO as well and handle it there properly. Sure, I will prepare a new patch and post it for approval by the end of the day. Apologies for the regression. -- Paulo Matos
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 06/03/2014 11:19, Richard Biener wrote: I have reverted the patch for now. Richard. That's fine Richard, thanks. I got stuck with another issue in the meantime but I will look at it again very soon. -- Paulo Matos
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 06/03/14 11:19, Richard Biener wrote:
On Wed, Mar 5, 2014 at 12:55 PM, Paulo Matos wrote:
On 05/03/2014 11:51, Richard Biener wrote:
On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres
wrote:
Revision 208312 causes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
Uhm. pointer comparison against double_type_node ...
I'd say we want to revert the patch. Paulo, please do that. Let's
do the alternate approach of marking -fshort-double eligible for LTO
as well and handle it there properly.
Sure, I will prepare a new patch and post it for approval by the end of the
day.
Apologies for the regression.
I have reverted the patch for now.
Richard.
Please find new patch attached. I have enabled LTO for short-double and
passed flag_short_double to build_common_tree_nodes.
I have tested this for C on powerpc-eabipse (target for which we are
fixing pr55113), and C/Fortran on a x86_64. Saw no regressions.
OK to commit?
gcc/c-family/
2014-03-06 Paulo Matos
* c.opt: Enable LTO FE for fshort-double.
gcc/lto/
2014-03-06 Paulo Matos
* lto-lang.c (lto_init): Pass flag_short_double to
build_common_tree_nodes.
gcc/testsuite/
2014-03-06 Paulo Matos
* gcc.dg/lto/pr55113_0.c: New testcase.
--
Paulo Matos
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 208385)
+++ gcc/c-family/c.opt (working copy)
@@ -1141,7 +1141,7 @@ C++ ObjC++ Optimization Var(flag_rtti) I
Generate run time type descriptor information
fshort-double
-C ObjC C++ ObjC++ Optimization Var(flag_short_double)
+C ObjC C++ ObjC++ LTO Optimization Var(flag_short_double)
Use the same size for double as for float
fshort-enums
Index: gcc/lto/lto-lang.c
===
--- gcc/lto/lto-lang.c (revision 208385)
+++ gcc/lto/lto-lang.c (working copy)
@@ -1158,7 +1158,7 @@ lto_init (void)
flag_generate_lto = (flag_wpa != NULL);
/* Create the basic integer types. */
- build_common_tree_nodes (flag_signed_char, /*short_double=*/false);
+ build_common_tree_nodes (flag_signed_char, flag_short_double);
/* The global tree for the main identifier is filled in by
language-specific front-end initialization that is not run in the
Index: gcc/testsuite/gcc.dg/lto/pr55113_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr55113_0.c (revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr55113_0.c (working copy)
@@ -0,0 +1,13 @@
+/* PR 55113 */
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -flto -fshort-double -O0 } } }*/
+/* { dg-skip-if "PR60410" { { x86_64-*-* i?86-*-* } && lp64 } } */
+
+int
+main(void)
+{
+ float a = 1.0;
+ float b = 2.0;
+ double f = a + b * 1e-12;
+ return (int)f - 1;
+}
Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc
On 07/03/14 09:03, Richard Biener wrote: Btw, can you check the attached as well? It makes sure all TUs have -fshort-double set consistently and it automatically enables it at link-time, not allowing to override the setting. If it works for you please check it in, too. (I can't really test it because -fshort-double brokeness on x86_64). I have tested it and everything looks fine. I have now committed all the code and testcase. Hopefully it's now sorted. Thanks for your help, Paulo Matos Thanks, Richard. -- PMatos
Fix PR55761
2012-12-20 Paulo Matos PR tree-optimization/55761 * tree-tailcall.c (process_assignment): Use build_int_cst only for integral types, for every other type that managed to pass all conditions use fold_build1. pr55761.patch Description: pr55761.patch
RE: Fix PR55761
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 20 December 2012 16:13 > To: Paulo Matos > Cc: gcc-patches@gcc.gnu.org > Subject: Re: Fix PR55761 > > On Thu, Dec 20, 2012 at 5:06 PM, Paulo Matos wrote: > > 2012-12-20 Paulo Matos > > > > PR tree-optimization/55761 > > * tree-tailcall.c (process_assignment): Use build_int_cst only for > integral types, > > for every other type that managed to pass all conditions use > fold_build1. > > case NEGATE_EXPR: >if (FLOAT_TYPE_P (TREE_TYPE (op0))) > *m = build_real (TREE_TYPE (op0), dconstm1); > + else if (INTEGRAL_TYPE_P (TREE_TYPE (non_ass_var))) > +*m = build_int_cst (TREE_TYPE (non_ass_var), -1); >else > -*m = build_int_cst (TREE_TYPE (op0), -1); > +*m = fold_build1 (NEGATE_EXPR, TREE_TYPE (non_ass_var), > non_ass_var); > > looks bogus (op0 vs. non_ass_var). Correct. My mistake applying same MINUS_EXPR pattern to NEGATE_EXPR case. > I'd rather use fold_unary here as I'm not > sure if callers handle a NEGATE_EXPR in *m. And I'd use that > unconditionally, > this last case looks like it will have very weak testing coverage. Thus, > >*m = fold_unary (NEGATE_EXPR, TREE_TYPE (op0), op0); > > and also in the MINUS_EXPR case. > Sounds reasonable. That would simplify it, it seems. Will fix patch and replace it in PR. > Richard.
