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=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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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=14441
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #11
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=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
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 #7 from Rich Felker ---
Can you provide a citation for that?
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
: 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
: 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
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
: 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
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
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
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=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.
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
: 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=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
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 #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=96952
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #3
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=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=12306
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #41 from Rich Felker ---
> Josef Wolf mentioned that he ran into this on the gcc-help mailing list here:
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg00079.html
I don't think that's an instance of this issue. It's normal/expected th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #8 from Rich Felker ---
> Floating point types are not guaranteed to support infinity by the C standard
Annex F (IEEE 754 alignment) does guarantee it, and GCC aims to implement this.
This issue report is specific to target sh*-*-* w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #10 from Rich Felker ---
GCC can choose the behavior for any undefined behavior it wants, and GCC
absolutely can make transformations based on behaviors it guarantees or that
Annex F guarantees on targets for which it implements the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #8 from Rich Felker ---
> Then LLVM has more to fix. Constraints never look at types. A register
> constraint (like "wa") simply says what registers are valid.
This is blatently false. For x86:
int foo(int x)
{
__asm__("" : "+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #9 from Rich Felker ---
And ok, to be more productive rather than just angry about the regression, if
you really think the "ws" constraint should be removed, what is the proper
preprocessor/configure-time check to determine the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #13 from Rich Felker ---
> That does not look at types. It complains that "x" lives in memory,
> while the constraint requires a register (a floating point register).
That does not sound accurate. An (in this case lvalue since it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #14 from Rich Felker ---
> So, if "ws" has been documented in the user documentation, perhaps just
> (define_register_constraint "ws" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
> "Compatibility alias to wa")
> could be added? If it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #16 from Rich Felker ---
> Using "ws" in inline asm never made sense. It was always the same as
> "wa", for all cases where either could be used in inline asm at all.
It made sense insomuch as it was documented and was the most clea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #18 from Rich Felker ---
> So use "wa" instead of "ws" in the two files you use it, and can we get
> on with our lives?
Translation: Introduce a regression on all existing versions of clang because
GCC broke a documented public inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #20 from Rich Felker ---
> After both musl and LLVM are fixed, if you then *still* feel you
> need "ws", then we can talk of course. Deal?
No, it's not a deal. Your proposal is *breaking all currently-working versions*
of clang beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #22 from Rich Felker ---
And to be clear, pretty much all gcc versions from 3.4.6 to present, and all
clang/LLVM versions since they fixed some critical bugs (like -ffreestanding
not working, which was a show-stopper), are supported c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #24 from Rich Felker ---
> Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
Nothing is broken on our side here. We are using the documented functionality
from gcc 9 going all the way back to whatever versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #27 from Rich Felker ---
> Have I already mentioned that if any program "in the wild" will use "ws" with
> GCC 10, then of course we can add an alias (to "wa") for it? No program
> should
> use "ws" in inline assembler, ever, but if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #29 from Rich Felker ---
For reference, here are the affected functions in musl (fmax, fmaxf, fmin,
fminf):
https://git.musl-libc.org/cgit/musl/tree/src/math/powerpc64?id=v1.1.24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #34 from Rich Felker ---
> Does musl not support BE? There is nothing about this that is LE-only
> as far as I can see.
For powerpc64, musl supports both BE and LE, and uses "elfv2" ABI for both
(since it was not present as a target
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
void foo()
{
int a[1,1];
}
produces:
error: expected ']' before ',' token
despite the declaration bei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92571
--- Comment #1 from Rich Felker ---
Note that I put it in a function just because VLA is invalid at file scope, and
I wanted to be clear that this bug is independent of the invalidity of VLA at
file scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92571
Rich Felker changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579
--- Comment #6 from Rich Felker ---
Ping.
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5
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=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
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 #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=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=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 #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 #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 #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=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 #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 #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=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 #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=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=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 #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 #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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
--- Comment #6 from Rich Felker 2013-02-12 07:08:14
UTC ---
That sounds highly doubtful. The sigcontext is (necessarily) on the stack, so
the only way accessing past the end of sigcontext could fault is if the access
were so far beyond the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
--- Comment #8 from Rich Felker 2013-02-12 15:27:58
UTC ---
Is there nothing internal in the sigcontext structure that distinguishes the
version?
Making the reference to __libc_stack_end weak won't help. If the symbol is
undefined, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
Bug #: 54232
Summary: For x86 PIC code, ebx should be spillable
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
--- Comment #1 from Rich Felker 2012-08-12 04:57:07
UTC ---
By the way, the code that inspired this report is crypt_blowfish.c and the
corresponding asm by Solar Designer. We've been experimenting with performance
characteristics while integratin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
--- Comment #3 from Rich Felker 2012-08-13 13:59:17
UTC ---
> I think the GOT is introduced too late to do any fancy ananlysis
> on whether we need it or not.
This may be true, but if so, it's a highly suboptimal design that's hurting
performanc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54395
Bug #: 54395
Summary: DWARF tables should go in non-mapped section unless
exceptions are enabled
Classification: Unclassified
Product: gcc
Version: unknown
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54395
--- Comment #2 from Rich Felker 2012-08-28 23:38:49
UTC ---
I can see the argument that some users would want/need that, and perhaps even
that you want backtrace() to be available in the default configuration, but I
still think there should be a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54395
--- Comment #4 from Rich Felker 2012-08-28 23:52:24
UTC ---
Would you care to elaborate on how it would break anything? They're already
easily removable with -fno-asynchronous-unwind-tables -fno-unwind-tables. The
problem is just that it's imposs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54395
--- Comment #6 from Rich Felker 2012-08-29 12:43:23
UTC ---
I seem to remember gcc -g -fno-asynchronous-unwind-tables -fno-unwind-tables
producing a warning that these options are incompatible and that debugging will
not work, but at the moment i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
Bug #: 55012
Summary: Protected visibility wrongly uses GOT-relative
addresses
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
--- Comment #1 from Rich Felker 2012-10-21 22:06:39
UTC ---
I'm not sure whether the fix should be in gcc/varasm.c,
default_binds_local_p_1(), or in the config/i386/predicates.md,
local_symbolic_operand predicate.
In the former, all non
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #19
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
This issue is almost identical to bug #23221, but affects functions whose
executions end with a call to a noreturn function rather than a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #1 from Rich Felker ---
One more thing: I would be happy with either of two solutions, either:
(1) Checking the canary before calling a noreturn function, just like
performing a check before a tail-call, or
(2) Eliminating the dead-c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245
--- Comment #3 from Rich Felker ---
We already do that; the patch is in the musl-cross repo here:
https://bitbucket.org/GregorR/musl-cross or
https://github.com/GregorR/musl-cross
However, we want the stack-protector behavior for GCC with musl t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470
Bug #: 50470
Summary: gcc does not respect -nostdlib with regard to search
paths
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470
--- Comment #2 from Rich Felker 2011-09-21 01:34:29
UTC ---
The sysroot features may be nice but they're not a substitute for being able to
eliminate the default library search path. For example, when using sysroot,
-L/new/path will prepend the s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134
--- Comment #8 from Rich Felker 2012-04-28 23:14:57
UTC ---
I agree, sadly, that WONTFIX is probably the most appropriate action. At least,
like Andrew said, we're getting to the point where assuming it's okay to build
with -msse2 and -mfpmath=ss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593
--- Comment #7 from Rich Felker 2012-04-28 23:21:51
UTC ---
This bug seems to have been fixed with the addition of the
-fexcess-precision=standard feature, which is now set by default with -std=c99
or c11, and which disables the builtin sqrt base
1 - 100 of 294 matches
Mail list logo
