> Am 05.06.2024 um 16:08 schrieb Michael Matz :
>
> Hey,
>
>> On Wed, 5 Jun 2024, David Brown wrote:
>>
>> The ideal here would be to have some way to tell gcc that a given
>> function has the semantics of a different function. For example, a
>> programmer might have several
Hey,
On Wed, 5 Jun 2024, David Brown wrote:
> The ideal here would be to have some way to tell gcc that a given
> function has the semantics of a different function. For example, a
> programmer might have several implementations of "memcpy" that are
> optimised for different purposes based
Hello,
On Tue, 4 Jun 2024, Jakub Jelinek wrote:
> On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> > (Well, and without reverse-recognition of isfinite-like idioms in the
> > sources. That's orthogonal as well.)
>
> Why? If isfinite is better done by a libcall, why
On 04/06/2024 19:43, Michael Matz via Gcc wrote:
Hello,
On Tue, 4 Jun 2024, Richard Biener wrote:
A pragmatic solution might be a new target hook, indicating a specified
builtin is not to be folded into an open-coded form.
Well, that's what the mechanism behind -fno-builtin-foobar is
On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> (Well, and without reverse-recognition of isfinite-like idioms in the
> sources. That's orthogonal as well.)
Why? If isfinite is better done by a libcall, why isn't isfinite-like
idiom also better done as a libcall?
> Am 04.06.2024 um 16:56 schrieb Michael Matz :
>
> Hello,
>
> On Sat, 1 Jun 2024, Richard Biener via Gcc wrote:
>
> You have a pointer how to define a target optab? I looked into optabs
> code but found no appropriate hook. For isinf is seems is is
> enough to provide a
Hello,
On Sat, 1 Jun 2024, Richard Biener via Gcc wrote:
> >>> You have a pointer how to define a target optab? I looked into optabs
> >>> code but found no appropriate hook. For isinf is seems is is
> >>> enough to provide a failing expander, but other functions like isnan
> >>> don't have
> Am 01.06.2024 um 17:41 schrieb Georg-Johann Lay :
>
>
>
> Am 31.05.24 um 22:12 schrieb Richard Biener:
Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay :
>>>
>>>
>>>
>>> Am 31.05.24 um 19:32 schrieb Richard Biener:
>> Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
>
Am 31.05.24 um 22:12 schrieb Richard Biener:
Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay :
Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
Am 31.05.24 um 17:00 schrieb
> Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay :
>
>
>
> Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
>>>
>>>
>>>
On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
Am 31.05.24 um 17:00 schrieb
Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
Am 31.05.24 um 17:00 schrieb Paul Koning:
On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
What's the recommended way to
> Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc :
>
>
>
>> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
>>
>>
>>
>> Am 31.05.24 um 17:00 schrieb Paul Koning:
> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
>
> What's the recommended way to stop
> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote:
>
>
>
> Am 31.05.24 um 17:00 schrieb Paul Koning:
>>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
>>>
>>> What's the recommended way to stop built-in expansions in gcc?
>>>
>>> For example, avr-gcc expands isinff() to a
Am 31.05.24 um 17:00 schrieb Paul Koning:
On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an isinff()
implementation that's written in asm (PR115307).
> On May 31, 2024, at 9:52 AM, Georg-Johann Lay wrote:
>
> What's the recommended way to stop built-in expansions in gcc?
>
> For example, avr-gcc expands isinff() to a bloated version of an isinff()
> implementation that's written in asm (PR115307).
>
> Johann
Isn't that up to the target
On Fri, 31 May 2024 at 15:53, Georg-Johann Lay wrote:
>
>
>
> Am 31.05.24 um 15:56 schrieb Jonathan Wakely:
> > On Fri, 31 May 2024 at 14:52, Georg-Johann Lay wrote:
> >>
> >> What's the recommended way to stop built-in expansions in gcc?
> >>
> >> For example, avr-gcc expands isinff() to a
Am 31.05.24 um 15:56 schrieb Jonathan Wakely:
On Fri, 31 May 2024 at 14:52, Georg-Johann Lay wrote:
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an
isinff() implementation that's written in asm (PR115307).
On Fri, 31 May 2024 at 14:52, Georg-Johann Lay wrote:
>
> What's the recommended way to stop built-in expansions in gcc?
>
> For example, avr-gcc expands isinff() to a bloated version of an
> isinff() implementation that's written in asm (PR115307).
Did you try -fno-builtin-isinff ?
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an
isinff() implementation that's written in asm (PR115307).
Johann
19 matches
Mail list logo
