[Bug tree-optimization/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443
--- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-06-19 08:09:43 UTC
---
Both tests contain misaligned accesses and cannot be vectorized on targets that
have no misalignment support, like ia64. So, I think, the tests should just
fail:
Index: vect-peel-3.c
===
--- vect-peel-3.c (revision 175101)
+++ vect-peel-3.c (working copy)
@@ -47,7 +47,7 @@
return main1 ();
}
-/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } } */
+/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect { xfail
vect_no_align } } } */
/* { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1
vect { xfail vect_no_align } } } */
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 1 vect } } */
+/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 1 vect { xfail vect_no_align } } } */
/* { dg-final { cleanup-tree-dump vect } } */
Index: vect-peel-4.c
===
--- vect-peel-4.c (revision 175101)
+++ vect-peel-4.c (working copy)
@@ -44,7 +44,7 @@
return main1 ();
}
-/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } } */
+/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect { xfail
vect_no_align } } } */
/* { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1
vect { xfail vect_no_align } } } */
/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 0 vect } } */
/* { dg-final { cleanup-tree-dump vect } } */
They worked before r175009, because the tests didn't take into account vectors
of two ints, and all the accesses were aligned unintentionally.
Could you please verify that the above patch fixes the failures?
Thanks,
Ira
[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49442 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-06-19 08:25:05 UTC --- We can try to fix this with the cost model and additional heuristic in vect_enhance_data_refs_alignment. Currently we decide not to do versioning for alignment, because all the accesses are supported anyway. Maybe something like the following condition for versioning could help (when all the alignment values are unknown): if (number_of_loads * cost_of_misaligned_load + number_of_stores * cost_of_misaligned_store + approx_vector_iteration_cost_without_drs approx_scalar_iteration_cost * vectorization_factor) do_versioning = true; Ira
[Bug tree-optimization/49457] integer comparison does not vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49457 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||irar at il dot ibm.com Resolution||DUPLICATE --- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-06-19 10:14:24 UTC --- Conditions with different types of the comparison and the then/else operands are not vectorized. This is a duplicate of pr27460. See also http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00255.html. *** This bug has been marked as a duplicate of bug 27460 ***
[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-06-19 10:14:24 UTC --- *** Bug 49457 has been marked as a duplicate of this bug. ***
[Bug target/48256] gcc4.4.5 internal compiler error: in change_address_1, at emit-rtl.c:1954
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48256 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-06-19 14:02:27 UTC --- Created attachment 24559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24559 preprocessed test case Several files in gsoc2010-fftw-neon ICE gcc-4.4 in change_address_1, this is the preprocessed code for the first one. The ICE doesn't occur with gcc-4.6.0, it was cured by r159480, a generic patch to reduce stack frame sizes. The description http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00441.html didn't mention fixing any bugs, so I don't know if it actually fixed this bug or just made it latent.
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-06-19
16:26:25 UTC ---
Created attachment 24562
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24562
runtime test case
Here's a small runtime test case.
cat pr48863.c
/* pr48863.c */
static inline int dosvc(int fd, unsigned long high, unsigned low)
{
register int r0 asm(r0) = fd;
register int r2 asm(r2) = high;
register int r3 asm(r3) = low;
asm volatile(
: =r(r0)
: 0(r0), r(r2), r(r3));
return r0;
}
struct s {
int fd;
long long length;
} s = { 2, 0 }, *p = s;
int main(void)
{
unsigned low = p-length 0x;
unsigned high = p-length / 23;
if (dosvc(p-fd, high, low) != 2)
__builtin_abort();
return 0;
}
/mnt/scratch/objdir47/gcc/xgcc -B/mnt/scratch/objdir47/gcc/ -O2 pr48863.c ;
./a.out
Abort
/mnt/scratch/objdir47/gcc/xgcc -B/mnt/scratch/objdir47/gcc/ -O2 -S pr48863.c
; cat pr48863.s
...
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
# loads p to r1
ldr r1, .L5
stmfd sp!, {r4, lr}
# loads *p to r1
ldr r1, [r1, #0]
mov r2, #23
mov r3, #0
ldr r4, [r1, #8]
ldr r1, [r1, #12]
mov r0, r4
bl __aeabi_ldivmod
mov r3, r4
mov r2, r0
# here's where the SWI would have been, note how:
# 1. p-fd was never loaded into r0
# 2. r0 was clobbered by the libcall to __aeabi_ldivmod
cmp r0, #2
# so this comparison will fail and we'll abort
...
Works when compiled with -O0.
[Bug fortran/49466] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.19 15:51:25 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-19 15:51:25 UTC --- I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6 (revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 --- Comment #2 from Oleg Endo oleg.e...@t-online.de 2011-06-19 15:48:41 UTC --- Created attachment 24561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24561 Before/After Examples
[Bug target/49263] SH Target: underutilized TST #imm, R0 instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #3 from Oleg Endo oleg.e...@t-online.de 2011-06-19 16:42:01 UTC
---
Thanks for having a look at it Kaz.
Yes, the fiddling with the combine pass is fragile. I've tried out your
peephole idea. It works in most cases but not all the time. E.g. it doesn't
catch the following example:
int test_imm (int i)
{
return (i 3) ? 20 : 40;
}
mov#3,r1
andr1,r4
tstr4,r4
bt/s.L5
mov#40,r0
mov#20,r0
.L5:
rts
nop
Also the following...
int test_imm (int* i)
{
return (*i 255) ? 20 : 40;
}
becomes on little endian (OK):
mov.b@r4,r1
tstr1,r1
bt/s.L10
mov#40,r0
mov#20,r0
.L10:
rts
nop
but on big endian (NG):
mov.l@r4,r1
extu.br1,r1
tstr1,r1
bt/s.L10
mov#40,r0
mov#20,r0
.L10:
rts
nop
I'll give the thing another try.
Regarding the change to the andcosts function, the following should be better:
--- sh.c(revision 175188)
+++ sh.c(working copy)
@@ -243,7 +243,7 @@
static int flow_dependent_p (rtx, rtx);
static void flow_dependent_p_1 (rtx, const_rtx, void *);
static int shiftcosts (rtx);
-static int andcosts (rtx);
+static int and_xor_ior_costs (rtx, int code);
static int addsubcosts (rtx);
static int multcosts (rtx);
static bool unspec_caller_rtx_p (rtx);
@@ -2841,14 +2841,14 @@
return shift_insns[value];
}
-/* Return the cost of an AND operation. */
+/* Return the cost of an AND/XOR/IOR operation. */
static inline int
-andcosts (rtx x)
+and_xor_ior_costs (rtx x, int code)
{
int i;
- /* Anding with a register is a single cycle and instruction. */
+ /* register x register is a single cycle instruction. */
if (!CONST_INT_P (XEXP (x, 1)))
return 1;
@@ -2864,17 +2864,17 @@
}
/* These constants are single cycle extu.[bw] instructions. */
- if (i == 0xff || i == 0x)
+ if ((i == 0xff || i == 0x) code == AND)
return 1;
- /* Constants that can be used in an and immediate instruction in a single
+ /* Constants that can be used in an instruction with an immediate are a
single
cycle, but this requires r0, so make it a little more expensive. */
if (CONST_OK_FOR_K08 (i))
return 2;
- /* Constants that can be loaded with a mov immediate and an and.
+ /* Constants that can be loaded with a mov immediate need one more cycle.
This case is probably unnecessary. */
if (CONST_OK_FOR_I08 (i))
return 2;
- /* Any other constants requires a 2 cycle pc-relative load plus an and.
+ /* Any other constant requires an additional 2 cycle pc-relative load.
This case is probably unnecessary. */
return 3;
}
@@ -3043,7 +3043,9 @@
return true;
case AND:
- *total = COSTS_N_INSNS (andcosts (x));
+case XOR:
+case IOR:
+ *total = COSTS_N_INSNS (and_xor_ior_costs (x, code));
return true;
case MULT:
[Bug fortran/49466] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 15:39:28 UTC --- (In reply to comment #1) (In reply to comment #0) In the attached sample code, which is a reduced test case from the full code, the assignment as_b = as_a leaks memory from the U(:) allocatable component (which is defined in state_t, the parent type), but not from the W(:) allocatable component (which is defined in astate_t). Sorry, I'm not able to reproduce the memory leak with gfortran version 4.5 and valgrind. Could you please tell me which gfortran version you use and how you detect the memory leak? This is 4.7.0 (svn) running on OS X 10.6.7. valgrind output: ==32629== Memcheck, a memory error detector ==32629== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==32629== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==32629== Command: ./evolve_aflow ==32629== --32629-- ./evolve_aflow: --32629-- dSYM directory is missing; consider using --dsymutil=yes ==32629== ==32629== HEAP SUMMARY: ==32629== in use at exit: 4,004,088 bytes in 1,002 blocks ==32629== total heap usage: 2,019 allocs, 1,017 frees, 8,012,001 bytes allocated ==32629== ==32629== 3,996,000 bytes in 999 blocks are definitely lost in loss record 4 of 4 ==32629==at 0x10001079F: malloc (vg_replace_malloc.c:236) ==32629==by 0x10C27: MAIN__ (in ./evolve_aflow) ==32629==by 0x10DA2: main (in ./evolve_aflow) ==32629== ==32629== LEAK SUMMARY: ==32629==definitely lost: 3,996,000 bytes in 999 blocks ==32629==indirectly lost: 0 bytes in 0 blocks ==32629== possibly lost: 0 bytes in 0 blocks ==32629==still reachable: 8,088 bytes in 3 blocks ==32629== suppressed: 0 bytes in 0 blocks ==32629== Reachable blocks (those to which a pointer was found) are not shown. ==32629== To see them, rerun with: --leak-check=full --show-reachable=yes ==32629== ==32629== For counts of detected and suppressed errors, rerun with: -v ==32629== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 --- Comment #1 from Oleg Endo oleg.e...@t-online.de 2011-06-19 15:29:45 UTC --- Created attachment 24560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24560 Proposed patch The patch adds explicit handling of abs:SI and abs:DI to the machine description instead of relying on the default abs handling. On SH4 the zero-offset branch way is definitely faster. It reduces pressure on EX group instructions and improves parallel instruction execution. On other than SH4 zero-offset branches are not as fast, but the resulting code should still be faster than the default branch-free abs code, at least it is more compact. The patch also handles the case of neg (abs (...)) by simply inverting the branch condition. Feedback appreciated.
[Bug fortran/49466] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2011-06-19 15:27:55 UTC --- (In reply to comment #0) In the attached sample code, which is a reduced test case from the full code, the assignment as_b = as_a leaks memory from the U(:) allocatable component (which is defined in state_t, the parent type), but not from the W(:) allocatable component (which is defined in astate_t). Sorry, I'm not able to reproduce the memory leak with gfortran version 4.5 and valgrind. Could you please tell me which gfortran version you use and how you detect the memory leak?
[Bug target/49468] New: SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Summary: SH Target: inefficient integer abs code
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
The generated code for abs:SI and abs:DI is a bit inefficient:
int abs (int i)
{
return (i 0) ? -i : i;
}
movr4,r1
shllr1
subcr1,r1
movr1,r0
xorr4,r0
rts
subr1,r0
long long abs (long long i)
{
return (i 0) ? -i : i;
}
movr4,r3
shllr3
subcr3,r3
movr5,r1
xorr3,r1
movr3,r0
clrt
xorr4,r0
subcr3,r1
rts
subcr3,r0
There is a define_split in sh.md which is supposed to handle the special case
for SH4 but it is not doing anything. The problem has been around since a
couple of GCC 4.x versions.
sh-elf-gcc -v
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --without-headers
--disable-nls --disable-werror --enable-lto --with-newlib --with-gnu-as
--with-gnu-ld --with-system-zlib : (reconfigured) ../gcc-trunk/configure
--target=sh-elf --prefix=/usr/local --enable-languages=c,c++ --enable-multilib
--disable-libssp --without-headers --disable-nls --disable-werror --enable-lto
--with-newlib --with-gnu-as --with-gnu-ld --with-system-zlib : (reconfigured)
../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --without-headers
--disable-nls --disable-werror --enable-lto --with-newlib --with-gnu-as
--with-gnu-ld --with-system-zlib : (reconfigured) ../gcc-trunk/configure
--target=sh-elf --prefix=/usr/local --enable-multilib --disable-libssp
--without-headers --disable-nls --disable-werror --enable-lto --with-newlib
--with-gnu-as --with-gnu-ld --with-system-zlib target_alias=sh-elf CFLAGS=-Os
CXXFLAGS=-Os --enable-languages=c,c++,lto --no-create --no-recursion
Thread model: single
gcc version 4.7.0 20110619 (experimental) (GCC)
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #3 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:39:22 UTC --- Author: mrs Date: Sun Jun 19 17:39:19 2011 New Revision: 175189 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175189 Log: 2011-06-18 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * configure.ac: Use mh-x86-darwin. * configure: Regenerate. * config/mh-x86-darwin: Add file and pass -no_pie on BOOT_LDFLAGS for darwin11. Added: branches/gcc-4_5-branch/config/mh-x86-darwin Modified: branches/gcc-4_5-branch/ChangeLog branches/gcc-4_5-branch/configure branches/gcc-4_5-branch/configure.ac
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.19 17:41:57 CC||mrs at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #4 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:48:15 UTC --- Author: mrs Date: Sun Jun 19 17:48:13 2011 New Revision: 175190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175190 Log: PR target/49461 * mh-darwin: Turn off -pie on darwin11 and later. Modified: branches/gcc-4_6-branch/config/ChangeLog
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #5 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:51:04 UTC --- Author: mrs Date: Sun Jun 19 17:51:02 2011 New Revision: 175191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175191 Log: 2011-06-19 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * configure.ac: Use mh-x86-darwin. * configure: Regenerate. config: 2011-06-19 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * mh-x86-darwin: Add file and pass -no_pie on BOOT_LDFLAGS for darwin11. Modified: branches/gcc-4_5-branch/ChangeLog branches/gcc-4_5-branch/config/ChangeLog
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:51:43 UTC --- Fixed in 4.5.4, 4.6.1 and 4.7.0.
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Memory leak with assignment |[4.6/4.7 Regression] Memory |of extended derived types |leak with assignment of ||extended derived types --- Comment #4 from janus at gcc dot gnu.org 2011-06-19 17:52:35 UTC --- (In reply to comment #3) I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6 (revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456. Ok, I can also reproduce the memory leak with gfortran 4.7 on x86_64-unknown-linux-gnu, which means that it is a regression. Here is a reduced test case: program evolve_aflow implicit none type :: state_t real, allocatable :: U(:) end type state_t type, extends(state_t) :: astate_t end type astate_t type(astate_t) :: a,b allocate(a%U(1000)) b = a b = a end program In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. In fact, the dump does not contain a single __builtin_free, while with 4.5 it has six. valgrind says: ==27163== 4,000 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==27163==at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27163==by 0x4009BC: MAIN__ (test.f90:16) ==27163==by 0x400B9D: main (test.f90:19)
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #7 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:54:26 UTC --- Author: mrs Date: Sun Jun 19 17:54:24 2011 New Revision: 175192 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175192 Log: PR target/49461 * mh-darwin: Turn off -pie on darwin11 and later. Modified: trunk/config/ChangeLog
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED | Target Milestone|--- |4.5.4 --- Comment #8 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 17:58:36 UTC --- The gcc pch problem is fixed in 4.5.4, 4.6.1 and 4.7.0. The libjava problem is fixed in 4.7.0. 4.6.x and 4.5.x are outstanding.
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #9 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 18:07:54 UTC --- Author: mrs Date: Sun Jun 19 18:07:52 2011 New Revision: 175193 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175193 Log: 2011-06-19 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11. * libjava/configure: Regenerate. Modified: branches/gcc-4_6-branch/libjava/ChangeLog branches/gcc-4_6-branch/libjava/configure branches/gcc-4_6-branch/libjava/configure.ac
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.4, 4.6.1, 4.7.0 Resolution||FIXED Known to fail||4.5.3, 4.6.0 --- Comment #10 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-06-19 18:12:01 UTC --- Ok, the libjava problem is fixed in 4.6.1. If you'd like this fixed for gcc-4.5.x, could you confirm it is a problem and that this fix, fixes it.
[Bug other/31400] enable static linking of support libraries through -static-libXY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400 Matt Arsenault arsenm2 at rpi dot edu changed: What|Removed |Added CC||arsenm2 at rpi dot edu --- Comment #20 from Matt Arsenault arsenm2 at rpi dot edu 2011-06-19 18:25:27 UTC --- I would find the -static-libgomp option useful
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-19 18:45:09 UTC --- In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. I don't think it should be freed then allocated for the second assignment in the code in comment#4.
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 18:57:40 UTC --- (In reply to comment #5) In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. I don't think it should be freed then allocated for the second assignment in the code in comment#4. Certainly, given that the lhs array component is the same shape as the rhs array component, an optimization would be not to free and then allocate the array prior to the copy. However, that doesn't alter the fact that the behavior should be *as if* the lhs array component were freed and then allocated with the appropriate shape. This behavior has been in Fortran since TR 15581, which first introduced allocatable derived-type components as an extension to Fortran 95.
[Bug fortran/49417] [4.6 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 --- Comment #5 from janus at gcc dot gnu.org 2011-06-19 21:05:22 UTC --- Author: janus Date: Sun Jun 19 21:05:18 2011 New Revision: 175194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175194 Log: 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * module.c (mio_component_ref): Handle components of extended types. * symbol.c (gfc_find_component): Return if sym is NULL. PR fortran/48699 * check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic, make sure the vtab is present. PR fortran/49074 * interface.c (gfc_extend_assign): Propagate the locus from the assignment to the type-bound procedure call. PR fortran/49417 * module.c (mio_component): Make sure the 'class_ok' attribute is set for use-associated CLASS components. * parse.c (parse_derived): Check for 'class_ok' attribute. * resolve.c (resolve_fl_derived): Ditto. 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * gfortran.dg/extends_13.f03: New. PR fortran/48699 * gfortran.dg/move_alloc_5.f90: New. PR fortran/49074 * gfortran.dg/typebound_assignment_3.f03: New. PR fortran/49417 * gfortran.dg/class_43.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_43.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_13.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_5.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/check.c branches/gcc-4_6-branch/gcc/fortran/interface.c branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/fortran/symbol.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #19 from janus at gcc dot gnu.org 2011-06-19 21:05:22 UTC --- Author: janus Date: Sun Jun 19 21:05:18 2011 New Revision: 175194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175194 Log: 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * module.c (mio_component_ref): Handle components of extended types. * symbol.c (gfc_find_component): Return if sym is NULL. PR fortran/48699 * check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic, make sure the vtab is present. PR fortran/49074 * interface.c (gfc_extend_assign): Propagate the locus from the assignment to the type-bound procedure call. PR fortran/49417 * module.c (mio_component): Make sure the 'class_ok' attribute is set for use-associated CLASS components. * parse.c (parse_derived): Check for 'class_ok' attribute. * resolve.c (resolve_fl_derived): Ditto. 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * gfortran.dg/extends_13.f03: New. PR fortran/48699 * gfortran.dg/move_alloc_5.f90: New. PR fortran/49074 * gfortran.dg/typebound_assignment_3.f03: New. PR fortran/49417 * gfortran.dg/class_43.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_43.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_13.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_5.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/check.c branches/gcc-4_6-branch/gcc/fortran/interface.c branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/fortran/symbol.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #32 from janus at gcc dot gnu.org 2011-06-19 21:05:22 UTC --- Author: janus Date: Sun Jun 19 21:05:18 2011 New Revision: 175194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175194 Log: 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * module.c (mio_component_ref): Handle components of extended types. * symbol.c (gfc_find_component): Return if sym is NULL. PR fortran/48699 * check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic, make sure the vtab is present. PR fortran/49074 * interface.c (gfc_extend_assign): Propagate the locus from the assignment to the type-bound procedure call. PR fortran/49417 * module.c (mio_component): Make sure the 'class_ok' attribute is set for use-associated CLASS components. * parse.c (parse_derived): Check for 'class_ok' attribute. * resolve.c (resolve_fl_derived): Ditto. 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * gfortran.dg/extends_13.f03: New. PR fortran/48699 * gfortran.dg/move_alloc_5.f90: New. PR fortran/49074 * gfortran.dg/typebound_assignment_3.f03: New. PR fortran/49417 * gfortran.dg/class_43.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_43.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_13.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_5.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/check.c branches/gcc-4_6-branch/gcc/fortran/interface.c branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/fortran/symbol.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49074 --- Comment #6 from janus at gcc dot gnu.org 2011-06-19 21:05:22 UTC --- Author: janus Date: Sun Jun 19 21:05:18 2011 New Revision: 175194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175194 Log: 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * module.c (mio_component_ref): Handle components of extended types. * symbol.c (gfc_find_component): Return if sym is NULL. PR fortran/48699 * check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic, make sure the vtab is present. PR fortran/49074 * interface.c (gfc_extend_assign): Propagate the locus from the assignment to the type-bound procedure call. PR fortran/49417 * module.c (mio_component): Make sure the 'class_ok' attribute is set for use-associated CLASS components. * parse.c (parse_derived): Check for 'class_ok' attribute. * resolve.c (resolve_fl_derived): Ditto. 2011-06-19 Janus Weil ja...@gcc.gnu.org PR fortran/47601 * gfortran.dg/extends_13.f03: New. PR fortran/48699 * gfortran.dg/move_alloc_5.f90: New. PR fortran/49074 * gfortran.dg/typebound_assignment_3.f03: New. PR fortran/49417 * gfortran.dg/class_43.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_43.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_13.f03 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_5.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/check.c branches/gcc-4_6-branch/gcc/fortran/interface.c branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/fortran/symbol.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #33 from janus at gcc dot gnu.org 2011-06-19 21:16:06 UTC --- Ok, the backport has landed on the 4.6 branch and should be just in time for the 4.6.1 release.
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #34 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 21:18:47 UTC --- Thanks, Janus -- you rock! On Jun 19, 2011, at 4:16 PM, janus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #33 from janus at gcc dot gnu.org 2011-06-19 21:16:06 UTC --- Ok, the backport has landed on the 4.6 branch and should be just in time for the 4.6.1 release. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #20 from janus at gcc dot gnu.org 2011-06-19 21:20:14 UTC --- The regression has been fixed on trunk and 4.6. The remaining issue will be tracked by PR 48887. Closing.
[Bug fortran/49417] [4.6 Regression] [OOP] ICE on invalid CLASS component declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49417 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-06-19 21:21:24 UTC --- Fixed on trunk and 4.6. Closing.
[Bug bootstrap/49469] New: GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49469 Summary: GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: manp...@gmail.com When building trunk on Mac OS X 10.6.7, it fails when building the embedded zlib, which creates an i386 directory in the building directory (which was different from source directory) during stage2, and still reference ./prev-gcc from there, which would work if it were ../prev-gcc. The i386 seems to be created as multidirs was set to i386 for zlib. The configure switch was: $ $HOME/VCS/GIT/gcc/configure --prefix=/usr/local --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --enable-cloog-backend=isl --program-suffix=-4.7 --enable-languages=c,c++ --disable-nls --disable-werror --enable-__cxa_init --enable-concept-checks --enable-decimal-float --enable-full-dynamic-string --enable-libstdcxx-debug --enable-libstdcxx-time --enable-multilib --enable-plugin --enable-shared --enable-threads --enable-version-specific-runtime-libs And the build log is attached.
[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49074 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from janus at gcc dot gnu.org 2011-06-19 21:31:25 UTC --- Since the fix is that simple, I decided to backport it. Also, hoping that class arrays will get implemented soon (in 4.7?), the 4.6 branch may be the only place where this patch is really effective. Anyway, Closing.
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra amodra at gmail dot com 2011-06-19 23:18:08 UTC --- Honza, the code here is called during expansion of functions. If called at the start of a function body, the function is attempting to answer the question: Can this function be called from anywhere external to this object file? If called for the expansion of a call then the question is: Can this function call go to a function external to this object file? Then, once those questions are answered, further code checks whether function arguments and return value might be affected by the ABI in force. We aren't at all interested in local functions, so I don't think c_node-local and c_node-can_change_signature are relevant. At least, I don't see that they give any more information than cgraph_only_called_directly_p relevant to the questions call_ABI_of_interest is trying to answer.
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-20 01:02:33 UTC --- We've verified that one-line fix allows the bootstrap to complete successfully.
[Bug c++/37089] [C++0x] rvalue/lvalue reference collapsing not performed in error ouput thus printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37089 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/49205] [C++0x] Default constructor with pack expansion parameter not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 01:53:05 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/48138] __attribute__((aligned)) should give an error when applied to a typedef or template parameter, at least in C++0x mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48138 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 02:20:52 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/47635] [C++0x] ICE on invalid code in constructor_name_p, at cp/name-lookup.c:1809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47635 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 02:26:34 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #35 from Kris kristopher.kuhlman at gmail dot com 2011-06-20 02:31:45 UTC --- (In reply to comment #34) Thanks, Janus -- you rock! I concur. Thanks!
[Bug c++/49470] New: no matching constructor for initialization errors not detected in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49470
Summary: no matching constructor for initialization errors not
detected in g++
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
Currently g++ doesn't warn or error on invalid code such as...
template class T class Array1D {
Array1D(int n, T *a);
};
templatetypename T
struct A {
Array1Dint x;
A() : x(1, (const int*)0) {}
};
for which clang++ produces the error...
[MacPro:~] howarth% clang++ -c invalid.cc
invalid.cc:7:9: error: no matching constructor for initialization of
'Array1Dint'
A() : x(1, (const int*)0) {}
^
invalid.cc:2:3: note: candidate constructor not viable: 2nd argument ('const
int *') would lose const qualifier
Array1D(int n, T *a);
^
invalid.cc:1:26: note: candidate constructor (the implicit copy constructor)
not viable: requires 1 argument, but 2 were provided
template class T class Array1D {
^
1 error generated.
[Bug c++/49470] no matching constructor for initialization errors not detected in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49470 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-06-20 03:12:23 UTC --- This test case originates from http://llvm.org/bugs/show_bug.cgi?id=9627.
[Bug c++/47080] [C++0x] explicit conversion function return conversions not restricted to qualifications
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 04:10:18 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.20 04:52:44 Ever Confirmed|0 |1
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #33 from Anitha Boyapati anitha.boyapati at atmel dot com 2011-06-20 05:00:47 UTC --- (In reply to comment #32) Fixed with: 2011-06-17 Richard Henderson r...@redhat.com Backport from mainline 2011-03-22 Richard Henderson r...@redhat.com * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec. Great! Build succeeds now. I am yet to test it. Thanks Richard. Anitha
