Re: A bug in vrp_meet?

On Sun, May 5, 2019 at 11:09 PM Eric Botcazou wrote: > > > I have now applied this variant. > > You backported it onto the 8 branch on Friday: > > 2019-05-03 Richard Biener > > Backport from mainline > [...] > 2019-03-07 Richard Biener > > PR tree-optimization/89595 >

Re: A bug in vrp_meet?

> I have now applied this variant. You backported it onto the 8 branch on Friday: 2019-05-03 Richard Biener Backport from mainline [...] 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take

Re: A bug in vrp_meet?

On Tue, Mar 19, 2019 at 8:53 PM Jeff Law wrote: > > On 3/6/19 3:05 AM, Richard Biener wrote: > > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote: > >> > >> On 3/5/19 7:44 AM, Richard Biener wrote: > >> > >>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE > >>> the MAX_EXP

Re: A bug in vrp_meet?

On 3/6/19 3:05 AM, Richard Biener wrote: > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote: >> >> On 3/5/19 7:44 AM, Richard Biener wrote: >> >>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE >>> the MAX_EXPR introduced by folding makes it somewhat ugly. >>> >>> Bootstrap

Re: A bug in vrp_meet?

On Wed, Mar 6, 2019 at 11:05 AM Richard Biener wrote: > > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote: > > > > On 3/5/19 7:44 AM, Richard Biener wrote: > > > > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE > > > the MAX_EXPR introduced by folding makes it somewhat

Re: A bug in vrp_meet?

On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote: > > On 3/5/19 7:44 AM, Richard Biener wrote: > > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE > > the MAX_EXPR introduced by folding makes it somewhat ugly. > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in pr

Re: A bug in vrp_meet?

On 3/5/19 7:44 AM, Richard Biener wrote: > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE > the MAX_EXPR introduced by folding makes it somewhat ugly. > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > Any ideas how to make it less so? I can split o

Re: A bug in vrp_meet?

On 3/4/19 4:45 AM, Richard Biener wrote: > On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote: >> >> >> On Mar 1, 2019, at 1:25 PM, Richard Biener >> wrote: >> >> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao >> wrote: >> >> Jeff, >> >> thanks a lot for the reply. >> >> this is really helpful.

Re: A bug in vrp_meet?

On 3/1/19 10:49 AM, Qing Zhao wrote: > Jeff, > > thanks a lot for the reply. > > this is really helpful. > > I double checked the dumped intermediate file for pass “dom3", and > located the following for _152: > > BEFORE the pass “dom3”, there is no _152, the corresponding Block > looks lik

Re: A bug in vrp_meet?

On Tue, Mar 5, 2019 at 11:44 AM Richard Biener wrote: > > On Tue, Mar 5, 2019 at 10:48 AM Richard Biener > wrote: > > > > On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote: > > > > > > Hi, Richard, > > > > > > > On Mar 4, 2019, at 5:45 AM, Richard Biener > > > > wrote: > > > >> > > > >> It looks

Re: A bug in vrp_meet?

On Tue, Mar 5, 2019 at 10:48 AM Richard Biener wrote: > > On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote: > > > > Hi, Richard, > > > > > On Mar 4, 2019, at 5:45 AM, Richard Biener > > > wrote: > > >> > > >> It looks like DOM fails to visit stmts generated by simplification. Can > > >> you ope

Re: A bug in vrp_meet?

On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote: > > Hi, Richard, > > > On Mar 4, 2019, at 5:45 AM, Richard Biener > > wrote: > >> > >> It looks like DOM fails to visit stmts generated by simplification. Can > >> you open a bug report with a testcase? > >> > >> > >> The problem is, It took me q

Re: A bug in vrp_meet?

Hi, Richard, > On Mar 4, 2019, at 5:45 AM, Richard Biener wrote: >> >> It looks like DOM fails to visit stmts generated by simplification. Can you >> open a bug report with a testcase? >> >> >> The problem is, It took me quite some time in order to come up with a small >> and independent tes

Re: A bug in vrp_meet?

Richard, thanks a lot for your suggested fix. I will try it. Qing > On Mar 4, 2019, at 5:45 AM, Richard Biener wrote: > > On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote: >> >> >> On Mar 1, 2019, at 1:25 PM, Richard Biener >> wrote: >> >> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao

Re: A bug in vrp_meet?

On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote: > > > On Mar 1, 2019, at 1:25 PM, Richard Biener wrote: > > On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao wrote: > > Jeff, > > thanks a lot for the reply. > > this is really helpful. > > I double checked the dumped intermediate file for pass “d

Re: A bug in vrp_meet?

> On Mar 1, 2019, at 1:25 PM, Richard Biener wrote: > > On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao > wrote: >> Jeff, >> >> thanks a lot for the reply. >> >> this is really helpful. >> >> I double checked the dumped intermediate file for pass “dom3", and >>

