[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 --- Comment #4 from mib.bugzilla at gmail dot com --- thank you!

[Bug c++/89345] New: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Target Milestone: --- In the patch to add destroying_delete, (Implement P0722R3, destroying operator delete.) the constexpr token is used directly, can

[Bug c/85054] New: gcc8 fail to identify template redeclaration - problem in string header

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Target Milestone: --- The Intel compiler and clang compiler finds an error in gcc8 string header [now fixed] which gcc didn't find. I opened

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 --- Comment #4 from mib.bugzilla at gmail dot com --- Thank you so much! (That means I won't need to change the Intel compiler to accommodate). Best regards

[Bug libstdc++/79156] New: incorrect c++ usage in gcc7 void function returns a value

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Target Milestone: --- Hello, I work on the Intel c++ compiler and I found this problem when compiling the gcc7 version of dated Jan 1, 2017. I believe

[Bug libstdc++/78326] incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326 --- Comment #5 from mib.bugzilla at gmail dot com --- Thanks so much. It would be great if this problem could be identified in the compiler, could you create a bug report, or just add another remark if you want me to create the bug report. Best

[Bug libstdc++/78326] New: incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible

Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Target Milestone: --- Hello, I work for Intel on the Intel c++ compiler and our compiler uses the g++ headers when we are compiling

[Bug c++/61873] New: with -openmp, -E does not produce preprocessed output on stdout

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com % g++ -c -E omp1.cpp # 1 "omp1.cpp" # 1 "" # 1 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "" 2 # 1 "omp1.cpp" int i; % g++ -c -openmp -E omp1.cpp %

[Bug c++/59865] gnu multiversion calculates wrong target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865 --- Comment #2 from mib.bugzilla at gmail dot com --- Thanks. I realized after I posted that the test case isn't definitive. Improved test case pasted below. Inspection of the assembly listing shows that popcnt is being checked before arch=c

[Bug c++/59865] New: gnu multiversion calculates wrong target

++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com According to the gnu multiversion wiki, if a target function is specified with arch=corei7, and another taret function is specified with "popcnt", then the arch= function should win, beca

[Bug c++/58848] constexpr function allows throw

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58848 --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 31073 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31073&action=edit simpler test case gets compilation error (good) both test cases should get a compilatio

[Bug c++/58848] New: constexpr function allows throw

++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Created attachment 31072 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31072&action=edit should get compilation error A simple test case rejects throw inside constexpr function, but a more comp

[Bug c++/58060] separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060 --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 30593 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30593&action=edit test case part 2

[Bug c++/58060] New: separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Created attachment 30592 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30592&action=edit test case part 1 I tr

[Bug c++/57546] templated gnu multiversion function pointer returns wrong value

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546 --- Comment #2 from mib.bugzilla at gmail dot com --- I rerun this test today and the program segfaults. Also get the same behavior (segfault) if the template is removed. I'll attach the non-templated test case g++ -v Using built-in

[Bug c++/57546] templated gnu multiversion function pointer returns wrong value

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546 mib.bugzilla at gmail dot com changed: What|Removed |Added CC||mib.bugzilla at gmail dot

[Bug c++/57561] New: gnu function multiversion - resolver doesn't use isa priority according to documentation

IRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com In this test case, the resolver function doesn't find the correct version, according to the documentation e.g. mmx should n

[Bug c++/57548] New: calling gnu multiversioned function at file scope causes ICE

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com /rdrive/ref/gcc/bin/g++48 -c mv1.cpp mv1.cpp:28:13: internal compiler error: Segmentation fault int j = fum(); ^ 0x84eaa07 crash_signal

[Bug c++/57546] New: templated gnu multiversion function pointer returns wrong value

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com /rdrive/ref/gcc/bin/g++48 fum.cpp -std=c++0x -bash-4.1$ ./a.out FAILED i:0 j:0x80499c6 -bash-4.1$ cat fum.cpp template class Foo { public: /* Default

[Bug c++/57378] New: gnu multiversioning gives assembler error: foo.resolver is already defined

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com % /rdrive/ref/gcc/bin/g++48 -c foo.cpp /tmp/cc9uFaZR.s: Assembler messages: /tmp/cc9uFaZR.s:116: Error: symbol `_Z3foov.resolver' is al

[Bug c++/57375] gnu multiversioning selects different version depending on link order

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375 --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 30166 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30166&action=edit Test case

[Bug c++/57375] New: gnu multiversioning selects different version depending on link order

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com With the attached program, a call to multiversioned foo selects either the default or corei7 version, depending on the link order. (Platform is corei7

[Bug c++/57362] unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 --- Comment #1 from mib.bugzilla at gmail dot com --- Using built-in specs. COLLECT_GCC=/rdrive/ref/gcc/4.8.0/rhel60/efi2/bin/g++ COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.0/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto

[Bug c++/57362] New: unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mib.bugzilla at gmail dot com Created attachment 30158 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30158&action=edit Test case I was experi

[Bug c++/56155] New: [C++0X] enumeration with fixed underlying type - enum literals have wrong type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56155 Bug #: 56155 Summary: [C++0X] enumeration with fixed underlying type - enum literals have wrong type Classification: Unclassified Product: gcc Version: unknown Statu

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54955 --- Comment #1 from mib.bugzilla at gmail dot com 2012-10-17 16:21:56 UTC --- p.s. This example is given here: http://en.cppreference.com/w/cpp/language/alignas char alignas(128) cacheline[128]; but g++ complains similarly to the root

[Bug c++/54955] New: alignas example in gcc 4.8 changes.html won't compile

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54955 Bug #: 54955 Summary: alignas example in gcc 4.8 changes.html won't compile Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: n

[Bug c++/54196] gcc doesn't find incompatible exception specification for operator

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196 --- Comment #1 from mib.bugzilla at gmail dot com 2012-08-07 18:57:28 UTC --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.7.0/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target

[Bug c++/54196] New: gcc doesn't find incompatible exception specification for operator

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196 Bug #: 54196 Summary: gcc doesn't find incompatible exception specification for operator Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED

[Bug c/53716] New: Intentional or bug? Inconsistencies in error diagnostics in function redeclaration involving stdcall attribute

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53716 Bug #: 53716 Summary: Intentional or bug? Inconsistencies in error diagnostics in function redeclaration involving stdcall attribute Classification: Unclassified Product

[Bug c/52534] New: gcc doesn't detect incorrect expression in call to va_start

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52534 Bug #: 52534 Summary: gcc doesn't detect incorrect expression in call to va_start Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED

[Bug c/52404] New: internal compiler error: in setup_min_max_allocno_live_range_point, at ira-build.c:2425

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52404 Bug #: 52404 Summary: internal compiler error: in setup_min_max_allocno_live_range_point, at ira-build.c:2425 Classification: Unclassified Product: gcc Versio

[Bug c/52382] New: Atomic builtins documentation, page not found

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52382 Bug #: 52382 Summary: Atomic builtins documentation, page not found Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Prio

[Bug c/52190] New: question about atomic intrinsics -- test and documentation vary -- please clarify

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190 Bug #: 52190 Summary: question about atomic intrinsics -- test and documentation vary -- please clarify Classification: Unclassified Product: gcc Version: 4.7.0 Statu