Re: OpenACC in GCC - how does it not violate the license?

2013-11-16 Thread Dmitry Mikushin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alec, > Nvidia (IIRC, this was like a year ago though) don't even give out the instruction set for their GPUs I understand you don't want to bound to PTX virtual assembler, as it conversion to GPU native assembler relies on proprietary component.

Re: OpenACC in GCC - how does it not violate the license?

2013-11-16 Thread Jeff Law
On 11/16/13 21:58, Alec Teal wrote: Now while great, is this true!? Nvidia (IIRC, this was like a year ago though) don't even give out the instruction set for their GPUs, can we have GCC targeting closed things? Also there (must be and is) a Cuda runtime, wouldn't we need an open runtime to link

Re: Enable -Wreturn-type by default ?

2013-11-16 Thread Alec Teal
Who isn't compiling with -Wall and -Wextra? I do hope Clang ('though I don't use it) doesn't make it an error because not all functions have to return in C iirc. Alec On 13/11/13 16:42, Sylvestre Ledru wrote: Hello, I would like to propose the activation by default of -Wreturn-type. The ma

OpenACC in GCC - how does it not violate the license?

2013-11-16 Thread Alec Teal
Hey all, I got linked this by a friend today: http://www.mentor.com/embedded-software/blog/post/we-are-bringing-openacc-to-the-gnu-compiler-suite--8d06289f-c4e9-44c8-801b-7a11496e7300 It seems to suggest that GCC can target Nvidia GPUs To quote: or OpenACC 2.0 in GCC, , and generating assembly l

Spamming the gcc-testresults mailing list (or not).

2013-11-16 Thread Toon Moene
I have now got two of these: - - - - - - - - - 8< - - - - - - - - - 8< - - - - - - - - - Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : In an

Re: proposal to make SIZE_TYPE more flexible

2013-11-16 Thread Joseph S. Myers
On Sat, 16 Nov 2013, Richard Biener wrote: > >I did a scan through the gcc source tree trying to track down all the > >implications of this, and there were a lot of them, and not just the > >RID_* stuff. There's also the integer_types[] array (indexed by > >itk_*, which is its own mess) > > I do

Re: Vectorization: Loop peeling with misaligned support.

2013-11-16 Thread Ondřej Bílka
On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote: > "Ondřej Bílka" wrote: > >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote: > > IIRC what can still be seen is store-buffer related slowdowns when you have a > big unaligned store load in your loop. Thus aligning st

Re: proposal to make SIZE_TYPE more flexible

2013-11-16 Thread Richard Biener
DJ Delorie wrote: > >> Everything handling __int128 would be updated to work with a >> target-determined set of types instead. >> >> Preferably, the number of such keywords would be arbitrary (so I >suppose >> there would be a single RID_INTN for them) - that seems cleaner than >the >> system

Re: Vectorization: Loop peeling with misaligned support.

2013-11-16 Thread Richard Biener
"Ondřej Bílka" wrote: >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote: >> Also keep in mind that usually costs go up significantly if >> misalignment causes cache line splits (processor will fetch 2 lines). >> There are non-linear costs of filling up the store queue in modern >> o