[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 --- Comment #4 from Jakub Jelinek 2013-01-15 07:55:06 UTC --- Please google around on "undefined behavior", you'll find various FAQs about it. When a program triggers undefined behavior, anything can happen, the compiler can optimize based on the fact that such behavior won't happen in a program, as a bonus in this case you get a warning telling you your bug. There is no graceful/expected behavior for undefined behavior, otherwise it wouldn't be undefined.
[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 JoeSoe changed: What|Removed |Added CC||b1314361 at rmqkr dot net --- Comment #3 from JoeSoe 2013-01-15 07:15:41 UTC --- Hi Jakub Jelinek, can you elaborate? What does it mean to say: "The testcase is invalid, the bug is only on the side of the testcase." ? Why does gcc not yield the "graceful/expected" result, and why will no effort be undertaken to make it yield the "graceful/expected" result? For example: Is it because of optimizations, that would be removed, if it were to yield the "graceful/expected" result?? In other words: what's the background on this? Thanks.
[Bug pending/55987] New: Redundant constant emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55987
Bug #: 55987
Summary: Redundant constant emitted
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pending
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: til...@code-monkey.de
Target: arm
For this code
uint32_t add (uint32_t x, uint32_t y)
{
uint32_t a, b;
a = (x & 0x7f7f7f7f) + (y & 0x7f7f7f7f);
b = (x ^ y) & ~0x7f7f7f7f;
return a ^ b;
}
gcc 4.7.2 generates the following machine code for ARMv5:
$ gcc -Wall -O2 -mtune=arm9tdmi -march=armv5te -S add.c
ldrr2, .L2 @ .word 2139062143
ldrr3, .L2+4 @ .word -2139062144
eorip, r1, r0
andr1, r1, r2
andr2, r0, r2
andr3, ip, r3
addr0, r1, r2
eorr0, r3, r0
bxlr
gcc missed that we can use bic to clear the low bits, which means
we don't need that 2nd constant:
ldrr2, .L2 @ .word 2139062143
eorip, r1, r0
bicip, ip, r2 @ use bic instead of and
andr1, r1, r2
andr0, r0, r2
addr0, r0, r1
eorr0, r0, ip
bxlr
[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #1 from Kostya Serebryany 2013-01-15 06:12:27 UTC --- [DISCLAIMER] I don't have access nor any experience with powerpc. Could you please insert various debugging Printf calls before the assertion in asan_thread.cc:74? Basically, print all local variables and also show the contents of /proc/self/maps.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Paul Thomas 2013-01-15 05:34:25 UTC --- Hopefully, it will stay fixed this time! Thanks Dominique. Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #10 from Paul Thomas 2013-01-15 05:29:07 UTC --- Author: pault Date: Tue Jan 15 05:29:01 2013 New Revision: 195185 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195185 Log: 2013-01-15 Paul Thomas PR fortran/54286 * expr.c (gfc_check_pointer_assign): Check for presence of 's2' before using it. 2013-01-15 Paul Thomas PR fortran/54286 * gfortran.dg/proc_ptr_result_8.f90 : Add module 'm' to check case where interface is null. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_8.f90
[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986 --- Comment #2 from David Krauss 2013-01-15 04:48:47 UTC --- Passing `-O2` additionally causes it to skip a condition like `(i == 0 || i != 0)`, so it looks like a general issue with expression simplification bypassing use.
[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986 --- Comment #1 from David Krauss 2013-01-15 04:47:53 UTC --- Passing `-O2` additionally causes it to skip a condition like `(i == 0 || i != 0)`, so it looks like a general issue with expression simplification bypassing ODR-use.
[Bug c++/55986] New: RHS of logical operators may render LHS unevaluated in constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986 Bug #: 55986 Summary: RHS of logical operators may render LHS unevaluated in constant-expression Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pot...@mac.com This compiles without incident, despite using a non-constant object in a constant-expression: int i; static_assert( i || true, "" ); static_assert( ! ( i && false ), "" ); It appears to be assuming that || and && are commutative, but short-circuiting only works in one direction.
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #7 from H.J. Lu 2013-01-15 02:19:55 UTC --- There are already R_386_SIZE32 38 word32 Z + A R_X86_64_SIZE32 32 word32 Z + A R_X86_64_SIZE64 33 word64 Z + A They should work here.
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Andrew Pinski 2013-01-15 01:17:32 UTC --- .
[Bug c/55985] New: Misleading message about which variable 'may be used uninitialized in this function'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55985
Bug #: 55985
Summary: Misleading message about which variable 'may be used
uninitialized in this function'
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jonathan.leff...@gmail.com
The problem has been reduced to the following 30 lines of code with no
preprocessing required.
typedef struct vtype { int type; } vtype_t;
typedef struct field { int length; } field_t;
typedef struct clist { char *tuple; field_t *fields; } clist_t;
extern int cvint(const char *p);
extern void updtypes(clist_t *clist, int ocnt, vtype_t *obind);
void
updtypes(clist_t *clist, int ocnt, vtype_t *obind)
{
char*tupstart = clist->tuple;
char*savtupstart;
int colsize = 0;
field_t *field = clist->fields;
for (int cnt = ocnt; cnt--; field++, obind++)
{
unsigned col_flags = 0;
tupstart += colsize;
colsize = cvint(tupstart+1);
if (*tupstart & 1)
col_flags |= 0x04;
tupstart += 5;
if (col_flags & 0x04)
tupstart = savtupstart;
}
}
The problem is that compilation like this refers to 'tupstart' as the
uninitialized variable, not 'savtupstart'. The source file was called
'gccbug.c' for this reproduction.
$ gcc-4.7.1 -O3 -Werror -Wall -g -std=c99 -c gccbug.c
gccbug.c: In function ‘updtypes’:
gccbug.c:20:18: error: ‘tupstart’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
$ gcc-4.7.1 -Werror -Wall -g -std=c99 -c gccbug.c
gccbug.c: In function ‘updtypes’:
gccbug.c:29:22: error: ‘savtupstart’ may be used uninitialized in this function
[-Werror=uninitialized]
cc1: all warnings being treated as errors
$
The real problem is that savtupstart is not initialized.
Compilation with '-v' too gives:
$ gcc-4.7.1 -v -O3 -Werror -Wall -g -std=c99 -c gccbug.c
Using built-in specs.
COLLECT_GCC=/usr/gcc/v4.7.1/bin/gcc
Target: x86_64-unknown-linux-gnu
Configured with: /work4/jleffler/open.source/GCC/gcc-4.7.1/configure
--prefix=/usr/gcc/v4.7.1 --with-gmp=/usr/gnu64 --with-mpfr=/usr/gnu64
-with-mpc=/usr/gnu64
Thread model: posix
gcc version 4.7.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-O3' '-Werror' '-Wall' '-g' '-std=c99' '-c'
'-mtune=generic' '-march=x86-64'
/work5/gcc/v4.7.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1 -quiet
-v -iprefix /work5/gcc/v4.7.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/
gccbug.c -quiet -dumpbase gccbug.c -mtune=generic -march=x86-64 -auxbase gccbug
-g -O3 -Werror -Wall -std=c99 -version -o /tmp/ccYrtwtL.s
GNU C (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112207
ignoring nonexistent directory
"/work5/gcc/v4.7.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/work5/gcc/v4.7.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include"
ignoring duplicate directory
"/work5/gcc/v4.7.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed"
ignoring nonexistent directory
"/work5/gcc/v4.7.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/work5/gcc/v4.7.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
/work5/gcc/v4.7.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
/usr/local/include
/work5/gcc/v4.7.1/bin/../lib/gcc/../../include
/usr/include
End of search list.
GNU C (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112207
Compiler executable checksum: 2d58955a5e5707524f76b1886c2957fc
gccbug.c: In function ‘updtypes’:
gccbug.c:20:18: error: ‘tupstart’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
$
The machine where it is running, and was built, is RHEL5:
$ uname -a
Linux toru 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
$
(Yes, archaic...sorry about that.)
The variable names and function names have been renamed from the original code;
it is unlikely that anyone could spot where it comes from. The structure types
have been renamed and their content minimized. The reduced code does not do
anything useful. Most changes to the code seem to give the correct
'savtupstart' message; I'm sure there are changes I've not tried that don't
change the erroneous output, but not all that many.
[Bug other/55982] __strncat_chk is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55982 --- Comment #2 from Paul Pluzhnikov 2013-01-15 00:59:57 UTC --- Patch mailed: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00756.html
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 lailavrazda1979 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #8 from lailavrazda1979 at gmail dot com 2013-01-14 23:43:54 UTC --- Oh, okay. That makes sense. Thank you.
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Andrew Pinski 2013-01-14 23:32:17 UTC --- (In reply to comment #6) > So, you need GCC 4.8 to build GCC 4.8? That's just... why? Doesn't that mean > it's basically impossible to build GCC 4.8 without a binary of it first? No you need a 4.8 cross compiler to build a 4.8 "native" compiler. So you should build a 4.8 cross compiler which will include all the target libraries and then you do a 4.8 Canadian cross (you just need to do "make all-host && make install-host" as you already have all the libraries done by the normal cross).
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #6 from lailavrazda1979 at gmail dot com 2013-01-14 23:18:30 UTC --- So, you need GCC 4.8 to build GCC 4.8? That's just... why? Doesn't that mean it's basically impossible to build GCC 4.8 without a binary of it first?
[Bug fortran/55984] New: ICE: gfc_trans_code(): Bad statement code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984 Bug #: 55984 Summary: ICE: gfc_trans_code(): Bad statement code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl First, sorry for not reducing the test case further more. Second, here's a recipe to reproduce the ICE: $ cat bug1.f module bcd_m type, abstract :: bcd_t contains procedure(bcd_fill_halos), deferred :: fill_halos end type abstract interface subroutine bcd_fill_halos(this) import :: bcd_t class(bcd_t ) :: this end subroutine end interface end module module solver_m use bcd_m type, abstract :: solver_t integer :: n, hlo class(bcd_t), pointer :: bcx, bcy contains procedure(solver_advop), deferred :: advop end type abstract interface subroutine solver_advop(this) import solver_t class(solver_t) :: this end subroutine end interface contains end module module solver_mpdata_m use solver_m type :: mpdata_t class(bcd_t), pointer :: bcx, bcy contains procedure :: advop => mpdata_advop end type contains subroutine mpdata_advop(this) class(mpdata_t) :: this associate ( bcx => this%bcx, bcy => this%bcy ) call bcx%fill_halos() end associate end subroutine end module $ /usr/lib/gcc-snapshot/bin/gfortran -ffree-form -std=f2008 bug1.f bug1.f: In function 'mpdata_advop': bug1.f:42:0: internal compiler error: gfc_trans_code(): Bad statement code call bcx%fill_halos() ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136] ... HTH, Sylwester
[Bug fortran/55983] New: ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 Bug #: 55983 Summary: ICE in find_typebound_proc_uop, at fortran/class.c:2711 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl First, sorry for not reducing the test case further. Second, here's the way to reproduce it: $ cat bug2.f module bcd_m type, abstract :: bcd_t contains procedure(bcd_fill_halos), deferred :: fill_halos end type abstract interface subroutine bcd_fill_halos(this) import :: bcd_t class(bcd_t ) :: this end subroutine end interface end module module solver_mpdata_m type :: mpdata_t class(bcd_t), pointer :: bcx, bcy contains procedure :: advop => mpdata_advop end type contains subroutine mpdata_advop(this) class(mpdata_t) :: this associate ( bcx => this%bcx, bcy => this%bcy ) call bcx%fill_halos() end associate end subroutine end module $ /usr/lib/gcc-snapshot/bin/gfortran -ffree-form -std=f2008 bug2.f f951: internal compiler error: in find_typebound_proc_uop, at fortran/class.c:2711 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136] ... HTH, Sylwester
[Bug other/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target||i?86-*-* x86_64-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-14
Ever Confirmed|0 |1
--- Comment #3 from Andrew Pinski 2013-01-14
23:08:10 UTC ---
The tree level is correct:
__atomic_store_8 (&MEM[(struct __atomic_base *)&y]._M_i, 4294967298, 5);
__atomic_store_8 (&MEM[(struct __atomic_base *)&y]._M_i, 12884901892, 5);
Expansion is correct:
;; __atomic_store_8 (&MEM[(struct __atomic_base *)&y]._M_i, 4294967298, 5);
(insn 31 30 32 (set (reg:DI 84)
(const_int 4294967298 [0x10002]))
/data1/src/gcc-cavium/toolchain/x86_64-tools/bin/../lib/gcc/x86_64-montavista-linux-gnu/4.7.0/../../../../x86_64-montavista-linux-gnu/include/c++/4.7.0/bits/atomic_base.h:438
-1
(nil))
(insn 32 31 33 (set (mem/v:DI (symbol_ref:DI ("y") [flags 0x2] ) [-1 S8 A64])
(reg:DI 84))
/data1/src/gcc-cavium/toolchain/x86_64-tools/bin/../lib/gcc/x86_64-montavista-linux-gnu/4.7.0/../../../../x86_64-montavista-linux-gnu/include/c++/4.7.0/bits/atomic_base.h:438
-1
(nil))
(insn 33 32 0 (set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0 A8])
] UNSPEC_MFENCE))
/data1/src/gcc-cavium/toolchain/x86_64-tools/bin/../lib/gcc/x86_64-montavista-linux-gnu/4.7.0/../../../../x86_64-montavista-linux-gnu/include/c++/4.7.0/bits/atomic_base.h:438
-1
(nil))
cprop3 does (though there might be cost issues):
(insn 66 30 33 3 (set (mem/v:DI (symbol_ref:DI ("y") [flags 0x2] ) [-1 S8 A64])
(const_int 4294967298 [0x10002]))
/data1/src/gcc-cavium/toolchain/x86_64-tools/bin/../lib/gcc/x86_64-montavista-linux-gnu/4.7.0/../../../../x86_64-montavista-linux-gnu/include/c++/4.7.0/bits/atomic_base.h:438
62 {*movdi_internal_rex64}
(nil))
(insn 33 66 35 3 (set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0 A8])
] UNSPEC_MFENCE))
/data1/src/gcc-cavium/toolchain/x86_64-tools/bin/../lib/gcc/x86_64-montavista-linux-gnu/4.7.0/../../../../x86_64-montavista-linux-gnu/include/c++/4.7.0/bits/atomic_base.h:438
2052 {mfence_sse2}
(nil))
peephole2 then comes around and does the splitting of the atomic instruction so
this is a target issue.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #3 from Thomas Koenig 2013-01-14
23:03:04 UTC ---
A reduced test case which shows the problem in the dump:
! { dg-do run }
! { dg-options "-fcoarray=single" }
!
! PR fortran/50981
! PR fortran/54618
!
program main
implicit none
type t
integer, allocatable :: i
end type t
type, extends (t):: t2
integer, allocatable :: j
end type t2
call a3a()
contains
subroutine a3a(z, z2, z3)
type(t2), optional :: z(4)
type(t2), optional, pointer :: z2(:)
type(t2), optional, allocatable :: z3(:)
type(t2), allocatable :: x(:)
type(t2), pointer :: y(:)
y => null()
call a4t2(y)
end subroutine a3a
subroutine a4t2(x)
type(t2), intent(in), optional :: x(4)
if (present (x)) call abort ()
!print *, present(x)
end subroutine a4t2
end program
ig25@linux-fd1f:~/Krempel/Os> gfortran -fcoarray=single -fdump-tree-original
c.f90
ig25@linux-fd1f:~/Krempel/Os> cat c.f90.003t.original
a4t2 (struct t2[4] * restrict x)
{
if (x != 0B)
{
_gfortran_abort ();
}
L.1:;
}
a3a (struct t2[4] * restrict z, struct array1_t2 * z2, struct array1_t2 * z3)
{
struct array1_t2 y;
y.data = 0B;
y.data = 0B;
{
void * D.1914;
D.1914 = _gfortran_internal_pack (&y);
a4t2 (D.1914);
if ((struct t2[0:] *) y.data != (struct t2[0:] *) D.1914)
{
{
void * D.1915;
D.1915 = D.1914;
if (D.1915 != 0B)
{
__builtin_free (D.1915);
}
}
}
}
}
_gfortran_internal_pack is called without setting up the array descriptor.
[Bug other/55982] __strncat_chk is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55982 Paul Pluzhnikov changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Paul Pluzhnikov 2013-01-14 23:01:09 UTC --- ... testing a patch.
[Bug other/55982] New: __strncat_chk is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55982
Bug #: 55982
Summary: __strncat_chk is buggy
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Oh, the irony.
__strncat_chk is buggy, and has been apparently since initial commit:
r101531 | jakub | 2005-07-02 01:52:21 -0700 (Sat, 02 Jul 2005) | 36 lines
#include
int main()
{
char buf[16];
buf[0] = '\0';
strncat(buf, "0123456789abcdefg", sizeof(buf) - 1);
return 0;
}
gcc -g -D_FORTIFY_SOURCE=2 strncat.c -O2 && ./a.out && echo ok
ok # using libc __strncat_chk
gcc -g -D_FORTIFY_SOURCE=2 strncat.c -O2 -lssp && ./a.out && echo ok
*** buffer overflow detected ***: a.out terminated
Illegal instruction (core dumped)
As far as I can tell, the loop on lines 64-96 is supposed to copy 4 bytes at a
time:
http://gcc.gnu.org/viewcvs/trunk/libssp/strncat-chk.c?annotate=184997
but actually copies 5.
Cut/paste error?
Google ref b/8003094
[Bug other/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #2 from Evgeniy Stepanov 2013-01-14 22:48:08 UTC --- Btw, the same happens if atomic is replaced with "volatile unsigned long y" - which does not violate the standard, but may be considered undesirable by some. I don't have a strong opinion about this.
[Bug other/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #1 from Evgeniy Stepanov 2013-01-14 22:45:30 UTC --- Disassembly of the loop in ff() function: 4007c0: movl $0x2,0x2008de(%rip)# 6010a8 4007ca: movl $0x1,0x2008d8(%rip)# 6010ac 4007d4: sub$0x1,%eax 4007d7: mfence 4007da: movl $0x4,0x2008c4(%rip)# 6010a8 4007e4: movl $0x3,0x2008be(%rip)# 6010ac 4007ee: mfence 4007f1: jne4007c0 <_Z2ffv+0xb0> Does not look atomic. Has all the proper fences, though.
[Bug other/55981] New: std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 Bug #: 55981 Summary: std::atomic store is split in two smaller stores Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: eugeni.stepa...@gmail.com Created attachment 29166 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29166 miscompiled program Hi, in the attached program, std::atomic store is compiled as two 4-byte stores, becoming not atomic at all. This happens at -O2 and higher. To reproduce, # g++ -std=c++11 -O3 1.cc -lpthread -o 1 # ./1 10004 ^ this can also be 30002, both outcomes are invalid.
[Bug middle-end/17886] variable rotate and unsigned long long rotate should be better optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886 --- Comment #26 from Andi Kleen 2013-01-14 22:37:34 UTC --- Sorry commented on the wrong bug. ignore.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #9 from Dominique d'Humieres 2013-01-14 22:35:20 UTC --- Additional comment from #gfortran: AFAIU this kind of changes, they cannot cause a problem for anything that did not triggered the ICE. So they are basically harmless, excepted that they can trun an ICE into a wrong code, which is worse (IMO). Too bad I cannot remember the origin of the code.
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #9 from Andi Kleen 2013-01-14 22:34:16 UTC --- Also i need to look more closely, but most likely the C++ atomic code should be changed to avoid this situation. This would give much better code on x86 in any case even without elision.
[Bug middle-end/17886] variable rotate and unsigned long long rotate should be better optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886 --- Comment #25 from Andi Kleen 2013-01-14 22:32:59 UTC --- Also i need to look more closely, but most likely the C++ atomic code should be changed to avoid this situation. This would give much better code on x86 in any case even without elision.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2013-01-14 22:32:35 UTC --- This is caused by revision 195125, see http://gcc.gnu.org/ml/gcc-regression/2013-01/msg00119.html Note that there is no regression on darwin, but I see the valgrind errors.
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #8 from Andi Kleen 2013-01-14 22:32:06 UTC --- forbid = give warning and drop bit It's a hint, but in a good implementation it should not be silently dropped or code generated that has no chance to elide. It's a quality of implementation issue. IMHO there should be at least a warning for this case, like we do for other cases where elision doesn't work.
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #3 from Thomas Koenig 2013-01-14 22:29:37 UTC --- Now for something harder (which is Michael Metcalf's original idiom): if (any([a(1),a(2)]>acc) then... This can be done by converting [a1, a2, ...] binop scalar to [a1 binop scalar, a2 binop scalar, ...] in general, followed by what has been committed already.
[Bug libstdc++/55963] std::vector fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-14 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Jonathan Wakely 2013-01-14 22:28:26 UTC --- I'll add the assertions for 4.8.1
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #7 from Mikael Morin 2013-01-14
22:23:20 UTC ---
Untested patch:
diff --git a/array.c b/array.c
index 6787c05..54fe337 100644
--- a/array.c
+++ b/array.c
@@ -1074,7 +1074,10 @@ gfc_match_array_constructor (gfc_expr **result)
/* Try to match an optional "type-spec ::" */
gfc_clear_ts (&ts);
- if (gfc_match_decl_type_spec (&ts, 0) == MATCH_YES)
+ m = gfc_match_decl_type_spec (&ts, 0);
+ if (m != MATCH_YES)
+goto cleanup;
+ else
{
seen_ts = (gfc_match (" ::") == MATCH_YES);
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #7 from Andrew Macleod 2013-01-14 22:22:58 UTC --- What do you mean 'forbid' it? Isn't the HLE bit suppose to be a hint anyway? Saying if the hardware supports it, use it on this atomic instruction... Its not incorrect to ignore it, and some targets simply don't support it. so its ignored. I would expect that when we have to drop back to a compare-exchange loop we're no longer going to really care?
[Bug libstdc++/55977] [C++11] vector range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977
--- Comment #1 from Daniel Krügler
2013-01-14 22:18:08 UTC ---
I just notice that the implementation of construct should be changed to
template
void construct(U* p, Args&&... args)
{
::new (static_cast(p)) U(std::forward(args)...);
}
instead. The slight difference (Replace T by U) doesn't matter in this example,
but for correctness reasons should be applied.
[Bug libstdc++/55979] [C++11] std::list range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55979 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1
[Bug libstdc++/55977] [C++11] vector range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #6 from H.J. Lu 2013-01-14 22:11:16 UTC --- Created attachment 29165 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29165 A prototype If as, ld and ld.so provide size info via "symbol@size", we can do .LASAN0: # __beg: .quadcommon_data # __size: .quadcommon_data@size # __size_with_redzone: .quadcommon_data@size + 40 # __name: .quad.LC0 # __has_dynamic_init: .quad0 [hjl@gnu-6 pr55739]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c -o m.o m.c /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c -o c.o c.c /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c size.S /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -o x m.o c.o size.o ./x 10: 0 29: 1 = ==1454== ERROR: AddressSanitizer: global-buffer-overflow on address 0x02e70a18 at pc 0x401dc5 bp 0x7fffde90 sp 0x7fffde70 WRITE of size 4 at 0x02e70a18 thread T0 #0 0x401dc4 (/export/home/hjl/bugs/gcc/pr55739/x+0x401dc4) 0x02e70a18 is located 0 bytes to the right of global variable 'c (d.c)' (0x2e709a0) of size 120 'c (d.c)' is ascii string '' Shadow bytes around the buggy address: 0x105ce0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x105ce140: 00 00 00[f9]f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x105ce150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe Stats: 0M malloced (0M for red zones) by 0 calls Stats: 0M realloced by 0 calls Stats: 0M freed by 0 calls Stats: 0M really freed by 0 calls Stats: 0M (0M-0M) mmaped; 0 maps, 0 unmaps mmaps by size class: mallocs by size class: frees by size class: rfrees by size class: Stats: malloc large: 0 small slow: 0 Stats: StackDepot: 0 ids; 0M mapped ==1454== ABORTING make: *** [all] Error 1 [hjl@gnu-6 pr55739]$ readelf -s c.o | grep common_data 17: 0020 120 OBJECT GLOBAL DEFAULT COM common_data [hjl@gnu-6 pr55739]$
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #6 from Andi Kleen 2013-01-14 22:05:38 UTC --- Hmm that's true. x86 doesn't have xand, x_or, x_xor, only xadd Maybe cmpxchg is the only way? For some special cases it can be done (like and single bit-> btr, or single bit -> btr), but it's probably complicated to implement. In this case I would prefer to forbid those for HLE. I guess more arguments for the target hook. Other ideas?
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 --- Comment #13 from Jack Howarth 2013-01-14 21:58:40 UTC --- (In reply to comment #12) > FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5 > with XCode 4.1 installed. > > Configured via: > ../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \ > --program-suffix=-4.7 --enable-checking=release > > This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I > believe during the glibc build). > > First setting: > > export CC="gcc-4.4" > export CXX="g++-4.4" > > fails with the error described in this bug report, while including > -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap. Make sure you have run 'make check' on the gmp build you installed. The earlier gmp 5.0.x releases had issues with the change to the llvm-gcc compiler in Xcode 4.1. FYI, since you are on Lion, you can upgrade to Xcode 4.5.2 which provides a very stable clang compiler as the system cc/cxx compiler.
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #5 from Uros Bizjak 2013-01-14 21:53:16 UTC --- (In reply to comment #4) > I tried building several compilers (4.7.2), none of which understand the > '-mfxsr' option. One was configured with: True. -mfxsr option was added to 4.8.0. After that, I build the mingw-w64 library, went back to my GCC build dir, and did: make && make install This command should first build a 4.8.0 crosscompiler, and then compile the library with the newly built compiler. The command should look like: /home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../gcc-svn/trunk/libgcc -I../../../gcc-svn/trunk/libgcc/. -I../../../gcc-svn/trunk/libgcc/../gcc -I../../../gcc-svn/trunk/libgcc/../include -I../../../gcc-svn/trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o crtfastmath.o -MT crtfastmath.o -MD -MP -MF crtfastmath.dep -mfxsr -msse -c ../../../gcc-svn/trunk/libgcc/config/i386/crtfastmath.c As you can see, using -mfxsr does not fail here.
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #2 from Thomas Koenig 2013-01-14 21:50:35 UTC --- Author: tkoenig Date: Mon Jan 14 21:50:28 2013 New Revision: 195179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195179 Log: 2013-01-14 Thomas Koenig PR fortran/55806 * frontend-passes.c (optimize_reduction): New function, including prototype. (callback_reduction): Likewise. (gfc_run_passes): Also run optimize_reduction. (copy_walk_reduction_arg): New function. (dummy_code_callback): New function. 2013-01-14 Thomas Koenig PR fortran/55806 * gfortran.dg/array_constructor_40.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_40.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with "-O2 -fcheck=bounds"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 H.J. Lu changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from H.J. Lu 2013-01-14 21:46:17 UTC --- It is caused by revision 176918: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01186.html
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from janus at gcc dot gnu.org 2013-01-14 21:45:17 UTC --- The wrong-code regression has been fixed on all branches (4.6, 4.7 and trunk). For all remaining problems (missed optimizations etc), I have opened PR 55980. Closing this one as fixed.
[Bug fortran/55980] New: missed optimizations with internal_pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55980
Bug #: 55980
Summary: missed optimizations with internal_pack
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
This is a tracking bug for possible remaining problems of PR 55072:
---
1) In PR 55072 comment 13, Mikael writes about this patchlet:
> Index: gcc/fortran/trans-array.c
> ===
> --- gcc/fortran/trans-array.c(revision 194517)
> +++ gcc/fortran/trans-array.c(working copy)
> @@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
> this_array_result = false;
>
>/* Passing address of the array if it is not pointer or assumed-shape. */
> - if (full_array_var && g77 && !this_array_result)
> + if (full_array_var && g77 && !this_array_result
> + && sym->ts.type != BT_DERIVED && sym->ts.type != BT_CLASS)
> {
>tmp = gfc_get_symbol_decl (sym);
It feels like a hack (that what there before) to blindly disable derived types
here. The real problem is that the code under the if condition supports only
bare variables without subreferences.
On the other hand it looks like a correct hack WRT the existing behaviour.
---
2) In http://gcc.gnu.org/ml/fortran/2012-12/msg00098.html, Tobias writes:
"Without experimenting more carefully, I have the gut feeling that there are
still cases where we might end up with invalid code and there is missed
optimization." [For more details see his full post.]
---
3) In http://gcc.gnu.org/ml/fortran/2013-01/msg00091.html, Mikael writes:
For:
>>> @@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
>>> this_array_result = false;
>>> /* Passing address of the array if it is not pointer or
>>> assumed-shape. */
>>> - if (full_array_var&& g77&& !this_array_result)
>>> + if (full_array_var&& g77&& !this_array_result
>>> +&& sym->ts.type != BT_DERIVED&& sym->ts.type != BT_CLASS)
I would have used instead:
&& expr->expr_type == EXPR_VARIABLE && ref == NULL)
to make the optimization available to variables of derived type.
[Bug target/55777] Inlining nomips16 function into mips16 function can result in undefined builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777 --- Comment #1 from Steve Ellcey 2013-01-14 21:34:09 UTC --- gcc.target/mips/mips32-dspr2.c fails for the same reason.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #1 from Thomas Koenig 2013-01-14
21:29:25 UTC ---
For -O0, valgrind complains about
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26355: _gfortran_internal_pack (in_pack_generic.c:54)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
and
==15263==
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26447: _gfortran_internal_pack (in_pack_generic.c:159)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
which is
size = GFC_DESCRIPTOR_SIZE (source);
switch (type_size)
and
dim = GFC_DESCRIPTOR_RANK (source);
respectively.
Reduced test case (run with -fcoarray=single):
! { dg-do run }
! { dg-options "-fcoarray=single" }
!
! PR fortran/50981
! PR fortran/54618
!
implicit none
type t
integer, allocatable :: i
end type t
type, extends (t):: t2
integer, allocatable :: j
end type t2
call a3a()
contains
subroutine a3a(z, z2, z3)
type(t2), optional :: z(4)
type(t2), optional, pointer :: z2(:)
type(t2), optional, allocatable :: z3(:)
type(t2), allocatable :: x(:)
type(t2), pointer :: y(:)
y => null()
call a4t2(y)
end subroutine a3a
subroutine a4t2(x)
type(t2), intent(in), optional :: x(4)
if (present (x)) call abort ()
!print *, present(x)
end subroutine a4t2
end
[Bug other/55925] Unrecognized command line option '-mfxsr' when building x86_64-w64-mingw32 native compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55925 --- Comment #4 from lailavrazda1979 at gmail dot com 2013-01-14 21:26:36 UTC --- I tried building several compilers (4.7.2), none of which understand the '-mfxsr' option. One was configured with: ../gcc-4.7.2/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --prefix=$CROSS_DIR --libexecdir=$CROSS_DIR/lib --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-targets=all --enable-cloog-backend=ppl --disable-shared --disable-nls --disable-werror --with-host-libstdcxx="-lstdc++ -lsupc++" --with-local-prefix=$CROSS_DIR --with-sysroot=$CROSS_DIR --with-ppl=$CROSS_DIR --with-cloog=$CROSS_DIR make all-gcc && make install-gcc After that, I build the mingw-w64 library, went back to my GCC build dir, and did: make && make install
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #5 from Uros Bizjak 2013-01-14 21:25:13
UTC ---
Following testcase will expand to a cmpxchg loop:
int hle_and (int *p, int v)
{
return __atomic_fetch_and_4 (p, v, __ATOMIC_ACQUIRE | __ATOMIC_HLE_ACQUIRE);
}
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #22 from janus at gcc dot gnu.org 2013-01-14 21:24:43 UTC --- Author: janus Date: Mon Jan 14 21:24:36 2013 New Revision: 195178 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195178 Log: 2013-01-14 Janus Weil PR fortran/55072 * trans-array.c (gfc_conv_array_parameter): No packing was done for full arrays of derived type. 2013-01-14 Janus Weil PR fortran/55072 * gfortran.dg/internal_pack_13.f90: New test. * gfortran.dg/internal_pack_14.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/internal_pack_13.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/internal_pack_14.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-array.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #4 from Uros Bizjak 2013-01-14 21:22:35 UTC --- The problem is, that in failed case maybe_emit_op() gets target register to return the result to, so with after=false, it expands via optab->mem_fetch_before. Unfortunately, atomic_fetch_ or atomic__fetch do not exist for x86 target, so generic expander falls back to exchange loop.
[Bug libstdc++/55979] New: [C++11] std::list range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55979
Bug #: 55979
Summary: [C++11] std::list range construction imposes
unnecessary conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code provided by Jonathan compiled with gcc 4.8.0 20130113
(experimental) using the flags
-Wall -std=c++11 -pedantic
is rejected:
//---
#include
struct A
{
A(int) { }
A(const A&) = delete;
A& operator=(const A&) = delete;
};
int main()
{
int i[] = {1, 2};
std::list li(i, i + 2);
}
//---
"[..]gcc\include\c++\4.8.0\bits\stl_list.h||In instantiation of
'std::_List_node<_Tp>::_List_node(_Args&& ...) [with _Args = {A}; _Tp = A]':|
[..]\gcc\include\c++\4.8.0\ext\new_allocator.h|120|required from 'void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
std::_List_node; _Args = {A}; _Tp = std::_List_node]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|506|required from 'std::list<_Tp,
_Alloc>::_Node* std::list<_Tp, _Alloc>::_M_create_node(_Args&& ...) [with _Args
= {A}; _Tp = A; _Alloc = std::allocator; std::list<_Tp, _Alloc>::_Node =
std::_List_node]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1558|required from 'void
std::list<_Tp, _Alloc>::_M_insert(std::list<_Tp, _Alloc>::iterator, _Args&&
...) [with _Args = {A}; _Tp = A; _Alloc = std::allocator; std::list<_Tp,
_Alloc>::iterator = std::_List_iterator]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1022|required from 'void
std::list<_Tp, _Alloc>::push_back(std::list<_Tp, _Alloc>::value_type&&) [with
_Tp = A; _Alloc = std::allocator; std::list<_Tp, _Alloc>::value_type = A]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|1491|required from 'void
std::list<_Tp, _Alloc>::_M_initialize_dispatch(_InputIterator, _InputIterator,
std::__false_type) [with _InputIterator = int*; _Tp = A; _Alloc =
std::allocator]'|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|628|required from 'std::list<_Tp,
_Alloc>::list(_InputIterator, _InputIterator, const allocator_type&) [with
_InputIterator = int*; = void; _Tp = A; _Alloc =
std::allocator; std::list<_Tp, _Alloc>::allocator_type =
std::allocator]'|
main.cpp|13|required from here|
[..]gcc\include\c++\4.8.0\bits\stl_list.h|115|error: use of deleted function
'A::A(const A&)'|
main.cpp|6|error: declared here
"
The error is due to a call of push_back with an previous int->A conversion.
Such an conversion from the iterator's value_type to the containers value_type
is not feasible. The specification of the corresponding constructor is
(indirectly) ruled by Table 100, expression X(i, j):
"Requires: T shall be EmplaceConstructible into X from *i."
Move/CopyConstructible or Convertible to value_type are not required.
Instead of invoking push_back this constructor should internally invoke the
equivalent of emplace_back.
This issue is similar to bug 55977 involving std::vector, but occurs even with
the default allocator and for all iterator categories except input iterator,
therefore this issue is reported separately.
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with "-O2 -fcheck=bounds"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin 2013-01-14 21:01:34 UTC --- Workaround: -fno-tree-vrp
[Bug fortran/55978] New: [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Bug #: 55978 Summary: [4.8 Regression] class_optional_2.f90 -Os fails Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This is for Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread model: posix gcc version 4.8.0 20130113 (experimental) (GCC) FAIL: gfortran.dg/class_optional_2.f90 -Os execution test May be related to PR 55483.
[Bug libstdc++/55977] New: [C++11] vector range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977
Bug #: 55977
Summary: [C++11] vector range construction imposes unnecessary
conversion constraints
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following code compiled with gcc 4.8.0 20130113 (experimental) using the
flags
-Wall -std=c++11 -pedantic
is rejected:
//-
#include
#include
#include
#include
#include
template
struct MyAllocator {
std::allocator base;
typedef T value_type;
MyAllocator() = default;
template
MyAllocator(const MyAllocator& other) : base(other.base) {}
T* allocate(std::size_t n) { return base.allocate(n); }
void deallocate(T* p, std::size_t n) { return base.deallocate(p, n); }
template
void construct(U* p, Args&&... args)
{
::new (static_cast(p)) T(std::forward(args)...);
}
};
struct A {
private:
friend class MyAllocator;
A(int value) : value(value) {}
int value;
public:
A() : value() {}
int get() const { return value; }
};
int main()
{
std::vector> v1;
const int i = 1;
v1.emplace_back(i); // OK
std::vector> v2(std::istream_iterator(std::cin), {});
// Error
}
//-
"[..]gcc\include\c++\4.8.0\bits\stl_vector.h||In instantiation of 'void
std::vector<_Tp, _Alloc>::_M_range_initialize(_InputIterator, _InputIterator,
std::input_iterator_tag) [with _InputIterator = std::istream_iterator; _Tp
= A; _Alloc = MyAllocator]':|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|1178|required from 'void
std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_InputIterator,
_InputIterator, std::__false_type) [with _InputIterator =
std::istream_iterator; _Tp = A; _Alloc = MyAllocator]'|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|396|required from 'std::vector<_Tp,
_Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with
_InputIterator = std::istream_iterator; = void;
_Tp = A; _Alloc = MyAllocator; std::vector<_Tp, _Alloc>::allocator_type =
MyAllocator]'|
main.cpp|38|required from here|
main.cpp|26|error: 'A::A(int)' is private|
[..]gcc\include\c++\4.8.0\bits\stl_vector.h|1188|error: within this context"
The error is due to a call of push_back with an previous int->A conversion.
Such an conversion from the iterator's value_type to the containers value_type
is not feasible. The specification of the corresponding constructor is
(indirectly) ruled by Table 100, expression X(i, j):
"Requires: T shall be EmplaceConstructible into X from *i."
Move/CopyConstructible or Convertible to value_type are not required.
Instead of invoking push_back this constructor should internally invoke the
equivalent of emplace_back.
The same problem also occurs for other standard containers such as std::list.
[Bug other/55973] r195150 doesn't properly handle out of tree isl 0.11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55973 --- Comment #1 from Jack Howarth 2013-01-14 20:49:22 UTC --- The change in r195150 doesn't take in account that the results from each call to ISL_CHECK_VERSION() is cached. So the results from a failed first test of ISL_CHECK_VERSION(0,10) are used when ISL_CHECK_VERSION(0,11) instead of actually compiling the isl version check again for 0.11.x. -g -O2 -I/opt/mp/include -I/opt/mp/include checking for version 0.10 of ISL... no -g -O2 -I/opt/mp/include -I/opt/mp/include checking for version 0.11 of ISL... (cached) no configure: error: Unable to find a usable ISL. See config.log for details.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas changed: What|Removed |Added Status|RESOLVED|REOPENED CC||dominiq at lps dot ens.fr Resolution|FIXED | --- Comment #8 from Paul Thomas 2013-01-14 20:32:04 UTC --- ICE noted by Dominique d'Humieres with module m type :: foobar real, pointer :: array(:) procedure (), pointer, nopass :: f end type contains elemental subroutine fooAssgn (a1, a2) type(foobar), intent(out) :: a1 type(foobar), intent(in) :: a2 allocate (a1%array(size(a2%array))) a1%array = a2%array a1%f => a2%f end subroutine end module m Dominique also provided the fix on #gfortran: in gfc_check_pointer_assign of ../../gcc/fortran/expr.c:3540 replacing if (s2->attr.proc_pointer with if (s2 && s2->attr.proc_pointer lets the code compile. Will commit as 'obvious' as soon as it has bootstrapped and regtested. Paul
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #20 from davidxl 2013-01-14 20:29:54 UTC --- (In reply to comment #19) > That wouldn't work, because you would then have the default (non-mv) version, > possibly mv version with no target attribute, and then some other mv versions > with target attributes. The problem with that is that the first two mangle > the > same. This means that a non-mv and mv with no target attribute needs to be > treated as the same decl (i.e. merged together). that makes sense -- mv annotated decl without target attribute gets merged with default version -- basically it has no actual effect. David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #19 from Jakub Jelinek 2013-01-14 20:23:54 UTC --- That wouldn't work, because you would then have the default (non-mv) version, possibly mv version with no target attribute, and then some other mv versions with target attributes. The problem with that is that the first two mangle the same. This means that a non-mv and mv with no target attribute needs to be treated as the same decl (i.e. merged together).
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #18 from davidxl 2013-01-14 20:17:45 UTC --- All target attributes on decls not tagged with 'mv' attribute should be merged into the default definition. Any decl tagged with 'mv' should be treated as a new decl. David
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andi Kleen changed: What|Removed |Added Attachment #29163|0 |1 is obsolete|| --- Comment #3 from Andi Kleen 2013-01-14 20:15:11 UTC --- Created attachment 29164 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29164 preprocessed test case Sorry earlier was the wrong file
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #2 from Andi Kleen 2013-01-14 19:52:03 UTC --- Created attachment 29163 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29163 preprocessed testcase
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Vladimir Makarov 2013-01-14 19:44:36 UTC --- (In reply to comment #2) > Vlad, can you please have a look? Thanks. Ok, I started to work on this.
[Bug c/55976] New: -Werror=return-type should error on returning a value from a void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
Bug #: 55976
Summary: -Werror=return-type should error on returning a value
from a void function
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lu_z...@gentoo.org
Stupid testcase
#include
void t () { return 1; } // does not error
int b () { return; }// does
int main()
{
t(); b();
return 0;
}
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 Matt Fago changed: What|Removed |Added CC||fago at earthlink dot net --- Comment #12 from Matt Fago 2013-01-14 19:35:43 UTC --- FYI, I recently ran into this issue as well building gcc 4.7.2 on MacOS 10.7.5 with XCode 4.1 installed. Configured via: ../gcc-4.7.2/configure --enable-languages=c,c++,fortran --enable-lto \ --program-suffix=-4.7 --enable-checking=release This command will use Apple's gcc 4.2.1. Bootstrap fails due to an ICE (I believe during the glibc build). First setting: export CC="gcc-4.4" export CXX="g++-4.4" fails with the error described in this bug report, while including -D_FORTIFY_SOURCE=0 in the above exports allows gcc to bootstrap.
[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 --- Comment #18 from Steven Bosscher 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 --- Comment #6 from Steven Bosscher 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug inline-asm/55775] [4.8 Regression] ICE when building pari
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55775 --- Comment #3 from Steven Bosscher 2013-01-14 19:35:10 UTC --- Author: steven Date: Mon Jan 14 19:35:03 2013 New Revision: 195173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195173 Log: * ira-build.c (ira_flattening): Comment fix. Port the following LRA changes on trunk back to the LRA branch: 2013-01-10 Vladimir Makarov PR rtl-optimization/pr55672 * lra-eliminations.c (mark_not_elimnable): Permit addition with const to be elimnable. 2012-12-21 Vladimir Makarov PR middle-end/55775 * lra-assigns.c (improve_inheritance): Do nothing after LRA_MAX_INHERITANCE_PASSES pass. * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to LRA_MAX_CONSTRAINT_ITERATION_NUMBER. Move to lra-int.h. (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES. Move to lra-int.h. * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from lra-constraints.c. (LRA_MAX_INHERITANCE_PASSES): Ditto. 2012-12-21 Steve Ellcey PR bootstrap/54128 * ira.c (build_insn_chain): Check only NONDEBUG instructions for register usage. 2012-12-11 Jakub Jelinek PR rtl-optimization/55193 * lra-constraints.c (loc_equivalence_callback): New function. (lra_constraints): Call simplify_replace_fn_rtx instead of loc_equivalence_change_p on DEBUG_INSNs. Modified: branches/lra/gcc/ChangeLog branches/lra/gcc/ira-build.c branches/lra/gcc/ira.c branches/lra/gcc/lra-assigns.c branches/lra/gcc/lra-constraints.c branches/lra/gcc/lra-eliminations.c branches/lra/gcc/lra-int.h
[Bug target/27338] Violation of mips o64 ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27338 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #3 from rsandifo at gcc dot gnu.org 2013-01-14 19:25:36 UTC --- Yeah, trh(In reply to comment #2) > Richard, has the need for any documentation change been removed by the age of > this defect? Perhaps it should just be closed now. Yeah, that would probably be best. I hang my head in shame at how long it's taken me to do nothing.
[Bug sanitizer/55975] New: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 Bug #: 55975 Summary: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org Target: powerpc64-*-* ==4629== AddressSanitizer CHECK failed: ../../../../../libsanitizer/asan/asan_thread.cc:74 "((AddrIsInMem(stack_bottom_))) != (0)" (0x0, 0x0) = ==4629== ERROR: AddressSanitizer: unknown-crash on address 0x3fffdcef88d0 at pc 0x3fffae6bcb1c bp 0x3fffdcef7400 sp 0x3fffdcef7470 WRITE of size 1 at 0x3fffdcef88d0 thread T0 ==4629== AddressSanitizer: while reporting a bug found another one.Ignoring. This only fails with -m64, the -m32 test works.
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #1 from Andi Kleen 2013-01-14
19:06:02 UTC ---
Here's a test case. This requires the libstdc++ HLE patch from
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00673.html
g++ -std=gnu++0x
#include
#define ACQ memory_order_acquire | __memory_order_hle_acquire
#define REL memory_order_release | __memory_order_hle_release
int main()
{
using namespace std;
atomic_ulong au = ATOMIC_VAR_INIT(0);
if (!au.fetch_and(1, ACQ))
au.fetch_and(-1, REL);
unsigned lock = 0;
__atomic_fetch_and(&lock, 1, __ATOMIC_HLE_ACQUIRE|__ATOMIC_ACQUIRE);
return 0;
}
The first fetch_and generates incorrectly:
.L2:
movq%rax, %rcx
movq%rax, %rdx
andl$1, %ecx
lock; cmpxchgq %rcx, -24(%rsp)
jne .L2
The second generates correctly:
lock;
.byte 0xf3
andq$-1, -24(%rsp)
The __atomic_fetch_and generates correctly:
lock;
.byte 0xf2
andl$1, -28(%rsp)
The first fetch_and should generate the same code sequence.
[Bug fortran/55618] [4.6, 4.7, 4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.6 Regression] Failures |[4.6, 4.7, 4.8 Regression] |with ISO_Varying_String |Failures with |test suite |ISO_Varying_String test ||suite --- Comment #10 from Paul Thomas 2013-01-14 18:44:42 UTC --- Fixed on 4.6, 4.7 and 4.8 - thanks for the report. Paul
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #3 from Georg-Johann Lay 2013-01-14 18:33:35 UTC --- Fixed in 4.7.3
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #17 from Jakub Jelinek 2013-01-14 18:32:44 UTC --- Actually, what you'd merge is everything as usually if mv attribute isn't on either of the decls, or if mv attribute is present on either one, and both decls have either the same target attribute, or no target attribute at all. If mv attribute is on newdecl or olddecl, and target attribute is either present on just one of the decls, or on both, but with different argument, it would treat them as decls that mangle differently and won't be merged.
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 --- Comment #2 from Georg-Johann Lay 2013-01-14 18:32:19 UTC --- Author: gjl Date: Mon Jan 14 18:32:05 2013 New Revision: 195170 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195170 Log: Backport from 2013-01-14 trunk r195169. PR target/55974 * config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH etc. to 1 and not to __flash. Use LL suffix for __INT24_MAX__ with -mint8. Use ULL suffix for __UINT24_MAX__ with -mint8. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr-c.c
[Bug target/55974] [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 --- Comment #1 from Georg-Johann Lay 2013-01-14 18:28:37 UTC --- Author: gjl Date: Mon Jan 14 18:28:24 2013 New Revision: 195169 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195169 Log: PR target/55974 * config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH etc. to 1 and not to __flash. Use LL suffix for __INT24_MAX__ with -mint8. Use ULL suffix for __UINT24_MAX__ with -mint8. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #16 from Jakub Jelinek 2013-01-14 18:25:41 UTC --- I guess if for multiversioning you want the two decls to be independent, like overloaded functions with different argument types are, then IMHO the mv attribute alternative and not merging anything at all in that case (neither the decls, nor any of the attributes (not just target attribute) is better.
[Bug target/55974] New: [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55974 Bug #: 55974 Summary: [avr] Wrong suffix for built-in defines __INT24_MAX__ and __UINT24_MAX__ with -mint8 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr Suffixes for these macros are L resp. UL, but with -mint8 they must be LL resp. ULL
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #4 from rguenther at suse dot de 2013-01-14 18:23:21 UTC --- ian at airs dot com wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 > >--- Comment #3 from Ian Lance Taylor 2013-01-14 >17:35:21 UTC --- >Gccgo doesn't work on Darwin anyhow. I don't think the problems are >hard to >fix. I expected to get go excluded then as not supported...
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #15 from Sriraman Tallam 2013-01-14
18:07:28 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > (In reply to comment #10)
> > > > Either use a different name of the attribute (replace target with
> > > > mv_target or
> > > > whatever), or require a new attribute (mv?) to be present for
> > > > multi-versioning
> > > > (mv attribute on any of the decls would enable it, if mv attribute isn't
> > > > present on either of the two decls being merged, then the target
> > > > attribute is
> > > > merged as before 4.8).
> > >
> > >
> > > I like this proposal:
> >
> > I too like just using a different attribute name. I will prepare a patch
> > asap
> > for this.
> >
> > Thanks
> > Sri.
> >
> > >
> > > >require a new attribute (mv?) to be present for multi-versioning
> > > > (mv attribute on any of the decls would enable it, if mv attribute isn't
> > > > present on either of the two decls being merged, then the target
> > > > attribute is
> > > > merged as before 4.8)
> > >
> > >
> > > David
>
>
> I mean Jacub's second alternative -- adding additional attribute that alters
> the meaning of 'target' attribute -- when it is present, no merging will be
> done.
Ok, so the two options are :
1) int foo __attribute__ ((mv_target ("sse4.2")));
2) int foo __attribute__ ((target("sse4.2")), mv);
I dont have a strong preference.
>
>
> David
[Bug fortran/55618] [4.6 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 --- Comment #9 from Paul Thomas 2013-01-14 17:59:13 UTC --- Author: pault Date: Mon Jan 14 17:59:07 2013 New Revision: 195159 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195159 Log: 2013-01-14 Paul Thomas PR fortran/55618 * trans-expr.c (gfc_conv_procedure_call): Dereference scalar character function arguments to elemental procedures in scalarization loops. 2013-01-14 Paul Thomas PR fortran/55618 * gfortran.dg/elemental_scalar_args_2.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/elemental_scalar_args_2.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #14 from davidxl 2013-01-14 17:49:59 UTC --- (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > Either use a different name of the attribute (replace target with > > > mv_target or > > > whatever), or require a new attribute (mv?) to be present for > > > multi-versioning > > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > > present on either of the two decls being merged, then the target > > > attribute is > > > merged as before 4.8). > > > > > > I like this proposal: > > I too like just using a different attribute name. I will prepare a patch asap > for this. > > Thanks > Sri. > > > > > >require a new attribute (mv?) to be present for multi-versioning > > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > > present on either of the two decls being merged, then the target > > > attribute is > > > merged as before 4.8) > > > > > > David I mean Jacub's second alternative -- adding additional attribute that alters the meaning of 'target' attribute -- when it is present, no merging will be done. David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #13 from Sriraman Tallam 2013-01-14 17:45:42 UTC --- (In reply to comment #12) > (In reply to comment #10) > > Either use a different name of the attribute (replace target with mv_target > > or > > whatever), or require a new attribute (mv?) to be present for > > multi-versioning > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > present on either of the two decls being merged, then the target attribute > > is > > merged as before 4.8). > > > I like this proposal: I too like just using a different attribute name. I will prepare a patch asap for this. Thanks Sri. > > >require a new attribute (mv?) to be present for multi-versioning > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > present on either of the two decls being merged, then the target attribute > > is > > merged as before 4.8) > > > David
[Bug other/55973] New: r195150 doesn't properly handle out of tree isl 0.11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55973 Bug #: 55973 Summary: r195150 doesn't properly handle out of tree isl 0.11.1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The commit... Author: rguenth Date: Mon Jan 14 15:01:13 2013 New Revision: 195150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195150 Log: 2013-01-14 Richard Biener * configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG 0.18.0. * configure: Re-generate doesn't handle out of tree installations of isl 0.11.1 as config/isl.m4 needs to be taught how to handle revision numbers in the complete version number. The proposed patch in... http://gcc.gnu.org/ml/gcc/2012-12/msg00195.html does this. The current commit also has a stray instance of... ISL_CHECK_VERSION(0,10) in configure.ac and doesn't recognize that the current checks are still hard-coded to a specific version. So either isl 0.11 or 0.11.1 was be designated in configure.ac.
[Bug go/55969] libgo fails to build on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55969 --- Comment #3 from Ian Lance Taylor 2013-01-14 17:35:21 UTC --- Gccgo doesn't work on Darwin anyhow. I don't think the problems are hard to fix.
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970 --- Comment #4 from Andrew Pinski 2013-01-14 17:34:28 UTC --- (In reply to comment #3) Maybe we should warn about these cases just like we warn for the other unspecified behavior which causes undefined behavior (aka a+=a+1).
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||tromey at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek 2013-01-14
17:33:02 UTC ---
This is about:
if (pfile->state.in_directive
|| pfile->state.parsing_args
|| pfile->state.in_deferred_pragma)
{
cur--;
type = CPP_OTHER;
cpp_error_with_line (pfile, CPP_DL_ERROR, token->src_loc, 0,
"unterminated raw string");
break;
}
in lex_raw_string, in this case state.in_directive is true, as it is in #define
directive. But just removing state.in_directive from that condition isn't
enough,
1537 _cpp_process_line_notes (pfile, false);
1538 if (!_cpp_get_fresh_line (pfile))
doesn't handle this case correctly.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #12 from davidxl 2013-01-14 17:20:56 UTC --- (In reply to comment #10) > Either use a different name of the attribute (replace target with mv_target or > whatever), or require a new attribute (mv?) to be present for multi-versioning > (mv attribute on any of the decls would enable it, if mv attribute isn't > present on either of the two decls being merged, then the target attribute is > merged as before 4.8). I like this proposal: >require a new attribute (mv?) to be present for multi-versioning > (mv attribute on any of the decls would enable it, if mv attribute isn't > present on either of the two decls being merged, then the target attribute is > merged as before 4.8) David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #11 from davidxl 2013-01-14 17:17:21 UTC --- (In reply to comment #9) > I'd say once a target attribute appears at a declaration (non-definition) MV > needs to be disabled. Or, the declarations target attribute and those at > the MV definitions need to be merged. > > Thus, a declarations target attribute applies to all definitions (thus all > MV variants). This might reduce the usefulness of MV -- using declarations with attributes to indicate MV candidates is the intended use model. David
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #8 from Jakub Jelinek 2013-01-14 16:45:11 UTC --- Can't we then compute the final values of the bases after the peeling loop, and add those gimplified after the peeling loop, then use them in the next loop?
[Bug target/55948] __atomic_clear / __atomic_store_n ignore HLE_RELEASE flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948 --- Comment #1 from uros at gcc dot gnu.org 2013-01-14 16:45:04 UTC --- Author: uros Date: Mon Jan 14 16:44:55 2013 New Revision: 195155 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195155 Log: PR target/55948 * config/i386/sync.md (atomic_store_1): New pattern. (atomic_store): Call atomic_store_1 for IX86_HLE_RELEASE memmodel flag. testsuite/ChangeLog PR target/55948 * gcc.target/i386/hle-clear-rel.c: New file * gcc.target/i386/hle-store-rel.c: New file. Added: trunk/gcc/testsuite/gcc.target/i386/hle-clear-rel.c trunk/gcc/testsuite/gcc.target/i386/hle-store-rel.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sync.md trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 --- Comment #5 from Jonathan Wakely 2013-01-14 16:43:55 UTC --- Thanks, Jakub, for some reason I thought it had ben done in the FE. Let's confirm this then, it's not an exact dup.
[Bug c++/55972] cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0
[Bug c++/55720] [C++11] Linkage errors of static data member initializers with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55720 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 Ever Confirmed|0 |1
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2013-01-14 16:35:52 UTC --- That's not the case, because most of the raw string support is in the preprocessor.
[Bug c++/55972] New: cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972
Bug #: 55972
Summary: cannot access private member from lambda used in NSDMI
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
The following short translation unit shows the issue:
class C
{
void f();
int j = 10;
int i = [this]() { return this->j; }();
};
$ g++ -std=c++11 x.cc
x.cc: In lambda function:
x.cc:4:11: error: ‘int C::j’ is private
x.cc:5:39: error: within this context
Non-static data member initializers (and lambdas used therein) should be able
to access private members of their class.
[Bug bootstrap/55961] [4.8 Regression] system.h includes gmp.h but system.h is included for build and not just target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55961 --- Comment #3 from joseph at codesourcery dot com 2013-01-14 16:05:48 UTC --- We run configure for the build system in a subdirectory, when build != host. # auto-host.h is the file containing items generated by autoconf and is # the first file included by config.h. # If host=build, it is correct to have bconfig include auto-host.h # as well. If host!=build, we are in error and need to do more # work to find out the build config parameters. if test x$host = x$build then build_auto=auto-host.h else # We create a subdir, then run autoconf in the subdir. # To prevent recursion we set host and build for the new # invocation of configure to the build for this invocation # of configure. [...]
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek 2013-01-14 16:01:36 UTC --- Because it behaves differently. ./xgcc -B ./ -fwrapv -ftrapv -fno-trapv -fverbose-asm -S -xc /dev/null -o - 2>&1 | grep rapv # -march=x86-64 -auxbase-strip - -fno-trapv -fverbose-asm with Negative(fwrapv) resp. Negative(ftrapv) added instead of this patch, while with that patch it was -fwrapv.
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 --- Comment #3 from Jonathan Wakely 2013-01-14 15:56:02 UTC --- I think basically the preprocessor doesn't support raw strings. Fix that and both bugs should go away.
