https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117359
--- Comment #14 from H. Peter Anvin ---
This is something that should be documented, if it is the construct to be
relied on to have this effect.
In the Linux kernel it has also been used to force the frame pointer to be set
up, but that feels f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117311
--- Comment #4 from H. Peter Anvin ---
Again, any recommendations for a construct (current or future) that *can* be
relied upon?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #15 from H. Peter Anvin ---
Odd. When I added a read flag intrinsic to my test case, it prevented the red
zone from being used. If it clobbers the redzone, then that's obviously a very
serious problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #14 from H. Peter Anvin ---
I am assuming the cases Uroš are talking about are constrained by a separate
software convention.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #13 from H. Peter Anvin ---
Yes, you have to be able to "reserve" (clobber) the entire redzone (128 bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #9 from H. Peter Anvin ---
So this sounds like it would solve additional problems, which may very well
make it worthwhile.
I just want to reiterate that for the inline assembly case specifically, just
doing the "heavy hammer" thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #7 from H. Peter Anvin ---
Created attachment 59489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59489&action=edit
Test case assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #6 from H. Peter Anvin ---
Created attachment 59488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59488&action=edit
Test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #4 from H. Peter Anvin ---
You would think so, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #16 from H. Peter Anvin ---
Except there is no load or store anywhere (see the case on comment 12), so I
don't understand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #16 from H. Peter Anvin ---
Well, if that is the way you feel about it. It is certainly different from the
messages we get in other situations, so it is a bit confusing to me.
It isn't *that* unusual that you know a priori that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117311
--- Comment #3 from H. Peter Anvin ---
It does, in fact, work just fine under -O0, although it will redundantly
manifest the frame pointer in a different register (which is not a problem.)
Now, it would seem to me that if this *isn't* something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #2 from H. Peter Anvin ---
I did state that the current kernel ABI doesn't *currently* use the red zone.
However, in the future, FRED exception handling *would* allow the kernel to use
the red zone.
There isn't really a good alterna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #12 from H. Peter Anvin ---
Certainly. This is *not* only used by copy_*_user (or {get,put}_user for that
matter), here is an example from msr.h:
static inline unsigned long long native_read_msr_safe(unsigned int msr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #14 from H. Peter Anvin ---
Note: comment 13 is not intended to be rhetorical but is a genuine question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #13 from H. Peter Anvin ---
When you say "should be done in an exceptional way", could you please clarify
what you mean? I'm not sure I follow you there? Are you saying we should be
asking for compiler support?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
H. Peter Anvin changed:
What|Removed |Added
Summary|RFE: builtins for N*N -> 2N |RFE: builtin 2N/N -> N
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
When compiling with red zone, an inline assembly routine using push, call, or
other instructions which use the stack, will c
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
This is strictly a documentation request, as experimentation seems to indicate
that this construct already works as intended.
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #9 from H. Peter Anvin ---
Created attachment 59450
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59450&action=edit
Proposed assembly header implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #8 from H. Peter Anvin ---
Created attachment 59449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59449&action=edit
Current code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #7 from H. Peter Anvin ---
I have included a concrete example from the Linux kernel (with other parts of
the code stripped for clarity.)
The file asm_header.s shows how it could be implemented as an assembly header.
As you can see,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #6 from H. Peter Anvin ---
No idea what you mean with #asmoptions.
Using hacks in the Makefile is equivalent to having to do dependencies by hand
(keep in mind that these statements will generally be part of header files.) In
other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #13 from H. Peter Anvin ---
On October 22, 2024 5:49:41 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
>--- Comment #12 from Andrew Pinski ---
>(In reply to H. Peter Anvin from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #11 from H. Peter Anvin ---
For the record, MSVC has the following intrinsics, and no, I'm very much
not in favor of their particular prototypes (a structure like div_t
would be better than what they have.)
#include
unsigned __i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #10 from H. Peter Anvin ---
Well sizeof() ought to be sufficient to represent something with enough bits.
Even if x86 is the only architecture that has that specific instruction, I
would be extremely surprised if gcc couldn't use th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #7 from H. Peter Anvin ---
> _BitInt(sizeof(foo_t)*CHAR_BIT)
Should of course have been _BitInt(sizeof(foo_t)*CHAR_BIT*2) ...
-hpa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #6 from H. Peter Anvin ---
On 10/22/24 13:53, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
> --- Comment #5 from Andrew Pinski ---
> Also you are mixing two different issues together.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #4 from H. Peter Anvin ---
On October 22, 2024 1:19:05 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
>
>Andrew Pinski changed:
>
> What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #3 from H. Peter Anvin ---
On October 22, 2024 1:33:33 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
>Andrew Pinski changed:
>
> What|Removed |A
normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
As has pointed out in e.g. bug 82677, these operations are fairly commonly used
in multi-precision arithmetic and cryptography.
The
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
There are things in assembly that is way easier to support using assembly
macros. Open-coding them in C may not even be possible, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116302
--- Comment #5 from H. Peter Anvin ---
That's really too bad. It would be a very nice feature to have to migrate a
code base from shift and mask to using bitfields.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116302
--- Comment #2 from H. Peter Anvin ---
Created attachment 58881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58881&action=edit
Error output
Generated with:
gcc -std=gnu17 -ggdb3 -O2 -Wattributes -Wall -Wextra -c transp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116302
--- Comment #1 from H. Peter Anvin ---
Created attachment 58880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58880&action=edit
Reproducer (preprocessed)
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Created attachment 58879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58879&action=edit
Reproducer (C source)
Bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503
--- Comment #7 from H. Peter Anvin ---
Note: this is now implemented for x86, but it affects other targets as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #8 from H. Peter Anvin ---
Well, _Embed() would be an extension and it doesn't seem unreasonable to say
that _Embed() would be expanded after token pasting. After all, as has been
discussed in the C committee is that if #embed cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686
--- Comment #2 from H. Peter Anvin ---
The intermediate alignment for lui is known, so if an object is known to fit
*entirely* within its natural alignment then it can be safely CSE'd, but this
is typically not the case with structures or arrays
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
When the Local Exec TLS model is in use, gcc generates inefficient code for
accessing the member of a structure:
struct foobar {
int alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #21 from H. Peter Anvin ---
I think this could be a really useful performance improvement in general. The
Linux exception and syscall paths have a fair number of tail calls on the
primary path, and this would make it possible to avoi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #19 from H. Peter Anvin ---
I'm away for the long weekend, but I'll try it out on Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #15 from H. Peter Anvin ---
That should be fine for this use case, obviously.
I should add the following: the reason the assembly stub isn't a problem for
FRED whereas it is a bit of a nuisance for IDT-style delivery is that with
FR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #13 from H. Peter Anvin ---
No, it will not. Most OSes flows will want to merge the kernel and user flows
at some point for some handlers, so it isn't clear that that makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #10 from H. Peter Anvin ---
Right, is there such an attribute (that's what I'm asking for in bug 103503)?
All I see in the gcc documentation is no_calle*R*_saved_registers, which,
again, is the exact opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #6 from H. Peter Anvin ---
Of course. That's not what we want in the Linux kernel specifically, though.
It's really up to the OS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
--- Comment #2 from H. Peter Anvin ---
Right. The only thing I'm suggesting is that for the cost of one extra
instruction we can make it robust against the programmer picking the wrong
type, or wanting to use the same handler.
It isn't a necess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #4 from H. Peter Anvin ---
(In reply to H.J. Lu from comment #2)
> (In reply to H. Peter Anvin from comment #1)
> > This is actually a specific use case of the feature requested in bug 103503.
>
> This covers #1. Should FRED handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #3 from H. Peter Anvin ---
Created attachment 57032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57032&action=edit
FRED assembly entry stub (example, slightly modified from the Linux kernel)
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
__attribute__((interrupt)) on x86 has two prototypes, and picking the wrong
type "probably will cause a system crash." It turns out that this is
unavoidable on i3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #1 from H. Peter Anvin ---
This is actually a specific use case of the feature requested in bug 103503.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113298
--- Comment #2 from H. Peter Anvin ---
You're not wrong per se. Arguably the problem (and many others) would be better
solved by allowing user-specified conversations that are not member functions.
In that case one could do:
// Set the properti
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
-fpermissive downgrades some errors to warnings, but there doesn't seem to be
any -W options to suppress those warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
--- Comment #5 from H. Peter Anvin ---
I don't think source code modifications are a huge problem, but at this point
they require tracking down each individual bit.
As far as trapping implementations are concerned:
1. In deeply embedded implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
--- Comment #2 from H. Peter Anvin ---
Named subsets are, inherently, designed to make sense toward mass-produced
products where the hardware and software are designed (mostly) independently.
However, what I mean with "very deep embedded use" is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #10
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
For very deeply embedded use, it is sometimes highly desirable to control the
instruction set on a very fine grained basis. For example, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486
--- Comment #5 from H. Peter Anvin ---
Yes, exactly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #4 from H. Peter Anvin ---
So I'm updating this to be C23 #embed, since that is a bit more general than
the typical incbin (at least conceptually it operates on the preprocessor
syntactic level; it does not of course preclude a short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054
--- Comment #2 from H. Peter Anvin ---
I agree, my naming was very poor.
Perhaps "panic" or "abort" would work; those are classic names in software use
for this.
Another case of a function that could be so attributed would be the function
typica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56314
--- Comment #6 from H. Peter Anvin ---
Unfortunately that's not really possible given the way the way the level does
runtime patching (which isn't going to change, sorry.) At the very least we
would need a *lot* more compiler support to give LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #37 from H. Peter Anvin ---
One would assume that there would be __foo__ aliases for the attribute names
like all the other ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #11 from H. Peter Anvin ---
If you look at the output, you see that the loops are already fully unrolled
(at considerable code size cost.)
Unfortunately, since the issue at hand is dealing with code written to be
portable, adding gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #9 from H. Peter Anvin ---
To clarify: the C test case produces the same output regardless if it is
compiled as C or C++. Only the C++ wrapped class definition detects the
additional case of a 32-bit bigendian load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #8 from H. Peter Anvin ---
Created attachment 53610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53610&action=edit
C++ test case object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #7 from H. Peter Anvin ---
Created attachment 53609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53609&action=edit
C++ test case assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #6 from H. Peter Anvin ---
Created attachment 53608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53608&action=edit
C++ test case preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #5 from H. Peter Anvin ---
Created attachment 53607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53607&action=edit
C++ test case main file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #4 from H. Peter Anvin ---
Created attachment 53606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53606&action=edit
C++ test case class definition header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #3 from H. Peter Anvin ---
Created attachment 53605
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53605&action=edit
C test case object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #2 from H. Peter Anvin ---
Created attachment 53604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53604&action=edit
C test case assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #1 from H. Peter Anvin ---
Created attachment 53603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53603&action=edit
C test case preprocessed source
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Created attachment 53602
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53602&action=edit
C test case source
The only *portable* way in C to de
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Since upgrading to gcc 12.1.1, I keep getting the following warning through
various projects:
cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503
--- Comment #4 from H. Peter Anvin ---
The interrupt attribute typically does two things:
1. It changes the return instruction;
2. It marks all registers as saved.
2 is exactly the *opposite* of what I want; I would like to improve performance
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
It is a *very* common operation to want to include a preexisting binary object
into a compiled project. There are a numbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85751
--- Comment #2 from H. Peter Anvin ---
Goodness... I missed the question here.
The intent was to just take advantage of existing padding: the execution flow
should not go there.
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Target: multiple
When a common assembly interrupt entry code or an equivalent hardware engine is
used to handle register saves in an interrupt routine, it may be completely
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Target: x86
In the Linux kernel we reasonably frequently use extended asm operand modifiers
like %P[]/%p[] for encoding a memory operand that *must not* use
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
__attribute__((error)) and __attribute__((warning)) are useful, but have, in
some places, poor semantics. It would be really good to have a function
attribute which would trigger if "all roads le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #9 from H. Peter Anvin ---
I can confirm this bug is still present as of gcc 8.2.1.
I have attached a test case which clearly shows __udivdi3 called with the
regparm convention, but libgcc definitely does not expect it:
objdump -dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #8 from H. Peter Anvin ---
Created attachment 45862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45862&action=edit
Test code (object output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #7 from H. Peter Anvin ---
Created attachment 45861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45861&action=edit
Test case (assembly output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #6 from H. Peter Anvin ---
Created attachment 45860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45860&action=edit
Test case (preprocessed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85752
--- Comment #1 from H. Peter Anvin ---
N.B.: this presumably needs some kind of special treatment of NULL, to prevent
NULL from being an absolute value.
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
If a pointer is optionally stored as a self-relative value rather than
absolute, it would enable the following use cases containing arbitrarily
complex data structures without needing
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
For most (all?) targets, there exists a breakpoint or other trap instruction
which can be inserted at any point in the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701
--- Comment #2 from H. Peter Anvin ---
(continued)
: "+rm,r" (aa.l[0]), "+rm,r" (aa.l[1])
: "ri,m" (bb.l[0]), "ri,m" (bb.l));
a = aa.q;
b = bb.q;
If this is something that works by intent and not by accident I'm perfectly
happy with this solut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701
--- Comment #1 from H. Peter Anvin ---
I just stumbled onto this technique somewhat by accident:
union dw {
uint64_t q;
uint32_t l[2];
};
union dw aa, bb;
aa.q = a;
bb.q = b;
asm("add %2,%0; adc %3,%1"
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
x86 inline assembly currently has no sensible way to use doubleword operands
(long long on x86-32, __int128 on x86-64) without restricting them to the d:a
register pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272
--- Comment #2 from H. Peter Anvin ---
Since it doesn't seem to be clear from the text, perhaps an interpretation
request to the committee is in order. If this indeed is the requirement, I
would suggest implementing it as a gnu99/gnu11 extension
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
People not familiar with C, or who have read misguided style guides, sometimes
write code like:
if (cond == true) {
}
instead of
if (cond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #30 from H. Peter Anvin ---
On August 18, 2017 3:52:12 PM CDT, "hjl.tools at gmail dot com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
>
>--- Comment #29 from H.J. Lu ---
>(In reply to r...@cebitec.uni-bielefeld.de f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #9 from H. Peter Anvin ---
In some applications it might even be appropriate to use the RDPID instruction
and store the canary in the IA32_TSC_AUX MSR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #8 from H. Peter Anvin ---
How about simply letting the user enter an assembly expression of neither of
the standard ABI options are suitable? Also, shouldn't the user space default
on 64 bits be an offset into the TLS using %fs, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #26 from H. Peter Anvin ---
@GPREL (altough it probably should be @GPOFF by analogy with @TPOFF?) gives the
linker an option to distinguish the relocations which need to be adjusted at
link/load time and the ones that don't.
We have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #1
1 - 100 of 190 matches
Mail list logo
