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
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?
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
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.
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/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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717
Anatol changed:
What|Removed |Added
CC||anatol.pomozov at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967
Anatol changed:
What|Removed |Added
CC||anatol.pomozov at gmail dot com
--- Comment
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
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95302
Anatol changed:
What|Removed |Added
CC||anatol.pomozov at gmail dot com
--- Comment #1
15 matches
Mail list logo
