https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #5 from H. Peter Anvin ---
Overlays is something entirely different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #2 from H. Peter Anvin ---
It certainly is not specific to the Linux kernel, although perhaps how I
phrased it is (in particular tying it to sections is rather specific to
embedded environments, of which the Linux kernel is but one.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #5 from H. Peter Anvin ---
Having an -fkernel option would not be a bad thing, either; it could be used to
hide anything the compiler does that is specific to kernel space. On a lot of
platforms that would include stuff like __attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #4 from H. Peter Anvin ---
So I guess the real question is to what extent you actually want to support the
Linux kernel -- and other kernels -- as a compilation target.
I will agree with you that doing this with type attributes -- i
: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
In the Linux kernel, we have a lot of functions which are annotated with
markings like __init to indicate a function that can be jettisoned after system
boot.
Given the compilation context, some of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #2 from H. Peter Anvin ---
Could you please clarify why you think this is not a good idea?
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Currently, -Wp,-dM can be used to get all the predefined macros in the
preprocessor, but there is no equivalent to get the C preprocessor assertions,
something like -Wp-dMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #6 from H. Peter Anvin ---
I would say it would either take up 1 bit or be an error. Bitfields actually
was one of the biggest design mistakes in C: the width should always have been
part of the type (like intX_t or now, finally, _Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
--- Comment #5 from H. Peter Anvin ---
(I'm asking because of our is far enough back then we can convert the kernel
code immediately.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
--- Comment #4 from H. Peter Anvin ---
Since when has i386 supported %a (outputting just the symbol)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
--- Comment #3 from H. Peter Anvin ---
THat should of course have been __attribute__((unused)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
--- Comment #2 from H. Peter Anvin ---
Having to omit the name puts us right back into macro hell... having to
macroize every function definition.
It also violates the principle of least surprise, since __attribute__((used))
works if attached t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #4 from H. Peter Anvin ---
Well, I did both.
See also bug 120010; I don't believe this is at all consistent.
Having to omit the variable name defeats the whole purpose here.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Created attachment 61242
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61242&action=edit
Test case
__attribute__((unused)) on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #2 from H. Peter Anvin ---
Very interesting indeed... I just tried it as such:
struct empty_t { } __attribute__((unused));
typedef struct empty_t empty_t __attribute__((unused));
int foo(empty_t a, int b, int c, empty_t d, int e,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
H. Peter Anvin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
In the case of configurable code, it sometimes happens that a variable,
structure member or function argument becomes pointless. At this point, the
only ways around that are to
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
When doing user space memory references from kernel space, x86 needs to use the
stac and clac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #17 from H. Peter Anvin ---
So I am still confused by this.
It would seem that this really ought to be a very simple request, and that
adding compiler support for all these cases would impose a really large burden
on the gcc team (y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
H. Peter Anvin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119987
--- Comment #3 from H. Peter Anvin ---
Yes, it seems that MS is an improper subset of Plan9. I think MS is much closer
to what we want, anyway.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
Being able to use an already predefined structure as an anonymous structure
member as permitted by -fms-extensions would be an incredibly useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85752
H. Peter Anvin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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.
1 - 100 of 213 matches
Mail list logo
