https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99315
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #23 from Jakub Jelinek ---
The make check results also looked ok on all 3 arches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
--- Comment #4 from Jakub Jelinek ---
I can actually reproduce e.g. on x86_64-linux with:
extern void fn2(void);
extern void fn3(int);
int a, b;
void fn1() {
int c;
short d;
switch (a) {
case 22000:
fn2();
case 22300:
b = 0;
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-03-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
--- Comment #3 from Jakub Jelinek ---
constexpr doesn't imply anything like that.
constexpr variables can still be odr-used, their address taken, compared etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
--- Comment #9 from Jakub Jelinek ---
Created attachment 50279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50279&action=edit
gcc11-pr95757.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #2 from Jakub Jelinek ---
I'm afraid we have multiple problems with -mavx512vl -mno-avx512bw (are there
any CPUs with that combination of ISA sets though?).
In r7-618-g9bdf001b7a2232753e4a92582218bb4f24c8d809 I've fixed the 16-byte
vp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99315
--- Comment #2 from Jakub Jelinek ---
Also, I'd add that
#pragma message "foo " "bar " "baz"
already works fine because it is done in the FE and not in libcpp and so it can
use pragma_lex under the hood to do this.
And, it also has
if (pragma_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
--- Comment #3 from Jakub Jelinek ---
Wouldn't it be better to remove the mark_addressable call from build_va_arg and
call {c,cxx}_mark_addressable in the callers instead.
That way we'd also e.g. diagnose invalid (on i686-linux):
register __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 95757, which changed state.
Bug 95757 Summary: [11 regression] missing warning in
gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
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=99339
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959
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=99342
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #3 from Jakub Jelinek ---
Created attachment 50288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50288&action=edit
gcc11-pr99321.patch
Untested fix for the peephole2.
The rest will be done separately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
--- Comment #8 from Jakub Jelinek ---
The stdarg pass already performs similar analysis, see e.g.
reachable_at_most_once function, because if those aren't used in loops and
escape, it computes not just whether the function uses some fp or gpr arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE: |[10 Regression] ICE:
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090
--- Comment #7 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
--- Comment #4 from Jakub Jelinek ---
Created attachment 50293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50293&action=edit
gcc11-pr99325.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
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=99378
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
--- Comment #4 from Jakub Jelinek ---
Fixed on the glibc side:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f0419e6a10740a672b28e112c409ae24f5e890ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Bug ID: 99388
Summary: Invalid debug info for __fp16
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-03-04
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #2 from Jakub Jelinek ---
The above patch changes:
--- pr99388.s 2021-03-04 15:47:31.151944020 +0100
+++ pr99388.s 2021-03-04 15:51:51.404086604 +0100
@@ -267,18 +267,21 @@ foo:
.byte 0x4 // uleb128 0x4; Location exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] invalid |[10 Regression] invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99383
--- Comment #4 from Jakub Jelinek ---
That was an intentional change, see the PR.
With -fPIC/-fPIE, when the switch isn't optimized into a table of values but
kept as a switch, it doesn't need runtime relocations on many targets. Just
try to com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99383
--- Comment #5 from Jakub Jelinek ---
Combining the separate strings into a single one if they have the same length
and aren't many would have the disadvantage that the returned value then
wouldn't be pointer equal to constant literal containing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99383
--- Comment #6 from Jakub Jelinek ---
Note, it could be even POINTER_DIFF_EXPR of the value and the first value in
the table or something similar.
The generic code would need to ensure for flag_pic that either reloc is
null_pointer_node for all e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99383
--- Comment #7 from Jakub Jelinek ---
The code would need to also verify the constants are all pointers, just having
a relocation nested somewhere in a struct wouldn't work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
--- Comment #7 from Jakub Jelinek ---
Ah, but __digits is one smaller than we want for signed types.
Plus before C++20 the left shifts of negative values are UB?
Maybe all the rotates should be implemented using the corresponding unsigned
types..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
--- Comment #8 from Jakub Jelinek ---
so
using __unsigned_type = __make_unsigned<_Tp>::__type;
constexpr auto _Nd = __gnu_cxx::__int_traits<__unsigned_type>::__digits;
const auto __r = static_cast(__s);
const auto __y = st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
Jakub Jelinek changed:
What|Removed |Added
Attachment #50303|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
Jakub Jelinek changed:
What|Removed |Added
Attachment #50304|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
--- Comment #14 from Jakub Jelinek ---
I believe std::__rot{l,r} can be used even in C++14 and if constexpr is only
supported in C++17 and later.
With optimizations enabled (_Nd & (_Nd - 1)) == 0 will optimize into constant
anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
--- Comment #15 from Jakub Jelinek ---
Could be if _GLIBCXX17_CONSTEXPR (...)
sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
Bug ID: 99405
Summary: Rotate with mask not optimized on x86 for QI/HImode
rotates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #30 from Jakub Jelinek ---
(In reply to Richard Biener from comment #29)
> I suppose the reason is that there's two unrelated insns between the
> xmm0 = cx:DI and the vec_concat. Which would hint that we somehow
> need to not match t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
Jakub Jelinek changed:
What|Removed |Added
Attachment #50306|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406
--- Comment #4 from Jakub Jelinek ---
Created attachment 50309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50309&action=edit
gcc11-pr99406.patch
Like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #4 from Jakub Jelinek ---
Any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
--- Comment #5 from Jakub Jelinek ---
The valid C code if it is correct without UB and is pattern matched is
definitely better than some intrinsics, it is portable and can be optimized
generally sooner and better than the intrinsics.
Just be warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99287
--- Comment #4 from Jakub Jelinek ---
(In reply to Patrick Palka from comment #3)
> IIUC, those two types are actually the same, it's just that one of them was
> obtained through the char_type alias, and it seems debug_tree prefers to
> show the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99287
--- Comment #5 from Jakub Jelinek ---
Or perhaps another option would be instead of
return mod;
do
return cxx_eval_constant_expression (ctx, mod, false, non_constant_p,
overflow_p);
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
--- Comment #3 from Jakub Jelinek ---
void bar (void *);
void
foo (void)
{
bar (&&lab);
#pragma omp parallel
for (;;)
;
lab:;
}
ICEs likely since r0-88143-gb357f682db35f4431e3011e7486a0ac865686e3e
Not really sure what to do if we find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #6 from Jakub Jelinek ---
Created attachment 50311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50311&action=edit
gcc11-pr99321.patch
One possible way to fix the above testcase (but not the many other insns, like
maybe:
vdbps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Jakub Jelinek changed:
What|Removed |Added
Attachment #50311|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99363
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #2 from Jakub Jelinek ---
I see the function is called before selecting a particular alternative, so
perhaps it means to care only about constraints like "X" and "" and not say
that mixed with other constraints etc.
But, shouldn't the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
Bug 99405 depends on bug 99396, which changed state.
Bug 99396 Summary: std::rotl and std::rotr Does not convert into ROTATE on the
gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429
--- Comment #3 from Jakub Jelinek ---
Slightly reduced:
namespace std {
struct strong_ordering {
int _v;
constexpr strong_ordering (int v) :_v(v) {}
constexpr operator int (void) const { return _v; }
static const strong_ordering less;
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99431
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94130
Jakub Jelinek changed:
What|Removed |Added
CC||jonathon.reinhart at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458
Bug ID: 99458
Summary: libgo doesn't build against latest glibc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
Bug ID: 99459
Summary: [11 Regression] Many coroutines regressions on
armv7hl-linux-gnueabi
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
--- Comment #2 from Jakub Jelinek ---
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/663801.html
r11-7517 was good, while
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/663970.html
r11-7537 was already bad.
The coroutines.cc c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
--- Comment #3 from Jakub Jelinek ---
p debug_tree (dummy)
>
side-effects
arg:0
public unsigned type_6 SI
size
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
--- Comment #4 from Jakub Jelinek ---
So perhaps:
2021-03-08 Jakub Jelinek
PR c++/99459
* coroutines.cc (build_co_await): Look through NOP_EXPRs in
build_special_member_call return value to find the CALL_EXPR.
--- gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459
--- Comment #8 from Jakub Jelinek ---
I think STRIP_NOPS strips the nops only if the outer and inner type have the
same TYPE_MODE, that is not the case here, the outer type is VOID_TYPE, the
inner type is some POINTER_TYPE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99418
--- Comment #4 from Jakub Jelinek ---
Asan can't by design detect neither #c0 nor #c1, only ubsan can.
The reason why ubsan has that off by one stuff is that in C/C++,
&mas[n - 1][m] is not undefined behavior, only mas[n - 1][m] is.
And with clas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456
--- Comment #5 from Jakub Jelinek ---
Created attachment 50330
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50330&action=edit
gcc11-pr99456.patch
On one side, we have still accepts-invalid issue, e.g. in your testcase:
constexpr inline C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456
--- Comment #6 from Jakub Jelinek ---
Another thing is that perhaps we should be rejecting reinterpret_cast only in
the
pedantic constant expression evaluation mode, not when we allow extensions and
fold as much as we can. So something like (inc
1 - 100 of 12374 matches
Mail list logo
