😎☀️ Теперь на чилле, на расслабоне
Встречаем лето в KOOK ЗАБРОНИРОВАТЬ СТОЛИК Вы получили это письмо, потому что подписались на рассылку от LB Group. Чтобы отписаться, перейдите по ссылке.
GCC trouble in dump_printf_loc
Hi Guys, I got some issues in debugging GCC. I want to use dump_printf_loc to dump some debug message in GCC. I find the fopt-info-all option which can enable some dump_printf_loc calls. But some dump_printf_loc can't be enable by fopt-opt-all option. Because the m_scope_depth variable in class dump_context. Are there any options can enable this dump_printf_loc which is disabled by m_scope_depth. I want to enable dump_printf_loc in vect_pattern_recog_1. Thanks Sent using https://www.zoho.com/mail/
Re: GCC trouble in dump_printf_loc
On Mon, Jun 3, 2024 at 2:54 AM weizhe wang via Gcc wrote: > > Hi Guys, > > > > I got some issues in debugging GCC. > > I want to use dump_printf_loc to dump some debug message in GCC. I find > the fopt-info-all option which can enable some dump_printf_loc calls. > > But some dump_printf_loc can't be enable by fopt-opt-all option. Because > the m_scope_depth variable in class dump_context. > > Are there any options can enable this dump_printf_loc which is disabled > by m_scope_depth. > > I want to enable dump_printf_loc in vect_pattern_recog_1. `-fopt-info-all-internals` as documented https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Developer-Options.html#index-fopt-info Note you can find the same information in the vect dump file if you dump if via -fdump-tree-vect-details too. Thanks, Andrew Pinski > > > > Thanks > Sent using https://www.zoho.com/mail/
Attribute with identifiers arguments
hi.
I'm trying to develop a gcc plugin which will support a new attribute.
I want my new attribute to receive as an argument, an identifier. it
should looks like that:
__attribute__ ((attribute_name(identifier_name_as_arg)))
I know that the gcc attribute "access" can get such an argument but I
didn't manage to do it for my own attribute.
Any idea how I could do it?
I'm attaching an example of my code and its output. if you replace my
attribute name with "access" (in test.c) it will work without error:
//plugin.cc:
#include "gcc-plugin.h"
#include "plugin-version.h"
#include
#include
int plugin_is_GPL_compatible;
static tree
coustom_attribute_handler(tree *node, tree name, tree args,
int flags, bool *no_add_attrs){
std::cout << "my custom attribute plugin executed!" << std::endl;
return NULL_TREE;
}
static struct attribute_spec my_attr =
{"custom", 1, 3, false, true, true, false, coustom_attribute_handler, NULL };
static void
register_attributes(void *event_data, void *data){
register_attribute(&my_attr);
}
int plugin_init(struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version){
if (!plugin_default_version_check(version, &gcc_version)){
return 1;
}
register_callback(plugin_info->base_name, PLUGIN_ATTRIBUTES,
register_attributes, NULL);
return 0;
}
//test.c:
__attribute__ ((custom(write_only, 1)))
void foo(char *);
int main(void){
return 0;
}
Execution:
GCC_PLUGINS=`gcc -print-file-name=plugin`
g++ -I$GCC_PLUGINS/include -fPIC -shared -fno-rtti -O2 plugin.cc -o plugin.so
sudo cp plugin.so $GCC_PLUGINS/plugin.so
gcc test.c -fplugin=plugin -o test.o
output:
test.c:3:24: error: ‘write_only’ undeclared here (not in a function)
3 | __attribute__ ((custom(write_only, 1)))
|^~
my custom attribute plugin executed!
Thanks, didi.
Epiphany target
Hi, Letting the community know that we are working on getting the Epiphany port back to a proper operational state. There will be a GCC maintainer assigned soon. New Epiphany silicon is in development and old Epiphany devices are still in circulation. Best regards, Andreas Olofsson
Re: Epiphany target
On 6/3/24 8:12 AM, Andreas Olofsson via Gcc wrote: Hi, Letting the community know that we are working on getting the Epiphany port back to a proper operational state. There will be a GCC maintainer assigned soon. New Epiphany silicon is in development and old Epiphany devices are still in circulation. Good to hear. You may be better off first switching to LRA (all non-LRA ports are to be deprecated this release IIRC). I suspect that will be a better use of time than first fixing epiphany to work with the deprecated reload infrastructure, then switching it to LRA. In addition to the LRA conversion, getting a degree of stability in the testsuite would be a huge step forward. jeff
Partial vector
Hi all, Is there some sort of guarantee that the unused part of a partial vector has all bits set to zero? The question came up while implementing an insn for mode V2SF on s390 where only half of the hard register would be utilized. The final machine instruction, however, would make use of the full register (V4SF). Therefore, if the other half is not guaranteed to be zero, then a floating-point exception might occur in this particular case. Of course, if such a guarantee exists, then one would have to maintain that for all insn implementations. This all sounds a bit fragile and probably better solved by having some sort of masking support by the hardware but I'm still keen to know. Cheers, Stefan
