From owner-freebsd-current@FreeBSD.ORG  Tue Mar 13 12:53:45 2007
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 EF94516A400;
	Tue, 13 Mar 2007 12:53:45 +0000 (UTC)
	(envelope-from rea-fbsd@codelabs.ru)
Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45])
	by mx1.freebsd.org (Postfix) with ESMTP id AAA1C13C45A;
	Tue, 13 Mar 2007 12:53:45 +0000 (UTC)
	(envelope-from rea-fbsd@codelabs.ru)
Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45])
	by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256)
	id 1HR6Fp-000PfM-2W; Tue, 13 Mar 2007 15:37:25 +0300
Date: Tue, 13 Mar 2007 15:37:18 +0300
From: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To: Andrey Chernov <ache@freebsd.org>, current@freebsd.org
Message-ID: <20070313123717.GU58523@codelabs.ru>
References: <20070313121106.GA96293@nagual.pp.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20070313121106.GA96293@nagual.pp.ru>
Sender: rea-fbsd@codelabs.ru
X-Spam-Status: No, score=-2.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_05
Cc: 
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 12:53:46 -0000

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 <stdio.h>

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.
-- 
Eygene