[Bug target/103503] RFE: no save registers attribute

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.

[Bug c/105863] RFE: C23 #embed

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

[Bug target/113686] [RISC-V] TLS (Local Exec) relaxation on structures (LE)

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

[Bug target/113686] New: [RISC-V] TLS (Local Exec) relaxation on structures (LE)

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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.

[Bug target/113321] x86-64: Make __attribute__((interrupt)) more robust

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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=edit FRED assembly entry stub (example, slightly modified from the Linux kernel)

[Bug target/113321] New: x86-64: Make __attribute__((interrupt)) more robust

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 unavoidab

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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.

[Bug c++/113298] RFE: allow suppressing warnings for void * conversions with -fpermissive

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

[Bug c++/113298] New: RFE: allow suppressing warnings for void * conversions with -fpermissive

: 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

[Bug target/111020] RFE: RISC-V: ability to cherry-pick additional instructions

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

[Bug target/111020] RFE: RISC-V: ability to cherry-pick additional instructions

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"

[Bug c/96952] __builtin_thread_pointer support cannot be probed

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

[Bug target/111020] New: RFE: RISC-V: ability to cherry-pick additional instructions

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

[Bug c++/106486] C++ warning for -Wmissing-prototypes is pure nuisance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486 --- Comment #5 from H. Peter Anvin --- Yes, exactly.

[Bug c/105863] RFE: C23 #embed

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

[Bug c/96054] RFE: __attribute__((fatal))

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

[Bug middle-end/56314] Please allow per-function specification of register conventions

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

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

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.

[Bug tree-optimization/107006] Missing optimization: common idiom for external data

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

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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.

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C++ test case object code

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C++ test case assembly output

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C++ test case preprocessed source

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C++ test case main file

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C++ test case class definition header file

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C test case object code

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C test case assembly output

[Bug rtl-optimization/107006] Missing optimization: common idiom for external data

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=edit C test case preprocessed source

[Bug rtl-optimization/107006] New: Missing optimization: common idiom for external data

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=edit C test case source The only *portable* way in C to deal with exter

[Bug c++/106486] New: C++ warning for -Wmissing-prototypes is pure nuisance

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

[Bug target/103503] RFE: no save registers attribute

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

[Bug c/105863] New: RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

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

[Bug middle-end/85751] RFE: option to align code using breakpoint instructions when unreachable

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.

[Bug target/103503] New: RFE: no save registers attribute

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

[Bug c/102266] New: RFE: x86: print operand with optional (%rip) suffix

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

[Bug c/96054] New: RFE: __attribute__((fatal))

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

[Bug target/41055] libgcc functions and -mregparm don't work well together

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

[Bug target/41055] libgcc functions and -mregparm don't work well together

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=edit Test code (object output)

[Bug target/41055] libgcc functions and -mregparm don't work well together

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=edit Test case (assembly output)

[Bug target/41055] libgcc functions and -mregparm don't work well together

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=edit Test case (preprocessed)

[Bug target/41055] libgcc functions and -mregparm don't work well together

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

[Bug c/66970] Add __has_builtin() macro

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

[Bug other/85752] RFE: self-relative (prepickled) pointers

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.

[Bug other/85752] New: RFE: self-relative (prepickled) pointers

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

[Bug middle-end/85751] New: RFE: option to align code using breakpoint instructions when unreachable

: 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

