https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62
Bug ID: 62
Summary: signed integer overflow triggered by
std::chrono::parse
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #1 from Andrew Pinski ---
> (which makes me think of register corruption occurring here)
>The codepath is a bit convoluted, setjmp/longjmp are involved.
Which could mean it is a bug in dietlibc's setjmp/longjmp since you said it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
--- Comment #13 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #1 from Jonathan Wakely ---
This doesn't seem much different to:
std::chrono::seconds s = std::chrono::duration{2314885530818453536};
Which we can't really do much about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #3 from Jonathan Wakely ---
We could also just have a "can_hh_mm_ss" check, as I think we use hh_mm_ss in
most places where we do these conversations. Then we would just check once, not
on every cast. I don't think we want to change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #7 from Paul Eggert ---
(In reply to Alexander Monakov from comment #6)
> Are you binding the benchmark to some core in particular?
I did the benchmark on performance cores, which was my original use case. On
efficiency cores,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #4 from Thorsten Glaser ---
Its {,sig}{set,long}jmp for x32 look good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #7 from Thorsten Glaser ---
(but with this, I think it’s neither the GCC builtins, nor a change thereof,
nor anything about dietlibc that is at fault; feel free to adjust the title
accordingly)
Surrounding code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
Bug ID: 67
Summary: swapping around duplicated conditionals can produce
better code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #6 from Thorsten Glaser ---
dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it
has a switch global variable __valgrind, if setting that to 1 it uses a very
traditional loop instead, and the registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66
Bug ID: 66
Summary: gcc unnecessarily creates vector operations for
packing 32 bit integers into struct (x86_64)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).
Sorry, missed the -std=f95 flag.
Confirmed on recent master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
--- Comment #1 from Andrew Pinski ---
In this case the problem seems to be jump threading related.
If we did:
```
void f(int);
void lookup_attribute1(const char *attr_ns, int list, int t) {
short t1;
if (attr_ns) { if (list) {t1 = 0; goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64
Bug ID: 64
Summary: The error message for a literal operator accepting an
argument of the wrong type is confusing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Bug ID: 65
Summary: [13 regression] builtin strchr miscompiles on
Debian/x32 with dietlibc
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
Bug ID: 63
Summary: signed integer overflow in
std::format("{:%S}",std::chrono::duration)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #2 from Paul Dreik ---
The fmt lib had the same problem. I wrote a safe duration cast which eventually
morphed into this:
https://github.com/fmtlib/fmt/blob/9b74160817f2bc63288d2111e823a35dd3dbf234/include/fmt/chrono.h#L57-L68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #3 from Thorsten Glaser ---
Not yet, given it’s been relatively clearly tracked down to a change in GCC.
I’ll have at its setjmp/longjmp myself now, will report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #5 from Thorsten Glaser ---
I managed to isolate one specific strchr call changing which causes the
breakage to go away:
asm volatile("nop"); //401
sp = cstrchr(sp, '\0') + 1;
asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68
Bug ID: 68
Summary: a[0,1]|b[0,-1] == 0 is not reduced to a ==0 & b ==0 if
a and b are defined by comparisons
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #6 from Alexander Monakov ---
Thanks.
i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> basically ccmp expension is just ifcombine really.
> That is:
> cc = bar cmp 0
> cc = cc.eq ? ne : d1 cmp d2
> cset cc.ne
> So this is why doing a late pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61
Bug ID: 61
Summary: [13 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in riscv_print_operand, at
config/riscv/riscv.cc:4394 during build
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85097
Michał Staromiejski changed:
What|Removed |Added
CC||michal.staromiejski+gnu@gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85097
--- Comment #5 from Michał Staromiejski ---
In clang 16.0.0 it compiles w/o errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #4 from Jan Hubicka ---
So here ipa-modref declares the field dead, while ipa-prop determines its value
even if it is unused and makes it used later?
I think dead argument is probably better than optimizing out one store, so I
40 matches
Mail list logo
