[Bug c++/78157] New: Incorrect diagnostic for variable template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78157
Bug ID: 78157
Summary: Incorrect diagnostic for variable template declaration
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kfischer at college dot harvard.edu
Target Milestone: ---
Consider the following:
```
template class A {
template static T pi;
};
template <> template double A::pi =
3.1415926535897932385;
extern template double A::pi;
template double A::pi;
```
GCC complains:
```
test2.cpp:4:47: error: conflicting declaration ‘double A::pi’
template <> template double A::pi =
3.1415926535897932385;
^
test2.cpp:2:39: note: previous declaration as ‘T A::pi’
template static T pi;
^~
test2.cpp:4:47: error: got 1 template parameters for ‘T A::pi’
template <> template double A::pi =
3.1415926535897932385;
^
test2.cpp:4:47: error: but 2 required
test2.cpp: In instantiation of ‘double A::pi’:
test2.cpp:6:25: required from here
test2.cpp:6:25: error: explicit instantiation of ‘A::pi’ but
no definition available [-fpermissive]
template double A::pi;
^~~
```
Clang accepts this without error. ICC complains that the partial specialization
is
not allowed. I don't know whether or not this code is actually valid C++ or
not,
but either way, the diagnostic seems off, since there are two template
parameters
provided.
Godbolt links:
GCC 7: https://godbolt.org/g/W6OsWw
Clang: https://godbolt.org/g/3h8s93
[Bug rtl-optimization/68601] New: GCC miscompiles LLVM on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 Bug ID: 68601 Summary: GCC miscompiles LLVM on Windows Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kfischer at college dot harvard.edu Target Milestone: --- I am compiling LLVM on Windows using Mingw-w64's pre-built GCC 5.2.0 for MSYS2 and believe the generated code is invalid. The effect of this miscompilation is an LLVM assertion firing even though it's conditions is not satisfied. This does not occur with -O0 and I have verified in the debugger that the memory looks as expected. The C++ code in questions (from LLVM's Instructions.cpp is): ``` assert(getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"); ``` Here is the relevant disassembly as seen from GDB: ``` │0x1a6b990 mov-0x18(%rbx),%rcx │ │0x1a6b994 callq 0x1bbf360 (llvm::Value*)> │ │0x1a6b999 mov0x8(%rax),%rdx │ │0x1a6b99d mov-0x30(%rbx),%rcx │ │0x1a6b9a1 callq 0x1bbf360 (llvm::Value*)> │ │0x1a6b9a6 mov%rdx,%rcx │ │0x1a6b9a9 mov0x8(%rax),%rsi │ >│0x1a6b9ad callq 0x1c60420 (llvm::Type*)> │ │0x1a6b9b2 mov0x10(%rax),%rax │ │0x1a6b9b6 cmp(%rax),%rsi ``` It seems live the mov at +102 is moving a junk value (since the previous call clobbers rdx). Moreover, before the call %rdx had value `getOperand(1)->getType()`, which would be the correct thing to put into rcx here. I thus think the compiler got confused and didn't notice that the register is being clobbered by the call. The full pre-processed source is attached.
[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 --- Comment #2 from Keno Fischer --- The default options used by LLVM's build system: ``` g++ -m64 -I/home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts/include -I/home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts/lib/IR -I/home/Administrator/julia/deps/srccache/llvm-svn/include -I/home/Administrator/julia/deps/srccache/llvm-svn/lib/IR -D_DEBUG -D__NO_CTYPE_INLINE -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O2 -fomit-frame-pointer -g -std=gnu++11 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Wcast-qual -D__USING_SJLJ_EXCEPTIONS__ -D__CRT__NO_INLINE -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings-Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-comment -c -MMD -MP -MF "/home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts+GCC/lib/IR/Release+Debug+Asserts/Instructions.d.tmp" -MT "/home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts+GCC/lib/IR/Release+Debug+Asserts/Instructions.o" -MT "/home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts+GCC/lib/IR/Release+Debug+Asserts/Instructions.d" /home/Administrator/julia/deps/srccache/llvm-svn/lib/IR/Instructions.cpp -o /home/Administrator/julia/deps/build/llvm-svn/build_Release+Asserts+GCC/lib/IR/Release+Debug+Asserts/Instructions.o ``` I will try `-fno-strict-aliasing`
[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 --- Comment #3 from Keno Fischer --- `-fno-strict-aliasing` does not seem to change the generated assembly.
[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 --- Comment #5 from Keno Fischer --- Created attachment 36866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36866&action=edit Preprocessed source Trying to attach again. This is part of latest LLVM trunk.
[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 --- Comment #8 from Keno Fischer --- Great, thank you, I was having quite a bit of trouble trying to reduce this one.
[Bug target/77333] New: Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 Bug ID: 77333 Summary: Incorrect stack adjust in epilogue when targeting i686-w64-mingw32 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kfischer at college dot harvard.edu Target Milestone: --- This is reduced from https://github.com/JuliaLang/julia/issues/18162. It appears that GCC miscompiles LLVM when targeting i686-w64-mingw32. This behavior was observed on at least GCC 5.4.0 and 6.1.0. GCC 4.9 was confirmed to not have this problem. To reproduce: ``` git clone https://github.com/llvm-mirror/llvm (cd llvm && git checkout release_37) mkdir llvm-build (cd llvm-build && \ ../llvm/configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --enable-optimized CC=i686-w64-mingw32-gcc CXX="i686-w64-mingw32-g++ -g1 -funwind-tables -fasynchronous-unwind-tables" --enable-shared && \ make -j8) cp llvm-build/Release+Asserts/bin/opt.exe llvm-build/Release+Asserts/bin/LLVM-3.7.dll . cp ~/cross-w32/i686-w64-mingw32/lib/libgcc_s_sjlj-1.dll ~/cross-w32/i686-w64-mingw32/lib/libstdc++-6.dll . wine ./opt.exe -slp-vectorizer -S ~/llvm/test/Transforms/SLPVectorizer/X86/vector.ll ``` (-g and unwind tables are only to make debugging easier, also happens without) The problem appears to be the following: ``` Stopped in function __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizePairEPN4llvm5ValueES3_RNS_7BoUpSLPE.part.774 0x025cf853<+51>: leal24(%esp), %eax 0x025cf857<+55>: calll -2284 => 0x025cf85c<+60>: subl$12, %esp 0x025cf85f<+63>: addl$44, %esp 0x025cf862<+66>: retl$12 ``` This code jumps to an invalid address once it hits the `retl`. I believe the `subl 12` is incorrect, perhaps supposed to clean up a corresponding retl $12` in the callee, when there actually isn't one [^1]. Moreover, stepping back one instruction (to the end of function being called here) shows the stack intact and a plausible backtrace, lending further credibility to this theory: ``` 1|debug > rsi Stopped in function __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizeListEN4llvm8ArrayRefIPNS1_5ValueEEERNS_7BoUpSLPES5_b.constprop.793 0x025cf051<+225>:popl%edi 0x025cf052<+226>:popl%ebp => 0x025cf053<+227>:retl 0x025cf054<+228>:addl$4, %ebx 0x025cf057<+231>:cmpl%ebx, %esi 1|debug > bt [1] __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizeListEN4llvm8ArrayRefIPNS1_5ValueEEERNS_7BoUpSLPES5_b.constprop.793 [2] __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizePairEPN4llvm5ValueES3_RNS_7BoUpSLPE.part.774 [3] __ZN12_GLOBAL__N_113SLPVectorizer22vectorizeChainsInBlockEPN4llvm10BasicBlockERNS_7BoUpSLPE [4] __ZN12_GLOBAL__N_113SLPVectorizer13runOnFunctionERN4llvm8FunctionE.part.786 [5] __ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE [6] __ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE [7] __ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE [8] Most likely ``` (full assembly of that function is here: https://gist.github.com/Keno/cb45c3f1e925c6ae3484ca98f7300a4a) Lastly, looking at the CFI of the crashing frame shows that it indeed expected the stack pointer to have been adjusted up by 12 bytes after the call: ``` Stopped in function __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizePairEPN4llvm5ValueES3_RNS_7BoUpSLPE.part.774 0x025cf853<+51>: leal24(%esp), %eax 0x025cf857<+55>: calll -2284 => 0x025cf85c<+60>: subl$12, %esp 0x025cf85f<+63>: addl$44, %esp 0x025cf862<+66>: retl$12 1|debug > cfi DW_CFA_def_cfa %esp 4 DW_CFA_offset %eip 1 DW_CFA_nop DW_CFA_nop -- DW_CFA_advance_loc 3 (=> 3) DW_CFA_def_cfa_offset 48 DW_CFA_advance_loc 57 (=> 60) DW_CFA_def_cfa_offset 36 DW_CFA_advance_loc 3 (=> 63) -- DW_CFA_def_cfa_offset 48 DW_CFA_advance_loc 3 (=> 66) DW_CFA_def_cfa_offset 4 ``` [^1]: such cleanup happens when calling __ZN12_GLOBAL__N_113SLPVectorizer18tryToVectorizePairEPN4llvm5ValueES3_RNS_7BoUpSLPE.part.774 ``` 1|debug > f 3 Stopped in function __ZN12_GLOBAL__N_113SLPVectorizer22vectorizeChainsInBlockEPN4llvm10BasicBlockERNS_7BoUpSLPE 0x025d0727<+3319>: movl%ecx, 8(%esp) 0x025d072b<+3323>: movl40(%esp), %ecx => 0x025d072f<+3327>: calll -3860 0x025d0734<+3332>: subl$12, %esp 0x025d0737<+3335>: testb %al, %al ``` Please let me know if I can provide any further information.
[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #2 from Keno Fischer --- Still broken adding both options to the compile.
