On Wed, 9 Jan 2019, Jakub Jelinek wrote:
> On Wed, Jan 09, 2019 at 11:10:25AM -0500, David Malcolm wrote:
> > extern void vf1()
> > {
> >#pragma vectorize enable
> >for ( int i = 0 ; i < 32768 ; i++ )
> > data [ i ] = std::sqrt ( data [ i ] ) ;
> > }
> >
> > Compiling on this x86_64
On 09.01.19 10:50, Andrew Haley wrote:
On 1/9/19 9:45 AM, Kyrill Tkachov wrote:
There's plenty of work being done on auto-vectorisation in GCC.
Auto-vectorisation is a performance optimisation and as such is not really
a user-visible feature that absolutely requires user documentation.
I don't
On Sat, Jan 05, 2019 at 06:02:08PM +0100, Daniel Marjamäki wrote:
> > I think the indentation warnings should catch that?
>
> I get this:
>
> void f()
> {
> }
> } // <- error: expected identifier or '(' before '}' token
>
> I ran with -Wall -Wextra -pedantic and did not see a indentation
> war
On 10/01/2019 08:19, Richard Biener wrote:
> On Wed, 9 Jan 2019, Jakub Jelinek wrote:
>
>> On Wed, Jan 09, 2019 at 11:10:25AM -0500, David Malcolm wrote:
>>> extern void vf1()
>>> {
>>>#pragma vectorize enable
>>>for ( int i = 0 ; i < 32768 ; i++ )
>>> data [ i ] = std::sqrt ( data [
On Thu, 10 Jan 2019 at 09:25, Kay F. Jahnke wrote:
> Documentation is absolutely essential. If there is lots of development
> in autovectorization, not documenting this work in a way users can
> simply find is - in my eyes - a grave omission. The text
> 'Auto-vectorization in GCC' looks like it has
Hello,
I am trying to assess an idea and whether it is possible to implement a
certain idea as a gcc plugin. I look over some of the information on the
web and the gcc internals documentation but I cannot still figure out some
basic things concerning manipulating GIMPLE in a plugin.
1) How does o
Can we remove __has_include__?
Its availability results in code which is needlessly non-portable
because for some reason, people write __has_include__ instead of
__has_include. (I don't think there is any difference.)
Thanks,
Florian
On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
> Can we remove __has_include__?
No.
> Its availability results in code which is needlessly non-portable
> because for some reason, people write __has_include__ instead of
> __has_include. (I don't think there is any difference.)
_
* Jakub Jelinek:
> On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
>> Can we remove __has_include__?
>
> No.
>
>> Its availability results in code which is needlessly non-portable
>> because for some reason, people write __has_include__ instead of
>> __has_include. (I don't think
On Thu, Jan 10, 2019 at 03:35:14PM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
> >> Can we remove __has_include__?
> >
> > No.
> >
> >> Its availability results in code which is needlessly non-portable
> >> because for some
Snapshot gcc-7-20190110 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
Hi,
(pls CC me when replying because I am not subscriber)
I met an interesting phenomenon when looking into linux kernel
compilation, it can be simply summarized as following: in
arch/x86/boot/compressed, memcpy is defined as __builtin_memcpy, while
also implemented as a function. But when using m
12 matches
Mail list logo
