powerpc compare_and_swap fails
I'm seeing a lot of testsuite failures on powerpc-linux, some of
which are locking related. For example:
WARNING: Program timed out.
FAIL: libgomp.c/atomic-10.c execution test
This one fails in f3() here:
#pragma omp atomic
z4 *= 3;
z4 is an unsigned char, so we hit the QImode case in
rs6000_expand_atomic_compare_and_swap. operands[3] is modified.
The rather horrible piece of code below corresponds with z4 *= 3;
At 1c60 you can see operands[3], oldval, being shifted. At
1c90 and 1c94, the newly loaded value from the z4 word is
shifted to the low byte position and masked. Then in 1c98 this is
compared against oldval. The comparison never succeeds, because r9
has the value 00yy (the shift happens to be 16 for z4) while r8
has 00yy.
1c34: 57 c6 1e f8 rlwinm r6,r30,3,27,28
1c38: 38 a0 00 ff li r5,255
1c3c: 89 39 13 d1 lbz r9,5073(r25)
1c40: 68 c6 00 18 xorir6,r6,24
1c44: 57 de 00 3a rlwinm r30,r30,0,0,29
1c48: 7c a5 30 30 slw r5,r5,r6
1c4c: 48 00 00 08 b 1c54
1c50: 7d 09 43 78 mr r9,r8
1c54: 7c 00 04 ac sync
1c58: 55 2a 08 3c rlwinm r10,r9,1,0,30
1c5c: 7d 4a 4a 14 add r10,r10,r9
1c60: 7d 29 30 30 slw r9,r9,r6
1c64: 55 4a 06 3e clrlwi r10,r10,24
1c68: 7d 4a 30 30 slw r10,r10,r6
1c6c: 7d 00 f0 28 lwarx r8,0,r30
1c70: 7d 07 28 38 and r7,r8,r5
1c74: 7f 87 48 00 cmpwcr7,r7,r9
1c78: 7d 07 28 78 andcr7,r8,r5
1c7c: 7c e7 53 78 or r7,r7,r10
1c80: 40 9e 00 0c bne-cr7,1c8c
1c84: 7c e0 f1 2d stwcx. r7,0,r30
1c88: 40 a2 ff e4 bne-1c6c
1c8c: 4c 00 01 2c isync
1c90: 7d 08 34 30 srw r8,r8,r6
1c94: 55 08 06 3e clrlwi r8,r8,24
1c98: 7f 89 40 00 cmpwcr7,r9,r8
1c9c: 40 9e ff b4 bne+cr7,1c50
I suspect the fix to this problem doesn't belong in rs6000.c,
but the following does seem to cure this failure.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 181400)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -17334,10 +17366,13 @@ rs6000_expand_atomic_compare_and_swap (r
mask = shift = NULL_RTX;
if (mode == QImode || mode == HImode)
{
+ rtx orig = oldval;
+
mem = rs6000_adjust_atomic_subword (mem, &shift, &mask);
/* Shift and mask OLDVAL into position with the word. */
- oldval = convert_modes (SImode, mode, oldval, 1);
+ oldval = gen_reg_rtx (SImode);
+ convert_move (oldval, orig, 1);
oldval = expand_simple_binop (SImode, ASHIFT, oldval, shift,
oldval, 1, OPTAB_LIB_WIDEN);
--
Alan Modra
Australia Development Lab, IBM
Transactional Memory documentation in extend.texi
We are aware that the TM language constructs should be documented in extend.texi. However, the most recent public version of the C++ TM specification document is outdated, and a new version is supposed to be released in a few weeks. Therefore, we'd like to wait until the release of the new specification document so that we can just cite this new document instead of having to cite the old one and list all the changes. Meanwhile, I have updated the GCC wiki page on TM to be a bit more verbose. Torvald
Re: Transactional Memory documentation in extend.texi
On Thu, Nov 17, 2011 at 03:14:57PM +0100, Torvald Riegel wrote: > We are aware that the TM language constructs should be documented in > extend.texi. However, the most recent public version of the C++ TM > specification document is outdated, and a new version is supposed to be > released in a few weeks. > > Therefore, we'd like to wait until the release of the new specification > document so that we can just cite this new document instead of having to > cite the old one and list all the changes. Why can't you just describe the extensions yourself? Shipping something undocumented is just pointless. And even if there's a specification somewhere users typically need a end user oriented manual too, which a specification is not. On the other hand documenting the ABI like you currently do doesn't seem very interesting to me, I don't know who ever would need that. If someone wants to implement their own STM they can as well read the spec themselves or read some header files. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: Transactional Memory documentation in extend.texi
On Thu, 2011-11-17 at 17:22 +0100, Andi Kleen wrote: > On Thu, Nov 17, 2011 at 03:14:57PM +0100, Torvald Riegel wrote: > > We are aware that the TM language constructs should be documented in > > extend.texi. However, the most recent public version of the C++ TM > > specification document is outdated, and a new version is supposed to be > > released in a few weeks. > > > > Therefore, we'd like to wait until the release of the new specification > > document so that we can just cite this new document instead of having to > > cite the old one and list all the changes. > > Why can't you just describe the extensions yourself? Because creating a write up with content that will be available in a polished form in about 3 weeks from now is perhaps not the best use of resources? > Shipping something undocumented is just pointless. And even if there's > a specification somewhere users typically need a end user oriented > manual too, which a specification is not. The C++ TM specification group is considering writing a tutorial, but there's still some discussion about who would actually do it. > On the other hand documenting the ABI like you currently do > doesn't seem very interesting to me, I don't know who ever would > need that. If someone wants to implement their own STM they > can as well read the spec themselves or read some header files. We document the differences to the Intel ABI, and why we think those differenes make sense. This is obviously not an effort targeting end users but required to eventually come up with a common ABI. We could have put all the comments about the ABI differences into the header files, but then it becomes harder to see the differences to the existing ABI specification by Intel. Torvald
Links to release criteria?
Gerald, I've been searching for the release criteria pages for various releases. I haven't found anything. I was expecting to find them as top-level links on the home page. Should I prepare a patch? Or should I have looked in a different place? Thanks. Diego.
Re: Links to release criteria?
On Thu, Nov 17, 2011 at 7:27 PM, Diego Novillo wrote: > > Gerald, I've been searching for the release criteria pages for various > releases. I haven't found anything. I was expecting to find them as > top-level links on the home page. > > Should I prepare a patch? Or should I have looked in a different place? They are release specific - in gcc-MAJOR.MINOR/criteria.html. Especially the list of primary and secondary targets may vary. It would be certainly useful to have a "next upcoming release" link on the main page, pointing to gcc-4.7/index.html. But we'd have to adjust the wording of the pages to not suggest that a release already happened. Richard. > > Thanks. Diego. >
Re: Links to release criteria?
On 11-11-17 11:19 , Richard Guenther wrote: They are release specific - in gcc-MAJOR.MINOR/criteria.html. Especially the list of primary and secondary targets may vary. It would be certainly useful to have a "next upcoming release" link on the main page, pointing to gcc-4.7/index.html. But we'd have to adjust the wording of the pages to not suggest that a release already happened. I was thinking changing the text: Active development: GCC 4.7.0 (changes) to Active development: GCC 4.7.0 (changes, release criteria) Or simply make 'GCC 4.7.0' a link to a 4.7-specific page. Diego.
Re: Links to release criteria?
On Thu, Nov 17, 2011 at 8:19 PM, Richard Guenther wrote: > On Thu, Nov 17, 2011 at 7:27 PM, Diego Novillo wrote: >> >> Gerald, I've been searching for the release criteria pages for various >> releases. I haven't found anything. I was expecting to find them as >> top-level links on the home page. >> >> Should I prepare a patch? Or should I have looked in a different place? > > They are release specific - in gcc-MAJOR.MINOR/criteria.html. Especially > the list of primary and secondary targets may vary. It would be > certainly useful > to have a "next upcoming release" link on the main page, pointing to > gcc-4.7/index.html. But we'd have to adjust the wording of the pages to > not suggest that a release already happened. I indeed do not see where we link to criteria.html. I think we should duplicate the list of primary/secondary targets on the releases index.html page(?) and make the rest of the criteria.html generic, pointing to it from gcc.gnu.org directly. The criteria itself are less interesting for already released versions. Richard. > Richard. > >> >> Thanks. Diego. >> >
Re: Links to release criteria?
Hi Diego, On Thu, 17 Nov 2011, Diego Novillo wrote: > Gerald, I've been searching for the release criteria pages for various > releases. I haven't found anything. I was expecting to find them as > top-level links on the home page. the release criteria are there, cf. > ls ~/wwwdocs/htdocs/*/criteria.html .../wwwdocs/htdocs/gcc-3.0/criteria.html .../wwwdocs/htdocs/gcc-3.1/criteria.html .../wwwdocs/htdocs/gcc-3.3/criteria.html .../wwwdocs/htdocs/gcc-3.4/criteria.html .../wwwdocs/htdocs/gcc-4.0/criteria.html .../wwwdocs/htdocs/gcc-4.1/criteria.html .../wwwdocs/htdocs/gcc-4.2/criteria.html .../wwwdocs/htdocs/gcc-4.3/criteria.html .../wwwdocs/htdocs/gcc-4.4/criteria.html .../wwwdocs/htdocs/gcc-4.5/criteria.html .../wwwdocs/htdocs/gcc-4.6/criteria.html .../wwwdocs/htdocs/gcc-4.7/criteria.html but, indeed they are not linked! > Should I prepare a patch? Or should I have looked in a different place? Where would you like to see these? For 4.7 in the release overview on the main page seems a natural place. If you agree, sure, go ahead and add it there. For older releases, where have you checked? Where would you like to find them? (I have an idea or two, though none totally satisfactory, so better ask the users. ;-) Gerald
Re: powerpc compare_and_swap fails
On 11/17/2011 12:37 AM, Alan Modra wrote: > - oldval = convert_modes (SImode, mode, oldval, 1); > + oldval = gen_reg_rtx (SImode); > + convert_move (oldval, orig, 1); >oldval = expand_simple_binop (SImode, ASHIFT, oldval, shift, > oldval, 1, OPTAB_LIB_WIDEN); Gah. From convert_modes, oldval is a subreg, and modifying that subreg gets us into all sorts of trouble. The fix should be as simple as - oldval, 1, OPTAB_LIB_WIDEN); + NULL_RTX, 1, OPTAB_LIB_WIDEN); so that we don't write back into the subreg. r~
gcc-4.5-20111117 is now available
Snapshot gcc-4.5-2017 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-2017/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 181459 You'll find: gcc-4.5-2017.tar.bz2 Complete GCC MD5=e82ddf856f64088af205d7c5bf2686e8 SHA1=adc5b323e6b7a2f6ba90a349751a67d4b3053604 Diffs from 4.5-2010 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: powerpc compare_and_swap fails
On Thu, Nov 17, 2011 at 3:25 PM, Richard Henderson wrote: > On 11/17/2011 12:37 AM, Alan Modra wrote: >> - oldval = convert_modes (SImode, mode, oldval, 1); >> + oldval = gen_reg_rtx (SImode); >> + convert_move (oldval, orig, 1); >> oldval = expand_simple_binop (SImode, ASHIFT, oldval, shift, >> oldval, 1, OPTAB_LIB_WIDEN); > > Gah. From convert_modes, oldval is a subreg, and modifying that > subreg gets us into all sorts of trouble. The fix should be as > simple as > > - oldval, 1, OPTAB_LIB_WIDEN); > + NULL_RTX, 1, OPTAB_LIB_WIDEN); > > so that we don't write back into the subreg. Richard, Are you going to test and apply the fix or do you want Alan and I to do it? Thanks, David
Re: powerpc compare_and_swap fails
On 11/17/2011 02:34 PM, David Edelsohn wrote: > On Thu, Nov 17, 2011 at 3:25 PM, Richard Henderson wrote: >> On 11/17/2011 12:37 AM, Alan Modra wrote: >>> - oldval = convert_modes (SImode, mode, oldval, 1); >>> + oldval = gen_reg_rtx (SImode); >>> + convert_move (oldval, orig, 1); >>>oldval = expand_simple_binop (SImode, ASHIFT, oldval, shift, >>> oldval, 1, OPTAB_LIB_WIDEN); >> >> Gah. From convert_modes, oldval is a subreg, and modifying that >> subreg gets us into all sorts of trouble. The fix should be as >> simple as >> >> - oldval, 1, OPTAB_LIB_WIDEN); >> + NULL_RTX, 1, OPTAB_LIB_WIDEN); >> >> so that we don't write back into the subreg. > > Richard, > > Are you going to test and apply the fix or do you want Alan and I to do it? Already done. See gcc-patches. http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181459 r~
Re: a question about IVOPTS: find_interesting_uses_address
2011/11/18 Richard Guenther : > On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote: >> 2011/11/17 Richard Guenther : >>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou >>> wrote: > Huh, IVOPTs should never cause a different size memory read. I wonder > if the original issue would still reproduce with the fix reverted. The original issue was unaligned arrays in packed structures. I don't see what could have changed since then. >>> >>> Ah, so it was expand being confused about the constructed access (not seeing >>> a component-ref), thus the usual old issue we have there. There's indeed no >>> trivial fix for this but to create the [TARGET_]MEM_REF with an explicitely >>> unaligned type and hope that the target implements the movmisalign optab >>> (the only case this explicit alignment is honored). And double-check the >>> TARGET_MEM_REF expansion code properly duplicates the movmisalign >>> path from the MEM_REF expander. >>> >>> I'd wish somebody fixed this path for non-movmisalign strict-align targets. >>> >> >> I'm a little bit confused, and i don't know if i understand you correctly. >> are you saying that we can remove those check in >> find_interesting_uses_address, >> and handle this misalign memory reference as aligned memory reference, >> just attach the >> misalign information in type and let expander to choose correct >> expansion dependent on >> movmisalign optab icode ? > > Yes. But only if movmisalign is available. > >> In that case if Target don't support misalign memory access, the >> result of IVOPTS will >> be non-optimal since the cost of IV used in misalign memory access is >> wrong, right? > > No, the cost of the IV is the same, independent on whether it is aligned or > not. > > Richard. I got you,thanks. Would it be ok if i file a bug about this,like missed optimization for misaligned memory access in IVOPTS? and since the path for non-movmisalign strict-align targets don't exist now, could i add a condition in that check to avoid this. like: if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step) && optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing) goto fail; I don't know if it is appropriate to check optab in IVOPTS, sorry if i go too far. -- Yuehai > >> -- >> Yuehai >> >> >>> Richard. >>> -- Eric Botcazou >>> >> >
````````你````好```````
¿ÉÒÔ´ú¿ª¸÷ÏîË°~~Ʊ ÁªÏµµç»°£»13713763916 ÁªÏµÈË £» ÕÅ ÏÈ Éú
