Path: ...!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-a.proxad.net!nnrp1-1.free.fr!not-for-mail
Newsgroups: fr.comp.lang.c
Message-ID: <c306e695cc566ff7d41dc028fe73aa26c800babd.camel@free.fr>
Subject: Re: Fonction inline
From: Arnaud DUMERAT <adumerat@free.fr>
Date: Fri, 11 Feb 2022 00:54:17 +0100
In-Reply-To: <slrnt09e6q.9sg.JKB@hilbert.systella.fr>
References: <slrnsvg0vb.1acos.JKB@hilbert.systella.fr>
	 <eef897d1dd621e63a3809aff819faf097130371e.camel@free.fr>
	 <slrnt09e6q.9sg.JKB@hilbert.systella.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) 
MIME-Version: 1.0
Lines: 57
Organization: Guest of ProXad - France
NNTP-Posting-Date: 11 Feb 2022 00:54:18 CET
NNTP-Posting-Host: 82.66.111.70
X-Trace: 1644537258 news-4.free.fr 8888 82.66.111.70:44620
X-Complaints-To: abuse@proxad.net
Bytes: 3333

je vous sugg=C3=A8re la lecture du chapitre gcc concernant les fonctions
inline, qui mentionne diff=C3=A9rents cas d'optimisations pour lesquelles
l'inlining peut =C3=AAtre sous optimal; l'utilisation de mots clefs
compl=C3=A9mentaires peut aussi intervenir. le standard C n'=C3=A9tant que
suggestif sur le mot clef inline, toute libert=C3=A9 est laiss=C3=A9e au
compilateur si il n'y a que cet attribut.

Hors modification de code, je vous sugg=C3=A9rerais plut=C3=B4t un whole-ar=
chive
qui au regard de la taille de l'archive et de son utilisation pourrait
=C3=AAtre adapt=C3=A9, =C3=A0 moins que la place ou un =C3=A9ventuel code m=
ort ne soient
vraiment un probl=C3=A8me.

Le jeudi 10 f=C3=A9vrier 2022 =C3=A0 07:03 +0000, JKB a =C3=A9crit=C2=A0:
> Le 09-02-2022, Arnaud DUMERAT <adumerat@free.fr> a =C3=A9crit=C2=A0:
> > Bonjour,
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Bonjour,
>=20
> > la definition de uart0_BytesToSend est elle exposee dans libusart.a
> > ? a
> > en croire ld, non.
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nous sommes bien d'accord=
.. Mais il me semblait qu'une
> fonction
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0inline =C3=A9tait trait=
=C3=A9e par le compilateur et non par l'=C3=A9diteur
> de lien
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(puisqu'elle =C3=A9tait j=
ustement inline).
>=20
> > deux solutions (ou plus): passer en always inline (attribute) ou
> > forcer
> > l'export par exemple avec un -whole-archive dans la creation du .a
> > ou
> > verifier pourquoi la reference a cette definition est effacee de
> > l'archive
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Effectivement, je vois da=
ns la doc de gcc un=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__attribute__((always_inl=
ine))
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0que je ne connaissais pas=
.. Mais quelle serait la raison pour
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0laquelle gcc refuserait s=
ilencieusement d'honorer le inline
> de la
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fonction en question ?
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Bien cordialement,
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0JKB
>=20