[Bug fortran/39290] Subroutine/function ambiguity in generics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org --- See also PR 20896 - and the test case at http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
The following is a shorter version of Marc's test case:
__get_cpuid_max (unsigned int __ext, unsigned int *__sig) {
unsigned __edx;
__cpuid (0, 0, 0, 0, __edx);
}
int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int
*__ebx, unsigned int *__ecx, unsigned int *__edx) {
fail: return 0;
}
typedef int IV __attribute__((vector_size(16)));
typedef union {
int s;
IV v;
} U;
static U i[2], b, c;
void check0(void) {
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 4, 0, 0});
(memcmp (b, c, sizeof(c)) == 0) || (__builtin_trap (), 0);
}
void check2(void) {
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 4, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 4, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 4, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 4, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 4, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 5, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 5, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 5, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 5, 5, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 6, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 6, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 6, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 6, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 7, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 7, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 7, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 7, 6, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 6, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 6, 7, 0});
b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 6, 7, 0});
b.v = __builtin_shuffle (i[0].v,
[Bug fortran/40276] Matching GENERIC procedure: Wrong INTENT should give directly an error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Patch for PR57711 and this PR: http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved). It fails for the test case http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html (- PR39290 and PR20896). In that test case, s1 and s2 are ambiguous in F2003/F2008. However, I fear that the check in the patch above will give a bogus error for interface gen subroutine s1(x) real, external :: x end subroutine s1 subroutine s1(x) integer, external :: x end subroutine s1 end interface which is valid since F2008 (both data objects or known to be functions, and neither is TKR compatible with the other,, 12.4.3.4.5). The issue does not occur yet, as the feature is not yet implemented.
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Patch for PR40276 and this PR: http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved). It fails for the test case http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html (- PR39290 and PR20896). In that test case, s1 and s2 are ambiguous in F2003/F2008. However, I fear that the check in the patch above will give a bogus error for interface gen subroutine s1(x) real, external :: x end subroutine s1 subroutine s1(x) integer, external :: x end subroutine s1 end interface which is valid since F2008 (both data objects or known to be functions, and neither is TKR compatible with the other,, 12.4.3.4.5). The issue does not occur yet, as the feature is not yet implemented.
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #5 from Lubos Lunak l.lunak at suse dot cz --- Gcc patch is in, r200941. Keeping open for libstdc++ to use the attribute for its relevant classes. I can try to submit a patch when I find the time, but I doubt I'll get past the most obvious classes, so anyone more knowledgeable about libstdc++ can feel free.
[Bug c++/57903] New: Object not getting constructed - Code misinterpreted as function declaration?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903
Bug ID: 57903
Summary: Object not getting constructed - Code misinterpreted
as function declaration?
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael at dietschi dot net
Created attachment 30508
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30508action=edit
Source file triggering the bug
Compiling this code:
class A
{
public:
A( int ) {}
};
class C
{
public:
C( A ) {}
void f() {}
};
int main( int /*argc*/, char */*argv*/[] )
{
int i = 0;
// OK
A a(i);
C c1(a);
c1.f();
// OK
C c2 = C( A(i) );
c2.f();
// not OK - why?
C c3( A(i) ); // It seems that c2 is not seen as an object but a function
declaration...
c3.f(); // ...hence this line forces a linker error!
return 0;
}
with this command-line: g++-4.6 -v -save-temps strange.cpp
[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 --- Comment #1 from michael at dietschi dot net --- Created attachment 30509 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30509action=edit command-line and output
[Bug fortran/57904] New: Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Bug ID: 57904 Summary: Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The test case is based on gfortran.dg/class_48.f90 - and the issue is exposed by r200954. Compiling the following test case with gfortran -m32 -O2 (or -m32 -Os) gives the warning: test.f90: In function '__final_test2_T.1838.constprop.0': test.f90:21:0: warning: iteration 2147483648 invokes undefined behavior [-Waggressive-loop-optimizations] class(t), allocatable :: a ^ Test case: program test call test2 () contains subroutine test2 () type t integer, allocatable :: x end type t type t2 class(t), allocatable :: a end type t2 type(t2) :: one, two allocate (two%a) one = two end subroutine test2 end program test
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Which are the relevant classes? It seems to me that we want to tag almost everything except a few RAII types such as std::lock_guard and std::unique_lock, which would be quite tedious. It's certainly applicable on all containers, and most streams except fstreams (which have constructors with side-effects.) I think your extend.texi change is wrong, a std::mutex that is unused is useless, its constructor and destructor don't do anything useful. A std::lock_guard that is unused is useless.
[Bug c++/57846] CRTP, templates, metaprogramming, forwarding and static member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57846 --- Comment #1 from Vincent vince.rev at gmail dot com --- Apparently, this is also a bug in the last version (4.9): http://stackoverflow.com/questions/17515079/crtp-templates-metaprogramming-forwarding-and-static-member-a-bug-in-g-4-8
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #6) std::lock_guard that is unused is useless. Oops, I meant is *not* useless! Sorry.
[Bug c++/57905] New: braced-init-list allowed in default template-argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905
Bug ID: 57905
Summary: braced-init-list allowed in default template-argument
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
[dcl.fct.default] 8.3.6/3 says
A default argument shall be specified … in a template-parameter (14.1); in the
latter case, the initializer-clause shall be an assignment-expression.
So a default template-argument cannot be a braced-init-list, yet this is
accepted without warning when using -Wall:
template int i = {} struct s;
Clang rejects it outright. I thought it was their bug but just happened to be
reading now about default arguments.
[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- See http://en.wikipedia.org/wiki/Most_vexing_parse
[Bug fortran/57906] New: Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 Bug ID: 57906 Summary: Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org gfortran.dg/coarray/lib_realloc_1.f90 (r200955) fails if compiled with optimization. It has: type t integer, allocatable :: CAF[:] end type t ... x = y which gives with -O0 the dump: D.1903 = x; x = y; x.caf = D.1903.caf; Namely: The fields of the struct x are updated from y - but the caf field is re-set to the previous value of x. (Reason: The x.caf.data is a pointer, whose previous address has to be kept. That's a special feature of coarray components.) With optimization, the x.caf = D.1903.caf line is effectively lost - such that x.caf.data and y.caf.data point to the same memory.
[Bug c++/57903] Object not getting constructed - Code misinterpreted as function declaration?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57903 --- Comment #3 from michael at dietschi dot net --- Oops! Thanks for clarification and sorry for the noise.
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #8 from Lubos Lunak l.lunak at suse dot cz --- (In reply to Jonathan Wakely from comment #6) Which are the relevant classes? It seems to me that we want to tag almost everything except a few RAII types such as std::lock_guard and std::unique_lock, which would be quite tedious. It's certainly applicable on all containers, and most streams except fstreams (which have constructors with side-effects.) Correct. And I do not see a better way than tagging everything where it applies. I think your extend.texi change is wrong, a std::mutex that is unused is useless, its constructor and destructor don't do anything useful. A std::lock_guard that is unused is *not* useless. Correct as well. But that doesn't come from my patch, that section was altered by Jason Merrill before committing, and I overlooked that. Can you fix that easily or should I submit a patch?
[Bug target/57907] New: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907
Bug ID: 57907
Summary: warning: switch -mcpu=cortex-a15 conflicts with
-march=armv7-a switch [enabled by default]
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.helm...@genode-labs.com
The manpage states that This option [-march] can be used in conjunction with
or instead of the -mcpu= option. and this works for, e.g., -mcpu=cortex-a9. On
the other GCC complains for -mcpu=cortex-a15 and -mcpu=cortex-a7 in conjunction
with -march=armv7-a.
The following command line reproduces the issue:
echo int main() {} | /usr/local/genode-gcc/bin/genode-arm-g++ -c -x c++ -
-o /tmp/stdin.o -march=armv7-a -mcpu=cortex-a15
stdin:1:0: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a
switch [enabled by default]
Examples in bugzilla never user both options for ARM but just -mcpu. Will the
combination be supported in the future or should I adapt the mcpu-only
approach? Does it have drawbacks?
[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #16 from Iain Sandoe iains at gcc dot gnu.org --- *** Bug 55654 has been marked as a duplicate of this bug. ***
[Bug target/55654] objc/obj-c++ failures present under darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55654 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Iain Sandoe iains at gcc dot gnu.org --- the image_info size fails are 48094 *** This bug has been marked as a duplicate of bug 48094 ***
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- I can fix the docs some time.
[Bug testsuite/55956] Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org --- This is another manifestation of 44107. The installed libgcc_s on darwin9 has an unwinder that does not recognise modern gcc output. The testsuite usually hides this by setting DYLD_LIBRARY_PATH/LD_LIBRARY_PATH to point to the newly-built libgcc_s (which, of course, works). It appears that the setting of DYLD_LIBRARY_PATH is not happening (or happening incorrectly) for the case that the testsuite (at least the acats portion) is run from the gcc dir. I have not tried to determine where the problem occurs or if it manifests in the same manner on Linux - since folks don't seem too concerned about it. Of course, it is potentially relevant that testing might be using different components depending on where it's invoked from. (I don't personally propose to do anything about this).
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #19 from Iain Sandoe iains at gcc dot gnu.org --- I have tried a number of ways to fix this - none of which are really satisfactory. 1. we could keep hacking on the code gen to cater for legacy output (not a good use of time with so many other darwin issues to deal with). 2. we could do some really hacky interposing of library code using undocumented dyld entry points (which is quite fun, but probably not an acceptable solution). 3. accept that the system is long out of security upgrade supports from the vendor - and install an up-to-date libgcc_s. 4. something else (feel free to suggest). I don't propose to investigate this further - but I am happy to provide a pre-built FAT libgcc_s.1.dylib tested on x86-apple-darwin9 and ppc-apple-darwin9. However, I don't have anywhere suitable to host it. NOTE: if you build/install your own libgcc_s.1.dylib on an x86 darwin9 you *must* build it FAT including i386/x86_64 *and* at least ppc/7400 if you want rosetta to function. sorry, can't justify any more effort on this one - I've replaced the libgcc_s.1.dylib in my Darwin9 systems with one built from 4.8 tip of branch. The gcc-4.6 solution will continue to work for anyone who wants to use it as a local patch.
[Bug c/57908] New: alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Bug ID: 57908 Summary: alignment of arrays allocated stack on amd64/x86_64: 16 bytes ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann at droneaud dot fr According to System V Application Binary Interface, AMD64 Architecture Processor Supplement, Draft Version 0.90 Aggregates and Unions - An array uses the same alignment as its elements, except that a local or global array variable that requires at least 16 bytes, or a C99 local or global variable-length array variable, always has alignment of at least 16 bytes.[4] No other changes required. [4] The alignment requirement allows the use of SSE instructions when operating on the array. The compiler cannot in general calculate the size of a variable-length array (VLA), but it is expected that most VLAs will require at least 16 bytes, so it is logical to mandate that VLAs have at least a 16-byte alignment. As I understand the ABI specifications, arrays allocated on stack must be aligned on 16 bytes boundaries, whatever its length is: eg. an array of 7 bytes get aligned on 16 bytes boundaries. A test program seems to verify that, with gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) : kind name address size alignment required Arrays object | u8 | 0x7fffefdd486f |1 | 1 |1 object | u8_0 | 0x7fffefdd4860 |8 |32 |1 object | u8_1 | 0x7fffefdd4850 |7 |16 |1 object | u8_2 | 0x7fffefdd4840 |6 |64 |1 object | u8_3 | 0x7fffefdd4830 |5 |16 |1 object | u8_4 | 0x7fffefdd4820 |4 |32 |1 object | u8_5 | 0x7fffefdd4810 |3 |16 |1 object | u8_6 | 0x7fffefdd4800 |2 | 2048 |1 object | u8_7 | 0x7fffefdd47ff |1 | 1 |1 object | u8_8 | 0x7fffefdd47fe |1 | 2 |1 IMHO it's a waste of memory and this behavor is inconsistent regarding structure layout: eg. arrays in structure are not aligned on 16 bytes boundary. But let's say the specification mandate such stack allocation, aligned on 16 bytes boundary. Then enter LLVM/Clang clang version 3.3 (tags/RELEASE_33/rc3): kind name address size alignment required Arrays object | u8 | 0x7fff45f4154f |1 | 1 |1 object | u8_0 | 0x7fff45f41547 |8 | 1 |1 object | u8_1 | 0x7fff45f41540 |7 |64 |1 object | u8_2 | 0x7fff45f4153a |6 | 2 |1 object | u8_3 | 0x7fff45f41535 |5 | 1 |1 object | u8_4 | 0x7fff45f41531 |4 | 1 |1 object | u8_5 | 0x7fff45f4152e |3 | 2 |1 object | u8_6 | 0x7fff45f4152c |2 | 4 |1 object | u8_7 | 0x7fff45f4152b |1 | 1 |1 object | u8_8 | 0x7fff45f4152a |1 | 2 |1 It seems that Clang is not aligning arrays on stack to 16 bytes boundary. Note: for both compiler, tested on Fedora 19, the results were produced with a test program compiled with default optimisation flag, with -O3, the results are quite the same. The source code of the test is available here: https://gitorious.org/opteya/alignment/blobs/master/stack-alignment.c
[Bug c/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #1 from Yann Droneaud yann at droneaud dot fr --- Additionally, for ARM target (ARMv7), it seems GCC align arrays on stack to 4 bytes boundary ... but I don't found the ABI specification that require such alignment. kind name address size alignment required Arrays object | u8 | 0xf6fff017 |1 | 1 |1 object | u8_0 | 0xf6fff00c |8 | 4 |1 object | u8_1 | 0xf6fff004 |7 | 4 |1 object | u8_2 | 0xf6ffeffc |6 | 4 |1 object | u8_3 | 0xf6ffeff4 |5 | 4 |1 object | u8_4 | 0xf6ffeff0 |4 |16 |1 object | u8_5 | 0xf6ffefec |3 | 4 |1 object | u8_6 | 0xf6ffefe8 |2 | 8 |1 object | u8_7 | 0xf6ffefe4 |1 | 4 |1 object | u8_8 | 0xf6ffefe3 |1 | 1 |1
[Bug target/57909] New: [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 Bug ID: 57909 Summary: [ARM] ICE with internal memcpy and -mno-unaligned-access Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yvan.roux at linaro dot org Created attachment 30510 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30510action=edit reduced test case compilling the attached reduced test case with the following command line produces an ICE. arm-linux-gnueabi-gcc -marm -march=armv7-a -mtune=cortex-a15 -mno-unaligned-access -c -o panic.o panic.i panic.i: In function 'bug': panic.i:10:1: error: unrecognizable insn: } ^ (insn 9 8 10 2 (set (reg:SI 114) (zero_extend:SI (unspec:HI [ (mem/u/c:HI (reg:SI 113) [0 MEM[(void *)aa]+0 S2 A32]) ] UNSPEC_UNALIGNED_LOAD))) panic.i:9 -1 (nil)) panic.i:10:1: internal compiler error: in extract_insn, at recog.c:2150
[Bug c/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Your test program is not fully testing things correctly. kind name address size alignment required object | u8_5 | 0x7fffefdd4810 |3 |16 |1 object | u8_6 | 0x7fffefdd4800 |2 | 2048 |1 object | u8_7 | 0x7fffefdd47ff |1 | 1 |1 Shows why. There are two variables right next to each other but the alignment recorded is 2048 but that was just accidental. The alignment of u8_6 is 16 due to the next variable at 10.
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-linux-gnu Status|UNCONFIRMED |RESOLVED Component|c |target Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- As I understand the ABI specifications, arrays allocated on stack must be aligned on 16 bytes boundaries, whatever its length is HUH? I don't read it that way. I read if the length is less than 16 bytes then it is same alignment as its elements; otherwise it is 16byte aligned. It does require VLAs to have 16byte alignment though.
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Created attachment 30511 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30511action=edit a first fix
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #4 from Yann Droneaud yann at droneaud dot fr --- (In reply to Andrew Pinski from comment #2) Your test program is not fully testing things correctly. kind name address size alignment required object | u8_5 | 0x7fffefdd4810 |3 |16 |1 object | u8_6 | 0x7fffefdd4800 |2 | 2048 |1 object | u8_7 | 0x7fffefdd47ff |1 | 1 |1 Shows why. There are two variables right next to each other but the alignment recorded is 2048 but that was just accidental. The alignment of u8_6 is 16 due to the next variable at 10. Have you noticed that u8_7 is an array of 1 element only ? Array of 1 element (bytes) only are not aligned on 16 bytes boundary. Array of 2 bytes and greater get aligned on 16 bytes boundary. Should I show another test case ?
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Yann Droneaud yann at droneaud dot fr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Yann Droneaud yann at droneaud dot fr --- (In reply to Yann Droneaud from comment #4) (In reply to Andrew Pinski from comment #2) Your test program is not fully testing things correctly. kind name address size alignment required object | u8_5 | 0x7fffefdd4810 |3 |16 |1 object | u8_6 | 0x7fffefdd4800 |2 | 2048 |1 object | u8_7 | 0x7fffefdd47ff |1 | 1 |1 Shows why. There are two variables right next to each other but the alignment recorded is 2048 but that was just accidental. The alignment of u8_6 is 16 due to the next variable at 10. Have you noticed that u8_7 is an array of 1 element only ? Array of 1 element (bytes) only are not aligned on 16 bytes boundary. Array of 2 bytes and greater get aligned on 16 bytes boundary. Should I show another test case ? kind name address size alignment required type |uint8_t |N/A |1 | N/A |1 type | uint8_t[2] |N/A |2 | N/A |1 Arrays object | u8_0 | 0x7fff7671e25f |1 | 1 |1 object | u8_1 | 0x7fff7671e250 |3 |16 |1 object | u8_2 | 0x7fff7671e240 |7 |64 |1 object | u8_3 | 0x7fff7671e230 |5 |16 |1 object | u8_4 | 0x7fff7671e220 |2 |32 |1 object | u8_5 | 0x7fff7671e21f |1 | 1 |1 object | u8_6 | 0x7fff7671e210 |3 |16 |1 object | u8_7 | 0x7fff7671e200 |5 | 512 |1 object | u8_8 | 0x7fff7671e1f0 |7 |16 |1 object | u8_9 | 0x7fff7671e1e0 |2 |32 |1 object | u8_10 | 0x7fff7671e1d0 | 11 |16 |1 object | u8_11 | 0x7fff7671e1c0 |3 |64 |1 object | u8_12 | 0x7fff7671e1b0 | 13 |16 |1 object | u8_13 | 0x7fff7671e1a0 |2 |32 |1 object | u8_14 | 0x7fff7671e19f |1 | 1 |1 object | u8_15 | 0x7fff7671e190 |2 |16 |1
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #6 from Yann Droneaud yann at droneaud dot fr --- Created attachment 30512 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30512action=edit Demonstrate stack allocation of array aligned on 16 bytes
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- Use -Os if you want no alignment for those arrays.
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Yann Droneaud from comment #8) Could someone comment on which optimisation is achieved by aligning such small arrays ? The simple answer is so each array is more likely to fit into a cache line: One use of this macro is to increase alignment of medium-size data to make it all fit in fewer cache lines. */
[Bug fortran/57910] New: ICE (segfault) with deferred-lemgth strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 Bug ID: 57910 Summary: ICE (segfault) with deferred-lemgth strings Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Blocks: 45170 Created attachment 30513 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30513action=edit Test case Test case by James Van Buskirk; from https://groups.google.com/forum/#!topic/comp.lang.fortran/j5GITiX1aYI Fails with: test.f90: In function 'strtest': test.f90:56:0: internal compiler error: Segmentation fault my_ptr = str_ptr(res,fstrlen(res)) ^ 0x9862ff crash_signal ../../gcc/toplev.c:333 0x97b51d tree_class_check ../../gcc/tree.h:3812 0x97b51d layout_decl(tree_node*, unsigned int) ../../gcc/stor-layout.c:553 0xb7352e build_decl_stat(unsigned int, tree_code, tree_node*, tree_node*) ../../gcc/tree.c:4360 0x807038 create_tmp_var_raw(tree_node*, char const*) ../../gcc/gimplify.c:403 0x5c9c7d gfc_create_var_np ../../gcc/fortran/trans.c:90 0x5c9c7d gfc_create_var(tree_node*, char const*) ../../gcc/fortran/trans.c:107 0x5ca987 gfc_evaluate_now_loc(unsigned int, tree_node*, stmtblock_t*) ../../gcc/fortran/trans.c:127 0x6021a6 gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:3555 0x5fe548 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc/fortran/trans-expr.c:4869 0x60035a gfc_conv_function_expr ../../gcc/fortran/trans-expr.c:5563
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #8 from Yann Droneaud yann at droneaud dot fr --- Using -Os show different results: Arrays object | u8_0 | 0x7fff9b4c05bc |1 | 4 |1 object | u8_1 | 0x7fff9b4c05c7 |3 | 1 |1 object | u8_2 | 0x7fff9b4c05da |7 | 2 |1 object | u8_3 | 0x7fff9b4c05d0 |5 |16 |1 object | u8_4 | 0x7fff9b4c05bf |2 | 1 |1 object | u8_5 | 0x7fff9b4c05bd |1 | 1 |1 object | u8_6 | 0x7fff9b4c05ca |3 | 2 |1 object | u8_7 | 0x7fff9b4c05d5 |5 | 1 |1 object | u8_8 | 0x7fff9b4c05e1 |7 | 1 |1 object | u8_9 | 0x7fff9b4c05c1 |2 | 1 |1 object | u8_10 | 0x7fff9b4c05e8 | 11 | 8 |1 object | u8_11 | 0x7fff9b4c05cd |3 | 1 |1 object | u8_12 | 0x7fff9b4c05f3 | 13 | 1 |1 object | u8_13 | 0x7fff9b4c05c3 |2 | 1 |1 object | u8_14 | 0x7fff9b4c05be |1 | 2 |1 object | u8_15 | 0x7fff9b4c05c5 |2 | 1 |1 So GCC is using 16 bytes to align array allocated on stack by default but it's not enforcing such alignment. I guess it's all about optimisation ... but wasting up to 14 bytes to get an array of 2 bytes aligned might be overkill. Could someone comment on which optimisation is achieved by aligning such small arrays ? Regards.
[Bug target/57908] alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908 --- Comment #10 from Yann Droneaud yann at droneaud dot fr --- (In reply to Andrew Pinski from comment #9) (In reply to Yann Droneaud from comment #8) Could someone comment on which optimisation is achieved by aligning such small arrays ? The simple answer is so each array is more likely to fit into a cache line: One use of this macro is to increase alignment of medium-size data to make it all fit in fewer cache lines. */ Thanks for the investigation. Initially I thought it would be better to pack such arrays to fit whole cache line: fewer cache lines will be used and most of the arrays would be already in cache lines. But according to http://stackoverflow.com/a/7281770: On x86 cache lines are 64 bytes, however, to prevent false sharing, you need to follow the guidelines of the processor you are targeting (intel has some special notes on its netburst based processors), generally you need to align to 64 bytes for this (intel states that you should also avoid crossing 16 byte boundries). This start to make sense to me. I'm likely buying the argument for global variables but for local variables, I think they are probably not going to be shared a lot across CPUs. But I haven't data for this so I won't continue that way. Thanks a lot for answer my question.
[Bug target/57911] New: alignment of arrays allocated stack on ARM : 4 bytes ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911 Bug ID: 57911 Summary: alignment of arrays allocated stack on ARM : 4 bytes ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yann at droneaud dot fr Hi Following discussion in bug #57908, especially bug #57908 comment #1, on ARMv7, I'm very surprised that array of bytes are aligned on 4 bytes boundary when allocated on stack. Using attachment #30512, I'm able to produce the following results using GCC arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2013.05-24) 4.7.3. Another custom GCC 4.7.2 produces same results. with default option: kind name address size alignment required type |uint8_t |N/A |1 | N/A |1 type | uint8_t[2] |N/A |2 | N/A |1 Arrays object | u8_0 | 0xf6fff00c |1 | 4 |1 object | u8_1 | 0xf6fff008 |3 | 8 |1 object | u8_2 | 0xf6fff000 |7 | 4096 |1 object | u8_3 | 0xf6ffeff8 |5 | 8 |1 object | u8_4 | 0xf6ffeff4 |2 | 4 |1 object | u8_5 | 0xf6ffeff0 |1 |16 |1 object | u8_6 | 0xf6ffefec |3 | 4 |1 object | u8_7 | 0xf6ffefe4 |5 | 4 |1 object | u8_8 | 0xf6ffefdc |7 | 4 |1 object | u8_9 | 0xf6ffefd8 |2 | 8 |1 object | u8_10 | 0xf6ffefcc | 11 | 4 |1 object | u8_11 | 0xf6ffefc8 |3 | 8 |1 object | u8_12 | 0xf6ffefb8 | 13 | 8 |1 object | u8_13 | 0xf6ffefb4 |2 | 4 |1 object | u8_14 | 0xf6ffefb0 |1 |16 |1 object | u8_15 | 0xf6ffefac |2 | 4 |1 with -Os: kind name address size alignment required type |uint8_t |N/A |1 | N/A |1 type | uint8_t[2] |N/A |2 | N/A |1 Arrays object | u8_0 | 0xf6ffef9c |1 | 4 |1 object | u8_1 | 0xf6ffefb8 |3 | 8 |1 object | u8_2 | 0xf6ffefd4 |7 | 4 |1 object | u8_3 | 0xf6ffefc4 |5 | 4 |1 object | u8_4 | 0xf6ffefa8 |2 | 8 |1 object | u8_5 | 0xf6ffefa0 |1 |32 |1 object | u8_6 | 0xf6ffefbc |3 | 4 |1 object | u8_7 | 0xf6ffefcc |5 | 4 |1 object | u8_8 | 0xf6ffefdc |7 | 4 |1 object | u8_9 | 0xf6ffefac |2 | 4 |1 object | u8_10 | 0xf6ffefe4 | 11 | 4 |1 object | u8_11 | 0xf6ffefc0 |3 |64 |1 object | u8_12 | 0xf6ffeff0 | 13 |16 |1 object | u8_13 | 0xf6ffefb0 |2 |16 |1 object | u8_14 | 0xf6ffefa4 |1 | 4 |1 object | u8_15 | 0xf6ffefb4 |2 | 4 |1 I'm reading AAPCS (IHI0042E) and I don't found any requirement for array allocated on stack to be aligned on 4 bytes. It's a pity that -Os, as suggested by Andrew Pinski in bug #57908 comment #7, doesn't align the array on 1 bytes boundary.
[Bug fortran/57912] New: gfortran/coarray/alloc_comp_2.f90 ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Bug ID: 57912 Summary: gfortran/coarray/alloc_comp_2.f90 ICE Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org On the trunk, gfortran(f951) ICEs when compiled with .../obj/gcc/f951 .../gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90 -fcoarray=lib -O2 __copy_parent_coarray_component_Child .../gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90:17:0: internal compiler error: in gfc_trans_scalar_assign, at fortran/trans-expr.c:6862 class(child) this ^ 0x566d2f translate_all_program_units ../../gcc/gcc/fortran/parse.c:4496 0x566d2f gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4706 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. This ICE goes away when this commit is reversed: commit 435feecde2fc6bf5627aad91805bbd69ddbbe830 Author: burnus burnus@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Jul 15 08:25:48 2013 + 2013-07-15 Tobias Burnus bur...@net-b.de * trans-array.h (gfc_deallocate_alloc_comp_no_caf, gfc_reassign_alloc_comp_caf): New prototype. * trans-array.c (enum): Add DEALLOCATE_ALLOC_COMP_NO_CAF and COPY_ALLOC_COMP_CAF. (structure_alloc_comps): Handle it. (gfc_reassign_alloc_comp_caf, gfc_deallocate_alloc_comp_no_caf): New function. (gfc_alloc_allocatable_for_assignment): Call it. * trans-expr.c (gfc_trans_scalar_assign, gfc_trans_arrayfunc_assign, gfc_trans_assignment_1): Ditto. * parse.c (parse_derived): Correctly set coarray_comp. * resolve.c (resolve_symbol): Improve error wording. 2013-07-15 Tobias Burnus bur...@net-b.de * gfortran.dg/coarray_lib_realloc_1.f90: New. * gfortran.dg/coarray/lib_realloc_1.f90: New. * gfortran.dg/coarray_6.f90: Add dg-error. I observed this behaviour on a trunk compiler built native on x86_64-unknown-linux-gnu.
[Bug c++/57913] New: [C++11] Explicitly defaulted constructor does not respect access specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57913
Bug ID: 57913
Summary: [C++11] Explicitly defaulted constructor does not
respect access specifier
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: charlie at charliedyson dot net
In particular, the following and similar examples will compile:
class X
{
X() = default; // Should be private
};
int main()
{
X x;
}
Tested with GCC Explorer.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Iain Sandoe from comment #19) Yes. It might be a more profitable use of time to work on moving from the compatibility unwinder onto the newer compact unwinder for modern darwin.
[Bug c++/56429] [C++11] Explicitly defaulted private constructor is not private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||charlie at charliedyson dot net --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 57913 has been marked as a duplicate of this bug. ***
[Bug c++/57913] [C++11] Explicitly defaulted constructor does not respect access specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57913 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 56429 ***
[Bug target/55656] objc/obj-c++ failures present under darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-16 Ever confirmed|0 |1 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Jack Howarth from comment #0) r200977 (mainline) r200980 (4.8) r200982 (4.7) Should have resolved those issues related to interface changes. === obj-c++ tests === FAIL: obj-c++.dg/cxx-ivars-3.mm -fnext-runtime execution test This is a real new fail - however, it remains to be seen what the origin is. The system (clang) compiler generates the same output as we do. So (a) the fault might lie in the vendor's library - or (b) the interface might have been changed.
[Bug target/55657] objc/obj-c++ failures present under darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55657 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-16 Ever confirmed|0 |1 --- Comment #8 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Jack Howarth from comment #0) r200977 (mainline) r200980 (4.8) r200982 (4.7) Should have resolved those issues related to interface changes. === obj-c++ tests === FAIL: obj-c++.dg/gnu-api-2-objc.mm -fnext-runtime execution test FAIL: obj-c++.dg/property/at-property-13.mm -fgnu-runtime execution test === objc tests === FAIL: objc.dg/gnu-api-2-objc.m -fnext-runtime execution test these are real new failures, to be investigated.
[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 30514 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30514action=edit proposed fix. So the problem here is that when we bind multiple objects together (each of which has an anonymous image_info section) LTO (unlike the system linker) doens't know that these should be coalesced - and, TBH, I doubt we're going to teach it about a darwin-specific section ... Luckily, the content of the image_info section only depends on command line flags. So this is a proposed solution. 1. allow the requisite ObjC flags to be recognized by lto1. 2. don't generate the image_info section in the FE instead .. 3. take note of the flag values, and (IFF there is some ObjC metadata present in the object) emit the image_info section from the back end. I've checked that this flies on Darwin12 with XCode 4.6.3 [with lto enabled] - but I don't have the XCode 4.2 configuration on Darwin10. (it has also been tested on older versions of the tool-chain). Mike - opinions on the solution? others: wider testing please
[Bug fortran/57912] gfortran/coarray/alloc_comp_2.f90 ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Tue Jul 16 20:54:37 2013 New Revision: 200987 URL: http://gcc.gnu.org/viewcvs?rev=200987root=gccview=rev Log: 2013-07-16 Tobias Burnus bur...@net-b.de PR fortran/57912 * trans-expr.c (gfc_trans_scalar_assign): Correct if condition for caf realloc. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug libstdc++/57914] New: Memory leak in __cxa_thread_atexit when using thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57914
Bug ID: 57914
Summary: Memory leak in __cxa_thread_atexit when using
thread_local
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: stephen.d.croll at gmail dot com
Valgrind is reporting leaked blocks in __cxa_thread_atexit,
apparently one per thread, in the following code:
#include iostream
#include thread
struct Foo
{
~Foo()
{
}
void
hello_world()
{
std::cout __PRETTY_FUNCTION__ '\n';
}
};
thread_local Foo foo;
void
hello_world_thread()
{
foo.hello_world();
}
int main()
{
for ( int i = 0; i 10; ++i )
{
std::thread thread( hello_world_thread );
thread.join();
}
}
Program compiled as follows:
$ g++ -std=gnu++11 -Og -g3 -Wall -Wextra -fno-omit-frame-pointer
thread_local_bug.cc
GCC info:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/localhome/scroll/tools/2/x86_64/stow/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure
--prefix=/localhome/scroll/tools/2/x86_64/stow/gcc-4.8.1 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-cxx-flags='-fno-omit-frame-pointer -g3' --enable-languages=c,c++
--enable-libstdcxx-time=rt --enable-checking=release --enable-build-with-cxx
--disable-werror --disable-multilib --disable-bootstrap --with-system-zlib
Thread model: posix
gcc version 4.8.1 (GCC)
Valgrind version:
$ valgrind --version
valgrind-3.8.1
Valgrind command line:
$ valgrind --leak-check=full --verbose ./a.out /dev/null
Tail-end of valgrind output:
==7102== HEAP SUMMARY:
==7102== in use at exit: 240 bytes in 10 blocks
==7102== total heap usage: 21 allocs, 11 frees, 1,104 bytes allocated
==7102==
==7102== Searching for pointers to 10 not-freed blocks
==7102== Checked 216,120 bytes
==7102==
==7102== 240 bytes in 10 blocks are definitely lost in loss record 1 of 1
==7102==at 0x4C29969: operator new(unsigned long, std::nothrow_t const)
(vg_replace_malloc.c:329)
==7102==by 0x4E8E53E: __cxa_thread_atexit (atexit_thread.cc:119)
==7102==by 0x400F69: _ZTH3foo (thread_local_bug.cc:17)
==7102==by 0x400F79: hello_world_thread() (thread_local_bug.cc:17)
==7102==by 0x401006: std::thread::_Implstd::_Bind_simplevoid (*())()
::_M_run() (functional:1732)
==7102==by 0x4EE4830: execute_native_thread_routine (thread.cc:84)
==7102==by 0x5A10E99: start_thread (pthread_create.c:308)
==7102==by 0x573DCCC: clone (clone.S:112)
==7102==
==7102== LEAK SUMMARY:
==7102==definitely lost: 240 bytes in 10 blocks
==7102==indirectly lost: 0 bytes in 0 blocks
==7102== possibly lost: 0 bytes in 0 blocks
==7102==still reachable: 0 bytes in 0 blocks
==7102== suppressed: 0 bytes in 0 blocks
==7102==
==7102== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--7102--
--7102-- used_suppression: 2 dl-hack3-cond-1
==7102==
==7102== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Notes:
- If you change the number of threads created, the number of leaked
blocks matches the number of threads.
- From the valgrind stacktrace, thread_local_bug.cc:17 is the line:
'thread_local Foo foo;'
[Bug fortran/57912] gfortran/coarray/alloc_comp_2.f90 ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57912 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |RESOLVED CC|bur...@net-b.de | Resolution|--- |FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED. Thanks for the report.
[Bug c/57915] New: ICE in set_address_disp, at rtlanal.c:5537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915
Bug ID: 57915
Summary: ICE in set_address_disp, at rtlanal.c:5537
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: etienne_lorrain at yahoo dot fr
On latest Fedora, with: gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
I get:
$ /usr/bin/gcc -m32 -Os bug.c
bug.c: In function ‘menu’:
bug.c:59:1: internal compiler error: in set_address_disp, at rtlanal.c:5537
}
^
Please submit a full bug report,
possibly related to asm(... X (*str)) , I use X mostly because I had
problems using m when the pointer points to local variable on the stack.
The problem do not exists with previous compiler versions, not a new code.
The simplified source code I finished to get after few hours is:
$ cat bug.c
extern inline const char *
_strnchr (const char *str, char c, unsigned size)
{
asm (cld ; repne scasb %%es:(%%edi),%%al
: +c (size), +D (str): a (c), X (*str):cc);
return str - 1;
}
extern inline unsigned
strlen (const char *str)
{
return _strnchr (str, '\0', (~0)) - str;
}
extern inline void
_strncpy (char *dst, const char *src, unsigned nb)
{
unsigned len = strlen (src);
if (len nb)
len = nb;
__builtin_memcpy (dst, src, len);
dst[len] = '\0';
}
extern inline char *
strcpy (char *dst, const char *src)
{
_strncpy (dst, src, (~0));
return dst;
}
typedef struct
{
char go_msg[8];
char scanpath[16];
} gujin_param_t;
extern gujin_param_t copy_gujin_param;
enum { kernel_bottom_menu, setup_bottom_menu } type;
unsigned short getkey(void);
unsigned timeout;
unsigned menu (void)
{
char local_scanpath[sizeof (copy_gujin_param.scanpath)];
strcpy (local_scanpath, copy_gujin_param.scanpath);
for (;;)
{
unsigned short key = getkey();
if ((type == kernel_bottom_menu) ? (key == (0x1312)) : key == (0x3900 | '
'))
{
strcpy (local_scanpath, copy_gujin_param.scanpath);
}
}
}
Regards, Etienne.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Brooks Moses brooks at gcc dot gnu.org changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #10 from Brooks Moses brooks at gcc dot gnu.org --- FWIW, this issue also affected GLIBC. Pointer to discussion, along with fixes, here: http://sourceware.org/ml/libc-alpha/2013-07/msg00306.html It seems to me -- based on my own experience, as well as Max's -- that the -ftree-distribute-patterns documentation could be notably improved. In my case, I read it clearly and understood it to mean that it was only responsible for the loop-distribution portion of the rearrangement in the code examples, and that the replacement of a loop by a memcpy call was some other optimization pass. Other than the documentation issues, this seems like a non-bug.
[Bug libstdc++/57916] New: Improve std::sort paritioning by explicitly employing the pivot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
Bug ID: 57916
Summary: Improve std::sort paritioning by explicitly employing
the pivot
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexey.tourbin at gmail dot com
Created attachment 30515
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30515action=edit
Move the median back to its pivot position. Exclude the pivot from further
partitioning.
In the original SGI code, partitioning does not use the concept of pivot
explicitly. The routine __unguarded_partition(first, last, pivot) only cuts
the sequence into two halves: [ = pivot | = pivot]. Note that the actual
pivot element used for partitioning can end up anywhere within the sequence,
not necessarily adjacent to the cut point. (Also, note that the name
__unguarded indicates that certain boundary checks are omitted, which places
some restrictions on how the pivot can be selected.)
In 2009, Chris Jefferson introduced a new helper function,
__unguarded_partition_pivot(first, last) which calls __unguarded_partition
using the median of 3 elements as a pivot. The median is actually placed into
the first element of the sequence and excluded from partitioning: [pivot| =
pivot | = pivot]. (Since this pivot selection scheme satisfies the
restrictions placed by __unguarded_partition, the __unguarded part ought to
be excluded from the name of this helper function.)
However, when partitioning is finished, this helper routine does NOT install
the pivot back to its final position: [ = pivot | pivot | = pivot ].
Although it can be argued that the resulting code is still correct, it does not
follow the common practice and misses an opportunity for optimization. Indeed,
by installing the pivot back to its final position, we can exclude it from
further partitioning stages. Although the change is small, it propagates
throughout partitioning tree and produces a cumulative effect. Measurements
show (see below) that this change improves std::sort running time by 2% to %3.
The same technique of excluding the pivot can also be applied to __introselect
helper function (used to implement the nth_element routine). Actually we can
check whether the pivot returned by partitioning is exactly the nth element,
and return immediately in this case. Although an improvement in running time,
if any, is hard to measure, there is an important special case: when the
nth_element is used to select the middle element of the sequence, and the
sequence is already sorted, only one partitioning stage will be executed.
I use the following program to evaluate the effect on the running time of
std::sort.
#include iostream
#include algorithm
#include cstdlib
#include ctime
#define N (64 20)
int a[N];
int main()
{
for (size_t i = 0; i N; i++)
a[i] = rand();
std::time_t start = std::clock();
std::sort(a, a + N);
std::cout (clock() - start) / (double) CLOCKS_PER_SEC std::endl;
return 0;
}
(before the change)
$ g++ -O2 test-sort.cc ./a.out
9.48
(after the change)
$ g++ -I. -O2 test-sort.cc ./a.out
9.29
Callgrind annotations also indicate an improvement - the number of instruction
reads has actually dropped by 10%!
(before this change)
16,344,046,167 PROGRAM TOTALS
10,249,743,434 ???:void std::__introsort_loopint*, long(int*, int*, long)'2
2,263,595,692 ???:main
1,742,665,662 /usr/src/debug/glibc-2.17-alt5/stdlib/random_r.c:random_r
1,140,850,688 /usr/src/debug/glibc-2.17-alt5/stdlib/random.c:random
677,198,672 ???:void std::__introsort_loopint*, long(int*, int*, long)
268,435,456 /usr/src/debug/glibc-2.17-alt5/stdlib/rand.c:rand
(after the change)
14,976,731,729 PROGRAM TOTALS
9,180,509,971 ???:void std::__introsort_loopint*, long(int*, int*, long)'2
2,110,233,226 ???:main
1,742,665,662 /usr/src/debug/glibc-2.17-alt5/stdlib/random_r.c:random_r
1,140,850,688 /usr/src/debug/glibc-2.17-alt5/stdlib/random.c:random
532,670,993 ???:void std::__introsort_loopint*, long(int*, int*, long)
268,435,456 /usr/src/debug/glibc-2.17-alt5/stdlib/rand.c:rand
[Bug middle-end/35308] Straight line strength reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- Conditional candidate processing was completed a couple of months ago. While there are improvements I plan to look at someday, the basic work is done, so closing the issue.
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #1 from Yvan Roux yvan.roux at linaro dot org --- The issue is that an UNSPEC_UNALIGNED_LOAD insn is emitted whereas the flag -mno-unaligned-access is passed, which implies that this insn is not recognized. The generation of the unaligned load is made in the gen_movmem_ldrd_strd function introduced at rev198970, there is a test that prevent doing calls to gen_unaligned_loadhiu when unaligned access are not authorized and src and dst are unaligned, but if they are aligned the call is made. The attached patch fixes the issue, but is still under validation.
