gcc __attribute__
Hi *GCC*:
On page:
https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html
you show the attribute coming after the parameter list. But when I try
this, I get the following:
#include
void __attribute__ ((noreturn)) aaa() // OK
{exit(0);
}
void bbb() __attribute__ ((noreturn)) // *error*: attributes should be
specified before the declarator in a function definition
{exit(0);
}
--
Thanks,
Phil
Philip R Brenan
Re: gcc __attribute__
On Thu, Aug 06, 2020 at 04:15:10PM +0100, Philip R Brenan via Gcc wrote: > Hi *GCC*: > > On page: > > https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html > > you show the attribute coming after the parameter list. But when I try > this, I get the following: That manual is for version 3.2, which is ancient. See https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Attribute-Syntax.html#Attribute-Syntax Marek
Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)
On 8/3/20 10:58 PM, Paul Smith wrote:
On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote:
If the code is designed to treat Node sort of like a struct with
a flexible array member I would suggest to make that explicit by
adding a zero-element array member to Node and using it to access
other memory. E.g., add:
unsigned char data[0];
as the last member of Node and change getPayload to:
PAYLOAD& getPayload() {
return *(reinterpret_cast(data) +
Node::actualSize(_keyLength, alignof(PAYLOAD)));
}
Thanks Martin; I suspected it was something like that. However, I
haven't been able to get a workaround to work.
My understanding is that you suggest replacing:
struct {} key;
with:
unsigned char key[0];
Yes (I said add but replacing it is what you would probably want
but see below).
in Node. And I think you have a paren in the wrong place in the
getPayLoad() example above; shouldn't it be:
return *(reinterpret_cast(data +
Node::actualSize(_keyLength, alignof(PAYLOAD;
(that is, the size should be added to data then the whole thing cast).
However, even trying this I still get the same failures:
stringop.cpp: In function 'void applyTo(LeafNode*)':
stringop.cpp:37:33: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
37 | void markUpdate() { flags() |= UPDATE; }
| ^
stringop.cpp:15:19: note: at offset 0 to object 'Node::key' with size 0
declared here
15 | unsigned char key[0];
| ^~~
cc1plus: all warnings being treated as errors
Were you able to get this working and I just am not understanding what
you mean?
The suggested change avoids the warning with trunk but not with
GCC 10. I suspect the warning in this case has been removed in
the bug fix for pr95353.
But looking more carefully at the test case, I would actually
expect the warning even with the zero-length array because when
it's in a base class it's not considered the same as a flexible
array member.
In general, it's not safe to access a trailing member of a struct
(or class) outside its bounds in an object of which is a member
of another class because when the latter is followed by another
member, accesses to the two alias one another. GCC assumes that
doesn't happen.
In other words, what the code in the test case does is not safe
and I would recommend to find a different way (e.g. avoid deriving
from Node).
Martin
Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)
On 8/6/20 2:14 PM, Martin Sebor wrote:
On 8/3/20 10:58 PM, Paul Smith wrote:
On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote:
If the code is designed to treat Node sort of like a struct with
a flexible array member I would suggest to make that explicit by
adding a zero-element array member to Node and using it to access
other memory. E.g., add:
unsigned char data[0];
as the last member of Node and change getPayload to:
PAYLOAD& getPayload() {
return *(reinterpret_cast(data) +
Node::actualSize(_keyLength, alignof(PAYLOAD)));
}
Thanks Martin; I suspected it was something like that. However, I
haven't been able to get a workaround to work.
My understanding is that you suggest replacing:
struct {} key;
with:
unsigned char key[0];
Yes (I said add but replacing it is what you would probably want
but see below).
in Node. And I think you have a paren in the wrong place in the
getPayLoad() example above; shouldn't it be:
return *(reinterpret_cast(data +
Node::actualSize(_keyLength, alignof(PAYLOAD;
(that is, the size should be added to data then the whole thing cast).
However, even trying this I still get the same failures:
stringop.cpp: In function 'void applyTo(LeafNode*)':
stringop.cpp:37:33: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
37 | void markUpdate() { flags() |= UPDATE; }
| ^
stringop.cpp:15:19: note: at offset 0 to object 'Node::key' with
size 0 declared here
15 | unsigned char key[0];
| ^~~
cc1plus: all warnings being treated as errors
Were you able to get this working and I just am not understanding what
you mean?
The suggested change avoids the warning with trunk but not with
GCC 10. I suspect the warning in this case has been removed in
the bug fix for pr95353.
But looking more carefully at the test case, I would actually
expect the warning even with the zero-length array because when
it's in a base class it's not considered the same as a flexible
array member.
In general, it's not safe to access a trailing member of a struct
(or class) outside its bounds in an object of which is a member
of another class because when the latter is followed by another
member, accesses to the two alias one another. GCC assumes that
doesn't happen.
In other words, what the code in the test case does is not safe
and I would recommend to find a different way (e.g. avoid deriving
from Node).
One way to avoid the warning without losing the derivation is to
use the derived pointer (i.e., the this pointer in flags) instead
of the base this pointer in getPayload. That way the access as
seen in the IL is not to the base subobject but the derived
object. Instead of this
[local count: 1073741824]:
_4 = &node_2(D)->D.2382; <<< pointer to subobject
...
_11 = _4 + _10;
_12 = MEM[(unsigned char &)_11 + 8];
_13 = _12 | 4;
MEM[(unsigned char &)_11 + 8] = _13;
the IL might look like this:
_10 = node_2(D) + _9; <<< pointer to derived object
_11 = MEM[(unsigned char &)_10 + 8];
_12 = _11 | 4;
MEM[(unsigned char &)_10 + 8] = _12;
return;
and the warning has nothing to complain about.
Martin
gcc-8-20200806 is now available
Snapshot gcc-8-20200806 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200806/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 8b692f8b4c0e47bc8e11d9c3ab83049f68b2edbc You'll find: gcc-8-20200806.tar.xzComplete GCC SHA256=722df911e0d0f56309f2006103927de5b7653d2dfd50f08c1b40a5802bd2af33 SHA1=12988dd5f5913ee1c7590d7dfeba76f94d34a99f Diffs from 8-20200730 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
A problem with DECL_FIELD_OFFSET in something I declared
This problem is from my structure reorganization optimization
optimization code (simplified and cleaned to illustrate
the problem.
Here's what happening below at the high level
>From the user program:
typedef struct type type_t;
struct type {
double x;
double y;
}:
I'll be creating:
typedef struct type_prime type_prime_t;
struct type_prime {
double x *;
double y *;
};
and
type_prime_t base_for_type_prime;
Later, when running partial redundancy elimination,
PRE attempts to access the DECL_FIELD_OFFSET of field
x and finds that the the DECL_FIELD_OFFSET is NULL.
Note, I suppose I could run gdb to track down in the storage
layout code what caused it to bypass place_field (where the
offset probably should be initialized) but I'd still not know
what I'm doing wrong below.
Please, somebody have a look and let me know.
Thanks,
Gary Oblock
// An alternate method of creating a record type
// I tried both ways
#define LANG_HOOKS 1
static void
create_a_new_type_and_base_var ( Info_t *info, tree type)
{
// For the sake of this code "ri" is just a place with
// interesting stuff about "type"
ReorgType_t *ri = get_reorgtype_info ( type, info);
if ( ri != NULL ) {
#if FROM_HOOKS
tree reorg_type_prime =
lang_hooks.types.make_type (RECORD_TYPE);
#else
tree reorg_type_prime =
build_variant_type_copy ( type MEM_STAT_DECL);
#endif
ri->reorg_ver_type = reorg_type_prime;
// Code to create name of reorg_type_prime ... irrelevant
// :
TYPE_NAME ( reorg_type_prime) = get_identifier ( rec_name);
// Build the new pointer type fields
tree field;
tree new_fields = NULL;
for (
#if LANG_HOOKS
field = TYPE_FIELDS ( type);
#else
field = TYPE_FIELDS ( reorg_type_prime);
#endif
field;
field = DECL_CHAIN ( field))
{
tree tree_type = TREE_TYPE ( field);
tree new_fld_type = build_pointer_type ( tree_type);
// I use the same name as the field of type
tree new_decl =
build_decl ( DECL_SOURCE_LOCATION (field),
FIELD_DECL, DECL_NAME (field), new_fld_type);
DECL_CONTEXT ( new_decl) = reorg_type_prime;
layout_decl ( new_decl, 0);
// I might be missing a bunch of attributes (see tree-nested.c:899)
DECL_CHAIN ( new_decl) = new_fields;
new_fields = new_decl;
}
// store reversed fields into reorg_type_prime (having them in the same
// order in as in type makes sense.)
TYPE_FIELDS ( reorg_type_prime) = NULL;
tree next_fld;
for ( field = new_fields; field; field = next_fld)
{
next_fld = DECL_CHAIN ( field);
DECL_CHAIN ( field) = TYPE_FIELDS ( reorg_type_prime);
TYPE_FIELDS ( reorg_type_prime) = field;
}
// Fix-up the layout
layout_type ( reorg_type_prime);
// Create the base element for the transformed type.
tree base_var =
build_decl ( UNKNOWN_LOCATION, VAR_DECL, NULL_TREE, reorg_type_prime);
// More name creation code here... irrelevant
//:
DECL_NAME ( base_var) = get_identifier ( base_name);
// Some attributes I really don't understand...
TREE_STATIC ( base_var) = 1;
TREE_ADDRESSABLE ( base_var) = 1;
DECL_NONALIASED ( base_var) = 1;
SET_DECL_ALIGN ( base_var, TYPE_ALIGN ( ri->reorg_ver_type));
// Is this necessary guys???
varpool_node::finalize_decl ( base_var);
relayout_decl ( base_var);
ri->base = base_var;
}
}
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and contains information that is
confidential and proprietary to Ampere Computing or its subsidiaries. It is to
be used solely for the purpose of furthering the parties' business
relationship. Any review, copying, or distribution of this email (or any
attachments thereto) is strictly prohibited. If you are not the intended
recipient, please contact the sender immediately and permanently delete the
original and any copies of this email and any attachments thereto.
Define __attribute__((no_instrument_function)) but still got instrumented
Hello! I am working on a ARM GCC plugin which instruments each GIMPLE function with some new function calls. Currently I want to skip certain functions by adding the no_instrument_function attribute. However, I do see that in the disassembled code, all functions are still instrumented. Am I missed anything here? From this page ( https://www.keil.com/support/man/docs/armcc/armcc_chr1359124976163.htm), I do see that no_instrument_function is used to skip --gnu_instrument, but might not be applicable to my case where I use the following command to compile: arm-none-eabi-g++ -fplugin=my_plugin.so -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-move-loop-invariants -Wall -Wextra -g3 -DDEBUG -DUSE_FULL_ASSERT -DOS_USE_SEMIHOSTING -DTRACE -DOS_USE_TRACE_SEMIH OSTING_DEBUG -DSTM32F429xx -DUSE_HAL_DRIVER -DHSE_VALUE=800 -DLOS_KERNEL_DEBUG_OUT But overall, could anyone shed some lights on: 1) how to skip instrument certain functions with GCC plugin? 2: is it possible to check the function attribute in GIMPLE code? If so, I can simply check if certain functions are marked as "no_instrument_function" and skip by myself. Thank you! Shuai
Re: Define __attribute__((no_instrument_function)) but still got instrumented
On Fri, Aug 7, 2020 at 8:35 AM Shuai Wang via Gcc wrote:
>
> Hello!
>
> I am working on a ARM GCC plugin which instruments each GIMPLE function
> with some new function calls.
>
> Currently I want to skip certain functions by adding the
> no_instrument_function attribute. However, I do see that in the
> disassembled code, all functions are still instrumented.
>
> Am I missed anything here? From this page (
> https://www.keil.com/support/man/docs/armcc/armcc_chr1359124976163.htm), I
> do see that no_instrument_function is used to skip --gnu_instrument, but
> might not be applicable to my case where I use the following command to
> compile:
>
> arm-none-eabi-g++ -fplugin=my_plugin.so -mcpu=cortex-m4 -mthumb
> -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections
> -fdata-sections -fno-move-loop-invariants -Wall -Wextra -g3 -DDEBUG
> -DUSE_FULL_ASSERT -DOS_USE_SEMIHOSTING -DTRACE -DOS_USE_TRACE_SEMIH
> OSTING_DEBUG -DSTM32F429xx -DUSE_HAL_DRIVER -DHSE_VALUE=800
> -DLOS_KERNEL_DEBUG_OUT
>
> But overall, could anyone shed some lights on: 1) how to skip instrument
> certain functions with GCC plugin? 2: is it possible to check the function
> attribute in GIMPLE code? If so, I can simply check if certain functions
> are marked as "no_instrument_function" and skip by myself.
You can check lookup_attribute("no_instrument_function",
DECL_ATTRIBUTES (cfun->decl))
> Thank you!
> Shuai
