[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Comment #56 from paul dot richard dot thomas at cea dot fr 2006-06-01 07:31 --- Jerry, Where are we with this one? Did you have time yet to automatize the testing? It would be real nice to close it! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #4 from mirko dot bruzzone at primeur dot com 2006-06-01 08:08 --- I tried to compile in another directory than the source directory and I executed the make bootstrap...but nothing. This is the report: gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwri te-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -I. -I/usr1/bruzzonem/gcc-4.0.3/gcc -I/usr1/bruzzonem/gcc-4.0.3/gcc/. -I/usr1/bruzzo nem/gcc-4.0.3/gcc/../include -I./../intl -I/usr1/bruzzonem/gcc-4.0.3/gcc/../libc pp/include /usr1/bruzzonem/gcc-4.0.3/gcc/c-pragma.c -o c-pragma.o In file included from /usr1/bruzzonem/gcc-4.0.3/gcc/c-pragma.c:708: gt-c-pragma.h:46: parse error before `__attribute__' /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_last' defined but n ot used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_iterate' defined bu t not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_alloc' defined but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_free' defined but n ot used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_embedded_size' defi ned but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_embedded_init' defi ned but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_safe_push' defined but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_pop' defined but no t used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_truncate' defined b ut not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_replace' defined bu t not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_lower_bound' define d but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_safe_insert' define d but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_ordered_remove' def ined but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_unordered_remove' d efined but not used /usr1/bruzzonem/gcc-4.0.3/gcc/tree.h:166: warning: `VEC_tree_address' defined bu t not used make[2]: *** [c-pragma.o] Error 1 make[2]: Leaving directory `/usr1/bruzzonem/objgcc/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/usr1/bruzzonem/objgcc/gcc' make: *** [bootstrap] Error 2 I hope that someone can help me! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug fortran/13615] g77 -Wuninitialized doesn't produce warning on characters
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-01 08:17 --- This is still the case; Is this a gfortran issue or a gcc one? If I give the characters length, using any format, even the anonymous warning goes away. In fact, any array expression that I have tried is the same; eg. real d(8), c(8) d = c is ignored. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #9 from uros at kss-loka dot si 2006-06-01 08:43 --- The benchmark run on a Pentium4 3.2G/800MHz FSB (32bit): vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping: 9 cpu MHz : 3191.917 cache size : 512 KB shows even more interesting results: gcc version 3.4.6 vs. gcc version 4.2.0 20060601 (experimental) -fomit-frame-pointer -O -msse2 -mfpmath=sse GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.162 2664.87 GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.164 2633.13 and -fomit-frame-pointer -O -mfpmath=387 GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.160 2697.37 GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.164 2633.15 There is a small performance drop on gcc-4.x, but nothing critical. I can confirm, that code indeed runs >50% slower on 64bit athlon. Perhaps the problem is in the order of instructions (Software Optimization Guide for AMD Athlon 64, Section 10.2). The gcc-3.4 code looks similar to the example, how things should be, and gcc-4.2 code looks similar to the example, how things should _NOT_ be. BTW: Did you try to run the benchmark on AMD target with -march=k8? The effects of this flag are devastating on Pentium4 CPU: -O -msse2 -mfpmath=sse -march=k8 ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.836 516.79 GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.287 1504.66 -- uros at kss-loka dot si changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-01 08:43:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug libgcj/20047] runtime 'protected' access checks
--- Comment #2 from mckinlay at redhat dot com 2006-06-01 11:07 --- This rule is mentioned in the last paragraph of JVMS, S 5.4.4: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#75929 It is explicitly stated that this is checked during verification, unlike other accessibility checks which are performed at link time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20047
[Bug tree-optimization/27855] New: reassociation pass produces ~30% slower matrix multiplication code
The testcase from PR target/27827 shows another problem, this time with -ffast-math. The runtime performance of -ffast-math code drops for ~30%. The problem could be traced down to reassociation tree pass, because the performance jumps back when "flag_unsafe_math_optimizations" switch is disabled by changing every occurence in tree-ssa-reassoc.c with (flag_unsafe_math_optimizations && 0). To see the problem, -funsafe-math-optimizations should be added to MMFLAGS in target/27827 example Makefile: MM4FLAGS = $(GMMFLAGS) -funsafe-math-optimizations Current mainline gcc produces code with following results: -O -mfpmath=387 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.260 1663.04 -O -msse2 -mfpmath=sse ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.229 1890.47 gcc with disabled reassoc pass for floating point values: -O -mfpmath=387 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.162 2664.87 -O -msse2 -mfpmath=sse ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.164 2633.15 -- Summary: reassociation pass produces ~30% slower matrix multiplication code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu OtherBugsDependingO 27827 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug rtl-optimization/27856] New: With -Os, loading a constant to a register can use another register
$ cat tmp.c
unsigned athird (unsigned val)
{
return val / 3;
}
$ /home/etienne/projet/toolchain/bin/gcc -S -Os -o tmp.s -fomit-frame-pointer
-fverbose-asm tmp.c
$ cat tmp.s
.file "tmp.c"
# GNU C version 4.1.1 (i686-pc-linux-gnu)
# compiled by GNU C version 4.1.1.
# GGC heuristics: --param ggc-min-expand=62 --param ggc-min-heapsize=60570
# options passed: -mtune=pentiumpro -auxbase-strip -Os
# -fomit-frame-pointer -fverbose-asm
# options enabled: -falign-loops -fargument-alias -fbranch-count-reg
# -fcaller-saves -fcommon -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions -finline-functions-called-once
# -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
# -fkeep-static-consts -fleading-underscore -floop-optimize
# -floop-optimize2 -fmath-errno -fmerge-constants -fomit-frame-pointer
# -foptimize-register-move -foptimize-sibling-calls -fpcc-struct-return
# -fpeephole -fpeephole2 -fregmove -freorder-functions
# -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column
# -fsplit-ivs-in-unroller -fstrength-reduce -fstrict-aliasing
# -fthread-jumps -ftrapping-math -ftree-ccp -ftree-copy-prop
# -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs
# -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
# -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp
# -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss -m32 -m80387
# -m96bit-long-double -malign-stringops -mfancy-math-387 -mfp-ret-in-387
# -mieee-fp -mno-red-zone -mpush-args -mtls-direct-seg-refs
# Compiler executable checksum: acc0f3237f8807740daa75cf2b5b2d98
.text
.globl athird
.type athird, @function
athird:
movl4(%esp), %eax # val, val
movl$3, %edx#, tmp63
movl%edx, %ecx # tmp63,
xorl%edx, %edx # tmp62
divl%ecx#
ret
.size athird, .-athird
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
Here tmp63 is not needed and the two lines:
movl$3, %edx#, tmp63
movl%edx, %ecx # tmp63,
Should be replaced by:
movl$3, %ecx
--
Summary: With -Os, loading a constant to a register can use
another register
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27856
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48 --- Does the C++ FE need the exact decl after gimplification? If not, perhaps as a workaround pushdecl_maybe_friend could together with duplicating DECL_UID also populate a hash table and cp-gimplify.c would use that hash table to make sure only one of the decls with the same DECL_UID ever makes it into gimple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-01 12:09 --- Similar(?) bug on ppc for trunk: +===GNAT BUG DETECTED==+ | 4.2.0 20060601 (experimental) (SUSE Linux) (powerpc64-suse-linux-gnu) GCC error:| | in change_address_1, at emit-rtl.c:1784 | | Error detected at g-os_lib.adb:2603:1| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[7]: *** [g-os_lib.o] Error 1 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21307
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-06-01 12:22 ---
The SMT related stuff is a red herring.
Someone is not marking things for renaming when they should be.
The following patch will show that (it disables the used alone code).
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 114136)
+++ tree-ssa-operands.c (working copy)
@@ -1294,12 +1294,12 @@ add_virtual_operand (tree var, stmt_ann_
|| none_added
|| (TREE_CODE (var) == SYMBOL_MEMORY_TAG
&& for_clobber
- && SMT_USED_ALONE (var)))
+ /*&& SMT_USED_ALONE (var)*/))
{
/* Every bare SMT def we add should have SMT_USED_ALONE
set on it, or else we will get the wrong answer on
clobbers. */
- if (none_added
+ if (0 && none_added
&& !updating_used_alone && aliases_computed_p
&& TREE_CODE (var) == SYMBOL_MEMORY_TAG)
gcc_assert (SMT_USED_ALONE (var));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug bootstrap/25453] [4.2 Regression] --disable-bootstrap is not documented
--- Comment #5 from bonzini at gnu dot org 2006-06-01 12:28 --- Subject: Bug 25453 Author: bonzini Date: Thu Jun 1 12:28:11 2006 New Revision: 114305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114305 Log: 2006-06-01 Paolo Bonzini <[EMAIL PROTECTED]> PR 25453 * doc/install.texi: Document --enable-bootstrap and --disable-bootstrap. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
[Bug bootstrap/25453] [4.2 Regression] --disable-bootstrap is not documented
--- Comment #6 from bonzini at gnu dot org 2006-06-01 12:33 --- documentation committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
[Bug c++/27804] [4.2 regression] ICE with invalid const variable
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-01 12:40 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27804
[Bug bootstrap/27822] [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
--- Comment #5 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-06-01 12:53 --- Subject: RE: [4.1 only] fastjar is asking for makeinfo in gmake bootstrap Sorry M. Pinski, I do not understand your comment. Do you mean fasjar is removed from the pre-release and not in the tarballs? Besides, the only one available from ftp.gnu.org is the following /gnu/gcc/gcc-4.1.1/gcc-4.1.1.tar.bz2 wich I assume to be the tarballs. If I do a simple gmake without the boostrap option I go through all the compiling. The problem appears only when I do a gmake bootstrap. William Paul Philibert Administrateur UNIX et SAN [EMAIL PROTECTED] Hébergement Telus Corporation Inc. (418) 722-1280 -Message d'origine- De : pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Envoyé : 1 juin 2006 00:57 À : William-Paul Philibert Objet : [Bug bootstrap/27822] [4.1 only] fastjar is asking for makeinfo in gmake bootstrap --- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 04:57 --- fastjar is removed in the mainline sources. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|fastjar is asking for |[4.1 only] fastjar is asking |makeinfo in gmake bootstrap |for makeinfo in gmake ||bootstrap Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27822 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27822
[Bug tree-optimization/27858] New: ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
I get the following ICE when bootstrapping gcc 4.2 20060530 on alpha. 20060508
worked fine. I'm running delta right now and will send a test case when it's
done.
/build/buildd/gcc-snapshot-20060530/build/./gcc/xgcc
-B/build/buildd/gcc-snapshot-20060530/build/./gcc/
-B/usr/lib/gcc-snapshot/alpha-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/alpha-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/alpha-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/alpha-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../../../../src/libjava/classpath/native/fdlibm -I../../include -O2 -g
-O2 -mieee -MT strtod.lo -MD -MP -MF .deps/strtod.Tpo -c
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c -fPIC -DPIC -o
.libs/strtod.o
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c: In function
'_Jv_strtod_r':
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c:718: error:
unable to find a register to spill in class 'FLOAT_REGS'
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c:718: error: this
is the insn:
(insn 1014 1010 2389 99
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c:345 (set (reg:DF
34 $f2 [orig:288 prephitmp.60 ] [288])
(subreg:DF (const_int 9218868437227405312 [0x7ff0]) 0)) 235
{*movdf_nofix} (nil)
(expr_list:REG_DEAD (reg:DI 875)
(nil)))
../../../../../../src/libjava/classpath/native/fdlibm/strtod.c:718: internal
compiler error: in spill_failure, at reload1.c:1911
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[7]: *** [strtod.lo] Error 1
--
Summary: ICE in spill_failure, at reload1.c:1911while
bootstrapping 4.2 on alpha
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug tree-optimization/27858] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:00 ---
3012:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O1 mini.c
3013:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O2 mini.c
mini.c: In function _Jv_strtod_r:
mini.c:81: error: unable to find a register to spill in class FLOAT_REGS
mini.c:81: error: this is the insn:
(insn 35 33 22 4 (set (reg:DF 34 $f2 [orig:70 prephitmp.31 ] [70])
(subreg:DF (const_int 9218868437227405312 [0x7ff0]) 0)) 235
{*movdf_nofix} (nil)
(expr_list:REG_DEAD (reg:DI 139)
(nil)))
mini.c:81: internal compiler error: in spill_failure, at reload1.c:1911
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
zsh: exit 1 /home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c -O2 mini.c
3014:[EMAIL PROTECTED]: ~/tmp/delta/bin]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug tree-optimization/27858] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
--- Comment #2 from tbm at cyrius dot com 2006-06-01 13:01 --- Created an attachment (id=11566) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11566&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug c/27859] New: Bug in generation of interrupt function code for ARM processor
The C compiler generates wrong assembler code for functions with __attribute__
((interrupt ("IRQ"))). Link register lr in interrupt function is decremented
two times before it is loaded back to the program counter pc. It is decremented
at the beginning of interrupt routime (sub lr, lr, #4) and again at the end
(subspc, lr, #4). It should be decremented only once. Such a bug was also
reported previously (ID 16634, ID 25428). Here is the complete example:
PROGRAM bug.c:
void function( void )
{
volatile unsigned int *a;
a = (unsigned int *)2000;
*a = 1;
*a = 0;
}
void IRQ_Handler( void ) __attribute__ ((interrupt ("IRQ")));
void IRQ_Handler( void )
{
volatile unsigned int s, *a;
a = (unsigned int *)2500;
s = *a;
function();
}
COMPILATION OUTPUT:
arm-4.1.1-eabi-gcc -v -save-temps -Wall -c -O -o bug.o bug.c
Using built-in specs.
Target: arm-none-eabi
Configured with: ./configure --target=arm-none-eabi
--program-prefix=arm-4.1.1-eabi-
Thread model: single
gcc version 4.1.1
/usr/local/packages/arm411/bin/../libexec/gcc/arm-none-eabi/4.1.1/cc1 -E
-quiet -v -iprefix
/usr/local/packages/arm411/bin/../lib/gcc/arm-none-eabi/4.1.1/
-D__USES_INITFINI__ bug.c -Wall -O -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/local/packages/arm411/bin/../lib/gcc/arm-none-eabi/4.1.1/../../../../arm-none-eabi/sys-include"
ignoring nonexistent directory "/usr/local/lib/gcc/arm-none-eabi/4.1.1/include"
ignoring nonexistent directory "/usr/local/lib/../arm-none-eabi/sys-include"
ignoring nonexistent directory "/usr/local/lib/../arm-none-eabi/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/packages/arm411/bin/../lib/gcc/arm-none-eabi/4.1.1/include
/usr/local/packages/arm411/bin/../lib/gcc/arm-none-eabi/4.1.1/../../../../arm-none-eabi/include
End of search list.
/usr/local/packages/arm411/bin/../libexec/gcc/arm-none-eabi/4.1.1/cc1
-fpreprocessed bug.i -quiet -dumpbase bug.c -auxbase-strip bug.o -O -Wall
-version -o bug.s
GNU C version 4.1.1 (arm-none-eabi)
compiled by GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128878
Compiler executable checksum: 8b248e68ff58c0b76da33bbc4bade307
/usr/local/packages/arm411/bin/../lib/gcc/arm-none-eabi/4.1.1/../../../../arm-none-eabi/bin/as
-meabi=4 -o bug.o bug.s
ASSEMBLER OUTPUT:
.file "bug.c"
.text
.align 2
.global function
.type function, %function
function:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r3, #0
mov r2, #1
str r2, [r3, #2000]
str r3, [r3, #2000]
bx lr
.size function, .-function
.align 2
.global IRQ_Handler
.type IRQ_Handler, %function
IRQ_Handler:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
sub lr, lr, #4
stmfd sp!, {r0, r1, r2, r3, ip, lr}
sub sp, sp, #8
mov r3, #0
ldr r3, [r3, #2500]
str r3, [sp, #4]
bl function
add sp, sp, #8
ldmfd sp!, {r0, r1, r2, r3, ip, lr}
subspc, lr, #4
.size IRQ_Handler, .-IRQ_Handler
.ident "GCC: (GNU) 4.1.1"
Best regards,
Jurij Kotar
--
Summary: Bug in generation of interrupt function code for ARM
processor
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jurij dot kotar at gmail dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27859
[Bug tree-optimization/27861] New: [4.0,4.1,4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
I get the following ICE with gcc 4.2 20060508 and 20060530 on mipsel. Actually, I get this with gcc 4.0 and 4.1 too. gcc 3.4 works. sh-3.1# /usr/lib/gcc-snapshot/bin/gcc -c -O1 mini.c mini.c: In function 'do_dror': mini.c:56: internal compiler error: in expand_expr_real_1, at expr.c:6916 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. sh-3.1# /usr/lib/gcc-snapshot/bin/gcc -c mini.c sh-3.1# gcc-4.0 -c -O1 mini.c mini.c: In function 'do_dror': mini.c:15: internal compiler error: in expand_expr_real_1, at expr.c:6608 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . sh-3.1# gcc-4.1 -c -O1 mini.c mini.c: In function 'do_dror': mini.c:56: internal compiler error: in expand_expr_real_1, at expr.c:6750 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Preprocessed source stored into /tmp/cckCjb5E.out file, please attach this to your bugreport. sh-3.1# -- Summary: [4.0,4.1,4.2 regression] ICE in expand_expr_real_1, at expr.c:6916 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: mipsel-linux-gnu GCC host triplet: mipsel-linux-gnu GCC target triplet: mipsel-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug tree-optimization/27861] [4.0,4.1,4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:59 --- Created an attachment (id=11567) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11567&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug target/27862] New: ICE in change_address_1, at emit-rtl.c:1784
/gcc/abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W
-Wall -fPIC -g -mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o
/dev/null
+===GNAT BUG DETECTED==+
| 4.2.0 20060601 (experimental) (powerpc64-suse-linux-gnu) GCC error: |
| in change_address_1, at emit-rtl.c:1784 |
| Error detected at g-os_lib.adb:2603:1|
gcc_assert (memory_address_p (mode, addr));
(gdb) up
#1 0x10564304 in change_address_1 (memref=0x4040ac70, mode=BLKmode,
addr=0x4053f2a0, validate=1) at ../../trunk/gcc/emit-rtl.c:1784
1784gcc_assert (memory_address_p (mode, addr));
(gdb) print mode
$1 = BLKmode
(gdb) call debug_rtx (addr)
(symbol_ref:SI ("*.LANCHOR1") [flags 0x182])
#1 0x10564304 in change_address_1 (memref=0x4040ac70, mode=BLKmode,
addr=0x4053f2a0, validate=1) at ../../trunk/gcc/emit-rtl.c:1784
#2 0x10565a5c in replace_equiv_address (memref=0x4040ac70, addr=0x4053f2a0)
at ../../trunk/gcc/emit-rtl.c:1965
#3 0x1057c9e4 in use_anchored_address (x=0x4040ac70)
at ../../trunk/gcc/explow.c:592
#4 0x105b2f90 in expand_expr_real_1 (exp=0x400e4ee0, target=0x0,
tmode=SImode, modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0)
at ../../trunk/gcc/expr.c:6883
...
#11 0x1057a120 in expand_normal (exp=0x40119600) at expr.h:499
#12 0x105771f4 in output_ttype (type=0x40119600, tt_format=155,
tt_format_size=4) at ../../trunk/gcc/except.c:3591
#13 0x10577dc8 in output_function_exception_table ()
at ../../trunk/gcc/except.c:3787
#14 0x105d4d48 in rest_of_handle_final () at ../../trunk/gcc/final.c:3929
#15 0x108f3dbc in execute_one_pass (pass=0x10df2374)
at ../../trunk/gcc/passes.c:864
in expanding of gnat__os_lib__copy_file.
Which breaks bootstrap with Ada on ppc. Maybe related to 21307.
--
Summary: ICE in change_address_1, at emit-rtl.c:1784
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
BugsThisDependsOn: 21307
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
[Bug target/27862] ICE in change_address_1, at emit-rtl.c:1784
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 14:13 --- Reproduces also with /abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O0 -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o /dev/null -fno-section-anchors fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
[Bug target/27862] ICE in change_address_1, at emit-rtl.c:1784
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 14:17 --- err, -O, not -O0 in previous comment. Obviously. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
[Bug target/27862] ICE in change_address_1, at emit-rtl.c:1784
--- Comment #3 from dje at gcc dot gnu dot org 2006-06-01 14:20 --- dup *** This bug has been marked as a duplicate of 27536 *** -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #12 from dje at gcc dot gnu dot org 2006-06-01 14:20 --- *** Bug 27862 has been marked as a duplicate of this bug. *** -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #12 from mark at codesourcery dot com 2006-06-01 14:59 --- Subject: Re: [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong jakub at gcc dot gnu dot org wrote: > --- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48 > --- > Does the C++ FE need the exact decl after gimplification? If not, perhaps > as a workaround pushdecl_maybe_friend could together with duplicating DECL_UID > also populate a hash table and cp-gimplify.c would use that hash table to make > sure only one of the decls with the same DECL_UID ever makes it into gimple. That's a good idea! I would still like to fix this "the right way" at some point (because there are other problems that would solve as well), but your idea would probably move the hack from the middle end into the front end. To answer your question directly, since the C++ front end is always unit-at-a-time, it doesn't care at all what happens after gimplification; by the time it's gimplifying, it's done all the semantic analysis it's going to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug other/27850] gcov-enabled sh-elf compiler fails to build
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-01 15:23 --- (In reply to comment #1) > --with-headers with a combined build is not really a good thing. > --with-headers is required for cross compilers in order to build a working libgcov. A working libgcov is required for profiling and profile-directed optimizations, and hence for a successfull regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27850
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 15:26 --- There is nothing special about reassociation at all. In fact what you are seeing is register allocator going funky. This what you get with x87. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target Keywords||ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/27858] [4.2 Regression] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target Keywords||build, ice-on-valid-code Summary|ICE in spill_failure, at|[4.2 Regression] ICE in |reload1.c:1911while |spill_failure, at |bootstrapping 4.2 on alpha |reload1.c:1911while ||bootstrapping 4.2 on alpha Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug libgcj/27860] build failure on m68k: error: 'ffi_closure' does not name a type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27860
[Bug tree-optimization/27861] [4.0/4.1/4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||3.4.6 Summary|[4.0,4.1,4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE |in expand_expr_real_1, at |in expand_expr_real_1, at |expr.c:6916 |expr.c:6916 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-06-01 15:44
---
(In reply to comment #11)
> Index: arith.c
> ===
> --- arith.c (revision 114111)
> +++ arith.c (working copy)
> @@ -1133,8 +1133,10 @@ gfc_compare_string (gfc_expr * a, gfc_ex
>
>for (i = 0; i < len; i++)
> {
> - ac = (i < alen) ? a->value.character.string[i] : ' ';
> - bc = (i < blen) ? b->value.character.string[i] : ' ';
> + /* We cast to unsigned char because default char, if it is signed,
> + would lead to ac<0 for string[i] > 127. */
> + ac = (unsigned char) ((i < alen) ? a->value.character.string[i] : ' ');
> + bc = (unsigned char) ((i < blen) ? b->value.character.string[i] : ' ');
>
>if (xcoll_table != NULL)
> {
OK. Although I still like better my previous patch, there's no point arguing
over this for years. Go ahead!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL|http://gcc.gnu.org/ml/fortra|
|n/2006-05/msg00489.html |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug target/27863] New: [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
gcc -c -O2 e3.c e3.c:1803: internal compiler error: in check_cfg, at haifa-sched.c:4615 Please submit a full bug report, with preprocessed source if appropriate. See http://www.suse.de/feedback> for instructions. -- Summary: [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 15:50 --- Created an attachment (id=11569) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11569&action=view) testcase (unreduced) Testcase. Reducing currently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 15:57 ---
Reduced testcase:
long stack[100];
int main(int argc,char**argv,char **envp)
{
long *esp=stack;
static void* jarray[]={ &&KeyCtrlKV };
*++esp=(long)&&_loc0;
goto SetTermStruc;
_loc0:;
*++esp=(long)&&_loc1;
_loc1:;
*++esp=(long)&&_loc35;
_loc35:;
goto *(*esp--);
*++esp=(long)&&_loc36;
_loc36:;
*++esp=(long)&&_loc37;
_loc37:;
KeyCtrlKV:
*++esp=(long)&&_loc66;
_loc66:;
*++esp=(long)&&_loc106;
_loc106:;
*++esp=(long)&&_loc119;
_loc119:;
SetTermStruc:
goto *(*esp--);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #10 from whaley at cs dot utsa dot edu 2006-06-01 16:02 --- Created an attachment (id=11571) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11571&action=view) Same benchmark, but with single precision timing included Here's the same benchmark, but can time single as well as double precision, in case you want to play with the SSE code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #11 from whaley at cs dot utsa dot edu 2006-06-01 16:26 --- Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3 Uros, OK, I originally replied a couple of hours ago, but that is not appearing on bugzilla for some reason, so I'll try again, this time CCing myself so I don't have to retype everything :) >gcc version 3.4.6 >vs. >gcc version 4.2.0 20060601 (experimental) > >-fomit-frame-pointer -O -msse2 -mfpmath=sse > >There is a small performance drop on gcc-4.x, but nothing critical. > >I can confirm, that code indeed runs >50% slower on 64bit athlon. Perhaps the >problem is in the order of instructions (Software Optimization Guide for AMD >Athlon 64, Section 10.2). The gcc-3.4 code looks similar to the example, how >things should be, and gcc-4.2 code looks similar to the example, how things >should _NOT_ be. First, thanks for looking into this! As to your point, yes, I am aware that gcc4-sse can get almost the same performance as gcc3-x87 (though not quite), and in fact can do so on the Athlon 64 as well, **but only for double precision**. To get SSE within a few percent of x87 on the AMD machine, you use a different kernel (remember, I'm sending you an example out of many), and throw the following flags: -march=athlon64 -O2 -mfpmath=sse -msse -msse2 -m64 \ -ftree-vectorize -fargument-noalias-global (note this does not vectorize the code, but I throw the flag in the hope that future versions will :) Note that my bug report concentrates on "x87 performance"! There are reasons to use x87 even if scalar SSE is competitive performance-wise, as the x87 unit produces much superior accuracy. However, even if we were to take the tack (and gcc may be doing this for all I know) that once scalar SSE can compete performance wise, the x87 unit will no longer be supported, we must also examine single precision performance. For single precision performance, I have never gotten any scalar SSE kernel to compete even close to the gcc3-x87 numbers. I believe (w/o having proved it) that this is probably due to the cost of using the scalar load: double precision can use the low-overhead movlpd instruction, but single must use MOVSS, which is **much** slower than FLD, and so any kernel using scalar SSE blows chunks. ATLAS's best case gcc4-sse kernel gets roughly half of the gcc-x87 performance on an Athlon-64, and something like 80% on a P4e (note that intel machines have half the theoretical peak for x87 [AMD: 2 flops/cycle, Intel: 1 flop/cycle]: getting a large % of performance gets easier the lower your peak gets!). I originally submitted a double precision kernel, because that showed the x87 performance problem, and allowed me to reuse the infrastructure I created for an earlier bug report (bugzilla 4991). I have just uploaded an example attachment that can time both single and double precision performance, if you want to confirm for yourself that SSE is not competitive for single precision. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/27858] [4.2 Regression] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 16:28 --- I can reproduce this with 4.2.0 Mon May 29 22:03:29 UTC 2006 (revision 114217M) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug target/27858] [4.2 Regression] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 17:14 ---
Confirmed, a little more reduced testcase:
typedef unsigned int uint32_t;
union double_union
{
double d;
uint32_t i[2];
};
int *_Jv_s2b (void);
int *_Jv_Balloc (int);
double _Jv_strtod_r (int *ptr, char *se, int e1, union double_union rv0, int
sign, long y)
{
union double_union rv;
int *bd = 0 , *bd0 = 0;
if (e1 > 308)
{
ovfl:
(rv.i[1]) = 0x7ff0L;
(rv.i[0]) = 0;
if (bd0)
goto retfree;
goto ret;
}
if (!rv.d)
rv.d = 0.;
bd0 = _Jv_s2b ();
for (;;)
{
bd = _Jv_Balloc (*bd0);
if (!rv.d)
goto retfree;
if (y == ((uint32_t) 0x10L) )
if (((rv.i[1]) & ((uint32_t) 0x7ff0L))
>= ((uint32_t) 0x10L) * (1994))
if ((rv0.i[1]) == (((uint32_t) 0xfL) | ((uint32_t)
0x10L) * (2046))
&& (rv0.i[0]) == ((uint32_t) 0xL))
goto ovfl;
_Jv_Bfree1 ();
}
retfree:
_Jv_Bfree (ptr);
ret:
*se = 0;
return sign ? -rv.d : rv.d;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-01 17:14:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug target/27856] With -Os, loading a constant to a register can use another register
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 17:21 ---
Confirmed, this is a RA issue.
Before register allocation:
(insn:HI 10 7 11 2 (set (reg:SI 63)
(const_int 3 [0x3])) 34 {*movsi_1} (nil)
(expr_list:REG_EQUIV (const_int 3 [0x3])
(nil)))
(insn:HI 11 10 15 2 (parallel [
(set (reg:SI 61)
(udiv:SI (reg/v:SI 59 [ val ])
(reg:SI 63)))
(set (reg:SI 62)
(umod:SI (reg/v:SI 59 [ val ])
(reg:SI 63)))
(clobber (reg:CC 17 flags))
]) 197 {udivmodsi4} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
10 (nil)))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 62)
(expr_list:REG_DEAD (reg/v:SI 59 [ val ])
(expr_list:REG_DEAD (reg:SI 63)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 62)
(nil
---
After:
(insn:HI 10 7 30 2 (set (reg:SI 1 dx [63])
(const_int 3 [0x3])) 34 {*movsi_1} (nil)
(expr_list:REG_EQUIV (const_int 3 [0x3])
(nil)))
(insn 30 10 11 2 (set (reg:SI 2 cx)
(reg:SI 1 dx [63])) 34 {*movsi_1} (nil)
(nil))
(insn:HI 11 30 15 2 (parallel [
(set (reg:SI 0 ax [61])
(udiv:SI (reg/v:SI 0 ax [orig:59 val ] [59])
(reg:SI 2 cx)))
(set (reg:SI 1 dx [62])
(umod:SI (reg/v:SI 0 ax [orig:59 val ] [59])
(reg:SI 2 cx)))
(clobber (reg:CC 17 flags))
]) 197 {udivmodsi4} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
10 (nil)))
(nil))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ra
Last reconfirmed|-00-00 00:00:00 |2006-06-01 17:21:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27856
[Bug target/27856] With -Os, loading a constant to a register can use another register
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-01 17:24 --- And "yara" gets this correct. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||18427 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27856
[Bug tree-optimization/27865] New: tree check failure building FreePOOMA
FreePOOMA 2.4.1 fails to build on powerpc-linux with beginning with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=114057 r114057 | rakdver | 2006-05-24 22:55:15 + (Wed, 24 May 2006) Output with a minimized testcase: elm3b145% /opt/gcc-nightly/trunk/bin/g++ -c -O2 poomabug.cc poomabug.cc: In constructor GLD::GLD(const II&, const PP&, const CM&) [with PP = GP<2> ()(), int Dim = 2]: poomabug.cc:117: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in adjust_range_with_scev, at tree-vrp.c:2079 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: tree check failure building FreePOOMA Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
[Bug tree-optimization/27865] tree check failure building FreePOOMA
--- Comment #1 from janis at gcc dot gnu dot org 2006-06-01 17:45 --- Created an attachment (id=11574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11574&action=view) minimized testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
[Bug target/27858] [4.2 Regression] ICE in spill_failure, at reload1.c:1911while bootstrapping 4.2 on alpha
--- Comment #5 from janis at gcc dot gnu dot org 2006-06-01 17:50 --- A regression hunt using an alpha-linux cross compiler on powerpc64-linux with the testcase mini.c identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=113632 r113632 | sayle | 2006-05-08 21:09:49 + (Mon, 08 May 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
[Bug tree-optimization/27865] [4.2 Regression] tree check failure building FreePOOMA
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|tree check failure building |[4.2 Regression] tree check |FreePOOMA |failure building FreePOOMA Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
[Bug middle-end/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #4 from trini at kernel dot crashing dot org 2006-06-01 18:36
---
(In reply to comment #3)
> Actually no, you have to use -fPIC to get this not to be optimized, otherwise
> func will be bound locally which is not what you want.
Two things. First, that's a change in behavior from how it used to work and I
don't recall seeing warnings about going-away behavior (the place this problem
is actually manifesting is in code for the Linux Kernel).
Second there is some sort of bug here as if we have:
$ cat file-a.c
void __attribute__((weak)) func(void)
{
printf("weak\n");
}
main()
{
func();
}
$ cat file-b.c
void func(void)
{
printf("func\n");
}
$ gcc-4.1 -c file-a.c file-b.c -O2
file-a.c: In function 'func':
file-a.c:3: warning: incompatible implicit declaration of built-in function
'printf'
file-b.c: In function 'func':
file-b.c:3: warning: incompatible implicit declaration of built-in function
'printf'
$ gcc-4.1 -o program file-a.o file-b.o
$ ./program
func
$ gcc-4.1 -o program file-a.o
$ ./program
weak
$ gcc-4.1 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.0 (Debian 4.1.0-1)
--
trini at kernel dot crashing dot org changed:
What|Removed |Added
CC||trini at kernel dot crashing
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #12 from whaley at cs dot utsa dot edu 2006-06-01 18:43 --- Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3 Uros, >gcc version 3.4.6 >vs. >gcc version 4.2.0 20060601 (experimental) > >-fomit-frame-pointer -O -msse2 -mfpmath=sse >There is a small performance drop on gcc-4.x, but nothing critical. >I can confirm, that code indeed runs >50% slower on 64bit athlon. Perhaps the >problem is in the order of instructions (Software Optimization Guide for AMD >Athlon 64, Section 10.2). The gcc-3.4 code looks similar to the example, how >things should be, and gcc-4.2 code looks similar to the example, how things >should _NOT_ be. Thanks for looking into this! However, I am indeed aware that by using SSE2 you can get the double precision results fairly close to the x87 on most platforms. In fact, you can get gcc 4.1-sse within a few % of gcc 3-x87 on the Athlon 64 as well, by changing the kernel you feed gcc, and giving it these flags: -march=athlon64 -O2 -mfpmath=sse -msse -msse2 -m64 \ -ftree-vectorize -fargument-noalias-global (this doesn't make it vectorize, but I throw the flag for future hope :) Now, sometimes you want to use the x87 unit because of its superior precision, but the real problem with the approach of "ignore the x87 performance and just use SSE" comes in single precision. The performance of the best kernel found by ATLAS in single precision using gcc4.1-sse is roughly half of that of using the x87 unit on an Athlon-64, and 80% on a P4e (one reason they are closer on the P4e is that the P4e's x87 peak is 1/2 that of the Athlon [AMD machines can do 2 flops/cycle using the x87, whereas intel machines can do only 1]), so there's not as large a gap between excellent and non-so-excellent kernels). My guess (and it's only a guess) for the reason scalar double-precision sse can compete and single cannot comes down to the cost of doing scalar load and stores. In double, you can use movlpd instead of movsd for a low-overhead vector load, but in single you must use movss, and since movss is much more expensive than fld, scalar SSE always blows in comparison to x87 . . . So, that's why my error report concentrated on "x87 performance". I submitted in double precision because I had a preexisting Makefile/source demonstrating the performance problem from a prior bug report (bugzilla 4991). I think we should not blow off the x87 performance even if SSE *was* competitive, because there are times when the x87 is better. However, in single precision, scalar SSE is not competitive, at least on the platforms I have tried. If you guys are planning on deprecating the x87 unit when SSE is competitive on modern machines, I can certainly rework the tarfile so I can send you single precision benchmark, so you can see the sse/x87 performance gap yourself. Let me know if you want this, as I'll need to do a bit of extra work. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/27866] New: Warn when casting, e.g. assigning a double precision to a real
In the following program there is clearly a problem with the "r = d" assignment. In most real programs such drastic case does not happen. However, simple precision loss or worse things may occure. gfortran -Wall should warn, but it does not deserve a default warning. program test double precision :: d real :: r d = 4d99 r = d print *, d, r end program test g95 -Wall shows: r = d 1 Warning (140): Implicit conversion at (1) may cause precision loss -- Summary: Warn when casting, e.g. assigning a double precision to a real Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27866
[Bug libstdc++/27867] New: compile error in repeated application of valarray<>::operator==
| Hello, | | I found some unexpected behavior in valarray, couldn't find anything | previous referencing it, and I thought that I'd write before | (erroneously??) submitting a bug. | | Simple case: repeated application of operator== | | Silly example: | | std::valarray v1(100,1); | std::valarray v2(100,1); | std::valarray v3(100,true); | | std::valarray res; | | res = ((v1 == v2) == v3); | | | This returns a compile error. | | | test.cc: In function `int main()': | test.cc:16: error: no match for 'operator==' in 'std::operator== [with _Tp | = int](((const std::valarray&)((const std::valarray*)(& v1))), | ((const std::valarray&)((const std::valarray*)(& v2 == v1' | /usr/include/gcc/darwin/4.0/c++/bits/valarray_after.h:394: note: | candidates are: std::_Expr, typename | std::__fun::result_type> | std::operator==(const std::_Expr<_Dom1, typename _Dom1::value_type>&, | const std::valarray&) [with _Dom = | std::_BinClos] | /usr/include/gcc/darwin/4.0/c++/bits/valarray_after.h:394: note: | std::_Expr, typename std::__fun::result_type> std::operator==(const | std::_Expr<_Dom1, typename _Dom1::value_type>&, const typename | _Dom::value_type&) [with _Dom = std::_BinClos] | | | This seems to happen regardless of the type of v3 BTW. Hmm, that must be a bug; please could you fill a PR in the GCC bugzilla database http://gcc.gnu.org/bugzilla/ and put me ([EMAIL PROTECTED]) in the CC:, and assign it to me? Thanks! -- Gaby -- Summary: compile error in repeated application of valarray<>::operator== Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tegtmeye at eecis dot udel dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27867
[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-06-01 19:13 --- (In reply to comment #3) > This is now fixed on mainline provided the user specifies -ffast-math. > There are some complications where imagpart(z*~z) can be non-zero, if > imagpart(z) is non-finite, such as an Inf or a NaN. It's unclear from > the fortran-95 standard whether gfortran is allowed to optimize this > even without -ffast-math. I'll ask con comp.lang.fortran :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23452
[Bug bootstrap/27794] stack explosion
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-06-01 19:14 --- azuma% grep maxssiz /stand/system tunable maxssiz 16777216 azuma% swapinfo Kb Kb Kb PCT START/ Kb TYPE AVAILUSEDFREE USED LIMIT RESERVE PRI NAME dev 4194304 83860 41104442% 0 -1 /dev/vg00/lvol2 reserve - 173972 -173972 memory 2085688 1108444 977244 53% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug fortran/15502] [meta-bug] bugs needed for SPEC CPU 2K and 2K6 and 95
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-01 19:19 --- I think that this one can be declared well and truly gone for the time being. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-06-01 19:24 --- Subject: Bug 27715 Author: tkoenig Date: Thu Jun 1 19:23:56 2006 New Revision: 114317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114317 Log: 2006-06-01 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/27715 * arith.c: Cast the characters from the strings to unsigned char to avoid values less than 0 for extended ASCII. 2006-06-01 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/27715 * gfortran.dg/extended_char_comparison_1.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/extended_char_comparison_1.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug libgcj/27860] build failure on m68k: error: 'ffi_closure' does not name a type
--- Comment #2 from tbm at cyrius dot com 2006-06-01 20:01 --- I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed that the part of the code that produces the error is within an ifdef USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But maybe the real fix would be to update ffi on m68k or something. Maybe Andreas can take a look and/or comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27860
Re: @dircategory Software development
On Mon, 29 May 2006, Karl Berry wrote: > rms asked me to try systematize the Texinfo dir categories to match the > Free Software Directory where possible. So I hope you will be ok > with changing the gcc manuals to say > @dircategory Software development > instead of > @dircategory Programming > (and "Software libraries" instead of "GNU libraries" for libiberty.) > > A patch is appended. I left the "GNU Ada Tools" manuals alone > (gnat_rm.texi and gnat_ugn.texi), since it wasn't immediately clear to > me why they were categorized differently than the rest. Whatever you > think best. Please submit a patch against SVN trunk to [EMAIL PROTECTED] with ChangeLog entries for each relevant ChangeLog. (As a doc fix it can be applied to release branches as well as trunk, and the same patch might apply to both, but we need to fix trunk first.) http://gcc.gnu.org/contribute.html -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-01 21:09 --- (In reply to comment #0) > In the following program there is clearly a problem with the "r = d" > assignment. In most real programs such drastic case does not happen. However, > simple precision loss or worse things may occure. > > gfortran -Wall should warn, but it does not deserve a default warning. There is -Wconversion, but this also warns the wrong way around. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27866
[Bug fortran/27868] New: Array reference out of bounds check should state file/line number or should at least crash
It is really helpful to have a program which stops with Fortran runtime error: Array reference out of bounds when compiled with -fbounds-check. Because one has no idea where this happens. Expected: At least crash so that one can do a backtrace in the debugger. Or write out the file/line number/variable name ... (Sorry for being sarcastic. The program runs ok with all checks turned on in the ifort 9.1, but crashes very early with gfortran 4.1 [glibc reports a double free].) -- Summary: Array reference out of bounds check should state file/line number or should at least crash Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30 --- Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be removed as well. I'm currenly testing a patch to that effect ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug fortran/27868] Array reference out of bounds check should state file/line number or should at least crash
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 21:30 --- Why not use gdb? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-01 21:31 --- Thanks for taking care of this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-01 21:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug libstdc++/27867] compile error in repeated application of valarray<>::operator==
--- Comment #1 from pcarlini at suse dot de 2006-06-01 21:37 ---
Gaby, I had a quick look and maybe it's just a trivial typo: the below seems
right to me and certainly fixes the testcase without regressions... What do you
think?
Thanks, Paolo.
//
Index: include/bits/valarray_before.h
===
--- include/bits/valarray_before.h (revision 114214)
+++ include/bits/valarray_before.h (working copy)
@@ -589,7 +589,7 @@
: _BinBase<_Oper, valarray<_Tp>, valarray<_Tp> >
{
typedef _BinBase<_Oper, valarray<_Tp>, valarray<_Tp> > _Base;
- typedef _Tp value_type;
+ typedef typename _Base::value_type value_type;
_BinClos(const valarray<_Tp>& __v, const valarray<_Tp>& __w)
: _Base(__v, __w) {}
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27867
[Bug target/27077] [x86, 4.1] builtin strlen poor performance
--- Comment #3 from christophe dot jaillet at wanadoo dot fr 2006-06-01 21:37 --- On my AMD Athlon and current HEAD and, I have other results, i.e. 2 or 3 times FASTER : (using your 19 bytes long 'aaa..' string) stringfrom lengthbuiltin library (-O2) (-fno-builtin -O2) 190.4841.172 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27077
[Bug fortran/27868] Array reference out of bounds check should state file/line number or should at least crash
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-01 21:41 --- > Why not use gdb? I don't see how gdb helps pinpointing the array-out-of-bound problem. As said: the program ends with Fortran runtime error: Array reference out of bounds Program exited with code 02. but it does not crash. Thus there is no backtrace available to pinpoint the problem. If you mean for the double-free: It crashes at a deallocate() which looks rather innocent (as does the whole file). My feeling is that something gets corrupted duing a subroutine call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #15 from geoffk at gcc dot gnu dot org 2006-06-01 21:49 --- After discussion with Mike, I don't think Andrew's fix is right either. If varasm.c wants to be able to predict memory layout, then what it needs to do is ensure that the memory layout is seen as a single unit by the linker. This can only be done by ensuring that the layout contains no linker-visible labels, that is all the labels inside the layout must start with 'L'. If this is done, then the linker is not involved and zero-sized objects can be zero sized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug fortran/27868] Array reference out of bounds check should state file/line number or should at least crash
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 --- You set your break point on exit in gdb and run your program and then you get the backtrace and look where the problem comes from, There is no magic going on with -fbounds-check Anyways this is a dup of bug 23375. *** This bug has been marked as a duplicate of 23375 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
[Bug fortran/23375] show location for runtime errors
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 --- *** Bug 27868 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #22 from wilson at gcc dot gnu dot org 2006-06-01 22:36 --- Subject: Bug 26483 Author: wilson Date: Thu Jun 1 22:36:19 2006 New Revision: 114319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114319 Log: Fix broken denorm support. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: branches/gcc-4_1-branch/libffi/ChangeLog branches/gcc-4_1-branch/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libmudflap/26120] mudflap behavior changes with trivial changes to build command
--- Comment #6 from idht4n at hotmail dot com 2006-06-01 23:03 --- Still behaves the same in 4.1.1 20060525 (Red Hat 4.1.1-1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug c/27869] New: "-O -fregmove" handles SSE scalar instructions incorrectly
Consider the following C program using SSE intrinsics:
//--
#include
#include
int main(int argc, const char **argv) {
__m128 v;
v = _mm_setr_ps( 1.0f, 2.0f, 3.0f, 4.0f );
v = _mm_rsqrt_ss( v );
v = _mm_add_ss( v, _mm_movehl_ps( v, v ));
v = _mm_add_ss( v, _mm_shuffle_ps( v, v, _MM_SHUFFLE( 0, 0, 0, 1 )));
printf( "%e %e %e %e\n", ((float *)&v)[0], ((float *)&v)[1], ((float
*)&v)[2], ((float *)&v)[3] );
return 0;
}
//--
Compiling and running this gives different results depending on whether
-fregmove is specified or not.
[EMAIL PROTECTED] regmove% gcc41 -Wall -O -fno-regmove -march=pentium4m -o test
main.c
[EMAIL PROTECTED] regmove% ./test
5.999756e+00 2.00e+00 3.00e+00 4.00e+00
[EMAIL PROTECTED] regmove% gcc41 -Wall -O -fregmove -march=pentium4m -o test
main.c
[EMAIL PROTECTED] regmove% ./test
7.999756e+00 4.00e+00 3.00e+00 4.00e+00
The first case (-fno-regmove) is the correct one.
When you take a look at the assembly output for both cases the problem is with
an "addss %xmm1, %xmm0" that is changed to "addss %xmm0, %xmm1". This is
incorrect. The addss instruction is not commutative (unlike addps which sums
over the entire vector).
The same problem occurs with _mm_add_ss in the code above replaced by
_mm_mul_ss (mulss instruction), but not with _mm_sub_ss for instance
(obviously), so I suppose this can be fixed by handling addss and mulss the
same way as subss.
I suppose other instructions could be affected too.
--
Summary: "-O -fregmove" handles SSE scalar instructions
incorrectly
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tijl at ulyssis dot org
GCC build triplet: i386-portbld-freebsd6.1
GCC host triplet: i386-portbld-freebsd6.1
GCC target triplet: i386-portbld-freebsd6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Comment #57 from jvdelisle at gcc dot gnu dot org 2006-06-02 00:17 --- Closing. I have regular testing on my list. Last I checked the gcc farm did not have daily gcc builds going yet. I was keying off that because I did not want to do my own builds on the garm. I will keep at it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-02 00:48 ---
(define_insn "sse_vmaddv4sf3"
[(set (match_operand:V4SF 0 "register_operand" "=x")
(vec_merge:V4SF
(plus:V4SF (match_operand:V4SF 1 "nonimmediate_operand" "%0")
(match_operand:V4SF 2 "nonimmediate_operand" "xm"))
(match_dup 1)
(const_int 1)))]
"TARGET_SSE && ix86_binary_operator_ok (PLUS, V4SFmode, operands)"
"addss\t{%2, %0|%0, %2}"
[(set_attr "type" "sseadd")
(set_attr "mode" "SF")])
The % is incorrect here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i386-portbld-freebsd6.1 |
GCC host triplet|i386-portbld-freebsd6.1 |
GCC target triplet|i386-portbld-freebsd6.1 |i?86-*-*
Keywords||ssemmx, wrong-code
Last reconfirmed|-00-00 00:00:00 |2006-06-02 00:48:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug libmudflap/26120] mudflap behavior changes with trivial changes to build command
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-02 02:12 --- g++f4 -o hello hello.o -lmudflap You need both -fmudlfap and -lmudflap when linking. This is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug libstdc++/27867] compile error in repeated application of valarray<>::operator==
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:21 --- Confirmed on both GDR saying this is a bug and Paolo providing a patch to fix this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-02 02:21:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27867
[Bug libgcj/27860] [4.2 Regression] build failure on m68k: error: 'ffi_closure' does not name a type
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 02:25 --- (In reply to comment #2) > I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed > that the part of the code that produces the error is within an ifdef > USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But > maybe the real fix would be to update ffi on m68k or something. Maybe Andreas > can take a look and/or comment. libffi should work on m68k. It might be closures have not been ported to m68k which means INTERPRETER should be false. (This is all from memory). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||java-prs at gcc dot gnu dot ||org Summary|build failure on m68k: |[4.2 Regression] build |error: 'ffi_closure' does |failure on m68k: error: |not name a type |'ffi_closure' does not name ||a type Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27860
[Bug libgcj/27860] build failure on m68k: error: 'ffi_closure' does not name a type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regression] build |build failure on m68k: |failure on m68k: error: |error: 'ffi_closure' does |'ffi_closure' does not name |not name a type |a type | Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27860
[Bug c++/27820] [4.0/4.1/4.2 regression] ICE with duplicate label
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:32 --- The C front-end does not add the duplicated label to the IR while the C++ front-end does. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27820
[Bug c++/27820] [4.0/4.1/4.2 regression] ICE with duplicate label
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 02:35 ---
if (DECL_INITIAL (decl) != NULL_TREE)
error ("duplicate label %qD", decl);
else
Maybe adding into the if condition:
POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, error_mark_node);
This might work but I have not tested it at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27820
[Bug c++/27870] New: ICE in build_outer_var_ref, at omp-low.c:585 with openmp
An orphaned for loop with a reduction clause causes an ICE. Note that the non-orphaned for loop doesn't. g++ -v: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc_svn/configure --enable-languages=c,c++ --prefix=/local_scratch/owe043/gcc_svn Thread model: posix gcc version 4.2.0 20060601 (experimental) compiled with: g++ -save-temps -c -fopenmp foo.cc -- Summary: ICE in build_outer_var_ref, at omp-low.c:585 with openmp Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bowie dot owens at csiro dot au GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27870
[Bug c++/27870] ICE in build_outer_var_ref, at omp-low.c:585 with openmp
--- Comment #1 from bowie dot owens at csiro dot au 2006-06-02 02:41 --- Created an attachment (id=11575) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11575&action=view) pre-processed c++ code that triggers the ICE Compiling I get the following: foo.cc: In function 'void mat_product(mat_c_t&, const mat_a_t&, const mat_b_t&, size_t, size_t, size_t) [with mat_c_t = double**, mat_a_t = double**, mat_b_t = double**]': foo.cc:15: internal compiler error: in build_outer_var_ref, at omp-low.c:585 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27870
[Bug middle-end/27870] ICE in build_outer_var_ref, at omp-low.c:585 with openmp
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:54 ---
Confirmed, reduced testcase:
void mat_product(double **const b, unsigned m)
{
int j;
double cik = 0;
#pragma omp for reduction(+: cik)
for (j = 0; j < m; ++j)
;
}
So the reduction in general is causing it.
This happens with the both C and C++ front-ends.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-02 02:54:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27870
[Bug middle-end/27870] ICE in build_outer_var_ref, at omp-low.c:585 with openmp
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 03:01 --- Note I might have reduced this testcase too much as I remove the reference to cik from the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27870
