[Bug c++/53181] New: static_assert sees as non constant the comparison between a constexpr and a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181 Bug #: 53181 Summary: static_assert sees as non constant the comparison between a constexpr and a template argument Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: blaffabla...@gmail.com Created attachment 27278 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27278 test case As per title. The weird is that it seems that the constexpr-ness seems to changes if the expression inside static_assert evaluates to true (compiles, expression seen as constexpr) or false (fails to compile, but not due to the assertion failing but to the described error).
[Bug c++/52744] New: bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744
Bug #: 52744
Summary: bad handling of member (function) pointers in template
parameters
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com
Created attachment 27017
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27017
the two test cases
The bug is well described in this stackoverflow question:
http://stackoverflow.com/questions/9893521/ambiguity-partial-template-specialization-for-member-and-member-functions#comment12624275_9893521
Description:
it seems that g++ 4.6.1 (probably both 4.6.* 4.7.*) has trouble in handling
template parameters of the kind of member pointers or member function pointers
in class partial specialization.
ambiguous.cpp fails with error is triggered at line 54 and 55 ("ambiguous class
template instantiation").
crash.cpp is an attempt to workaround with std::enable_if in typedefs within
the class bodies. But unfortunately that triggers a worse error, a crash of the
compiler, when trying to instantiate the partial specialization for pointers to
member object.
See source for ulterior comments.
My g++ version:
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --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.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
Both the attachments work with g++ 4.5.1 (from ideone.com). Other guys from
stackoverflow tried to compile ambiguous.cpp (see the comments), and it works
with clang 3.1 and g++ 4.5.3, but not with g++ 4.6.2 and 4.7.something (sic).
[Bug c++/52744] bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744 --- Comment #1 from Lorenzo Pistone 2012-03-27 19:37:50 UTC --- Of course it's c++0x. Compile with -std=c++0x.
[Bug c++/52744] bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744 --- Comment #3 from Lorenzo Pistone 2012-03-27 20:15:11 UTC --- I'm sorry but the bug reporting interface seemed to allow only one attachment.
[Bug c++/52744] bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744 --- Comment #4 from Lorenzo Pistone 2012-03-27 20:37:22 UTC --- gcc version 4.4.5 (Debian 4.4.5-8) can build both the test cases.
[Bug c++/52744] bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744 --- Comment #6 from Lorenzo Pistone 2012-04-03 14:28:57 UTC --- Same problem with free function pointers. See free_functions.cpp
[Bug c++/52744] bad handling of member (function) pointers in template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52744 --- Comment #7 from Lorenzo Pistone 2012-04-03 14:29:38 UTC --- Created attachment 27075 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27075 test case with free function pointers
[Bug c++/53009] New: pointer to static member function of template class is “invalid” as a template argument of another template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53009
Bug #: 53009
Summary: pointer to static member function of template class is
“invalid” as a template argument of another template
class
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com
I believe that this bug is somewhat related to #35167: probably g++ thinks that
the address of a static member function of a template class is not a constant
expression, whereas it is. I'm filing a new bug though because the situation
here involves two distinct class templates, the error message is different
("error: template argument 2 is invalid", not helpful at all), and because it's
said in the comments of #35167 that it's fixed if C++11 is used, whereas my
testcase is compiled with and needs C++11 (for variadic templates).
Fails to build with g++ 4.6.2 4.5.4 4.4.6.
[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53009 --- Comment #1 from Lorenzo Pistone 2012-04-16 16:09:16 UTC --- Created attachment 27170 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27170 testcase
[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53009 --- Comment #2 from Lorenzo Pistone 2012-04-16 16:22:04 UTC --- I just tested, the problem happens only if the template arguments of function_proxy are function pointers. More trivial types (int is what I've tested) just work fine
[Bug c++/51936] New: template function not instantiated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51936 Bug #: 51936 Summary: template function not instantiated Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: blaffabla...@gmail.com Created attachment 26405 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26405 test case It appears that in some circumstances g++ fails to instantiate a template function, and so end up in link time errors. Consider the code in attachment. If compiled with: g++ -Wall -std=c++0x testcase.cpp the result is: testcase.cpp:(.text+0x13): undefined reference to `int asd(int*)' collect2: ld returned 1 exit status whereas if compiled with: g++ -Wall -std=c++0x -DWORKAROUND testcase.cpp it does warn for the unused variable 'inted', but compiles and run correctly. It looks like that getting the pointer of a template function and immediately cast it to something else "weakens" the usage of the template, so that g++ doesn't instantiate it.
[Bug c++/70338] New: ICE combining debug symbols, range-for in lambda in function template accessing captured variable-size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70338 Bug ID: 70338 Summary: ICE combining debug symbols, range-for in lambda in function template accessing captured variable-size array Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blaffablaffa at gmail dot com Target Milestone: --- Created attachment 38045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38045&action=edit testcase The testcase in attachment causes a segfault with 5.3.1 only when compiled with -g(gdb) or -g(gdb)2 or -g(gdb)3. It appears that some debug symbol generation cannot handle a complex interaction between template functions, variable-length arrays and range-for. I have included in the test case examples of functions that do not crash, taking out some of the elements that put together cause the ICE.
[Bug c++/70832] move-assignment of lambdas calls copy-assignment for captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70832 --- Comment #1 from Lorenzo Pistone --- correction, it calls the copy assignment operator, not the copy constructor.
[Bug c++/70832] New: move-assignment of lambdas calls copy-constructor for captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70832
Bug ID: 70832
Summary: move-assignment of lambdas calls copy-constructor for
captures
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blaffablaffa at gmail dot com
Target Milestone: ---
Created attachment 38352
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38352&action=edit
testcase, compile with -std=c++14
Testcase attached, which compiles and produces correct output with clang++ 3.7.
Incorrect g++ diagnostic:
[pisto@localhost ~]$ g++ -std=c++14 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:18:12: error: use of deleted function ‘main()::&
main()operator=(const main()::&)’
lambda = move(lambda_moved);//g++ tries to call copy constructor and
fails, clang++ 3.7 works
^
test.cpp:16:37: note: a lambda closure type has a deleted copy assignment
operator
auto lambda = [test = move(data)]{};
^
[Bug c++/70832] move-assignment of lambdas calls copy-assignment for captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70832 --- Comment #2 from Lorenzo Pistone --- I should add also that this makes impossible to assign lambdas with move-only captures to a std::function.
[Bug c++/70882] New: vectorized sincos trashes the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70882 Bug ID: 70882 Summary: vectorized sincos trashes the stack Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blaffablaffa at gmail dot com Target Milestone: --- Created attachment 38381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38381&action=edit testcase The double4 version of the vectorized sincos() in libmvec (glibc 2.22) causes the stack to be corrupted, leading to assorted bugs such as crash, backtrace corruption in gdb, etc. I am reporting a bug here because since it's the only vectorized math function that uses pointers, so it might be an ABI problem. On my CPU (ivybridge) I can only test the double4 version, not the wider ones. Attached testcase, compile with g++ -std=c++11 -O1 -fopenmp -ffast-math -march=ivybridge -mtune=ivybridge -o double_sincos double_sincos.cpp (interestingly, the vectorized call is not emitted with a c++ version lower than 2011).
[Bug c++/70882] vectorized sincos trashes the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70882 Lorenzo Pistone changed: What|Removed |Added CC||blaffablaffa at gmail dot com --- Comment #1 from Lorenzo Pistone --- glibc bug https://sourceware.org/bugzilla/show_bug.cgi?id=20024
[Bug c++/70901] New: vectorized sin cos is wrongly optimized into scalar sincos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70901 Bug ID: 70901 Summary: vectorized sin cos is wrongly optimized into scalar sincos Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blaffablaffa at gmail dot com Target Milestone: --- Created attachment 38390 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38390&action=edit testcase As per title. Compile testcase with g++ -std=c++11 -O1 -fopenmp -ffast-math -march=ivybridge -mtune=ivybridge -o vector_sin_cos_to_scalar_sincos vector_sin_cos_to_scalar_sincos.cpp
[Bug c++/70901] vectorized sin cos is wrongly optimized into scalar sincos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70901 Lorenzo Pistone changed: What|Removed |Added CC||blaffablaffa at gmail dot com --- Comment #1 from Lorenzo Pistone --- Note that vectorized sincos is currently (glibc 2.22) broken: https://sourceware.org/bugzilla/show_bug.cgi?id=20024
[Bug c++/81943] New: Wrong ABI in class methods returning structs for the Windows amd64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81943
Bug ID: 81943
Summary: Wrong ABI in class methods returning structs for the
Windows amd64 target
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blaffablaffa at gmail dot com
Target Milestone: ---
test case:
struct retstruct{
int a;
};
struct badABI{
retstruct f(int arg){
retstruct ret;
ret.a = arg;
arg++;
return ret;
}
};
int main(){
badABI test;
auto testret = test.f(234);
};
g++ assembly output (x86_64-w64-mingw32-g++ -S -std=c++11 -o main.S main.cpp)
around the badABI::f call:
leaq-1(%rbp), %rax
movl$234, %edx #2nd arg, int
movq%rax, %rcx #1st arg, this pointer
call_ZN6badABI1fEi
movl%eax, -8(%rbp) #returned struct in eax
cl.exe (version 19, Visual Studio 2017) output:
mov r8d, 234 ; 00eaH #3rd argument, int
lea rdx, QWORD PTR testret$[rsp] #2nd argument, return buffer
lea rcx, QWORD PTR test$[rsp] #1st argument, this pointer
call badABI::f
Note that this is not fixed by -fpcc-struct-return, because the this pointer
and the hidden return struct buffer pointer are inverted:
leaq-8(%rbp), %rax
leaq-1(%rbp), %rdx #2nd argument, this pointer
movl$234, %r8d #3rd argument, int
movq%rax, %rcx #1st argument, return buffer
call_ZN6badABI1fEi
As far as I know this last convention isn't used anywhere on windows, so it's
completely wrong. On the other hand, the first convention appears to follow the
specifications for small struct returns
(https://msdn.microsoft.com/en-us/library/7572ztz4(v=vs.120).aspx), but I can't
explain why the latest cl.exe does not appear to use it.
There are projects where this discrepancy has been taken into account, the one
I know of is https://github.com/SteamRE/open-steamworks : it is a reverse
engineering of the Steamworks SDK (started when it wasn't public), and they
have a number of instances (see for example
https://github.com/SteamRE/open-steamworks/blob/master/Open%20Steamworks/ISteamUser017.h#L44
macro STEAMWORKS_STRUCT_RETURN_0) where the return of structs is fixed by
actually returning void and passing a reference to the return buffer.
clang appears to emit the right assembly when using -cc1 -triplet
x86_64-pc-windows-msvc18.0.0 (default of clang-cl):
leaq48(%rsp), %rcx #1st argument, this pointer
leaq40(%rsp), %rdx #2nd argument, return buffer
movl$234, %r8d #3rd argument, int
callq "?f@badABI@@QEAA?AUretstruct@@H@Z"
excerpt of badABI::f:
movq%rdx, %rax #return buffer pointer in rax (correct as per
microsoft ABI)
movl%r8d, 12(%rsp)
movq%rcx, (%rsp)
movl12(%rsp), %r8d
movl%r8d, (%rdx)
movl12(%rsp), %r8d
addl$1, %r8d
movl%r8d, 12(%rsp)
[Bug c++/81973] New: Aliased virtual methods are treated as undefined, so the vtable is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81973
Bug ID: 81973
Summary: Aliased virtual methods are treated as undefined, so
the vtable is not generated
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blaffablaffa at gmail dot com
Target Milestone: ---
test case:
#include
using namespace std;
struct b{
int a;
virtual void f(){
cout<<__PRETTY_FUNCTION__<<' '<a<a<
[Bug c++/81973] Aliased virtual methods are treated as undefined, so the vtable is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81973 --- Comment #1 from Lorenzo Pistone --- It is possible to obtain the desired behavior defining in a compilation unit a dummy s::f with weak attribute (and so generate the vtable), then in a separate compilation the actual alias of s::f to s_f_alias, but this it is an impractical workaround.
[Bug c++/81973] Aliased virtual methods are treated as undefined, so the vtable is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81973
--- Comment #3 from Lorenzo Pistone ---
That is not the issue, or maybe I don't understand the suggestion. This program
fails just the same:
#include
using namespace std;
struct b{
int a;
virtual void f(){
cout<<__PRETTY_FUNCTION__<<' '
[Bug c++/80583] New: ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80583
Bug ID: 80583
Summary: ICE with target_clones and vectorized float: internal
compiler error: in convert_move, at expr.c:270
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blaffablaffa at gmail dot com
Target Milestone: ---
The test case in attachment unfortunately is relatively large, but I couldn't
isolate the issue.
The main() of this source file is prepended with
#ifdef __x86_64__
__attribute__((target_clones("default","avx","avx2")))
#endif
I use some operations on vector float types:
typedef float __attribute__((vector_size(32))) float8;
typedef float __attribute__((vector_size(16))) float4;
typedef float __attribute__((vector_size(8))) float2;
The compiler appears to stumble on some arithmetic operations on these
Compile with "g++ -std=c++1y -Wall -c -o main.o main.cpp". Error is:
In file included from /usr/include/c++/6.3.1/bits/stl_algo.h:61:0,
from /usr/include/c++/6.3.1/algorithm:62,
from main.cpp:4:
/usr/include/c++/6.3.1/bits/stl_heap.h: In function ‘void
std::__adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp, _Compare)
[with _RandomAccessIterator = armorset*; _Distance = long int; _Tp = armorset;
_Compare = __gnu_cxx::__ops::_Iter_less_iter]’:
/usr/include/c++/6.3.1/bits/stl_heap.h:209:5: note: The ABI for passing
parameters with 32-byte alignment has changed in GCC 4.6
__adjust_heap(_RandomAccessIterator __first, _Distance __holeIndex,
^
main.cpp: In function ‘int main.avx.298(int, char**)’:
main.cpp:477:85: internal compiler error: in convert_move, at expr.c:270
auto body_legs_abs = (body->absorptions.all - 100) * (legs->absorptions.all
- 100);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccUaXkg3.out file, please attach this to
your bugreport.
[pisto@pisto ds3]$ g++ -std=c++1y -Wall -c -o main.o main.cpp
In file included from /usr/include/c++/6.3.1/bits/stl_algo.h:61:0,
from /usr/include/c++/6.3.1/algorithm:62,
from main.cpp:4:
/usr/include/c++/6.3.1/bits/stl_heap.h: In function ‘void
std::__adjust_heap(_RandomAccessIterator, _Distance, _Distance, _Tp, _Compare)
[with _RandomAccessIterator = armorset*; _Distance = long int; _Tp = armorset;
_Compare = __gnu_cxx::__ops::_Iter_less_iter]’:
/usr/include/c++/6.3.1/bits/stl_heap.h:209:5: note: The ABI for passing
parameters with 32-byte alignment has changed in GCC 4.6
__adjust_heap(_RandomAccessIterator __first, _Distance __holeIndex,
^
main.cpp: In function ‘int main.avx.0(int, char**)’:
main.cpp:477:44: internal compiler error: in convert_move, at expr.c:270
auto body_legs_abs = (body->absorptions.all - 100) * (legs->absorptions.all
- 100);
~~^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/cc8Qjc34.out file, please attach this to
your bugreport.
[Bug c++/80583] ICE with target_clones and vectorized float: internal compiler error: in convert_move, at expr.c:270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80583 --- Comment #2 from Lorenzo Pistone --- Created attachment 41291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41291&action=edit test case My bad.
[Bug c++/61514] New: -ftree-vectorize cause bogus "duplicate section ... has different size" on windows x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61514 Bug ID: 61514 Summary: -ftree-vectorize cause bogus "duplicate section ... has different size" on windows x64 Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blaffablaffa at gmail dot com some other instances: http://stackoverflow.com/q/14181351/1073006 http://stackoverflow.com/q/11635485/1073006 In my case the duplicated section is related to guard variable of a static function variable. I haven't been able to reduce this to a small test case, because being something related to optimization it's being very sensitive to the actual code being compiled. My code is located on github: wget https://github.com/pisto/spaghettimod/archive/4342b93933ce8d9f18c1bc2cc35db3e689a6d101.zip -O spaghetti.zip unzip spaghetti.zip rm spaghetti.zip cd spaghetti* make PLATFORM=x86_64-w64-mingw32 (you'll need a working `pkg-config lua`).
[Bug c++/61514] -ftree-vectorize cause bogus "duplicate section ... has different size" on windows x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61514 --- Comment #1 from Lorenzo Pistone --- The warning printed by the test case is: spaghetti/spaghetti.o: duplicate section `.data$_ZGVZN9luabridge8Security11getSettingsEvE8settings[_ZGVZN9luabridge8Security11getSettingsEvE8settings]' has different size
[Bug c++/61514] -ftree-vectorize cause bogus "duplicate section ... has different size" on windows x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61514 --- Comment #2 from Lorenzo Pistone --- Created attachment 32943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32943&action=edit The object file that triggers the warning
[Bug c++/59790] New: Inner template class specialization has no direct access to outer template class typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59790 Bug ID: 59790 Summary: Inner template class specialization has no direct access to outer template class typedefs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blaffablaffa at gmail dot com See the attached testcase, Compile simply with `g++ -c test.cpp`. The code compiles with the latest clang.
[Bug c++/59790] Inner template class specialization has no direct access to outer template class typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59790 Lorenzo Pistone changed: What|Removed |Added CC||blaffablaffa at gmail dot com --- Comment #1 from Lorenzo Pistone --- Created attachment 31822 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31822&action=edit test case
[Bug sanitizer/67941] New: calls on function pointer from a captureless lambda cause ubsan warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941
Bug ID: 67941
Summary: calls on function pointer from a captureless lambda
cause ubsan warning
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: blaffablaffa at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Test program: int main(){ (+[](){})(); }
Compilation: -std=c++11 -fsanitize=null
Wrong output: :1:20: runtime error: member call on null pointer of type
'const struct __lambda0'
Expected: no warning at all.
Note: if the cast to a function pointer is not performed (remove the +), there
is no warning, probably because the capture is still used, although empty.
