https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
Bug ID: 114641
Summary: sh: fdpic optimization of function address breaks
pointer equality
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114158
--- Comment #5 from Rich Felker ---
I don't know how I ended up copying the wrong commit id, but the one I meant to
reference was 9c560cf23996271ee26dfc4a1d8484b85173cd12.
Actually, I do know now. I got it out of the gitweb url which gratuitous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114158
Bug ID: 114158
Summary: Wrong FDPIC special-casing in crtstuff produces
invalid pointer in init_array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114060
--- Comment #2 from Rich Felker ---
How could there be such a contract? In order to call any other function, the
GOT address of the callee needs to be loaded, replacing the caller's value,
which must be spilled and reloaded if it's needed again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114060
Bug ID: 114060
Summary: asm constraints getting GOT address for ARM/FDPIC look
wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
--- Comment #6 from Rich Felker ---
I'm aware of the allowance to accept "other forms". It's unfortunately
underspecified (does the implementation need to be specific in what forms?
document them per the normal rules for implementation-defined b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
Rich Felker changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
--- Comment #1 from Rich Felker ---
FWIW -pedantic also does not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653
Bug ID: 113653
Summary: Failure to diagnose use of (non-constant-expr) const
objects in static initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #62 from Rich Felker ---
The process described there would have to end at least N bits before the end of
the destination buffer. The point was that it would destroy information
internal to the buffer at each step along the way, before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #60 from Rich Felker ---
Nobody said anything about writing past end of buffer. Obviously you can't do
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #57 from Rich Felker ---
I think one could reasonably envision an implementation that does some sort of
vector loads/stores where, due to some performance constraint or avoiding
special casing for possible page boundary past the end o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #44 from Rich Felker ---
My naive expectation is that "if ((uintptr_t)src == 0x400400)" is and should be
UB, but I may be misremembering the details of the formalism by which the spec
for restrict is implemented.
If so, that's kinda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #42 from Rich Felker ---
> I'm not saying that such an implementation will be a good idea, but just a
> remark: You could, in fact, keep restrict for the arguments in this case,
> because the object pointed to by src and dest is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #37 from Rich Felker ---
Also: has anyone even looked at what happens if a C memcpy with proper use of
restrict gets LTO-inlined into a caller with GCC-generated memcpy calll where
src==dest? That sounds like a case likely to blow up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #36 from Rich Felker ---
> the assembly generated by the current implementations already supports that
> case.
Our memcpy is not written in asm but in C, and it has the restrict qualifier on
src and dest. This entitles a compiler to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #28 from Rich Felker ---
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
Far less than a call to memmove (which necessarily has something comparable to
that and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #26 from Rich Felker ---
> The only reasonable fix on the compiler side is to never emit memcpy but
> always use memmove.
No, it can literally just emit (equivalent at whatever intermediate form of):
cmp src,dst
je 1f
call memcpy
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #24 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849
--- Comment #2 from Rich Felker ---
I agree that volatile isn't the best way to handle memcpy suppression for other
purposes - it was just one of the methods I experimented with that led to me
discovering this issue, which I found surprising and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849
Bug ID: 111849
Summary: GCC replaces volatile struct assignments with memcpy
calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #7 from Rich Felker ---
Second one filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
Bug ID: 107115
Summary: Wrong codegen from TBAA under stores that change
effective type?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #1 from Rich Felker ---
There's also a potentially related test case at https://godbolt.org/z/jfv1Ge6v4
- I'm not yet clear on whether it's likely to have the same root cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Bug ID: 107107
Summary: Wrong codegen from TBAA when stores to distinct
same-mode types are collapsed?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #11 from Rich Felker ---
Are you sure? If pure/const discovery is no longer applied to weak definitions,
it shouldn't be able to propagate to a non-inlined caller. Of course the fix
may be incomplete or not working, which I guess we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #9 from Rich Felker ---
Can you provide a link to the commit that might have fixed it? I imagine it's
simple enough to backport, in which case I'd like to do so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #7 from Rich Felker ---
> Do weak aliases fall under some implicit ODR here?
The whole definition of "weak" is that it entitles you to make a definition
that will be exempt from ODR, where a non-weak definition, if any, replaces it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #30 from Rich Felker ---
This is a critical codegen issue. Is it really still not fixed in 9.4.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98555
--- Comment #5 from Rich Felker ---
Ping. Could this be solved without the need for target-specific logic by, in
some earlier layer, transforming entirely empty function bodies to
__builtin_trap()? (And thereby relying on the target's implementat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99491
Bug ID: 99491
Summary: [mips64] over-strict refusal to emit tail calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #46 from Rich Felker ---
It's a standard and completely reasonable assumption that, if you statically
linked libstdc++ into your shared library, the copy there is for *internal use
only* and cannot share objects of the standard librar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #44 from Rich Felker ---
Uhg. I don't know what kind of retroactive fix for that is possible, if any,
but going forward this kind of thing (assumptions that impose ABI boundaries)
should not be inlined by the template. It should just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #42 from Rich Felker ---
I'm confused why this is an ABI boundary at all. Was the old implementation of
std::call_once being inlined into callers? Otherwise all code operating on the
same once object should be using a common implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98555
--- Comment #3 from Rich Felker ---
> Due to "undefined behavior" of course means this isn't unexpected
That would only be the case if undefined behavior were reached during
execution, but it's not. This bug affects programs that do not and cann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98555
Bug ID: 98555
Summary: Functions optimized to zero length break function
pointer inequality
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97431
--- Comment #1 from Rich Felker ---
Do you have a complete disassembly of the function it crashed in and register
dump at the point of crash? That would help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #26 from Rich Felker ---
Is that complete, or is it unclear whether there are code paths other than
builtin memcmp by which this is hit? Am I correct in assuming that with builtin
memcmp expansion returning NULL_RTX, GCC always expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #24 from Rich Felker ---
The fixes do not seem trivial to backport; lots of conflicts. It would be
really helpful to have versions of the patch that are minified and applicable
to all affected versions that might be shipping in distro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #20 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
--- Comment #5 from Rich Felker ---
The whole point of __has_builtin is to let you avoid the configure-time checks
on compilers that support __has_builtin. If __has_builtin doesn't actually
work, it's pointless that it even exists and indeed ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #7 from Rich Felker ---
Indeed, the direct clock_gettime syscall stuff is just unnecessary on any
modern system, certainly any time64 one. I read the patch briefly and I don't
see anywhere it would break anything, but it also wouldn't
43 matches
Mail list logo
