From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25518 invoked by alias); 22 Jan 2010 19:05:21 -0000 Received: (qmail 25465 invoked by uid 48); 22 Jan 2010 19:05:06 -0000 Date: Fri, 22 Jan 2010 19:05:00 -0000 Message-ID: <20100122190506.25464.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg02762.txt.bz2 ------- 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