[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: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mib.bugzi...@gmail.com gcc 4.8 changes.html file gives this example: alignas(double) int i; But the snapshot from Oct 14 2012 gives this message: g++ -c -std=c++11 alignas.cpp alignas.cpp:1:1: error: expected unqualified-id before 'alignas' alignas(double) int f; ^ If alignas is moved to the end of the declaration it compiles okay: int f alignas(double); doc error? Could you also confirm whether c++11 keyword alignas is the same as c1x _Alignas? Thanks and regards
[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 report
[Bug c++/57362] New: unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 Bug ID: 57362 Summary: unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior Product: gcc Version: unknown Status: UNCONFIRMED 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 experimenting with what values might be acceptable to gcc 4.8 __attribute__((target())) I expected that the compiler would flag the targets that weren't recognized and then quit, but it ran a very long time (5 minutes?). I stopped the job and process cc1plus was still running.
[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-wrapper Target: x86_64-unknown-linux-gnu Configured with: /rusers/sys_cron/grab_gcc/downloads_rel/4.8.0/gcc-4.8.0/configure --prefix=/rdrive/ref/gcc/4.8.0/rhel60/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 Thread model: posix gcc version 4.8.0 (GCC)
[Bug c++/57375] New: gnu multiversioning selects different version depending on link order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375 Bug ID: 57375 Summary: gnu multiversioning selects different version depending on link order Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal 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) Is this expected? % /rdrive/ref/gcc/bin/g++48 mv12-aux.cc mv12-aux1.cc mv12.C % ./a.out foo is 7 % /rdrive/ref/gcc/bin/g++48 mv12.C mv12-aux.cc mv12-aux1.cc % ./a.out foo is 0 (The call to foo from different compilation units has different visibility to which versions are available) /rdrive/ref/gcc/bin/g++48 -v 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-wrapper Target: x86_64-unknown-linux-gnu Configured with: /rusers/sys_cron/grab_gcc/downloads_rel/4.8.0/gcc-4.8.0/configure --prefix=/rdrive/ref/gcc/4.8.0/rhel60/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 Thread model: posix gcc version 4.8.0 (GCC)
[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++/57378] New: gnu multiversioning gives assembler error: foo.resolver is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378
Bug ID: 57378
Summary: gnu multiversioning gives assembler error:
foo.resolver is already defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: 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 already defined
% cat foo.cpp
int foo () __attribute__ ((target ("default")));
int foo () __attribute__ ((target ("arch=core2")));
static int fumm();
#include
int main ()
{
int f = foo();
printf("foo is %d\n", f);
printf("fumm is %d\n", fumm());
return 0;
}
__attribute__ ((target ("default")))
int foo () { return 0; }
__attribute__ ((target ("arch=corei7")))
int foo () { return 7; }
static int fumm()
{ return foo(); }
% /rdrive/ref/gcc/bin/g++48 -v
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-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.0/gcc-4.8.0/configure
--prefix=/rdrive/ref/gcc/4.8.0/rhel60/efi2
--enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap
--target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
Thread model: posix
gcc version 4.8.0 (GCC)
Platform is corei7 (sandybridge)
[Bug c++/57546] New: templated gnu multiversion function pointer returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546
Bug ID: 57546
Summary: templated gnu multiversion function pointer returns
wrong value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: 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 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 version of foo. */
__attribute__ ((target("default")))
T foo () { return 0; }
/* corei7 version of foo. */
__attribute__ ((target("arch=corei7")))
T foo () { return 0; }
T (Foo::*p)() = &Foo::foo; // pointer to member
};
#include
int main ()
{
Foo f;
int i = f.foo();
int j = (f.*(f.p))(); // pointer to member call
if (i==j && j==0) {
printf("PASSED\n");
return 0;
} else {
printf("FAILED i:%d j:0x%x\n", i, j);
return -1;
}
}
-bash-4.1$ /rdrive/ref/gcc/bin/g++48 -v
Using built-in specs.
COLLECT_GCC=/rdrive/ref/gcc/4.8.1/rhel60/x86/bin/g++
COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.1/rhel60/x86/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure
--prefix=/rdrive/ref/gcc/4.8.1/rhel60/x86 --enable-languages=c,c++,objc,fortran
--disable-multilib --target=i686-pc-linux-gnu --disable-bootstrap
--enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/x86
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug c++/57548] New: calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548
Bug ID: 57548
Summary: calling gnu multiversioned function at file scope
causes ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: 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 mv1.cpp
mv1.cpp:28:13: internal compiler error: Segmentation fault
int j = fum();
^
0x84eaa07 crash_signal
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/toplev.c:332
0x868bd44 ix86_can_inline_p
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/config/i386/i386.c:4498
0x8102760 build_over_call
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/call.c:7044
0x8106154 build_new_function_call(tree_node*, vec**, bool, int)
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/call.c:3918
0x81bbdef finish_call_expr(tree_node*, vec**,
bool, bool, int)
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/semantics.c:2220
0x8176dd7 cp_parser_postfix_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:5855
0x8178a82 cp_parser_unary_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:6729
0x8179532 cp_parser_binary_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7421
0x8179ab0 cp_parser_assignment_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7657
0x8179f29 cp_parser_assignment_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7707
0x8179f29 cp_parser_constant_expression
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:7917
0x818303a cp_parser_init_declarator
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:16095
0x8184d49 cp_parser_simple_declaration
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10670
0x81726d6 cp_parser_block_declaration
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10551
0x818c2b4 cp_parser_declaration
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10448
0x818c676 cp_parser_declaration_seq_opt
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:10334
0x818cac4 cp_parser_translation_unit
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:3813
0x818cac4 c_parse_file()
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/cp/parser.c:28338
0x8227d5a c_common_parse_file()
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Test case:
int fum (); // Extra declaration that is merged with the second one.
int fum () __attribute__ ((target("default")));
#if 0
// gcc doesn't recognize cmov
int fum () __attribute__((target( "cmov")));
#endif
int fum () __attribute__((target( "mmx")));
int fum () __attribute__((target( "popcnt")));
int fum () __attribute__((target( "sse")));
int fum () __attribute__((target( "sse2")));
int fum () __attribute__((target( "sse3")));
int fum () __attribute__((target( "ssse3")));
int fum () __attribute__((target( "sse4.1")));
int fum () __attribute__((target( "sse4.2")));
int fum () __attribute__((target( "avx")));
int fum () __attribute__((target( "avx2")));
int fum () __attribute__((target("arch=core2")));
int fum () __attribute__((target("arch=corei7")));
int fum () __attribute__((target("arch=atom")));
int (*p)() = &fum;
int j = fum();
[Bug c++/57561] New: gnu function multiversion - resolver doesn't use isa priority according to documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57561
Bug ID: 57561
Summary: gnu function multiversion - resolver doesn't use isa
priority according to documentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
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 not preceed sse4.2
(Using gcc 4.8.1 on x86 system)
grep movl fu.s | grep arch
movl$_Z3fumv.arch_corei7_avx2, %eax
movl$_Z3fumv.arch_corei7_avx, %eax
movl$_Z3fumv.arch_corei7_popcnt, %eax
movl$_Z3fumv.arch_corei7_mmx, %eax
movl$_Z3fumv.arch_corei7_sse4.2, %eax
movl$_Z3fumv.arch_corei7_sse4.1, %eax
movl$_Z3fumv.arch_corei7_ssse3, %eax
movl$_Z3fumv.arch_corei7_sse, %eax
movl$_Z3fumv.arch_corei7_sse2, %eax
movl$_Z3fumv.arch_corei7_sse3, %eax
cat fu.cpp
__attribute__ ((target("default"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,sse3"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,sse2"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,sse"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,ssse3"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,sse4.1"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,sse4.2"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,popcnt"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,avx"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,avx2"))) int fum () { return 0; }
__attribute__ ((target("arch=corei7,mmx"))) int fum () { return 0; }
int (*p)() = &fum;
int foo(void)
{
int j = fum();
return j;
}
[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 com --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 30591 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30591&action=edit test case without template, also segfault
[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 specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.1/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure --prefix=/rdrive/ref/gcc/4.8.1/rhel60/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 Thread model: posix gcc version 4.8.1 (GCC)
[Bug c++/58060] New: separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060
Bug ID: 58060
Summary: separate compilation of gnu multiversioning gives
undefined/multiple defined symbols at link time
Product: gcc
Version: unknown
Status: UNCONFIRMED
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 tried gnu multiversioning with separate compilation but I get both these
messages at link time: multiple defined symbols and undefined symbol.
g++ -o foo.exe mv6c-1.o mv6c.o
mv6c.o: In function `foo()':
mv6c.C:(.text+0x0): multiple definition of `foo()'
mv6c-1.o:mv6c-1.C:(.text+0x0): first defined here
mv6c-1.o: In function `_Z3foov.resolver':
mv6c-1.C:(.text._Z3foov.resolver[_Z3foov.resolver]+0x1b): undefined reference
to `_Z3foov.arch_corei7'
collect2: error: ld returned 1 exit status
-bash-4.1$ cp mv6c*C ~/my_home
-bash-4.1$ cat mv6c.C
/* corei7 version of foo. */
__attribute__ ((target("arch=corei7")))
int foo () { return 7; }
// I thought this compilation unit would create a function with the name
arch_corei7, but it just creates a foo without target decoration
[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/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: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
Two questions about diagnostics on templated/non-templated function
redeclarations and the presence of attribute stdcall
Question 1:
// no error for non template function redeclaration, i.e.:
void __attribute((stdcall)) f(int);
void f(int) {;} // compiles fine
// but on x86, g++ 4.6 and later give an error if function is a template --
Why?
template void __attribute__((stdcall)) f2(int);
template void f2(int) {;} // error here?
test3.c:2:31: error: new declaration âtemplate void f2(int)â
test3.c:1:50: error: ambiguates old declaration âtemplate void
f2(int)â
Question 2:
On x86 (not x64) this test case gets an error when compiled with gcc 4.6.2, but
there is no error when compiled with g++. Is this intentional or should an
error be produced in g++ as well?
% cat test2.c
// no error for non template function redeclaration, i.e.:
void __attribute((stdcall)) f(int);
void f(int a) {;} // compiles fine
gcc -c test2.c
test2.c:3:7: error: conflicting types for âfâ
test2.c:2:30: note: previous declaration of âfâ was here
% g++ -c test2.c
// no error
[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
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
It look like g++ emit error for regular functions but not for new. Here is the
example:
For following test case g++ emit error for foo but not for operator new.
class bad_alloc
{
public:
bad_alloc() throw() { }
};
struct nothrow_t { };
extern const nothrow_t nothrow;
typedef unsigned long size_t;
//void* operator new(size_t) noexcept;
void* operator new(size_t, const nothrow_t&);
void foo();
int main(int argc, char *argv[])
{
void* (*pf)(size_t) throw (bad_alloc) = operator new;
void* (*pf1)() throw (bad_alloc) = foo;
}
[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: x86_64-unknown-linux-gnu Configured with: /home/myuser/d/gcc_src/gcc-4.7.0/configure --prefix=/rdrive/ref/gcc/4.7.0/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/home/myuser/d/gcc_src/lib/efi2 --with-mpfr=/home/myuser/d/gcc_src/lib/efi2 --with-mpc=/home/myuser/d/gcc_src/lib/efi2 Thread model: posix gcc version 4.7.0 (GCC) g++ -c fubar.cpp fubar.cpp: In function âint main(int, char**)â: fubar.cpp:16:40: error: invalid conversion from âvoid (*)()â to âvoid* (*)()â [-fpermissive]
[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 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mib.bugzi...@gmail.com This url http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html shows these 2 intrinsics declared like this: Built-in Function: bool __atomic_always_lock_free (size_t size) Built-in Function: bool __atomic_is_lock_free (size_t size) But there are test cases for these 2 functions that have 2nd argument (memmodel) e.g. atomic-lockfree.c lines 23 and 24 r1 = __atomic_always_lock_free (sizeof(char), 0); r2 = __atomic_is_lock_free (sizeof(char), 0); Please clarify, thanks!
[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 Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mib.bugzi...@gmail.com The link below is referred to from a couple of pages (e.g. http://gcc.gnu.org/wiki/Atomic#Status), but it's "not found" http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html#Atomic-Builtins
[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
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
Created attachment 26764
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26764
Detailed description of the error
If option -mcx16 is used, the bug doesn't exhibit. Verbose information about
compiler build etc in attachment
extern void abort(void);
__int128_t v=0, count=0;
extern int result;
int foo ()
{
result = __atomic_load_n (&v, __ATOMIC_RELAXED);
return 0;
}
[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
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
The C standard is very clear that the second argument to va_start is a
parameter identifier, not an expression.
For example,
int maxof(int, ...) ;
void f(void);
int maxof(int n_args, ...){
register int i;
int max, a;
va_list ap;
va_start(ap, (unsigned int)n_args);
max = va_arg(ap, int);
for(i = 2; i <= n_args; i++) {
if((a = va_arg(ap, int)) > max) max = a;
}
va_end(ap);
return max;
}
Intel compiler finds the bug:
vaarg.c(12): error: incorrect use of va_start
va_start(ap, (unsigned int)n_args);
^
[Bug c++/58848] New: constexpr function allows throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58848
Bug ID: 58848
Summary: constexpr function allows throw
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
complicated test case allows the throw. Attaching 2 test cases
Bad:
g++ constexp_error.cpp -std=c++0x
-bash-4.1$ ./a.out
fail, exception raised
Good:
g++ constexp_ok.cpp -std=c++0x
constexp_ok.cpp: In function âint main()â:
constexp_ok.cpp:15:47: in constexpr expansion of
âfum::numSubEntities(5)â
constexp_ok.cpp:8:73: error: expression ââ is not a
constant-expression
throw std::out_of_range("a point has only subentities of codim=0");
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/rdrive/ref/gcc/4.8.1/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure
--prefix=/rdrive/ref/gcc/4.8.1/rhel60/efi2
--enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap
--target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
Thread model: posix
gcc version 4.8.1 (GCC)
[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 compilation error because of the throw.
[Bug c++/89345] New: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 Bug ID: 89345 Summary: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal 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 you modify this to use the macro e.g. _GLIBCXX_CONSTEXPR. For example, recently the clang compiler predefines __cpp_impl_destroying_delete and this causes the header to fail compilation if compiling with option -std=c++98. This issue is discussed here, https://reviews.llvm.org/D55741 Thanks and regards --Melanie Blower (I work on the Intel C++ compiler)
[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/85054] New: gcc8 fail to identify template redeclaration - problem in string header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85054
Bug ID: 85054
Summary: gcc8 fail to identify template redeclaration - problem
in string header
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
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 a bug report at llvm and Richard Smith
provided this analysis of the issue:
This is CWG issue 1980 (wg21.link/cwg1980, which is still open at the time of
writing).
Further reduced and cleaned up:
template using void_t = void;
template struct X;
template struct X> {};
template struct X {};
Same question as applied to function template overloads:
template void f(X>) {}
template void f(X) {}
[temp.alias]p2 says:
"When a template-id refers to the specialization of an alias template, it is
equivalent to the associated type obtained by substitution of its
template-arguments for the template-parameters in the type-id of the alias
template."
Now, "equivalent" here means equivalent in the [temp.over.link] sense -- in
particular, it is intended that you can redeclare function templates with and
without manually expanding alias templates that they name. Which means the two
function templates, and the two partial specializations, are equivalent (but,
oddly, not functionally-equivalent).
Since they're equivalent, they're redeclarations, at least in today's standard
wording.
https://bugs.llvm.org/show_bug.cgi?id=36869
--Melanie Blower (I work for Intel on the Intel C++ compiler)
[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
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type. gcc appears to be ignoring
the underlying type, as the value of E_ in this example is 4
gpp48 bug1.cpp -std=c++0x
bug1.cpp: In function âint main()â:
bug1.cpp:4:3: error: static assertion failed: E_ should be 1
static_assert( E_ == 1, "E_ should be 1");
^
enum e_ : unsigned char { Z_, E_=sizeof(Z_) };
#include
int main(void) {
static_assert( E_ == 1, "E_ should be 1");
printf("z is %d e is %d\n", Z_, E_ ); // prints 4
printf("sizeof unsigned char is %d\n", sizeof(unsigned char)); // prints 1
printf("sizeof e_ is %d\n", sizeof(e_)); // prints 1
return 0;
}
[Bug libstdc++/79156] New: incorrect c++ usage in gcc7 void function returns a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156
Bug ID: 79156
Summary: incorrect c++ usage in gcc7 void function
returns a value
Product: gcc
Version: unknown
Status: UNCONFIRMED
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 on the Intel c++ compiler and I found this problem when compiling
the gcc7 version of dated Jan 1, 2017. I believe the error message is
accurate and it could be fixed with a minor change.
In file included from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr.h(52),
from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/memory(81),
from mem.cpp(1):
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr_base.h(1823):
error: return value type does not match the function type
{ return __p; }
The function being complained about looks like this:
friend void
__enable_shared_from_this_base(const __shared_count<_Lp>&,
const __enable_shared_from_this* __p)
{ return __p; }
mutable __weak_ptr<_Tp, _Lp> _M_weak_this;
};
Changing "friend void" to "friend auto" would be a simple fix.
Thanks and regards, Melanie Blower (melanie dot blower at intel dot com)
[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++/78326] New: incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326
Bug ID: 78326
Summary: incorrect c++ usage in experimental/vector and others?
_X_max_align is inaccessible
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
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 on Linux host. When we compile the
experimental/vector file we are finding a programming problem. We've also
compiled this construct using the Microsoft visual studio compiler and the
clang compiler, those compilers likewise are not able to process this
construct.
Here's what our compiler reports:
include/c++/6.2.0/experimental/memory_resource(284): error #308: member
"std::experimental::fundamentals_v2::pmr::memory_resource::_S_max_align"
(declared at line 74) is inaccessible
__alignment : _S_max_align);
^
detected during instantiation of "void
*std::experimental::fundamentals_v2::pmr::__resource_adaptor_imp<_Alloc>::do_allocate(std::size_t={unsigned
long}, std::size_t={unsigned long}) [with _Alloc=std::allocator]"
Using creduce, we created this smaller test case:
icpc -c vecE.cpp -w
vecE.cpp(14): error #308: member "C::_S_max_align" (declared at line 10) is
inaccessible
size_t __new_size = _S_max_align;
^
detected during instantiation of "void *D<>::m_fn1() [with
=B::rebind_alloc]"
compilation aborted for vecE.cpp (code 2)
-bash-4.2$ cat !$
cat vecE.cpp
typedef int size_t;
class A;
struct B {
template < typename > using rebind_alloc = A;
};
template < typename > class D;
template < typename > using resource_adaptor = D < B::rebind_alloc < int >>;
class C {
static constexpr size_t
_S_max_align = 0;
};
template < typename > class D:C {
virtual void * m_fn1 () {
size_t __new_size = _S_max_align;
}
};
resource_adaptor < A > __get_default_resource___r;
What do you think, is it possible you could correct this? We see the same
diagnostic in experimental/unordered_set, unordered_map, string, set, regex,
memory_resource, map, list, forward_list, dequeue
Thanks and regards, Melanie Blower
[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 regards.
Here's a further investigation showing an inconsistency around this issue:
If you compile this with –DNOTEMPLATE (making Derived a non template class)
then GNU will issue an access error.
But if Derived is a template class, then GNU incorrectly allows it.
/*
This shows the GNU inconsistency -- no diagnostic is issued if Derived is a
template class.
Clang, EDG, and Microsoft issue an error if Derived is a template or if it is
not.
sptxl15-478> g++6 -c -w tt.cpp
sptxl15-479> g++6 -c -w -DNOTEMPLATE tt.cpp
tt.cpp: In member function ‘void Derived::foo()’:
tt.cpp:15:17: error: ‘int Base::j’ is private within this context
int i = j;
^
tt.cpp:4:15: note: declared private here
static int j;
^
tt.cpp:15:17: error: ‘int Base::j’ is private within this context
int i = j;
^
tt.cpp:4:15: note: declared private here
static int j;
^
sptxl15-480>
*/
class Base
{
static int j;
};
#ifdef NOTEMPLATE
#else
template
#endif
struct Derived : public Base
{
void foo()
{
int i = j;
}
};
int main() {
#ifdef NOTEMPLATE
Derived d;
#else
Derived d;
#endif
d.foo();
return 0;
}
[Bug c++/59865] New: gnu multiversion calculates wrong target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865
Bug ID: 59865
Summary: gnu multiversion calculates wrong target
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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, because corei7 supports popcnt as well.
however, gcc 4.8.1 is choosing the popcnt target, not the corei7 target.
Do you expect this discrepancy will be fixed?
Test case:
cat corei7.C
#include
int __attribute__ ((target("default")))
foo() { puts("default wins\n"); }
int __attribute__((target("arch=corei7")))
foo() { puts("corei7 wins\n"); }
int __attribute__((target("popcnt")))
foo() { puts("popcnt wins\n"); }
int main ()
{
int val = foo ();
return 0;
}
-bash-4.1$ g++ corei7.C
-bash-4.1$ ./a.out
popcnt wins
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/rdrive/ref/gcc/4.8.1/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure
--prefix=/rdrive/ref/gcc/4.8.1/rhel60/efi2
--enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap
--target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float
--with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
--with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2
Thread model: posix
gcc version 4.8.1 (GCC)
Quoting the wiki:
When a function version with target attribute "arch=" is compared
with a function version with attribute "", then the highest priority of
the any ISA supported by processor X is compared to the priority of ISA Y to
decide which version should be dispatched first. If the priorities are the same
then the version with "arch=" is given precedence. For instance, when comparing
"arch=corei7" and "popcnt", "arch=corei7" wins since the priority of the
highest ISA supported by corei7 is popcnt.
[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=corei7. I was testing to see the precendence of arch= versus isa by
creating foo for all isa, then seeing where a single arch= is sorted in the
dispatch function.
cat core-pop.C
#include
#include
#include
const char * __attribute__ ((target("default"))) foo(void)
{ return("default wins\n");}
const char* __attribute__ ((target("arch=corei7"))) foo(void)
{ return("corei7 wins\n");}
const char* __attribute__ ((target("popcnt"))) foo(void)
{ return("popcnt wins\n");}
int main ()
{
const char *result = foo ();
if (__builtin_cpu_is ("corei7")) puts("builtin cpu is corei7\n");
if (__builtin_cpu_is ("corei7"))
assert ( 0 == strcmp(result, "corei7 wins"));
return 0;
}
-bash-4.1$ g++ core-pop.C -S
-bash-4.1$ g++ core-pop.C
-bash-4.1$ grep movl core-pop.s | grep foov //From dispatch function
movl$_Z3foov.popcnt, %eax
movl$_Z3foov.arch_corei7, %eax
movl$_Z3foov, %eax
-bash-4.1$ ./a.out
builtin cpu is corei7
a.out: core-pop.C:15: int main(): Assertion `0 == strcmp(result, "corei7
wins")' failed.
Aborted (core dumped)
[Bug c++/61873] New: with -openmp, -E does not produce preprocessed output on stdout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61873 Bug ID: 61873 Summary: with -openmp, -E does not produce preprocessed output on stdout Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal 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 %
