https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #10 from Dale Weiler ---
New test case without UB still exhibits the behavior
#include
#include
typedef union {
unsigned char as_bytes[64];
unsigned long long as_chunks[64 / sizeof(unsigned long long)];
} Block;
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #8 from Dale Weiler ---
Yeah, you can add another `while (j < 64) block.as_bytes[j] = 0;` to the end if
you want. I really should've done a better job reducing it so as not to create
uninitialized memory. You can also just memset the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #5 from Dale Weiler ---
I should note that there is a byte in-between these two pieces of code I
removed
for (; j < i; j++) block.as_bytes[j] = argv[0][j];
block.as_bytes[j] = 0x01; // I removed this line
while (++j &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #3 from Dale Weiler ---
> You don't have to share, but I find it useful to know where stuff was reduced
> from. Was it a public library? If so, what? It is OK to not answer.
It's the inner part of the Tiger Hash cryptographic hash
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: weilercdale at gmail dot com
Target Milestone: ---
I've isolated what appears to be an unsound __builtin_memset optimization
applied b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #7 from Dale Weiler ---
Yeah the code example is invalid, there is a reference to a temporary,
decltype(auto) on *ptr produces reference type, somehow I thought it produced
the value type, sorry for the confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
Dale Weiler changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #5 from Dale Weiler ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2)
> > > Ah, passing `T&` here instead of T does appear to avoid the issue, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #4 from Dale Weiler ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Dale Weiler from comment #2)
> > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > question now becomes why does -fsanitize=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #2 from Dale Weiler ---
(In reply to Andrew Pinski from comment #1)
> f.0_1 = f_8(D);
> tuple = t;
> _11 = &tuple.__ts#2;
> tuple ={v} {CLOBBER};
>
>
> template
> constexpr decltype(auto) get(T tuple) { return *tuple(Get{})
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: weilercdale at gmail dot com
Target Milestone: ---
Created attachment 51191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51191&action=edit
minimized te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83367
--- Comment #5 from Dale Weiler ---
Except they are referenced via their this pointer (which should alias the
static storage in that translation unit). I don't see how this is any different
than having a static variable in a translation unit and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83367
--- Comment #3 from Dale Weiler ---
(In reply to Richard Biener from comment #2)
> Try -fno-lifetime-dse?
Tried that, same issue.
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: weilercdale at gmail dot com
Target Milestone: ---
Created attachment 42835
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42835&action=edit
I've combined three files here because Bugzi
14 matches
Mail list logo
