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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #6
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #18
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.
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).
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:
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|FIXED |---
See Also|
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) =
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
Attachment #57874|0 |1
is obsolete|
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
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.
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
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
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
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112791
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #1
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
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);
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:
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #20 from Martin Uecker ---
Ah, this is how it works. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #18 from Martin Uecker ---
I think this can be closed.
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
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.
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.
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,
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
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
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
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.")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56490|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56489|0 |1
is obsolete|
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #3 from Martin Uecker ---
Thanks for reporting. I will fix this.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
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,
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
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
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
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
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
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
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
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,
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:
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #6
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
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
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" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #56
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]; }).
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102556
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110878
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
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.
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5
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.
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
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
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
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
1 - 100 of 239 matches
Mail list logo
