Re: PR68425 warn message enhancement

On 19 September 2017 at 01:35, Martin Sebor wrote: > On 09/18/2017 01:06 PM, Prasad Ghangal wrote: >> >> Hi, >> >> This was discussed a few time ago in this email thread : >> https://gcc.gnu.org/ml/gcc/2016-02/msg00235.html >> >> As per the discussion, the attached patch produces warning message f

Re: GCC extension for atomic access to members

On 09/18/2017 10:07 PM, Torvald Riegel wrote: On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: I would like to see the GCC project to document that if the address of a member is taken, this does not constitute an access to the object as a whole. That is, in the following code: #include

Re: [RFC] type promotion pass

Hi Steve, On 19 September 2017 at 05:45, Steve Ellcey wrote: > On Mon, 2017-09-18 at 23:29 +0530, Prathamesh Kulkarni wrote: >> >> Hi Steve, >> The patch is currently based on r249469. I will rebase it on ToT and >> look into the build failure. >> Thanks for pointing it out. >> >> Regards, >> Pra

Re: Redundant sign-extension instructions on RISC-V

Hi, I’ve spun an alternative version of RISC-V GCC which preserves RV64 ABI sign extended canonicalisation for passed values but keeps values in SImode until return. https://github.com/michaeljclark/riscv-gcc/commits/riscv-gcc-7-mc These are the changes: - #undef PROMOTE_MODE

Re: GCC extension for atomic access to members

On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: > I would like to see the GCC project to document that if the address of a > member is taken, this does not constitute an access to the object as a > whole. > > That is, in the following code: > > #include > > struct S { >_Atomic in

Re: PR68425 warn message enhancement

On 09/18/2017 01:06 PM, Prasad Ghangal wrote: Hi, This was discussed a few time ago in this email thread : https://gcc.gnu.org/ml/gcc/2016-02/msg00235.html As per the discussion, the attached patch produces warning message for excess elements in array initialization along with number of expecte

Re: [RFC] type promotion pass

On Mon, 2017-09-18 at 23:29 +0530, Prathamesh Kulkarni wrote: >  > Hi Steve, > The patch is currently based on r249469. I will rebase it on ToT and > look into the build failure. > Thanks for pointing it out. > > Regards, > Prathamesh OK, I applied it to that version successfully.  The thing I wa

PR68425 warn message enhancement

Hi, This was discussed a few time ago in this email thread : https://gcc.gnu.org/ml/gcc/2016-02/msg00235.html As per the discussion, the attached patch produces warning message for excess elements in array initialization along with number of expected and extra elements and underlined extra elemen

Re: [RFC] type promotion pass

On 18 September 2017 at 23:12, Steve Ellcey wrote: > On Fri, 2017-09-15 at 12:22 +, Wilco Dijkstra wrote: > > Wilco or Prathamesh, > > I could not apply this patch (cleanly) to ToT. match.pd did not apply, > I think I fixed that. The cfgexpand.c patch applied but will not > build. I get thi

Re: [RFC] type promotion pass

On Fri, 2017-09-15 at 12:22 +, Wilco Dijkstra wrote: Wilco or Prathamesh, I could not apply this patch (cleanly) to ToT.  match.pd did not apply, I think I fixed that.  The cfgexpand.c patch applied but will not build.  I get this error: ../../../src/gcc/gcc/cfgexpand.c: In function ‘rtx_def

Re: Infering that the condition of a for loop is initially true?

Joseph Myers writes: > On Mon, 18 Sep 2017, Niels Möller wrote: >> I'm suggesting that with -DNDEBUG, assert(x) should let the compiler >> assume that x is true, but without producing any code to evaluate it at >> runtime. > > There's no requirement that x is even a valid expression with -DNDEBU

Re: GCC aliasing extension for C

On September 18, 2017 4:12:07 PM GMT+02:00, Andrew Haley wrote: >On 18/09/17 10:48, Florian Weimer wrote: >> Is this a property of the char type, or would other types work as >well, >> for example, double or long double? > >It has to be a character type, I believe. It can be any type. All store

Re: Infering that the condition of a for loop is initially true?

On Mon, 18 Sep 2017, Niels Möller wrote: > Andreas Schwab writes: > > > The problem is that assert is not allowed to evaluate the expression > > with -DNDEBUG, and side effects must not be carried out. > > I'm suggesting that with -DNDEBUG, assert(x) should let the compiler > assume that x is t

Re: GCC aliasing extension for C

On 18/09/17 10:48, Florian Weimer wrote: > Is this a property of the char type, or would other types work as well, > for example, double or long double? It has to be a character type, I believe. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF

GCC extension for atomic access to members

I would like to see the GCC project to document that if the address of a member is taken, this does not constitute an access to the object as a whole. That is, in the following code: #include struct S { _Atomic int a; int b; }; int load_a (struct S *p) { return atomic_load_explicit (&

Re: Infering that the condition of a for loop is initially true?

> I'm suggesting that with -DNDEBUG, assert(x) should let the compiler > assume that x is true, but without producing any code to evaluate it at > runtime. > > E.g, given > > void foo (size_t n) > { > size_t i; > assert (n < 17); > for (i = n; i < 17; i++) > { ... } > } I t

Re: Infering that the condition of a for loop is initially true?

Andreas Schwab writes: > The problem is that assert is not allowed to evaluate the expression > with -DNDEBUG, and side effects must not be carried out. I'm suggesting that with -DNDEBUG, assert(x) should let the compiler assume that x is true, but without producing any code to evaluate it at ru

Re: Infering that the condition of a for loop is initially true?

Jeff Law writes: >> 1. Does gcc attempt to do this optimization? > Yes. It happens as a side effect of jump threading and there are also > dedicated passes to rotate the loop. > >> >> 2. If it does, how often does it succeed on loops in real programs? > Often. The net benefit is actually smal

Re: Infering that the condition of a for loop is initially true?

On Sep 18 2017, ni...@lysator.liu.se (Niels Möller) wrote: > I imagine the C standard might specify that assert "completely > disappears" if -DNDEBUG is defined. But maybe there's room for a > -fstrict-assert optimization flag, to let assert always guide > optimization? The problem is that assert

Re: Infering that the condition of a for loop is initially true?

Marc Glisse writes: > assert is not what you want, since it completely disappears with > -DNDEBUG. clang has __builtin_assume, with gcc you want a test and > __builtin_unreachable. Replacing your assert with > if(n==0)__builtin_unreachable(); To me, it would make sense to have assert expand to s

GCC aliasing extension for C

I know that GCC implements a C extension (which is more or less required by POSIX) which allows you to define a buffer char buf[1024]; and then allocate objects from that (assuming that the buffer is sufficiently large and the pointers to subobjects are suitably aligned). In short, it is p