About Bug 52485
Want to comment on "Bug 52485 - [c++11] add an option to disable c++11 user-defined literals" It's a pity GCC doesn't support this, which forces me to give up introducing newer C++ standard into my project. I know it is ridiculous, but we must know the real world is somehow ridiculous as well as nothing is perfect.
Re: About Bug 52485
On Wed, 9 May 2018, SHIH YEN-TE wrote: Want to comment on "Bug 52485 - [c++11] add an option to disable c++11 user-defined literals" It's a pity GCC doesn't support this, which forces me to give up introducing newer C++ standard into my project. I know it is ridiculous, but we must know the real world is somehow ridiculous as well as nothing is perfect. You have the wrong approach. Apparently, you are using an unmaintained library (if it was maintained, it would be compatible with C++11 by now), so there is no problem modifying it, especially just to add a few spaces. A single run of clang-tidy would likely fix all of them for you. -- Marc Glisse
Re: About Bug 52485
Thanks to your brand new Bugzilla account, you may now comment! :-) You will receive instructions on how to reset your default default password and access your account. Please let me know if you have any questions or trouble gaining access. I'd be happy to help in any way that I can! Thanks for contributing to GCC! Will On Wed, May 9, 2018 at 4:08 AM, SHIH YEN-TE wrote: > Want to comment on "Bug 52485 - [c++11] add an option to disable c++11 > user-defined literals" > > > It's a pity GCC doesn't support this, which forces me to give up introducing > newer C++ standard into my project. I know it is ridiculous, but we must know > the real world is somehow ridiculous as well as nothing is perfect. > >
Re: About Bug 52485
On 9 May 2018 at 09:08, SHIH YEN-TE wrote: > Want to comment on "Bug 52485 - [c++11] add an option to disable c++11 > user-defined literals" > > > It's a pity GCC doesn't support this, which forces me to give up introducing > newer C++ standard into my project. Why do you have to give up? > I know it is ridiculous, but we must know the real world is somehow > ridiculous as well as nothing is perfect. Which is why GCC will only warn and not error when it sees ill-formed uses of macros following string literals without whitespace. So you should still be able to compile code that isn't compatible with C++11 user-defined literals.
Semantics of SAD_EXPR and usad/ssad optabs
Hi all,
I'm looking into implementing the usad/ssad optabs for aarch64 to catch code
like in PR 85693
and I'm a bit lost with what the midend expects the optabs to produce.
The documentation for them says that the addend operand (op 3) is of mode equal
or wider than
the mode of the product (and consequently of operands 1 and 2) with the result
operand 0 being
the same mode as operand 3.
The x86 implementation for usadv16qi (for example) takes a V16QI vector and
returns a V4SI vector.
I'm confused as to what is the reduction logic expected by the midend?
The PSADBW instruction that x86 uses in that case accumulates the two V8QI
halves of the input into
two 16-bit values (you don't need any more bits to represent a sum of 8 byte
differences I believe):
one placed at bit 0, and the other placed at bit 64. The bit ranges [16 - 63]
and [80 - 127] are left as zeroes.
So it produces a V2DI result in essence.
If the input V16QI vectors look like:
{ a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15 }
{ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15 }
then the result V4SI view (before being added into operand 3) is:
{ SUM (ABS (a[0-7] - b[0-7])), 0, SUM (ABS (a[8-15] - b[8-15])), 0 } (1)
whereas a normal widening reduction of V16QI -> V4SI to me would look more like:
{ SUM (ABS (a[0-3] - b[0-3])), SUM (ABS (a[4-7] - b[4-7])), SUM (ABS (a[8-11] -
b[8-11])), SUM (ABS (a[12-15] - b[12-15])) } (2)
My question is, does the vectoriser depend on the semantics of [us]sad
producing the result in (1)?
If so, do you think it's worth clarifying in the documentation?
Thanks,
Kyrill
AMD GCN port
Honza, Martin, Further to our conversation on IRC ... We have just completed work on a GCN3 & GCN5 port intended for running OpenMP and OpenACC offload kernels on AMD Fiji and Vega discrete GPUs. Unfortunately Carrizo is probably broken because we don't have one to test, and the APUs use shared memory and XNACK, which we've not paid any attention to. There will be a binary release available soon(ish). Apologies the development schedule has made it hard to push the work upstream, but now it is time. I've posted the code to Github for reference: https://github.com/ams-cs/gcc https://github.com/ams-cs/newlib We're using LLVM 6 for the assembler and linker; there's no binutils port. It should be possible to build a "standalone" amdgcn-none-amdhsa compiler that can run code via the included "gcn-run" loader tool (and the HSA runtime). This can be used to run the testsuite, with a little dejagnu config trickery. It should also be possible to build an x86_64-linux-gnu compiler with --enable-offload-target=gcn, and a matching amdgcn-none-amdhsa compiler with --enable-as-accelerator-for=x86_64-linux-gnu, and have them run code offloaded with OpenMP or OpenACC directives. The code is based on Honza's original port, rebased to GCC 7.3. I'd like to agree an upstreaming strategy that a) gets basic GCN support into trunk soonish. We'll need to get a few middle/front end patches approved, and probably update a few back-end hooks, but this ought to be easy enough. b) gets trunk OpenMP/OpenACC to work for GCN, eventually. I'm expecting some pain in libgomp here. c) gives me a stable base from which to make binary releases (i.e. not trunk). d) allows me to use openacc-gcc-8-branch without too much duplication of effort. How about the following strategy? 1. Create "gcn-gcc-7-branch" to archive the current work. This would be a source for merges (or cherry-picking), but I'd not expect much future development. Initially it would have the same content as the Github repository above. 2. Create "gcn-gcc-8-branch" with a merger of "gcc-8-branch" and "gcn-gcc-7-branch". This would be broken w.r.t. libgomp, initially, but get fixed up in time. It would receive occasional merges from the release branch. I expect to do GCN back-end development work here. 3. Create "gcn-openacc-gcc-8-branch" from the new "gcn-gcc-8-branch", and merge in "openacc-gcc-8-branch". This will hold offloading patches not compatible with trunk, and receive updated GCN changes via merge. I intend to deliver my next binary release from this branch. 4. Replace/update the existing "gcn" branch with a merger of "trunk" and "gcn-gcc-8-branch" (not the OpenACC branch). This would be merged to trunk, and possibly retired, as soon as possible. I imagine bits will have to be submitted as patches, and then the back-end merged as a whole. trunk |\ | gcc-7-branch | |\ | : gcn-gcc-7-branch | \ |\ '. | gcc-8-branch | | | \ '. | | : openacc-gcc-8-branch gcn-gcc-8-branch | \ / | | gcn-openacc-8-branch | |\ ,-' | gcn |/ gcc-9 It's slightly complex to describe, but hopefully logical and workable. Comments? Better suggestions? -- Andrew Stubbs Mentor Graphics / CodeSourcery.
Re: Semantics of SAD_EXPR and usad/ssad optabs
On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
wrote:
>Hi all,
>
>I'm looking into implementing the usad/ssad optabs for aarch64 to catch
>code like in PR 85693
>and I'm a bit lost with what the midend expects the optabs to produce.
>The documentation for them says that the addend operand (op 3) is of
>mode equal or wider than
>the mode of the product (and consequently of operands 1 and 2) with the
>result operand 0 being
>the same mode as operand 3.
>
>The x86 implementation for usadv16qi (for example) takes a V16QI vector
>and returns a V4SI vector.
>I'm confused as to what is the reduction logic expected by the midend?
>The PSADBW instruction that x86 uses in that case accumulates the two
>V8QI halves of the input into
>two 16-bit values (you don't need any more bits to represent a sum of 8
>byte differences I believe):
>one placed at bit 0, and the other placed at bit 64. The bit ranges [16
>- 63] and [80 - 127] are left as zeroes.
>So it produces a V2DI result in essence.
>
>If the input V16QI vectors look like:
>{ a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15
>}
>{ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15
>}
>
>then the result V4SI view (before being added into operand 3) is:
>{ SUM (ABS (a[0-7] - b[0-7])), 0, SUM (ABS (a[8-15] - b[8-15])), 0 }
>(1)
>
>whereas a normal widening reduction of V16QI -> V4SI to me would look
>more like:
>
>{ SUM (ABS (a[0-3] - b[0-3])), SUM (ABS (a[4-7] - b[4-7])), SUM (ABS
>(a[8-11] - b[8-11])), SUM (ABS (a[12-15] - b[12-15])) } (2)
>
>My question is, does the vectoriser depend on the semantics of [us]sad
>producing the result in (1)?
No, it doesn't. It is required that any association of the embedded reduction
is correct and thus this requires appropriate - ffast-math flags. Note it's
also the reason why we do not implement constant folding of SAD.
>If so, do you think it's worth clarifying in the documentation?
Probably yes - but I'm not sure the current state of affairs is best... Do
other targets implement the same reduction order as x86? Other similar
reduction ops have high /low or even /odd variants. But they also do not reduce
the outputs.
Note DOT_PROD has the very same issue.
Richard.
>Thanks,
>Kyrill
gcc-6-20180509 is now available
Snapshot gcc-6-20180509 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180509/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 260099 You'll find: gcc-6-20180509.tar.xzComplete GCC SHA256=9bce0a94d7eeb0922ff4201ad51e45d30dd012b380f608822862f22fc48f289d SHA1=8e363c89969b8726b0185014b5362060fb5875a8 Diffs from 6-20180502 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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.
Noblelift at CEMAT 2018, see what's new! --Noblelift E-Newsletter
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=218fb2531d&e=8d69277303 Noblelift at CEMAT 2018 Hannover, Germany https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=3ca9d9285f&e=8d69277303 Noblelift @ CeMAT 2018 in Hannover Germany The biggest exhibition for mataerial handling industry--CEMAT, was taking place on April 23-27 as part of the Hannover Messe – one of the world’s largest and best-known industrial events. With a booth of 249㎡ located at Hall 26-F09, Noblelift showcased its latest range N series Class 3 trucks and Class 1 trucks, as well as the revolutionary Easy Mover which is designed to replace applications of hand pallet trucks at an affordable cost. Visitors will be able to gain an insight into Noblelift' s approach to supply reliable products with great quality as well as affordable cost, by using the most well-known brands for key compotnents such as Drive unit, Controller as well as Hydraulic unit., combining with the manufacturing in China. An example of the new N series Class 3 trucks: ·German Drive unit with high speed at 7/8KM/H for high efficiency ·Optimized design with smallest turning raidus for ride-on stackers in the industry ·Various options such as Proportional Lift, EPS, Side Battery Extraction, Pin-code Panel and more To see more about Noblelift at CEMAT 2018 and welcome to inqure to our products and be our dealers! https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=9b44f9a635&e=8d69277303 ` ** https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=44b36ef84d&e=8d69277303 https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=5002f79914&e=8d69277303 https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=9e3b8e77d2&e=8d69277303 https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=fcf234989c&e=8d69277303 Hand Pallet Trucks (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=9a18e14d93&e=8d69277303) https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=5c584c9153&e=8d69277303 Manual Stackers (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=4aca40d93d&e=8d69277303) https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=c5b9673b22&e=8d69277303 Electric Pallet Trucks (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=90162c0901&e=8d69277303) https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=8a4b854195&e=8d69277303 Electric Stackers (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=51a5d47fbe&e=8d69277303) https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=1d9a43c605&e=8d69277303 Electric Forklifts (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=6dde1f13ce&e=8d69277303) https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=d8523df383&e=8d69277303 Aerial Work Platforms (https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=256709e08f&e=8d69277303) Noblelift Equipment is the leading manufacturer of material handling equipments in China, with more than 20 years offering the full range of the material handling equipments from manual pallet tucks, stackers, to electric pallet trucks & stackers, Forklifts, manual and electric lift tables & platforms and more, we offer the biggest range of the equipments in the business. Noblelift was public-listed in Shanghai Stock Exchange(SSE) on Jan.28th, 2015. To know more about Noblelif, please visit www.noblelift.com. https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=3826cb71a9&e=8d69277303 Tel: 86-572-6210817 6210311 Email: sa...@noblelift.com (mailto:sa...@noblelift.com) www.noblelift.com www.noblelift.us This email was sent to gcc@gcc.gnu.org (mailto:gcc@gcc.gnu.org) why did I get this? (https://noblelift.us10.list-manage.com/about?u=e8aec7d772de62b3b6c40316a&id=df20522972&e=8d69277303&c=a3af634187) unsubscribe from this list (https://noblelift.us10.list-manage.com/unsubscribe?u=e8aec7d772de62b3b6c40316a&id=df20522972&e=8d69277303&c=a3af634187) update subscription preferences (https://noblelift.us10.list-manage.com/profile?u=e8aec7d772de62b3b6c40316a&id=df20522972&e=8d69277303) Noblelift Equipment . #528 Changzhou Road . Changxing, Zhejiang 313100 . China
