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 pa...@matos-sorge.com * 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 dmalc...@redhat.com Mikhail Maltsev malts...@gmail.com Simon Martin simar...@users.sourceforge.net Ranjit Mathew rmat...@hotmail.com +Paulo Matospa...@matos-sorge.com Michael Matz m...@suse.de Greg McGaryg...@gnu.org Roland McGrath rol...@hack.frob.com Committed as obvious. -- Paulo Matos
[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 pa...@matos-sorge.com * 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 dmalc...@redhat.com Mikhail Maltsev malts...@gmail.com Simon Martin simar...@users.sourceforge.net Ranjit Mathew rmat...@hotmail.com +Paulo Matospa...@matos-sorge.com Michael Matz m...@suse.de Greg McGaryg...@gnu.org Roland McGrath rol...@hack.frob.com
[PATCH] Fix typo
OK to commit?
2015-05-10 Paulo Matos pa...@matos-sorge.com
* 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
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
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 05/03/2014 11:51, Richard Biener wrote: On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres domi...@lps.ens.fr 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
[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 pma...@broadcom.com * 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 pma...@broadcom.com 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] 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 pma...@broadcom.com Eric Botcazou ebotca...@adacore.com * 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 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 pma...@broadcom.com Eric Botcazou ebotca...@adacore.com * 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 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 pma...@broadcom.com * 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 pma...@broadcom.com * ipa-inline.c (edge_badness): Cap edge-count at max_count for badness calculations. -- PMatos pr58682-v2.patch Description: pr58682-v2.patch
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: 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: 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. 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: [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 pma...@broadcom.com * ... For gcc/cp/ 2013-10-15 Paulo Matos pma...@broadcom.com * ... -- 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 pma...@broadcom.com 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 pma...@broadcom.com 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 pma...@broadcom.com 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
[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 pma...@broadcom.com * 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 pma...@broadcom.com * 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 pma...@broadcom.com * 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 pma...@broadcom.com * 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] 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 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 pma...@broadcom.com 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: [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
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 pma...@broadcom.com 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 rguent...@suse.de 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 pma...@broadcom.com * 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 pma...@broadcom.com * 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 pma...@broadcom.com 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 pma...@broadcom.com ^^ Two spaces between name and e-mail. Sorry for nitpicking like this. Thanks! Marek It's fine. :) 2013-09-24 Paulo Matos pma...@broadcom.com * cfgloop.h (number_of_loops): Fix typo in check for null.
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-whateverpass-all and add corresponding:
/* { dg-final { cleanup-tree-dump whateverpass } } */
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 pma...@broadcom.com * 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 pma...@broadcom.com 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 pma...@broadcom.com * 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
[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 rguent...@suse.de 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 pma...@broadcom.com * gcc.c-torture/pr58463.c: New testcase. Paulo Matos pr58463-testcase.patch Description: pr58463-testcase.patch
[PATCH] Fix documentation typo: pr50345
Fixes an LTO documentation typo in gcc internals. 08-05-2013 Paulo Matos pma...@broadcom.com * gcc/doc/lto.texi: Fix typo. Paulo Matos lto_docfix_pr50345.patch Description: lto_docfix_pr50345.patch
Fix PR55761
2012-12-20 Paulo Matos pma...@broadcom.com 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 pma...@broadcom.com wrote: 2012-12-20 Paulo Matos pma...@broadcom.com 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.
[PATCH] Improve patch regexp to ensure that numbers like 3000 do not match
2012-10-19 Paulo Matospma...@broadcom.com * 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
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 Matospma...@broadcom.com * tm.texi, tm.texi.in: Add IDENTIFIER_NODE as an alternative possibility to possible values of decl. Paulo Matos doc.patch Description: doc.patch
