From patchwork Sat Nov 5 00:26:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Sebor X-Patchwork-Id: 691498 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3t9ff33Pwfz9t9b for ; Sat, 5 Nov 2016 11:26:51 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="uKPapCxe"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=XFuxrPJLM26SP0CxL9HtCoQKIXixiT23bR7SSBiayf1pAsRi/R f4h08OUfMS1pmAlqIgMlrDMTiI0tXkzjZXZZfX46dRG58FzPm5b9Kse9nHFkEnMU QO+bhyeSBYr74gC4R1yOuY1GIe+qPH8H2BizbCn1UqzbmnEv+6iMHkg3g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=TdH3s/syfLfbNJEgxbanfdOrAQs=; b=uKPapCxe+Gf+BgUvpM/4 nT34hKdwm5GcrS+skEMUtK7ESAkf018ItT6QiuFsXeUWhGOQco+9Eu6kDIS5AS4z 4z1PbNKmx+KDAek93lWyBEv8y2dmG/xjUCReeMqmI+IVX119SWVysze8OAPH1dAa t7Rt3N0aXwy51L/2FXLuy7o= Received: (qmail 122605 invoked by alias); 5 Nov 2016 00:26:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 122590 invoked by uid 89); 5 Nov 2016 00:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*aldyh, unbounded, stand X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 Nov 2016 00:26:41 +0000 Received: by mail-qt0-f180.google.com with SMTP id c47so58150513qtc.2 for ; Fri, 04 Nov 2016 17:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=KRz3Lq8/7ZtyRbLjBrGmq+6St0Zc0pNpyWYNt2PeENs=; b=RZG3CRQj0mY/0KSkQc7nJoXZEeuQnbFPdPVjQ+UfATHbaBj/HefOMK9NJiDIp3VNZB 6iijitFvMAwBih44ZVAMAJkSUtSNXP+A4QR4DM0jXeRdLGHIFIwl+kA6q+tGxwx/V0uq 5g3OyNJdg0hTA5P2tOXKVk/EsxanBbhN7bUebl6xPb6pLYqDS9N1ZAnfTeCGBK9rLgfl JWjAWxREtWuW41fdajD/bd3lFnSAaqilbRXsbCuITFz4SF0JhXptu/QnwDlJzMFIx6KM 9zDR4W5NMwb7n4vqeIMgEsmpXLddA+VfsO/0KoTjLJ0+j1Af9bce7KmKDOHa6jwzRFIf lK/g== X-Gm-Message-State: ABUngvdupHU8++uPVNb4SWYDPzznDstvwpCCkaMDjc0Cm+pvC9rHT0pGC3K0EtJvrsOIOg== X-Received: by 10.200.42.201 with SMTP id c9mr16616189qta.121.1478305600026; Fri, 04 Nov 2016 17:26:40 -0700 (PDT) Received: from [192.168.0.26] (71-212-250-41.hlrn.qwest.net. [71.212.250.41]) by smtp.gmail.com with ESMTPSA id 126sm9236809qkl.12.2016.11.04.17.26.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 17:26:39 -0700 (PDT) To: Gcc Patch List , Aldy Hernandez From: Martin Sebor Subject: [PATCH] fix a few minor nits in -Walloca documentation Message-ID: Date: Fri, 4 Nov 2016 18:26:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 X-IsSubscribed: yes While experimenting with -Walloca and cross-referencing the manual I noticed a few minor nits that I thought could stand to corrected and/or clarified. Attached is a patch. In the update I mentioned that the alloca argument must have integer type for the bounds checking to be recognized to make it clear that for example floating point arguments are not considered to be bounded even if they are constrained. (Apparently VRP doesn't handle those.) Martin gcc/ChangeLog: * doc/invoke.texi (Warning Options): Correct typos in -Walloca documentation. Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi (revision 241863) +++ gcc/doc/invoke.texi (working copy) @@ -4997,8 +4997,10 @@ This option warns on all uses of @code{alloca} in @item -Walloca-larger-than=@var{n} This option warns on calls to @code{alloca} that are not bounded by a -controlling predicate limiting its size to @var{n} bytes, or calls to -@code{alloca} where the bound is unknown. +controlling predicate limiting its argument of integer type to at most +@var{n} bytes, or calls to @code{alloca} where the bound is unknown. +Arguments of non-integer types are considered unbounded even if they +appear to be constrained to the expected range. For example, a bounded case of @code{alloca} could be: @@ -5014,13 +5016,13 @@ void func (size_t n) @} @end smallexample -In the above example, passing @code{-Walloca=1000} would not issue a -warning because the call to @code{alloca} is known to be at most 1000 -bytes. However, if @code{-Walloca=500} was passed, the compiler would -have emitted a warning. +In the above example, passing @code{-Walloca-larger-than=1000} would not +issue a warning because the call to @code{alloca} is known to be at most +1000 bytes. However, if @code{-Walloca-larger-than=500} were passed, +the compiler would emit a warning. Unbounded uses, on the other hand, are uses of @code{alloca} with no -controlling predicate verifying its size. For example: +controlling predicate constraining its integer argument. For example: @smallexample void func () @@ -5030,8 +5032,8 @@ void func () @} @end smallexample -If @code{-Walloca=500} was passed, the above would trigger a warning, -but this time because of the lack of bounds checking. +If @code{-Walloca-larger-than=500} were passed, the above would trigger +a warning, but this time because of the lack of bounds checking. Note, that even seemingly correct code involving signed integers could cause a warning: @@ -5048,7 +5050,7 @@ void func (signed int n) @end smallexample In the above example, @var{n} could be negative, causing a larger than -expected argument to be implicitly casted into the @code{alloca} call. +expected argument to be implicitly cast into the @code{alloca} call. This option also warns when @code{alloca} is used in a loop.