[Bug c/115027] Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/656024.html
[Bug c/115515] New: constexpr ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115515
Bug ID: 115515
Summary: constexpr ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
Here is an ICE with constexpr.
https://godbolt.org/z/8EdTW84n4
const struct { float x; } i = { 3.1 };
constexpr int j = i.x;
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 --- Comment #5 from Martin Uecker --- If we do want to constrain the type, we should make them incompatible at the language level. Aliasing is secondary. From a safety perspective, it is always safer to allow aliasing, because the optimizer breaks code that assumes otherwise but not vice versa.
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652669.html
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 Martin Uecker changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115157 --- Comment #2 from Martin Uecker --- They are internally implemented as enums, so the issue is basically the same as PR115157. The types can alias via the langhook but TYPE_CANONICAL is different and so derived types can not alias. It needs to be fixed somewhere else though.
[Bug tree-optimization/115177] New: incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
Bug ID: 115177
Summary: incorrect TBAA for derived types involving hardbool
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
This is another example where type compatibility in the C FE disagrees with
TBAA. Not sure whether those types should be made incompatible instead.
https://godbolt.org/z/e6nYzWMzx
typedef int A;
typedef int __attribute__ (( hardbool(0, 1) )) B;
_Static_assert(_Generic((A*){ 0 }, B*: 1), "");
void* foo(void* a, void *b, A *c, B *d)
{
*(A**)a = c;
*(B**)b = d;
return *(A**)a;
}
int main()
{
A *a, b, c;
if ( != (A*)foo(, , , ))
__builtin_abort();
}
[Bug tree-optimization/115157] New: incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157
Bug ID: 115157
Summary: incorrect TBAA for derived types involving enum types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
Another example where TBAA does not seem to work correctly similar to PR114959.
I guess here it should be easier to set TYPE_CANONICAL correctly in the FE, but
we have the same completion issues we also have in C23 with other tagged types.
https://godbolt.org/z/qcWxn9f6z
enum E { E1 = -1, E2 = 0, E3 = 1 };
typedef int A;
typedef enum E B;
_Static_assert(_Generic((A){ 0 }, B: 1), "");
void* foo(void* a, void *b, A *c, B *d)
{
*(A**)a = c;
*(B**)b = d;
return *(A**)a;
}
int main()
{
A *a, b, c;
if ( != (A*)foo(, , , ))
__builtin_abort();
}
[Bug c/114831] typeof doesn't evaluate expression when it has variably modified type in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652089.html
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 --- Comment #2 from Martin Uecker --- The GCC FE has all the necessary logic to compute type compatibility and this could easily be adapted to compute equivalence classes and then set a TYPE_CANONICAL. All function types in the same class would get the same TYPE_CANONICAL even if a little bit different, i.e. return pointers to compatible but slightly different array types. I think function arguments we need to ignore completely, because T (*f)(); is compatible with all pointers to functions with the same return type. (this is gone in C23 though) Or we special case such functions. What is unclear to me whether function types are the only remaining issue or whether this should then be done for all types (pointers, arrays, etc)?
[Bug tree-optimization/114959] New: incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959
Bug ID: 114959
Summary: incorrect TBAA for drived types involving function
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
The example below shows that aliasing analysis treats some derived types as
incompatible even though they are derived from compatible types char (*)[1] and
char (*)[] and should then be compatible themselves.
The effect type rules are defined in "6.5 Expressions" and allows accesses with
— a type compatible with the effective type of the object,
— a qualified version of a type compatible with the effective type of the
object,
— a type that is the signed or unsigned type corresponding to the effective
type of the object,
— a type that is the signed or unsigned type corresponding to a qualified
version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned types
among its members
(including, recursively, a member of a subaggregate or contained union), or
— a character type.
The relevant condition is the first which refers to type compatibility.
Type compatibility rules are defined in "6.2.7 Type compatibility and composite
type"
"Two types are compatible types if they are the same. Additional rules for
determining whether two types are compatible are described in 6.7.2 for type
specifiers, in 6.7.3 for type qualifiers, and in 6.7.6 for declarators.58)
Moreover, two complete structure, union, or enumerated types declared..."
In 6.7.6 we then have
"For two pointer types to be compatible, both shall be identically qualified
and both shall be pointers to compatible types."
"For two array types to be compatible, both shall have compatible element
types, and if both size specifiers are present, and are integer constant
expressions, then both size specifiers shall have the same constant value."
"For two function types to be compatible, both shall specify compatible return
types. Moreover, the parameter type lists shall agree in the number of
parameters and in use of the final ellipsis; corresponding parameters shall
have compatible types. In the determination of type compatibility and of a
composite type, each parameter declared with function or array type is taken as
having the adjusted type and each parameter declared with qualified type is
taken as having the unqualified version of its declared type."
So type compatibility builds up recursively and types derived in the same way
from different but compatible types are compatible.
Example:
https://godbolt.org/z/rTsE3PhKc
#define COMPAT
typedef char (*(*t0)())[];
typedef char (*(*t1)())[1];
#ifdef COMPAT
typedef char (*(*t2)())[/*2*/];
#else
typedef char (*(*t2)())[2];
#endif
//[[gnu::noinline]]
t0 foo(t0 *x, t0 *y, t0 u, t0 v)
{
t1 *a = x;
t2 *b = y;
#ifdef COMPAT
_Static_assert(_Generic(*b, typeof(*a): 1, default: 0), "");
#endif
(*a) = u;
// since *a and *b alias and the types are compatible,
// this should overwrite the result
(*b) = v;
return *a;
}
char (*(a()))[1] { return 0; }
char (*(b()))[2] { return 0; }
int main()
{
t0 t;
return == foo(, , , );
}
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #6 from Martin Uecker --- Supporting this seems better than forcing the user to work around by providing an incorrect size such as (0, 0).
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #30 from Martin Uecker --- Am Donnerstag, dem 18.04.2024 um 11:57 + schrieb jakub at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 > > --- Comment #29 from Jakub Jelinek --- > (In reply to uecker from comment #28) > > I do not fully understand yet what happens for may_alias, but it if we later > > complete the struct with the may_alias attribute it seems we would also need > > to update the previously created pointer so that it has > > TYPE_REF_CAN_ALIAS_ALL. Setting TYPE_STRUCTURAL_EQUALITY for incomplete > > structs also for pre-C23 seems to fix the assertion failure, but I am not > > sure if this fixes the underlying bug. > > Certainly that may_alias case isn't specific to just C, C++ behaves the same, > and I'd just say don't do that, you can always put the may_alias attribute on > the forward declaration of the struct if all pointers to it are supposed to > alias. The problem I was referring to is the ICE, not that we get from assertions in the middle end, not that some pointers constructed from the incomplete type without the attribute may not have this property, cf. PR114493 For C++, the example does not ICE. I haven't looked at what the C++ FE does differently, I simply observed that setting TYPE_STRUCTURAL_EQUALITY as the patch does for C23 also seems to fix (?) this ICE (but only for C23 if guarded by flag_iso_c23). I haven't had time to look more into this. Martin
[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #19 from Martin Uecker --- It would still work for other arguments that are used in the active branch, but not arguments you may not use in active branch or other subexpressions not used in the active branch.
[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #18 from Martin Uecker --- In theory, we could do something like this, but note that this also has undesirable consequences: This would turn off all such warnings also in expressions passed as macro arguments, i.e. this would substantially reduce type safety for expressions you pass to your 'a2i' macro and also affect other sub expressions one might have inside the implementation of such macros. We could try to be smart and find heuristics to avoid this, but then it already gets more difficult. I personally find the version with the casts acceptable. I would suggest o implement the type tests also using _Generic instead of using the builtin. For example, you could do something like: #define a2i(TYPE, ...) \ _Generic((n), \ long: a2sl(_Generic((n), TYPE: (long*)(n), s, endp, base, min, max), \ ...)
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #13 from Martin Uecker --- A C compiler has to diagnose all constraint violations. Alternatively, it could also reject the program with an error.
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #11 from Martin Uecker --- A conforming C compiler has to diagnose all violations of constraints with the same correct type of x in all branches (not the type it would have in another context where a different is taken).
[Bug c/114727] New: ICE with c23 with aligned attribute and .-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
Bug ID: 114727
Summary: ICE with c23 with aligned attribute and .-g
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
The following ICEs with -std=c23, -g and checking:
#define Y [[gnu::aligned(128)]]
extern struct Y foo { int x; } x;
struct foo { int x; };
We should probably reject redefinition by having
the following in tagged_types_tu_compatible_p.
if (TYPE_USER_ALIGN (t1) != TYPE_USER_ALIGN (t2))
data->different_types_p = true;
[Bug lto/114713] New: incorrect TBAA for struct with flexible array member or GNU zero size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
Bug ID: 114713
Summary: incorrect TBAA for struct with flexible array member
or GNU zero size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
If one mixes a struct with FAM and one with zero size at the end, then TBAA
considers them incompatible for aliasing purposes when using LTO. One could
decide that those are incompatible types, but this would break code that mixes
both, e.g. during a transition time to standard FAMs. Also affects old versions
of GCC.
https://godbolt.org/z/xodMK9sqE
struct foo { int x; char a[]; };
void test_bar(void* b);
__attribute__((noinline))
int test_foo(struct foo* a, void* b)
{
a->x = 1;
test_bar(b);
return a->x;
}
int main()
{
struct foo y;
if (2 != test_foo(, ))
__builtin_abort();
return 0;
}
// TU2
struct foo { int x; char a[0]; };
void test_bar(void* b)
{
struct foo *p = b;
p->x = 2;
}
[Bug c/114361] ICE with c23 related to completion of incomplete structure types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 Martin Uecker changed: What|Removed |Added Resolution|FIXED |--- See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114574 Status|RESOLVED|UNCONFIRMED --- Comment #7 from Martin Uecker --- Reopen bug as setting TYPE_CANONICAL is not so simple, see PR 114574
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #20 from Martin Uecker --- (In reply to Martin Uecker from comment #18) > > > > + TYPE_CANONICAL (x) = TYPE_CANONICAL (t); > > As has been discussed, this is wrong, it should have been > > TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS > > (x)); > > or so. > > Thanks Actually, I think we need to also add the lookup in the hash table to c_build_qualified_type to find the right TYPE_CANONICAL.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #18 from Martin Uecker ---
>
> + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> As has been discussed, this is wrong, it should have been
> TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS
> (x));
> or so.
Thanks
>
> The build_pointer_type change looks really weird.
> I'd say if you want to be prepared for to_type formerly
> TYPE_STRUCTURAL_EQUALITY_P types and now no longer so, we should just change
> for (t = TYPE_POINTER_TO (to_type); t; t = TYPE_NEXT_PTR_TO (t))
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all)
> return t;
> loop to check for this case before return t; (i.e. { if
> (!TYPE_STRUCTURAL_EQUALITY_P (to_type) && !in_lto_p &&
> TYPE_STRUCTURAL_EQUALITY_P (t)) TYPE_CANONICAL (t) =
> build_pointer_type_for_mode (TYPE_CANONICAL (to_type), mode, false); return
> t; }
> or so, and do something similar also for array types and the like.
> And maybe instead of tweaking asserts in ipa-free-lang-data also update
> TYPE_CANONICAL on the derived types if the base type doesn't have
> TYPE_STRUCTURAL_EQUALITY_P.
I am just looking at a version that would have changed the condition to:
if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
&& TYPE_STRUCTURAL_EQUALITY_P (t) == TYPE_STRUCTURAL_EQUALITY_P (to_type))
Martin
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Martin Uecker changed: What|Removed |Added Attachment #57874|0 |1 is obsolete|| --- Comment #16 from Martin Uecker --- Created attachment 57885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57885=edit patch New version. This should work with and without the flag_isoc23 guards.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #15 from Martin Uecker --- Created attachment 57874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57874=edit patch Tentative patch for the fix that makes the incomplete types have structural equivalence at the beginning and then sets TYPE_CANONICAL when they are completed. There is some fallout when one removes the flag_isoc23 condition which I need to look into... Assuming this approach is ok, then I think this change should be done also for pre-C23 in the future.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #14 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #12)
> Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
> TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
> seems c-typeck.cc doesn't actually use that, so it is mainly middle-end
> then).
> See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at
> least one TYPE_CANONICAL is NULL (aka TYPE_STRUCTURAL_EQUALITY_P), and
> otherwise at least without checking will rely on TYPE_CANONICAL comparison
> and that is it.
> So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as long
> as comptypes etc. works correctly). Having TYPE_CANONICAL non-NULL and not
> actually matching could cause type comparisons to think types are the same
> when they aren't or vice versa.
>
> Now, when you set TYPE_CANONICAL on completion of the flag_isoc23
> aggregates, you could surely also update TYPE_CANONICAL of the variant types
> using build_qualified_type and perhaps pointers too, just to handle the
> common case. But unlike the case where the TYPE_CANONICAL of the aggregate
> TYPE_MAIN_VARIANT would be initially different, you wouldn't need to chase
> down everything, including TYPE_CANONICAL on FUNCTION_TYPE which have
> pointers to array type of array type of pointer of pointer of qualified
> pointer to the aggregate etc., just the common things.
> And setting TYPE_CANONICAL just based on the tag would be also wrong, if one
> can define struct S { int s; }; in one scope and struct S { int a, b; }; in
> another scope and those types are supposed to be different.
According to my understanding, setting based on tag would form larger
equivalence classes, so should give correct code but suboptimal aliasing
analysis.
There are two general issues I see here.
1.) The middle end idea of type compatibility is not necessarily the same as
the language semantics. In particular type compatibility in C is not based on
mutual equivalence, so any mechanism based on forming equivalence classes using
TYPE_CANONICAL can only be an approximation (which to be correct, must be less
precise than the language semantics).
2.) If compatibility relationship changes for types (as it the case when
completing types, then we either have to use an equivalence class that does not
need to change (e.g. based on tags) or only use structural equivalency, or
upgrade structural equivalency to the equivalency class for the completed type
if this is allowed.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #13 from Martin Uecker --- (In reply to Richard Biener from comment #11) > Wrong TYPE_CANONICAL leads to wrong TBAA. And yes "fixing" TYPE_CANONICAL > after the fact means possibly merging two equivalence classes which means > you have to > fix all members of both classes to have the corresponding TYPE_CANONICAL. > Plus > the complication of derived types (vector, pointer, and others) which have > constraints based on their contained type equivalence class. Is upgrading incomplete types from structural comparison to TYPE_CANONICAL meant to be allowed?
[Bug c/114361] ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 Martin Uecker changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #4 from Martin Uecker --- Though similar symptoms, this is not a duplicate for 114014
[Bug c/114361] ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 --- Comment #3 from Martin Uecker --- Created attachment 57834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57834=edit patch Tentative patch.
[Bug c/114361] New: ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Bug ID: 114361
Summary: ICE with c23 when creating mutually nested and
compatible types with statement expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
This fails in verify_type (goes away with -fchecking=0):
void f()
{
typedef struct foo bar;
typedef __typeof( ({ (struct foo { bar *x; }){ }; }) ) wuz;
struct foo { wuz *x; };
}
https://godbolt.org/z/q7n5xbsc1
[Bug tree-optimization/113879] New: missed optimization - not exploiting known range of integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
Bug ID: 113879
Summary: missed optimization - not exploiting known range of
integers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
This is similar to PR105855 but without sanitizer.
In the following example the loop is not vectorized because the overflow check
(which is not needed) is not removed. It works when adding the first check
before the loop. But the information about j < INT_MAX can be derived directly
from j < i + 4.
void f(int i, float * restrict a, float * restrict b)
{
#if 0
if (INT_MAX - 4 < i)
__builtin_unreachable();
#endif
for (int j = i; j < i + 4; ) {
a[j] = b[j] + 1.;
#if 1
if (INT_MAX - 1 < j)
__builtin_trap();
#endif
j++;
}
}
https://godbolt.org/z/xnEbh5zfv
[Bug c/113878] New: missed optimization with sanitizer and signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878
Bug ID: 113878
Summary: missed optimization with sanitizer and signed integer
overflow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
It would be nice if the following example could be optimized better with the
sanitizer. Without sanitizer the function is optimized to return 1. With
sanitizer I would expect it to only add the test for the underflow condition,
but it then fails to optimize well.
int test(int x)
{
if (x > 100)
return 1;
x -= 10;
if (x > 100)
return 2;
return 1;
}
https://godbolt.org/z/j4K96v7jn
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 --- Comment #5 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644124.html
[Bug c++/113263] New: ICE for invalid code for compound literal and type definition in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Bug ID: 113263
Summary: ICE for invalid code for compound literal and type
definition in return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
The following example ICEs after invalid code (it is valid C but not C++)
https://godbolt.org/z/7zrbxPraM
(partially minimized from: C example https://godbolt.org/z/M7n7o1r8h)
#define TOKEN_CONCAT_EX(x, y) x##y
#define TOKEN_CONCAT(x, y)TOKEN_CONCAT_EX(x, y)
#define UNIQUIFY(x) TOKEN_CONCAT(x, __LINE__)
#define ResultBody(T, E) { bool _is_ok; union { T _ok; E _err; }; }
#define ResultName(T, E) result_##T##_##E
#define ResultEx(T, E, T_N, E_N) struct ResultName(T_N, E_N) ResultBody(T, E)
#define Result(T, E) ResultEx(T, E, T, E)
#define Err(R, V) ((R) { ._is_ok = false, ._err = V, })
typedef struct
{
int val;
} thing_t;
Result(thing_t, bool) maybe_make_thing(int v)
{
return Err(Result(thing_t, bool), v == 200);
}
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 --- Comment #10 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639961.html
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #9 from Martin Uecker --- Created attachment 56830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56830=edit patch Here is a patch, but it causes an ICE in FAIL: gcc.dg/debug/pr39412.c -gctf (internal compiler error: in AT_unsigned, at dwarf2out.cc:4590) which I do not understand so far.
[Bug c/112791] error: 'TYPE_CANONICAL' is not compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112791 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #1 from Martin Uecker --- Also on RISC V (64 bit9 https://godbolt.org/z/3bEc5j34E
[Bug lto/112716] LTO optimization with struct with variable size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #9 from Martin Uecker ---
(In reply to Richard Biener from comment #8)
> (In reply to uecker from comment #7)
>
> > >
> > > Note that even without LTO when you enable inlining you'd expose two
> > > different structures with two different alias-sets, possibly leading
> > > to wrong-code (look at the RTL expansion dump and check alias-sets).
> >
> > Yes, for pre C23 this is true for all structs even without VLA.
> > But for C23 this changes.
> >
> > The main case where the GNU extension is interesting and useful is
> > when the VLA field is at the end. So at least for this case it would
> > be nice to have a solution.
>
> So what's the GNU extension here? VLA inside structs are not a C thing?
ISO C does not currently allow VLAs or variably-modified types
inside structs. So all these are GNU extensions.
WG14 is thinking about allowing pointers to VLAs inside structs.
struct foo {
int n;
char (*buf)[.n];
};
But this is a bit different because it would not depend on an
external value.
> I suppose if they were then C23 would make only the "abstract" types
> compatible but the concrete types (actual 'n') would only be compatible
> when 'n' is the same?
Yes, this is how it works for other variably-modified types
in C (since C99) where it is then run-time undefined behavior
if 'n' turns out not to be the same.
>
> I think the GNU extension is incomplete, IIRC you can't have
>
> foo (int n, struct bar { int x; int a[n]; } b) -> struct bar
> {
> return bar;
> }
>
> and there's no way to 'declare' bar in a way that it's usable across
> functions.
You could declare it again in another function
void xyz(int n)
{
struct bar { int x; int a[n]; } y;
foo(n, y);
}
and with C23 compatibility rules this would work.
>
> So I'm not sure assigning C23 "semantics" to this extension is very
> useful. Your examples are awkward workarounds for an incomplete
> language extension.
In any case, we already have the extension and we should
either we make it more useful, or document its limitations,
or deprecate it completely.
[Bug lto/112716] LTO optimization with struct with variable size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #5 from Martin Uecker ---
It works (and is required to work) for other types, e.g.
[[gnu::noinline,gnu::noipa]]
int foo(void *p, void *q)
{
int n = 5;
int (*p2)[n] = p;
(*p2)[0] = 1;
bar(q);
return (*p2)[0];
}
void bar(void* q)
{
int n = 5;
int (*q2)[n] = q;
(*q2)[0] = 2;
}
One could argue that there is a weaker requirement for having an object of type
int[n] present than for struct { int x[n]; } because we do not access the array
directly but it decays to a pointer. (but then, other languages have array
assignment, so why does the middle-end care about this C peculiarity?)
There is also no indication in documentation that structs with variable size
follow different rules than conventional structs. So my preference would be
to fix this somehow. Otherwise we should document this as a limitation.
[Bug lto/112716] New: LTO optimization with struct of variable ssize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
Bug ID: 112716
Summary: LTO optimization with struct of variable ssize
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The following code using a GNU extension gets miscompiled due to incorrect
aliasing assumptions with -flto and -O2:
gcc -flto -O2 y.c y2.c -DT1="int[n]" -DT2="int[n]"
// y.c
void bar(void*);
[[gnu::noinline,gnu::noipa]]
int foo(void *p, void *q)
{
int n = 5;
struct foo { int x; typeof(T1) y; } *p2 = p;
p2->x = 1;
bar(q);
return p2->x;
}
int main()
{
int n = 5;
void *p = __builtin_malloc(sizeof(struct foo { int x; typeof(T1) y;
}));
if (!p)
return 0;
if (2 != foo(p, p))
__builtin_abort();
return 0;
}
// y2
void bar(void* q)
{
int n = 5;
struct foo { int x; typeof(T2) y; } *q2 = q;
q2->x = 2;
}
[Bug c/112429] New: Wnonnull should warn for multi-dimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112429
Bug ID: 112429
Summary: Wnonnull should warn for multi-dimensional arrays
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
In the following example, Wnonnull warns only about the second call.
int b(int n, char buf[static n][n]);
int c(int n, char buf[static n][1]);
void foo(int n)
{
b(3, 0);
c(3, 0);
}
https://godbolt.org/z/nnhxoPo91
[Bug c/112428] New: Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428
Bug ID: 112428
Summary: Wnonnull outputs wrong type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
In the following example the type of the argument if output incorrectly:
int b(int n, char buf[static n][1]);
void foo(int n)
{
b(3, 0);
}
:7:5: warning: argument 2 to 'char[1][static 3]' is null where non-null
expected [-Wnonnull]
7 | b(3, 0);
| ^~~
:2:5: note: in a call to function 'b'
2 | int b(int n, char buf[static n][1]);
| ^
https://godbolt.org/z/eTe6hWxoM
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #11 from Martin Uecker --- This is one possible way to read it. But as written, I think one can easily understand it the other way, because calloc never mentions requested total size but only about space for an array of objects of size 'size'. And then also 7.24.3 continues with "It may then be used to access such an object or an array of such objects.." which would also imply that the "size" in the sentence before refers to the size of an individual object. Anyway, I think it does not really matter for us... IMHO it is still useful to make the code have the logical order as documented for calloc. And if it turns out that the warning annoys too many people in this way, we can still tweak it before the release.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #9 from Martin Uecker --- (In reply to jos...@codesourcery.com from comment #7) > I believe "size requested" refers to the product nmemb * size in the case > of calloc, so getting the arguments the "wrong" way round does not affect > the required alignment. The point of the change was to override DR#075 > and stop requiring e.g. 1-byte allocations to be suitably aligned for > larger types, not to make alignment for calloc depend on more than the > product of the two arguments. This may have been the intention but the wording now refers explicitly to the size. To me this also makes sense as calloc talks about allocating an array of objects of size 'size'. The required alignment of the array would not depend on the number of elements but only their size.
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #20 from Martin Uecker --- Ah, this is how it works. Thanks!
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #18 from Martin Uecker --- I think this can be closed.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #6 from Martin Uecker --- For reference, this is were the revised wording in C comes. This is intentional. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #16 from Martin Uecker --- I agree that the C++ should have this warning as well, although it seems less important there. This would be an enhancement request for the C++ FE.
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #14 from Martin Uecker --- "I think calloc is available in C++, so the warning is wrong." I am happy to revise the warning if it is wrong or annoying, but I do not understand what C++ has to do with this.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #4 from Martin Uecker --- Interesting. But independently of alignment, the description of calloc makes it clear that it allocates an array of nmemb objects of size x. So in any case I think the code should be changed accordingly, which seems simple enough.
[Bug libfortran/112364] calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #2 from Martin Uecker --- I don't think this is correct. The requirement is "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and size less than or equal to the size requested." So it only has to take into account fundamental alignments for objects below the given size and the fundamental alignment requirement differs for different objects. Note that there is no "fundamental alignment". max_align_t would have the "greatest fundamental alignment", but the wording for allocation functions does not refer to the greatest fundamental alignment.
[Bug libfortran/112364] New: calloc used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 Bug ID: 112364 Summary: calloc used incorrectly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: muecker at gwdg dot de Target Milestone: --- As detected by -Walloc-size, there are some calls to calloc in libgfortran with incorrectly ordered arguments. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347#c10 ../../../trunk.year/libgfortran/io/async.c:265:24: warning: allocation of insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size] ../../../trunk.year/libgfortran/io/async.c:287:24: warning: allocation of insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size] ../../../trunk.year/libgfortran/io/async.c:311:24: warning: allocation of insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size] ../../../trunk.year/libgfortran/io/async.c:331:24: warning: allocation of insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size] transfer_queue *tq = calloc (sizeof (transfer_queue), 1); Note that for the allocated size the order of arguments does not matter, but - at least according to my understanding - the alignment requirements for the returned memory may depend on the object size being the second argument.
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #12 from Martin Uecker --- I filed a bug for libfortran: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #11 from Martin Uecker ---
In this case this is by design because the size of an element should be second
argument to calloc. ("The calloc function allocates space for an array of nmemb
objects, each of whose size is size.")
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 Martin Uecker changed: What|Removed |Added Attachment #56490|0 |1 is obsolete|| --- Comment #6 from Martin Uecker --- Created attachment 56491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56491=edit patch Ok, let's try again...
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 Martin Uecker changed: What|Removed |Added Attachment #56489|0 |1 is obsolete|| --- Comment #5 from Martin Uecker --- Created attachment 56490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56490=edit patch Correct attachment.
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #4 from Martin Uecker --- Created attachment 56489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56489=edit patch This should fix it. I am running some tests and will commit this.
[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347 --- Comment #3 from Martin Uecker --- Thanks for reporting. I will fix this.
[Bug sanitizer/98608] missing sanitizer detection for arrays with invalid length defind using typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608 --- Comment #3 from Martin Uecker --- PATCH (but unclear about n == 0) https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634896.html
[Bug c/70954] -Wmisleading-indentation false positive on GNU "ed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 from Martin Uecker ---
Here is another example of what appears to be the same bug. Reported here:
https://gcc.gnu.org/pipermail/gcc/2023-November/242803.html
I think it would be useful of the title of this report could be changed to
mention "label".
/*
* miside.c
* MWE for a wrong warning shown with gcc -Wmisleading-indentation
*/
void
good(int c)
{
label:
while (c != '-');
if (c != '-')
goto label;
}
void
bad(int c)
{
label: while (c != '-');
if (c != '-')
goto label;
}
https://gcc.godbolt.org/z/6MMsds1bd
[Bug ipa/96503] attribute alloc_size effect lost after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 --- Comment #7 from Martin Uecker --- Am Mittwoch, dem 25.10.2023 um 11:08 + schrieb siddhesh at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 > > --- Comment #6 from Siddhesh Poyarekar --- > So basically, > > __builtin_with_access(void *ptr, size_t size, int access) > > where access == > > -1: Unknown access semantics > 0: none > 1: read_only > 2: write_only > 3: read_write > > should address both access and alloc_size and even counted_by. Yes, sounds good. > We would need > to emit the builtin in the caller as well as callee of the function that has > the access attribute while for alloc_size, we only need to emit this in the > caller. Yes, makes sense, although I guess caller part for "access" is only for warning and not relevant for BDOS, so could potentially stay as it is for now. For __builtin_with_access we probably only want to allow reducing the object size, while the 'extend_size' workaround used by systemd (cf comment #4) would need to extend it. Maybe we need another flag? Martin
[Bug ipa/96503] attribute alloc_size effect lost after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3 from Martin Uecker ---
Was just to file this bug...
Note that the access attribute could be translated into the same builtin
suggested for counted_by in
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634177.html
and then this could work. This would also simply the BDOS path I think because
special code for the access attribute could go.
Example: https://godbolt.org/z/1TTePn7hn
static
#if 0
char *propagate(char *p, int s)
[[gnu::access(read_only, 1, 2)]]
#else
char *propagate(char *p; int s;
char p[(p = pointer_with_size(p, s), s)], int s)
#endif
{
printf("%ld\n", __builtin_dynamic_object_size(p, 0));
return p;
}
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #25 from Martin Uecker --- I agree that they are not idiomatic C++ and that there exist good reasons why a programmer may want to avoid them (including standards compliance). But code not being idiomatic is not a terrible good reason for having a warning. As a matter of principle, we should not warn about our own extensions without a very good reason with -std=gnu modes and neither should clang IMHO. But the idea that VLAs are inherently very dangerous is incorrect, so let's not perpetuate that myth. There are many useful things a compiler could do to improve security for VLAs and also for std::vector or elsewhere by having better static analysis and more efficient options for bounds checking. Neither clang nor GCC will currently give any compile-time warning about a problem here with -Wall -Wextra nor will there be a run-error with UBSan: https://godbolt.org/z/7vhGMn3E5 And yes, -D_GLIBXX_DEBUG which will detect the out-of-bounds access but not the memset. Maybe -D_FORTIFY_SOURCE=3 will do this (as it does for VLAs), but it does not seem to work on godbolt for both cases, so I can't check. Asan will catch both. For comparison, with VLAs we have this: https://godbolt.org/z/hGxGrc569
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #22 from Martin Uecker --- There may be many good reasons to prefer std::vector over VLAs in C++ but security and safety is not one of them. There are plenty of CVEs caused by std::vector out-of-bounds accesses. The question is whether in GNU mode one should warn about a GNU extension. People who want to avoid VLAs for reasons of standard compliance would also not use a GNU mode.
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #20 from Martin Uecker --- And what alternative do you think is fundamentally safer than VLAs? VLAs know their bound. Thus, they integrate with _FORTIFY_SOURCE, and UBSan bounds checking. Also UBSan address checking at run-time. At compile-time there is -Wstringop-overflow -fanalyzer and -Walloc-larger-than. Then also stack clash protection against stack overflow and stack protection against overflow on the stack (which is a second-line defense after bounds checking, which failed here in a very specific case to protect alloca and VLAs. This is - of course - by itself not a vulnerability.) https://godbolt.org/z/PfcWP55or alloca is clearly worse. Fixed size arrays on the stack which a worst-case bounds are also worse in most cases. std::vector has some protection, e.g. ASAN finds the out of bounds access (at a high run-time cost) and one could activate the GLIBC assertions someho: https://godbolt.org/z/8zanMG5x4 But I would not call it safer and overhead is much worse. Fundamentally, VLAs are the dynamic buffer which can be protected most easily and should be *preferred*.
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #16 from Martin Uecker --- I do not think -Wall should warn about GNU extensions when used with -std=gnu++XX in C++ and I think it is annoying that clang does it now. It only drives people to use alloca or other alternatives with worse safety properties. And I think the security concerns for VLAs are largely based on a logical fallacy: Because they appear in CVE is no reason to believe they caused it: It is likely saying that people ICDs have more often cardiac arrests if because of the ICDs. Any kind of dynamically sized buffer will appear in CVEs because buffers are used to process data from the network. If you discourage the one with the best potential for bounds checking people will turn to worse options. This will not improve safety. But stack clash protection should become the default.
[Bug c/111808] [C23] constexpr with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #8 from Martin Uecker ---
There are certainly other similar portability issues, e.g.:
enum : long { X = 0xUL };
https://godbolt.org/z/hKsqPe9c1
BTW: Are there better examples where we have similar build failures also in
pre-C2X? (not counting explicit compile-time tests for sizes or limits) Most
simple C expressions do not seem to produce a hard error when switching between
64 and 32 bit archs, e.g. exceeding the range in an initializer of an enum does
not produce hard errors without -predantic-error before C2X. That we now seem
to have such issues worries me a little bit.
In any case, I would argue that issues related to the size of integers are much
better understood by programmers, while excess precision is rather obscure and
also has much more implementation-defined degrees of freedom. The behavior of
integers is more or less fixed by its width, but with what precision 1. / 3. is
computed on any specific platform is not restricted. The use of such a thing in
a constexpr initializer then makes the program inherently non-portable and I do
not believe programmers are aware of this.
Debugging such issues after the fact because a package fails to build on, for
example, 3 of 20 architectures in Debian is generally a huge pain. On the
other hand, maybe excess precision on i386 is obscure and i386 will go away
and we should not worry?
[Bug c/111808] [C23] constexpr with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #6 from Martin Uecker --- Adding a note is a good idea, but it doesn't really solve the issue. The problem I see is that somebody developing on x86-64 does not get a warning that the code is not strictly conforming and then it fails to build elsewhere. Ideally, there is an algorithm which can decide whether the result is exact in all versions with same or higher precision or not. Otherwise, computing it with some higher precision and comparing the results would catch most problems (but not all). Alternatively, one could downgrade the error to warning. The code may then be slightly wrong on i386 but at least the build does not fail.
[Bug c/111808] [C23] constexpr with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #2 from Martin Uecker --- On i386 1. / 3. is computed with higher precision than double and then the initializer changes the value which is a contraint violation in C23. But whether this happens or not depends on the architecture, so this code is not portable.
[Bug c/111808] New: [C23] constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Bug ID: 111808
Summary: [C23] constexpr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
GCC implements constraint 6.7.1p5 for constexpr initialized with a float
pointer value as an error. For example, the following fails to compile on
i386:
int func(void)
{
constexpr double f2 = 1. / 3.;
return 3. * f2 == 3. * (1. / 3.);
}
with
: In function 'func':
:7:25: error: 'constexpr' initializer not representable in type of
object
7 | constexpr double f2 = 1. / 3.;
while it compiles on x64-86. This seems problematic because this it will cause
a lot surprising failures when compiling code written for x64-86 on i386. We
should either have a warning that such code is non-portable (but this seems
difficult) or downgrade this to a warning and accept the code as an extension
on architectures which compute with excess precision.
https://godbolt.org/z/7vsWhvKjd
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 --- Comment #8 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632999.html
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 --- Comment #7 from Martin Uecker --- Created attachment 56075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56075=edit patch adding error external / internal mismatch of functions Untested patch.
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #6 from Martin Uecker --- I think your nested declaration of "extern int f(int);" has external linkage, because the declaration with internal linkage is not visible (it is hidden by the definition of the object with no linkage). So I agree this is compile-time UB and we miss the warning which we have for objects.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #48 from Martin Uecker --- Indicating a null terminated string should certainly use a different attribute name.
[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630817.html
[Bug c++/109021] accept size parameter in extern C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021 --- Comment #6 from Martin Uecker --- Note that I do not propose to add variably modified types to C++. This would indeed be a major extension. I simply propose to ignore the size expressions in C headers as a usability improvement. My patch I have somewhere for this are a couple lines of code. I plan to bring this up to WG21 anyway, but standards should ideally standardize things where there exists prior experience. It would be helpful if GCC takes part in this process.
[Bug c++/109021] accept size parameter in extern C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021 --- Comment #4 from Martin Uecker --- Sorry, how can an enhancement request that addresses a real C/C++ compatibility problem be marked "resolved invalid" ?
[Bug c/84510] C front-end does not utilise -Wuseless-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626973.html
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #56 from Martin Uecker --- [[nodiscard]] works as expected and is supported for older language modes since GCC 11 (and the syntax is ignored with a warning in GCC 10). Clang supports it with -std=c2x since version 9 and it seems Clang will also support it in older language modes in future releases.
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #15 from Martin Uecker ---
GCC seems to allocate enough for sizeof(struct foo) + n * sizeof(char) but not
for sizeof(struct { int a; char b; char t[n]; }).
[Bug c++/110920] New: variably-length array declarations as parameters for C compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110920
Bug ID: 110920
Summary: variably-length array declarations as parameters for C
compatibility
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
g++ rejects variably length arrays in parameters because C++ does not have
this. This is a problem when including some C headers.
extern "C" {
extern void foo(int A, double matrix[A]);
extern void bar(int A, int B, double[A][B]);
}
g++ could simply parse and then ignore the parameter as a language extension.
The first function 'foo' would then be directly usable form C++. For the second
function, there is no corresponding C++ type, but accepting this declaration in
headers would still allow the use of other functions. One could also consider
the possibility to allow calling this function from C++ code with a double*.
[Bug c/102558] missing warning comparing T[static N] to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #1 from Martin Uecker --- Possibly fix by synthesizing a nonnull attribute: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625559.html
[Bug c/108986] [11 Regression] Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #10 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625559.html
[Bug c/68193] _Generic -Woverflow false alarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #7 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html
[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html
[Bug tree-optimization/102556] equality comparison of a [static N] parameter to null not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102556 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2 from Martin Uecker --- PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625559.html
[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110878 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- It is true that there is no UB, but the warning is not directly related to whether something is UB or not. It simply assumes that 16 is an upper bound although the standard does require this.
[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609 --- Comment #9 from Martin Uecker --- I just ran into this problem again while trying to fix PR98608 where the problem is that instrumentation of parameters is missing. In parameters people often use n == 0 null and some of the -Wnonnull warnings we have currently even require setting it 0.
[Bug sanitizer/98608] missing sanitizer detection for arrays with invalid length defind using typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608 --- Comment #2 from Martin Uecker --- The problem is actually the missing sanitizer instrumentation of the parameter type. This is easy to fix, but then I run into the problem that a lot of code has n == 0 in parameters. Having an option to avoid the instrumentation (PR98609) might help.
[Bug c++/110848] Consider enabling -Wvla by default in C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- I am not entirely convinced std::vector is actually superior in terms of performance nor security. The code looks better to for VLAs even with bounds checking. https://godbolt.org/z/xhvPePGbb Although compiler support could be better and their usefulness in C++ without other VM types is limited compared to C.
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 --- Comment #1 from Martin Uecker --- Created attachment 55638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55638=edit patch This patch would synthesize a nonnull attribute for such parameters, making this fully equivalent.
[Bug c/110815] New: [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815
Bug ID: 110815
Summary: [static] not as useful as the nonnull attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
C code increasingly uses
void foo(char buf[static 10]);
to indicate that buf is a non-null pointer.
GCC already has some warnings for this but all you would get with the nonnull
attribute. In particular, -Wnonnull-compare is missing.
void
foo (int a[static 1])
{
if ((void*)0 == a) // should warn
return;
}
https://godbolt.org/z/E6E33Pa8h
[Bug middle-end/110754] assume create spurious load for volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754 --- Comment #6 from Martin Uecker --- One should check whether there is a similar issue with atomics, at least regarding accidentally introducing memory ordering or so.
[Bug c++/110754] New: assume create spurious load for volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754
Bug ID: 110754
Summary: assume create spurious load for volatile variable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
With optimization, using assume with volatile create spurious loads:
int bar(int p)
{
volatile int n = p;
[[assume (1 == n)]];
return 1 + n;
}
bar(int):
mov DWORD PTR [rsp-4], edi
mov eax, DWORD PTR [rsp-4]
mov eax, DWORD PTR [rsp-4]
add eax, 1
ret
[Bug middle-end/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- I agree. It would nice to have a solution here, as it would make using VLAs safer. And the alternatives to VLAs people tend to use because they are scared are usually worse in terms of readability, performance, and bounds checking.
[Bug c/29970] mixing ({...}) with VLA leads to massive breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970 --- Comment #18 from Martin Uecker --- What is not fixed is returning structs with VLA members as in the first three test cases, e.g. the second one still ICEs.
[Bug sanitizer/98623] sanitizer does not diagnose when passing pointers to arrays of incorrect run-time length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98623 --- Comment #2 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619943.html
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #14 from Martin Uecker --- Maybe. On the other hand, I wonder whether a struct with FAM should not rather always have the same size, and alignment, and representation as the corresponding struct with a conventional array. This would conceptually be cleaner, easier to understand, and less error prone.
[Bug c/109970] New: -Wstringop-overflow should work with parameter forward declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970
Bug ID: 109970
Summary: -Wstringop-overflow should work with parameter forward
declarations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
For bar I get the expected warning but not for foo.
void bar(int x, char buf[x]);
void foo(int x; char buf[x], int x);
int main()
{
char buf[10];
bar(11, buf);
foo(buf, 11);
}
https://godbolt.org/z/zhzr43c55
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #12 from Martin Uecker ---
The C standard says "However, when a . (or -> ) operator has a left operand
that is (a pointer to) a structure with a flexible array member and the right
operand names that member, it behaves as if that member were replaced with the
longest array (with the same element type) that would not make the structure
larger than the object being accessed;"
This would imply that also for GCC not all elements can be accessed in the
following structure without invoking UB. For x86_64 'x' has 11 bytes (for clang
9) but a struct with replacement array actually needs 12.
struct foo { int a; short b; char t[]; } x = { .t = { 1, 2, 3 } };
// x has 11 bytes
struct bar { int a; short b; char t[3]; }; // 12 bytes
One can argue that this does not matter for an extension and maybe the C
standard should not be read in this way as itself also contains an example
using the sizeof() + n * sizeof() rule which implies that this amount of
storage is enough for n elements.
But the question is what programmers should use when using memcpy of statically
initialized structs which have a FAM? sizeof() + n * sizeof() works for GCC
but not for clang. sizeof(struct bar) works for neither. One can use
MAX(sizeof(struct foo, offsetof(struct foo, t) + n * sizeof(char)) but I have
not seen anybody use it.
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #9 from Martin Uecker --- Clang as well, but that would be only padding inside the first part without taking into account extra element in the FAM. I am more concert about programmers using the formula sizeof(.) + n * sizeof for memcpy etc. (and we have an example in the standard using this formula). Creating objects smaller than this seems a bit dangerous.
