Hi Martin,
On Thu, Jul 11, 2024 at 06:34:04PM GMT, Alejandro Colomar wrote:
> Hi Martin, David,
>
> On Thu, Jul 11, 2024 at 06:08:38PM GMT, David Brown wrote:
> > On 11/07/2024 11:58, Martin Uecker via Gcc wrote:
> > > > [[gnu::access(read_write, 1)]]
> > > > [[gnu::access(read_on
Hi Martin, David,
On Thu, Jul 11, 2024 at 06:08:38PM GMT, David Brown wrote:
> On 11/07/2024 11:58, Martin Uecker via Gcc wrote:
> > > [[gnu::access(read_write, 1)]]
> > > [[gnu::access(read_only, 2)]]
> > > [[gnu::nonnull(1, 2)]]
> > > [[gnu::null_terminated_string_arg(2)]]
> > > char *
On 11/07/2024 11:58, Martin Uecker via Gcc wrote:
Am Donnerstag, dem 11.07.2024 um 11:35 +0200 schrieb Alejandro Colomar via Gcc:
Hi,
I was wondering how we could extend attributes such as gnu::access() to
apply it to pointees too. Currently, there's no way to specify the
access mode of a poi
Am Donnerstag, dem 11.07.2024 um 11:35 +0200 schrieb Alejandro Colomar via Gcc:
> Hi,
>
> I was wondering how we could extend attributes such as gnu::access() to
> apply it to pointees too. Currently, there's no way to specify the
> access mode of a pointee.
>
> Let's take for example strsep(3
On Sat, 11 Jun 2022 at 21:17, Alejandro Colomar wrote:
> P.S.: Please consider deprecating 'auto' some day. It would be nice to
> see C++'s auto in ISO C some day, even if it's 2060. I'm not entirely
> happy doing `#define auto __auto_type` (of course it's UB, but it's nice) ;)
There's a proposa
On 6/11/22 14:08, Gabriel Ravier wrote:
> Do we want to add a completely unnecessary feature, just for symmetry
with C++, even if it poses a danger of breaking (both human and script)
readability of function declarations/definitions, especially when hidden
in macros?
I actually don't get th
On Sat, 11 Jun 2022, 10:00 Alejandro Colomar,
wrote:
> Hi Jonathan,
>
> On 6/11/22 00:47, Jonathan Wakely wrote:
> > Well, I'd argue the same reasons to remove it from C++. Don't know
> how
> > useful that feature is for C++, though. I bet not much, but am not
> an
> > expert in the
On 6/11/22 11:03, Alejandro Colomar via Gcc wrote:
> Hi Jonathan,
>
> On 6/11/22 00:47, Jonathan Wakely wrote:
>> Well, I'd argue the same reasons to remove it from C++. Don't
know how
>> useful that feature is for C++, though. I bet not much, but am
not an
>> expert in the langua
Hi Jonathan,
On 6/11/22 00:47, Jonathan Wakely wrote:
Well, I'd argue the same reasons to remove it from C++. Don't know how
useful that feature is for C++, though. I bet not much, but am not an
expert in the language.
It's used in libstdc++ because I couldn't get an attribute to
On Fri, 10 Jun 2022, 22:29 Alejandro Colomar via Gcc,
wrote:
> [I reordered some of your answers, to better answer]
>
> Hi Jakub,
>
> On 6/10/22 23:16, Jakub Jelinek wrote:
> > On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc
> wrote:
> >> So, could you please drop that from C2
Hi Joseph,
On 6/10/22 23:09, Joseph Myers wrote:
P.S.: The latest draft that I know of is N2731. I guess there are newer ones.
Could you please name the latest one?
It's N2912 (June 8 version - the version originally published on June 7
had various problems; there are still some issues, espec
[I reordered some of your answers, to better answer]
Hi Jakub,
On 6/10/22 23:16, Jakub Jelinek wrote:
On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
So, could you please drop that from C2x?
No!
[[attr0]] void foo (void), bar (void);
appertains to both declara
On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
> So, could you please drop that from C2x?
No!
For one it diverges from C++, but also it means something different
at the different locations.
[[attr0]] void foo (void), bar (void);
appertains to both declarations, while
v
On Fri, 10 Jun 2022, Alejandro Colomar via Gcc wrote:
> I'd like to suggest a change in C2x regarding attributes.
The attribute syntax is supposed to accept attributes in exactly the
places they are accepted in C++ (and appertaining to the same entity, for
each such place), for constructs prese
Hi, Joseph!
I'd like to suggest a change in C2x regarding attributes.
Right now, the draft allows function attributes to go right at the
beginning of a function prototype, or just before the opening parenthesis:
[[attr]] type f(params);
type f [[attr]](params);
I'd argue against
s used in a
> > [[gnu::const(...)]] annotated function each call to this function is
> > considered an observable effect to the function.
> >
> >
> > *[[gnu::const([():],...)]]*
> > This is an extension to the old [[gnu::const]] attribute. But: When some of
> &g
[CC gcc list and Sandra]
Thanks for the suggestions. I agree that the documentation
should make it possible to answer at least the basic questions
on your list. We'll see about incorporating them.
In general, attributes that affect optimization are implemented
at a level where higher-level dis
pend on a function/expression, which
calls the annotated function.
*[[gnu::calls([():],...)]]*
This function attributes tells the compiler, that the given expression
might be called inside. This makes older values recieved from
[[gnu::const(...)]] functions (which depend on (parts of) the expression)
tated function.
*[[gnu::calls([():],...)]]*
This function attributes tells the compiler, that the given expression
might be called inside. This makes older values recieved from
[[gnu::const(...)]] functions (which depend on (parts of) the expression)
dirty when called. The attribute is inherited to p
t (options)'
accepts all options as mentioned in [3], expect ...
If it's acceptable opinion, I can prepare a patch.
Thanks,
Martin
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652#c4
[2]
https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes
[3]
Hi Umesh/Ian,
I followed the steps and it has generated the required branch instruction.
Thankyou so much for the links and steps.
On Wed, Oct 16, 2013 at 4:00 PM, Umesh Kalappa wrote:
> Here you go ,
>
> a)define new field in the struct "CUMULATIVE_ARGS" says as int long_call;
>
> b)set
Here you go ,
a)define new field in the struct "CUMULATIVE_ARGS" says as int long_call;
b)set the field long_call to known vlaue@ init_cumulative_args() .
c)In the TARGET_FUNCTION_ARG hook
The last time this MACRO is called, it is called with
MODE == VOIDmode, and its result is
Yes.. I still had no luck.
Do you have any thoughts on this??
On Wed, Oct 16, 2013 at 2:05 PM, Umesh Kalappa wrote:
> You still stuck with this issue ???
>
> ~Umesh
>
> On Tue, Oct 15, 2013 at 9:08 PM, Ian Lance Taylor wrote:
>> On Tue, Oct 15, 2013 at 8:04 AM, Nagaraju Mekala
>> wrote:
>>> H
You still stuck with this issue ???
~Umesh
On Tue, Oct 15, 2013 at 9:08 PM, Ian Lance Taylor wrote:
> On Tue, Oct 15, 2013 at 8:04 AM, Nagaraju Mekala
> wrote:
>> Hi Ian,
>>
>> Thanks for the reply.
>>
>> On Fri, Oct 11, 2013 at 10:31 PM, Ian Lance Taylor wrote:
>>> On Fri, Oct 11, 2013 at
On Tue, Oct 15, 2013 at 8:04 AM, Nagaraju Mekala wrote:
> Hi Ian,
>
> Thanks for the reply.
>
> On Fri, Oct 11, 2013 at 10:31 PM, Ian Lance Taylor wrote:
>> On Fri, Oct 11, 2013 at 9:20 AM, Nagaraju Mekala
>> wrote:
>>>
>>> I observed that in rs6000 port longcall is implemented by using
>>>
Hi Ian,
Thanks for the reply.
On Fri, Oct 11, 2013 at 10:31 PM, Ian Lance Taylor wrote:
> On Fri, Oct 11, 2013 at 9:20 AM, Nagaraju Mekala
> wrote:
>>
>> I observed that in rs6000 port longcall is implemented by using
>> CALL_LONG define.
>> #define CALL_LONG 0x0008 /* always call indir
On Fri, Oct 11, 2013 at 9:20 AM, Nagaraju Mekala wrote:
>
> I observed that in rs6000 port longcall is implemented by using
> CALL_LONG define.
> #define CALL_LONG 0x0008 /* always call indirect */
> In the md file they are checking the operand with CALL_LONG
> if (INTVAL (operands[3]) & CALL_
func)
>> {
>> tree a;
>> if (TREE_CODE (func) != FUNCTION_DECL)
>> return 0;
>> a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
>> return a != NULL_TREE;
>> }
>>
>>
>> How to get the information of function att
(tree func)
> {
> tree a;
> if (TREE_CODE (func) != FUNCTION_DECL)
> return 0;
> a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
> return a != NULL_TREE;
> }
>
>
> How to get the information of function attributes even before entering
CTION_DECL)
return 0;
a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
return a != NULL_TREE;
}
How to get the information of function attributes even before entering
to prologue or during function call itself??
Thanks,
Nag
> > At least the Linux kernel has a couple such cases ("nasty inline asm to
> > hide register clobbering in calls") and it's always ugly and hard to
> > maintain.
>
> It would simply be an alternate ABI that makes all registers callee-saved?
Yes exactly that.
-Andi
--
a...@linux.intel.com -- Sp
On Mon, Oct 17, 2011 at 02:57, Richard Guenther
> It would simply be an alternate ABI
that makes all registers callee-saved?
> I suppose that would be not too hard to add.
That would be great. There are quite a few interfaces which have a
trivial normal case and only in special situations you ne
On Mon, Oct 17, 2011 at 1:36 AM, Andi Kleen wrote:
> Ulrich Drepper writes:
>>
>> It's not guaranteed to work in general. The problem to solve is that
>> I know the function which is called is not clobbering any registers.
>> If I leave it with the normal function call gcc has to spill
>> regist
Ulrich Drepper writes:
>
> It's not guaranteed to work in general. The problem to solve is that
> I know the function which is called is not clobbering any registers.
> If I leave it with the normal function call gcc has to spill
> registers. If I can hide the function call the generated code ca
On Sun, Oct 16, 2011 at 14:38, Jakub Jelinek wrote:
> If this is about e.g.
> 2011-09-14 Ulrich Drepper
>
> * sysdeps/x86_64/fpu/bits/mathinline.h (__MATH_INLINE): Use
> __extern_always_inline.
> Define lrint{f,} and llrint{f,} for 64-bit and in some situations for
>
On Sat, Oct 15, 2011 at 05:52:03PM -0400, Ulrich Drepper wrote:
> I think gcc should allow the programmer to tell it something about a
> function return value even if the function is inlined and the compiler
> can see all the code. Consider the code below.
If this is about e.g.
2011-09-14 Ulrich
On Sun, Oct 16, 2011 at 06:31, Richard Guenther
wrote:
> The question is now, of course why you need to emit calls
> from an asm() statement, something which isn't guaranteed
> to work anyway (IIRC).
It's not guaranteed to work in general. The problem to solve is that
I know the function which i
On Sat, Oct 15, 2011 at 11:52 PM, Ulrich Drepper wrote:
> I think gcc should allow the programmer to tell it something about a
> function return value even if the function is inlined and the compiler
> can see all the code. Consider the code below.
>
> If NOINLINE is defined the compiler will cal
I think gcc should allow the programmer to tell it something about a
function return value even if the function is inlined and the compiler
can see all the code. Consider the code below.
If NOINLINE is defined the compiler will call g once. No need to do
anything after the h() call since the fun
er the attribute stuff) the warning is gone. In
> both cases (and when the function was used) it is put in the
> ".init.text" section though. That is in the first case __init worked,
> but __maybe_unused did not. Is this intended? Do I something wrong?
> What is the most
t.text" section though. That is in the first case __init worked,
but __maybe_unused did not. Is this intended? Do I something wrong?
What is the most correct position for function attributes for functions
returning a pointer?
(I'm using gcc 4.3.2 for arm, OSELAS.Toolchain-1.99.3.6 here.
Weddington, Eric schrieb:
Hi All,
This may be a dumb question, but I'm having difficulty finding the answer to
this.
I'm working on a back-end and I have a function being called for the
FUNCTION_ARG macro, and in that function I need to find out the attributes of
the called function as this
Hi All,
This may be a dumb question, but I'm having difficulty finding the answer to
this.
I'm working on a back-end and I have a function being called for the
FUNCTION_ARG macro, and in that function I need to find out the attributes of
the called function as this will affect the calling conv
e TARGET_ATTRIBUTE_TABLE and friends. There
are examples in several backends, including, e.g., i386.
> 2. Any documentation regarding adding new function attributes?
Yes, some, in the internals manual around TARGET_ATTRIBUTE_TABLE.
> 3. If i have to emit an assembler directive based on the
documentation regarding adding new function attributes?
3. If i have to emit an assembler directive based on the flag status,
where should i look for?
4. If i specify the attribute at the time of function declaration and
i need to update the same flag while defining the function, where
should i look to
45 matches
Mail list logo
