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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #5 from Martin Uecker ---
Clang bug:
https://github.com/llvm/llvm-project/issues/62929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #4 from Martin Uecker ---
The concern would be that a program relying on the size of an object being
larger may then have out of bounds accesses. But rereading the standard, I am
also not not seeing that this is required. (for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96114
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106425
Martin Uecker changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418
--- Comment #8 from Martin Uecker ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
Martin Uecker changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
--- Comment #5 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #10 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
--- Comment #10 from Martin Uecker ---
PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
--- Comment #3 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #43 from Martin Uecker ---
Yes, this is great! I am also looking forward to your patch! It seems it works
with the bounds checking code? Does it also interact with the object size
pass?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #5 from Martin Uecker ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Uecker from comment #3)
> > I general the pointer could point to the first object of an array that has
> > more elements, or to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
--- Comment #8 from Martin Uecker ---
Created attachment 54818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54818=edit
another version
This works without regressions, but is still not correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
--- Comment #2 from Martin Uecker ---
This is unrelated to PR29970. The cause of this is that gimplify_parm_type
recurses into incomplete types which is wrong for the same reason as in
gimplify_type_sizes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
Bug ID: 109450
Summary: Wrong code for VLA in struct sithe size expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #38 from Martin Uecker ---
Am Dienstag, dem 04.04.2023 um 15:07 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #37 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #36 from Martin Uecker ---
Am Montag, dem 03.04.2023 um 20:29 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #35 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
--- Comment #1 from Martin Uecker ---
Created attachment 54796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54796=edit
partial fix
Simply removing the condition based on internal_p would make it work for the
most important cases as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #15 from Martin Uecker ---
Thanks.
I still wonder whether the original example should be added to the test suite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #34 from Martin Uecker ---
Created attachment 54787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54787=edit
patch for C FE to add size expressions to VM types in structs
Here is a preliminary patch for C FE just to see how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
--- Comment #4 from Martin Uecker ---
This version works with 4.1.2
https://godbolt.org/z/x4v6aTv87
int h(void)
{
int g(int m, struct { char (*p)[m]; }* b) { return sizeof *b->p; }
return g(5, 0);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105208
--- Comment #1 from Martin Uecker ---
Still affects 12.x but seems to have disappeared on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
--- Comment #4 from Martin Uecker ---
Seems you are right. Thanks!
I get it for gcc-10 but not gcc-12 with -mfma on x86.
Apparently, WG14 made a change at some point to allow this. But GCC does not
implement the pragma to turn it off...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
Bug ID: 109132
Summary: Apple M1 floating point bug when optimizing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #32 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 19:20 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #30 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #29 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 17:13 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #24 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #28 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 16:56 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #23 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #21 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Bill Wendling from comment #18)
> > > This is not the case in C: https://godbolt.org/z/P7M6cdnoa
> > >
> > Right, it's not legal C syntax. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #20 from Martin Uecker ---
Am Montag, dem 06.03.2023 um 19:15 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #18 from Bill Wendling ---
> (In reply to Martin Uecker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
--- Comment #2 from Martin Uecker ---
True. But we could still take it as a hint about where this is not useful to
users to diagnose this as an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109021
Bug ID: 109021
Summary: accept size parameter in extern C
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #17 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 23:18 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #16 from Bill Wendling ---
> (In reply to Martin Uecker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #15 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #14 from Bill Wendling ---
> (In reply to Martin Uecker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #13 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 19:47 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #10 from Martin Uecker ---
And to get bounds checking for the flexible array member today,
one could use a macro to attach the bound back to the array
on member access.
https://godbolt.org/z/GbaoYrhav
But the bound from the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #9 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 17:34 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #8 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #7 from Martin Uecker ---
An attribute is certainly simpler and should be easy to add.
I proposed similar extension for C23 and there was some interest,
but I did not have time to follow up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108931
Bug ID: 108931
Summary: conditional operator for variably modified types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
--- Comment #7 from Martin Uecker ---
Created attachment 54529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54529=edit
new version of patch
Here is another patch that does all the recursion in gimplify_type_sizes.
Unfortunately, there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #11 from Martin Uecker ---
Yes, for C this is fixed on trunk. This change seems to also fix PR102939.
There is only one place in c-common/ left where middle-end function is used, so
we could easily separate the C FE understanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
--- Comment #3 from Martin Uecker ---
Created attachment 54496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54496=edit
patch for C FE
Here is a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #8 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612245.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
Martin Uecker changed:
What|Removed |Added
Attachment #54458|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #6 from Martin Uecker ---
Created attachment 54458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54458=edit
preliminary patch against trunk
Here is a preliminary patch. It takes a bit from type_common to cache negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #5 from Martin Uecker ---
Recursing into arrays is simple and does not seem to cause any problems,
but this not enough for GNU C, we can also have VLA or variably modified
types as member of structs. At least the later is sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108765
--- Comment #3 from Martin Uecker ---
I see. Thanks. The checking is new? Or just because it is not a release built?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108765
Bug ID: 108765
Summary: ICE with non-local goto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #8 from Martin Uecker ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660
--- Comment #11 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
--- Comment #6 from Martin Uecker ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660
--- Comment #10 from Martin Uecker ---
I do not think the suggested change is correct. I am looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
--- Comment #5 from Martin Uecker ---
Yes. After reconsidering this, this is not related to the other bugs mentioned
above. I think your first example needs to be invalid, because the derived
return type then depends on a variable inside the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770
--- Comment #7 from Martin Uecker ---
Regression tests:
https://gcc.gnu.org/g:ebf7dd754a95bf9680bc53331a6b70f0cf83c045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #7 from Martin Uecker ---
* gimplify_type_size does not recurse into pointer, record, or function types
(the later are not mentioned).
* the C FE has code to emit fake TYPE_DECLs for pointer types in
c-decl.cc/grokdeclarator
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #6 from Martin Uecker ---
Actually, I meant PR84305 for C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #5 from Martin Uecker ---
Probably related to PR88256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #4 from Martin Uecker ---
The specific problem is triggered by the change to pointer_int_sum in
gcc/c-family/c-common.cc, but the underlying problem is older. The following
example fails since gcc 7:
void f(int n, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #3 from Martin Uecker ---
Smaller example:
void f(int n, int (*a(void))[n])
{
(a())[0];
}
void g(void)
{
int (*a(void))[1];
f(1, a);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054
--- Comment #3 from Martin Uecker ---
It is a major usability issue for its intended use in macros if it then
sometimes breaks due to arbitrary constraints (which __auto_type does not have,
so do not seem to be essential).
Also with the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108156
Bug ID: 108156
Summary: missing set but not used warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054
Bug ID: 108054
Summary: C2X auto with structs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106702
Bug ID: 106702
Summary: ICE with LTO: internal compiler error: tree code
‘c_maybe_const_expr’ is not supported in LTO streams
Product: gcc
Version: 11.3.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106580
Bug ID: 106580
Summary: ICE with UBSan and -fsanitize-undefined-trap-on-error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
Bug ID: 106465
Summary: ICE for VLA in struct in parameter of nested function
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
--- Comment #7 from Martin Uecker ---
Sorry, somehow I missed this. I will look at this once I am back from travel
(if Marek hasen't fixed it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106425
--- Comment #1 from Martin Uecker ---
Example:
int f(void)
{
auto n = 1.5;
return n * 2;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106425
Bug ID: 106425
Summary: implicit-int
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105855
--- Comment #2 from Martin Uecker ---
Clang seems to do a combined check before the loop without creating a new
version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105855
Bug ID: 105855
Summary: missed optimization - vectorization
-fsanitize=signed-integer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105294
Bug ID: 105294
Summary: restrict pointer - disagreement with specification
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105208
Bug ID: 105208
Summary: incorrect -Wunused-but-set-variable for static const
variables used in const expressions
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #16 from Martin Uecker ---
(In reply to rguent...@suse.de from comment #14)
> On Wed, 9 Mar 2022, muecker at gwdg dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
> >
> > --- Comment #12 from Martin Uecker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #15 from Martin Uecker ---
(In reply to rguent...@suse.de from comment #13)
> On Wed, 9 Mar 2022, muecker at gwdg dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
> >
> > --- Comment #11 from Martin Uecker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #12 from Martin Uecker ---
(In reply to Richard Biener from comment #10)
> Btw, with -ftrapv it would mean we cannot re-order any signed arithmetic
> with respect to volatile accesses unless we can prove it does not invoke
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #11 from Martin Uecker ---
(In reply to Richard Biener from comment #9)
> (In reply to Martin Uecker from comment #8)
> > The standard specifies in 5.1.2.3p6 that
> >
> > "— Volatile accesses to objects are evaluated strictly
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #8 from Martin Uecker ---
The standard specifies in 5.1.2.3p6 that
"— Volatile accesses to objects are evaluated strictly
according to the rules of the abstract machine."
and
"This is the observable behavior of the program."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #5 from Martin Uecker ---
Different context, but also relevant:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590757.html
"The problem is there may be observable side effects on the *0 path
between the test and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #4 from Martin Uecker ---
Patch (by Martin Sebor)
diff --git a/gcc/tree-ssa-pre.c b/gcc/tree-ssa-pre.c
index ab24fa98a1f..8f437791d94 100644
--- a/gcc/tree-ssa-pre.c
+++ b/gcc/tree-ssa-pre.c
@@ -3971,6 +3971,13 @@ compute_avail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #1 from Martin Uecker ---
Godbolt link:
https://godbolt.org/z/111a7a3Y8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
Bug ID: 104800
Summary: reodering of potentially trapping operations and
volatile stores
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770
--- Comment #3 from Martin Uecker ---
Here is another example which fails on armel
extern _Complex float g(int N, int dims[N]);
void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}
during RTL pass: expand
BUG.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770
Bug ID: 103770
Summary: ICE related to VLA
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
Martin Uecker changed:
What|Removed |Added
Summary|atomic creates incorrect|atomic creates incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #9 from Martin Uecker ---
Yes the clang behavior is useful.
If we get the optimal code for types with sufficient alignment, then I do not
think a separate set of functions would be required. A programmer simply can
use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #7 from Martin Uecker ---
I do not think these functions are meant only as internal tools to implement
the language features.
We also seem to agree that the documentation implies that there should work for
all types and does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
--- Comment #15 from Martin Uecker ---
Another version of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583593.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #3 from Martin Uecker ---
The documentation:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins
"The four non-arithmetic functions (load, store, exchange, and
compare_exchange) all have
101 - 200 of 247 matches
Mail list logo
