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
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
: 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
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
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=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 #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,
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.
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__
13 matches
Mail list logo