[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism

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

[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly

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

[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly

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"

[Bug inline-asm/82701] New: RFE: x86: double word operands in inline assembly

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

[Bug c/82272] RFE: request a warning for ( == ) etc.

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

[Bug c/82272] New: RFE: request a warning for ( == ) etc.

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

[Bug c/53037] warn_if_not_aligned(X)

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

[Bug target/81708] The x86 stack canary location should be customizable

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.

[Bug target/81708] The x86 stack canary location should be customizable

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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

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

[Bug target/81708] The x86 stack canary location should be customizable

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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #22 from H. Peter Anvin --- There are other issues, too (we'd have to drop the kernel memory model, probably replace it with the small-pic model) but %gs: addressing is one of those.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #19 from H. Peter Anvin --- So the Linux kernel, right now, basically does (b); we'd like to do something more like (a). Because the stack canary (which is a percpu variable in the Linux kernel) is hard-coded in gcc to be %gs:0x28,

[Bug c/34455] Request warning for casts to _Bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34455 --- Comment #5 from H. Peter Anvin --- 10 years have passed since the original request. These days compilers that don't have any support for bool at all can be genuinely considered rare at the very best. I don't think it is applicable anymore.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #13 from H. Peter Anvin --- On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 > >--- Comment #12 from Uroš Bizjak --- >(In reply to Andy

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #11 from H. Peter Anvin --- Not primarily.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #7 from H. Peter Anvin --- Thinking about this some more, this is really not an aspect of __seg_* but rather the section the symbol is placed in. An embedded system kernel, for example, could quite possibly want to access an

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #6 from H. Peter Anvin --- It is probably inappropriate to generate non-absolute address references for these symbols for any kind of PIC or PIE output (as that would require unwanted relocation!), so #2 is probably not really

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #5 from H. Peter Anvin --- The test case was compiled with: gcc -fno-plt -fpie -fvisibility=hidden -mcmodel=small -O2 (note: no code changes between -fpie and -fpic)

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #4 from H. Peter Anvin --- Created attachment 41801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41801=edit Test case: assembly output

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #3 from H. Peter Anvin --- Created attachment 41800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41800=edit Test case: preprocessor output

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #2 from H. Peter Anvin --- Created attachment 41799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41799=edit Test case: object file

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #1 from H. Peter Anvin --- Created attachment 41798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41798=edit Test case: source code

[Bug target/81490] New: x86: Handling of symbol ranges for __seg_fs/__seg_gs

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- Note: this was tested with gcc 6.3.1, but I believe there is no changes in later versions. On x86, gcc assumes that the valid range of symbols compiled with __seg_fs

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #10 from H. Peter Anvin --- It is not. I guess I'd like to modify the request to allow __attribute__((scalar_storage_order())) to be specified for scalar *pointer*. That would bring the 90% up to 99% at the very least; the

[Bug c/79217] Feature request: high half of an integer multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217 --- Comment #5 from H. Peter Anvin --- As noted on bug 79219 there are a few issues with simply relying on __int128, even if 32 bits is the natural "limb" size on a 32-bit architecture. a) it requires algorithms to be implemented using lengthy

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #8 from H. Peter Anvin --- (In reply to Richard Biener from comment #1) > So you mean DW/W -> W, but that can result in the result being not > representable? > What's the desired behavior in this case? Invoking undefined behavior?

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #7 from H. Peter Anvin --- Created attachment 40603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40603=edit Test case: assembly output

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #6 from H. Peter Anvin --- Created attachment 40602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40602=edit Test case: preprocessor output

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #5 from H. Peter Anvin --- Created attachment 40601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40601=edit Test case: source code

[Bug c/79217] Feature request: high half of an integer multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217 --- Comment #4 from H. Peter Anvin --- My apologies for the three attachments; I incorrectly attached them to the wrong bug report.

[Bug c/79217] Feature request: high half of an integer multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217 --- Comment #3 from H. Peter Anvin --- Created attachment 40600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40600=edit Assembly output

[Bug c/79217] Feature request: high half of an integer multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217 --- Comment #2 from H. Peter Anvin --- Created attachment 40599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40599=edit Preprocessor output

[Bug c/79217] Feature request: high half of an integer multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217 --- Comment #1 from H. Peter Anvin --- Created attachment 40598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40598=edit Source code

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #4 from H. Peter Anvin --- There are a few issues with that: a) the overflow behavior is inherently different, which is why the inline you propose doesn't work. Try compiling the attached program, on x86-64 it produces a call to

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #8 from H. Peter Anvin --- I guess I'm confused why it would not be possible to specify the endianness of a scalar, or perhaps far more importantly a pointer to a scalar. Other than that, this feature seems to do 90% of what I was

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #4 from H. Peter Anvin --- As in, I would expect that: struct foo __attribute__((scalar_storage_order("big-endian"))) { uint32_t bar; } foo; uint32_t *baz = ... would give an error on a littleendian architecture and a warning

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #3 from H. Peter Anvin --- It does indeed, I don't know why I missed it. The only thing that I really see as a problem with it is that it doesn't allow the assignment of endianness to scalar pointers, e.g.: uint32_t

[Bug c/79219] New: Feature request: double width/single width division and remainder

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- A fair number of numerical algorithms could use a double width/single width division (and remainder) operation. This is not part of standard

[Bug c/79217] New: Feature request: high half of a multiplication

: c Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- There is no standard way in C to obtain the high half of a multiplication for the largest integer data type supported. gcc has __int128 on 64-bit platforms, but not on 32-bit

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #1 from H. Peter Anvin --- The idea being that assignments to/from such a data item would make the compiler generate the appropriate byte-swapping instructions appropriate for the architecture. If part of a packed structure, this

[Bug c/57612] add builtin to assert that expression does not have side effects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 H. Peter Anvin changed: What|Removed |Added CC||hpa at zytor dot com --- Comment #2

[Bug c/79216] New: Feature request: byte order attributes

Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- It is pretty crazy that the C language doesn't have any way to indicate the layout of external data, even though it is incredibly frequently used that way. It ought to be a major

[Bug c/70967] New: doc: Please document rotate idiom

Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- The idiom that gcc has recognized since time immemorial (gcc 2-something) to generate a rotate: ((foo >> n) + (foo << (sizeof(foo) * CHAR_BIT - n)) /* | instead o

[Bug c/66899] ICE when compiling pkcs7_trust.c in Linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66899 --- Comment #1 from H. Peter Anvin hpa at zytor dot com --- I have not yet narrowed down the set of options required to manifest the bug.

[Bug c/66899] New: ICE when compiling pkcs7_trust.c in Linux

Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- Created attachment 35997 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35997action=edit File that ICEs Git version: 29a78fec9c08f01c8afa12b08ffe994904a782ce git-svn-id: svn+ssh

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #8 from H. Peter Anvin hpa at zytor dot com --- Arguably the *right* way to solve that would be to support __null for C as well as for C++.

  1   2   >