Re: strcpy and strcat seem to lead to a stack overflow
On Tue, Feb 22, 2022 at 10:01:47PM +0100, Emile Michel Hobo via Gcc wrote: > Dear developers: > > I find it counterintuitive that if I repeatedly reset a variable by using > strcpy with an empty string "" to that variable and then us strcat to add > characters to that variable that that seems to lead to a stack overflow. > > I would expect strcpy to first free the variable, then malloc, then copy the > string value into the variable. I think that would be a better > interpretation, because it can keep running for quite some time before it > overflows and doesn’t really call it. strcpy() doesn't dynamically allocate memory according to docs. And this great. Otherwise we will have a performance impact. It would be terrible. For example, i allocate some buffer once at program initialization and later do many strcpy() with it. This is a frequent scenario. > I ended up reimplementing the reset function, implementing it with free and > malloc myself, but the way strings have been implemented in C is highly > counter-intuitive. In general pointers tend to be bug-prone, but here you > would expect this not to happen. Implementing string manipulation routines for your needs is ok. Strings in C are very intuitive. You work mostly without allocations and docs specify this. This is great and give the best performance where we need it. Where you don't need it - you make string manipulation routines for yourself. -- Олег Неманов (Oleg Nemanov)
Re: strcpy and strcat seem to lead to a stack overflow
On Tue, 22 Feb 2022 at 21:02, Emile Michel Hobo wrote: > I hope you can fix this. There is nothing to fix, strcpy and strcat work exactly as required by the C standard, and that isn't going to change. In any case, it's off-topic on this mailing list because those functions are defined in the C standard and provided by the C library on your OS, not by GCC. This list is for discussing the development of GCC itself. > Personally, I’m looking into switching to Ada. GCC has a very capable Ada compiler, so maybe you will be happy using that instead of C.
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Jan 27, 2022)
Hi all, There is an agenda for tomorrow's meeting. If you have topics to discuss or share, please let me know and I can add them to the agenda. Agenda: - Intrinsics common availability and naming rules discuss - RISC-V subextension related implement progress - Scalar Crypto extension supports status - Zmmul extension supports status - Zc*[1] extension supports status - CMO extension supports on gcc part - Open topics Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Join Zoom Meeting https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 11:00pThu, Feb 24 2022 12:00aFri, Feb 24 2022 PST/PDT, Pacific Standard Time (US) 7:00aThu, Feb 24 2022 8:00aThu, Feb 24 2022 PHILADELPHIA, United States, Pennsylvania 10:00aThu, Feb 24 2022 11:00aThu, Feb 24 2022
qual_union_type help
Hi everyone
I am seeking some help on using the QUAL_UNION_TYPE it seems ideally
placed to be used for enums in Rust. My initial implementation was
achieved by simply using a union such as:
union my_enum {
variant_a { enum discriminant; ...data } ;
variant_b { enum discriminant; ...data} ;
}
Having each variant contain an enum for the discriminant meant that
dataless handling variants were quite simple. Upon trying to use the
QUAL_UNION_TYPE this all seems reasonably trivial but I can't figure
out what to set the DECL_QUALIFIER to be, initially from reading the
documentation on https://gcc.gnu.org/onlinedocs/gccint/Types.html it
seemed that it wants a slightly different layout by using a
placeholder_expr to reference an outer discriminant field such that
the layout becomes:
struct my_enum {
enum discriminant;
union variants {
variant_a { data };
variant_b { data };
}
}
So I have been creating my DECL_QUALIFIER as follows:
```
tree field_offset = NULL_TREE;
tree place_holder = build0 (PLACEHOLDER_EXPR, sizetype);
tree place_holder_expr
= build3 (COMPONENT_REF, TREE_TYPE (qual_field),
place_holder, qual_field, field_offset);
DECL_QUALIFIER (field)
= build2 (EQ_EXPR, boolean_type_node,
place_holder_expr, discrim);
```
So this seems to generate some interesting code and then finally hit
an ICE inside:
Breakpoint 5, gimplify_expr (expr_p=0x76ff1f48,
pre_p=0x7fffd2d8, post_p=0x7fffbb58, gimple_test_f=0x15aa98f
, fallback=3) at
../../gccrs/gcc/gimplify.cc:15755
15755 gcc_unreachable ();
(gdb) call debug_tree(*expr_p)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7700a000 precision:64 min max >
>
This makes sense this we can't gimplify a placeholder expression. So
this seems that when i make a constructor for the QUAL_UNION_TYPE i
must iterate the fields and replace the placeholder_expr to have a
reference to the discriminant via another COMPONENT_REF. Though does
this mean for the constructor i will need to create a temporary to
hold onto it to create another component_ref?
Or am I doing this completely wrong? I haven't had much success in
following the QUAL_UNION_TYPE code in the Ada front-end, but any
pointers would be greatly appreciated.
Thanks.
--Phil
Re: Benchmark recommendations needed
On 2022-02-22 16:59, Patrick McGehearty wrote: I studied Dhrystone about 30 years ago and found it had a number of flaws back then. For example, most of the loops in the code are only executed 1-3 times, which minimizes the value of hoisting values out of inner loops. Read the Dhrystone wikipedia article for more information. Going back to what benchmarks might be useful... you might consider the Livermore Loops http://www.netlib.org/benchmark/livermorec These are 24 kernels (tight loops) originally in Fortran but ported to C 30 years ago. They are reasonably representative of floating point computational kernels. They are available without a fee. Even if you have no interest in floating point computation for your target architecture, examining the assembly output of these kernels will be helpful in finding where your port of gcc is doing well and where the machine architecture input to the various optimizer phases need some tuning. You also might review that code and write some modest test loops of your own for integer code patterns. Developing good benchmarks is a skill which requires the developer to know the intended purpose of the benchmark. I.e. is our goal to compare optimizer implementations? or different architectures (i.e. arm vs x86)? or different implementations of an architecture (i.e. intel vs amd or early x86 vs current x86) or ... well, you get the idea. Good luck, - Patrick McGehearty On 2/22/2022 3:49 PM, Paul Koning via Gcc wrote: On Feb 22, 2022, at 4:26 PM, Gary Oblock via Gcc wrote: Andras, The whole point of benchmarks is to judge a processor's performance. That being said, just crippling GCC is not reasonable because processors must be judged in the appropriate context and that includes the current state of the art compiler technology. If you have a new processor I'd benchmark it using the applications you built it for. Exactly. Part of what you want to see is that GCC optimizes well for the new machine, i.e., that there aren't artifacts of the machine description that get in the way of optimization. So you'd want to use applications that are good exercises not just of the code generator but also the optimizer. Dhrystone isn't really that, because it has evolved into mostly an optimizer test, not a machine or code generator test. paul Thank you for all the feedback. When I said 'crippling' GCC, I didn't mean to make it generally worse, just to make sure I don't trigger dhrystone-specific optimizations, if there are any. Your point about comparing processors is a fair one and that's where I'm heading, but I need to start small. Even just comparing object file (.text section) size between architectures have been hugely enlightening. There is another point though: my port of GCC is certainly not state of the art (well, it technically is, because that's the only port in existence, but you get what I mean). Part of the process is to hone in the port in terms of tuning the instruction selection, peepholes, etc. In some sense this work benchmarks compilers not processors. At any rate, I do get that dhrystone is a poor substitute for a real benchmark and I'll try to move away from it. I wasn't aware of Livermore loops being ported to C (and I don't yet have a Fortran port), so that's a great suggestion. I'll check it out. Thanks again for all the help, Andras
Re: qual_union_type help
> This makes sense this we can't gimplify a placeholder expression. So > this seems that when i make a constructor for the QUAL_UNION_TYPE i > must iterate the fields and replace the placeholder_expr to have a > reference to the discriminant via another COMPONENT_REF. Though does > this mean for the constructor i will need to create a temporary to > hold onto it to create another component_ref? The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you know the value of the discriminant since it is assigned in the CONSTRUCTOR, so the gimplifier is indeed presumably not wired to eliminate them on its own. -- Eric Botcazou
Re: qual_union_type help
Hi Eric, That makes sense during construction we also know what the value of the discriminant is. What does the Ada front-end replace the placeholder_exprs with? Can it simply be the value of the discriminant at constructor? I haven't tried that. Thanks --Phil On Wed, 23 Feb 2022 at 17:33, Eric Botcazou wrote: > > > This makes sense this we can't gimplify a placeholder expression. So > > this seems that when i make a constructor for the QUAL_UNION_TYPE i > > must iterate the fields and replace the placeholder_expr to have a > > reference to the discriminant via another COMPONENT_REF. Though does > > this mean for the constructor i will need to create a temporary to > > hold onto it to create another component_ref? > > The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the > subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you > know the value of the discriminant since it is assigned in the CONSTRUCTOR, so > the gimplifier is indeed presumably not wired to eliminate them on its own. > > -- > Eric Botcazou > >
Nagios
Hi, Would you be interested in acquiring a list of companies that are currently using Nagios? We can also provide you with competitor's customers such as: Dynatrace, checkmk, Zabbix, Datadog, Microsoft System Center, AppDynamics, LogicMonitor, LogRocket and Splunk. Once you confirm the target criteria I will get back to you with counts and pricing. Regards, Melissa Anderson Sales Consultant Lead Gen Marketing LLC If you do not wish to receive these emails. Please respond Exit.
Re: qual_union_type help
> That makes sense during construction we also know what the value of > the discriminant is. What does the Ada front-end replace the > placeholder_exprs with? Can it simply be the value of the discriminant > at constructor? I haven't tried that. Ultimately all PLACEHOLDER_EXPRs need to be replaced by something in the code, i.e. they can only survive in (abstract) types. There is an entire machinery in tree.c for that, called both from the front-end and middle-end in Ada. You can replace it with an explicit value (SUBSTITUTE_IN_EXPR) or you can search for it in an object (SUBSTITUTE_PLACEHOLDER_IN_EXPR). You can presumably do it through the gimplification hook. -- Eric Botcazou
