From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4AB0A38582A2 for ; Tue, 5 Jul 2022 20:55:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4AB0A38582A2 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-588-r5AYEHTrNni4mKHTKmDw1w-1; Tue, 05 Jul 2022 16:55:00 -0400 X-MC-Unique: r5AYEHTrNni4mKHTKmDw1w-1 Received: by mail-qt1-f198.google.com with SMTP id m6-20020ac866c6000000b002f52f9fb4edso10439798qtp.19 for ; Tue, 05 Jul 2022 13:55:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=uacgaZ378IvavSW6qtOpFWP4GvUHXkqO9mDfe1ry+nA=; b=F5ryL19pag3qI2AlYBt8aOYLaj5xLtUCoHKdQftBqVYhzMrrHIs179ci4E7h36CzLf cXsd7PDm0fAxf+Xy+/OsQ8CqImcGt8E5rX74lnIYGEz5oqNSRuReuehfpjRJAIpRQDfR x2FCbBS0fz3yKmFKlz+gNUnMEjYZTJHHJDQszn/CLW2GJoqiTjLdYxLFOl8kEE+4k7QE FSlr4rUNXlAirMiAgAZt7b0qnEOgSrmkqDgkMlQGbNkYbOquegHIBHN7aJ3oHY7kVoAx 1A456lifZH7Rjbai9TTZdJuJRAIjf0iB6VfXwUp4i1RkMzwSXiX89MzlWqnPxof7gLPF V8Rw== X-Gm-Message-State: AJIora9FuYtN3A7q5FturwKloD0Dti6dRki/XUEwPzpmWr2+DbOLDiPI YcWocNFuwfiz2uZXfYzx8KjqpKeqp4Vv2aPc4VuDbFq29puwEXwM9YbL+AV86bEYuc2sCm3Af+W ASJcDs1i9nM6wykshTw== X-Received: by 2002:a05:6214:20a7:b0:470:514b:951f with SMTP id 7-20020a05621420a700b00470514b951fmr33270493qvd.27.1657054500326; Tue, 05 Jul 2022 13:55:00 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vY0JAlPIeTEdhHh0fs4zBjrN1KFpfrFnWOkUPLJhP5Bvs2CdRi3M1s1Xzb5a7lPnVEO1h1Cg== X-Received: by 2002:a05:6214:20a7:b0:470:514b:951f with SMTP id 7-20020a05621420a700b00470514b951fmr33270480qvd.27.1657054500036; Tue, 05 Jul 2022 13:55:00 -0700 (PDT) Received: from [192.168.1.100] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id g6-20020ac842c6000000b00317ccc66971sm22492048qtm.52.2022.07.05.13.54.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jul 2022 13:54:59 -0700 (PDT) Message-ID: <9fa09ffa-f520-115b-7f14-da449d5014e7@redhat.com> Date: Tue, 5 Jul 2022 16:54:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20220617212002.3747825-1-jason@redhat.com> <162bc331-56a6-ed11-872a-658235611ce2@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 20:55:03 -0000 On 6/29/22 13:26, Jakub Jelinek wrote: > On Wed, Jun 29, 2022 at 12:42:04PM -0400, Jason Merrill wrote: >>> The usual case is that people just use -fsanitize=undefined >>> and get both return and unreachable sanitization, for fall through >>> into end of functions returning non-void done through return sanitization. >>> >>> In the rare case people use something different like >>> -fsanitize=undefined -fno-sanitize=return >>> or >>> -fsanitize=unreachable >>> etc., they presumably don't want the fall through from end of function >>> diagnosed at runtime. >> >> I disagree with this assumption for the second case; it seems much more >> likely to me that the user just wasn't thinking about needing to also >> mention return. Missing return is a logical subset of unreachable; if we >> sanitize all the other __builtin_unreachable introduced by the compiler, why >> in the world would we want to leave out this one that is such a frequent >> error? > > UBSan was initially implemented in LLVM and our -fsanitize= options try to > match where possible what they do. > And their behavior is too that return and unreachable are separate > sanitizers, fallthrough from function return is sanitized only for the > former, they apparently at -O0 implement something like -funreachable-traps > (but not at -Og) and emit a trap there (regardless of > -fsanitize=unreachable), for -O1 and higher they act as if non-sanitized > __builtin_unreachable () is in there regardless of -fsanitize=unreachable. Hmm, does clang only sanitize explicit calls to __builtin_unreachable? > It would be strange to diverge from this without a strong reason. > The fact that we use __builtin_unreachable for the function ends is just our > implementation detail and when we'd report that to users, they'd just be > confused on what's going on. With -fsanitize=return they are told what > happens. > >> Full -fsanitize=undefined is much higher overhead than just >> -fsanitize=unreachable, which introduces no extra checks. And adding return >> checking to unreachable is essentially zero overhead. I can't imagine any >> reason to want to check unreachable points EXCEPT for missing return. > > -fsanitize=unreachable isn't zero overhead, it will force evaluation of all > the conditionals guarding it and preparation of arguments for it etc.