From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.24]) by sourceware.org (Postfix) with ESMTPS id 595203858D39 for ; Wed, 24 May 2023 15:52:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 595203858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de ARC-Seal: i=1; a=rsa-sha256; t=1684943530; cv=none; d=strato.com; s=strato-dkim-0002; b=FTpJ6KKT7Bl/VN6RQ/ENczQHUE/Eykc7FwKHdqmqVcH/J1SCJb9g6Weou5VYFsQEmo YzGI2adNxnH/jTAR0gEux+K6dqfRVCoB8zHn3qImemoLshEZiAm45LMaSP+rFCQFEB+M GgbHj2yjE7wuqHna/TaU2hx9IaUByltwOt4E2u3h/R5yBpMh9PLd7MkIFH/wJZ1aLnV0 wWdK+KgzP7+SwI79bYunfj+87cMrh193oxc/mIhVpfqvBx0YTRoFgOQ5hdOm8p5q9uea xzvw/Y91nb5mIG+/ASOp3GaYVRuegD2SaurcSocrKijXnWhvSJBBl/bWSRXRWIzD/0q4 DkKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1684943530; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=tp836MMrTZKIOGOIgRRRojWGGGuoDhP91t00xMnaQKI=; b=LhybShDhc6AHsGKirmMj1Tof8++c9/tGraEestGKuqLeWt24U/gOmBdHpxez3g+mJG o4xKGhJRneufegRd8zucVX8oxt5sSLXpBoQ8WCssMVYqXwYRMIWuugotboelBDsoEalN 3OSka3YBaKljrr77cd4/dQKLPuxW0FGS8TEYNvClkCuv/s+lvKwb0g1IWE/o2lRBu+ie d/itaRdCu1pOAl+jxHR6iAYa3vbrGRJcckfsa1Fa4PB1FPP0k3jCJHbnJ5oYzd7qjIls zSn3tc5Cny2kWudVrve1Sv228AhGTmWbdggn8ta9F+xwBLDiGb0CE87TVlkL1M6lopel r6gA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1684943530; s=strato-dkim-0002; d=gjlay.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=tp836MMrTZKIOGOIgRRRojWGGGuoDhP91t00xMnaQKI=; b=i5WQAxTyV8Auf0YngPHyqljdoY1J/8sfE1n1rpHDouh2tZ0ZwdpRpBHRNUwm/1CqkW SIbEDaHAZ2cBHuVZEha/btoozK+k7YPYhAGXMZWk5jrJUfPMGyRtSKaiJzjrrdC6k98j G/ZYCOTEAvJl5LjRRDfzTXw8Asr5cG4kxH39NwnxkApZcGCw1ebuE0evku2WYmu647uF RS5LevElJ8zUSmvnRTsO6dPzYHScmqCBrsoGtDed1b2yd0MaVJ912n+l66outFnmrfYZ SNj9f4HgJ2aCBE+aNmrkIlPAZNdVkjiFZvqLlbggb8vXAHU6/KVrcoUWM266LxzTdQd7 EWrg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1684943530; s=strato-dkim-0003; d=gjlay.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=tp836MMrTZKIOGOIgRRRojWGGGuoDhP91t00xMnaQKI=; b=xyJTYKTB7lx6HdNrhUtIlnoFZsXClyCmQqzrHW5G263LpzzbaszI3ximOpqN2oF53Y 8WGb5DvlcGFVhFqrySAw== X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkRmM69o2y+LiO3MutATA==" Received: from [192.168.2.102] by smtp.strato.de (RZmta 49.4.0 DYNA|AUTH) with ESMTPSA id z691f1z4OFqAmyk (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 24 May 2023 17:52:10 +0200 (CEST) Message-ID: <05f65ccb-c493-ac08-b6d4-3f0fc124012f@gjlay.de> Date: Wed, 24 May 2023 17:52:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: inlining failed in call to 'always_inline': target specific option mismatch Content-Language: en-US To: Richard Biener Cc: gcc@gcc.gnu.org References: <7a3552f0-ac4d-754f-a7ba-cba3ff9a4a41@gjlay.de> From: Georg-Johann Lay In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 List-Id: Am 24.05.23 um 11:28 schrieb Richard Biener: > On Tue, May 23, 2023 at 1:25 PM Georg-Johann Lay wrote: >> >> This error pops up in the testsuite for avr. >> >> As far as I understand, this is due to target-specific optimization like >> in avr-common.cc: >> >> { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_prologues, NULL, 1 }, >> { OPT_LEVELS_1_PLUS, OPT_mmain_is_OS_task, NULL, 1 }, >> // Stick to the "old" placement of the subreg lowering pass. >> { OPT_LEVELS_1_PLUS, OPT_fsplit_wide_types_early, NULL, 1 }, > > For testcases that have say __attribute__(optimize(0))? Do you have a specific > example? It's gcc.c-torture/compile/pr104327.c I came across this when checking fallout. That test case occurred for a target, but was put in generic space so other targets would be notified, too: /* PR target/104327 */ void foo (int *); static inline __attribute__((always_inline)) void bar (int *x) { foo (x); } __attribute__((cold, optimize("Os"))) void baz (int *x) { bar (x); } Johann >> My question is how to fix this. >> >> The backend does not implement can_inline_p, and adding "Optimization" >> to the respective option definition in avr.opt does not help. > > I think you'd need to implement the target hook and at least handle > the mismatches of target options you want to allow for inlining, As I wrote in the other answer, setting target options in attribute is nor supported. Target attributes should be diagnosed or even throw error. Johann > otherwise the default implementations rejects any mismatch, so > for example when a function has -mgas-isr-prologues but a callee > has not it will never inline that (not even with always-inline I think). It's actually find to inline anything, anywhere. I added the condition on interrupts because they get special prologues. Inlining ISR code in other functions would work, but its not graat style. Johann > > Richard.