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,
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.
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,
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__
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);
}
++
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=edit
self-contained test case
The attached example incorrectly trigger the alloc-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Gael Guennebaud gael.guennebaud at gmail dot com changed:
What|Removed |Added
CC
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
--- Comment #2 from Gael Guennebaud gael.guennebaud at gmail dot com ---
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
: 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=33124action=edit
Tarball of the files to reproduce the issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900
--- Comment #4 from Gael Guennebaud gael.guennebaud at gmail dot com
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900
--- Comment #2 from Gael Guennebaud gael.guennebaud at gmail dot com
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
13 matches
Mail list logo