[Bug c++/85710] New: Enabling memset-elt-size warning causes ICE on memset of template member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85710
Bug ID: 85710
Summary: Enabling memset-elt-size warning causes ICE on memset
of template member array
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Target Milestone: ---
The memset-elt-size warning causes an internal compiler error when compiling:
#include
template struct A { int a; };
template
class E
{
public:
void Clear();
private:
A mA[2];
};
template
void E::Clear()
{
memset(mA, 0, sizeof(int)*2);
}
It does not cause an ICE if mA is not an array, or is an array of size 1. It
does not cause an ICE if using memset(mA, 0, sizeof(mA)); or memset(&mA[0], 0,
sizeof(int)*2);
The code causes an ICE when compiled with:
g++ -Wmemset-elt-size test.cpp
It does not cause an ICE when compiled with:
g++ -Wall -Wextra -Wno-memset-elt-size
Reproduces in:
g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
Configured with: ../gcc-8.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 8.1.0 (GCC-Explorer-Build)
Configured with: ../gcc-trunk-20180508/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 9.0.0 20180508 (experimental) (GCC-Explorer-Build)
Does not reproduce in:
Configured with: ../gcc-7.3.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --enable-multiarch --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.3.0 (GCC-Explorer-Build)
[Bug sanitizer/85774] New: Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85774
Bug ID: 85774
Summary: Incorrect stack-use-after-scope caused by missing
cleanup of shadow bytes
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive 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, marxin at
gcc dot gnu.org
Target Milestone: ---
The code:
#include
void DoSomething(){}
void DoFunc(const std::function& func)
{
func();
}
void Setup()
{
switch (1)
{
case 1:
{
DoFunc([](){});
break;
}
case 2:
{
DoFunc([](){});
break;
}
default:
break;
}
DoSomething();
}
void DemostrateBadPoisoning()
{
DoFunc([](){});
}
int main()
{
Setup();
DemostrateBadPoisoning();
return 0;
}
will cause an AddressSanitizer stack-use-after-scope error in
DemonstrateBadPoisoning. This appears to be because the shadow bytes for the
stack of Setup are not completely zeroed on function exit.
Compiled with: g++ -O0 -g -fsanitize=address -Wall -Wextra
gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)
[Bug pch/86674] New: -W(no)-error=invalid-pch does not affect incorrect language warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86674 Bug ID: 86674 Summary: -W(no)-error=invalid-pch does not affect incorrect language warning Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: jwyatt at feralinteractive dot com Target Milestone: --- -Werror=invalid-pch does not turn warnings caused by -Winvalid-pch into errors. -Wno-error=invalid-pch does not turn errors caused by -Winvalid-pch -Werror into warnings. Context: When compiling the same prefix for multiple languages, https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html suggests that they can all co-exist in the same folder, since the compiler will search them all and choose the correct one. However this will cause https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17162. As a result, in cases where -Werror is enabled, it would be useful to turn -Winvalid-pch back into a warning. Example - the contents of the files are irrelevant, just use empty files if need be: gcc -Wall -Wextra -x c-header Prefix.h -o Prefix.h.gch/c.h gcc -Wall -Wextra -x c++-header Prefix.h -o Prefix.h.gch/c++.h gcc -Wall -Wextra -Winvalid-pch -Werror -Wno-error=invalid-pch -include Prefix.h -c Test.c gcc -Wall -Wextra -Winvalid-pch -Werror -Wno-error=invalid-pch -include Prefix.h -c Test.cpp This produces only the following output: cc1plus: error: ./Prefix.h.gch/c.h: not for GNU C++14 [-Werror] cc1plus: all warnings being treated as errors
[Bug tree-optimization/78189] New: movaps generated for unaligned store in aligned struct, when struct is referenced via unaligned member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78189
Bug ID: 78189
Summary: movaps generated for unaligned store in aligned
struct, when struct is referenced via unaligned
member.
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Target Milestone: ---
The code below, when compiled with -O2 -ftree-slp-vectorize -Wall -Wextra,
generates:
pxor %xmm0,%xmm0
movaps %xmm0,0x10(%rdi)
for NullB. This causes a segfault, as rdi contains the address of the 8-byte
aligned "misaligned" member of struct B.
This does not happen if NullB uses reinterpret_cast instead of
uint8_t*, if "misaligned" and "pad" are swapped (so that "misaligned" is in
fact aligned). B::Null() is also fine.
// Impl.h
#include
struct A
{
void * a;
void * b;
};
struct alignas(16) B
{
void * pad;
void * misaligned;
void * pad2;
A a;
void Null();
};
static_assert((offsetof(B, a) % 16) == 8, "A should be misaligned for this
test");
void NullB(void * misalignedPtr);
// Impl.cpp
#include
#include "Impl.h"
void B::Null()
{
a.a = nullptr;
a.b = nullptr;
}
void NullB(void * misalignedPtr)
{
B* b = reinterpret_cast(reinterpret_cast(misalignedPtr)
- offsetof(B, misaligned));
b->Null();
}
// main.cpp
#include "Impl.h"
int main()
{
B b;
NullB(&b.misaligned);
return 0;
}
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,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-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)
[Bug c++/68186] New: Using public base member function privately prevents derived classes using base member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68186
Bug ID: 68186
Summary: Using public base member function privately prevents
derived classes using base member function
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Target Milestone: ---
Created attachment 36637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36637&action=edit
Minimal example
The following setup (compiled with g++ -Wall -Wextra) causes the error:
‘int Base::Method()’ is inaccessible
within the Derived2 context. This doesn't happen if the using statement within
the class Derived is removed, or if it is made public.
class Base
{
public:
int Method();
};
class Derived : public Base
{
using Base::Method;
};
class Derived2 : public Derived
{
using Base::Method;
};
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,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-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Jason Wyatt changed:
What|Removed |Added
CC||jwyatt at feralinteractive dot
com
--- Comment #3 from Jason Wyatt ---
Similarly:
#include
struct TestStruct
{
int m1;
int m2;
};
int main()
{
int testValue = 1;
const TestStruct var = { testValue, 2 };
TestStruct array[1] = {
var
};
std::cout << "var: " << var.m1 << "," << var.m2 << std::endl;
std::cout << "array[0]: " << array[0].m1 << "," << array[0].m2 <<
std::endl;
return 0;
}
produces:
var: 1,2
array[0]: 0,2
(gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC))
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
--- Comment #4 from Jason Wyatt ---
It appears that while parsing the initialiser for the array,
maybe_constant_init switches the var for a constructor. This constructor only
sets the m2 member variable. You can see the result in the gimple it produces:
testValue = 1;
var = {};
var.m2 = 2;
var.m1 = testValue;
array = {};
array[0].m2 = 2;
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550 --- Comment #5 from Jason Wyatt --- When parsing the initialisation of const TestStruct var: store_init_value ends up calling split_nonconstant_init, so that only the constant part of the initialisation of var is stored in DECL_INITIAL(t). Then when parsing the initialisation of the array, maybe_constant_init eventually calls through to decl_constant_value(t), i.e. constant_value_1(t, false, true). That then uses DECL_INITIAL(t) as if it were the whole initialisation, rather than just the constant part, hence all the non constant parts aren't initialised correctly. I've got no idea how this is supposed to work though, presumably at some point in the chain of calls it's supposed to realise this is not a constant?
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
--- Comment #6 from Jason Wyatt ---
Adding a TREE_READONLY (to match TREE_READONLY being unset in
split_nonconstant_init) check seems to fix the generated gimple. This is total
guesswork though - I have no idea what side effects this change might have.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index ac11224..ee0405d 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2038,7 +2038,8 @@ constant_value_1 (tree decl, bool strict_p, bool
return_aggregate_cst_ok_p)
|| (strict_p
? decl_constant_var_p (decl)
: (VAR_P (decl)
- && CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (decl)
+ && CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (decl))
+ && TREE_READONLY (decl
{
tree init;
/* If DECL is a static data member in a template
[Bug tree-optimization/63379] New: Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379
Bug ID: 63379
Summary: Incorrect vectorization when enabling SSE and O3,
initialises loop with wrong value
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Created attachment 33579
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33579&action=edit
.i file for simple test case
Enabling SSE and 03 causes gcc to vectorize the following for loop:
Point min_pt = pt_array[0];
for (Point *ptr = pt_array+1, *ptr_end = pt_array+size; ptr != ptr_end; ++ptr)
{
min_pt.x = (min_pt.x < ptr->x) ? min_pt.x : ptr->x;
min_pt.y = (min_pt.y < ptr->y) ? min_pt.y : ptr->y;
}
where pt_array is an array of:
struct Point {
int x;
int y;
};
This sets the min_pt.y value to an x value if the y values are greater than the
x values.
Looking at the assembly, the vectorization splits this into two. It looks like
for one of these, it initialises the first min y value as the min x value.
Compiled with g++ -msse --std=c++11 -O3 -Wall -Wextra test.cpp, which gives no
warnings.
Version info:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
[Bug tree-optimization/63379] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 --- Comment #1 from Jason Wyatt --- Created attachment 33580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33580&action=edit Test case Compiling this code and running it gives the following output: Point 0,1000 Point 1,1001 Point 2,1002 Point 3,1003 Point 4,1004 Point 5,1005 Point 6,1006 Point 7,1007 Point 8,1008 Point 9,1009 Point 10,1010 Point 11,1011 Point 12,1012 Point 13,1013 Point 14,1014 Point 15,1015 Point 16,1016 Point 17,1017 Point 18,1018 Point 19,1019 Point 20,1020 Point 21,1021 Point 22,1022 Point 23,1023 Point 24,1024 Size: 25 25, 0, 0 <---This value should be 1000 (minimum y value) Point 0,1000 Point 1,1001 Point 2,1002 Point 3,1003 Point 4,1004 Point 5,1005 Point 6,1006 Point 7,1007 Point 8,1008 Point 9,1009 Point 10,1010 Point 11,1011 Point 12,1012 Point 13,1013 Point 14,1014 Point 15,1015 Point 16,1016 Point 17,1017 Point 18,1018 Point 19,1019 Point 20,1020 Point 21,1021 Point 22,1022 Point 23,1023 Point 24,1024
