Can we vectorize the code below ?

2019-06-11 Thread Li Jia He
Hi, I recently did some analysis on the automatic vectorization of gcc, I found that singed char can not be vectorized in the following code. --- #define ITERATIONS 100 #if defined(do_reduce_signed_char) #define TYPE signed char #elif defined(do_reduce_unsigned_char) #define TYPE unsigned

Re: Preventing ISO C errors when using macros for builtin types

2019-06-11 Thread Segher Boessenkool
Hi Jozef, On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote: > Thanks for the pointers, they've put me on the right track I think. > > It doesn't look like we can create the new type in the msp430 backend - the > SIZE_TYPE macro is examined quite early and only a couple of basic b

Re: Preventing ISO C errors when using macros for builtin types

2019-06-11 Thread Jozef Lawrynowicz
On Mon, 10 Jun 2019 17:09:10 -0500 Segher Boessenkool wrote: > On Mon, Jun 10, 2019 at 08:58:00PM +0100, Jozef Lawrynowicz wrote: > > On Mon, 10 Jun 2019 13:32:42 -0500 > > Segher Boessenkool wrote: > > > That is not a fix, that is sweeping the problem under the rug. > > > > > > As a somewhat

The 7th HelloLLVM / HelloGCC social in China: Shanghai, June 22, 2019

2019-06-11 Thread 吴伟
Hi all, The 7th HelloLLVM / HelloGCC social in China will happen on June 22, 2019. The location is at Shanghai. Everyone interested in LLVM/GCC/Toolchain related projects is invited to join. Event details is at https://mp.weixin.qq.com/s/ErxD4BwSRgTYRuErHCPMJQ BoF style. Presentations are welc

Re: alloca (0) in include/libiberty.h

2019-06-11 Thread Jakub Jelinek
On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote: > On Tue, 11 Jun 2019, Martin Liška wrote: > > > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > > properly > > guarded within: > > > > # ifdef C_ALLOCA > > alloca (0); > > # endif > > > > and then I

Re: alloca (0) in include/libiberty.h

2019-06-11 Thread Michael Matz
Hi, On Tue, 11 Jun 2019, Martin Liška wrote: > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > properly > guarded within: > > # ifdef C_ALLOCA > alloca (0); > # endif > > and then I noticed 2 more occurrences in gdb that break build right now: > > gdb/regcach

Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Jonathan Wakely
On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote: > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote: > > > > Hi! > > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > > wrote: > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > > > wrote: > > > > We have found that the Git

Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Jonathan Wakely
On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge wrote: > > Hi! > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > wrote: > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > > wrote: > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > > the actual GCC 9.1 rel

Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Thomas Schwinge
Hi! On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely wrote: > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > as well as 'svn+ssh

Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Jonathan Wakely
On Tue, 11 Jun 2019 at 16:18, Jonathan Wakely wrote: > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > > > Hi! > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > > as well as 's

Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Jonathan Wakely
On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge wrote: > > Hi! > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to > the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > r272156) would

Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

2019-06-11 Thread Thomas Schwinge
Hi! We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to the actual GCC 9.1 release. The GCC 9.1 release (as per 'gcc-9.1.0.tar' as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', r272156) would correspond to Git commit 3defceaa1a2987fa90296abfbcc85d7e9ad59684

Re: On-Demand range technology [6/5] - Integration

2019-06-11 Thread Richard Biener
On Fri, Jun 7, 2019 at 4:54 PM Andrew MacLeod wrote: > > On 6/7/19 8:25 AM, Richard Biener wrote: > > On Wed, Jun 5, 2019 at 10:56 PM Andrew MacLeod wrote: > >> After the various discussions, I've evaluated how I think everything can > >> fit together, so this is my proposal for integration with

Re: alloca (0) in include/libiberty.h

2019-06-11 Thread Martin Liška
On 6/11/19 9:49 AM, Martin Liška wrote: > gdb/regcache.c: alloca (0); > gdb/top.c: alloca (0); There's a PR for these: https://sourceware.org/bugzilla/show_bug.cgi?id=24653 Martin

Re: alloca (0) in include/libiberty.h

2019-06-11 Thread Martin Liška
On 6/10/19 1:54 PM, Andrew Haley wrote: > On 6/10/19 8:24 AM, Martin Liška wrote: > >> I've just noticed that we have couple of alloca (0) in libiberty: >> >> #ifndef REGEX_MALLOC >> # ifdef C_ALLOCA >> alloca (0); >> # endif >> #endif >> >> If I'm correct the value 0 has a special meaning t