Hi.
We're trying to remove the duplication of the attributes code between
the C and libgccjit frontend.
The attached patch shows a draft of this attempt that only supports a
few attributes.
Would that kind of approach be acceptable (I'm not sure since this
includes a c-family file in
Hello
Antoni Boucher wrote:
> We're trying to remove the duplication of the attributes code between
> the C and libgccjit frontend.
> The attached patch shows a draft of this attempt that only supports a
> few attributes.
> Would that kind of approach be acceptable (I&#
On Tue, Mar 18, 2025 at 4:49 PM Antoni Boucher via Gcc wrote:
>
> Hi.
> We're trying to remove the duplication of the attributes code between
> the C and libgccjit frontend.
> The attached patch shows a draft of this attempt that only supports a
> few attributes.
> Woul
return a const char * for the type.
Yes, const char* would be easier. I just didn't know how to alloc one,
and where. A new const char* property in class attr_desc_would solve
it.
And then in turn we can pass a const char * to (f)print_c_condition.
The MD reader then wouldn't need to know
that area; better someone more experienced would take it over.
>
>> it causes anything to break, I think we should fix whatever that breaking
>> thing is. Could you try doing that, as a pre-patch? Or I can give it a
>> go, if you'd rather not.
>
> Yes please.
ubmission,
but it looks mostly ready to go. Some comments below:
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 7f4335e0aac..3e46693e8c2 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -10265,6 +10265,56 @@ so there is no need to explicitly convert the
expression into a boolean
> in the symbol_ref as an expression. Though I think this
> could be a nice addition, in particular because the scanning
> side in md_reader already supports the syntax.
Looks good to me. I know you said it wasn't a patch submission,
but it looks mostly ready to go. Some comments
t; > > > [[gnu::access(read_only, 2)]]
> > > > [[gnu::nonnull(1, 2)]]
> > > > [[gnu::null_terminated_string_arg(2)]]
> > > > char *
> > > > strsep(char **restrict sp, const char *delim);
> > >
&
terminated_string_arg(2)]]
> > > char *
> > > strsep(char **restrict sp, const char *delim);
> >
> > The main problem from a user perspective is that
> > these are attributes on the function declaration
> > and not on the argument (type).
> >
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
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
65,56 @@ so there is no need to explicitly convert the expression into a boolean
(match_test "(x & 2) != 0")
@end smallexample
+@cindex @code{symbol_ref} and attributes
+@item (symbol_ref "@var{quoted-c-expr}")
+
+Specifies the value of the attribute sub-expression as a C e
out
unreferenced variables that are initialized via that constructor.
<https://reviews.llvm.org/D148505> "Allow
`__attribute__((warn_unused))` on individual constructors" would
implement that for Clang---but was met with some reservation for now,
due to the already somewhat confusing landsc
__attribute__((warn_unused)), the compiler could warn about
> unreferenced variables that are initialized via that constructor.
> <https://reviews.llvm.org/D148505> "Allow
> `__attribute__((warn_unused))` on individual constructors" would
> implement that for Clang---but was me
[cross-posting this to both the GCC and Clang communities]
I have two specific issues on the subject I would like to discuss below.
But first a quick overview:
C++ has two attributes dealing with warnings about unused entities:
* In one direction (making the compiler suppress warnings it
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 co
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
oval of null pointer checks).
> > >
> >
> > That's a fair point.
> >
> > Here's a v3 of the patch, which tones down the advice, and mentions
> > that
> > there are caveats when directing the reader to the "nonnull"
> > a
* doc/extend.texi (Common Function Attributes): Document that
'access' does not imply 'nonnull'.
Signed-off-by: David Malcolm
---
gcc/doc/extend.texi | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a4a25e8
he nonnull attribute here. This
> attribute could have pretty dangerous effects in the function
> definition
> (removal of null pointer checks).
>
That's a fair point.
Here's a v3 of the patch, which tones down the advice, and mentions that
there are caveats when directin
On 23/03/2022 17:31, Martin Sebor via Gcc-patches wrote:
The concern is that the constraints implied by atttributes access and
nonnull are independent of each other. I would suggest to document
that without talking about dereferencing because that's not implied
by either of them. E.g., somethi
onnull - though perhaps there are cases
where
APIs
check for NULL and reject them gracefully?
No, I think they are separate. The access just says these access
attributes are read only, write only, read-write or don't access
what
the pointer points to; it does not say they have to be read or
writt
, that parameter is probably
> > > > going
> > > > to
> > > > be required to be nonnull - though perhaps there are cases
> > > > where
> > > > APIs
> > > > check for NULL and reject them gracefully?
> > >
> > >
think they are separate. The access just says these access
attributes are read only, write only, read-write or don't access what
the pointer points to; it does not say they have to be read or
written
to.
I think it is a bad idea to connect the two ideas because you could
have some cases
t; > to
> > be required to be nonnull - though perhaps there are cases where
> > APIs
> > check for NULL and reject them gracefully?
>
> No, I think they are separate. The access just says these access
> attributes are read only, write only, read-write or don't a
David Malcolm via Gcc writes:
> I think I want a way for the user to be able to mark security
> boundaries in their code: for example:
> * in the Linux kernel the boundary between untrusted user-space data
> and kernel data, or,
> * for a user-space daemon, the boundary between data coming from t
On 4/29/21 11:18 AM, David Malcolm wrote:
I've been going through old Linux kernel CVEs, trying to prototype some
possible new warnings for -fanalyzer in GCC 12 (and, alas, finding
places where the analyzer internals need work...)
I think I want a way for the user to be able to mark security
bou
I've been going through old Linux kernel CVEs, trying to prototype some
possible new warnings for -fanalyzer in GCC 12 (and, alas, finding
places where the analyzer internals need work...)
I think I want a way for the user to be able to mark security
boundaries in their code: for example:
* in the
GCC manual (https://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html)
states that a result tree for a FUNCTION_DECL can be obtained by using a
DECL_RESULT macro. This does not seem to be the case when processing
user-defined attributes via a plugin - when GCC calls my callback for
handling the
ion of the lookup table/api; or is it guaranteed, that the
> > function is only called in places, where it would be called without the
> > attribute. I also propose some additional attributes to let the programmer
> > clarify his/her intentions.
>
> The purpose of the const at
[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-
also propose some additional attributes to let the programmer
clarify his/her intentions.
The purpose of the const attribute is to let GCC assume that
invocations of a function it's on with the same argument values
yield the same result no matter when they are made. Any function
that sati
variables like a lookup table
or the initialization of an api? Does GCC may invoke the function before
the initialization of the lookup table/api; or is it guaranteed, that the
function is only called in places, where it would be called without the
attribute. I also propose some additional attributes
is attribute.
>
>
> Does affects_type_identity cause other user visible changes ? For e.g. based
> on
> a cursory look it appears to affect mangling in C++. The comment in
> tree-core.h
> simply says this affects the type's identity presumably implying that this
>
On 09/01/2016 09:04 AM, Martin Sebor wrote:
Understood. I think a write-only attribute or type qualifier would
make sense. Until/unless it's implemented I would recommend to work
around its absence by hiding access to the registers behind a read-
only and write-only functional API.
As you note
Hi Martin (and all other list members).
On Thu, 1 Sep 2016 09:04:10 -0600, Martin Sebor wrote:
> On 08/31/2016 04:56 AM, Jens Bauer wrote:
>>>__attribute__ ((not_readable)) int write_only;
>>>int *preadwrite = &write_only;
>>
>> Would it not be possible to bring a warning in such cases ?
, attribute not_readable would need to be elevated
to the status of a type qualifier analogous to const. Otherwise it
would (likely, if applied as most other attributes) be lost during
conversions such as in
__attribute__ ((not_readable)) int write_only;
int *preadwrite = &write_only;
Woul
Hi Florian.
On Thu, 1 Sep 2016 15:21:27 +0200, Florian Weimer wrote:
>> So I'd like to propose the following two attributes, which is 'off'
>> by default (eg. read access + write access):
>> __attribute__((not_readable))
>> __attribute__((not_writable))
>
ucture
member 'read-only', 'write-only' or 'read+write'.
In addition to that, it would definitely be handy to declare variables 'no
access'
So I'd like to propose the following two attributes, which is 'off' by default
(eg. read access +
to be elevated
> to the status of a type qualifier analogous to const. Otherwise it
> would (likely, if applied as most other attributes) be lost during
> conversions such as in
>
> __attribute__ ((not_readable)) int write_only;
> int *preadwrite = &write_only;
Would it not be
ucture
member 'read-only', 'write-only' or 'read+write'.
In addition to that, it would definitely be handy to declare variables 'no
access'
So I'd like to propose the following two attributes, which is 'off' by default
(eg. read access +
write-only' or 'read+write'.
In addition to that, it would definitely be handy to declare variables 'no
access'
So I'd like to propose the following two attributes, which is 'off' by default
(eg. read access + write access):
__attribute__((not_readable))
_
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]
On Tue, May 19, 2015 at 03:17:26PM +0100, Kyrill Tkachov wrote:
> Hi all,
Sorry, it took me awhile to comment.
> I'm working on enabling target attributes and pragmas on aarch64 and I'm
> stuck on a particular issue.
> I want to be able to use a target pragma to enable
On 19/05/15 16:21, Kyrill Tkachov wrote:
On 19/05/15 15:55, Christian Bruel wrote:
Hi Kiril,
This is funny, I've updated bz65837 today in the same direction.
On 05/19/2015 04:17 PM, Kyrill Tkachov wrote:
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and
On 19/05/15 15:55, Christian Bruel wrote:
Hi Kiril,
This is funny, I've updated bz65837 today in the same direction.
On 05/19/2015 04:17 PM, Kyrill Tkachov wrote:
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and I'm stuck
on a particular issue.
I
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and I'm stuck
on a particular issue.
I want to be able to use a target pragma to enable SIMD support in a SIMD
intrinsics header file.
So it will look like this:
$ cat simd_header.h
#pragma GCC push_options
#
On 18/05/15 09:25, Kyrill Tkachov wrote:
Hi Christian,
On 18/05/15 07:26, Christian Bruel wrote:
Hi Kyrill,
On 05/13/2015 05:43 PM, Kyrill Tkachov wrote:
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled
Hi Christian,
On 18/05/15 07:26, Christian Bruel wrote:
Hi Kyrill,
On 05/13/2015 05:43 PM, Kyrill Tkachov wrote:
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled with floating point support
the
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled with floating point support
the __ARM_FEATURE_FMA predefine is available. If the user adds to a function
a target attribute disabling floating point, then is
Dear All,
We ported gcc 4.8.1 for custom hardware and we have target specific
attributes like io for variables and interrupt for functuions and many
more.
We are able to fetch the attributes for variables like
look_up(DECL_ATTRIBUTES(node),attr_name)
for typedef variables we are fetching
,
>>>>>
>>>>> 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:
>
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
(INTVAL (operands[3]) & CALL_LONG)
>>>>> operands[1] = rs6000_longcall_ref (operands[1]);
>>>>> In my port I dont have suchthing to compare. Can we somehow parse the
>>>>> tree chain and check the attributes of the functions..
>>>>
>>
direct */
>>>> In the md file they are checking the operand with CALL_LONG
>>>> if (INTVAL (operands[3]) & CALL_LONG)
>>>> operands[1] = rs6000_longcall_ref (operands[1]);
>>>> In my port I dont have suchthing to compare. Can we somehow parse the
>>
] = rs6000_longcall_ref (operands[1]);
>>> In my port I dont have suchthing to compare. Can we somehow parse the
>>> tree chain and check the attributes of the functions..
>>
>> Look at init_cumulative_args in rs6000.c to see how CALL_LONG is set
>> based on the function
LONG 0x0008 /* always call indirect */
>> In the md file they are checking the operand with CALL_LONG
>> if (INTVAL (operands[3]) & CALL_LONG)
>> operands[1] = rs6000_longcall_ref (operands[1]);
>> In my port I dont have suchthing to compare. Can we somehow parse t
INTVAL (operands[3]) & CALL_LONG)
> operands[1] = rs6000_longcall_ref (operands[1]);
> In my port I dont have suchthing to compare. Can we somehow parse the
> tree chain and check the attributes of the functions..
Look at init_cumulative_args in rs6000.c to see how CALL_LONG is set
based on the function attribute.
Ian
question is how to find the attributes of a function which we are
>> going to call
>>
>> Problem:
>>
>>Generally while calling a function we use branch instruction
>>
>>ex: br r5,
>>
>> But when we have a function with "super&quo
On Fri, Oct 11, 2013 at 2:48 AM, Nagaraju Mekala wrote:
>
> My question is how to find the attributes of a function which we are
> going to call
>
> Problem:
>
>Generally while calling a function we use branch instruction
>
>ex: br r5,
>
> But wh
Hi,
I am working on GCC-4.6.4 version ported to a embedded target which
is similar to frv.
My question is how to find the attributes of a function which we are
going to call
Problem:
Generally while calling a function we use branch instruction
ex: br r5,
But when we have a
ult is effectively to place an
arbitrary limit of 1 (the hidden this pointer) on the number of parameters
that can be passed in registers.
If I change __stdcall to __thiscall in the example, I get a clear error
message:
> bar.h:3:57: error: regparam and thiscall attributes are not c
NightStrike gmail.com> writes:
> > ... used to work, with the attribute from the declaration being applied also
> > to the definition.
I stumbled upon this as well recently.
> Someone else just asked not too long ago:
>
> http://gcc.gnu.org/ml/gcc-help/2013-03/msg00012.html
Yes, but there’s n
On Wed, Apr 3, 2013 at 10:44 PM, Dave Korn wrote:
>
> Hi list,
>
> Previously (tested with gcc-4.5.3), constructs like this:-
>
> -- foo.h
>
> struct sigpacket
> {
> int __stdcall process () __attribute__ ((regparm (1)));
> };
>
> -- foo.cpp
>
> #include "foo.h"
>
> int __stdcall
> sigpack
Hi list,
Previously (tested with gcc-4.5.3), constructs like this:-
-- foo.h
struct sigpacket
{
int __stdcall process () __attribute__ ((regparm (1)));
};
-- foo.cpp
#include "foo.h"
int __stdcall
sigpacket::process ()
{
return 2;
}
--
... used to work, wi
On Thu, Feb 28, 2013 at 8:05 PM, Andrew Pinski wrote:
> On Thu, Feb 28, 2013 at 3:54 PM, Jeffrey Walton wrote:
>> Hi All,
>>
>> I'm having trouble compiling sources adorned with the aligned
>> attribute under Clang 3.1. Clang claims its GCC 4.2.1 compatible:
>
> This is not a good list to ask thi
efine __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4
When did GCC add support for function and variable attributes?
Specifically, __attribute__(aligned) for x86/x64? Did the aligned
attribute come into being after GCC 4.2?
That wouldn't be the only place where clang is not perfectly compatible
with gcc.
inski
>
> $ clang -dM -E -x c /dev/null | grep -i gnuc
> #define __GNUC_MINOR__ 2
> #define __GNUC_PATCHLEVEL__ 1
> #define __GNUC_STDC_INLINE__ 1
> #define __GNUC__ 4
>
> When did GCC add support for function and variable attributes?
> Specifically, __attribute__(align
> > 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
On Thu, 29 Sep 2011, Nick Clifton wrote:
> Hi Richard,
>
> > I don't think it's a good idea to have the attributes of
> > every CPU we support in a single file. That's going to
> > get unmaintainable very quickly.
>
> Really - why ?
>
> These
Hi Richard,
I don't think it's a good idea to have the attributes of
every CPU we support in a single file. That's going to
get unmaintainable very quickly.
Really - why ?
These attributes are mostly static. Some new ones might be added from
time to time, but baring the
e would contain enums describing the
> attributes that be can found in SHT_GNU_ATTRIBUTES sections. The
> purpose of the file is to provide a single place where these values
> are defined, and to share the information between GCC, BINUTILS and
> GDB.
>
> The patch
Hi Guys,
All I wanted to do was to make GCC's ARM assembler output slightly
easier to read...
I would like to propose a patch to create a new header file in the
include/ directory. This file would contain enums describing the
attributes that be can found in SHT_GNU_ATTRIBUTES sec
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.
On Tue, Sep 14, 2010 at 4:51 PM, Ian Lance Taylor wrote:
> Please do file a PR if there isn't one already. Thanks.
I have no idea if that could happen outside C++ and couldn't find
anything relevant, thus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45668
That's the best i can do.
And thanks for y
tbp writes:
> Would it be possible to have some clarifications? Shall i file a PR
> for a warning? Sacrifice a goat?
Please do file a PR if there isn't one already. Thanks.
Ian
Hello,
i know it's no good form to reply to self, or be that insistent, but
i've been hit again.
In the bug report discussion, i've been told by A. Pinski that, as of
now, forward declarations shall have matching attributes. That's fine,
i suppose. What's not is that:
.
On Fri, Sep 10, 2010 at 5:20 PM, Ian Lance Taylor wrote:
> Since you do have a test case, you could try using a tool like delta to reduce
> it to something that you can share.
My delta-fu is too weak to get anywhere with an error so easily
produced (mismatched prototype, plus g++ senseless diagnos
On 10 September 2010 17:20, Ian Lance Taylor wrote:
>
> I understand what you are trying to do, but it's very unlikely that
> anybody will be able to solve this problem without a test case. Since
> you do have a test case, you could try using a tool like delta to reduce
> it to something that you
t's no testcase because it works: to kludge around, i have
> to forward declare with matching attributes (or get an error).
> I fail to reduce it, and the source code is large & fugly; i'd prefer
> not to have to disclose, hence no formal bug report.
> My hope being that
foo {
void bar(fwd &);
};
}
class __attribute((aligned(16))) fwd {};
}
// error prototype for... candidate is... would be here.
void n1::n2::foo::bar(n1::fwd &) {}
Except that's no testcase because it works: to kludge around, i have
to forward declare with matchin
I refer you to the various issues I have raised with attributes proposals
in WG14 in the past, some at least of which have also been forwarded to
WG21. The committees have generally chosen not to listen to compatibility
concerns, except insofar as WG14 ended up not adopting general attribute
1 - 100 of 172 matches
Mail list logo
