++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
https://eel.is/c++draft/expr.new#8.6 says that for invalid sizes ::operator
new{,[]}
shouldn't be called (at least when not constant evaluating it), but either
throw or result in nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #20 from Jakub Jelinek ---
What still isn't committed is the C++ optimization support of #embed.
And, we need to decide what to do with the macro expansion for #embed, the
current implementation isn't conformant (but maybe WG14 will
|RESOLVED
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Because the testcase invokes UB (dereferences a NULL pointer) - d = in[0]; in
particular where in is nullptr and path isolation just adds __builtin_trap
after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117456
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439
--- Comment #4 from Jakub Jelinek ---
And the last issue is that we don't optimize the dynamic initialization to
static initialization, details in PR102876.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #18 from Jakub Jelinek ---
I think Richi didn't like it much, but my memory is fuzzy on it.
The latest version of the patch was
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588539.html
I'll need to look at IRC logs if somet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439
--- Comment #3 from Jakub Jelinek ---
There are multiple issues.
One is that we uselessly use the sub_byte_op_p case for empty_ctor_p even if it
starts and ends on byte boundary. The need for int_mode_for_size (bitlen, 0)
check is native_encod
]
|encode_tree_to_bitpos |ICE in
||encode_tree_to_bitpos
CC||jakub at gcc dot gnu.org
Priority|P3 |P2
Last reconfirmed||2024-11-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Ever
|jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Target Milestone|--- |15.0
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117401
--- Comment #3 from Jakub Jelinek ---
That doesn't really matter. Anybody who used the option in GCC 13/14 got that
deprecation message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117401
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117388
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #37 from Jakub Jelinek ---
B2I and B4I modes shouldn't exist, they aren't really boolean, they are really
partial integer modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117386
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Jakub Jelinek ---
Created attachment 59514
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59514&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #24 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #22)
> But as Jonathan says in comment 10, the replaceable operator new is shared
> by the whole program, so I don't see why we would need a per-call flag for
> the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #23 from Jakub Jelinek ---
I've just tried:
int i, j, k;
void *
foo ()
{
i = 1;
j = 2;
void *p = __builtin_operator_new (32);
j = 3;
k = i;
return p;
}
void *
bar ()
{
i = 1;
j = 2;
void *p = __builtin_malloc (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #12 from Jakub Jelinek ---
Should be fixed now for 15.1+ so far.
||jakub at gcc dot gnu.org
Keywords||error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117370
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #19 from Jakub Jelinek ---
"memory" clobber is IMO about possibly changing any user var in memory behind
the back of the compiler, not about changing whatever compiler internals stored
somewhere on the stack in stack slots that don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #9 from Jakub Jelinek ---
Doesn't need -fsanitize=address, just ensuring the _BitInt(256) var is just
8-byte aligned is enough:
struct S {
unsigned char y;
_BitInt(256) x;
} s;
__attribute__((noipa)) static void
foo (const char
||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #4 from Jakub Jelinek ---
The testcase is garbage or reduced to garbage, there are tons of UBs in it.
E.g.
int32_t *t = &e, j, k;
for (; j < 3; j++)
j is uninitialized here.
at gcc dot gnu.org |jakub at gcc dot gnu.org
Known to work||15.0
Known to fail|15.0|
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE:
|ICE: in |in
|--- |15.0
Status|UNCONFIRMED |RESOLVED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Hopefully fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117021
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #5 from Jakub Jelinek ---
(In reply to David Malcolm from comment #4)
> where arguably the type of the symbolic value should be
>unsigned char[72]
> rather than:
>unsigned char
>
> This is because the analyzer is just using
||error-recovery
CC||jakub at gcc dot gnu.org
Summary|[15 Regression] |[12/13/14/15 Regression]
|Segmentation fault in |Segmentation fault in
|permerror(unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117323
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #5 from Jakub Jelinek ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
--- Comment #5 from Jakub Jelinek ---
Slightly cleaned up:
struct C {
constexpr bool operator== (const C &b) const { return foo (); }
constexpr virtual bool foo () const = 0;
};
class A : public C {};
class B : public C {};
template
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321
--- Comment #7 from Jakub Jelinek ---
Fixed on the trunk so far.
Guess it should be eventually backported to 14/13 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #5 from Jakub Jelinek ---
Combined build is when you build gcc together with binutils (and often other
modules like gmp, mpfr, libmpc, etc.) by unpacking those into the same tree.
The toplevel configure indeed doesn't check for .base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117021
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Created attachment 59470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59470&action=edit
gcc15-pr117313.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117308
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117021
--- Comment #4 from Jakub Jelinek ---
Ah, ok, got it. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
--- Comment #14 from Jakub Jelinek ---
I don't see why it wouldn't, it uses the same code for handling % in the string
as is used for extended asm inside of functions. Nothing before that actually
parses/interprets the format string, the restric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117021
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #5 from Jakub Jelinek ---
Why do you think it is more triggerable on trunk rather than on branches?
The testcase ICEs on the 13/14 branches too, and the only reason I saw it on
the trunk is that I was considering using [[assume (EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #3 from Jakub Jelinek ---
Whatever is done, it needs to be (worst case conservatively) correct, so if it
can't or decides not to process some edge which does or might result into true
result, assume the worst (VARYING etc.).
Of cours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117209
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14/15 Regression] ICE: |[13/14 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117209
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: |[13 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression]
|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117259
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression] warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117201
Jakub Jelinek changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117201
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117288
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Jakub Jelinek changed:
What|Removed |Added
Attachment #59415|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #1 from Jakub Jelinek ---
_Z3bazj._assume.0 assume inferred range of x_2(D) (param x) = [irange] unsigned
int [9, 10] MASK 0x3 VALUE 0x8
on-exit update x_2(D) in BB2 : [irange] unsigned int [9, 10] MASK 0x3 VALUE
0x8
The _Z3bazj.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #17 from Jakub Jelinek ---
Given PR117287 I'm going to test just the #1 patch for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Keywords|build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-10-24
Status|UNCONFIRM
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, jakub at gcc dot gnu.org,
pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #16 from Jakub Jelinek ---
So, the powerpc gengtype issue during --disable-checking build with those 2
patches is about whether
gcc_assert (union_or_struct_p (kind));
in gengtype.cc (new_structure) is present or commented out, if i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Jakub Jelinek changed:
What|Removed |Added
Attachment #59416|0 |1
is obsolete|
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek ---
Created attachment 59428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59428&action=edit
gcc15-pr117201.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117201
--- Comment #13 from Jakub Jelinek ---
unsigned char a = 193;
unsigned char *b = &a;
void
foo (void)
{
unsigned char c[] = { 0, 2, 1, 1, 2, 1, 2, 2, 6, 2, 1, 1, 1, 1, 2, 2, 0,
2, 1, 1, 2, 1, 2, 2, 1, 2, 1, 1, 2, 1, 2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #13 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 59416 [details]
> gcc15-pr117249-2.patch
>
> Untested patch to change the gcc_assert definition.
Unfortunately this doesn't work, there ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117209
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #9 from Jakub Jelinek ---
Andrew, do you plan to backport this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #11 from Jakub Jelinek ---
Created attachment 59416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59416&action=edit
gcc15-pr117249-2.patch
Untested patch to change the gcc_assert definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
|invalid optimization of |optimization of
|-fma(-x,x,-z) when -O3 and |-fma(-x,x,-z) when -O3 and
|-frounding-math are used|-frounding-math are used
CC||jakub at gcc dot gnu.org
--- Comment #15 from
gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #12 from Jakub Jelinek ---
Should be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117230
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117199
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #2 from Jakub Jelinek ---
Sure, it is trunk only, introduced in r15-4375.
Would be nice if it could be handled similarly to apply_ctor_val_to_range by
creating just a single record for the whole range, just with slightly different
me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117229
--- Comment #6 from Jakub Jelinek ---
(In reply to Thomas Schwinge from comment #2)
> OK, that's going to be "fun":
> During "manual bisecting", I found that I can, for example, also make it
> PASS this way:
The h array is
const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117229
--- Comment #8 from Jakub Jelinek ---
I'd suggest the embed-100.c hack mentioned above, then you can easily shrink
the embed-1.c testcase if it still reproduces (hopefully just to the two strstr
calls or what) and similarly reduce the embed-100.
-fail, wrong-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org,
dmalcolm at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117229
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117259
--- Comment #7 from Jakub Jelinek ---
I don't think throwing more save_expr calls is the right way here.
The problem is that save_expr can just return what has been passed to it
without building a SAVE_EXPR. In some cases for the PMFs it is fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257
--- Comment #4 from Jakub Jelinek ---
Of course, I'd be afraid we'd break a lot of code if it is changed.
Note, C++11 list initialization of _Complex has been added exactly for
std::complex, see PR48760.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117256
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117259
--- Comment #6 from Jakub Jelinek ---
Slightly simplified testcase (still -fsanitize=undefined -Wuninitialized):
struct A { void foo () {} };
struct B { void (A::*b) (); B (void (A::*x) ()) : b(x) {}; };
const B c[1] = { { &A::foo } };
void
foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117229
--- Comment #1 from Jakub Jelinek ---
All of those tests are the same source (3 of them include the fourth), just
differ in used options.
Could you please
sed -i -e 's|abort ()|__builtin_printf ("%d FAIL\\n", __LINE__)|p'
c-c++-common/cpp-embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117230
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #7 from Jakub Jelinek ---
Then we could use [[assume (EXPR)]]; if the attribute is supported, that would
never evaluate the side-effects but still optimize the non-side-effect cases
and some easy side-effect cases too if inlining + V
1 - 100 of 13915 matches
Mail list logo
