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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
Bug ID: 117312
Summary: RFE: x86 (and perhaps others): inline assembly:
"red-zone" clobber
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117311
Bug ID: 117311
Summary: Documentation request: __builtin_frame_address(0) and
inline assembly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
Bug ID: 117266
Summary: RFE: builtins for N*N -> 2N multiplication and 2N/N ->
N div/mod
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
Bug ID: 117265
Summary: RFE: extended asm support for assembly macros/assembly
headers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116302
Bug ID: 116302
Summary: transparent union does not work with {integral type,
bitfield struct}
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686
Bug ID: 113686
Summary: [RISC-V] TLS (Local Exec) relaxation on structures
(LE)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Pri
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
Bug ID: 113321
Summary: x86-64: Make __attribute__((interrupt)) more robust
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113298
Bug ID: 113298
Summary: RFE: allow suppressing warnings for void * conversions
with -fpermissive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020
Bug ID: 111020
Summary: RFE: RISC-V: ability to cherry-pick additional
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
Bug ID: 107006
Summary: Missing optimization: common idiom for external data
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486
Bug ID: 106486
Summary: C++ warning for -Wmissing-prototypes is pure nuisance
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
Bug ID: 105863
Summary: RFE: __attribute__((incbin("file"))) or
__builtin_incbin("file")
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503
Bug ID: 103503
Summary: RFE: no save registers attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
Bug ID: 102266
Summary: RFE: x86: print operand with optional (%rip) suffix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
79 matches
Mail list logo
