[Bug c++/96716] New: GCC reports "object is private" when it's accessed through proper accessor

2020-08-19 Thread vorfeed.canal at gmail dot com
Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vorfeed.canal at gmail dot com Target Milestone: --- The following program doesn't work ( https://godbolt.org/z/87cr44 ): #include #include class F

[Bug c++/96976] g++ reports "call of overloaded '...' is ambiguous" when universal reference is used

2020-09-09 Thread vorfeed.canal at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96976 Vorfeed Canal changed: What|Removed |Added CC||vorfeed.canal at gmail dot com

[Bug c++/82793] New: __attribute__((target("sse"))) causes call throught ifunc

2017-11-01 Thread vorfeed.canal at gmail dot com
ty: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vorfeed.canal at gmail dot com Target Milestone: --- The following example illustrates the problem: #include "xmmintrin.h" extern __attribute__((target("avx")

[Bug c++/82793] __attribute__((target("sse"))) causes call throught ifunc

2017-11-01 Thread vorfeed.canal at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82793 --- Comment #1 from Vorfeed Canal --- Example closer to real code: #include "xmmintrin.h" inline __attribute__((target("avx"),visibility("hidden"))) __m128 foo(__m128 a, __m128 b) { return _mm_add_ps(a, b); } inline __attribute__((target("ss

[Bug c/68360] New: GCC bitfield processing code is very inefficient

2015-11-15 Thread vorfeed.canal at gmail dot com
: c Assignee: unassigned at gcc dot gnu.org Reporter: vorfeed.canal at gmail dot com Target Milestone: --- It looks like GCC couldn't generate efficient code where clang could. I'm not talking about something extremely complicated - just the code where few bits must

[Bug inline-asm/69248] New: VFP register constraint 'w' is ignored when optimizations are enabled

2016-01-12 Thread vorfeed.canal at gmail dot com
ty: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: vorfeed.canal at gmail dot com Target Milestone: --- Looks like optimizations confuse something in GCC and cause it to ignore proper 'w' constraint.

[Bug ada/49732] New: GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9

2011-07-13 Thread vorfeed.canal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 Summary: GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P

[Bug ada/49732] GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9

2011-07-14 Thread vorfeed.canal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 --- Comment #2 from Vorfeed Canal 2011-07-14 12:07:01 UTC --- Which compilation options? I'm not specifying anything strange and even if I use -O0 the result is the same: /localbuild/build/sysnative-prencurses-5.9/narrowc/Ada95/src$ gnatmake -O0

[Bug ada/49732] GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9

2011-07-14 Thread vorfeed.canal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 --- Comment #4 from Vorfeed Canal 2011-07-14 13:22:31 UTC --- Ah, I see. Well, it looks it's -gnatafno option which triggers the error. And I have no idea what it's supposed to do :-( /localbuild/build/sysnative-prencurses-5.9/narrowc/Ada95/src$

[Bug ada/49732] GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9

2011-07-14 Thread vorfeed.canal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 --- Comment #6 from Vorfeed Canal 2011-07-14 13:52:07 UTC --- Ah-ha. Here we go: gcc -c -O0 -gnato -I- -gnatA /ncplc/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-menus.adb raised STORAGE_ERROR : stack overflow (or erroneous

[Bug ada/49732] [4.6/4.7 regression] crash on terminal_interface-curses-menus.adb from ncurses with -gnato

2011-07-14 Thread vorfeed.canal at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 --- Comment #8 from Vorfeed Canal 2011-07-14 14:43:49 UTC --- It makes sense because patch which "fixes" the problem effectively removes the information needed to do overflow check. And now, when I know where to look is much smaller reproducer:

[Bug c++/104652] New: It's impossible to declare non-default target function as a friend.

2022-02-22 Thread vorfeed.canal at gmail dot com via Gcc-bugs
ormal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vorfeed.canal at gmail dot com Target Milestone: --- The following example generates error with GCC 11.2 and trunk: https://godbolt.org/z/MKo9Whsf5 class Foo { p

[Bug c++/104652] It's impossible to declare non-first target function as a friend

2022-05-16 Thread vorfeed.canal at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104652 --- Comment #2 from Vorfeed Canal --- Thanks for showing a workaround: class Foo { public: explicit Foo(int f) : x(f) {} [[gnu::target("default")]] friend inline Foo bar(Foo& foo) { return Foo(foo.x); } [[gnu::target("