[Bug target/44606] Wrong SPE floating point during computation
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-09-09 15:28 --- The problem is in the register allocator. What happens is that after register allocation, we have something like: r27:DF = [r11:SI] ... r27:SI = 0 ... and then the first def gets deleted because it's obviously dead code. I don't know why the register allocator chooses r27 for the SImode pseudo. Scheduling is necessary to trigger the bug, but it's not the problem. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug bootstrap/45518] New: [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
I'm seeing a bootstrap failure on the compile farm's gcc63 machine. I realize
there've been several logs submitted to gcc-testresults from Laurent's
autotesters, but those testers configured with somewhat different options than
I did. I'm configuring with:
--disable-lib{ssp,mudflap,gomp} --enable-languages=c --disable-nls
--enable-threads=posix
whereas Laurent passes --with-cpu=v8 and --disable-multilib.
Bootstrapping fails starting at r163383, Bernd's 4-insn combine change, when
configuring support libraries (libiberty, zlib, libdecnumber) for stage3. I
double-checked subsequent revisions that fix other PRs from r163383 (e.g.
r163546) and those did not help either. I tried --disable-multilib and/or
--with-cpu=niagara and that did not help.
I'm unsure of what other information to provide, but can provide more
information on request.
--
Summary: [4.6 regression] bootstrap failure on sparc64-unknown-
linux-gnu
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
GCC build triplet: sparc64-unknown-linux-gnu
GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-08-18 16:06 --- Subject: Bug 45049 Author: froydnj Date: Wed Aug 18 16:05:40 2010 New Revision: 163344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163344 Log: gcc/cp/ PR c++/45049 * name-lookup.c (push_overloaded_decl): Change DECL_CHAIN to TREE_CHAIN. gcc/testsuite/ PR c++/45049 * g++.dg/pr45049-1.C: New test. * g++.dg/pr45049-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr45049-1.C trunk/gcc/testsuite/g++.dg/pr45049-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45049
[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-08-18 16:07 --- Fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45049
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #21 from froydnj at gcc dot gnu dot org 2010-08-12 17:08 --- Even without optimization (as the compilation script uses), the program crashes. To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5): bug_example: pushl%ebp movl%esp, %ebp subl$1048, %esp # space for buffer movl8(%ebp), %eax # move string elsewhere movl%eax, -1020(%ebp) movl%gs:20, %eax# stuff for stack checking movl%eax, -12(%ebp) xorl%eax, %eax movb$0, -1012(%ebp) leal12(%ebp), %eax # address of i to stack movl%eax, 4(%esp) leal-1020(%ebp), %eax # address of (copied) strp to stack movl%eax, (%esp) callbug_example_2 movl-12(%ebp), %eax xorl%gs:20, %eax je.L6 call__stack_chk_fail .L6: leave ret .sizebug_example, .-bug_example You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*. This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #9 from froydnj at gcc dot gnu dot org 2010-08-09 15:58 --- r114528 and r114655 have been committed as r163033. r114348, r114396, and r116014 have been committed (no revisions, but I have them crossed off on my local list). FWIW, everything after r116179 is irrelevant for backporting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug libgcj/35367] Linux x86 build (with --enable-targets=all, so also building with cross-to-x64 multilib configuration) fails in libjava (prims.cc)
--- Comment #2 from froydnj at gcc dot gnu dot org 2010-07-06 13:02 --- (In reply to comment #1) debian doesn't have all libraries needed as build dependencies as 64bit versions, so it's clear that the build fails. IMO not a GCC issue. This same error occurs on systems where a native x86-64 build works just fine (and builds libjava), so yes, it is a GCC issue. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-06 13:02:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35367
[Bug bootstrap/44825] [4.6 regression] Failed to bootstrap
--- Comment #5 from froydnj at gcc dot gnu dot org 2010-07-05 22:19 --- Subject: Bug 44825 Author: froydnj Date: Mon Jul 5 22:19:22 2010 New Revision: 161856 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161856 Log: PR bootstrap/44825 * class.c (make_class_data): Cast result of VEC_length calls to int. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44825
[Bug objc/24867] many N^2 loops in objc frontend
--- Comment #5 from froydnj at gcc dot gnu dot org 2010-07-03 19:01 --- Subject: Bug 24867 Author: froydnj Date: Sat Jul 3 19:00:52 2010 New Revision: 161777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161777 Log: PR objc/24867 * objc-act.c (build_sized_array_type): New function. (add_objc_string): Use it. (generate_protocol_list): Likewise. (generate_objc_image_info): Likewise. (add_field_decl): New function. (objc_build_struct): Use a VEC rather than building a TREE_LIST. (generate_struct_by_value_array): Use add_field_decl. (build_objc_symtab_template): Likewise. (build_module_descriptor): Likewise. (build_objc_exception_stuff): Likewise. (build_protocol_template): Likewise. (build_method_prototype_list_template): Likewise. (build_method_prototype_template): Likewise. (build_category_template): Likewise. (build_selector_template): Likewise. (build_class_template): Likewise. (build_super_template): Likewise. (build_ivar_template): Likewise. (build_ivar_list_template): Likewise. (build_method_list_template): Likewise. (build_method_template): Likewise. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24867
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #4 from froydnj at gcc dot gnu dot org 2010-06-29 15:57 --- Subject: Bug 44713 Author: froydnj Date: Tue Jun 29 15:57:06 2010 New Revision: 161540 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161540 Log: PR bootstrap/44713 * config/i386/i386.c (type_natural_mode): Const-ify CUM parameter. (function_arg_advance_32): Const-ify TYPE parameter. (function_arg_advance_64): Likewise. Change type of NAMED to bool. (ix86_function_arg_advance): Change type of NAMED to bool. (function_arg_32): Const-ify CUM and TYPE parameters. (function_arg_64): Likewise. Change type of NAMED to bool. (function_arg_ms_64): Const-ify CUM parameter. Change type of NAMED to bool. (ix86_function_arg): Change type of NAMED to bool. (ix86_setup_incoming_varargs): Call ix86_function_arg_advance. Pass last argument as a bool. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- Comment #3 from froydnj at gcc dot gnu dot org 2010-06-14 17:51 --- Switched to NEW for NightStrike. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-14 17:51:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug middle-end/44204] [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167
--- Comment #2 from froydnj at gcc dot gnu dot org 2010-05-21 13:17 --- Subject: Bug 44204 Author: froydnj Date: Fri May 21 13:17:04 2010 New Revision: 159662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159662 Log: PR middle-end/44204 * builtins.c (fold_call_stmt): Pass error_mark_node if the call statement has no arguments. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44204
[Bug middle-end/44204] [4.6 regression] ICE in gimple_op_ptr, at gimple.h:167
--- Comment #3 from froydnj at gcc dot gnu dot org 2010-05-21 13:19 --- Fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44204
[Bug middle-end/44103] [4.6 Regression] New Java test failures
--- Comment #2 from froydnj at gcc dot gnu dot org 2010-05-14 20:47 --- Subject: Bug 44103 Author: froydnj Date: Fri May 14 20:47:39 2010 New Revision: 159414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159414 Log: PR 44103 * java-tree.h (START_RECORD_CONSTRUCTOR): Change first argument to a vector. Move call to build_constructor... (FINISH_RECORD_CONSTRUCTOR): ...here. Add necessary arguments. Clear TREE_CONSTANT on the constructor. (PUSH_SUPER_VALUE): Change first argument to a vector. (PUSH_FIELD_VALUE): Likewise. * resource.c (compile_resource_data): Update calls to above macros. * constants.c (build_constants_constructor): Likewise. * class.c (build_utf8_ref): Likewise. (make_field_value): Likewise. (make_method_value): Likewise. (add_table_and_syms): New function. (make_class_data): Call it. Update calls to above macros. (build_symbol_table_entry): New function. (build_symbol_entry): Call it. Update calls to above macros. (emit_symbol_table): Likewise. (make_catch_class_record): Update calls to above macros. (build_assertion_table_entry): New function. (add_assertion_table_entry): Call it. (emit_assertion_table): Likewise. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/gcc/java/constants.c trunk/gcc/java/java-tree.h trunk/gcc/java/resource.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44103
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #6 from froydnj at gcc dot gnu dot org 2010-05-12 15:35 --- r114291, r114400, and r114401 have been committed as r159326. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-05-12 15:56 --- r114547 and 114548 have been committed as r159328. r115342 has been committed as part of the CALL_EXPR changes that *did* make it in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-05-12 19:52 --- r114536 has been committed as r159340. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #3 from froydnj at gcc dot gnu dot org 2010-04-12 15:27 --- This should have been taken care of by: 2009-09-09 Jakub Jelinek ja...@redhat.com * config/t-slibgcc-elf-ver (SHLIB_MAKE_SOLINK, SHLIB_INSTALL_SOLINK): New variables. (SHLIB_LINK, SHLIB_INSTALL): Use them. * config/t-slibgcc-libgcc: New file. * config.gcc (powerpc*-*-linux*, powerpc*-*-gnu*): Use it. What does g++ -v say? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #4 from froydnj at gcc dot gnu dot org 2010-04-12 15:41 --- FWIW, I cannot reproduce with 'gcc version 4.5.0 20100205'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)
--- Comment #6 from froydnj at gcc dot gnu dot org 2010-02-09 17:51 --- Declaring this one fixed, somewhat late. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-01-25 21:10 ---
First, something has gotten better; an arm-eabi gcc (-O2 -std=c99 -mcpu=arm9
-funroll-loops) from 20091209 gives:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r4, r5, r6, r7, r8}
add r8, r1, #256
.L2:
ldr ip, [r1, #0]
mov r7, r1
mul r2, ip, r0
str r2, [r7], #4
ldr r3, [r1, #4]
ldr r5, [r7, #4]
mul r6, r3, r0
str r6, [r7, #0]
ldr r4, [r1, #12]
ldr ip, [r1, #16]
add r2, r1, #20
ldmia r2, {r2, r3, r7}@ phole ldm
mul r6, r5, r0
mul r5, r4, r0
mul r4, ip, r0
mul ip, r2, r0
mul r2, r3, r0
mul r3, r7, r0
str r6, [r1, #8]
str r5, [r1, #12]
str r4, [r1, #16]
str ip, [r1, #20]
str r2, [r1, #24]
add r1, r1, #32
cmp r1, r8
str r3, [r1, #-4]
bne .L2
ldmfd sp!, {r4, r5, r6, r7, r8}
bx lr
.size Unroll, .-Unroll
.ident GCC: (GNU) 4.5.0 20091209 (experimental)
which, if not close to ManualUnroll from the first comment, is much better than
the initial example.
Second, the problem Daniel mentioned concerning auto-inc/dec not doing the
right thing is because of the cleverness of
loop-unroll.c:analyze_iv_to_split_insn. It breaks the code shape that
auto-inc/dec needs. (You can see its effects in the assembly above; the
spurious move to r7 at the top of the loop.) Even if you disable that bit of
RTL loop unrolling, you also need to disable the web pass so as to not really
break the code shape for auto-inc/dec and introduce spurious moves into the
RTL. Once you do that, you get:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r1, #256
.L2:
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
cmp r1, ip
bne .L2
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug middle-end/41343] New: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use
When compiling the attached file as: powerpc-linux-gnu-gcc dosincos.i -g -O2 -std=gnu99 -fgnu89-inline -fmerge-all-constants The memory use of GCC balloons to 4GB+. I have a low ulimit on my machine, so I don't know whether leaving it alone with more memory would let the compilation finish. Using -fdump-tree-all-details indicates that things die somewhere in the inline_param3 pass. Discussion on IRC demonstrates the same behavior with a cross compiler from x86-64, with memory usage up to 12GB without finishing. -- Summary: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: froydnj at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343
[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use
--- Comment #1 from froydnj at gcc dot gnu dot org 2009-09-12 04:05 --- Created an attachment (id=18571) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18571action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343
[Bug middle-end/29274] [4.3/4.4/4.5 Regression] not using mulsidi3
--- Comment #8 from froydnj at gcc dot gnu dot org 2009-08-26 15:50 --- Even if the problems in expand are fixed, reassoc is still going to cause problems with the original testcase. From the dse1 dump: D.2474_14 = (long long int) vLo_11; D.2475_15 = (long long int) c1_6; D.2476_16 = D.2474_14 * D.2475_15; D.2477_19 = (long long int) c2_8; D.2478_20 = D.2474_14 * D.2477_19; From the reassoc1 dump right after: D.2474_14 = (long long int) vLo_11; D.2475_15 = (long long int) c1_6; D.2477_19 = (long long int) c2_8; D.2495_16 = D.2477_19 + D.2475_15; D.2495_20 = D.2495_16 * D.2474_14; So we've traded a multiplication for an addition, but we've also made it difficult to see that we could have used mulsidi3. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug target/40672] New: constant address loads moved into loop unnecessarily
The testcase below:
typedef unsigned char uint8_t;
#define UART3_LSR (*(volatile uint8_t *)(0x4902+20))
#define UART3_RBR (*(volatile uint8_t *)(0x4902+0))
int IsSerialBufferFull(void)
{
return (UART3_LSR 0x20) == 0;
}
void SendSerialByte(uint8_t byte)
{
while (IsSerialBufferFull())
;
UART3_RBR = byte;
}
when compiled with arm-none-eabi-gcc -O2 results in suboptimal code for
SendSerialByte:
SendSerialByte:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #1224736768
add r3, r3, #131072
.L3:
ldrbr2, [r3, #20] @ zero_extendqisi2
tst r2, #32
mov r2, #1224736768
add r2, r2, #131072
beq .L3
strbr0, [r2, #0]
bx lr
.size SendSerialByte, .-SendSerialByte
The load of the constant for UART3_RBR (mov r2/add r2) should not be moved into
the loop, since it's not needed until after the loop. Furthermore, the
necessary value is already available in r3.
The same problem doesn't happen on other platforms, e.g. mips-sde-elf gives:
andi$4,$4,0x00ff
li $2,1224867840 # 0x4902
.L6:
lbu $3,20($2)
andi$3,$3,0x20
beq $3,$0,.L6
nop
sb $4,0($2)
j $31
nop
or powerpc-eabi:
lis 9,0x4902
ori 9,9,20
.L4:
lbz 0,0(9)
andi. 11,0,32
beq+ 0,.L4
lis 9,0x4902
stb 3,0(9)
blr
(which is not quite perfect, but better than the arm-none-eabi code...).
--
Summary: constant address loads moved into loop unnecessarily
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40672
[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs
--- Comment #9 from froydnj at gcc dot gnu dot org 2009-03-10 15:43 --- Subject: Bug 37850 Author: froydnj Date: Tue Mar 10 15:42:51 2009 New Revision: 144751 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144751 Log: PR middle-end/37850 * libgcc2.c (__mulMODE3): Use explicit assignments to form the result. (__divMODE3): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/libgcc2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs
--- Comment #10 from froydnj at gcc dot gnu dot org 2009-03-10 15:49 --- Fixed on trunk. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug target/31535] ICE on attempt to put SPE vector variables in SDA
--- Comment #3 from froydnj at gcc dot gnu dot org 2008-11-12 14:32 --- Fixed in 4.3. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31535
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #17 from froydnj at gcc dot gnu dot org 2008-11-12 14:34 --- Fixed for 4.4. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #16 from froydnj at gcc dot gnu dot org 2008-08-12 18:20 --- Subject: Bug 26165 Author: froydnj Date: Tue Aug 12 18:19:08 2008 New Revision: 139031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139031 Log: PR libgomp/26165 * gcc.c (include_spec_function): Tweak call to find_a_file. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)
--- Comment #5 from froydnj at gcc dot gnu dot org 2008-07-30 15:32 --- Subject: Bug 35866 Author: froydnj Date: Wed Jul 30 15:30:59 2008 New Revision: 138316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138316 Log: PR target/35866 * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Add clause for vector modes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)
--- Comment #4 from froydnj at gcc dot gnu dot org 2008-05-09 03:14 --- If I understand correctly, one would just need to add vector modes with appropriate alignment restrictions to SLOW_UNALIGNED_ACCESS. If I add an extra || (((MODE) == V4SFmode || (MODE) == V2DFmode) (ALIGN) 128) to SLOW_UNALIGNED_ACCESS, and compile without -mstrict-align, I get semi-reasonable looking code at -O2: f: stwu 1,-48(1) addi 9,1,16 stw 28,32(1) stw 29,36(1) stvx 2,0,9 lwz 8,12(9) lwz 5,0(9) lwz 6,4(9) mr 0,8 lwz 7,8(9) stw 8,13(3) addi 8,1,16 stw 5,1(3) stw 7,9(3) stw 6,5(3) stw 5,0(8) stw 6,4(8) stw 7,8(8) stw 0,12(8) lvx 2,0,8 lwz 28,32(1) lwz 29,36(1) addi 1,1,48 blr It could be improved, but it's a lot better than -mstrict-align code. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug target/31535] ICE on attempt to put SPE vector variables in SDA
--- Comment #2 from froydnj at gcc dot gnu dot org 2008-01-28 18:32 --- Subject: Bug 31535 Author: froydnj Date: Mon Jan 28 18:31:19 2008 New Revision: 131914 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131914 Log: gcc/ PR 31535 * config/rs6000/rs6000.c (small_data_operand): Vectors and floats are not legitimate small data references on SPE targets. gcc/testsuite/ PR 31535 * gcc.target/powerpc/spe-small-data-1.c: New test. * gcc.target/powerpc/spe-small-data-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/spe-small-data-1.c trunk/gcc/testsuite/gcc.target/powerpc/spe-small-data-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31535
[Bug middle-end/25445] -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c
--- Comment #3 from froydnj at gcc dot gnu dot org 2007-10-15 17:30 --- Marking as fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25445
[Bug middle-end/25446] -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c
--- Comment #3 from froydnj at gcc dot gnu dot org 2007-10-15 17:31 --- Marking as fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25446
[Bug rtl-optimization/11001] global register %edi versus string builtins
--- Comment #13 from froydnj at gcc dot gnu dot org 2007-10-12 16:12 --- Subject: Bug 11001 Author: froydnj Date: Fri Oct 12 16:12:45 2007 New Revision: 129265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129265 Log: gcc/ PR 11001 * config/i386/i386.md (strmov): Check for esi and edi usage. * config/i386/i386.c (decide_alg): Check whether we can use a rep prefix and adjust algorithm choice accordingly. (ix86_expand_strlen): Check for eax, ecx, and edi usage. gcc/testsuite/ PR 11001 * gcc.target/i386/pr11001-strlen-1.c: New testcase. * gcc.target/i386/pr11001-strlen-2.c: New testcase. * gcc.target/i386/pr11001-strlen-3.c: New testcase. * gcc.target/i386/pr11001-memset-1.c: New testcase. * gcc.target/i386/pr11001-memset-2.c: New testcase. * gcc.target/i386/pr11001-memset-3.c: New testcase. * gcc.target/i386/pr11001-memcpy-1.c: New testcase. * gcc.target/i386/pr11001-memcpy-2.c: New testcase. * gcc.target/i386/pr11001-memcpy-3.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-3.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-3.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11001
[Bug middle-end/25445] -fpic/-fPIC failure in gcc.dg/tree-ssa/wholeprogram-1.c
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:40 --- Subject: Bug 25445 Author: froydnj Date: Thu Aug 2 14:40:36 2007 New Revision: 127162 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127162 Log: PR middle-end/25445 * varasm.c (default_binds_local_p_1): Consult flag_whole_program if we are compiling with -fPIC. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25445
[Bug middle-end/25446] -fpic/-fPIC failure in gcc.dg/vect/vect-ifcvt-9.c
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:43 --- Subject: Bug 25446 Author: froydnj Date: Thu Aug 2 14:42:53 2007 New Revision: 127163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127163 Log: PR middle-end/25446 * c-objc-common.c (c_cannot_inline_tree_fn): Check for an always_inline attribute on the function decl. Modified: trunk/gcc/ChangeLog trunk/gcc/c-objc-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25446
