[Bug c/57657] New: [regression from 4.7] Reports incorrect cache sizes on corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657 Bug ID: 57657 Summary: [regression from 4.7] Reports incorrect cache sizes on corei7 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thomas.br...@virtuell-zuhause.de I have a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GH" CPU and I'm on debian unstable. The bottom line is that gcc-4.8 reports incorrect cache sizes compared to gcc-4.7. #gcc-4.8 -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-3) Calling #gcc-4.8 -### -E -march=native /usr/include/stdlib.h 2>&1 | grep cache-size gives /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -E -quiet -imultilib . -imultiarch x86_64-linux-gnu /usr/include/stdlib.h "-march=corei7-avx" -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param "l1-cache-size=0" --param "l1-cache-line-size=0" --param "l2-cache-size=256" "-mtune=corei7-avx" Whereas #cat /proc/cpuinfo | grep -E "(cache size|cache_alignment)" | tail -n 2 says cache size : 12288 KB cache_alignment : 64 Using an older version of gcc #gcc-4.7 --version gcc-4.7 (Debian 4.7.3-5) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE I get what I expect #gcc-4.7 -### -E -march=native /usr/include/stdlib.h 2>&1 | grep cache-size /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -imultilib . -imultiarch x86_64-linux-gnu /usr/include/stdlib.h "-march=corei7-avx" -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=12288" "-mtune=corei7-avx Thanks for reading Thomas PS: Output of cpuid eax ineax ebx ecx edx 000d 756e6547 6c65746e 49656e69 0001 000206d7 03200800 1fbee3bf bfebfbff 0002 76035a01 00f0b2ff 00ca 0003 0004 0005 0040 0040 0003 00021120 0006 0077 0002 0009 0007 0008 0009 0001 000a 07300403 0603 000b 002c 0003 000c 000d 8000 8008 8001 0001 2c100800 8002 20202020 49202020 6c65746e 20295228 8003 65726f43 294d5428 2d376920 30333933 8004 5043204b 20402055 30322e33 007a4847 8005 8006 01006040 8007 0100 8008 302e Vendor ID: "GenuineIntel"; CPUID level 13 Intel-specific functions: Version 000206d7: Type 0 - Original OEM Family 6 - Pentium Pro Model 13 - Stepping 7 Reserved 8 Extended brand string: " Intel(R) Core(TM
[Bug c++/58091] Non-ambiguous member lookup rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091
Thomas Braun changed:
What|Removed |Added
CC||thomas.braun@virtuell-zuhau
||se.de
--- Comment #4 from Thomas Braun ---
The example can be even more simplified:
namespace NS
{
template < typename T >
struct NS {};
}
int main()
{
using namespace NS;
NS a;
}
And the same error message:
test.cpp: In function ‘int main()’:
test.cpp:11:3: error: reference to ‘NS’ is ambiguous
test.cpp:3:1: error: candidates are: namespace NS { }
test.cpp:5:10: error: template struct NS::NS
test.cpp:11:6: error: expected primary-expression before ‘int’
test.cpp:11:6: error: expected ‘;’ before ‘int’
I tried g++ 4.4, 4.6 and 4.7.
[Bug c++/58888] New: [c++11] Rejects-valid: static member with auto and initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug ID: 5
Summary: [c++11] Rejects-valid: static member with auto and
initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.br...@virtuell-zuhause.de
The following code is rejected by
~/gcc-4.8.2/bin/g++ -std=c++11 test.cpp
#include
struct A
{
static constexpr auto b{1.0};
};
constexpr decltype(A::b) A::b;
int main(int argc, char** argv)
{
std::cout << &A::b << std::endl;
}
with the message
#
test.cpp:46:30: error: invalid use of 'auto'
static constexpr auto b{1.0};
^
test.cpp:49:30: error: invalid type in declaration before ';' token
constexpr decltype(A::b) A::b;
^
test.cpp:49:30: error: declaration of 'constexpr A::b' outside
of class is not definition [-fpermissive]
#
I'm using g++ (GCC) 4.8.2.
My interpretation of &7.1.6.4 is that this code is valid, clang accepts the
code and
http://stackoverflow.com/questions/12834874/auto-static-in-class-constant-initalization-with-meta-programming
also suggests that it is valid.
[Bug c++/58986] New: [C++11] Narrowing for initializer lists must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58986
Bug ID: 58986
Summary: [C++11] Narrowing for initializer lists must be an
error
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.br...@virtuell-zuhause.de
Compiling
#
struct B {
B(int, double) {}
};
void g(B) {};
int main(int argc, char** argv)
{
g( {'a', 'b'} ); // OK: g(B(int,double)) user-defined conversion
g( {1.0, 1.0} ); // error: narrowing
}
#
with LANG=C g++ -std=c++11 gcc-bug-narrowing.cpp
with g++ 4.8.2 compiles fine with the warning:
#
gcc-bug-narrowing.cpp: In function 'int main(int, char**)':
gcc-bug-narrowing.cpp:9:17: warning: narrowing conversion of '1.0e+0' from
'double' to 'int' inside { } [-Wnarrowing]
g( {1.0, 1.0} ); // error: narrowing
#
Although C++11 standard §13.3.3.1.5 3 states that narrowing for initializer
lists is an error.
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #4 from Thomas Braun --- (I'm no gcc dev at all) In general gcc is much better in doing NRVO/URVO than other compilers according to my analysis [1]. So maybe the competitors need to get better first ;) [1]: http://www.byte-physics.de/cpp-copy-elision
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #7 from Thomas Braun ---
> The three cases (L, P, R) where GCC is "better" is actually non-conforming.
Could you elaborate on that?
For example case L is:
X nrvo_two_different_tern()
{
trace t("nrvo_two_different_tern");
const bool param = true;
X a, b;
return param ? a : b;
}
which always returns a.
[Bug c/71897] New: crashed on querying help information from command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71897 Bug ID: 71897 Summary: crashed on querying help information from command line Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thomas.br...@virtuell-zuhause.de Target Milestone: --- GCC told me to come here. $/rest/inst/gcc-6.1.0/usr/local/bin/gcc --help=^ cc1: internal compiler error: Speicherzugriffsfehler 0x9c70ff crash_signal ../../gcc/toplev.c:333 0x1008c00 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option const*, unsigned int, int, unsigned int, cl_option_handlers const*, diagnostic_context*) ../../gcc/opts.c:1615 0x100c457 handle_option ../../gcc/opts-common.c:981 0x100c586 read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*, unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*) ../../gcc/opts-common.c:1180 0x9157a7 read_cmdline_options ../../gcc/opts-global.c:229 0x9157a7 decode_options(gcc_options*, gcc_options*, cl_decoded_option*, unsigned int, unsigned int, diagnostic_context*) ../../gcc/opts-global.c:308 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. $/rest/inst/gcc-6.1.0/usr/local/bin/gcc --version gcc (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
