Created attachment 48494 [details] Original source file triggering the bug. With the attached cpp-file, a strange behaviour is triggered. Tested with g++-10.1 built with docker (docker run gcc:10.1). The bug is also present in g++-7.5.0. Upon compiling the attached source file, this output is obtained: ===== # g++ -v -c -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -save-temps test_fragmentation.cpp Using built-in specs. COLLECT_GCC=g++ Target: x86_64-linux-gnu Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-linux-gnu/10.1.0/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test_fragmentation.cpp -mtune=generic -march=x86-64 -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fpch-preprocess -o test_fragmentation.ii ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/../../../../include/c++/10.1.0 /usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/../../../../include/c++/10.1.0/x86_64-linux-gnu /usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/../../../../include/c++/10.1.0/backward /usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/include /usr/local/include /usr/local/lib/gcc/x86_64-linux-gnu/10.1.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-c' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-linux-gnu/10.1.0/cc1plus -fpreprocessed test_fragmentation.ii -quiet -dumpbase test_fragmentation.cpp -mtune=generic -march=x86-64 -auxbase test_fragmentation -Wall -Wextra -version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o test_fragmentation.s GNU C++14 (GCC) version 10.1.0 (x86_64-linux-gnu) compiled by GNU C version 10.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (GCC) version 10.1.0 (x86_64-linux-gnu) compiled by GNU C version 10.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 731fbf5b63dd31db9f4b6aef8d6447dc test_fragmentation.cpp: In function 'void X()': test_fragmentation.cpp:45:8: error: request for member 'popFragment' in 'frag', which is of non-class type 'PacketFragmenting(MaxPacketSize, PhySize)' {aka 'PacketFragmenting(NamedType<long unsigned int, MaxPacketSize_t>, NamedType<long unsigned int, PhySize_t>)'} 45 | frag.popFragment(); | ^~~~~~~~~~~ test_fragmentation.cpp:37:16: warning: unused variable 'PHY_SIZE' [-Wunused-variable] 37 | const size_t PHY_SIZE = 112; | ^~~~~~~~ test_fragmentation.cpp:38:16: warning: unused variable 'MAX_PACKET_SIZE' [-Wunused-variable] 38 | const size_t MAX_PACKET_SIZE = 1500; | ^~~~~~~~~~~~~~~ root@2580b215cc3e:/app/arm_apps/src/tests/bug# ==== Within the source file, there is a commented-out line. If I uncomment it, i.e. switch from const size_t PHY_SIZE = 112; PacketFragmenting frag(MaxPacketSize(MAX_PACKET_SIZE), PhySize(PHY_SIZE)); to PacketFragmenting frag(MaxPacketSize(MAX_PACKET_SIZE), PhySize(static_cast<size_t>(112))); the file compiles successfully. To me this seems like a bug, because it should make no difference if I use the const or the literal.
Created attachment 48495 [details] The corresponding .ii-file
Unfortunately, this seems to be a hard-to-spot case of the most vexing parse (just tried with clang, whose warning pointed me into that direction). https://www.fluentcpp.com/2018/01/30/most-vexing-parse/
> PacketFragmenting frag(MaxPacketSize(MAX_PACKET_SIZE), PhySize(PHY_SIZE)); I was going to say this defines a function, frag which takes MaxPacketSize and PhySize as arguments and returns PacketFragmenting .
Not a bug then.