[Bug c++/95302] function attributed to be deprecated cannot include a typedef/using

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95302 Anatol changed: What|Removed |Added CC||anatol.pomozov at gmail dot com --- Comment #1

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709 --- Comment #6 from Anatol --- > I don't believe compiler needs to do all that. I might miss something, could you please share why? The check for FXSAVE can be a compile time: if compiled for Pentium II tune or later then use FXSAVE otherwise u

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709 --- Comment #4 from Anatol --- > you need to save the complete vector state It is a good point. Would it make sense for compiler to do it? Instead of forcing users to track if SSE registers are used and doing xsave/xrstor manually?

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709 --- Comment #2 from Anatol --- Theoretically it is possible to do things like this manually. Track functions x86 extensions usage and save registers accordingly. But I would love to see a more automated and less error-prone way to do it. Similar

[Bug c/81709] New: __attribute__((interrupt)) should handle SSE registers

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: anatol.pomozov at gmail dot com Target Milestone: --- GCC documentation for __attribute__((interrupt)) states that interrupts should not use SSE/MPX/ MMX/x87 as GCC does not preserve the register content in handlers

[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342 --- Comment #5 from Anatol --- Having 32bit preamble in 64bit code is a standard situation in x86 OS development. Bootloader (such as GRUB multiboot) leaves the system in 32bit protected mode. It is responsibility of the OS to finish 32bit initia

[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342 --- Comment #3 from Anatol --- Hi I indeed observe the issue in a kernel project. It is a custom x86 kernel that is not published yet. I tried to narrow down use case and I think I found how to reproduce the issue easily. It looks like a trigge

[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342 --- Comment #2 from Anatol --- Created attachment 41724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41724&action=edit Reproduce lto crash with LD

[Bug c/81342] New: LTO: lto1: internal compiler error: Segmentation fault

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: anatol.pomozov at gmail dot com Target Milestone: --- I am using the latest version of gcc (7.1.0 built using https://github.com/travisg/toolchains on Ubuntu 14.04) and I have following crash if I try to use LTO with

[Bug target/25967] Add attribute naked for x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967 Anatol changed: What|Removed |Added CC||anatol.pomozov at gmail dot com --- Comment

[Bug lto/80717] LTO wrappers segfault if run with absolute path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717 Anatol changed: What|Removed |Added CC||anatol.pomozov at gmail dot com --- Comment #3

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #5 from Anatol --- This bug has been reported by Arch Linux users. https://bugs.archlinux.org/task/49284 It is a severe compiler issue that stop avr-gcc 6 from using. Consider changing "Importance" status to blocker.

[Bug libstdc++/53579] libstdc++ configure use CXXFLAGS instead of CXXFLAGS_FOR_TARGET

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579 --- Comment #3 from Anatol --- I just hit this issue when tried to build cross-tools for arm64. CFLAGS_FOR_TARGET works as expected and I was assuming that CXXFLAGS_FOR_TARGET is used instead of CXXFLAGS. If CXXFLAGS_FOR_TARGET is not honored no

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #8 from Anatol 2011-03-12 04:50:22 UTC --- What are the plans? Are you going to submit the fix to 4.6? How can I help you with testing?

[Bug c/47997] New: gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 Summary: gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString" Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal