Re: [RFC] MAINTAINERS: require a BZ account field
Arsen Arsenović writes: > Hi, > > Richard Biener writes: > >> [snip] >>> I was also proposing (and would like to re-air that here) enforcing >>> that the committer field of each commit is a (valid) @gcc.gnu.org >>> email. This can be configured repo-locally via: >>> >>> $ git config committer.email @gcc.gnu.org >>> >>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d >>> (v2.22.0). >>> >>> This makes a permanent association of each commit to its authors >>> Sourceware account. >> >> I'd welcome this - care to create a patch for >> contrib/gcc-git-customization.sh? > > Sure - I've attached a partial patch. I didn't find the hook which runs > on each push to check commits, so the current patch is minimal. Is that > also in the tree? I could try hacking it to check commits. See https://github.com/AdaCore/git-hooks.
Re: [RFC] MAINTAINERS: require a BZ account field
On 24/06/2024 22:34, Sam James via Gcc wrote: > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >account> > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > Further, that the field must not be blank (-> must have a BZ account; > there were/are some without at all)! > > Why? > --- > > 1) This is tied to whether or not people should use their committer email > on Bugzilla or a personal email. A lot of people don't seem to use their > committer email (-> no permissions) and end up not closing bugs, so > pinskia (and often myself these days) end up doing it for them. > > 2) It's standard practice to wish to CC the committer of a bisect result > - or to CC someone who you know wrote patches on a subject area. Doing > this on Bugzilla is challenging when there's no map between committer > <-> BZ account. > > Specifically, there are folks who have git committer+author as > joeblo...@example.com (or maybe even coold...@example.com) where the > local part of the address has *no relation* to their GCC/sw account, > so finding who to CC is difficult without e.g. trawling through gcc-cvs > mails or asking overseers for help. > > Summary > --- > > TL;DR: The proposal is: > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > email in full, or their gcc username (bikeshedding semi-welcome); > > 2) It should become a requirement that to be in MAINTAINERS, one must > possess a Bugzilla account (ideally using their gcc.gnu.org email). > > thanks, > sam How does this work for cases where: 1) Committer is pushing to a personal or other copy of the repository 2) Developers who have used the 'fetch' model to pull another developer's patches from 1 above? Forcing these to be rewritten will break the hashes. R.
Re: [RFC] MAINTAINERS: require a BZ account field
"Richard Earnshaw (lists)" writes: > On 24/06/2024 22:34, Sam James via Gcc wrote: >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> >> What? >> --- >> >> I propose that MAINTAINERS be modified to be of the form, >> adding an extra field for their GCC/sourceware account: >> > account> >> Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org >> >> Further, that the field must not be blank (-> must have a BZ account; >> there were/are some without at all)! >> >> Why? >> --- >> >> 1) This is tied to whether or not people should use their committer email >> on Bugzilla or a personal email. A lot of people don't seem to use their >> committer email (-> no permissions) and end up not closing bugs, so >> pinskia (and often myself these days) end up doing it for them. >> >> 2) It's standard practice to wish to CC the committer of a bisect result >> - or to CC someone who you know wrote patches on a subject area. Doing >> this on Bugzilla is challenging when there's no map between committer >> <-> BZ account. >> >> Specifically, there are folks who have git committer+author as >> joeblo...@example.com (or maybe even coold...@example.com) where the >> local part of the address has *no relation* to their GCC/sw account, >> so finding who to CC is difficult without e.g. trawling through gcc-cvs >> mails or asking overseers for help. >> >> Summary >> --- >> >> TL;DR: The proposal is: >> >> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >> email in full, or their gcc username (bikeshedding semi-welcome); >> >> 2) It should become a requirement that to be in MAINTAINERS, one must >> possess a Bugzilla account (ideally using their gcc.gnu.org email). >> >> thanks, >> sam > > > How does this work for cases where: > 1) Committer is pushing to a personal or other copy of the repository > 2) Developers who have used the 'fetch' model to pull another developer's > patches from 1 above? > > Forcing these to be rewritten will break the hashes. To be clear, my proposal doesn't touch on the actual git metadata people should use, although Arsen's followup one does. > > R. thanks, sam
Re: [RFC] MAINTAINERS: require a BZ account field
On Thu, 27 Jun 2024 at 13:26, Richard Earnshaw (lists) via Gcc wrote: > > On 24/06/2024 22:34, Sam James via Gcc wrote: > > Hi! > > > > This comes up in #gcc on IRC every so often, so finally > > writing an RFC. > > > > What? > > --- > > > > I propose that MAINTAINERS be modified to be of the form, > > adding an extra field for their GCC/sourceware account: > >> sourceware account> > > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > > > Further, that the field must not be blank (-> must have a BZ account; > > there were/are some without at all)! > > > > Why? > > --- > > > > 1) This is tied to whether or not people should use their committer email > > on Bugzilla or a personal email. A lot of people don't seem to use their > > committer email (-> no permissions) and end up not closing bugs, so > > pinskia (and often myself these days) end up doing it for them. > > > > 2) It's standard practice to wish to CC the committer of a bisect result > > - or to CC someone who you know wrote patches on a subject area. Doing > > this on Bugzilla is challenging when there's no map between committer > > <-> BZ account. > > > > Specifically, there are folks who have git committer+author as > > joeblo...@example.com (or maybe even coold...@example.com) where the > > local part of the address has *no relation* to their GCC/sw account, > > so finding who to CC is difficult without e.g. trawling through gcc-cvs > > mails or asking overseers for help. > > > > Summary > > --- > > > > TL;DR: The proposal is: > > > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > > email in full, or their gcc username (bikeshedding semi-welcome); > > > > 2) It should become a requirement that to be in MAINTAINERS, one must > > possess a Bugzilla account (ideally using their gcc.gnu.org email). > > > > thanks, > > sam > > > How does this work for cases where: > 1) Committer is pushing to a personal or other copy of the repository > 2) Developers who have used the 'fetch' model to pull another developer's > patches from 1 above? > > Forcing these to be rewritten will break the hashes. Good point. So enforcing it on a receive hook is probably too strict. We can encouraged gcc devs to set their committer.email to @gcc.gnu.org but not require all commits to have that.
Re: [RFC] MAINTAINERS: require a BZ account field
On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote: > Hi, > > Sam James via Gcc writes: > >> Hi! >> >> This comes up in #gcc on IRC every so often, so finally >> writing an RFC. >> >> What? >> --- >> >> I propose that MAINTAINERS be modified to be of the form, >> adding an extra field for their GCC/sourceware account: >> > account> >> Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org >> >> Further, that the field must not be blank (-> must have a BZ account; >> there were/are some without at all)! >> >> Why? >> --- >> >> 1) This is tied to whether or not people should use their committer email >> on Bugzilla or a personal email. A lot of people don't seem to use their >> committer email (-> no permissions) and end up not closing bugs, so >> pinskia (and often myself these days) end up doing it for them. >> >> 2) It's standard practice to wish to CC the committer of a bisect result >> - or to CC someone who you know wrote patches on a subject area. Doing >> this on Bugzilla is challenging when there's no map between committer >> <-> BZ account. >> >> Specifically, there are folks who have git committer+author as >> joeblo...@example.com (or maybe even coold...@example.com) where the >> local part of the address has *no relation* to their GCC/sw account, >> so finding who to CC is difficult without e.g. trawling through gcc-cvs >> mails or asking overseers for help. > > I was also proposing (and would like to re-air that here) enforcing that > the committer field of each commit is a (valid) @gcc.gnu.org email. > This can be configured repo-locally via: > > $ git config committer.email @gcc.gnu.org > > Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d > (v2.22.0). > > This makes a permanent association of each commit to its authors > Sourceware account. > > This should not inhibit pushes, as the committer should be a reflection > of who /applied/ a patch, and anyone applying a patch that can also push > has a Sourceware account. It also should not inhibit any workflow, as > it should be automatic. I think this presumes a strict 'git apply' model for incorporating patches from mailing lists, but what about contributors who do not have a sourceware account and rely on another developer to fetch from their tree and push it afterwards (eg the linux bubble-up model)? In that case the patch fetched will show the original author as the committer. R. > >> Summary >> --- >> >> TL;DR: The proposal is: >> >> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >> email in full, or their gcc username (bikeshedding semi-welcome); >> >> 2) It should become a requirement that to be in MAINTAINERS, one must >> possess a Bugzilla account (ideally using their gcc.gnu.org email). >
Re: [RFC] MAINTAINERS: require a BZ account field
On 27/06/2024 13:29, Sam James via Gcc wrote: > "Richard Earnshaw (lists)" writes: > >> On 24/06/2024 22:34, Sam James via Gcc wrote: >>> Hi! >>> >>> This comes up in #gcc on IRC every so often, so finally >>> writing an RFC. >>> >>> What? >>> --- >>> >>> I propose that MAINTAINERS be modified to be of the form, >>> adding an extra field for their GCC/sourceware account: >>> >> sourceware account> >>> Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org >>> >>> Further, that the field must not be blank (-> must have a BZ account; >>> there were/are some without at all)! >>> >>> Why? >>> --- >>> >>> 1) This is tied to whether or not people should use their committer email >>> on Bugzilla or a personal email. A lot of people don't seem to use their >>> committer email (-> no permissions) and end up not closing bugs, so >>> pinskia (and often myself these days) end up doing it for them. >>> >>> 2) It's standard practice to wish to CC the committer of a bisect result >>> - or to CC someone who you know wrote patches on a subject area. Doing >>> this on Bugzilla is challenging when there's no map between committer >>> <-> BZ account. >>> >>> Specifically, there are folks who have git committer+author as >>> joeblo...@example.com (or maybe even coold...@example.com) where the >>> local part of the address has *no relation* to their GCC/sw account, >>> so finding who to CC is difficult without e.g. trawling through gcc-cvs >>> mails or asking overseers for help. >>> >>> Summary >>> --- >>> >>> TL;DR: The proposal is: >>> >>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org >>> email in full, or their gcc username (bikeshedding semi-welcome); >>> >>> 2) It should become a requirement that to be in MAINTAINERS, one must >>> possess a Bugzilla account (ideally using their gcc.gnu.org email). >>> >>> thanks, >>> sam >> >> >> How does this work for cases where: >> 1) Committer is pushing to a personal or other copy of the repository >> 2) Developers who have used the 'fetch' model to pull another developer's >> patches from 1 above? >> >> Forcing these to be rewritten will break the hashes. > > To be clear, my proposal doesn't touch on the actual git metadata people > should use, although Arsen's followup one does. Oops! I've replied to Arsen's message directly. >> >> R. > > thanks, > sam
Re: [RFC] MAINTAINERS: require a BZ account field
On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote:
> Hi,
>
> Richard Biener writes:
>
>> [snip]
>>> I was also proposing (and would like to re-air that here) enforcing
>>> that the committer field of each commit is a (valid) @gcc.gnu.org
>>> email. This can be configured repo-locally via:
>>>
>>> $ git config committer.email @gcc.gnu.org
>>>
>>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>>> (v2.22.0).
>>>
>>> This makes a permanent association of each commit to its authors
>>> Sourceware account.
>>
>> I'd welcome this - care to create a patch for
>> contrib/gcc-git-customization.sh?
>
> Sure - I've attached a partial patch. I didn't find the hook which runs
> on each push to check commits, so the current patch is minimal. Is that
> also in the tree? I could try hacking it to check commits.
This won't work for developers who don't have a gcc account. Previously it
didn't matter what you said here, but now it will mess up any personal tree you
have.
+git config "committer.email" "${remote_id}@gcc.gnu.org"
R.
About the effect of "O0" on inlining into a function.
Hello If I declare a function __attribute__((noipa, optimize (“-O0”))), I was kinda expecting that it would not be optimized at all .. however it does not seem to prevent functions called by it from being inlined into its body .. am I missing some additional constraint that should be added? (I explicitly want to avoid called functions being inlined into the body, but cannot mark _those_ functions as noinline) thanks Iain
consistent unspecified pointer comparison
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html proposes to require that repeated unspecified comparisons be self-consistent, which does not match current behavior in either GCC or Clang. The argument is that the current allowance to be inconsistent is user-unfriendly and does not enable significant optimizations. Any feedback about this? Jason
Re: About the effect of "O0" on inlining into a function.
> On 27 Jun 2024, at 14:51, Iain Sandoe wrote: > > If I declare a function __attribute__((noipa, optimize (“-O0”))), I was kinda > expecting that it would not be optimized at all .. > > however it does not seem to prevent functions called by it from being inlined > into its body .. > > am I missing some additional constraint that should be added? > > (I explicitly want to avoid called functions being inlined into the body, but > cannot mark _those_ functions as noinline) Additional: If I compile the entire code “O0” then all behaves as expected. The issue seems to be when compiing (say) O2 and a function has a local optimisation set lower (O0) .. perhaps this is a target problem .. although looking at say tree-ssa-ccp.cc I do not see any gating on the optimisation level - which I guess suggests once it’s selected in the stack .. it’s going to run… any insights would be welcome. Iain
Re: consistent unspecified pointer comparison
Am Donnerstag, dem 27.06.2024 um 13:02 -0400 schrieb Jason Merrill via Gcc: > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > proposes to require that repeated unspecified comparisons be > self-consistent, which does not match current behavior in either GCC > or Clang. The argument is that the current allowance to be > inconsistent is user-unfriendly and does not enable significant > optimizations. Any feedback about this? Making pointer comparison self-consistent in cases where there is no UB makes a lot of sense, because everything else is dangerous. This is not the only thing this paper proposes. I do not think angelic / demonic nondeterminism is good language design, and especially think it is not a good fit for systems languages such as C or C++. Also most programmers will not understand it. Martin
Re: consistent unspecified pointer comparison
> Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > proposes to require that repeated unspecified comparisons be > self-consistent, which does not match current behavior in either GCC > or Clang. The argument is that the current allowance to be > inconsistent is user-unfriendly and does not enable significant > optimizations. Any feedback about this? Can you give an example of an unspecified comparison? I think the only way to do what the paper wants is for the implementation to make the comparison specified (without the need to document it). Is the self-consistency required only within some specified scope (a single expression?) or even across TUs (which might be compiled by different compilers or compiler versions)? So my feedback would be to make the comparison well-defined. I’m still curious about which ones are unspecified now. Richard > > Jason >
Re: consistent unspecified pointer comparison
On Thu, Jun 27, 2024 at 2:38 PM Richard Biener wrote: > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > > proposes to require that repeated unspecified comparisons be > > self-consistent, which does not match current behavior in either GCC > > or Clang. The argument is that the current allowance to be > > inconsistent is user-unfriendly and does not enable significant > > optimizations. Any feedback about this? > > Can you give an example of an unspecified comparison? I think the only way > to do what the paper wants is for the implementation to make the comparison > specified (without the need to document it). Is the self-consistency > required only within some specified scope (a single expression?) or even > across TUs (which might be compiled by different compilers or compiler > versions)? > > So my feedback would be to make the comparison well-defined. > > I’m still curious about which ones are unspecified now. https://eel.is/c++draft/expr#eq-3.1 "If one pointer represents the address of a complete object, and another pointer represents the address one past the last element of a different complete object, the result of the comparison is unspecified." This is historically unspecified primarily because we don't want to force a particular layout of multiple variables. See the example under "consequences for implementations" in the paper. Jason
Re: consistent unspecified pointer comparison
> Am 27.06.2024 um 20:55 schrieb Jason Merrill : > > On Thu, Jun 27, 2024 at 2:38 PM Richard Biener > wrote: Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : >>> >>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html >>> proposes to require that repeated unspecified comparisons be >>> self-consistent, which does not match current behavior in either GCC >>> or Clang. The argument is that the current allowance to be >>> inconsistent is user-unfriendly and does not enable significant >>> optimizations. Any feedback about this? >> >> Can you give an example of an unspecified comparison? I think the only way >> to do what the paper wants is for the implementation to make the comparison >> specified (without the need to document it). Is the self-consistency >> required only within some specified scope (a single expression?) or even >> across TUs (which might be compiled by different compilers or compiler >> versions)? >> >> So my feedback would be to make the comparison well-defined. >> >> I’m still curious about which ones are unspecified now. > > https://eel.is/c++draft/expr#eq-3.1 > "If one pointer represents the address of a complete object, and > another pointer represents the address one past the last element of a > different complete object, the result of the comparison is > unspecified." > > This is historically unspecified primarily because we don't want to > force a particular layout of multiple variables. > > See the example under "consequences for implementations" in the paper. And how do we currently not have consistent behavior? I don’t think we constantly fold such comparisons in any way but we could take advantage of the unspecifiedness in more complex situations (though I can’t come up with one off my head). Richard > Jason >
Re: About the effect of "O0" on inlining into a function.
> Am 27.06.2024 um 19:43 schrieb Iain Sandoe : > > >> On 27 Jun 2024, at 14:51, Iain Sandoe wrote: >> >> If I declare a function __attribute__((noipa, optimize (“-O0”))), I was >> kinda expecting that it would not be optimized at all .. >> >> however it does not seem to prevent functions called by it from being >> inlined into its body .. >> >> am I missing some additional constraint that should be added? >> >> (I explicitly want to avoid called functions being inlined into the body, >> but cannot mark _those_ functions as noinline) > > Additional: If I compile the entire code “O0” then all behaves as expected. > > The issue seems to be when compiing (say) O2 and a function has a local > optimisation set lower (O0) .. > perhaps this is a target problem .. > although looking at say tree-ssa-ccp.cc I do not see any gating on the > optimisation level - which I guess suggests once it’s selected in the stack > .. it’s going to run… > > any insights would be welcome. It might be that we do not honor -O0 in the caller this way during IPA inlining. I would guess it correctly disables early inlining into it though. It sounds like a bug to me. Richard > Iain > >
Re: consistent unspecified pointer comparison
On Thu, Jun 27, 2024 at 11:57 AM Jason Merrill via Gcc wrote: > > On Thu, Jun 27, 2024 at 2:38 PM Richard Biener > wrote: > > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > > > > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > > > proposes to require that repeated unspecified comparisons be > > > self-consistent, which does not match current behavior in either GCC > > > or Clang. The argument is that the current allowance to be > > > inconsistent is user-unfriendly and does not enable significant > > > optimizations. Any feedback about this? > > > > Can you give an example of an unspecified comparison? I think the only way > > to do what the paper wants is for the implementation to make the comparison > > specified (without the need to document it). Is the self-consistency > > required only within some specified scope (a single expression?) or even > > across TUs (which might be compiled by different compilers or compiler > > versions)? > > > > So my feedback would be to make the comparison well-defined. > > > > I’m still curious about which ones are unspecified now. > > https://eel.is/c++draft/expr#eq-3.1 > "If one pointer represents the address of a complete object, and > another pointer represents the address one past the last element of a > different complete object, the result of the comparison is > unspecified." > > This is historically unspecified primarily because we don't want to > force a particular layout of multiple variables. > > See the example under "consequences for implementations" in the paper. There is instability due to floating point too; https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 and uninitialized variables: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 (but that might be fixed via https://wg21.link/P2795R5). > > Jason >
Re: consistent unspecified pointer comparison
Am Donnerstag, dem 27.06.2024 um 12:05 -0700 schrieb Andrew Pinski via Gcc: > On Thu, Jun 27, 2024 at 11:57 AM Jason Merrill via Gcc > wrote: > > > > On Thu, Jun 27, 2024 at 2:38 PM Richard Biener > > wrote: > > > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > > > > > > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > > > > proposes to require that repeated unspecified comparisons be > > > > self-consistent, which does not match current behavior in either GCC > > > > or Clang. The argument is that the current allowance to be > > > > inconsistent is user-unfriendly and does not enable significant > > > > optimizations. Any feedback about this? > > > > > > Can you give an example of an unspecified comparison? I think the only > > > way to do what the paper wants is for the implementation to make the > > > comparison specified (without the need to document it). Is the > > > self-consistency required only within some specified scope (a single > > > expression?) or even across TUs (which might be compiled by different > > > compilers or compiler versions)? > > > > > > So my feedback would be to make the comparison well-defined. > > > > > > I’m still curious about which ones are unspecified now. > > > > https://eel.is/c++draft/expr#eq-3.1 > > "If one pointer represents the address of a complete object, and > > another pointer represents the address one past the last element of a > > different complete object, the result of the comparison is > > unspecified." > > > > This is historically unspecified primarily because we don't want to > > force a particular layout of multiple variables. > > > > See the example under "consequences for implementations" in the paper. > > There is instability due to floating point too; > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 > > and uninitialized variables: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301 > (but that might be fixed via https://wg21.link/P2795R5). For pointer comparison: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Martin > > > > > Jason > >
gcc-12-20240627 is now available
Snapshot gcc-12-20240627 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240627/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 95ca5f458251e21123e45ec52c38d629d39cd0e4 You'll find: gcc-12-20240627.tar.xz Complete GCC SHA256=9d6b917f6a30d776b89efffdd823c9463284f3db51bdbfcf8c821549a46ed5d2 SHA1=4ae99058a9871b0ecd1dfaaa795eee255b6094fe Diffs from 12-20240620 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: About the effect of "O0" on inlining into a function.
> On 27 Jun 2024, at 20:06, Richard Biener via Gcc wrote: >> Am 27.06.2024 um 19:43 schrieb Iain Sandoe : >>> On 27 Jun 2024, at 14:51, Iain Sandoe wrote: >>> >>> If I declare a function __attribute__((noipa, optimize (“-O0”))), I was >>> kinda expecting that it would not be optimized at all .. >>> >>> however it does not seem to prevent functions called by it from being >>> inlined into its body .. >>> >>> am I missing some additional constraint that should be added? >>> >>> (I explicitly want to avoid called functions being inlined into the body, >>> but cannot mark _those_ functions as noinline) >> >> Additional: If I compile the entire code “O0” then all behaves as expected. >> >> The issue seems to be when compiing (say) O2 and a function has a local >> optimisation set lower (O0) .. >> perhaps this is a target problem .. >> although looking at say tree-ssa-ccp.cc I do not see any gating on the >> optimisation level - which I guess suggests once it’s selected in the stack >> .. it’s going to run… >> >> any insights would be welcome. > > It might be that we do not honor -O0 in the caller this way during IPA > inlining. I would guess it correctly disables early inlining into it though. > It sounds like a bug to me. Pilot error — synthesizing function decls sometimes needs to emulate some of the parser actions. It’s not enough to attach the attributes to the decl, in some cases the attributes machinery processes them at parse time and adds internal information to the decl itself. That is the case here. So no bug - at least, I can now build a fn that has no optimisation. thanks Iain
