gcc-7-20190321 is now available

2019-03-21 Thread gccadmin
Snapshot gcc-7-20190321 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190321/ 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

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Jakub Jelinek
On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > Hmm, I am curious. How strongly would gcc assume x is 0? If x is not 0, then it is undefined behavior and anything can happen, so yes, it can assume x is 0, sometimes gcc does that, sometimes not, it is not required to do tha

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Allan Sandfeld Jensen
On Montag, 11. März 2019 10:14:49 CET Jakub Jelinek wrote: > On Mon, Mar 11, 2019 at 08:49:30AM +, Moritz Strübe wrote: > > Considering that C11 6.5.7#3 ("If the value of the right operand > > is negative or is greater than or equal to the width of the promoted > > left operand, the be

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Andrew Haley
On 3/21/19 8:53 AM, Moritz Strübe wrote: > Hey. > > Am 20.03.2019 um 18:36 schrieb Andrew Haley: >> On 3/20/19 2:08 PM, Moritz Strübe wrote: >>> Ok, I played around a bit. Interestingly, if I set >>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the >>> compiler detects that it will a

Re: Indicating function exit points in debug data

2019-03-21 Thread Justin Paston-Cooper
On Thu, 21 Mar 2019 at 09:11, Justin Paston-Cooper wrote: > > On Thu, 21 Mar 2019 at 08:23, Richard Biener > wrote: > > > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > > > > > "Segher" == Segher Boessenkool writes: > > > > > > >> Section 6.2.5.2 outlines the line number informa

Re: Indicating function exit points in debug data

2019-03-21 Thread Justin Paston-Cooper
On Thu, 21 Mar 2019 at 08:23, Richard Biener wrote: > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > > > "Segher" == Segher Boessenkool writes: > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Moritz Strübe
Hey. Am 20.03.2019 um 18:36 schrieb Andrew Haley: > On 3/20/19 2:08 PM, Moritz Strübe wrote: >> Ok, I played around a bit. Interestingly, if I set >> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the >> compiler detects that it will always trap, and optimizes the code >> accordingly (

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Richard Biener
On Thu, Mar 21, 2019 at 9:25 AM Alexander Monakov wrote: > > On Thu, 21 Mar 2019, Richard Biener wrote: > > > Maybe an example would help. > > > > > > Consider this code: > > > > > > for (int i = start; i < limit; i++) { > > > foo(i * 5); > > > } > > > > > > Should GCC be entitled to turn it int

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Alexander Monakov
On Thu, 21 Mar 2019, Richard Biener wrote: > > Maybe an example would help. > > > > Consider this code: > > > > for (int i = start; i < limit; i++) { > > foo(i * 5); > > } > > > > Should GCC be entitled to turn it into > > > > int limit_tmp = i * 5; > > for (int i = start * 5; i < limit_tmp; i +=

Re: Indicating function exit points in debug data

2019-03-21 Thread Richard Biener
On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > "Segher" == Segher Boessenkool writes: > > >> Section 6.2.5.2 outlines the line number information state machine's > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > >> is: > > Segher> How should this work with sh

Re: GCC turns &~ into | due to undefined bit-shift without warning

2019-03-21 Thread Richard Biener
On Wed, Mar 20, 2019 at 6:36 PM Andrew Haley wrote: > > On 3/20/19 2:08 PM, Moritz Strübe wrote: > > > > Ok, I played around a bit. Interestingly, if I set > > -fsanitize=udefined and -fsanitize-undefined-trap-on-error the > > compiler detects that it will always trap, and optimizes the code > > a