[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

2021-10-05 Thread ilya.konstantinov at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Ilya Konstantinov changed: What|Removed |Added CC||ilya.konstantinov at gmail dot com

[Bug preprocessor/61922] Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

2014-07-27 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922 --- Comment #6 from Ilya Konstantinov --- OK, I've done some more research: 1) It turns out Windows doesn't handle parent directories from symlinks the way *nix does, but rather just follows them out of the symlink. Same for junctions a.k.a moun

[Bug preprocessor/61922] Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

2014-07-27 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922 --- Comment #5 from Ilya Konstantinov --- cygwin and mingw can document a limitation such as: fopen will truncate paths to MAX_PATH. Once cygwin or mingw receive a monstrous path, there's little they can do. CreateFile won't accept it, neither

[Bug preprocessor/61922] Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

2014-07-27 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922 --- Comment #3 from Ilya Konstantinov --- Both mingw and cygwin will eventually call CreateFile, there's no way around that. The 260 characters limitation is on CreateFile. Re symlinks - see discussion on the llvm issue. I'm not proposing textua

[Bug preprocessor/61922] Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

2014-07-27 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922 --- Comment #1 from Ilya Konstantinov --- Of course, I meant to say: When #include "..." is relative to the including file's directory, **gcc** performs simple path concatenation.

[Bug c/61922] New: Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

2014-07-26 Thread ilya.konstantinov at gmail dot com
: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ilya.konstantinov at gmail dot com Created attachment 33190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33190&action=edit Minimal testcase When #include &

[Bug c/61413] New: __ARM_SIZEOF_WCHAR_T is constant 32 -- should be 4 or 2

2014-06-04 Thread ilya.konstantinov at gmail dot com
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ilya.konstantinov at gmail dot com ARM EABI mandates __ARM_SIZEOF_WCHAR_T that reflects the wchar size: "wchar_t may be 2 or 4 bytes. The predefined macro __ARM_SIZEOF_WCHAR_T should be defin

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

2014-06-02 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804 --- Comment #7 from Ilya Konstantinov --- Whoever has permission to change, please add 'rejects-valid' as per my example in the previous comment. P.S. this issue reproduces in g++ 4.8

[Bug c++/37804] friend declaration leaks into global scope at template instantiation

2014-06-01 Thread ilya.konstantinov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804 Ilya Konstantinov changed: What|Removed |Added CC||ilya.konstantinov at gmail dot com