[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580
--- Comment #1 from Zavadovsky Yan ---
Got same bug with all GCC version since (at least, doesn't check older
versions) 6.3.0 and newer.
Code:
struct Base
{
Base(void*) { }
virtual ~Base() { }
};
template< typename... Ts > struct Derived : public Ts...
{
template< typename... Us > Derived(Us... args) : Ts(args...)... { }
};
int main()
{
Derived d((void*)0);
return 0;
}
Clang++ compiles it.
GCC reports error:
test.cpp: In instantiation of ‘Derived::Derived(Us ...) [with Us = {void*};
Ts = {Base}]’:
test.cpp:14:26: required from here
test.cpp:9:62: error: no matching function for call to ‘Base::Base(bool)’
9 | template< typename... Us > Derived(Us... args) : Ts(args...)... { }
| ^~~
test.cpp:3:2: note: candidate: ‘Base::Base(void*)’
3 | Base(void*) { }
| ^~~~
test.cpp:3:7: note: no known conversion for argument 1 from ‘bool’ to ‘void*’
3 | Base(void*) { }
| ^
test.cpp:1:8: note: candidate: ‘constexpr Base::Base(const Base&)’
1 | struct Base
|^~~~
test.cpp:1:8: note: no known conversion for argument 1 from ‘bool’ to ‘const
Base&’
Compilation command: g++ -std=c++14 -c test.cpp
GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580 --- Comment #2 from Zavadovsky Yan --- Created attachment 47622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47622&action=edit test.ii gcc --save-temps output
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580 --- Comment #3 from Zavadovsky Yan --- (In reply to Petr Filipsky from comment #0) > Sorry if this kind of error has been reported already (I know that there are > already several bugs reported regarding variadic template parameter > expansion but none of them seemed to me identical to this one). I also can't find similar bugs except this one created by you.
[Bug c++/88562] New: Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562
Bug ID: 88562
Summary: Incorrect pointer incrementing on ST-SH4
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zavadovsky.yan at gmail dot com
Target Milestone: ---
Created attachment 45268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45268&action=edit
code to trigger the bug
Hello.
I have got some piece of source code which incorrectly works after optimized
compilation for ST-SH4 architecture.
But it works good with some other CPUs - checked on x86-64, armv8 and mips.
And works good with some optimizations off.
Details:
Here is the minimal piece of code to trigger this bug:
unsigned Read32(const unsigned char* ptr);
const unsigned char* ReadQm(const unsigned char* ptr, const unsigned char* end)
{
const unsigned char* ret = 0;
while(ptr < end)
{
unsigned char tag = *ptr++;
unsigned len = Read32(ptr);
ptr += 4;
if (!tag || !len)
break;
if (ptr + len > end)
break;
ret = ptr;
ptr += len;
}
return ret;
}
The error is in 'ptr += 4;' statement.
It is compiled like 'ptr += 5;'.
This leads to non-working assembler opcodes.
But some changes to this code will prevent this error.
I've checked these variants:
- replace 'return ret;' with 'return ptr;'
- add line 'AnyFuncWhichTakesPointerAsArgument(ptr);' before 'return ret;'
- compile without some optimizations
How to compile and get the bug: 'sh4-unknown-linux-gnu-g++ -Os -S -c
ReadQm.cpp'
Assembler output with some comments:
// r4 == ptr
cmp/hs r11,r4
bt/s.L8
mov r10,r0
mov r4,r8 // r8 = ptr
mov.b @r8+,r9 // r9 = tag, r8 = (ptr + 1)
mov r8,r4
jsr @r12 // call Read32(ptr + 1)
add #5,r8 // r8 = ((ptr + 1) + 5) HERE IS ERROR, must be '+=4'
How to compile and DON'T get the bug: 'sh4-unknown-linux-gnu-g++ -Os
-fno-expensive-optimizations -S -c ReadQm.cpp'
Assembler output with some comments:
// r8 == ptr
mov r8,r4 // r4 = ptr
jsr @r12 // call Read32(ptr + 1), note: this line is executed after
next because of SH4's 'delayed slot' stuff
mov.b @r4+,r9 // r9 = tag, r4 = (ptr + 1)
tst r9,r9
mov r8,r1 // r1 = ptr
bt/s.L5
add #5,r1 // r1 = ((ptr + 1) + 4) ALL GOOD HERE
GCC info:
yan@ws-zavadovskiy:~/000_sh4_qmreader$ ./820/bin/sh4-unknown-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=./820/bin/sh4-unknown-linux-gnu-g++
COLLECT_LTO_WRAPPER=/yan/000_sh4_qmreader/820/bin/../libexec/gcc/sh4-unknown-linux-gnu/8.2.0/lto-wrapper
Target: sh4-unknown-linux-gnu
Configured with:
/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=sh4-unknown-linux-gnu
--prefix=/yan/000_sh4_gcc/ct-ng/../sh4-unknown-linux-gnu
--with-sysroot=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG 1.23.0.580-eb72b4e'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-mpfr=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-mpc=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-isl=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--disable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++ -lm'
--enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls
--enable-multiarch
--with-local-prefix=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot
--enable-long-long
Thread model: posix
gcc version 8.2.0 (crosstool-NG 1.23.0.580-eb72b4e)
I've additionally checked some GCC versions:
GCC 4.6 and 4.7 on st-sh4, x86-64, armv7, mips - no bug
GCC 4.9.4 on st-sh4 - no bug
GCC 5.4.0 on st-sh4 - has bug
GCC 6.3.0 on armv8, mips - no bug
GCC 6.3.0 on st-sh4 - has bug
GCC 6.5.0 on st-sh4 - has bug
GCC 7.4.0 on st-sh4 - has bug
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #1 from Zavadovsky Yan --- Created attachment 45269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45269&action=edit ReadQm_Os.s Add full assembler output with buggy code. Command to compile: 'sh4-unknown-linux-gnu-g++ -Os -S -c ReadQm.cpp'
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #2 from Zavadovsky Yan --- Created attachment 45270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45270&action=edit ReadQm_Os_no_expensive_optimizations.s Add full assembler output with NON-buggy code. Command to compile: 'sh4-unknown-linux-gnu-g++ -Os -fno-expensive-optimizations -S -c ReadQm.cpp'
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #3 from Zavadovsky Yan --- Created attachment 45271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45271&action=edit main.cpp Add some testing code. Command to compile: './820/bin/sh4-unknown-linux-gnu-g++ --sysroot=./820/sh4-unknown-linux-gnu/sysroot -static -Os -o /export/st-sh4/rootfs/test820 ReadQm.cpp main.cpp' It will produce executable which will assert. Another command to compile: './820/bin/sh4-unknown-linux-gnu-g++ --sysroot=./820/sh4-unknown-linux-gnu/sysroot -static -Os -fno-expensive-optimizations -o /export/st-sh4/rootfs/test820 ReadQm.cpp main.cpp' It will produce executable which won't assert.
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #4 from Zavadovsky Yan --- Some additional note. Test code is placed in separate file from 'Read32' function implementation because inlining of 'Read32' will avoid bug. Full source file on which bug was observed has about 300 lines of code. And 'Read32' wasn't inlined while compilation. But after stripping non-releated code compiler inlined remaining code. And bug was disappeared.
[Bug c++/88630] New: Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 Bug ID: 88630 Summary: Incorrect float negating together with convertion to int on SH4 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zavadovsky.yan at gmail dot com Target Milestone: --- Created attachment 45299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45299&action=edit main.cpp: code to trigger the bug Hello. I have some strange behavior with such simple code: float float_val = ; int int_val = -float_val; Problem is in "losing" negation. Real result of code execution looks like int int_val = float_val; E.g. if float_val==12.0f I am awaiting that int_val will be equal -12; And vice versa. But I got int_val==12 when float_val==12.0f; I.e. there was no negation. There is no such bug in GCC-4.x (checked 4.7.3 and 4.9.4). It begins since 5.x(I checked 5.4.0, 6.3.0, 7.4.0, 8.2.0). There is no such bug on x86-64, mips and arm with 4.6/4.7 and 6.3.0 compiler versions. Assembler from GCC-8.2.0 - works bad: sts fpscr,r1 mov.l .L2,r2 fnegfr5 xor r2,r1 lds r1,fpscr ftrcfr5,fpul sts fpul,r0 xor r2,r1 lds r1,fpscr rts Assembler from GCC-4.9.4 - works good: mov.l .L2,r1 lds.l @r1+,fpscr add #-4,r1 fnegfr5 add #4,r1 ftrcfr5,fpul sts fpul,r0 rts lds.l @r1+,fpscr I can see that FPU 'calculation' commands wasn't changed between compiler versions. But there was change of work with FPU status/control register. Can somebody say is it compiler bug or there is a problem with my code?
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #1 from Zavadovsky Yan --- Rewriting code as float float_val = ; int int_val = -(int)float_val; avoids bug. And rewriting code as double float_val = ; int int_val = -float_val; also avoids bug.
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #2 from Zavadovsky Yan --- Created attachment 45300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45300&action=edit main494.s: assembler output from GCC-4.9.4
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #3 from Zavadovsky Yan --- Created attachment 45301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45301&action=edit main820.s: assembler output from GCC-8.2.0
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #4 from Zavadovsky Yan --- Compilation command: sh4-unknown-linux-gnu-g++ --sysroot=../8.2.0/sh4-unknown-linux-gnu/sysroot -static -Os -o test820 main.cpp GCC info: Using built-in specs. COLLECT_GCC=../000_sh4_gcc/820/bin/sh4-unknown-linux-gnu-g++ COLLECT_LTO_WRAPPER=/yan/000_sh4_gcc/820/bin/../libexec/gcc/sh4-unknown-linux-gnu/8.2.0/lto-wrapper Target: sh4-unknown-linux-gnu Configured with: /yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=sh4-unknown-linux-gnu --prefix=/yan/000_sh4_gcc/ct-ng/../sh4-unknown-linux-gnu --with-sysroot=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot --enable-languages=c,c++ --with-pkgversion='crosstool-NG 1.23.0.580-eb72b4e' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libmpx --with-gmp=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-mpfr=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-mpc=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --with-isl=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools --disable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++ -lm' --enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls --enable-multiarch --with-local-prefix=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot --enable-long-long Thread model: posix gcc version 8.2.0 (crosstool-NG 1.23.0.580-eb72b4e)
[Bug c++/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #5 from Zavadovsky Yan --- Created attachment 45302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45302&action=edit main.ii: -save-temps output
[Bug target/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #7 from Zavadovsky Yan --- Hello. >your posted disassembly doesn't seem to match >the actual source that you have posted Sorry, my mistake. Seems that I attached some temporary ASM sources. Must be check for -12, of course. >The difference is that in GCC 4.9, the fpscr switch >is done before fneg and later it's done after fneg. >That is OK because fneg does not use and does not >modify any of the fpscr bits. I also found out that this fpscr-related changes seems to be normal. But behavior of generated code is different: >Are you testing this on real hardware or on some emulator/simulator? I got this bug on real hardware - STiH237 chip from STMicroelectronics. >in GCC 4.9, the fpscr switch is done before fneg This works good on STiH237 >later it's done after fneg but that is not.
[Bug c++/88562] Incorrect pointer incrementing on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #11 from Zavadovsky Yan --- Thanks for fixing!
[Bug c++/88562] Incorrect pointer incrementing on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #12 from Zavadovsky Yan --- I've checked this patch locally on our STiH237 hardware. Using GCC 8.2 built by crosstool-ng. It works!
[Bug target/88630] Incorrect float negating together with convertion to int on SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #9 from Zavadovsky Yan --- >Can you try it out please and see >if it fixes the issue on your hardware? Checked GCC 8.2 + your patch and crosstool-ng to build toolchain(using same config as I've used while reporting bug). At least it works on attached main.cpp. Got no assert when run on our STiH237-based board.
[Bug target/88630] Incorrect float negating together with convertion to int on ST-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #11 from Zavadovsky Yan --- >We can set it as a default behavior for all FPU-capable SH4 variants, >but that will pessimize it for everything. >The other option is to enable this only for your specific CPU (ST-40), >which would require you to use the -m4-300 option, not the -m4 option If behavior of hardware is variative for this fpscr register switching it by some option sounds as good idea. >Would that be feasible for you? Yes. Any variant - I can add more compiler options to "makefiles" or rebuild whole toolchain.
[Bug target/88630] Incorrect float negating together with convertion to int on ST-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630 --- Comment #13 from Zavadovsky Yan --- (In reply to Oleg Endo from comment #12) > > Please try it out. Let me know what you find GCC 8.2 + "trial patch" : assert passed GCC 8.2 + "patch from comment 12" : assert failed GCC 8.2 + "patch from comment 12" + -m4-300 option : assert passed GCC 7.4 + "patch from comment 12" : assert failed GCC 7.4 + "patch from comment 12" + -m4-300 option : assert passed Also I built and run our whole firmware(about 100mb of cpp code) using "GCC 7.4 + patch from comment 12 + -m4-300 option". And got no visible issues. Initially it was UI rendering bugs(because of FPU calculations) on statements like: intVar1 = boolVar ? (intVar2 - intVar3) : -floatVar;
