> 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
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
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:
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
> 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
> 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 unspec
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
> 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
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
> 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
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 doe
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?
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:
>>>
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
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
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
"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/s
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:
>a
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
19 matches
Mail list logo
