From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39270C48BE6 for ; Sat, 12 Jun 2021 00:32:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D711F613CA for ; Sat, 12 Jun 2021 00:32:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D711F613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 574226B006C; Fri, 11 Jun 2021 20:32:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5245A6B006E; Fri, 11 Jun 2021 20:32:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 376FC6B0070; Fri, 11 Jun 2021 20:32:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 04A276B006C for ; Fri, 11 Jun 2021 20:32:10 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7CC071813F3C9 for ; Sat, 12 Jun 2021 00:32:10 +0000 (UTC) X-FDA: 78243194820.28.A4D4630 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by imf13.hostedemail.com (Postfix) with ESMTP id 4CD04E000259 for ; Sat, 12 Jun 2021 00:32:04 +0000 (UTC) Received: by mail-pj1-f50.google.com with SMTP id k22-20020a17090aef16b0290163512accedso8064237pjz.0 for ; Fri, 11 Jun 2021 17:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BzY4XDgBWed7bO/Eixe56mN9w07810mPceqGipGdIao=; b=eloI4URecslO3/Yb20jYzKteNuFCDaiF5ZIfNQGkM9tx5ZcxsWgx7pkzVUzt+WRFqW r0HU4IVtNfdbmCSrQyNO2NuRYnBP5YMGYu9AuF70sOh+jttUIy4t3BrdGdpCqPAwg6pH 1Dr+iuFLCS1TuFb7KOwE/x8g61w4+WAdoZ7fNJnoQxfd2HKaAvr8vmQVNA00mQ1KTduG rDl2sYBVDCop99Gkf4RsD4VQogrsB2vXlQGjMue6GIBZjf7jKdGcSYyliHIrSk1JLEgz btt+tWSEDk8u8J/P9CrPo6nr4hy1dwiIDc0JImfo5dVPhwE/hxP1XSEzq0cr+CE2VjbT nJrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BzY4XDgBWed7bO/Eixe56mN9w07810mPceqGipGdIao=; b=uVoKxrdSCPopcTm+mLDqVZrptqWRsCrMgUyFvHItp38n1DRf9Q1lJkVFP0B0RNW5K4 7ldSvQKtQMrAU8g5nZ3Nu6aGfBmY5kUuFJdPYvL6oVwExgUNYfGuIqbgOTUKSmzezXgd s1FghsGDRjlmHbhL6Tan5ecM2u4l9LRx6klF2YGTrQ1hcboMCFPxU6PWbKH4tvmyhTeO /UQhTxRdRSpEpf2E1hUWz3yYOeFpf1ipWr8/hbOH8+UF0/0sAbWTYYBi9N4J/BSnkZkS oEVgPWSVy+TwgThXwyjVmMngB/gLHLHC/GgFW6ZH5teo0KljTfrH3u9dJtqsGwjxTvgl Qg9Q== X-Gm-Message-State: AOAM531sKJgwPVuZ2qE6mfCpEgUsHul88n6cJF8hapcurXko70IlcjCd V1q6RILI2mnSc12Qi4RSrASEk8sFECw5mBn8Apg= X-Google-Smtp-Source: ABdhPJyAby4cD9RTxnIF8P3j/4K19N9ebcLW5PsFwQNpuX9vy2O78UUnLHHUPAu51haahwhKTNMa4UbhKQshfrRMZp4= X-Received: by 2002:a17:90a:b10a:: with SMTP id z10mr7177905pjq.226.1623457929276; Fri, 11 Jun 2021 17:32:09 -0700 (PDT) MIME-Version: 1.0 References: <202106051442.G1VJubTz-lkp@intel.com> <20210606110839.GA13828@hyeyoo> <20210607122550.GA752464@hyeyoo> <06af75da-ffe9-7070-1da8-bcb2cb7881d2@suse.cz> <20210607154957.GB927582@hyeyoo> <6e1d48f2-409c-0a71-4d04-a907fe4183b8@suse.cz> <20210608170528.GA28015@hyeyoo> <2d2d792e-e189-99a4-36cb-f1473a4df9ad@suse.cz> <20210608184501.GA5505@hyeyoo> <513f82e6-175c-d040-691c-5d0e7dacfb83@suse.cz> <99de1f59-1e38-6410-86ff-0ea1f016c49f@kernel.org> In-Reply-To: <99de1f59-1e38-6410-86ff-0ea1f016c49f@kernel.org> From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Sat, 12 Jun 2021 09:31:51 +0900 Message-ID: Subject: Re: [linux-next:master 7012/7430] include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_183' declared with attribute error: unexpected size in kmalloc_index() To: Nathan Chancellor Cc: Vlastimil Babka , kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Andrew Morton , Nick Desaulniers , clang-built-linux Content-Type: multipart/alternative; boundary="0000000000002eaf6a05c486c17f" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4CD04E000259 X-Stat-Signature: gijc5wp14pw63x3rfrtmpjy815rain36 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=eloI4URe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of 42hyeyoo@gmail.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=42hyeyoo@gmail.com X-HE-Tag: 1623457924-311045 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --0000000000002eaf6a05c486c17f Content-Type: text/plain; charset="UTF-8" On Sat, Jun 12, 2021, 1:56 AM Nathan Chancellor wrote: > On 6/11/2021 1:58 AM, Hyeonggon Yoo wrote:> After playing with clang > more a bit, I got to know that > > compiletime_assert makes weird link error (undefined reference to > > compiletime_assert_XXX), Not a compile error. > > > > > > I think it's time to CC ClangBuiltLinux maintainers, who work on > > clang/llvm build support. > > > > [+CC Nathan and Nick] > > > > I assumeed that compiletime_assert (in linux/compiler.h) will make > > compiler error, but it makes no compile error, just makes weird link > error. > > > > I'm not sure it it works well with clang, or somewhat buggy status? > > I am guessing this alone is why we were keyed into the thread so I am > just going to respond to this. > Thank you for quick reply! Unfortunately, this is a known issue with clang: > > https://github.com/ClangBuiltLinux/linux/issues/1173 > > https://bugs.llvm.org/show_bug.cgi?id=16428 > As you noticed, building the full kernel will result in a link error but > it would certainly be nicer if it were a compiler error. Something for > us to improve indeed but I am not sure when we will be able to allocate > resources for that. I wanted to be sure if we can use compiletime_assert for clang. Then there is room for improvement, but it seems okay. Until then, you can build a full kernel to get the > failing translation unit then use nm or readelf when building the single > translation unit to see if there are any "__compiletime_assert" symbols. > Okay, then we should find symbol like that until improved. It may confuse developer, but it seems okay for our code to support clang as it meets minimal condition - build failure. And I hope it become improved in future! Thanks, Hyeonggon Cheers, > Nathan > --0000000000002eaf6a05c486c17f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 12, 2021, 1:56 AM Nathan Chancellor <nathan@kernel.org> wrote:
On 6/11/2021 1:58 AM, Hyeonggon Yoo wrote:> Aft= er playing with clang
more a bit, I got to know that
> compiletime_assert makes weird link error (undefined reference to
> compiletime_assert_XXX), Not a compile error.
>
>
> I think it's time to CC ClangBuiltLinux maintainers, who work on <= br> > clang/llvm build support.
>
> [+CC Nathan and Nick]
>
> I assumeed that compiletime_assert (in linux/compiler.h) will make > compiler error, but it makes no compile error, just makes weird link e= rror.
>
> I'm not sure it it works well with clang, or somewhat buggy status= ?

I am guessing this alone is why we were keyed into the thread so I am
just going to respond to this.

Thank you for quick reply!



As you noticed, building the full kernel will result in a link error but it would certainly be nicer if it were a compiler error. Something for
us to improve indeed but I am not sure when we will be able to allocate resources for that.

I wanted to be sure if we can use compiletime_assert for cl= ang. Then there is room for improvement, but it seems okay.

Until then, you can build a full kernel to get the failing translation unit then use nm or readelf when building the single translation unit to see if there are any "__compiletime_assert" s= ymbols.

Okay, then we should find symbol like that until improved.

It may confuse developer, but it = seems okay for our code to support clang as it meets minimal condition - bu= ild failure.

And I hope = it become improved in future!

Thanks,
Hyeonggon

<= /div>
Cheers,
Nathan
--0000000000002eaf6a05c486c17f--