Re: A bug in vrp_meet?

On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao wrote: >Jeff, > >thanks a lot for the reply. > >this is really helpful. > >I double checked the dumped intermediate file for pass “dom3", and >located the following for _152: > >BEFORE the pass “dom3”, there is no _152, the corresponding Block >

Re: A bug in vrp_meet?

Jeff, thanks a lot for the reply. this is really helpful. I double checked the dumped intermediate file for pass “dom3", and located the following for _152: BEFORE the pass “dom3”, there is no _152, the corresponding Block looks like: [local count: 12992277]: _98 = (int) ufcMSR_52(D

Re: A bug in vrp_meet?

On 2/28/19 10:05 AM, Qing Zhao wrote: > Hi, > > I have been debugging a runtime error caused by value range propagation. and > finally located to the following gcc routine: > > vrp_meet_1 in gcc/tree-vrp.c > > > /* Meet operation for value ranges. Given two value ranges VR0 and >VR1,

Re: A bug (?) with inline functions at O0: undefined reference

On Fri, Mar 06, 2015 at 07:12:48PM +0300, Ilya Verbin wrote: > Hi All, > > I've discovered a strange behaviour on trunk gcc, here is the reproducer: > > inline int foo () > { > return 0; > } > > int main () > { > return foo (); > } > > $ gcc main.c > /tmp/ccD1LeXo.o: In function `main': > m

Re: A bug (?) with inline functions at O0: undefined reference

On Fri, 6 Mar 2015, Ilya Verbin wrote: I've discovered a strange behaviour on trunk gcc, here is the reproducer: inline int foo () { return 0; } int main () { return foo (); } $ gcc main.c /tmp/ccD1LeXo.o: In function `main': main.c:(.text+0xa): undefined reference to `foo' collect2: error:

RE: A bug on 32-bit host?

eng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: A bug on 32-bit host? > > "Bingfeng Mei" writes: > > > /* Obtain value by shifting and set zeros for remaining part*/ > > if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT) > &

Re: A bug on 32-bit host?

"Bingfeng Mei" writes: > /* Obtain value by shifting and set zeros for remaining part*/ > if((bitpos + bitsize) > HOST_BITS_PER_WIDE_INT) > high = (v >> (HOST_BITS_PER_WIDE_INT - bitpos)) > & ((1 << (bitpos + bitsize - HOST_BITS_PER_WIDE_INT)) - 1); That is

Re: A bug?

Sebastian Redl wrote: > Michel Van den Bergh wrote: >> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu >> 8.10 (Intel core2 duo) >> I get >> >> stest.c: In function ‘main’: >> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 >> has type ‘char[20]’ >> >> The

Re: A bug

The C standard says no such thing; only integer promotions are performed. (See 6.5.2.2 of the C99 final draft.) Ok one more question. Why does this not give a warning then (and runs fine)? #include struct Hello { char world[20]; }; struct Hello s(){ struct Hello r; r.wor

Re: A bug?

On Tuesday 2008-12-16 18:01, Sebastian Redl wrote: > Michel Van den Bergh wrote: >> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10 >> (Intel core2 duo) >> I get >> >> stest.c: In function ‘main’: >> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 ha

Re: A bug?

Michel Van den Bergh wrote: That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10 (Intel core2 duo) I get stest.c: In function ‘main’: stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char[20]’ The resulting binary does not segfault but prin

Re: A bug?

That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10 (Intel core2 duo) I get stest.c: In function ‘main’: stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char[20]’ The resulting binary does not segfault but prints garbage (probably uniniti

Re: A bug?

> Hi, > > The following program segfaults when compiled with gcc > but runs fine when compiled with g++ or icc (the intel C compiler) > > #include > struct Hello { > char world[20]; > }; > struct Hello s(){ > struct Hello r; > r.world[0]='H'; > r.world[1]='\0'; >

Re: A bug ( ? ) and a question

On Mar 5, 2006, at 11:15 AM, Mike Stump wrote: The string is a bit trickier, strncpy (newbuf, buf+30, 40); newbuf [70] = 0; [40] = 0; I meant of course.

Re: A bug ( ? ) and a question

First, let me say this is the wrong list for how to program in C++, comp.lang.c++ would be better, or even comp.lang.c would be better. gcc-help would the a second choice. On Mar 5, 2006, at 8:47 AM, Nieuwenhuizen, JK wrote: cout << "Done"; This doesn't output anything immediately. E

Re: A bug in the current released GCC 4.0.0

On Apr 23, 2005, at 6:35 AM, ~{Dt>Clb~} wrote: Hello, I casually found a bug in the current released GCC 4.0.0. However, I have located the wrong code, and it's very easy to be fixed, so it's not necessary to still submit a bug report. See the following artificial C++ code: int *x;