[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #34 from dnovillo at redhat dot com 2006-04-12 14:09 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 08:20, rakdver at gcc dot gnu dot org wrote: > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view) > Patch to speed up update_ssa > Fails building libgcc with checking disabled on x86. Starting program: /notnfs/dnovillo/BLD-gcc-native/gcc/cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -mtune=generic -auxbase-strip libgcc/./_gcov.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes - -Wmissing-prototypes -Wold-style-definition -version -fPIC -o libgcov.s Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xb000 GNU C version 4.2.0 20060412 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060304 (Red Hat 4.1.0-3). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128991 Compiler executable checksum: 3c4ee7023c10209f81749c69d1323e23 Program received signal SIGSEGV, Segmentation fault. 0x0813d8f4 in bitmap_first_set_bit (a=0x86ec974) at /home/dnovillo/gcc/src/gcc/bitmap.c:595 595 bit_no = elt->indx * BITMAP_ELEMENT_ALL_BITS; (gdb) up #1 0x080da1da in set_livein_block (var=0xb7ce9034, bb=0xb7cc0d20) at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:486 486 int def_block_index = bitmap_first_set_bit (db_p->def_blocks); (gdb) up #2 0x080ddd3b in mark_use_interesting (var=0xb7ce9034, stmt=0xb7cd8f50, bb=0xb7cc0d20, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:1924 1924set_livein_block (var, bb); (gdb) #3 0x080dde71 in prepare_use_sites_for (name=0xb7ce9034, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:2045 2045 mark_use_interesting (name, stmt, bb, blocks, insert_phi_p); (gdb) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQooUTa2oAUaiwQRAkAIAKCE4Sy7b0HCuZXv2M6a0OP0EBrQWgCgg5CT 7er5u0KdZhzL7y6sHsLVZts= =B10i -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #36 from dnovillo at redhat dot com 2006-04-12 14:23 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 10:20, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > forgot to say: mostly untested patch, still work in progress :-) > Oh, OK. I got the impression you were submitting it. I'll wait for your final version then. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQ1sUTa2oAUaiwQRApY5AJ4v+ve2Yl2mkv8+nMVSo0XvOBEF0wCeOLKr aojItQJu1BeKQcMIwzfLKSM= =5Ole -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #6 from dnovillo at redhat dot com 2006-05-01 16:11 --- Subject: Re: [gomp] firstprivate not working properly with non-POD -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jakub at gcc dot gnu dot org wrote: > --- Comment #5 from jakub at gcc dot gnu dot org 2006-05-01 16:07 --- > We do need a barrier (well, in some cases with extra code we can avoid > it in some cases), in order to honor 2.8.3.4: > "If a list item appears in both firstprivate and lastprivate clauses, the > update > required for lastprivate occurs after all the initializations for > firstprivate." > Ah, yes, of course. Sorry about that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEVjMVUTa2oAUaiwQRAkViAJ4s5n62EohuFxCUWVQGZ1owtoSTcACfZR7i NgLf43AMmOQ0xLmnl89ZkYQ= =cjzg -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #7 from dnovillo at redhat dot com 2006-06-12 12:12 --- Subject: Re: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static mmitchel at gcc dot gnu dot org wrote on 06/05/06 18:37: > Diego, what say you? > Shouldn't COMPLETE_TYPE_P imply that we can compute the size of the type? That's the requisite we need in this case to emit the load from the volatile reference. Otherwise, we have no other choice but to throw it away. ISTM that if COMPLETE_TYPE_P had the right sizeof semantics, we wouldn't need the workaround added for 23167. The only thing the gimplifier can do in this case is throw the reference out, but -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties
--- Comment #4 from dnovillo at redhat dot com 2006-06-13 14:49 --- Subject: Re: gimplifying "return CONSTANT" creates unneeded temporaties dann at godzilla dot ics dot uci dot edu wrote on 06/13/06 10:42: > --- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13 > 14:42 --- > One of the issues with this PR and also 27800, 27809 and 27810 is that this > extra work/memory allocation done for a number of functions that are never > used: like all the inline functions present in the glibc headers. These > functions are thrown out after gimplification... > We need to strike a balance between the potential memory savings due to a more streamlined GIMPLE and the effort needed to get it. We should avoid anything that requires the gimplifier to build complex dataflow and/or duplicate existing optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug fortran/25219] [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE
--- Comment #4 from dnovillo at redhat dot com 2006-01-16 18:18 --- Subject: Re: [GOMP] ICE with SAVE attribute and (FIRST|LAST)PRIVATE On Monday 16 January 2006 12:40, jakub at gcc dot gnu dot org wrote: > ICEs the same. I can't reproduce this in the Fedora Core gcc though, > so I think this got fixed by > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01192.html > Dunno about its status, Diego, was it subsummed by your > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00668.html > patch? > No, it's unrelated. I've committed Aldy's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25219
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #13 from dnovillo at redhat dot com 2007-03-10 00:07 --- Subject: Re: Revision 121302 causes 30% performance regression hjl at lucon dot org wrote on 03/09/07 19:04: > --param max-aliased-vops=100 works: > OK, thanks. I'll add this PR to the mix then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #16 from dnovillo at redhat dot com 2007-04-05 13:15 --- Subject: Re: Floating point computation far slower for -mfpmath=sse bonzini at gnu dot org wrote on 04/05/07 08:03: > Is there a way to ensure ordering of PHI functions unlike what Uros's > dumps suggest? No. I also don't see how PHI ordering would affect out-of-ssa. It just emits copies. If the ordering of those copies is affecting things like register pressure, then RA should be looked at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug middle-end/19865] [4.0 Regression] ice / gnat bug detected.
--- Additional Comments From dnovillo at redhat dot com 2005-02-16 15:16 --- Subject: Re: [4.0 Regression] ice / gnat bug detected. pinskia at gcc dot gnu dot org wrote: > Is that what you want? > Yes, thanks. I can now reproduce this on my ppc box with your reduced test case. I'll take a look. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug
--- Additional Comments From dnovillo at redhat dot com 2005-02-21 19:33 --- Subject: Re: [PR tree-optimization/19786] fix alias grouping lossage Alexandre Oliva wrote: > PR tree-optimization/19786 > * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add one > tag to another's may-alias bitmap when adding to the other's list. > OK. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From dnovillo at redhat dot com 2005-02-25 01:05 --- Subject: Re: [4.0 regression] miscompilation of asm-declared registers hp at gcc dot gnu dot org wrote: > --- Additional Comments From hp at gcc dot gnu dot org 2005-02-25 00:59 > --- > I forgot to mention that this is the only suspect patch in this time-frame: > > + 2005-02-24 Diego Novillo <[EMAIL PROTECTED]> > + > + * tree-into-ssa.c: Re-organize internal functions. > + > + > I find this very hard to believe. The only thing this patch did is move text around the file. It added no code and removed no code. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From dnovillo at redhat dot com 2005-02-25 01:21 --- Subject: Re: [4.0 regression] miscompilation of asm-declared registers hp at gcc dot gnu dot org wrote: > I can certainly understand that a typo changed some assigmnent such that > asm-declared registers are mishandled. Pretty please. > I've had this patch in TCB for over 3 weeks now, but don't worry, I'll take a peek tomorrow. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Additional Comments From dnovillo at redhat dot com 2005-03-04 17:59 --- Subject: Re: RFE: add attribute to specify that a function never returns NULL giovannibajo at libero dot it wrote: > --- Additional Comments From giovannibajo at libero dot it 2005-03-04 > 17:53 --- > I don't object that this feature is indeed needed, but I would still like to > see a reduced testcase from Subversion which shows a bogus warning that could > be fixed with this attribute. > I have attached the pre-processed test case from Joe. > BTW, Diego, once ASSERT_EXPR becomes a generic node, can't just the C++ FE > uses > it to assert that the return value for a CALL_EXPR to an allocation function > is > non-zero? > The attribute would be enough. The FE need only set an ECF_ flag to the CALL_EXPR and the optimizers will pick it up from there. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 01:36
---
Subject: Re: alias analysis doesn't take into
account that variables that haven't their address taken can't alias arbitrary
MEMs
pinskia at gcc dot gnu dot org wrote:
> void g();
> int
> f(int s, int *a)
> {
> static int i;
> for (i = 0; i < 800; i++)
> {
> g();
> s += a[i];
> }
> return s;
> }
>
> But all of this needs to be on the tree level to be really effective.
>
This particular case is trivial to fix inside the tree optimizers.
Variable 'i' is a local variable with static storage that is not upward
exposed (i.e., it has no default definition).
Once you recognize that, you can safely flip the TREE_STATIC bit on the
variable and expose it as a gimple register.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 03:16 --- Subject: Re: The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation. pinskia at gcc dot gnu dot org wrote: > Why isn't the tree level loop IV-OPTs doing this? > Because variable i is static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
[Bug rtl-optimization/20376] The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation.
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 03:20 --- Subject: Re: The missed-optimization of general induction variables in the new rtl-level loop optimizer cause performance degradation. Andrew Pinski wrote: > I think you commenting on the wrong bug. > Indeed. I misread 20376 as 20367. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
[Bug tree-optimization/20962] copyprop dump files have wrong names
--- Additional Comments From dnovillo at redhat dot com 2005-04-12 04:15 --- Subject: Re: New: copyprop dump files have wrong names On Tue, Apr 12, 2005 at 03:48:10AM -, kazu at cs dot umass dot edu wrote: > test.c.t21.copyprop1 > test.c.t26.copyprop2 > test.c.t40.copyprop3 > test.c.t55.copyprop5 > test.c.t66.copyprop4 > > Note that the last two lines are sort of swapped. > t55 and t66 should have copyprop4 and copyprop6, respectively. > That's because .t66.copyprop5 is invoked as a sub-pass of pass_loop, which runs before the last copyprop run. An artifact of how the dynamic numbering of the passes is computed. Not sure how to fix it off-hand. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20962
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From dnovillo at redhat dot com 2005-04-13 13:03 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote: > That mental model doesn't work right now with the way DOM & the > jump threader because they are too tightly intertwined. > The link that you have still not shown me is why doesn't this mental model work for the jump threader. That's why I said that I need to run the threader myself and see why it needs all these additional crutches. If the code has been cleaned up of redundancies, copies propagated, names have known values and ranges are set, then I don't see why we would need all the extra baggage. > The iteration step we see today would turn into a worklist. > ie, after we thread jumps, we walk through the IL for PHIs > which represent a copy that can be propagated. > Ah, here's something specific I don't follow. Why would you have these PHIs anymore? If all the arguments were ultimately equivalent, then the various propagators are bound to have removed them. If not, that sounds like a bug in them. > What's nice about this is the bulk of DOM as we know it today > disappears along with the expensive iteration in the case when > jumps are threaded. We just need the right APIs for copy > propagation and value handles. > Again, why? The propagators are supposed to have done this already. They are all supposed to work in conditional regions. > We could still potentially use ASSERT_EXPRs to encode > information about edge equivalences, though we probably would > still want the ASSERT_EXPR to appear as statement rather than > the RHS of a MODIFY_EXPR. > Odd, the nice thing about assertions being on the RHS is that you pin their result to a specific SSA name that you then get to use at every place naturally dominated by the assertion. If you could give me a concrete test case that I could sink my teeth in, that'd be great. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug tree-optimization/21029] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From dnovillo at redhat dot com 2005-04-14 20:18 --- Subject: Re: New: vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances On Thu, Apr 14, 2005 at 08:16:09PM -, aoliva at gcc dot gnu dot org wrote: > Unfortunately, vrp seldom kicks in, so it's a bit difficult to > duplicate the problem. > Hmm? VRP is automatically enabled at -O2 and higher. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/24028] CCP is broken
--- Additional Comments From dnovillo at redhat dot com 2005-09-23 12:30 --- Subject: Re: CCP is broken On September 23, 2005 01:29, kazu at gcc dot gnu dot org wrote: > --- Additional Comments From kazu at gcc dot gnu dot org > 2005-09-23 05:29 --- The reason why CCP thinks that the result of > the PHI node is varying is because ccp_initialize thinks that a PHI > node is varying if at least one of PHI argument is varying. > This is very related to 23588. The heuristics to speed up propagation are crippling the propagator. likely_value and ccp_initialize are the main functions to start fixing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24028
[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP
--- Additional Comments From dnovillo at redhat dot com 2005-09-30 13:27 --- Subject: Re: [4.1 Regression] wrong code due to VRP On September 30, 2005 09:24, jakub at gcc dot gnu dot org wrote: > 2005-09-30 13:24 --- Jim's patch certainly worked for me. But > the question is if we can do more. If not anti-range and > limit_vr->min == limit_vr->max, then we at least can create > anti-range from TYPE_MIN_VALUE to TYPE_MAX_VALUE. Right. That's what I'm trying to determine ATM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
[Bug tree-optimization/24141] [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965
--- Comment #14 from dnovillo at redhat dot com 2005-10-02 02:11 --- Subject: Re: [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965 On October 1, 2005 13:00, rguenth at gcc dot gnu dot org wrote: > Diego, you only fixed the ICE, not the wrong-code. Please continue > with 24142 which tracks the wrong-code issue. OK, thanks for testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24141
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #8 from dnovillo at redhat dot com 2005-10-12 14:16 --- Subject: Re: C++ FE emitting assignments to read-only global symbols On Tuesday 11 October 2005 17:07, mmitchel at gcc dot gnu dot org wrote: > Diego, will this allow you to reactivate your optimization? And, if so, > what kind of code will be improved? > Thanks Mark. The underlying code has shifted in the interim. There was another bug that would cause us to ICE with code that specifically casted away constness. We now should get this micro-optimization on the cases we cared for (call-clobbering situations, mostly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #10 from dnovillo at redhat dot com 2005-10-12 15:00 --- Subject: Re: C++ FE emitting assignments to read-only global symbols On Wednesday 12 October 2005 10:55, mark at codesourcery dot com wrote: > OK, so my patch is no longer directly useful then? (It still seems like > it would be an improvement in the abstract, in that assigning to > TREE_READONLY variables is evil, but if it won't have any immediate > tangible benefit, I'll leave this for 4.2.) > Leaving it for 4.2 should be fine. It is only a micro-optimization and I only noticed it by chance because we were being too aggressive with it. Yes, it's nice to stop the FE from generating stores to TREE_READONLY, but it's not the end of the world for 4.1. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 --- Subject: Re: New: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: > I'd expect that i is threadprivate in file1.c and file2.c. > But you have to mark it so in both places. > Am I misreading the OpenMP spec or is this a bug in the frontends? > I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: "If a variable is specified in a threadprivate directive in one translation unit, it must be specified in a threadprivate directive in every translation unit in which it is declared." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #4 from dnovillo at redhat dot com 2005-10-20 17:07 --- Subject: Re: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de > Doesn't translation unit cover the include file? > > But anyway. How should I mark it threadprivate in file2.c? > Adding "#pragma omp threadprivate (i)" before or after "int i;" > doesn't work. > Indeed, sorry about that. I misread your code. I'll take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #5 from dnovillo at redhat dot com 2005-10-22 17:32 --- Subject: Re: gcc generates incorrect assignment because of reordering On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote: > Would it make sense to have a new option in `gcc' to say that target is > always evaluated after source is? > Not really possible. You are correct that it occurs at any optimization level. The bug in your code is exposed when GCC creates the intermediate representation for your program. In that intermediate representation, GCC is explicitly exposing the sequence points in expression evaluation using the standard rules. Your program breaks simply because it is not following the sequence points dictated by the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #7 from dnovillo at redhat dot com 2005-10-22 17:42 --- Subject: Re: gcc generates incorrect assignment because of reordering On Saturday 22 October 2005 13:32, Diego Novillo wrote: > The bug in your code is exposed when GCC creates the intermediate > representation for your program. In that intermediate representation, > GCC is explicitly exposing the sequence points in expression evaluation > using the standard rules. > BTW, you can ask GCC to show you this initial representation with -fdump-tree-gimple. The file with extension .gimple shows you how this translation is done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug tree-optimization/18501] [4.1 Regression] Missing 'used unintialized' warning
--- Comment #11 from dnovillo at redhat dot com 2005-11-01 18:56 --- Subject: Re: [4.1 Regression] Missing 'used unintialized' warning On Tuesday 01 November 2005 13:50, law at redhat dot com wrote: > I'd rather you not assign it to me just yet -- while I think my approach > is better, I don't think we have a consensus that it's what we're going > to do yet :-) > Don't worry, I haven't assigned it :) I just added a pointer to the thread and added you to the CC list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug tree-optimization/22216] [4.1 regression] ICE during GC
--- Additional Comments From dnovillo at redhat dot com 2005-06-28 12:16 --- Subject: Re: New: [4.1 regression] ICE during GC On Tue, Jun 28, 2005 at 11:52:20AM -, schwab at suse dot de wrote: > Broken by patch from PR21959. > Are you sure? Kenner seemed to get good results from that patch. If this was introduced by that patch, then it must've triggered a latent bug elsewhere. The patch merely prevented transformation opportunities in VRP. > #14 0x40b4f840 in ggc_collect () at ggc-page.c:1972 > #15 0x40b58b60 in rest_of_compilation () at passes.c:423 > #16 0x405d04f0 in execute_one_pass (pass=0x6000e840) > at tree-optimize.c:665 > Show me '*pass'? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22216
[Bug tree-optimization/22216] [4.1 regression] ICE during GC
--- Additional Comments From dnovillo at redhat dot com 2005-06-28 12:52
---
Subject: Re: [4.1 regression] ICE during GC
On Tue, Jun 28, 2005 at 12:42:03PM -, schwab at suse dot de wrote:
> $1 = {name = 0x0, gate = 0,
> execute = @0x41013990: 0x40b569d0 ,
> sub = 0x0, next = 0x0, static_pass_number = -1, tv_id = 116,
> properties_required = 267, properties_provided = 11,
> properties_destroyed = 256, todo_flags_start = 0, todo_flags_finish = 2,
> letter = 0 '\0'}
>
Huh, well that tells me nothing. If my ia64 supports Ada, I'll
try to take a look, otherwise you'll have to debug this yourself.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22216
[Bug tree-optimization/22216] [4.1 regression] ICE during GC
--- Additional Comments From dnovillo at redhat dot com 2005-06-28 14:18 --- Subject: Re: [4.1 regression] ICE during GC On Tue, Jun 28, 2005 at 12:42:03PM -, schwab at suse dot de wrote: > > Are you sure? > > Yes. > You need to check your script then. The patch for 21959 had nothing to do with this failure. I get the same ICE without that patch. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22216
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From dnovillo at redhat dot com 2005-07-06 00:23 --- Subject: Re: [4.1 Regression] wrong code with downcast in C++ On Wed, Jul 06, 2005 at 12:16:20AM -, dberlin at gcc dot gnu dot org wrote: > > --- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06 > 00:16 --- > It's in the ml archives, i'll try to find it. > Thanks. I remember the discussion, but I need some URL so that we can reference it from the source code. The comment in tree-ssa-operands.c:note_addressable references this PR, but there's no link from the PR into the discussion. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug tree-optimization/22591] [4.0 regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From dnovillo at redhat dot com 2005-07-26 22:24 --- Subject: Re: [4.0 regression] wrong alias information causes an incorrect redundant load elimination On Tue, Jul 26, 2005 at 10:00:51PM -, steven at gcc dot gnu dot org wrote: > You just closed the bug before it was fixed everywhere. I don't understand > your grim comment. > Tried to be sarcastic but forgot the smiley. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/23086] aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly
--- Additional Comments From dnovillo at redhat dot com 2005-07-27 20:38 --- Subject: Re: aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly On Wed, Jul 27, 2005 at 08:34:10PM -, pinskia at gcc dot gnu dot org wrote: > Isn't this a simple fix to may_alias_p saying that PARM_DECLs > cannot alias local variables? > It isn't. Only a default_def of a PARM_DECL is guaranteed not to point into any local. may_alias_p is flow-insensitive, so it can only return answers that apply to *all* the SSA names for a DECL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23086
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dnovillo at redhat dot com 2005-08-04 19:24 --- Subject: Re: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191 On Thu, Aug 04, 2005 at 07:18:13PM -, dank at kegel dot com wrote: > In general, once a ten-line testcase is found, do these get added > to the gcc regression testsuite as a matter of course? > No. Only after a fix has been created for the failure. > We would be happy to submit patches to add these to the test suite, but > we don't have copyright assignments in. Let us know if we > should submit such patches anyway. > I don't know whether test cases require copyright assignments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #10 from dnovillo at redhat dot com 2006-03-09 19:10 --- Subject: Re: ICE (segfault) on C++ OpenMP code On 03/09/06 14:03, pinskia at gcc dot gnu dot org wrote: > Then there are two issues, one for the reduced testcase which is PR 26076 and > another issue. But please don't say I don't understand the issue when the > fact > is this testcase here actually reduces to the testcase in PR 26076. > The fact that you closed one as a duplicate of the other is a clear indication that you have no idea what the issue is about. Reducing one test case to another one means nothing. The very reduction removes information that hides other bugs, or other aspects of the same bug. If you are so keen on closing PRs, close 26076 as a duplicate of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #12 from dnovillo at redhat dot com 2006-03-09 19:28 --- Subject: Re: ICE (segfault) on C++ OpenMP code On 03/09/06 14:17, pinskia at gcc dot gnu dot org wrote: > If you had written a status on this bug before I closed it as a dup, > I would not have closed it as a dup because I would have read that it > was not fully a dup. > When in doubt, ask. I don't have the time you seem to have to keep a perfectly up-to-date status on the PRs I have in my queue. I understand that you as a bugmaster would like to minimize open PRs and have perfect information on all of them, but such is life. It's an imperfect system and the bugs will not always have all the information you want in them. Unless you are absolutely certain (i.e., you have worked on a patch or debugged the problem in detail), you should ask the developer who was last working on the bug to see what the status is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug tree-optimization/21096] copy-prop leaks memory
--- Additional Comments From dnovillo at redhat dot com 2005-04-18 22:21 --- Subject: Re: New: copy-prop leaks memory On Mon, Apr 18, 2005 at 10:12:12PM -, kazu at cs dot umass dot edu wrote: > tree-ssa-copy.c:844 > > cached_last_copy_of = xmalloc (...) > > does not have a corresponding free. > Yeah. Obvious patch pre-approved. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21096
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at redhat dot com 2005-04-23 15:46 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Sat, Apr 23, 2005 at 03:11:52PM -, kargl at gcc dot gnu dot org wrote: > > --- Additional Comments From kargl at gcc dot gnu dot org 2005-04-23 > 15:11 --- > (In reply to comment #13) > > > > I would like to, but currently my patch causes a regression in one of > > the VRP testcases. > > Kazu, which test case is this? Send me details? I'll look at this next week. In the meantime, I would rather have sub-optimal code than a broken FE. > I haven't checked 4.0.0 against my Fortran > testsuite; hopefully, this problem isn't present in > gfortran's first exposure to the world. > No. VRP is a 4.1 feature. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From dnovillo at redhat dot com 2005-04-24 18:07 --- Subject: Re: Generates unneeded test On Sun, Apr 24, 2005 at 05:56:50PM -, pinskia at gcc dot gnu dot org wrote: > > i_15: [1, 2147483647] > i_16: [0, 2147483647] > i_20: VARYING > > # i_20 = PHI ; > > > Looks like VRP does not understand PHI functions or it just gives up too > often. > i_15 and 0 have a non-empty intersection and so vrp_meet returns VARYING. VRP does not handle multiple ranges, but in this case it should not be hard to merge the two adjacent ranges [1, +INF] and [0, 0]. What is the type of 'i'? If it's unsigned, then we would be wasting our time. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Additional Comments From dnovillo at redhat dot com 2005-04-27 19:43 --- Subject: Re: New: Teach VRP to pick up a constant from case label. On Wed, Apr 27, 2005 at 07:38:04PM -, kazu at cs dot umass dot edu wrote: > I think Diego already knows about this, but I think it's worth a PR so that > we don't forget. > Yes, there's a FIXME in tree-vrp.c about not handling SWITCH_EXPR. I agree it's worth having a PR for it. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at redhat dot com 2005-04-29 14:59 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 02:55:58PM -, kazu at cs dot umass dot edu wrote: > I have not sent my current patch to gcc-patches@ yet because I have > not finished testing it. This time I will unless you beat me to it. > Oh, OK. No, that's fine. I'm now analyzing the test case. I'll check out your patch in a little while, if it matches what I found, then it's OK to go in. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at redhat dot com 2005-04-29 21:11 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 07:57:43PM -, ro at techfak dot uni-bielefeld dot de wrote: > > --- Additional Comments From ro at techfak dot uni-bielefeld dot de > 2005-04-29 19:57 --- > Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with > -O2 > > Unfortunately, even with the patch applied, the Ada bootstrap failure on > i386-pc-solaris2.10 remains unchanged, a regression from 4.0: > > stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2 > -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada > /vol/gnu/src/gcc/gcc-dist/gcc/ada/sem_intr.adb -o ada/sem_intr.o > +===GNAT BUG DETECTED==+ > | 4.1.0 20050429 (experimental) (i386-pc-solaris2.10) GCC error: | > | in set_value_range, at tree-vrp.c:124| > | Error detected at sem_intr.adb:437:1 | > > Rainer > Huh. Odd. I just finished a bootstrap with $ configure --enable-languages=c,ada $ make bootstrap on i686-pc-linux-gnu. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at redhat dot com 2005-04-29 21:39 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 09:11:12PM -, dnovillo at redhat dot com wrote: > Huh. Odd. I just finished a bootstrap with > > $ configure --enable-languages=c,ada > $ make bootstrap > > on i686-pc-linux-gnu. > Just reproduced it with --target=i386-pc-linux-gnu. Thanks Andrew P. for pointing it out. Will take a look. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From dnovillo at redhat dot com 2005-05-02 15:29 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 On Fri, Apr 29, 2005 at 07:57:43PM -, ro at techfak dot uni-bielefeld dot de wrote: > Unfortunately, even with the patch applied, the Ada bootstrap failure on > i386-pc-solaris2.10 remains unchanged, a regression from 4.0: > Would you mind filing a separate PR? This is a different problem. The Ada FE is emitting a seemingly always-false predicate that is causing VRP to create an invalid range (http://gcc.gnu.org/ml/gcc/2005-05/msg00049.html). Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21488] [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure
--- Additional Comments From dnovillo at redhat dot com 2005-05-10 23:21 --- Subject: Re: [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure On Tue, May 10, 2005 at 11:07:24PM -, pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10 > 23:07 --- > Both DOM and copyprop are messing this up. > Be more specific: 1- What exactly is being "messed up". 2- Why is it wrong? 3- How would "fixing" this affect PR 18048? 4- What do you think should be done differently? You know, it is extremely irritating to read these one liners that offer no valuable information at all. It's not the first time you do this, please be more considerate in the future. If you don't have anything useful to contribute, silence is a perfectly valid option. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21488
[Bug tree-optimization/21488] [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure
--- Additional Comments From dnovillo at redhat dot com 2005-05-10 23:33 --- Subject: Re: [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure On Tue, May 10, 2005 at 11:27:17PM -, pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10 > 23:27 --- > (In reply to comment #8) > > > Be more specific: > > > > 1- What exactly is being "messed up". > Read Zdenek's comment about renaming them. > > > 2- Why is it wrong? > > Because now we have "unresolvable overlapping live ranges" > > > 3- How would "fixing" this affect PR 18048? > I don't know if it does. The bug which Steven was referencing was really PR > 19038, well there was some > discussion in PR 18048 about this problem also. > > > 4- What do you think should be done differently? > Not creating "unresolvable overlapping live ranges", how I don't know. > You really didn't understand my point, did you? You needlessly added noise to the PR. Nothing you said was new information nor was it useful to the person fixing this problem. I appreciate the triaging work that you do, but I don't appreciate random noise in PRs, particularly when that implies more mail in my inbox. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21488
[Bug tree-optimization/21289] A numeric range is spoiled by a symblic one in VRP
--- Additional Comments From dnovillo at redhat dot com 2005-05-14 20:00 --- Subject: Re: A numeric range is spoiled by a symblic one in VRP On Sat, May 14, 2005 at 07:40:04PM -, kazu at cs dot umass dot edu wrote: > > --- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 > 19:40 --- > Another case of a numeric value range spoiled by a symbolic one: > Fixed with my current changes to VRP. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21289
[Bug tree-optimization/19833] bogus uninitialized variable warning for powerpc64
--- Additional Comments From dnovillo at redhat dot com 2005-05-24 23:06 --- Subject: Re: bogus uninitialized variable warning for powerpc64 On Tue, May 24, 2005 at 11:02:09PM -, janis at gcc dot gnu dot org wrote: > Diego, can this PR be closed as fixed? > Yes. Apologies for not having done this before. The uninitialized warning machinery needs to be re-designed, though. Right now, we are at the mercy of whether certain passes were done in some specific order. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug middle-end/21858] [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
--- Additional Comments From dnovillo at redhat dot com 2005-06-01 19:38
---
Subject: Re: [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
On Wed, Jun 01, 2005 at 07:31:24PM -, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01
> 19:31 ---
> Confirmed, reduced testcase:
> unsigned int dsdblm_GetBlockAddress();
> void error_LocalAssert(void);
> int dsdblm_CreateBlock(unsigned int address)
> {
>address = dsdblm_GetBlockAddress();
>if (address >= (void*)0x0002)
> error_LocalAssert();
>return address;
> }
> This is either a front-end bug or a fold bug.
>
Is this legal C?
vrp15.c: In function `dsdblm_CreateBlock':
vrp15.c:6: warning: comparison between pointer and integer
This is very similar to what I found in the Fortran FE a few days
ago. The .gimple form is already "wrong":
D.1242 = dsdblm_GetBlockAddress ();
address = D.1242;
if (address > 131071B)
We lose, or never emit, the cast to convert the constant to integer.
However, the optimizers should probably not be ICEing here. I
will remove the assert in compare_values, to simply refuse to do
anything when pointers and non-pointers are mixed in the same
predicate.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21858
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 16:55
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 04:49:40PM -, ghazi at gcc dot gnu dot org wrote:
>
> --- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09
> 16:49 ---
> (In reply to comment #4)
> > (In reply to comment #1)
> > > If side effects appear in the arguments, that also would be a problem,
> > > e.g.:
> > >
> > > printf("%d", i++);
> > > printf("%d", i++);
> > >
> > > should not be turned into:
> > >
> > > printf("%d%d", i++, i++);
> > >
> > There should be little danger of this. Side-effects are explicitly exposed
> > in
> > GIMPLE. As long as the printf() calls are adjacent, we should be able to
> > combine them.
> > Diego.
>
> I'm not sure. In my specific example above, after the combination we don't
> know which i++ gets executed first because the order is not guaranteed within
> an argument list of a single function call (right?) So if we want to include
> combinations whose arguments have side-effects, we have to prove they don't
> interact with any other arguments.
>
But remember that we are not optimizing C, we are optimizing
GIMPLE. And in GIMPLE we don't have those problems. Here's what
the tree optimizers see:
i_3 = i_1 + 1;
printf (&"%d"[0], i_1);
printf (&"%d"[0], i_3);
Those two calls to printf can be merged. The order of evaluation
has been decided by the gimplifier. Whether that's right or
wrong for C, I couldn't say, all I know is that for the
optimizers, those two printf calls look mergeable.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:03
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 05:02:28PM -, ghazi at gcc dot gnu dot org wrote:
> int i=0, j=2;
> printf("%d", i);
> j++;
> printf("%d", j);
>
> Pushing the first printf further down, this could be reordered as:
> int i=0, j=2;
> j++;
> printf("%d", i);
> printf("%d", j);
>
> which would expose another combination possibility.
>
> Paul seemed to think this wasn't hard with the existing infrastructure, and
> that was two years ago.
>
Oh, absolutely. The algorithm I'm using will naturally do this.
This is a purely local transformation, we obviously cannot merge
builtins in different control flow paths, so the transformation
goes like this: when we get to a builtin, we try to merge it with
a previously found builtin. The only time we reset the concept
of "previously found builtin" is when we find a CALL_EXPR or an
ASM_EXPR which are the only ones that may have side-effects
affecting the output of the program.
If the program manipulates the same FILE * that is being used by
the stdio calls, then we'd lose. But I think that's fair game,
right?
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:38
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 07:29:42PM -, joseph at codesourcery dot com wrote:
> Although it may not be valid to manipulate the FILE * directly, it seems
> quite possible that a program might call another function
> between the printf calls
>
That is fine. Any call between the two builtins blocks the
merging.
> that function on the particular implementation
> having a macro expansion without a function call.
>
Sorry, you lost me here.
> It is also possible
> that values of arguments to the second built-in printf call may depend on
> the first one having been previously evaluated; for example, given
>
> extern char *s;
> extern int i;
>
> printf("%d", i);
> printf("%.5s", s);
>
> you can't merge the printf calls because the first one could have changed
> what is pointed to by s.
>
How can printing an integer to stdout affect 's'? Unless 's' has
been somehow mapped to stdout's buffer? Is that what you have in
mind?
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-09 19:57 --- Subject: Re: GCC should combine adjacent stdio calls On Thu, Jun 09, 2005 at 07:52:42PM -, joseph at codesourcery dot com wrote: > Suppose an implementation defines e.g. clearerr as a macro, and the > expansion of that macro just clears bits in the stdio structure and > doesn't call any functions. Then though the user's source code looks like > it contains a function call, after preprocessing it contains manipulation > of bits of the FILE structure for stdout instead. > Ah, OK. In which case, we should reset the "previous builtin" if we find a store to global memory in between. That'd be easy. > (a) It could be stdio's buffer (via setvbuf). > > (b) It could be a glibc memory stream opened with fmemopen (if the user > assigned to stdout - which glibc allows - or you do this optimization on > fprintf and not just printf). > > (c) It could point to a memory mapping of the file being written. > Gah, so we'll need to parse the format string then. Oh, well. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-10 13:15
---
Subject: Re: GCC should combine adjacent stdio calls
On Thu, Jun 09, 2005 at 07:52:42PM -, joseph at codesourcery dot com wrote:
> > > extern char *s;
> > > extern int i;
> > >
> > > printf("%d", i);
> > > printf("%.5s", s);
> > >
> > > you can't merge the printf calls because the first one could have changed
> > > what is pointed to by s.
> > >
> > How can printing an integer to stdout affect 's'? Unless 's' has
> > been somehow mapped to stdout's buffer? Is that what you have in
> > mind?
>
> (a) It could be stdio's buffer (via setvbuf).
>
> (b) It could be a glibc memory stream opened with fmemopen (if the user
> assigned to stdout - which glibc allows - or you do this optimization on
> fprintf and not just printf).
>
> (c) It could point to a memory mapping of the file being written.
>
Good lord. To me this is a pathological case. I'd wager that
this happens approximately never. How about a switch disabling
stdio merging?
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-10 13:56 --- Subject: Re: GCC should combine adjacent stdio calls On Fri, Jun 10, 2005 at 01:49:54PM -, joseph at codesourcery dot com wrote: > Not that I really see the benefit of printf merging in any case; without > statistics showing its effects on real code it seems any size benefit > could easily be wiped out by inhibiting the sharing of strings used in > more than one printf because instead they get merged with the adjacent > different strings. > This is a good point. Kaveh, do you think you'd have time to do some timings on things like GCC bootstraps or other code bases that use stdio extensively? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-10 14:25 --- Subject: Re: GCC should combine adjacent stdio calls On Fri, Jun 10, 2005 at 02:22:05PM -, ghazi at gcc dot gnu dot org wrote: > I have the cpu time, but it seems premature. Your patch as it > stands only optimizes two adjacent printf calls. Not printf > with putc or puts and none of the f* variants, right? And GCC > uses mostly the f* variants. This is like asking for tree-ssa > benchmarks when the framework was in but before any new passes > were written. > Hmm, right. OK, let me finish that part first then. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
--- Additional Comments From dnovillo at redhat dot com 2005-06-10 14:35 --- Subject: Re: GCC should combine adjacent stdio calls On Fri, Jun 10, 2005 at 02:28:36PM -, joseph at codesourcery dot com wrote: > Since putc and puts are typically faster than printf (not needing to parse > the input) and we optimize printf of constants into them, it's not clear > that merging printf with such functions would be an improvement either. > No, the patch does not merge different builtins. The whole idea is to collapse multiple I/O calls of the same kind into one. Whether this helps or not, I don't know. It certainly is a straightforward transformation. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
[Bug tree-optimization/19633] local address incorrectly thought to escape
--- Additional Comments From dnovillo at redhat dot com 2005-06-13 13:44 --- Subject: Re: local address incorrectly thought to escape On Mon, Jun 13, 2005 at 01:41:06PM -, steven at gcc dot gnu dot org wrote: > Ping Diego, should this be closed?? > If the testcase now works on ppc-darwin (see comment #7), then yes. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19633
[Bug libgcj/22084] Divide_1 test case hangs
--- Additional Comments From dnovillo at redhat dot com 2005-06-17 13:44 --- Subject: Re: Divide_1 test case hangs On Fri, Jun 17, 2005 at 01:13:49PM -, rmathew at gcc dot gnu dot org wrote: > -2147483648 > -2147483648 > 0 > 0 > [...] > > Note that the values are totally off. > This looks somewhat familiar. Could you try testing with -fno-tree-vrp? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug optimization/14272] [tree-ssa] miscompilation of __exchange_and_add (atomicity.h)
--- Additional Comments From dnovillo at redhat dot com 2004-02-25 19:52 --- Subject: Re: [tree-ssa] miscompilation of __exchange_and_add (atomicity.h) On Wed, 2004-02-25 at 13:20, amacleod at redhat dot com wrote: > --- Additional Comments From amacleod at redhat dot com 2004-02-25 18:20 --- > Err, did you try that patch on a testsuite run? > Nope. I only checked that it fixed this specific problem. I didn't mean to apply the patch until you checked it out. > It seems to me that you still need to look through the operands and kill any > active partition experssions which are dependent on the uses and defs. Ie, you > wouldn't make anything replaceable, but you do need to remove things from the > current search list. > Yes, I had the feeling that it was a bit heavy handed. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14272
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From dnovillo at redhat dot com 2004-12-17 22:54 --- Subject: Re: -Wuninitialized tricked by conditional assignments pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 > 22:41 --- > Isn't this just a dup of the long standing bug 5035? > Indeed. I must've searched for the wrong string. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers
--- Additional Comments From dnovillo at redhat dot com 2005-01-20 02:32 --- Subject: Re: [4.0 Regression] ICE with volatile non-PODs pointers pinskia at gcc dot gnu dot org wrote: >>$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version >>xgcc (GCC) 4.0.0 20050117 (experimental) >> > > > --version makes the compiler to do nothing except for printing out the > version. > I know. I collapsed both outputs for brevity. Never mind. I was using a --disabled-checking binary. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19299
[Bug tree-optimization/19853] [4.0 Regression] incorrect vops after exposing a new global variable
--- Additional Comments From dnovillo at redhat dot com 2005-02-14 19:03 --- Subject: Re: [4.0 Regression] incorrect vops after exposing a new global variable uweigand at gcc dot gnu dot org wrote: > When SRA scalarizes this initializer, > it is gimplified; the Ada-specific gimplification routine will replace > the ADDR_EXPR of CONSTRUCTOR with the newly generated temporary at this > point. > We *gimplify* in the middle of the optimization pipeline? Sigh. Send me a test case in a new PR? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug tree-optimization/19853] [4.0 Regression] incorrect vops after exposing a new global variable
--- Additional Comments From dnovillo at redhat dot com 2005-02-14 19:34 --- Subject: Re: [4.0 Regression] incorrect vops after exposing a new global variable uweigand at gcc dot gnu dot org wrote: > I only have the Ada test case for this; I can try to simplify it > a bit further ... > Anything I can reproduce with gnat1 should be fine. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug ada/19865] [4.0 Regression] ice / gnat bug detected.
--- Additional Comments From dnovillo at redhat dot com 2005-02-14 22:13
---
Subject: Re: [4.0 Regression] ice / gnat bug detected.
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
> 22:10 ---
> From PR 18706 when I was looking into the bootstrap bug before
>
> "I think this is the same failure as the current bootstrap problem on
> ppc-darwin.
> For the bootstrap problem we have the following CONST_DECL:
> static struct gnat__strings__string_access C.828 =
> {.P_ARRAY=(character[(long int)
> .P_BOUNDS->LB0:(long
> int)
> .P_BOUNDS->UB0] *) "",
> .P_BOUNDS=&{.LB0=1, .UB0=0}};
>
> Notice how we take the address of a CONSTRUCTOR this is wrong and we should
> never do that."
>
That tells me nothing. Show me the failure and the spot where we fail.
You don't seem to be sure of what the problem is.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os
--- Additional Comments From dnovillo at redhat dot com 2004-10-08 13:09 --- Subject: Re: [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os On Fri, 2004-10-08 at 09:03, sebastian dot pop at cri dot ensmp dot fr wrote: > Then the following patch solves the problem by avoiding the analysis > of these cycles. > You could also try splitting blocks, but if there's a cheaper work around for 4.0, that'd be safer. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560
[Bug middle-end/18574] [4.0 Regression] bootstrap comprison failed
--- Additional Comments From dnovillo at redhat dot com 2004-11-21 15:22 --- Subject: Re: [4.0 Regression] bootstrap comprison failed On Sun, 2004-11-21 at 08:02 -0700, Jeffrey A Law wrote: > Since I've been unable to trigger the failure here, I can't say for > certain whether or not this patch fixes the bootstrap failures others > have seen. > If it helps, one of my i686 testers bootstraps with checking disabled, the other one with checking enabled. The bootstrap failure occurs with checking disabled. This is as of last night at 1am EST. Bootstrap comparison failure! ./tree-ssa-loop-niter.o differs cp/decl.o differs cp/pt.o differs cp/typeck.o differs java/parse.o differs make[1]: *** [gnucompare] Error 1 make[1]: Leaving directory `/notnfs/dnovillo/sbox/gcc/bld.tobiano/gcc' make: *** [bootstrap] Error 2 Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info
--- Additional Comments From dnovillo at redhat dot com 2004-11-26 22:53
---
Subject: Re: [4.0 Regression]: ICE in
merge_alias_info
On Fri, 2004-11-26 at 22:50 +, dnovillo at gcc dot gnu dot org
wrote:
> --- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26
> 22:50 ---
> (In reply to comment #6)
>
> > Diego, if you are too busy, just let me know which you prefer and i'll
> implement it.
> >
> I'll take a look, but in principle it seems to me that NMT.1 and NMT.2 should
> actually be the same name tag. They have overlapping points-to sets, after
> all.
> I'm not sure at the moment what would be the best approach.
>
By which, I mean:
$ cvs diff -dup tree-ssa-alias.c
Index: tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.57
diff -d -u -p -r2.57 tree-ssa-alias.c
--- tree-ssa-alias.c25 Nov 2004 03:54:07 - 2.57
+++ tree-ssa-alias.c26 Nov 2004 22:52:46 -
@@ -771,7 +771,7 @@ create_name_tags (struct alias_info *ai)
if (qi
&& qi->pt_vars
&& qi->name_mem_tag
- && bitmap_equal_p (pi->pt_vars, qi->pt_vars))
+ && bitmap_intersect_p (pi->pt_vars, qi->pt_vars))
{
pi->name_mem_tag = qi->name_mem_tag;
break;
But that may be too pessimistic.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18291
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From dnovillo at redhat dot com 2004-11-29 13:42 --- Subject: Re: [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049 On Mon, 2004-11-29 at 13:37 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 > 13:37 --- > Steven's patch should work ... > But it should not be necessary. One thing that needs to change, however is: --- tree-into-ssa.c 25 Nov 2004 22:31:08 - 2.33 +++ tree-into-ssa.c 29 Nov 2004 13:40:34 - @@ -614,7 +614,7 @@ insert_phi_nodes (bitmap *dfs, bitmap na /* Vector WORK_STACK is a stack of CFG blocks. Each block that contains an assignment or PHI node will be pushed to this stack. */ - work_stack = VEC_alloc (basic_block, last_basic_block); + work_stack = VEC_alloc (basic_block, n_basic_blocks); /* Iterate over all variables in VARS_TO_RENAME. For each variable, add to the work list all the blocks that have a definition for the But that is not sufficient. We are overflowing work_stack, when we really shouldn't. I'm looking into this now. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug tree-optimization/18746] segfault with cc1 compiled with checking disabled
--- Additional Comments From dnovillo at redhat dot com 2004-12-01 00:55 --- Subject: Re: New: segfault with cc1 compiled with checking disabled On Wed, 2004-12-01 at 00:51 +, kazu at cs dot umass dot edu wrote: > I get "internal compiler error: Segmentation fault". > > The testcase was reduced from i386.c. > Hmm, does this happen after fold-all-builtins? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18746
[Bug tree-optimization/18892] missed optimization with & and ==
--- Additional Comments From dnovillo at redhat dot com 2004-12-08 20:28
---
Subject: Re: New: missed SRA of a block copy
pinskia at gcc dot gnu dot org wrote:
> The following function:
> int f(int a)
> {
> int i = a & -129;
> return i == 144;
> }
> Should be compiled to:
> int f1(int a)
> {
> return (a & -129) == 144; // aka return 0;
> }
>
> Yes this shows up in real code (gcc), found while testing out my tree
> combiner.
>
Hmm? What does SRA have to do with anything here?
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18892
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #22 from dnovillo at redhat dot com 2006-11-09 15:08 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc Daniel Berlin wrote on 11/09/06 10:05: > One thing i'm going to try later is to try to partition all the > stores/load statements and figure out how many symbols it takes to > represent the results exactly (IE one symbol for each set of > statements that must interfere with each other, where each statement > can be in multiple partitions). > This is what I'm doing in memory SSA. More details later this week after I'm done testing and such. The difference is that partitioning is embedded in the actual SSA form and the partitioning heuristic can be changed independently of the renamer. This will let us play with a slider-style throttling for precision/compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #25 from dnovillo at redhat dot com 2006-11-09 17:38 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc Daniel Berlin wrote on 11/09/06 12:22: > Right, but the difference is, In the scheme i propose, you'd never > have overlapping live ranges of vuse/vdefs, and in mem-ssa, you do. > IE we wouldn't run into all the problems mem-ssa is going to bring in > this regard. No, that's not right. Overlapping live-ranges are not a problem until you hit a PHI node. That's where currently mem-ssa is having difficulties with. We can use those static partitions at key points during SSA renaming. Since the partitions are completely unrelated to the renamer, we can experiment with different partitioning schemes. It's actually even possible to arrive to a perfect partitioning scheme that doesn't introduce false positive dependencies. More details to follow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #33 from dnovillo at redhat dot com 2006-11-09 21:48 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc dberlin at dberlin dot org wrote on 11/09/06 16:28: > Uh, LIM and store sinking are too. Roughly all of our memory > optimizations are. > They are? Really? Can you show me where exactly? > The changes i have to make to PRE (and to the other things) to > account for this is actually to rebuild the non-mem-ssa-factored (IE > the current factored) form out of the chains by seeing what symbols > they really affect. > OK, so how come you were so positive about the new interface? I need to understand what was the great difficulty you ran into that made you change your mind. I need to see a specific example. See, the UD chains you get in mem-ssa are neither incomplete nor wrong. The symbols affected are right there in plain sight, so there is no loss of any information. > For at least all the opts i see us doing, it makes them more or less > useless without doing things (like reexpanding them) first. Because > this is true, I'm not sure it's a good idea at all, which is why i'm > still on the fence. > But you still haven't *shown* me where the hardness or slowness comes in. Granted, the work is still unfinished so we can't really do actual measurements. But I need to understand where the difficulties will be so that I can accomodate the infrastructure. It's obviously not my intent to make things harder to use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
