[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 from Anatol --- Shyouhei, thank you for filing this ticket. I agree that GCC should not complain about deprecated usage if the symbol is not really used. Such GCC behavior causes excessive compile time warnings when using SWIG library https://github.com/swig/swig/issues/1689#issuecomment-636109918
[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 use FSAVE. if (tune >= 'pentium II') FXSAVE else FSAVE ... save whatever FSAVE did not save ... end
[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 to what CLANG compiler already does. CLANG tracks registers use and reduces a lot of burden for me. That is the reason why we switched to CLANG in our project for now but I would love to see GCC first-class support as well. What is the reason that GCC does not track SSE register usage? Is it a GGC architecture restriction or something else?
[Bug c/81709] New: __attribute__((interrupt)) should handle SSE registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709
Bug ID: 81709
Summary: __attribute__((interrupt)) should handle SSE registers
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
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. https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html
Is there any way to relax this restriction and make GCC aware of SSE/.. usage
and preserve the state correctly? While I think that interrupt handlers should
be as fast as possible there are cases when it is OK to call functions compiled
with SSE support. GCC should handle such situations and preserve SSE/..
registers.
Clang handles this situation. Here is a compiler output for a handler with a
function call that uses SSE:
__attribute__((interrupt)) void handle_breakpoint(struct interrupt_frame
*frame) {
printf("Hello from breakpoint handler\n");
}
GCC 7:
001021b0 :
1021b0: 41 53 push %r11
1021b2: 41 52 push %r10
1021b4: 41 51 push %r9
1021b6: 41 50 push %r8
1021b8: 57 push %rdi
1021b9: 56 push %rsi
1021ba: bf 40 33 10 00 mov$0x103340,%edi
1021bf: 51 push %rcx
1021c0: 52 push %rdx
1021c1: 50 push %rax
1021c2: 31 c0 xor%eax,%eax
1021c4: fc cld
1021c5: e8 c6 de ff ff callq 100090
1021ca: 58 pop%rax
1021cb: 5a pop%rdx
1021cc: 59 pop%rcx
1021cd: 5e pop%rsi
1021ce: 5f pop%rdi
1021cf: 41 58 pop%r8
1021d1: 41 59 pop%r9
1021d3: 41 5a pop%r10
1021d5: 41 5b pop%r11
1021d7: 48 cf iretq
1021d9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
Clang 4:
00100260 :
100260: 50 push %rax
100261: 41 53 push %r11
100263: 41 52 push %r10
100265: 41 51 push %r9
100267: 41 50 push %r8
100269: 57 push %rdi
10026a: 56 push %rsi
10026b: 52 push %rdx
10026c: 51 push %rcx
10026d: 48 81 ec 00 01 00 00sub$0x100,%rsp
100274: 44 0f 29 bc 24 f0 00movaps %xmm15,0xf0(%rsp)
10027b: 00 00
10027d: 44 0f 29 b4 24 e0 00movaps %xmm14,0xe0(%rsp)
100284: 00 00
100286: 44 0f 29 ac 24 d0 00movaps %xmm13,0xd0(%rsp)
10028d: 00 00
10028f: 44 0f 29 a4 24 c0 00movaps %xmm12,0xc0(%rsp)
100296: 00 00
100298: 44 0f 29 9c 24 b0 00movaps %xmm11,0xb0(%rsp)
10029f: 00 00
1002a1: 44 0f 29 94 24 a0 00movaps %xmm10,0xa0(%rsp)
1002a8: 00 00
1002aa: 44 0f 29 8c 24 90 00movaps %xmm9,0x90(%rsp)
1002b1: 00 00
1002b3: 44 0f 29 84 24 80 00movaps %xmm8,0x80(%rsp)
1002ba: 00 00
1002bc: 0f 29 7c 24 70 movaps %xmm7,0x70(%rsp)
1002c1: 0f 29 74 24 60 movaps %xmm6,0x60(%rsp)
1002c6: 0f 29 6c 24 50 movaps %xmm5,0x50(%rsp)
1002cb: 0f 29 64 24 40 movaps %xmm4,0x40(%rsp)
1002d0: 0f 29 5c 24 30 movaps %xmm3,0x30(%rsp)
1002d5: 0f 29 54 24 20 movaps %xmm2,0x20(%rsp)
1002da: 0f 29 4c 24 10 movaps %xmm1,0x10(%rsp)
1002df: 0f 29 04 24 movaps %xmm0,(%rsp)
1002e3: fc cld
1002e4: bf 4f 3c 10 00 mov$0x103c4f,%edi
1002e9: 31 c0 xor%eax,%eax
1002eb: e8 f0 28 00 00 callq 102be0
1002f0: 0f 28 04 24 movaps (%rsp),%xmm0
1002f4: 0f 28 4c 24 10 movaps 0x10(%rsp),%xmm1
1002f9: 0f 28 54 24 20 movaps 0x20(%rsp),%xmm2
1002fe: 0f 28 5c 24 30 movaps 0x30(%rsp),%xmm3
100303: 0f 28 64 24 40 movaps 0x40(%rsp),%xmm4
100308: 0f 28 6c 24 50 movaps 0x50(%rsp),%xmm5
10030d: 0f 28 74 24 60 movaps 0x60(%rsp),%xmm6
100312: 0f 28 7c 24 70 m
[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 initialization (where only i386 instructions can be used) and switch to 64bit code. Once 32bit initialization is done switching to 64code happens with "far jump with selector" instruction "jmp $CODE_SELECTOR, $START64" You cannot link 32bit and 64bit together (and least LD linker does not allow it). Thus one have to use a trick, either: 1) objcopy code32.o from elf32 to elf64 format 2) if code32 was an ASM code then use ".code32" GAS directive and compile file with 64bit flags. Here is an example of #2 from LK operation system https://github.com/littlekernel/lk/blob/master/arch/x86/64/start.S#L210 I tried both solution and they both work with GCC and CLANG. GCC crashes if I enable LTO for #1.
[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 trigger pattern is: 1) compile one file as 32bit code (-m32) 2) convert it to 64bit elf object using objcopy 3) link the object above with regular 64bit elf If "-flto" is not used then linking works fine otherwise I have the crash above. Here is an attached repo case for your convenience.
[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=edit Reproduce lto crash with LD
[Bug c/81342] New: LTO: lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342 Bug ID: 81342 Summary: LTO: lto1: internal compiler error: Segmentation fault Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 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 my project. The crash happens when I run liner stage: /home/anatol/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/x86_64-elf-gcc arch/x86/apic.o arch/x86/interrupt.o arch/x86/interrupt_handler.o arch/x86/mmu.o arch/x86/multiboot1.o arch/x86/pit.o arch/x86/start.o arch/x86/start_64.o arch/x86/vga_console.o core/mem.o core/printf.o core/string.o core/app.o -o out/app.elf -g -ggdb -flto -nostdlib -ffreestanding -std=c11 -fno-stack-protector -mno-red-zone -fno-common -W -Wall -Wextra -O3 -I./include -Wl,-n -Wl,--gc-sections -Wl,-Tarch/x86/linker.ld Here is the message from gcc: lto1: internal compiler error: Segmentation fault 0x994e8f crash_signal ../../gcc-7.1.0/gcc/toplev.c:337 0xb4205d streamer_get_pickled_tree(lto_input_block*, data_in*) ../../gcc-7.1.0/gcc/tree-streamer-in.c: 0x8785b4 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ../../gcc-7.1.0/gcc/lto-streamer-in.c:1452 0x87880a lto_input_tree(lto_input_block*, data_in*) ../../gcc-7.1.0/gcc/lto-streamer-in.c:1492 0xb41e97 lto_input_ts_decl_minimal_tree_pointers ../../gcc-7.1.0/gcc/tree-streamer-in.c:695 0xb41e97 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) ../../gcc-7.1.0/gcc/tree-streamer-in.c:1051 0x877edf lto_read_tree_1 ../../gcc-7.1.0/gcc/lto-streamer-in.c:1333 0x878498 lto_read_tree ../../gcc-7.1.0/gcc/lto-streamer-in.c:1363 0x878498 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ../../gcc-7.1.0/gcc/lto-streamer-in.c:1475 0x878779 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*) ../../gcc-7.1.0/gcc/lto-streamer-in.c:1387 0x5eaa3e lto_read_decls ../../gcc-7.1.0/gcc/lto/lto.c:1696 0x5ec41e lto_file_finalize ../../gcc-7.1.0/gcc/lto/lto.c:2040 0x5ec41e lto_create_files_from_ids ../../gcc-7.1.0/gcc/lto/lto.c:2050 0x5ec41e lto_file_read ../../gcc-7.1.0/gcc/lto/lto.c:2091 0x5ec41e read_cgraph_and_symbols ../../gcc-7.1.0/gcc/lto/lto.c:2803 0x5ec41e lto_main() ../../gcc-7.1.0/gcc/lto/lto.c:3308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. lto-wrapper: fatal error: /usr/local/google/home/anatol/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/x86_64-elf-gcc returned 1 exit status compilation terminated. /mnt/cold/sources/toolchains/x86_64-elf-7.1.0-Linux-x86_64/bin/../lib/gcc/x86_64-elf/7.1.0/../../../../x86_64-elf/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status
[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 #11 from Anatol --- I need this feature in my project as well. And I was surprised to find this old feature request that has not been resolved yet. Is there any chance to see __naked__ implemented for x86? As it turned out clang supports __naked__ attribute at x86. So we switched from GCC to CLANG as our main compiler. But I would really love to see GCC as an option for our project.
[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 from Anatol --- Hi, any progress with fixing this issue? Arch users found that 'arduino' tool crashes because of this bug. https://bugs.archlinux.org/task/54159
[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 anatol.pomozov at gmail dot com --- 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 now, what is recommended workaround for cross-compilers that need different CXXFLAGS for host and target?
[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 anatol.pomozov at gmail dot com 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 Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: anatol.pomo...@gmail.com Created attachment 23553 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23553 A repro case for ld: warning: -fwritable-strings not compatible with literal CF/NSString warning Hi, I am trying to implement a program that uses fsevent library on macosx. http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/FSEvents_ProgGuide/UsingtheFSEventsFramework/UsingtheFSEventsFramework.html#//apple_ref/doc/uid/TP40005289-CH4-SW4 And I need some features (such as __thread) that is not supported neither by outdated GCC from XCode, nor by Clang. The only option is GCC from MacPorts. I installed GCC-4.6 from macports (gcc46 @4.6-20110226) and trying to compile a fsevent sample (see it in the attachement). When I try to compile it with gcc 4.6 it produces a weird warning: $ gcc-mp-4.6 -framework CoreServices ld_warn.c ld: warning: -fwritable-strings not compatible with literal CF/NSString in /var/folders/++/++27Xk++6+0++4RjPqRgNE+-0Mw/-Tmp-//cc3B1vHB.o The output binary looks OK. When I try to compile the same sources either with gcc from XCode or clang - it compiles without any warning: $ clang -framework CoreServices ld_warn.c It makes me think that this is an issue with GCC. I also googled following clang bug that looks very similar http://llvm.org/bugs/show_bug.cgi?id=8993
