From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 19:42:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D415716A400; Thu, 15 Mar 2007 19:42:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8A413C458; Thu, 15 Mar 2007 19:42:31 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.14] ([129.247.12.14]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:04:43 +0100 Message-ID: <45F6A169.9050008@dlr.de> Date: Tue, 13 Mar 2007 14:04:41 +0100 From: Hartmut Brandt User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> In-Reply-To: <20070313123717.GU58523@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 13:04:44.0215 (UTC) FILETIME=[2B654C70:01C76570] X-Mailman-Approved-At: Thu, 15 Mar 2007 20:57:39 +0000 Cc: current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 19:42:32 -0000 Eygene Ryabinkin wrote: > Andrey, good day. > > >> It calls "puts(NULL)" with core dump. >> It means "printf("%s\n", NULL)" is overoptimized. >> BTW, things like "printf("1%s\n", NULL)" are not overoptimized. >> > > Yes, it is in the gcc/builtins.c::expand_builtin_printf(). Currently > it only handles "%s" and "%c". > > >> Any ideas? Is it right or needs to be fixed? >> > > It is definitely not right, since it produces the bad code. > And there are no compilation-time checks that can say for > sure will the argument for the "%s" be NULL: > ----- > $ cat 1.c > #include > > int main(void) > { > void *ptr = NULL; > func(ptr); > } > > int func(void *ptr) > { > printf("%s\n", ptr); > } > :: rea@codelabs : 15:31:43 : ~/xlam > $ cat 1.s > .file "1.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call func > leave > ret > .size main, .-main > .p2align 2,,3 > .globl func > .type func, @function > func: > pushl %ebp > movl %esp, %ebp > subl $20, %esp > pushl 8(%ebp) > call puts > leave > ret > .size func, .-func > ----- > The possible way to proceed with this optimization is to have the > 'puts', but to enable runtime check for the NULL value. > > I see the following definition for the fn_puts in builtins.def: > ----- > DEF_EXT_LIB_BUILTIN (BUILT_IN_PUTS_UNLOCKED, "puts_unlocked", BT_FN_INT_CONST_STRING, ATTR_NOTHROW_NONNULL_1) > ----- > The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and something > can be done with the NULL pointer. I am not very familiar with gcc > internals, but I will try to see if something can be changed. > The behaviour of gcc is correct. Passing NULL to the %s of printf() produces undefined behaviour. The compiler is free to do what ever it wants including burning your house. Depending on printf to print (null) or whatever is just bad programming. harti