[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #45 from rguenth at gcc dot gnu dot org 2010-04-06 11:20 --- GCC 4.5.0 is being released. Deferring to 4.5.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #44 from mmitchel at gcc dot gnu dot org 2010-02-17 17:20 --- As I understand it, this is an Alpha-specific problem. It may have an Alpha-independent solution, but only users on Alpha will be affected. So, I've downgraded this to P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #42 from jakub at gcc dot gnu dot org 2010-01-23 08:13 --- Well, stdarg wants to be scheduled after some kind of DCE, to avoid making decisions from dead code. So in that case we'd have to schedule a DCE pass after retslot (perhaps just for cfun-stdarg functions), then stdarg, then phiprop/fre. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #43 from rguenth at gcc dot gnu dot org 2010-01-23 12:06 --- Well, we run DCE during early optimizations and the CCP that runs before pass_return_slot and after final inlining removes dead basic-blocks and trivially dead insns already. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2009-09-04 18:45:26 |2010-01-23 12:06:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-01-22 11:25 --- Well, w/o a way to reproduce the problem (read: execute code) I think you have to do a better job analyzing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #34 from ubizjak at gmail dot com 2010-01-22 12:33 --- (In reply to comment #33) Well, w/o a way to reproduce the problem (read: execute code) I think you have to do a better job analyzing the problem. This is: FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -g from [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01777.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-01-22 14:17 --- (In reply to comment #34) (In reply to comment #33) Well, w/o a way to reproduce the problem (read: execute code) I think you have to do a better job analyzing the problem. This is: FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -g from [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01777.html That doesn't make me have an alpha machine or a proper reduced testcase. Note that it now only fails at -O3. Please paste a reduced testcase that still fails and track down what is the pass that does which wrong transformation. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #36 from ubizjak at gmail dot com 2010-01-22 17:26 --- (In reply to comment #35) That doesn't make me have an alpha machine or a proper reduced testcase. Note that it now only fails at -O3. Please paste a reduced testcase that still fails and track down what is the pass that does which wrong transformation. Probably you should read Comment #20 all the way to the end... There are listed _two_ testcases (with dumps) and the exact location in execute_optimize_stdarg () of tree-stdarg.c where the problem happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #37 from jakub at gcc dot gnu dot org 2010-01-22 19:05 --- Well, as alpha is the only affected platform, it is a target problem. The thing is, alpha unfortunately doesn't define va_list the same as x86_64 or s390 or rs6000 - a single member array of structs. So, in a function that takes va_list argument on x86_64/s390/rs6000 the parent fn va_list object is updated (thus all writes to it are kept) but on alpha it is not and thus DSE can remove those stores as dead. In 4.4 and earlier tree-stdarg would bail out when it saw an apX = apY assignment (struct copy), but apparently in 4.5 this is DCEd away. You can certainly just stop using the tree-stdarg computed info in alpha backend (alpha is the only backend that uses the info and doesn't have va_list either a void/char pointer, or single member array of structs; I'm afraid that would be a code quality regression though, especially on alpha which badly needs this), or we need to find out if there is anything tree-stdarg could do, or we could tell DCE not to DCE away va_list RECORD_TYPE assignments before tree-stdarg pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #38 from jakub at gcc dot gnu dot org 2010-01-22 19:17 --- In 4.4 the apY = apX; assignment isn't optimized out, because the code after it reads from the apY's fields (apY is the struct from the inline, apX in the caller). But in 4.5 FRE replaces them by whatever is written into apX fields. It surprises me FRE does this, I'd expect that the struct needs to be SRAed first before such optimizations can do anything with it. That said, other options would be prevent FRE from doing that kind of things with RECORD_TYPE __builtin_va_list objects in the first fre pass, or for DCE1 to somehow signalize to the stdarg pass if it removes an va_list = va_list assignment that it should just signalize that va_list escapes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #39 from rguenther at suse dot de 2010-01-22 21:47 --- Subject: Re: [4.5 Regression] stdarg pass produces wrong code On Fri, 22 Jan 2010, jakub at gcc dot gnu dot org wrote: --- Comment #38 from jakub at gcc dot gnu dot org 2010-01-22 19:17 --- In 4.4 the apY = apX; assignment isn't optimized out, because the code after it reads from the apY's fields (apY is the struct from the inline, apX in the caller). But in 4.5 FRE replaces them by whatever is written into apX fields. It surprises me FRE does this, I'd expect that the struct needs to be SRAed first before such optimizations can do anything with it. It's a feature ;) FRE can look through struct copies now and thus can value-number x to 1 in s.a = 1; r = s; x = r.a; That said, other options would be prevent FRE from doing that kind of things with RECORD_TYPE __builtin_va_list objects in the first fre pass, or for DCE1 to somehow signalize to the stdarg pass if it removes an va_list = va_list assignment that it should just signalize that va_list escapes. or alpha could make the va_list struct copies volatile. Or we can schedule tree-stdarg earlier. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #40 from steven at gcc dot gnu dot org 2010-01-22 22:49 --- Running tree-stdarg earlier would introduce non-obvious pass ordering requirements IIUC. I don't think that's a good idea... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #41 from rguenth at gcc dot gnu dot org 2010-01-22 22:57 --- (In reply to comment #40) Running tree-stdarg earlier would introduce non-obvious pass ordering requirements IIUC. I don't think that's a good idea... Well given that practically we moved stdarg towards the back by adding early optimizations it would be not unreasonable to move it right after pass_return_slot. That retains scalar cleanup after final inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #32 from ubizjak at gmail dot com 2010-01-21 20:25 --- I would like RMs to reconsider the priority of this bug, since it shows weakness in the generic part of the compiler. Please see comments #20, #25 (and #26) for the analysis. -- ubizjak at gmail dot com changed: What|Removed |Added Priority|P4 |P3 Summary|[4.5 Regression] r147980|[4.5 Regression] stdarg pass |(New SRA) breaks stdargs|produces wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
