powerpc bootstrap failure
Hi I'm getting this failure on powerpc: ../../gcc/gcc/fortran/simplify.c: In function 'gfc_simplify_scale': ../../gcc/gcc/fortran/simplify.c: In function 'gfc_simplify_scale': ../../gcc/gcc/fortran/simplify.c:3345: error: type mismatch in binary expression long unsigned int long unsigned int int D.14635 = 4294967294 - exp_range make[3]: *** [fortran/simplify.o] Error 1 make[3]: *** Waiting for unfinished jobs... Razya
Re: porting problem again: ICE in add_clobbers
On 9/18/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > Tomas Svensson wrote: > There is no optimization at all without -O, no matter how many -f > options you use. What you want to do is -O -fno-foo -fno-bar etc. > However, we do not have -f options for every optimization, so there is > no guarantee that this will identify the optimization pass that exposes > the bug in your port. Right, thanks. I sure hope I learn from all these silly mistakes... Anyway, I did the same thing again, this time with starting with the -O2 that causes the problem and turning off options with -fno- flags. This time, I found the compilation to work with '-O2 -fno-gcse' but to break with just '-O2'. So I guess the problem is somehow caused by global common subexpression elimination. Could it be that gcse changes the insn in some way, making it unrecognizable by the usual define_insn's? Should I use (unspec ..) or (clobber ..) instead of (use ..) (as suggested in GCC Internals, Side effects)? If so, what is the difference, really?
Re: GCC 4.3.0: Stage 3
Hi Mark, there are 3 simple patches waiting for review which I hoped to get in in stage 2. They should be a nop for targets not exploiting the new insn attribute. So I hope they still qualify for early stage 3. I've several patches on my harddisk relying on that feature to be present so I would really like to see them upstream. What do think? Any chance to get this stuff integrated soon? [PATCH 1/3] S/390: New `enabled' insn attribute http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01908.html [PATCH 2/3] reload,recog: New `enabled' insn attribute http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01909.html [PATCH 3/3] genattr: New `enabled' insn attribute http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01910.html Bye, -Andreas-
Re: MIPS atomic memory operations (A.K.A PR 33479).
David Daney wrote: > Richard, > > There seems to be a small problem with the MIPS atomic memory operations > patch I recently committed > (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a > dual CPU machine it does not quite work. > > You can look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479#c3 for > more information. > > Here is the code in question (from mips.h): > > #define MIPS_COMPARE_AND_SWAP(SUFFIX, OP) \ > "%(%<%[sync\n" \ This sync is for SB-1 implied by ll, but other MIPS systems may need it. > "1:\tll" SUFFIX "\t%0,%1\n" \ > "\tbne\t%0,%2,2f\n" \ > "\t" OP "\t%@,%3\n" \ > "\tsc" SUFFIX "\t%@,%1\n" \ > "\tbeq\t%@,%.,1b\n" \ > "\tnop\n" \ The SB-1 needs a "sync" here. > "2:%]%>%)" > > > > I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a 'sync' > after the 'sc'? I would have thought that 'sc' made the write visible to > all CPUs, but on the SB1 it appears not to be the case. > > If we do need to add another 'sync' should it go in the delay slot of the > branch? I would say yes because we would expect the branch to rarely > taken. But it would make things a lot worse for the contended case, which is the interesting one for performance. Thiemo
Re: [Bug c/33076] Warning when passing a pointer to a const array to a function that expects a point
Andreas, besides doing this act of bookkeeping, could you also point out a solution to the problem at hand? Thanks, Jan >>> "schwab at suse dot de" <[EMAIL PROTECTED]> 19.09.07 11:47 >>> --- Comment #4 from schwab at suse dot de 2007-09-19 09:47 --- *** This bug has been marked as a duplicate of 16602 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: GCC 4.3.0: Stage 3
"Andreas Krebbel" <[EMAIL PROTECTED]> writes: > there are 3 simple patches waiting for review which I hoped to get in > in stage 2. They should be a nop for targets not exploiting the new > insn attribute. So I hope they still qualify for early stage 3. I've > several patches on my harddisk relying on that feature to be present > so I would really like to see them upstream. I'm sorry I haven't had time to reply to this patch, but I'm not entirely happy with it. Conceptually it seems reasonable, but I don't understand why your implementation has to work the way it does; it seems overly complicated. And I wonder whether it wouldn't be simpler to achieve the same effect using constraints. Ian
Re: GCC 4.3.0: Stage 3
"Andreas Krebbel" <[EMAIL PROTECTED]> writes: > there are 3 simple patches waiting for review which I hoped to get in > in stage 2. They should be a nop for targets not exploiting the new > insn attribute. So I hope they still qualify for early stage 3. I've > several patches on my harddisk relying on that feature to be present > so I would really like to see them upstream. I'm sorry I haven't had time to reply to this patch, but I'm not entirely happy with it. Conceptually it seems reasonable, but I don't understand why your implementation has to work the way it does; it seems overly complicated. And I wonder whether it wouldn't be simpler to achieve the same effect using constraints. Ian
Re: porting problem again: ICE in add_clobbers
"Tomas Svensson" <[EMAIL PROTECTED]> writes: > So I guess the problem is somehow caused by global common > subexpression elimination. Could it be that gcse changes the insn in > some way, making it unrecognizable by the usual define_insn's? gcse will never convert a recognizable insn into an unrecognizable insn. > Should > I use (unspec ..) or (clobber ..) instead of (use ..) (as suggested in > GCC Internals, Side effects)? If so, what is the difference, really? You still haven't showed us the actual insn which failed to match. The problem is that whatever that insn looks like, there is no define_insn which matches it. For purposes of matching, a define_expand does not count. The difference between unspec, clobber, and use is that unspec tells the compiler nothing, clobber tells the compiler that the register was clobbered, and use tells the compiler that the register was used but not changed. Ian
Re: GCC 4.3.0: Stage 3
Hi Ian, > I'm sorry I haven't had time to reply to this patch, but I'm not > entirely happy with it. Conceptually it seems reasonable, but I don't > understand why your implementation has to work the way it does; it > seems overly complicated. And I wonder whether it wouldn't be simpler > to achieve the same effect using constraints. the recog, reload and back end changes are straightforward and probably not what you considered overly complex. The lengthy part is necessary to have attribute getter functions which allow to specify the alternative as additional parameter. I admit that these are a lot of quite mechanical changes to the genattr stuff but my hope was that these getter functions might be useful in other contexts as well. The genattr changes allow me to use the existing attribute mechanism. An alternative would be to enhance the language of the machine description files. If we do this we might add the enabled flag to the insn_data struct as it is done with the constraint letters. But this would probably need even more code. And since we already have per alternative attributes I think we don't need a new mechanism to describe this. Misusing the constraint letters to enable or disable alternatives is a solution which is already used by back ends. On S/390 we have the 'O' constraint familiy which only returns true for machines providing the extended immediate facility. But actually this was one of the reasons why I wanted to change this. I think this is a non-obvious mixture of different concepts. The constraint letters should only depend on the type of the operand. Adding additional conditions to it could create a real mess. Besides the presence of the extended immediate facility the S/390 'O' constraint just checks for immediate values of different bit widths. For immediate values on other machines I therefore have to duplicate these constraints which is quite ugly and might be a problem since constraint letters are already quite sparse. Since a single insn alternative usually has more than just one operand there are several constraint letters which might be used to disable that alternative. The availability of a certain insn alternative mostly means that the instruction is not available. But how can this be coupled to the validity of an operand for an insn? Either the instruction isn't available then *ALL* operands of the alternative are invalid or if it is available *ALL* operands of the appropriate type are valid. I don't think it is a clean concept having one operand of an alternative accepted but the other rejected since the instruction is not present. Bye, -Andreas-
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote: > There seems to be a small problem with the MIPS atomic memory operations > patch I recently committed > (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a > dual CPU machine it does not quite work. > > You can look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479#c3 for > more information. > > Here is the code in question (from mips.h): > > #define MIPS_COMPARE_AND_SWAP(SUFFIX, OP) \ > "%(%<%[sync\n" \ > "1:\tll" SUFFIX "\t%0,%1\n" \ > "\tbne\t%0,%2,2f\n" \ > "\t" OP "\t%@,%3\n" \ > "\tsc" SUFFIX "\t%@,%1\n" \ > "\tbeq\t%@,%.,1b\n" \ Please make this loop closure branch a branch-likely. This is necessary as a errata workaround for some processors. (I know silicon people hate me for keeping branch likely instruction alive this way but it's my job to make sure Linux and software are working without unpleasant surprises.) > "\tnop\n" \ > "2:%]%>%)" > > > > I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a > 'sync' after the 'sc'? I would have thought that 'sc' made the write > visible to all CPUs, but on the SB1 it appears not to be the case. The MIPS architecture specification specifies no memory model, so for portable code you need to make a worst case assumption which is weak ordering. Only on R4000 and R4400 SC and SCD did imply a SYNC operation. > If we do need to add another 'sync' should it go in the delay slot of > the branch? I would say yes because we would expect the branch to > rarely taken. Not when using a branch likely. Btw, I recently wrote an article about memory consistency which is at http://www.linux-mips.org/wiki/Memory_consistency. It gives a bit of an overview of things in general and on MIPS specifically. I request people with detailed knowledge of MIPS cores not specifically covered in that article to contribute. Ralf
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Wed, 19 Sep 2007, Ralf Baechle wrote: > Please make this loop closure branch a branch-likely. This is necessary > as a errata workaround for some processors. Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding "sync" is easy (as a no-op as support for R3000 SMP is unlikely to ever happen). Adding branches-likely, hmm... Even though we do have logic to do that as a part of the FP emulator. A workaround for a CPU erratum fits within the "-mfix-*" option family quite well though. Maciej
Re: MIPS atomic memory operations (A.K.A PR 33479).
Maciej W. Rozycki wrote: On Wed, 19 Sep 2007, Ralf Baechle wrote: Please make this loop closure branch a branch-likely. This is necessary as a errata workaround for some processors. Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding "sync" is easy Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and 'sync', If sync is not emulated, we would need to adjust the code generation so that it is not emitted on ISAs that don't support it. (as a no-op as support for R3000 SMP is unlikely to ever happen). Adding branches-likely, hmm... Even though we do have logic to do that as a part of the FP emulator. A workaround for a CPU erratum fits within the "-mfix-*" option family quite well though. Do we know which CPUs require branch-likely? I would be inclined to agree with adding a "-mfix-??" option. The only place where GCC's __sync_* primitives are generated without explicitly writing them into your program is in GCJ compiled java code that uses volatile fields. If we expect the use of the __sync_* primitives on CPUs that require branch-likely to be rare, we shouldn't penalize those trying to rid themselves of the beasts. Maciej
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Wed, 19 Sep 2007, David Daney wrote: > Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and > 'sync', If sync is not emulated, we would need to adjust the code generation > so that it is not emitted on ISAs that don't support it. While adding "sync" is trivial enough I may have a patch ready by tomorrow, that will not change the existing userbase and I am not entirely sure forcing such a hasty upgrade on people would be reasonable; likely not. > > A workaround for a CPU erratum fits within the "-mfix-*" option family quite > > well though. > > Do we know which CPUs require branch-likely? The R1; there is a note about it in at R1_LLSC_WAR. > I would be inclined to agree with adding a "-mfix-??" option. > > The only place where GCC's __sync_* primitives are generated without > explicitly writing them into your program is in GCJ compiled java code that > uses volatile fields. > > If we expect the use of the __sync_* primitives on CPUs that require > branch-likely to be rare, we shouldn't penalize those trying to rid themselves > of the beasts. Another option is to depend on the setting of -mbranch-likely. By default it is on only for the processors which implement it and do not discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs. Maciej
Re: MIPS atomic memory operations (A.K.A PR 33479).
David Daney wrote: Maciej W. Rozycki wrote: On Wed, 19 Sep 2007, Ralf Baechle wrote: Please make this loop closure branch a branch-likely. This is necessary as a errata workaround for some processors. Do we emulate them for MIPS I? We do emulate "ll" and "sc" and adding "sync" is easy Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and 'sync', If sync is not emulated, we would need to adjust the code generation so that it is not emitted on ISAs that don't support it. I just checked myself. 'sync' is not emulated. We will have to make a change so that it is not emitted on ISAs that do not support it. David Daney
Re: MIPS atomic memory operations (A.K.A PR 33479).
Maciej W. Rozycki wrote: On Wed, 19 Sep 2007, David Daney wrote: Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and 'sync', If sync is not emulated, we would need to adjust the code generation so that it is not emitted on ISAs that don't support it. While adding "sync" is trivial enough I may have a patch ready by tomorrow, that will not change the existing userbase and I am not entirely sure forcing such a hasty upgrade on people would be reasonable; likely not. A workaround for a CPU erratum fits within the "-mfix-*" option family quite well though. Do we know which CPUs require branch-likely? The R1; there is a note about it in at R1_LLSC_WAR. I would be inclined to agree with adding a "-mfix-??" option. The only place where GCC's __sync_* primitives are generated without explicitly writing them into your program is in GCJ compiled java code that uses volatile fields. If we expect the use of the __sync_* primitives on CPUs that require branch-likely to be rare, we shouldn't penalize those trying to rid themselves of the beasts. Another option is to depend on the setting of -mbranch-likely. By default it is on only for the processors which implement it and do not discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs. This seems to be the most sensible option. I will try to work up the GCC patch tonight. Thanks, David Daney
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Wed, 19 Sep 2007, David Daney wrote: > I just checked myself. 'sync' is not emulated. We will have to make a change > so that it is not emitted on ISAs that do not support it. The problem is if such software is run on a newer processor it may silently break. Tough, I know... We should have added "sync" emulation long ago. OTOH, perhaps the MIPS I userbase is not that large anymore for the emulation to be required with a short transition period only? Maciej
Re: MIPS atomic memory operations (A.K.A PR 33479).
David Daney wrote: > Maciej W. Rozycki wrote: >> On Wed, 19 Sep 2007, David Daney wrote: >>> Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', >>> 'sc' and >>> 'sync', If sync is not emulated, we would need to adjust the code >>> generation >>> so that it is not emitted on ISAs that don't support it. >> While adding "sync" is trivial enough I may have a patch ready by >> tomorrow, that will not change the existing userbase and I am not entirely >> sure forcing such a hasty upgrade on people would be reasonable; likely >> not. A workaround for a CPU erratum fits within the "-mfix-*" option family quite well though. >>> Do we know which CPUs require branch-likely? >> The R1; there is a note about it in at >> R1_LLSC_WAR. >>> I would be inclined to agree with adding a "-mfix-??" option. >>> >>> The only place where GCC's __sync_* primitives are generated without >>> explicitly writing them into your program is in GCJ compiled java code >>> that >>> uses volatile fields. >>> >>> If we expect the use of the __sync_* primitives on CPUs that require >>> branch-likely to be rare, we shouldn't penalize those trying to rid >>> themselves >>> of the beasts. >> Another option is to depend on the setting of -mbranch-likely. By >> default it is on only for the processors which implement it and do not >> discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs. > > This seems to be the most sensible option. > > I will try to work up the GCC patch tonight. This means generic MIPS code (MIPS I) wil have broken atomic intrinsics when run on modern MIPS machines. Thiemo
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Wed, Sep 19, 2007 at 07:12:33PM +0100, Thiemo Seufer wrote: > >> Another option is to depend on the setting of -mbranch-likely. By > >> default it is on only for the processors which implement it and do not > >> discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs. All MIPS implementations that have branch likely also support it with good performance. So the deprecation is atm really something that has happened on paper. The approach for LL/SC loops (where it's used for correctness) and the rest of the code where we care about code size and performance is not necessarily the same. > > This seems to be the most sensible option. > > > > I will try to work up the GCC patch tonight. > > This means generic MIPS code (MIPS I) wil have broken atomic > intrinsics when run on modern MIPS machines. Oh and if it takes adding new emulations for SYNC (some pseudo MIPS II implementations lack SYNC afair) or branch likely to the kernel I will certainly support that. Ralf
GCC spec posting on AMD Barcelona
We have performance results that show GCC now delivers outstanding performance on AMD's Quad-core Barcelona processors. We've just posted our SPECint results tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to thank all of you for doing such a great job on the performance front. Our posted benchmark results are at http://developer.amd.com/gcc. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
[wwwdocs] Patch for RE: Coding conventions -- command line option vs command-line option
On Mon, 17 Sep 2007, Dave Korn wrote: > Hyphenated. It's not a line option of a command, it's an option of a > command-line. On Mon, 17 Sep 2007, Joseph S. Myers wrote: > As an adjective I think it should be "command-line"; I'm sure Sandra will > correct me if I'm wrong here. On Mon, 17 Sep 2007, Sandra Loosemore wrote: > As an adjective immediately preceding the noun it modifies, yes, it should be > hyphenated: "command-line option". But if you use "command line" as a noun, > use the unhyphenated form; e.g., "use the -foo option on the command line". Thanks to the three of you for your guidance on this, Dave, Joseph, and Sandra! I am committing the patch below to our coding conventions and will fix up the existing web pages accordingly. Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.52 diff -u -3 -p -r1.52 codingconventions.html --- codingconventions.html 10 Sep 2007 18:45:48 - 1.52 +++ codingconventions.html 19 Sep 2007 22:29:05 - @@ -270,6 +270,11 @@ and code. The following table lists som +"command-line option" +"command line option" + + + "dependent" (adjective), "dependence", "dependency" "dependant", "dependance", "dependancy"
Re: Signed division with rounding towards -infinity (and floating point rounding)
Christopher Key wrote:
The most concise form that I've found so far is:
const int d = 8; // 16, 32 etc
x = y / d - ((y % d < 0) ? 1 : 0)
although this still produces rather longer code (see example below).
Any integer divide by constant can be replaced by a sequence of
multiply, shift, and add instructions that produces the same result for
all inputs. There is a proof in a paper by Peter Montgomery and
Torbjorn Granlund. Because integer divide instructions are slow on most
hardware, this is often a profitable optimization. The same is true for
the modulo operation. So what you are seeing here are two sequences of
instructions to compute divide/modulo results using multiply/shift/add.
Gcc is not able to simplify the two sequences further. We would have to
add code to recognize this sequence and handle it specially, and that
isn't what you are asking for.
On a similar point, is there a good way get floats rounded to the
nearest integer value rather than truncated. The following give the
correct rounding behaviour (I'm only interested in +ve values),
x = (int) (f + 0.5)
although gets compiled as an addition of 0.5 followed by a truncation
(again, see example).
Gcc has some builtin support for the lrint library function, however,
only x86 supports this, and you have to use -ffast-math to get this
optimization.
On an x86_64-linux system, compiling this testcase
long int lrint (double d);
long int sub (double d) { return lrint (d); }
with -O2 -ffast-math -S gives me
sub:
cvtsd2siq %xmm0, %rax
ret
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCC spec posting on AMD Barcelona
Michael Meissner wrote: > We have performance results that show GCC now delivers outstanding performance > on AMD's Quad-core Barcelona processors. We've just posted our SPECint > results > tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to > thank all of you for doing such a great job on the performance front. Our > posted benchmark results are at http://developer.amd.com/gcc. > Solid support for the gnu toolchain and linux kernel is a _fundamental_ requirement when I make buying decisions. Well done, AMD. I hope your competitors are listening. Some of them are woefully inadequate in this regard. Andrew Walrond
