[Bug c++/53900] New: Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 Bug #: 53900 Summary: Too optimistic on a alignment assert Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gael.guenneb...@gmail.com Created attachment 27766 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27766 an example triggering the issue. Since gcc 4.7 the assertion of the attached piece of code is resolved at compile-time while there is no guaranty, for instance when using a non-aligned memory allocator, or on some systems where function arguments cannot be aligned. Here is the output with gcc-4.7: $ g++-4.7 -m32 alignedassert.cpp && ./a.out 0x8321008 0x832100c no assertion! And with gcc 4.6: $ g++-4.6 -m32 alignedassert.cpp && ./a.out 0x9322008 a.out: alignedassert.cpp:12: Foo::Foo(): Assertion `(std::ptrdiff_t(array) & std::ptrdiff_t(0xf))==0' failed. Aborted Or without the -m32 flag: $ g++-4.7 alignedassert.cpp && ./a.out 0xde3010 0xde3014 $ g++-4.6 alignedassert.cpp && ./a.out 0x1f03010 0x1f03014 a.out: alignedassert.cpp:12: Foo::Foo(): Assertion `(std::ptrdiff_t(array) & std::ptrdiff_t(0xf))==0' failed. Aborted
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #2 from Gael Guennebaud 2012-07-09 16:12:07 UTC --- The problem is that it is not guaranteed to be effectively aligned, and it is nice to be able to detect when this happens to either abort with a clear message, trigger an exception, or even properly handle this case by disabling at runtime some optimizations. Anyway, if you disagree, I'm sure I'll find a workaround using, e.g., a non inlined intermediate function masking the origin of the pointer.
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #4 from Gael Guennebaud 2012-07-10 11:09:16 UTC --- Created attachment 27770 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27770 Another demonstration of the issue using std::vector Note that when we declare: __attribute__((aligned(16))) float array[4]; we request GCC to give us an aligned array, and we are not telling gcc that array is aligned that is slightly different. I attached another example demonstrating the problem: a simple declaration like: std::vector vec(5); generates unaligned arrays that are not caught by assertion because it has been removed by gcc 4.7. Outputs are as follow: $ g++-4.7 -m32 alignedassert.cpp && ./a.out ctor 0xffdc58f0 copy 0x9f72008 copy 0x9f72018 copy 0x9f72028 copy 0x9f72038 copy 0x9f72048 ctor 0xffdc5900 g++-4.6 -m32 alignedassert.cpp && ./a.out ctor 0xff8e19e0 copy 0x98e2008 a.out: alignedassert.cpp:18: Foo::Foo(const Foo&): Assertion `(std::ptrdiff_t(array) % std::ptrdiff_t(16))==0' failed. Aborted
[Bug target/89101] New: [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
Bug ID: 89101
Summary: [Aarch64] vfmaq_laneq_f32 generates unnecessary dup
instrcutions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Target Milestone: ---
vfmaq_laneq_f32 is currently implemented as:
__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
vfmaq_laneq_f32 (float32x4_t __a, float32x4_t __b,
float32x4_t __c, const int __lane)
{
return __builtin_aarch64_fmav4sf (__b,
__aarch64_vdupq_laneq_f32 (__c, __lane),
__a);
}
thus leading to unoptimized code as:
ldr q1, [x2, 16]
dup v28.4s, v1.s[0]
dup v27.4s, v1.s[1]
dup v26.4s, v1.s[2]
dup v1.4s, v1.s[3]
fmlav22.4s, v25.4s, v28.4s
fmlav3.4s, v25.4s, v27.4s
fmlav6.4s, v25.4s, v26.4s
fmlav17.4s, v25.4s, v1.4s
instead of:
ldr q1, [x2, 16]
fmlav22.4s, v25.4s, v1.s[0]
fmlav3.4s, v25.4s, v1.s[1]
fmlav6.4s, v25.4s, v1.s[2]
fmlav17.4s, v25.4s, v1.s[3]
I guess several other *lane* intrinsics exhibit the same shortcoming.
For the record, I managed to partly workaround this issue by writing my own
version as:
if(LaneID==0) asm("fmla %0.4s, %1.4s, %2.s[0]\n" : "+w" (c) : "w"
(a), "w" (b) : );
else if(LaneID==1) asm("fmla %0.4s, %1.4s, %2.s[1]\n" : "+w" (c) : "w"
(a), "w" (b) : );
else if(LaneID==2) asm("fmla %0.4s, %1.4s, %2.s[2]\n" : "+w" (c) : "w"
(a), "w" (b) : );
else if(LaneID==3) asm("fmla %0.4s, %1.4s, %2.s[3]\n" : "+w" (c) : "w"
(a), "w" (b) : );
but that's of course not ideal. This change yields a 32% speed up in Eigen's
matrix product: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1633
[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
--- Comment #2 from Gael Guennebaud ---
Indeed, it fails to remove the dup only if the coefficient is used multiple
times as in the following reduced exemple: (https://godbolt.org/z/hmSaE0)
#include
void foo(const float* a, const float * b, float * c, int n) {
float32x4_t c0, c1, c2, c3;
c0 = vld1q_f32(c+0*4);
c1 = vld1q_f32(c+1*4);
for(int k=0; k
[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101 --- Comment #4 from Gael Guennebaud --- Good to know this is fixed in trunk! Thank you, and sorry for the false alarm then.
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #10 from Gael Guennebaud --- I created a simplified example that has no dependencies at all: https://godbolt.org/z/uIy1Uu You can workaround the compilation issue by either: #1 - commenting line 16 and uncommenting line 15, i.e., by by-passing some indirection. #2 - commenting line 16 and uncommenting line 21, i.e., by removing the default value of the second templated parameter of Base<>. Hope it will help fixing the issue.
[Bug c++/87544] New: alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
Bug ID: 87544
Summary: alloc-size-larger-than incorrectly triggered
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Target Milestone: ---
Created attachment 44800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44800&action=edit
self-contained test case
The attached example incorrectly trigger the alloc-size-larger-than= warning
with either gcc 7, 8 or trunk. (-O2 -Wall). It is also reproduced on godbolt
for convenience:
https://godbolt.org/z/KXsyZP
The weirdest thing is that if I remove the condition line 15:
if(size>16 && (std::size_t(result) & 15)!=0)
or only remove one of the condition like:
if(size>16) { ... }
if((std::size_t(result) & 15)!=0) { ... }
then the warning is gone. I don't really see how a test on the pointer returned
by malloc can change anything... If I replace this test by an assert (instead
of freeing and returning 0) then I also get the alloc-size-larger-than=
warning.
Of course I can workaround with:
void *result = 0;
if(size::max())
result = std::malloc(size);
and this is what I'm going to do in the original code.
[Bug libstdc++/87544] alloc-size-larger-than incorrectly triggered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #2 from Gael Guennebaud ---
Indeed, if I redefine max_size as follows instead of relying on std::allocator
then the warning is gone:
size_type max_size() const {
return std::numeric_limits::max()/sizeof(T);
}
[Bug c++/61808] New: Linking error with explicit template instantiation and default template param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61808
Bug ID: 61808
Summary: Linking error with explicit template instantiation and
default template param
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Created attachment 33124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33124&action=edit
Tarball of the files to reproduce the issue.
Here is small example which fails to compile with gcc but works well with other
compilers. Compiling the files with:
$ g++ func.cpp main.cpp
produces the following error:
Undefined symbols for architecture x86_64:
"void foo<2>(Bar::Matrix<2, (2)+((int)((Bar::._1)0))>&)", referenced from:
_main in ccZW4Wal.o
You can workaround the issue doing either:
1 - In main.cpp, line 3: remove the declaration"enum { fifi = sizeof(int) };"
2 - In main.cpp, move the above declaration after including func.h
3 - In either func.h or main.cpp, replace one (or both) anonymous enum
declaration with a non-anonymous one.
4 - Move the explicit template declaration from func.cpp to main.cpp.
A real-word use case is described there:
http://stackoverflow.com/questions/24730981/undefined-reference-error-from-gcc-using-a-template-with-a-stdvector-and-an-ei
[Bug c++/57709] -Wshadow is too strict / has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Gael Guennebaud changed:
What|Removed |Added
CC||gael.guennebaud at gmail dot
com
--- Comment #15 from Gael Guennebaud ---
-Wshadow still trigger false positive when a base member functions is imported
with the "using" keyword, as in the following example (tested with gcc 5.1):
template struct BaseClass {
BaseClass(int size) : m_size(size) {}
int size() { return m_size; }
int m_size;
};
template struct Foo : BaseClass {
typedef BaseClass Base;
Foo(int size) : Base(size) {}
using Base::size;
};
$ g++-mp-5 gcc_shadow.cpp -c -Wshadow
gcc_shadow.cpp: In constructor 'Foo::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'Foo' [-Wshadow]
Foo(int size) : Base(size) {}
^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
using Base::size;
Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported "size" symbol is a function and not a
variable.
[Bug c++/66472] New: -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
Bug ID: 66472
Summary: -Wshadow gets confused by using statements in template
classes
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Target Milestone: ---
This is a followup to bug 57709 that disabled shadow warnings between variables
and class functions. However, -Wshadow still trigger false positive when a base
member functions is imported with the "using" keyword, as in the following
example (tested with gcc 5.1):
template struct BaseClass {
BaseClass(int size) : m_size(size) {}
int size() { return m_size; }
int m_size;
};
template struct Foo : BaseClass {
typedef BaseClass Base;
Foo(int size) : Base(size) {}
using Base::size;
};
$ g++-mp-5 gcc_shadow.cpp -c -Wshadow
gcc_shadow.cpp: In constructor 'Foo::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'Foo' [-Wshadow]
Foo(int size) : Base(size) {}
^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
using Base::size;
Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported "size" symbol is a function and not a
variable.
As suggested there https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709#c16, I
tried to break at the call to warning_at to give you more input, but with no
luck, as if warning_at was not called at all. (I also tried to break at any
*warning* symbol with same result).
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472 --- Comment #2 from Gael Guennebaud --- But with the same reasoning you would end up reintroducing shadow warnings between local variables and *any* functions, not only the ones visible from a using statement. It has been recognized that triggering a warning in such a case was too much: - gcc 4.8 removed them for free functions - gcc 5.0 removed them for member functions and I think that it thus make sense to remove them for member functions visible through "using". Did I miss something special regarding the use of "using"?
