https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #10
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Created attachment 57904
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57904&action=edit
rough fix
For FDPIC target
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
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Commit 11189793b6ef60645d5d1126d0bd9d0dd83e6583 introduced wrong special-casing
of FDPIC to __do_global_dtors_aux
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
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Reading the code added for unwind-pe.h for FDPIC, I came across the ARM
implementation that uses FDPIC_REGNUM as an input constraint to
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.
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
The following is a constraint violation:
int foo()
{
static const int x = 1;
static const int y = x; // not a
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
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
On at least some targets where GCC compiles struct assignments to memcpy calls,
this pattern is also used when the struct objects involved
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Created attachment 53648
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53648&action=edit
original test case by s
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.
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Created attachment 53646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53646&action=edit
original te
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
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
mips_function_ok_for_sibcall refuses to generate sibcalls (except locally) on
mips64 due to %gp being call-saved and the possibility that the callee is a
lazy resolver
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Given a function such as
void foo() { __builtin_unreachable(); }
or optimized to such due to unconditional undefined
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #4 from Rich Felker ---
Actually I didn't see it, I just saw Florian added to CC and it reminded me of
the issue, which reminded me I needed to check this for riscv32 issues with the
riscv32 port pending merge. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #2 from Rich Felker ---
Rather than #if defined(SYS_futex_time64), I think it should be made:
#if defined(SYS_futex_time64) && SYS_futex_time64 != SYS_futex
This is in consideration of support for riscv32 and future archs without le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #4 from Rich Felker ---
The related issue I meant to link to is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 which is for x87, but the
equivalent happens on m68k due to FLT_EVAL_METHOD being 2 here as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #3 from Rich Felker ---
Yes,I'm aware m68k has FLT_EVAL_METHOD=2. That's not license for *functions* to
return excess precision. The language specification is very clear about where
excess precision is and isn't kept, and here it must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #1 from Rich Felker ---
I wonder if the fact that GCC thinks the output of the insn is already double
suggests other similar bugs in the m68k backend, though... If extended
precision were working correctly, I'd think it would at least
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
On ISA levels below 68040, __builtin_sqrt expands to code that performs an
extended-precision sqrt operation rather than a double-precision one. Not only
does this give the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #3 from Rich Felker ---
In addition to a fix, this is going to need a workaround as well. Do you have
ideas for a clean one? A dummy asm in the dummy function to kill pureness is
certainly a big hammer that would work, but it preclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #2 from Rich Felker ---
Wow. It's interesting that we've never seen this lead to incorrect codegen
before, though. All weak dummies should be affected, but only in some cases
does the pure get used to optimize out the external call.
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Created attachment 48689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48689&action=edit
test case
Here is a case that came up in WIP code on mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249
--- Comment #2 from Rich Felker ---
Indeed, using an extra zero pad byte could bump the stack frame size by 4 or 8
or 16 bytes, or could leave it unchanged, depending on alignment prior to
adding the byte and the alignment requirements of the tar
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
At least glibc presently stores a null byte in the first byte of the stack
protector canary value, so that string-based read
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
#include
struct foo {
uint32_t x:20;
};
int bar(struct foo f)
{
if (f.x) {
uint32_t y = (uint32_t)f.x*4096;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #12 from Rich Felker ---
There's some awful hand-written asm in libgcc/config/arm/ieee754-df.S replacing
the standard libgcc2.c versions; that's the problem. But in order to use the
latter it would need to be compiled with -mfloat-abi
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
GCC emits a call to __aeabi_l2d to convert from long long to double. This is
invalid for hardfloat ABI because it does not
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Test case:
#include
uint16_t a[];
uint64_t f(int i)
{
return a[i]*16;
}
Produces:
movslq %edi, %rdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #8 from Rich Felker ---
OK, I think it's in 6.3.1.1 Boolean, characters, and integers, ΒΆ2, but somewhat
poorly worded:
"The following may be used in an expression wherever an int or unsigned int may
be used:
- An object or expressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #7 from Rich Felker ---
Can you provide a citation for that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #5 from Rich Felker ---
No, GCC's treatment also seems to mess up bitfields smaller than int and fully
governed by the standard (no implementation-defined use of non-int types):
struct foo {
unsigned x:31;
};
struct foo bar = {0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #2 from Rich Felker ---
So basically the outcome of DR120 was allowing the GCC behavior? It still seems
like a bad thing, not required, and likely to produce exploitable bugs (due to
truncation of arithmetic) as well as very poor-perf
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Test case:
struct foo {
unsigned long long low:12, hi:52;
};
unsigned long long bar(struct foo *p)
{
return p->hi*4096;
}
Should generate only a mask off of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14441
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #35 from Rich Felker ---
> Oh, your real code is different, and $10 doesn't work for that? I see.
No, the real code is exactly that. What you're missing is that the kernel,
entered through syscall, has a jump back to the addu after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #33 from Rich Felker ---
> An asm clobber just means "may be an output", and no operand will be assigned
> a register mentioned in a clobber. There is no magic.
This, plus the compiler cannot assume the value in any of the clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #30 from Rich Felker ---
> You need to make $r10 not a clobber but an inout, of course. And not
That's not a correct constraint, because it's clobbered by the kernel between
the first syscall instruction's execution and the second e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #28 from Rich Felker ---
And it looks like I actually hit this exact bug back in 2012 but misattributed
it:
https://git.musl-libc.org/cgit/musl/commit/?id=4221f154ff29ab0d6be1e7beaa5ea2d1731bc58e
I assumed things went haywire from u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #27 from Rich Felker ---
Also just realized:
> Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable
solution for you?
It doesn't even work, because the syscall clobbers basically all call-clobbered
register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #26 from Rich Felker ---
Indeed, I just confirmed that binding the n input to a particular register
prevents the "i" part of the "ir" alternative from working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #24 from Rich Felker ---
The reasons I was hesitant to force n to a particular register through an extra
register __asm__ temp var was that I was unsure how it would interact with the
"i" constraint (maybe prevent it from being used?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #22 from Rich Felker ---
What should I call the new bug? The description sounds the same as this one,
and it's fixed in gcc 9.x, just not earlier versions, so it seems to be the
same bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #19 from Rich Felker ---
> This looks like bad inline asm. You seem to be using $2, $8, $9 and $sp
> explicitly and not letting the compiler know you are using them.
$2, $8, and $9 are all explicitly outputs. All changes to $sp are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #16 from Rich Felker ---
> I didn't say this very well... The only issue is using the same hard
> register for two different operands. You don't need to do this for
> syscalls (and you do not *need* that *ever*, of course).
I hit t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #12 from Rich Felker ---
> You can work around it on older GCC by simply not using a register var
> for more than one asm operand, I think?
Nope. Making a syscall inherently requires binding specific registers for all
of the inputs/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #32 from Rich Felker ---
> A slightly modified version of the example, showing the issue with GCC 5 to 7
> (as the noipa attribute directive has been added in GCC 8):
Note that __attribute__((__weak__)) necessarily applies noipa and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #14 from Rich Felker ---
Indeed, without Anenx F, division by zero is UB, so it's fine to do anything if
the program performs division by zero. So we need examples without division by
zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #12 from Rich Felker ---
To me the meaning of internal consistency is very clear: that the semantics of
the C language specification are honored and that the only valid
transformations are those that follow the "as-if rule". Since C w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #10 from Rich Felker ---
I don't think it's at all clear that -fno-signed-zeros is supposed to mean the
programmer is promising that their code has behavior independent of the sign of
zeros, and that any construct which would be influ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #25 from Rich Felker ---
I think standards-conforming excess precision should be forced on, and added to
C++; there are just too many dangerous ways things can break as it is now. If
you really think this is a platform of dwindling re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #2 from Rich Felker ---
I think the underlying issue here is just that -mpc64 (along with -mpc32) is
just hopelessly broken and should be documented as such. It could probably be
made to work, but there are all sorts of issues like fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #19 from Rich Felker ---
Test case provided by Szabolcs Nagy showing that GCC does seem to spill right
if it can't assume there's no excess precision to begin with:
double h();
double ff(double x, double y)
{
return x+y+h();
}
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #18 from Rich Felker ---
It was just pointed out to me that this might be an invalid test since GCC
assumes (correctly or not) that the return value of a function does not have
excess precision. I'll see if I can make a better test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #17 from Rich Felker ---
And indeed you're right that GCC does it wrong. This can be seen from a minimal
example:
double g(),h();
double f()
{
return g()+h();
}
where gcc emits fstpl/fldp around the second call rather than fstpt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #16 from Rich Felker ---
> And GCC does not do spills in this format, as see in bug 323.
In my experience it seems to (assuming -fexcess-precision=standard), though I
have not done extensive testing. I'll check and follow up.
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #9 from Rich Felker ---
Indeed, I don't think the ABI says anything about this; a bug against the psABI
should probably be opened.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #14 from Rich Felker ---
> No problems: FLT_EVAL_METHOD==2 means "evaluate all operations and constants
> to the range and precision of the long double type", which is what really
> occurs. The consequence is indeed double rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #7 from Rich Felker ---
I'll inquire about it. Note that F.6 already requires this for C functions; the
loophole is just that the implementation itself does not inherently have to
consist of C functions.
If it's determined that C won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #12 from Rich Felker ---
Note that -fexcess-precision=standard is not available in C++ mode to fix this.
However, -ffloat-store should also ensure consistency to the optimizer
(necessary to prevent this bug, and other variants of it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #214 from Rich Felker ---
I'm not particular in terms of the path it takes as long as this gets back to a
status where it's on the radar for fixing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #211 from Rich Felker ---
If new reports are going to be marked as duplicates of this, then can it please
be moved from SUSPENDED status to REOPENED? The situation is far worse than
what seems to have been realized last this was worked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #210 from Rich Felker ---
If new reports are going to be marked as duplicates of this, then can it please
be moved from SUSPENDED status to REOPENED? The situation is far worse than
what seems to have been realized last this was worked
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Attempting to use -fexcess-precision=standard with g++ produces:
cc1plus: sorry, unimplemented: '-fexcess-precision=standard&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #27
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Presently stack protector functionality depends on making a call to
__stack_chk_fail (possibly via __stack_chk_fail_local to avoid PLT-call-ABI
constraint in the
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Created attachment 47704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47704&action=edit
simple fix, not necessarily right for upstream
Th
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
The configure logic for libstdc++ is choosing to make direct clock_gettime
syscalls (via syscall()) rather than
1 - 100 of 293 matches
Mail list logo
