From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16085 invoked by alias); 23 Jan 2015 21:36:57 -0000 Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org Received: (qmail 16074 invoked by uid 89); 23 Jan 2015 21:36:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 23 Jan 2015 21:36:54 +0000 Received: by mail-ob0-f177.google.com with SMTP id uy5so9210823obc.8 for ; Fri, 23 Jan 2015 13:36:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.92.230 with SMTP id cp6mr5834912oeb.85.1422049012352; Fri, 23 Jan 2015 13:36:52 -0800 (PST) Received: by 10.202.102.210 with HTTP; Fri, 23 Jan 2015 13:36:52 -0800 (PST) Date: Fri, 23 Jan 2015 21:36:00 -0000 Message-ID: Subject: gcc x64 linux code generation (passing pointer var-args) bug From: Reuben Hawkins To: overseers@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-q1/txt/msg00026.txt.bz2 Hi Overseers, I ran into an issue with all versions of gcc which support x64 which *could* be considered a bug. At the very least, it's a pitfall. I'm not really sure to whom I should bring this problem to. Bugzilla? Mailing list? Not sure... Anyway, the gist of the bug is this... printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, 0); The first 5 zero ints are copied into the esi, edx, ecx, r8d and r9d, (as the linux x64 calling convention mandates) with the movl instruction. The movl instruction will zero out the upper 32-bits of those registers. The last zero int, however is copied to (%rsp) with movl, which does *not* zero out the upper 32 bits because (%rsp) is not a register, so the last 0 is not promoted to a 64-bit zero, but the rest of the zeros are. If I were to add another zero, that zero would be copied to 8(%rsp), so the upper 32-bits of (%rsp) are skipped and whatever garbage happens to be there is passed to the called function. printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, (void*)0); ...works because the (void*) causes gcc to emit a movq instruction. I'm wondering if there's a possibility to change this unexpected behavior in gcc such that it always uses movq on stack args. I realize all the zeros are technically wrong, they should be either NULL or (void*) casts, but it's a huge pain that '0' works for the first 6 args, then doesn't on the 7th when the args start going on the stack. Thanks in advance, Reuben Hawkins