[Bug c/111307] New: RFE: builtin to construct va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111307
Bug ID: 111307
Summary: RFE: builtin to construct va_list
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: equinox-gccbugs at diac24 dot net
Target Milestone: ---
A common pattern of defining a pair of varargs functions looks like:
void somefuncv(char *spec, va_list ap)
{
/* ... */
}
void somefunc(char *spec, ...)
{
va_list ap
va_start(ap, spec);
sumefuncv(spec, ap);
va_end(ap);
}
somefunc("%d", 1234); /* => quite a bit of wasted moving bits around */
However, the resulting code for calling somefunc() is suboptimal; the arguments
are arranged as specified by the psABI, only to then be rearranged into a
va_list by somefunc (which can be rather complex since somefunc has no clue
about type, number, or even floating-point calling conventions of its
arguments.)
It would be very helpful if GCC added a builtin function to create a va_list
for a given "...", with a (pseudo-)prototype like "__builtin_va_list
__builtin_va_construct(...)". This could be used to directly put together a
va_list at the caller's location, e.g.:
#define somefunc(spec, ...) somefuncv(spec,
__builtin_va_construct(__VA_ARGS__))
somefunc("%d", 1234); /* => minimal va_list to carry a single int */
Thus the round-trip through the psABI could be avoided, with the caller
constructing a minimal (since it knows all the args) va_list.
(This builtin would also make inlining varargs functions much less relevant,
since there are no more actual varargs functions in the latter example...)
[Bug c/57612] add builtin to assert that expression does not have side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 David L. changed: What|Removed |Added CC||equinox-gccbugs at diac24 dot net --- Comment #5 from David L. --- I would like to "third" this request. In my head I was thinking of a "__builtin_warn_side_effects(x[, "extra warning text"])" that returns the value of x, but if the parameter does not actually get evaluated a "__builtin_pure_p(x)" test returning 0/1 works too I guess.
[Bug c/99526] New: Casts should retain typedef information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99526 Bug ID: 99526 Summary: Casts should retain typedef information Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: equinox-gccbugs at diac24 dot net Target Milestone: --- Currently, any cast in C will produce the "resolved" type regardless of whether the cast is written using a typedef. E.g.: typedef int i; typedef const int cint; typedef const i ci; char v; typeof((i)v)=> int; typeof((cint)v) => int; typeof((ci)v) => int; typeof((const i)v) => int; The IMHO ideal situation would be: typedef int i; typedef const int cint; typedef const i ci; char v; typeof((i)v)=> i; typeof((cint)v) => int; typeof((ci)v) => i; typeof((const i)v) => i; Note that since casts produce rvalues, qualifiers need to be stripped, and thus "ci" and "cint" shouldn't be used since the typedef itself contains a qualifier. My rationale for this is twofold: - systems (on POSIX: pid_t, uid_t, gid_t, ...) have some types that are of "unspecified" size, and it is helpful to be able to warn when these are intermixed. Especially in printf() due to varargs calling: there is no format specifier that is correct for these types. - plugins may want to attach additional semantics to some typedefs, and this breaks if the plugin can't get at the typedef.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 David L. changed: What|Removed |Added CC||equinox-gccbugs at diac24 dot net --- Comment #8 from David L. --- Issue persists in gcc 10.2, test program from comment #6 still errors out. We're hitting this bug in production/real-world code [ https://github.com/FRRouting/frr/pull/6766 ]. What we're doing is very similar to SystemTap's trace points, I believe those might be affected as well. clang++ works fine meanwhile.
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #6 from David L. --- Created attachment 37808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37808=edit patch (gcc-5.3.0) patch attached (probably makes the user's PC explode and burns down their house) varpool_node::finalize_decl (tree decl) -node->force_output = true; +node->force_output = !TREE_READONLY (decl) || flag_keep_static_consts;
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #5 from David L. --- (In reply to David L. from comment #4) > Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the > check for >else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) >&& (optimize || !flag_keep_static_consts >|| DECL_ARTIFICIAL (decl))) > is never hit because the earlier > else if (node && node->definition) > > needed = false; > is taken (on both -O0 or -O1). > > Thus, the value of flag_keep_static_consts is irrelevant (and this is the > only place in the code where it's used...) If I put a "static const int intvalnoinit;" into my test source, -fno-keep-static-consts does actually have an effect on that. It seems a little counterintuitive to me though that static consts only get removed if they have no initialiser...
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #3 from David L. --- Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the check for else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) && (optimize || !flag_keep_static_consts » » || DECL_ARTIFICIAL (decl)))
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #4 from David L. --- Argh, for some reason this submitted in the middle of editing... Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the check for else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl) && (optimize || !flag_keep_static_consts || DECL_ARTIFICIAL (decl))) is never hit because the earlier else if (node && node->definition) needed = false; is taken (on both -O0 or -O1). Thus, the value of flag_keep_static_consts is irrelevant (and this is the only place in the code where it's used...)
[Bug c/69981] -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 --- Comment #2 from David L. --- (In reply to Jakub Jelinek from comment #1) > I disagree, removing static consts is an optimization, if you tell the > compiler not to optimize, it doesn't perform the optimizations. Documentation bug then? It says it's independent of optimization. -fkeep-static-consts Emit variables declared static const when optimization isn't turned on, even if the variables aren't referenced. GCC enables this option by default. If you want to force the compiler to check if a variable is referenced, regardless of whether or not optimization is turned on, use the -fno-keep-static-consts option.
[Bug c/69981] New: -f[no]keep-static-consts has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69981 Bug ID: 69981 Summary: -f[no]keep-static-consts has no effect Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: equinox-gccbugs at diac24 dot net Target Milestone: --- This bug is an extension of #20319; the -fkeep-static-consts option seems to have no effect in either direction. (#20319 was focused on the "-fkeep" variant; my issue is with -O0 -fno-keep-static-consts.) My application code is extern struct foo ref; static struct foo * const myconst = Where ref is defined in a library that is not always linked in, which works on -O1 -Og -Os -O2 -O3 but not on "-O0 -fno-keep-static-consts". I think it should. Trying older versions, gcc-4.2.4 already behaves the same. $ ./test.sh gcc-4.9.3 -O0 l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O0 -fkeep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O0 -fno-keep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-4.9.3 -O1 gcc-4.9.3 -O1 -fkeep-static-consts gcc-4.9.3 -O1 -fno-keep-static-consts gcc-5.3.0 -O0 l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O0 -fkeep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O0 -fno-keep-static-consts l O .rodata0004 intval l O .data.rel.ro 0008 ptrval gcc-5.3.0 -O1 gcc-5.3.0 -O1 -fkeep-static-consts gcc-5.3.0 -O1 -fno-keep-static-consts $ cat test.sh #!/bin/sh cat >const.c <
[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808 --- Comment #2 from David L. equinox-gccbugs at diac24 dot net --- (In reply to Marek Polacek from comment #1) I don't think it is a bug. If you use -pedantic, it doesn't matter whether -std=c11 or -std=gnu11 (the default) is in effect. If you want to suppress the warning, use __extension__ as you did in the test(). Hm. It doesn't seem to produce a warning for the system's/glibc's wait() definition, even though there is no __extension__ on that. I guess that's special-handling for system headers(?) (Either way our target language is C with gcc/clang/icc common extensions, so I guess -pedantic is not appropriate...)
[Bug c/65808] New: -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808
Bug ID: 65808
Summary: -pedantic -std=gnu11 results in warning for
transparent_union usage
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: equinox-gccbugs at diac24 dot net
Created attachment 35359
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35359action=edit
test program, compile with -std=gnu11 -pedantic
Trying to use a transparent_union results in a warning when -pedantic is used,
even though -std=gnu11 is specified.
Test program is this:
(gcc -std=gnu11 -pedantic -c /tmp/uniontest.c)
struct a { int a; };
struct b { int b; };
__extension__ union ab {
struct a *pa;
struct b *pb;
} __attribute__ ((transparent_union));
extern void func1 (union ab arg);
__extension__ extern void func2 (union ab arg);
void test(void)
{
struct a sa = { 1 };
func1(sa); /* warning */
__extension__ func1(sa); /* no warning */
func2(sa); /* warning */
}
Expected behaviour: no warning at all, or some way to put __extension__ on the
union or the function prototype.
Actual behaviour: __extension__ must be used on each and every individual
function call, or a warning occurs:
/tmp/uniontest.c: In function ‘test’:
/tmp/uniontest.c:15:2: warning: ISO C prohibits argument conversion to union
type [-Wpedantic]
func1(sa); /* warning */
^
/tmp/uniontest.c:17:2: warning: ISO C prohibits argument conversion to union
type [-Wpedantic]
func2(sa); /* warning */
^
