Re: calculation of pi
On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no "original." The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. 2012110500 - arguments.tar.bz2 Description: application/bzip
Re: calculation of pi
On 05/11/2012 11:33, Mischa Baars wrote: On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no "original." The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. Hi, I think you are still misunderstanding the situation here. Floating point arguments are not passed in the xmm registers "because Ian thinks it's faster". They are passed in the xmm registers because that is the ABI that was agreed on long ago by a group of experienced experts involved in the design of the processor (the 64-bit AMD processors, since they pre-dated Intel's 64-bit x86 chips), compiler design, and operating system design (since it is the ABI for 64-bit x86 Linux we are discussing). It is quite possible that Ian was part of that group - he is an "experienced expert" - but it was not his decision. And it is /not/ going to change. The ABI is fixed - you have to live with it. I'm sure there are many aspects of the 32-bit x86 ABI that people would like to change, since it was fixed in stone before features like xmm registers were part of the x86 cpus. But that doesn't happen - you have to keep the ABI consistent. For purely internal code - static functions without external linkage - the compiler can use whatever calling conventions it wants. If you think that such calls could be done better, then that can be discussed or filed as "missed optimisation" bug reports. In the particular case of passing floating point arguments, of course, the extra step needed to move data from an xmm register onto the stack for the "fsin" code is totally negligible. The great majority of floating point operations /are/ handled by SSE instructions, since operations such as load, store, register move, and basic arithmetic outweigh the use of transcendental functions by many orders of magnitude. You do not change the ABI used by an entire operating system to shave a few clock cycles off an unusual piece of test code to calculate pi. mvh., David
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-10-29 at 18:56 +0100, 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. I'd like to post later today (hopefully this morning) a very minimal configure patch that adds the -mcpu=power8 and -mtune=power8 compiler options to gcc. Currently, power8 will be an alias for power7, but getting this path in now allows us to add power8 support to the compiler without having to touch the arch independent configure script. The only hang up at the moment is we're still determining the assembler mnemonic we'll be releasing that the gcc configure script will use to test for power6 assembler support. Peter
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote: > On Mon, 2012-10-29 at 18:56 +0100, Jakub Jelinek wrote: > > 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. > > I'd like to post later today (hopefully this morning) a very minimal > configure patch that adds the -mcpu=power8 and -mtune=power8 compiler > options to gcc. Currently, power8 will be an alias for power7, but > getting this path in now allows us to add power8 support to the > compiler without having to touch the arch independent configure script. config.gcc target specific hunks are part of the backend, the individual target maintainers can approve changes to that, I really don't see a reason to add a dummy alias now just for that. If the power8 enablement is approved and non-intrusive enough that it would be acceptable even during stage 3, then so would be corresponding config.gcc changes. Jakub
[C++11] PR54413 Option for turning off compiler extensions for numeric literals.
I sent this to the wrong list originally, apologies to those who get it twice. There is a request to be able to turn off interpretation of several suffixes for gcc extension numeric literals to make way for C++-1Y or various std libraries to claim several suffixes currently used for gnu extensions. This patch interprets the suffixes according to the current extension rules by default. But if -std=c++1y is used as the C++ standard then the flags are off by default allowing use as C+11 user-defined literals. I would like to get this into 4.8 if I can. It passes on x86_64 linux. Regards, Ed libcpp 2012-11-05 Ed Smith-Rowland <3dw...@verizon.net> PR c++/54413 * include/cpplib.h (cpp_interpret_float_suffix): Add cpp_reader* arg. (cpp_interpret_int_suffix): Add cpp_reader* arg. * init.c (cpp_create_reader): Iitialize new flags. * expr.c (interpret_float_suffix): Use new flags. (cpp_interpret_float_suffix): Add cpp_reader* arg. (interpret_int_suffix): Use new flags. (cpp_interpret_int_suffix): Add cpp_reader* arg. (cpp_classify_number): Adjust calls to interpret_x_suffix. gcc/c-family 2012-11-05 Ed Smith-Rowland <3dw...@verizon.net> PR c++/54413 * c-opts.c (c_common_handle_option): Set new flags. * c.opt: Describe new flags. gcc/cp 2012-11-05 Ed Smith-Rowland <3dw...@verizon.net> PR c++/54413 * decl.c (grokfndecl): Adjust calls to interpret_x_suffix. gcc/testsuite 2012-11-05 Ed Smith-Rowland <3dw...@verizon.net> PR c++/54413 * g++.dg/cpp0x/fno-fixed-point-literals.C: New. * g++.dg/cpp0x/fno-imaginary-literals.C: New. * g++.dg/cpp0x/fno-machine-defined-literals.C: New. * g++.dg/cpp0x/ffixed-point-literals.C: New. * g++.dg/cpp0x/fimaginary-literals.C: New. * g++.dg/cpp0x/fmachine-defined-literals.C: New. Index: libcpp/include/cpplib.h === --- libcpp/include/cpplib.h (revision 192897) +++ libcpp/include/cpplib.h (working copy) @@ -431,6 +431,18 @@ ud-suffix which does not beging with an underscore. */ unsigned char warn_literal_suffix; + /* Nonzero means interpret imaginary number suffix as an imaginary number + literal. */ + unsigned char imaginary_literals; + + /* Nonzero means interpret fixed-point number suffix as a fixed-point number + literal. */ + unsigned char fixed_point_literals; + + /* Nonzero means interpret fixed-point number suffix as amachine-defined + number literal. */ + unsigned char machine_defined_literals; + /* Holds the name of the target (execution) character set. */ const char *narrow_charset; @@ -854,10 +866,12 @@ const char **, source_location); /* Return the classification flags for a float suffix. */ -extern unsigned int cpp_interpret_float_suffix (const char *, size_t); +extern unsigned int cpp_interpret_float_suffix (cpp_reader *, const char *, + size_t); /* Return the classification flags for an int suffix. */ -extern unsigned int cpp_interpret_int_suffix (const char *, size_t); +extern unsigned int cpp_interpret_int_suffix (cpp_reader *, const char *, + size_t); /* Evaluate a token classified as category CPP_N_INTEGER. */ extern cpp_num cpp_interpret_integer (cpp_reader *, const cpp_token *, Index: libcpp/init.c === --- libcpp/init.c (revision 192897) +++ libcpp/init.c (working copy) @@ -182,6 +182,9 @@ CPP_OPTION (pfile, track_macro_expansion) = 2; CPP_OPTION (pfile, warn_normalize) = normalized_C; CPP_OPTION (pfile, warn_literal_suffix) = 1; + CPP_OPTION (pfile, imaginary_literals) = 1; + CPP_OPTION (pfile, fixed_point_literals) = 1; + CPP_OPTION (pfile, machine_defined_literals) = 1; /* Default CPP arithmetic to something sensible for the host for the benefit of dumb users like fix-header. */ Index: libcpp/expr.c === --- libcpp/expr.c (revision 192897) +++ libcpp/expr.c (working copy) @@ -61,8 +61,8 @@ static cpp_num parse_defined (cpp_reader *); static cpp_num eval_token (cpp_reader *, const cpp_token *, source_location); static struct op *reduce (cpp_reader *, struct op *, enum cpp_ttype); -static unsigned int interpret_float_suffix (const uchar *, size_t); -static unsigned int interpret_int_suffix (const uchar *, size_t); +static unsigned int interpret_float_suffix (cpp_reader *, const uchar *, size_t); +static unsigned int interpret_int_suffix (cpp_reader *, const uchar *, size_t); static void check_promotion (cpp_reader *, const struct op *); /* Token type abuse to create unary plus and minus operators. */ @@ -87,7 +87,7 @@ length LEN, p
Re: calculation of pi
I think this thread belongs on the gcc-help list, not here.
Re: [C++11] PR54413 Option for turning off compiler extensions for numeric literals.
On 11/05/2012 02:09 PM, Ed Smith-Rowland wrote: I sent this to the wrong list originally, apologies to those who get it twice. Actually, you originally sent it to the *right* list. Paolo.
Re: [help]failed to generate PHI NODE in esra pass.
Hi,
On Sun, Nov 04, 2012 at 09:32:48PM -0800, Handong Ye wrote:
> On Sun, Nov 4, 2012 at 2:13 PM, Martin Jambor wrote:
> > On Sat, Nov 03, 2012 at 09:01:53AM +, Yangyueming wrote:
> >> Hi, all
> >>
...
> >>
> >> But when I do the test for a case with a little change, it is failed to
> >> generate MAX_EXPR in phiopt1.
> >> The failed case2 :
> >> int foo(short a ,short b)
> >> {
> >> int c;
> >> if (a < b)
> >> a = b;
> >>
> >> c = *(int *)&a;
> >
> > ehm, and just what do you expect the result of the above line to be?
> >
> >> return c;
> >> }
> >>
...
> >
> > Nevertheless, I can tell why there is no phi node for a. a has its
> > address taken and therefore it is not in SSA form (as clearly visible
> > in the first statements in bb 2 and bb 3). Thus, no PHI nodes for a.
> >
>
> Why 'a' has no SSA form if it's address taken?
> I didn't check the code, but I guess it may because 'a' value is not
> directly used.
Because address taken variables might be used and defined indirectly
through a memory load/store, often in ways that are practically
impossible to detect.
Martin
>
> >> Dump of phifail.c.027t.esra:
> >> foo (short int a, short int b)
> >> {
> >> int c;
> >> short int a$0;
> >>
> >> :
> >> a$0_1 = a;
> >> if (a$0_1 < b_2(D))
> >> goto ;
> >> else
> >> goto ;
> >>
> >> :
> >> a = b_2(D);
> >>
> >> :
> >> c_4 = MEM[(int *)&a];
> >> c_5 = c_4;
> >> return c_5;
> >>
> >> }
> >>
> >> Why it is failed and if there's a way to make it work?
> >
> > I believe that the modified input has undefined semantics (sorry, I
> > don't have time to verify this in the standard) and so no, there is no
> > way to make it work.
> >
> > Martin
>
>
>
> --
> Thanks.
> Handong
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, 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. That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) "wide-int" objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. We had considered something along these lines and rejected it. I am not really opposed to doing something like this, but it is not an obvious winning idea and is likely not to be a good idea. Here was our thought process: if you abstract away the storage inside a wide int, then you should be able to copy a pointer to the block of data from either the rtl level integer constant or the tree level one into the wide int. It is certainly true that making a wide_int from one of these is an extremely common operation and doing this would avoid those copies. However, this causes two problems: 1) Mike's first cut at the CONST_WIDE_INT did two ggc allocations to make the object. it created the base object and then it allocated the array. Richard S noticed that we could just allocate one CONST_WIDE_INT that had the array in it. Doing it this way saves one ggc allocation and one indirection when accessing the data within the CONST_WIDE_INT. Our plan is to use the same trick at the tree level. So to avoid the copying, you seem to have to have a more expensive rep for CONST_WIDE_INT and INT_CST. 2) You are now stuck either ggcing the storage inside a wide_int when they are created as part of an expression or you have to play some game to represent the two different storage plans inside of wide_int. Clearly this is where you think that we should be going by suggesting that we abstract away the internal storage. However, this comes at a price: what is currently an array access in my patches would (i believe) become a function call. From a performance point of view, i believe that this is a non starter. If you can figure out how to design this so that it is not a function call, i would consider this a viable option. On the other side of this you are clearly correct that we are copying the data when we are making wide ints from INT_CSTs or CONST_WIDE_INTs. But this is why we represent data inside of the wide_ints, the INT_CSTs and the CONST_WIDE_INTs in a compressed form. Even with very big types, which are generally rare, the constants them selves are very small. So the copy operation is a loop that almost always copies one element, even with tree-vrp which doubles the sizes of every type. There is the third option which is that the storage inside the wide int is just ggced storage. We rejected this because of the functional nature of wide-ints.There are zillions created, they can be stack allocated, and they last for very short periods of time. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of Maybe the double_int typedef is without any clear use. Properly abstracting from the storage / information providers will save compil
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-11-05 at 13:53 +0100, Jakub Jelinek wrote: > On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote: > > I'd like to post later today (hopefully this morning) a very minimal > > configure patch that adds the -mcpu=power8 and -mtune=power8 compiler > > options to gcc. Currently, power8 will be an alias for power7, but > > getting this path in now allows us to add power8 support to the > > compiler without having to touch the arch independent configure script. > > config.gcc target specific hunks are part of the backend, the individual > target maintainers can approve changes to that, I really don't see a reason > to add a dummy alias now just for that. If the power8 enablement is > approved and non-intrusive enough that it would be acceptable even during > stage 3, then so would be corresponding config.gcc changes. Well we also patch config.in and configure.ac/configure. If those are acceptable to be patched later too, then great. If not, the patch isn't really very large. We did do this for power7 initially too: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html Peter
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote: > Well we also patch config.in and configure.ac/configure. If those are > acceptable to be patched later too, then great. If not, the patch That is the same thing as config.gcc bits. > isn't really very large. We did do this for power7 initially too: > > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html But then power7 patch went in during stage1 of the n+1 release, and wasn't really backported to release branch (just to distro vendor branches), right? Jakub
Defining scheduling resource constraint
Hello, I am experience a problem in GCC4.7 scheduler whereby the scheduler is issuing two instructions that write with a cond_exec to the same register. It ends up looking like this: Cond_exec p1 != 0 : r2 <- r2 and 0xf8 Cond_exec p0 != 0: r2 <- 0x10 This cannot happen, but I am unsure about which hook can be used to tell the scheduler about this. -- Paulo Matos
Re: Defining scheduling resource constraint
Quoting Paulo Matos : Hello, I am experience a problem in GCC4.7 scheduler whereby the scheduler is issuing two instructions that write with a cond_exec to the same register. It ends up looking like this: Cond_exec p1 != 0 : r2 <- r2 and 0xf8 Cond_exec p0 != 0: r2 <- 0x10 This cannot happen, but I am unsure about which hook can be used to tell the scheduler about this. Sounds like it could be one of these issues: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044 http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00743.html
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Wed, 2012-10-31 at 11:13 +0100, Richard Biener wrote: > On Mon, Oct 29, 2012 at 6:56 PM, 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. > > Reminds me of the stable plugin API for introspection. David, Micha - what's > the status here? Adding this is certainly ok during stage3 and I think that > we should have something in 4.8 to kick of further development here. (sorry for the belated response, I was on vacation). I'm currently leaning towards having the API as a separate source tree that can be compiled against 4.6 through 4.8 onwards (hiding all necessary compatibility cruft within it [1]), generating a library that plugins can link against, providing a consistent C API across all of these GCC versions. Keeping it out-of-tree allows plugins to be written that can work with older versions of gcc, and allows the plugin API to change more rapidly than the rest of gcc (especially important for these older gcc releases). Distributions of gcc could build the plugin api at the same time as gcc, albeit from a separate tarball. When the API is more mature, we could merge it inside gcc proper, I guess. I'll try to post something later today. Dave [1] e.g C vs C++ linkage
Re: Defining scheduling resource constraint
On 11/05/2012 03:51 PM, Paulo Matos wrote: > Hello, > > I am experience a problem in GCC4.7 scheduler whereby the scheduler is > issuing two instructions that write with a cond_exec to the same register. It > ends up looking like this: > Cond_exec p1 != 0 : r2 <- r2 and 0xf8 > Cond_exec p0 != 0: r2 <- 0x10 > > This cannot happen, but I am unsure about which hook can be used to tell the > scheduler about this. Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the bookkeeping yourself - keep track of which registers have been set in the current cycle, and ensure insns which set the same registers go to the back of the queue and aren't considered anymore until the next cycle. Bernd
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Jakub and Richi, At this point I have decided to that i am not going to get the rest of the wide-int patches into a stable enough form for this round. The combination of still living without power at my house and some issues that i hit with the front ends has made it impossible to get this finished by today's deadline. I do want patches 1-7 to go in (after proper review) but i am going to withdraw patch 8 for this round. patches 1-5 deal with the rtl level. These have been extensively tested and "examined" with the exception of patch 4, "examined" by Richard Sandiford.They clean up a lot of things at the rtl level that effect every port as well as fixing some outstanding regressions. patches 6 and 7 are general cleanups at the tree level and can be justified as on their own without any regard to wide-int.They have also been extensively tested. I am withdrawing patch 8 because it converted tree-vpn to use wide-ints but the benefit of this patch really cannot be seen without the rest of the tree level wide-int patches. In the next couple of days i will resubmit patches 1-7 with the patch rot removed and the public comments folded into them. Kenny
RE: Defining scheduling resource constraint
> -Original Message- > From: Joern Rennecke [mailto:joern.renne...@embecosm.com] > Sent: 05 November 2012 16:32 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Defining scheduling resource constraint > > > This cannot happen, but I am unsure about which hook can be used to > > tell the scheduler about this. > > Sounds like it could be one of these issues: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044 > > http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00743.html Thanks for the references. I haven't looked into it but the patch attached to the bug doesn't actually fix the symptom so I am assuming it's not the problem. On the other hand I see that the patch is quite old and never managed into GCC so maybe the problem has been fixed somewhere else. Do you know why the patch never made it into GCC? Paulo Matos
RE: Defining scheduling resource constraint
> -Original Message- > From: Bernd Schmidt [mailto:ber...@codesourcery.com] > Sent: 05 November 2012 16:52 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Defining scheduling resource constraint > > Depends on why it schedules them in the same cycle. Either there's an > output dependency, in which case your target's adjust_cost needs to > ensure it doesn't have cost zero. Or maybe the scheduler proved that the > conditions are mutually exclusive and didn't add such a dependency. In > that case, if the machine really disallows this case, you'll probably > need to define the sched_reorg hooks and maybe variable_issue and do the You mean sched_reorder, right? -- Paulo Matos
Re: Defining scheduling resource constraint
On 11/05/2012 06:11 PM, Paulo Matos wrote: >> -Original Message- >> From: Bernd Schmidt [mailto:ber...@codesourcery.com] >> Sent: 05 November 2012 16:52 >> To: Paulo Matos >> Cc: gcc@gcc.gnu.org >> Subject: Re: Defining scheduling resource constraint >> >> Depends on why it schedules them in the same cycle. Either there's an >> output dependency, in which case your target's adjust_cost needs to >> ensure it doesn't have cost zero. Or maybe the scheduler proved that the >> conditions are mutually exclusive and didn't add such a dependency. In >> that case, if the machine really disallows this case, you'll probably >> need to define the sched_reorg hooks and maybe variable_issue and do the > > You mean sched_reorder, right? Right. Bernd
Precompiled header question
I am getting a bunch of failed GCC tests with precompiled headers and was wondering if anyone can help me figure out where to look for the problem. If I run a test by hand by creating common-1.h.gch from common-1.h, then remove common-1.h and compile common-1.c (which includes common-1.h), it fails to find the precompiled common-1.h.gch file. The compile line contains '-I.' and common-1.h.gch is in the current directory along with common-1.c. What is weird is that I have created two new targets; mips-mti-linux-gnu and mips-mti-elf. I see this problem with the mips-mti-linux-gnu target but not with the mips-mti-elf target. I don't see what difference in these targets is causing the difference in behaviour. Does anyone know what routines or variables I should be looking at? Steve Ellcey sell...@mips.com
a question for the c/c++ front end / standards people.
i have been trying to change the representation of INT_CSTs so that they do not carry around the limitation that they can only represent numbers as large as 2 host_wide_ints (HWI). I have chosen a variable length implementation that uses an array of HWIs that is just large enough to hold the specific value. However, the problems that i have hit with the front ends is that i do math "with in the precision specified by the type" rather than infinite precision (where infinite is defined to be the width of two HWIs). This switch to doing math within the precision causes many test cases to behave differently. However, I want to know if differently means "incorrectly" or "I have fixed problems that we have just decided to live with". For instance, produces warnings for many (but not all) of the cases at the bottom of gcc.dg/overflow-warn-1.c. However, there are some test cases that i find baffling. The most troublesome seems to be gcc.dg/switch-warn-1.c. In this test case, the labels of case statements are outside of the range that can be represented by an unsigned char. However, the comments in the testcase seem to indicate that it is ok for the value of the case label to not fit in the range defined by the type of the object being swiched on. in my world, this is a problem because the 256 cannot be represented as an unsigned char and so it looks like an 8 bit 0. This ends up causing a down stream ice, but that is not the problem. The ice is likely cause by the fact that there are a large number of places in gcc that think that they know how to compare ints and some do it one way and some do it in other ways. The question is why is having a case label of 256 on a unsigned char switch legal? richard sandiford has pointed out to me privately that for: unsigned char foo[((1U << 30 << 6) >> 30) + 1]; the array must (and does) have only one element, rather than the (1 << 6) + 1 you'd get from infinite precision. And in this case the overflow occurs in the middle of the operation; it's not something you can fix up after the fact. Is there something magical about things getting promoted to ints that i am missing? kenny
Re: a question for the c/c++ front end / standards people.
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck wrote: > > The question is why is having a case label of 256 on a unsigned char switch > legal? Are you asking why it is valid in the C language? Or are you asking why it is valid in GIMPLE? I guess the first question is fairly obvious so you are asking about GIMPLE. I don't personally see a problem with declaring that it is invalid in GIMPLE, but of course you would need to modify the gimplifier and verify_gimple_stmt to reject this code. Ian
Re: a question for the c/c++ front end / standards people.
On 11/05/2012 01:08 PM, Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck wrote: The question is why is having a case label of 256 on a unsigned char switch legal? Are you asking why it is valid in the C language? Or are you asking why it is valid in GIMPLE? I guess the first question is fairly obvious so you are asking about GIMPLE. I don't personally see a problem with declaring that it is invalid in GIMPLE, but of course you would need to modify the gimplifier and verify_gimple_stmt to reject this code. Ian i have been around enough to understand that a lot can unravel when you pull on a string. At the top level, i could ask is it a problem if i make this illegal gimple? and by problem i mean does this make the front ends reject some legal c program? the problem seems to be mostly that the front ends need to be calling force_fit_type_double (or on my branch force_fit_type_wide rather than just double_int_to_tree (or wide_int_to_tree). This would mean that the value would go into the gimple code with overflow bit set. kenny
Re: [help]failed to generate PHI NODE in esra pass.
On Mon, Nov 5, 2012 at 5:32 AM, Martin Jambor wrote:
> Hi,
>
> On Sun, Nov 04, 2012 at 09:32:48PM -0800, Handong Ye wrote:
>> On Sun, Nov 4, 2012 at 2:13 PM, Martin Jambor wrote:
>> > On Sat, Nov 03, 2012 at 09:01:53AM +, Yangyueming wrote:
>> >> Hi, all
>> >>
>
> ...
>
>> >>
>> >> But when I do the test for a case with a little change, it is failed to
>> >> generate MAX_EXPR in phiopt1.
>> >> The failed case2 :
>> >> int foo(short a ,short b)
>> >> {
>> >> int c;
>> >> if (a < b)
>> >> a = b;
>> >>
>> >> c = *(int *)&a;
>> >
>> > ehm, and just what do you expect the result of the above line to be?
>> >
>> >> return c;
>> >> }
>> >>
>
> ...
>
>> >
>> > Nevertheless, I can tell why there is no phi node for a. a has its
>> > address taken and therefore it is not in SSA form (as clearly visible
>> > in the first statements in bb 2 and bb 3). Thus, no PHI nodes for a.
>> >
>>
>> Why 'a' has no SSA form if it's address taken?
>> I didn't check the code, but I guess it may because 'a' value is not
>> directly used.
>
> Because address taken variables might be used and defined indirectly
> through a memory load/store, often in ways that are practically
> impossible to detect.
Isn't memory ssa supposed to handle such issues? ...
Seems I need do some research ...
Thanks
Handong
>
> Martin
>
>
>>
>> >> Dump of phifail.c.027t.esra:
>> >> foo (short int a, short int b)
>> >> {
>> >> int c;
>> >> short int a$0;
>> >>
>> >> :
>> >> a$0_1 = a;
>> >> if (a$0_1 < b_2(D))
>> >> goto ;
>> >> else
>> >> goto ;
>> >>
>> >> :
>> >> a = b_2(D);
>> >>
>> >> :
>> >> c_4 = MEM[(int *)&a];
>> >> c_5 = c_4;
>> >> return c_5;
>> >>
>> >> }
>> >>
>> >> Why it is failed and if there's a way to make it work?
>> >
>> > I believe that the modified input has undefined semantics (sorry, I
>> > don't have time to verify this in the standard) and so no, there is no
>> > way to make it work.
>> >
>> > Martin
>>
>>
>>
>> --
>> Thanks.
>> Handong
--
Thanks.
Handong
Re: a question for the c/c++ front end / standards people.
On Mon, 5 Nov 2012, Kenneth Zadeck wrote: > This switch to doing math within the precision causes many test cases to > behave differently. However, I want to know if differently means > "incorrectly" or "I have fixed problems that we have just decided to live > with". As far as I know, the TREE_OVERFLOW settings follow the most sensible interpretation of the C standard requirements (that any overflowing operation, with signed result type, whose operands are integer constant expressions, results in the overall containing expression, wherein that overflowing operation is evaluated in the abstract C semantics, not being an integer constant expression). Nothing in the testcases should care in the least about the "two HWI" internal implementation - from the front-end perspective, arithmetic according to the relevant precision is always right, and overflow should always be determined according to that precision. > The question is why is having a case label of 256 on a unsigned char switch > legal? "The integer promotions are performed on the controlling expression. The constant expression in each case label is converted to the promoted type of the controlling expression." (C11, 6.8.4.2 paragraph 5). That is, in the semantics of C the switch is on an int value, not an unsigned char, and 256 is converted to int (which leaves it unchanged). If the value *is* modified by the conversion (say if it's 0x1ULL, converted to int), that's still valid C, as long as you don't get duplicate case labels. I don't know if the *implementation* of this bit of C does anything funny with constants outside the range of their types, but the specification is clear enough. -- Joseph S. Myers jos...@codesourcery.com
Re: a question for the c/c++ front end / standards people.
On 11/05/2012 03:37 PM, Joseph S. Myers wrote: On Mon, 5 Nov 2012, Kenneth Zadeck wrote: This switch to doing math within the precision causes many test cases to behave differently. However, I want to know if differently means "incorrectly" or "I have fixed problems that we have just decided to live with". As far as I know, the TREE_OVERFLOW settings follow the most sensible interpretation of the C standard requirements (that any overflowing operation, with signed result type, whose operands are integer constant expressions, results in the overall containing expression, wherein that overflowing operation is evaluated in the abstract C semantics, not being an integer constant expression). Nothing in the testcases should care in the least about the "two HWI" internal implementation - from the front-end perspective, arithmetic according to the relevant precision is always right, and overflow should always be determined according to that precision. The question is why is having a case label of 256 on a unsigned char switch legal? "The integer promotions are performed on the controlling expression. The constant expression in each case label is converted to the promoted type of the controlling expression." (C11, 6.8.4.2 paragraph 5). That is, in the semantics of C the switch is on an int value, not an unsigned char, and 256 is converted to int (which leaves it unchanged). If the value *is* modified by the conversion (say if it's 0x1ULL, converted to int), that's still valid C, as long as you don't get duplicate case labels. I don't know if the *implementation* of this bit of C does anything funny with constants outside the range of their types, but the specification is clear enough. What i see is that the front end builds an int_cst with the type unsigned char and a value 0x100. I consider this invalid gimple and i think the iant's email does too. It seems like the front end is wrong to create this and should have promoted this value to an int before it ever created gimple for it. kenny
Time for GCC 5.0? (TIC)
On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote: > > Say, why don't we reserve GCC 5.0 for the first version that gets rid of > reload? Then let's see if we can get there while the X in 4.X is still in > single digits! (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html) I suppose LRA counts, even if it doesn't get rid of reload completely just yet. Bump the number! :-) Ciao! Steven
Re: Time for GCC 5.0? (TIC)
On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote: > On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote: >> >> Say, why don't we reserve GCC 5.0 for the first version that gets rid of >> reload? Then let's see if we can get there while the X in 4.X is still in >> single digits! > > (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html) > > I suppose LRA counts, even if it doesn't get rid of reload completely just > yet. > > Bump the number! :-) Also the fact that GCC is now written in C++ seems to me to be deserving of a bump to 5.0. So now we have two reasons! Ian
Re: Time for GCC 5.0? (TIC)
On 2012-11-05 16:17 , Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote: On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote: Say, why don't we reserve GCC 5.0 for the first version that gets rid of reload? Then let's see if we can get there while the X in 4.X is still in single digits! (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html) I suppose LRA counts, even if it doesn't get rid of reload completely just yet. Bump the number! :-) Also the fact that GCC is now written in C++ seems to me to be deserving of a bump to 5.0. I agree. This might be a good time to bump the major version number. In addition to the C++ switch, I think we have a ton of new features. Alerting users that this release may be a double-edged sword seems wise. Diego.
Re: Time for GCC 5.0? (TIC)
Ian Lance Taylor writes: > Also the fact that GCC is now written in C++ seems to me to be > deserving of a bump to 5.0. I see no reason why an internal design change that has no user visible effects should have any impact on the version number. Typically a major version bump is reserved for either massive new functionality or a break with backwards compatibility.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
I'd like to get a small patch to tree reassociation ( http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01761.html ) in. Thanks, Easwaran 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: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, 2012-11-05 at 15:47 +0100, Jakub Jelinek wrote: > On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote: > > Well we also patch config.in and configure.ac/configure. If those are > > acceptable to be patched later too, then great. If not, the patch > > That is the same thing as config.gcc bits. > > > isn't really very large. We did do this for power7 initially too: > > > > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00162.html > > But then power7 patch went in during stage1 of the n+1 release, and > wasn't really backported to release branch (just to distro vendor branches), > right? I think we could have done better there, yes, but not all of our patches were appropriate for backporting, especially those parts that touched outside of the port. There will be portions of power8 we won't/don't want to backport either, but I would like to get the major backend portions like machine description files and the like backported to 4.8 when the time comes. Having the configurey changes in would help that, but if you say those are things we can get in after stage1, then that can ease things a bit. That said, I'll post our current patch as is and discuss within our team and with David on what our next course of action should be. Peter
Re: Time for GCC 5.0? (TIC)
On 11/05/2012 07:43 PM, DJ Delorie wrote: Ian Lance Taylor writes: Also the fact that GCC is now written in C++ seems to me to be deserving of a bump to 5.0. I see no reason why an internal design change that has no user visible effects should have any impact on the version number. Typically a major version bump is reserved for either massive new functionality or a break with backwards compatibility. I tend to agree that major version number bumps ought to be tied to major user-visible changes. I think dropping reload would quality, particularly if there are other major user visible changes going on. For example, significant improvements in modularity allowing for easier plugin development, major improvements in static & dynamic analysis capabilities, etc. jeff
