Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote: > Hi Jakub, > > My -fopt-info pass filtering patch > (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being > reviewed and I hope to get this in by Nov. 5 for inclusion in gcc > 4.8.0. I just committed -fopt-info pass filtering patch as r193061. Thanks, Sharad > Thanks, > Sharad > > On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek wrote: >> Status >> == >> >> I'd like to close the stage 1 phase of GCC 4.8 development >> on Monday, November 5th. If you have still patches for new features you'd >> like to see in GCC 4.8, please post them for review soon. Patches >> posted before the freeze, but reviewed shortly after the freeze, may >> still go in, further changes should be just bugfixes and documentation >> fixes. >> >> >> Quality Data >> >> >> Priority # Change from Last Report >> --- --- >> P1 23 + 23 >> P2 77 + 8 >> P3 85 + 84 >> --- --- >> Total 185 +115 >> >> >> Previous Report >> === >> >> http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html >> >> The next report will be sent by me again, announcing end of stage 1.
Re: Debugging incorrect generation of RTL
On 11/01/2012 10:28 AM, Peter Garbett wrote: > I am maintaining a private port that I am attempting to port to GCC 4.7.2 > > With RTL checking enabled, it fails with a message > > > "RTL check: expected code 'reg' have 'const_int' in rhs_regno, at rtl.h:1090" > > > I assume this is because there is a problem with my .md file? > > If so, any hints or tips on how to trace it back to the misbehaving > definition(s)? > (currently trying to print out some rtl from rhs_rego to see if I > recognise it, is there a better way?) > http://gcc.gnu.org/wiki/DebuggingGCC
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote: > On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote: > > Hi Jakub, > > > > My -fopt-info pass filtering patch > > (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being > > reviewed and I hope to get this in by Nov. 5 for inclusion in gcc > > 4.8.0. > > I just committed -fopt-info pass filtering patch as r193061. How was that change tested? I'm seeing thousands of new UNRESOLVED failures, of the form: spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o branch-cost1.s PASS: gcc.target/i386/branch-cost1.c (test for excess errors) gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple "if " 2 gcc.target/i386/branch-cost1.c: dump file does not exist UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple " & " See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html The difference is just your patch and unrelated sh backend change. Jakub
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
richi, I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I would like to point out that there are about 125 places where we have two copies of the code for some operation. Many of these places are smaller than this, but some are larger. There are also at least several hundred places where the code only was written for the 1 hwi case. These are harder to find with simple greps. I am very concerned about this particular aspect of your comments because it seems to doom us to write the same code over and over again. kenny On 10/31/2012 02:19 PM, Kenneth Zadeck wrote: Jakub, it is hard from all of the threads to actually distill what the real issues are here. So let me start from a clean slate and state them simply. Richi has three primary objections: 1) that we can do all of this with a templated version of double-int. 2) that we should not be passing in a precision and bitsize into the interface. 3) that the interface is too large. I have attached a fragment of my patch #5 to illustrate the main thrust of my patches and to illustrate the usefulness to gcc right now. In the current trunk, we have code that does simplification when the mode fits in an HWI and we have code that does the simplification if the mode fits in two HWIs. if the mode does not fit in two hwi's the code does not do the simplification. Thus here and in a large number of other places we have two copies of the code.Richi wants there to be multiple template instantiations of double-int.This means that we are now going to have to have 3 copies of this code to support oi mode on a 64 bit host and 4 copies on a 32 bit host. Further note that there are not as many cases for the 2*hwi in the code as their are for the hwi case and in general this is true through out the compiler. (CLRSB is missing from the 2hwi case in the patch) We really did not write twice the code when we stated supporting 2 hwi, we added about 1.5 times the code (simplify-rtx is better than most of the rest of the compiler). I am using the rtl level as an example here because i have posted all of those patches, but the tree level is no better. I do not want to write this code a third time and certainly not a fourth time. Just fixing all of this is quite useful now: it fills in a lot of gaps in our transformations and it removes many edge case crashes because ti mode really is lightly tested. However, this patch becomes crucial as the world gets larger. Richi's second point is that we should be doing everything at "infinite precision" and not passing in an explicit bitsize and precision. That works ok (sans the issues i raised with it in tree-vpn earlier) when the largest precision on the machine fits in a couple of hwis.However, for targets that have large integers or cross compilers, this becomes expensive.The idea behind my set of patches is that for the transformations that can work this way, we do the math in the precision of the type or mode. In general this means that almost all of the math will be done quickly, even on targets that support really big integers. For passes like tree-vrp, the math will be done at some multiple of the largest type seen in the actual program.The amount of the multiple is a function of the optimization, not the target or the host. Currently (on my home computer) the wide-int interface allows the optimization to go 4x the largest mode on the target. I can get rid of this bound at the expense of doing an alloca rather than stack allocating a fixed sized structure.However, given the extremely heavy use of this interface, that does not seem like the best of tradeoffs. The truth is that the vast majority of the compiler actually wants to see the math done the way that it is going to be done on the machine. Tree-vrp and the gimple constant prop do not. But i have made accommodations to handle both needs.I believe that the reason that double-int was never used at the rtl level is that it does not actually do the math in a way that is useful to the target. Richi's third objection is that the interface is too large. I disagree. It was designed based on the actual usage of the interface. When i found places where i was
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 8:28 AM, Jakub Jelinek wrote: > How was that change tested? I'm seeing thousands of new UNRESOLVED > failures, of the form: > spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ > /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c > -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o > branch-cost1.s > PASS: gcc.target/i386/branch-cost1.c (test for excess errors) > gcc.target/i386/branch-cost1.c: dump file does not exist > UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple "if " 2 > gcc.target/i386/branch-cost1.c: dump file does not exist > UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple " & " > > See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html > or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that > to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html > or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html > > The difference is just your patch and unrelated sh backend change. I'm seeing the same failures. Sharad, could you fix them or revert your change? Thanks. Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Kenneth Zadeck writes: > I would like you to respond to at least point 1 of this email. In it > there is code from the rtl level that was written twice, once for the > case when the size of the mode is less than the size of a HWI and once > for the case where the size of the mode is less that 2 HWIs. > > my patch changes this to one instance of the code that works no matter > how large the data passed to it is. > > you have made a specific requirement for wide int to be a template that > can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I > would like to know how this particular fragment is to be rewritten in > this model? It seems that I would have to retain the structure where > there is one version of the code for each size that the template is > instantiated. I think richi's argument was that wide_int should be split into two. There should be a "bare-metal" class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo<2> double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide "as wide as we need" arithmetic, as in your rtl patch. I don't think he was objecting to that. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI and once
for the case where the size of the mode is less that 2 HWIs.
my patch changes this to one instance of the code that works no matter
how large the data passed to it is.
you have made a specific requirement for wide int to be a template that
can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I
would like to know how this particular fragment is to be rewritten in
this model? It seems that I would have to retain the structure where
there is one version of the code for each size that the template is
instantiated.
I think richi's argument was that wide_int should be split into two.
There should be a "bare-metal" class that just has a length and HWIs,
and the main wide_int class should be an extension on top of that
that does things to a bit precision instead. Presumably with some
template magic so that the length (number of HWIs) is a constant for:
typedef foo<2> double_int;
and a variable for wide_int (because in wide_int the length would be
the number of significant HWIs rather than the size of the underlying
array). wide_int would also record the precision and apply it after
the full HWI operation.
So the wide_int class would still provide "as wide as we need" arithmetic,
as in your rtl patch. I don't think he was objecting to that.
As is probably obvious, I don't agree FWIW. It seems like an unnecessary
complication without any clear use. Especially since the number of
significant HWIs in a wide_int isn't always going to be the same for
both operands to a binary operation, and it's not clear to me whether
that should be handled in the base class or wide_int.
Richard
There is a certain amount of surprise about all of this on my part.I
thought that i was doing such a great thing by looking at the specific
port that you are building to determine how to size these data
structures.You would think from the response that i am getting that
i had murdered some one.
do you think that when he gets around to reading the patch for
simplify-rtx.c that he is going to object to this frag?
@@ -5179,13 +4815,11 @@ static rtx
simplify_immed_subreg (enum machine_mode outermode, rtx op,
enum machine_mode innermode, unsigned int byte)
{
- /* We support up to 512-bit values (for V8DFmode). */
enum {
-max_bitsize = 512,
value_bit = 8,
value_mask = (1 << value_bit) - 1
};
- unsigned char value[max_bitsize / value_bit];
+ unsigned char value [MAX_BITSIZE_MODE_ANY_MODE/value_bit];
int value_start;
int i;
int elem;
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
anyway richard, it does not answer the question as to what you are going to do with a typedef foo<2>. the point of all of this work by me was to leave no traces of the host in the way the compiler works. instantiating a specific size of the double-ints is not going to get you there. kenny On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the case where the size of the mode is less that 2 HWIs. my patch changes this to one instance of the code that works no matter how large the data passed to it is. you have made a specific requirement for wide int to be a template that can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I would like to know how this particular fragment is to be rewritten in this model? It seems that I would have to retain the structure where there is one version of the code for each size that the template is instantiated. I think richi's argument was that wide_int should be split into two. There should be a "bare-metal" class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo<2> double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide "as wide as we need" arithmetic, as in your rtl patch. I don't think he was objecting to that. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I am really sorry about that. I am looking and will fix the breakage or revert the patch shortly. Thanks, Sharad On Thu, Nov 1, 2012 at 5:28 AM, Jakub Jelinek wrote: > On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote: >> On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote: >> > Hi Jakub, >> > >> > My -fopt-info pass filtering patch >> > (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being >> > reviewed and I hope to get this in by Nov. 5 for inclusion in gcc >> > 4.8.0. >> >> I just committed -fopt-info pass filtering patch as r193061. > > How was that change tested? I'm seeing thousands of new UNRESOLVED > failures, of the form: > spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/ > /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c > -fno-diagnostics-show-caret -O2 -fdump-tree-gimple -mbranch-cost=0 -S -o > branch-cost1.s > PASS: gcc.target/i386/branch-cost1.c (test for excess errors) > gcc.target/i386/branch-cost1.c: dump file does not exist > UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-times gimple "if " 2 > gcc.target/i386/branch-cost1.c: dump file does not exist > UNRESOLVED: gcc.target/i386/branch-cost1.c scan-tree-dump-not gimple " & " > > See http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00033.html > or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00034.html, compare that > to http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00025.html > or http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00026.html > > The difference is just your patch and unrelated sh backend change. > > Jakub
Re: [ANN] gcc-lua: Lua plugin for the GNU Compiler Collection
On 2012-10-31 13:50 , Peter Colberg wrote: gcc‑lua extends the GNU Compiler Collection with the ability to run Lua scripts. The plugin provides an interface to register callback functions for plugin events, and inspect the abstract syntax tree of a translation unit. The plugin is useful for static C code analysis. gcc‑lua supports GCC 4.6 or 4.7, and, Lua 5.1 or 5.2, or LuaJIT. http://colberg.org/gcc-lua/ Thanks for the contribution, Peter. We keep a loosely organized catalog of available plugins. If you want, you can add gcc-lua to it. See http://gcc.gnu.org/wiki/plugins Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Richard Sandiford writes: > As is probably obvious, I don't agree FWIW. It seems like an unnecessary > complication without any clear use. Especially since the number of > significant HWIs in a wide_int isn't always going to be the same for > both operands to a binary operation, and it's not clear to me whether > that should be handled in the base class or wide_int. ...and the number of HWIs in the result might be different again. Whether that's true depends on the value as well as the (HWI) size of the operands. Richard
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I found the problem and the following patch fixes it. The issue with my testing was that I was only looking at 'FAIL' lines but forgot to tally the 'UNRESOLVED' test cases, the real symptoms of my test problems. In any case, I am rerunning the whole testsuite just to be sure. Assuming tests pass, is it okay to commit the following? Thanks, Sharad 2012-11-01 Sharad Singhai PR other/55164 * dumpfile.h (struct dump_file_info): Fix order of flags. Index: dumpfile.h === --- dumpfile.h (revision 193061) +++ dumpfile.h (working copy) @@ -113,8 +113,8 @@ struct dump_file_info const char *alt_filename; /* filename for the -fopt-info stream */ FILE *pstream;/* pass-specific dump stream */ FILE *alt_stream; /* -fopt-info stream */ + int pflags; /* dump flags */ int optgroup_flags; /* optgroup flags for -fopt-info */ - int pflags; /* dump flags */ int alt_flags;/* flags for opt-info */ int pstate; /* state of pass-specific stream */ int alt_state;/* state of the -fopt-info stream */
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai wrote: > I found the problem and the following patch fixes it. The issue with > my testing was that I was only looking at 'FAIL' lines but forgot to > tally the 'UNRESOLVED' test cases, the real symptoms of my test > problems. In any case, I am rerunning the whole testsuite just to be > sure. > > Assuming tests pass, is it okay to commit the following? > > Thanks, > Sharad > > 2012-11-01 Sharad Singhai > > PR other/55164 > * dumpfile.h (struct dump_file_info): Fix order of flags. OK (remember to insert a tab at the start of each ChangeLog line). Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Thu, Nov 1, 2012 at 9:44 AM, Diego Novillo wrote: > On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai wrote: >> I found the problem and the following patch fixes it. The issue with >> my testing was that I was only looking at 'FAIL' lines but forgot to >> tally the 'UNRESOLVED' test cases, the real symptoms of my test >> problems. In any case, I am rerunning the whole testsuite just to be >> sure. >> >> Assuming tests pass, is it okay to commit the following? >> >> Thanks, >> Sharad >> >> 2012-11-01 Sharad Singhai >> >> PR other/55164 >> * dumpfile.h (struct dump_file_info): Fix order of flags. > > OK (remember to insert a tab at the start of each ChangeLog line). Fixed tab chars. (they were really there, but gmail ate them! :)) Retested and found all my 'UNRESOLVED' problems were gone. Hence committed the fix as r193064. Thanks, Sharad > > Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, I would like to get the fission implementation in before stage 1. It has been under review for some time, and is awaiting another round of review now. More info here: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02684.html Sterling
ASAN support accepted and reviewers appointed
I am pleased to announce that the GCC Steering Committee has accepted the Address Sanitizer (ASAN) feature and its associated runtime support library imported from an external repository. Jakub Jelinek, Dodji Seketeli, Kostya Serebryany, and Dmitry Vyukov have been appointed co-reviewers. Happy hacking! David
