[Bug target/24230] [4.1 Regression] [altivec] ICE in extract_insn, at recog.c:2084
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-10-07 07:19 --- I'm looking at it. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug c++/24052] [3.4/4.0/4.1 Regression] &#`label_decl' not supported by dump_expr#
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-10-07 07:21 --- Created an attachment (id=9916) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9916&action=view) another patch Similar to the previous patch, but also prints && correctly for ADDR_EXPR of a LABEL_DECL. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Attachment #9803 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24052
[Bug driver/19848] "options passed" from -verbose-asm do not adequately reflect optimization
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-10-07 07:30 --- Thomas, perhaps we could divide and conquer. We could manually eliminate each of the 204 optimzations one at a time until the breakage disappears. Maybe we develop a script to locate those, bubblestrap, test, remove, and go on to the next until its discovered. I know its a pain, but it could be done. If not a script, then get several volunteers and assign them out to check. It would be nice to claim a final victory on this. Any thoughts anyone -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug c++/24139] [4.0/4.1 Regression] Rejects definition of member of specialized inner class
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24139
[Bug java/24251] New: Segmentation fault using org.w3c.dom.
Hi! As discussed on the mailing list ( http://gcc.gnu.org/ml/java/2005-10/msg00025.html ), there is a segmentation fault problem using org.w3c.dom.* packages. Verified on debian SID (me, gcj version 4.0.2) and on FC3 (David Daney, CVS head) using the small test program what was wirtten to demonstrate the segfault. Here is the test program: http://khiraly.4242.hu/tmp/saxsux/SaxSux.java http://khiraly.4242.hu/tmp/saxsux/config.xml Quick quide: [EMAIL PROTECTED]:~/saxsux$ javac SaxSux.java [EMAIL PROTECTED]:~/saxsux$ java SaxSux config.xml Teszt true [EMAIL PROTECTED]:~/saxsux$ gcj-4.0 --main=SaxSux SaxSux.java [EMAIL PROTECTED]:~/saxsux$ ./a.out config.xml Aborted [EMAIL PROTECTED]:~/saxsux$ gdb output (CVS HEAD): #0 0xb7fe8402 in __kernel_vsyscall () #1 0x00b887d5 in raise () from /lib/tls/libc.so.6 #2 0x00b8a149 in abort () from /lib/tls/libc.so.6 #3 0xb74f81c7 in _Jv_Throw (value=0x17b7b0) at ../../../gcccvsmain/gcc/libjava/exception.cc:111 #4 0xb74ec0ea in catch_segv (_dummy=Could not find the frame base for "catch_segv". ) at ../../../gcccvsmain/gcc/libjava/prims.cc:152 #5 #6 0x0804a508 in org::w3c::dom::Node::class$ () #7 0x08049340 in SaxSux.getStringElement(java.lang.String) () #8 0x0804906e in SaxSux.main(java.lang.String[]) () #9 0xb75189d3 in gnu::java::lang::MainThread::call_main (this=0x62f18) at ../../../gcccvsmain/gcc/libjava/gnu/java/lang/natMainThread.cc:47 #10 0xb7559a07 in gnu.java.lang.MainThread.run() (this=0x62f18) at MainThread.java:105 #11 0xb75277eb in _Jv_ThreadRun (thread=0x62f18) at ../../../gcccvsmain/gcc/libjava/java/lang/natThread.cc:299 #12 0xb74ed03d in _Jv_RunMain (vm_args=0x0, klass=0x804a2c0, name=0x0, argc=2, argv=0xbf8e5bd4, is_jar=false) at ../../../gcccvsmain/gcc/libjava/prims.cc:1386 #13 0xb74ed1a2 in _Jv_RunMain (klass=0x804a2c0, name=0x0, argc=2, argv=0xbf8e5bd4, is_jar=false) at ../../../gcccvsmain/gcc/libjava/prims.cc:1397 #14 0xb74ed1e7 in JvRunMain (klass=0x804a2c0, argc=2, argv=0xbf8e5bd4) at ../../../gcccvsmain/gcc/libjava/prims.cc:1403 #15 0x08048fc4 in main () Best regards, Khiraly -- Summary: Segmentation fault using org.w3c.dom. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: khiraly123 at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24251
[Bug java/24251] Segmentation fault using org.w3c.dom.
--- Comment #1 from khiraly123 at gmx dot net 2005-10-07 08:36 --- Created an attachment (id=9917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9917&action=view) Testcase, java source file Exactly the same file, what is available on: http://khiraly.4242.hu/tmp/saxsux/SaxSux.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24251
[Bug java/24251] Segmentation fault using org.w3c.dom.
--- Comment #2 from khiraly123 at gmx dot net 2005-10-07 08:37 --- Created an attachment (id=9918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9918&action=view) XML file, what the java program use Exactly the same file, what is available on: http://khiraly.4242.hu/tmp/saxsux/config.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24251
[Bug tree-optimization/24172] [4.1 Regression] error: incorrect sharing of tree nodes
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-10-07 09:05 --- Honza, I'm stuck with rth's comment that there may be still sharing bugs even after making fold_indirect_ref_1 fold the offending statement. And as you noted, calling copy_body_r on the folded or unfolded tree causes either nice recursion or the assert at tree-inline.c:665 to trigger. So can you try either convince rth that just doing better folding is safe or try your unshare_expr idea? Thx, Richard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|rguenth at gcc dot gnu dot |hubicka at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24172
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Comment #48 from cvs-commit at gcc dot gnu dot org 2005-10-07 10:54 --- Subject: Bug 15855 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-07 10:54:10 Modified files: gcc/cp : ChangeLog decl2.c Log message: 2005-10-07 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline 2005-09-26 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/15855 * decl2.c (do_static_destruction): Remove. (finish_static_initialization_or_destruction): Likewise. (DECL_EFFECTIVE_INIT_PRIORITY): New macro. (NEEDS_GUARD_P): Likewise. (do_static_initialization): Rename to do_static_initialization_or_destruction. Process all initializers/destructors and handle common conditionalizing. (start_static_initialization_or_destruction): Rename to one_static_initialization_or_destruction. Handle only decl-specific conditionalizing. (cp_finish_file): Call do_static_initialization_or_destruction. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.118&r2=1.4648.2.119 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.770.2.9&r2=1.770.2.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug testsuite/19231] Execute failure in gcc.c-torture/execute/builtins/strlen-3.c with -fpic/-fPIC
--- Comment #2 from jkj at sco dot com 2005-10-07 10:57 --- (In reply to comment #1) > Because bar is not static to the TU, we can override it in a different one > which causes use not to > optimizate it out, try adding static infront of bar, baz, and larger. > > So this is a testcase problem. So is putting static in front of those variables the actual fix? Does it still test what it thinks its testing? Or should this test be ignored in -fPIC mode? -- jkj at sco dot com changed: What|Removed |Added CC||jkj at sco dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19231
[Bug c/24252] New: Missing "warning: control reaches end of non-void function" in static function
// gcc 3.4.5 and 4.0.2 produce warning output
#define STATIC
// no warning
#define STATIC static
STATIC int foo(void)
{
int i = 47;
i++;
}
int bar(void)
{
if (foo()) return 1;
return 0;
}
--
Summary: Missing "warning: control reaches end of non-void
function" in static function
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ch12 at os dot inf dot tu-dresden dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24252
[Bug middle-end/24252] [3.4/4.0/4.1 Regression] Missing "warning: control reaches end of non-void function" in static function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:12 --- Fixed in 4.1.0 by change a lot of the middle-end so the patch will not be backported, so closing as fixed. There is most likely a dup of this bug somewhere. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Keywords||diagnostic Known to fail||3.4.0 4.0.0 Known to work||3.3.3 4.1.0 Resolution||FIXED Summary|Missing "warning: control |[3.4/4.0/4.1 Regression] |reaches end of non-void |Missing "warning: control |function" in static function|reaches end of non-void ||function" in static function Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24252
[Bug c/24253] New: parse error expected at empty struct declaration
when declaring an empty struct like
struct {};
there should be a parse error when compiling with -std=c99, since there seem to
be no grammar rule in the c-standard[1] which allows the empty curled braces in
a struct declaration.
visual studio 2003 and the edg parser report this as a parse error.
[1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
--
Summary: parse error expected at empty struct declaration
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander dot floh at fh-hagenberg dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24253
[Bug c/24253] parse error expected at empty struct declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:16 --- Using -std=c99 -pedantic-errors: earth:~>gcc t.c -std=c99 -pedantic-errors t.c:1: error: struct has no members t.c:1: error: unnamed struct/union that defines no instances earth:~>~/ia32_linux_gcc3_4/bin/gcc t.c -std=c99 -pedantic-errors t.c:1: error: struct has no members t.c:1: error: unnamed struct/union that defines no instances earth:~>~/ia32_linux_gcc3_0/bin/gcc t.c -std=c99 -pedantic-errors t.c:1: struct has no members t.c:1: unnamed struct/union that defines no instances So this is invalid. -- 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=24253
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Comment #49 from rguenth at gcc dot gnu dot org 2005-10-07 11:17 --- So trying to get some updated comparison I noticed that the testcase fails to compile with 3.3.x and compared to 3.4.x we have improved a lot wrt -O2 compile-time: 3.4: 1m32s, peak at 230MB 4.1:48s, peak at 480MB Still we are using too much memory. Time-report for 4.1 does no longer show obvious problems: Execution times (seconds) garbage collection: 0.50 ( 1%) usr 0.00 ( 0%) sys 0.50 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.17 ( 0%) usr 0.01 ( 0%) sys 0.19 ( 0%) wall 1898 kB ( 0%) ggc callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 422 kB ( 0%) ggc ipa reference : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 97 kB ( 0%) ggc ipa pure const: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa type escape : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc cfg construction : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 589 kB ( 0%) ggc cfg cleanup : 0.26 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall 511 kB ( 0%) ggc trivially dead code : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall 0 kB ( 0%) ggc life analysis : 1.43 ( 3%) usr 0.00 ( 0%) sys 1.41 ( 3%) wall 91 kB ( 0%) ggc life info update : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 11 kB ( 0%) ggc alias analysis: 0.19 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 3249 kB ( 1%) ggc register scan : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall 49 kB ( 0%) ggc rebuild jump labels : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.52 ( 1%) usr 0.29 (11%) sys 0.78 ( 1%) wall 732 kB ( 0%) ggc parser: 3.27 ( 7%) usr 0.42 (15%) sys 3.84 ( 7%) wall 121022 kB (21%) ggc name lookup : 0.65 ( 1%) usr 0.48 (18%) sys 1.15 ( 2%) wall 9424 kB ( 2%) ggc inline heuristics : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 1163 kB ( 0%) ggc integration : 0.90 ( 2%) usr 0.02 ( 1%) sys 0.93 ( 2%) wall 46704 kB ( 8%) ggc tree gimplify : 0.41 ( 1%) usr 0.01 ( 0%) sys 0.47 ( 1%) wall 7205 kB ( 1%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1725 kB ( 0%) ggc tree CFG construction : 0.04 ( 0%) usr 0.03 ( 1%) sys 0.06 ( 0%) wall 5236 kB ( 1%) ggc tree CFG cleanup : 0.25 ( 1%) usr 0.02 ( 1%) sys 0.29 ( 1%) wall 332 kB ( 0%) ggc tree VRP : 0.37 ( 1%) usr 0.05 ( 2%) sys 0.44 ( 1%) wall 2375 kB ( 0%) ggc tree copy propagation : 1.22 ( 2%) usr 0.23 ( 8%) sys 1.43 ( 3%) wall 997 kB ( 0%) ggc tree store copy prop : 0.09 ( 0%) usr 0.06 ( 2%) sys 0.16 ( 0%) wall 202 kB ( 0%) ggc tree find ref. vars : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 6215 kB ( 1%) ggc tree PTA : 1.80 ( 4%) usr 0.03 ( 1%) sys 1.88 ( 4%) wall 4061 kB ( 1%) ggc tree alias analysis : 3.18 ( 6%) usr 0.08 ( 3%) sys 3.40 ( 6%) wall 5523 kB ( 1%) ggc tree PHI insertion: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 459 kB ( 0%) ggc tree SSA rewrite : 1.80 ( 4%) usr 0.14 ( 5%) sys 2.00 ( 4%) wall 120115 kB (21%) ggc tree SSA other: 0.17 ( 0%) usr 0.03 ( 1%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 4.90 (10%) usr 0.05 ( 2%) sys 4.86 ( 9%) wall 5152 kB ( 1%) ggc tree operand scan : 3.98 ( 8%) usr 0.29 (11%) sys 4.21 ( 8%) wall 58117 kB (10%) ggc dominator optimization: 1.70 ( 3%) usr 0.04 ( 1%) sys 1.81 ( 3%) wall 100326 kB (17%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 17 kB ( 0%) ggc tree STORE-CCP: 0.15 ( 0%) usr 0.02 ( 1%) sys 0.11 ( 0%) wall 193 kB ( 0%) ggc tree CCP : 0.54 ( 1%) usr 0.03 ( 1%) sys 0.56 ( 1%) wall 923 kB ( 0%) ggc tree split crit edges : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 820 kB ( 0%) ggc tree reassociation: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree PRE : 0.34 ( 1%) usr 0.00 ( 0%) sys 0.30 ( 1%) wall 2854 kB ( 0%) ggc tree FRE : 0.32 ( 1%) usr 0.03 ( 1%) sys 0.33 ( 1%) wall 3726 kB ( 1%) ggc tree code sinking : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 78 kB ( 0%) ggc tree linearize phis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 63 kB ( 0%) ggc tree forward propagate: 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 1127 kB ( 0%) ggc tree conservative DCE : 0.49 ( 1%) usr 0.00 ( 0%) sys 0.52 ( 1%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.07 ( 0%) usr 0.00 ( 0%) sys 0
[Bug c/24254] New: parse error expected at empty struct declaration
when declaring an empty struct like
struct {};
there should be a parse error when compiling with -std=c99, since there seem to
be no grammar rule in the c-standard[1] which allows the empty curled braces in
a struct declaration.
visual studio 2003 and the edg parser report this as a parse error.
[1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
--
Summary: parse error expected at empty struct declaration
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander dot floh at fh-hagenberg dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24254
[Bug c/24253] parse error expected at empty struct declaration
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 11:28 --- *** Bug 24254 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24253
[Bug c/24254] parse error expected at empty struct declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:28 --- *** This bug has been marked as a duplicate of 24253 *** -- 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=24254
[Bug target/24255] New: [4.1 regression] __transparent_union__ mishandled
Instead of passing the pointer to the variable itself a pointer to a temporary
holding the address of the variable is used.
$ cat wait.c
typedef union
{
union wait *__uptr;
int *__iptr;
} __WAIT_STATUS __attribute__ ((__transparent_union__));
union wait
{
int w_status;
};
int wait (__WAIT_STATUS __status_loc);
int do_wait (void) { int status; wait (&status); return status; }
$ gcc -O2 -S -fverbose-asm wait.c
$ cat wait.s
.file "wait.c"
# rs6000/powerpc options: -msdata=data -G 8
# GNU C version 4.1.0 20051001 (experimental) (SUSE Linux)
(powerpc64-suse-linux)
# compiled by GNU C version 4.1.0 20051001 (experimental) (SUSE Linux).
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: -iprefix -isystem -D__unix__ -D__gnu_linux__
# -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
# -Asystem=unix -Asystem=posix -auxbase -O2 -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-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 -fpeephole -fpeephole2 -freg-struct-return
# -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
# -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2
# -fshow-column -fsplit-ivs-in-unroller -fstrength-reduce
# -fstrict-aliasing -fthread-jumps -ftrapping-math -ftree-ccp -ftree-ch
# -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-pre -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 -maix-struct-return -mbig -mbig-endian
# -mbss-plt -mfp-in-toc -mfused-madd -mhard-float -mnew-mnemonics
# -mpowerpc -msched-prolog -mupdate
# Compiler executable checksum: 98247ca61e462f7c754c17f0242fef41
.section".text"
.align 2
.p2align 4,,15
.globl do_wait
.type do_wait, @function
do_wait:
mflr 0 #,
stwu 1,-32(1)#,,
stw 0,36(1) #,
addi 3,1,24 #,,
addi 0,1,8 # status.1,,
stw 0,24(1) #, status.1
bl wait #
lwz 0,36(1) #,
lwz 3,8(1) # status,
addi 1,1,32 #,,
mtlr 0 #,
blr #
.size do_wait,.-do_wait
.ident "GCC: (GNU) 4.1.0 20051001 (experimental) (SUSE Linux)"
.section.note.GNU-stack,"",@progbits
--
Summary: [4.1 regression] __transparent_union__ mishandled
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24255
[Bug fortran/23151] print (buf, format), expression should be invalid
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-07 11:45:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23151
[Bug target/24255] [4.1 regression] __transparent_union__ mishandled
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:45 --- Hmm, unions are passed by reference in powerpc-linux, unless that is also an ABI regression too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24255
[Bug target/24255] [4.1 regression] __transparent_union__ mishandled
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 12:06 --- Confirmed, this is a ABI regression. -- 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 |2005-10-07 12:06:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24255
[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails
--- Comment #13 from ptsekov at gmx dot net 2005-10-07 12:13 --- Both the simple testcase and the program I am working on work fine with your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
[Bug middle-end/24227] [4.1 Regression] ICE in compare_values, at tree-vrp.c:415
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-07 12:45 --- In fold_binary (fold-const.c:7122) we fold op0 == (x, op1) to (x, op0 == op1) but in creation of the new EQ_EXPR we use trees which have NOPs stripped, so we end up with a pointer and an integer type for the comparison. I have a fix which fold_converts one type to the other. Richard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-06 13:22:47 |2005-10-07 12:45:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24227
[Bug middle-end/24255] [4.1 regression] __transparent_union__ mishandled
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-07 13:05 ---
Debugging this, it looks a middle-end bug, in that we get the wrong type.
The type which we get now:
Breakpoint 5, function_arg (cum=0xb020, mode=SImode, type=0x1c97900,
named=1) at ../../gcc/config/rs6000/rs6000.c:4940
4940 enum rs6000_abi abi = DEFAULT_ABI;
(gdb) p debug_tree(type)
unit size
align 32 symtab 0 alias set 4
fields
unsigned SI file t.c line 3 size unit
size
align 32 offset_align 128
offset
bit offset context
chain > context
pointer_to_this chain >
unsigned SI size unit size
align 32 symtab 0 alias set -1>
(gdb) p debug_generic_expr (type)
union
{
union wait * __uptrD.1289;
intD.0 * __iptrD.1290;
} *
The type we got in 4.0.x:
(gdb) p debug_tree(type)
unit size
align 32 symtab 0 alias set -1
fields
SI file t.c line 8 size unit size
align 32 offset_align 128
offset
bit offset context
arguments > context
pointer_to_this chain >
unsigned SI size unit size
align 32 symtab 0 alias set -1>
$1 = void
(gdb) p debug_generic_expr(type)
union wait *
This what we get in function_arg.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24255
[Bug middle-end/24255] [4.1 regression] __transparent_union__ mishandled
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-07 13:08 --- Caused by: 2005-09-24 Richard Henderson <[EMAIL PROTECTED]> ... * gimplify.c (create_tmp_from_val): Likewise. Confirmed caused by that patch by reverting it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24255
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #10 from stewart at neuron dot com 2005-10-07 13:49 --- (In reply to comment #9) > Yes, I'm sure. I know what's going on here. > This is the only bug I was able to find regarding AttachCurrentThread. I'm working on getting FUSE-J (Java bindings for FUSE userspace filesystem) working with GCJ and have run across an apparent bug with AttachCurrentThread/AttachCurrentThreadAsDaemon whereby the returned JNIEnv has a corrupted pointer to CallObjectMethod. I emailed the following to : You should be able to setup/reproduce this quickly. First is to get/build/install the fuse library: http://fuse.sourceforge.net/ http://easynews.dl.sourceforge.net/sourceforge/fuse/fuse-2.4.0.tar.gz ./configure --prefix=/usr/local && make && make install && depmod -a && modprobe fuse Second, get fuse-j, the java language bindings http://www.select-tech.si/fuse/ http://www.select-tech.si/fuse/fuse-j-2.2.3.tar.gz get and apply my patch for gcj: http://mrallen.com/misc/fuse-j-2.2.3-gcj.diff inside fuse-j-2.2.3: patch -p1 < path_to_patch then you will need a zip file to test and a mount point. next: make sh zipfs_gcj.sh once it's running, doing a 'df' in another term will crash cause the segfault. you will have to have /usr/local/bin in your PATH and execute 'fusermount -u ' to undo the mount. (In reply to comment #9) > Yes, I'm sure. I know what's going on here. > -- stewart at neuron dot com changed: What|Removed |Added CC||stewart at neuron dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug fortran/23884] failure in gcc
--- Comment #9 from segalemb at usp dot br 2005-10-07 13:57 --- (In reply to comment #8) I tried this simple test case: module param double precision mutdefc(8,5,7) data mutdefc(1,1,1) /0.d0/ * mutdefc(1,1,2) /0.d0/ end module param and the compilation go straight. Only when all indexes of mutdefc where equal, the error appears. This indicates that this is not a duplicate of bug 17737. > (In reply to comment #7) > > Note I reduced it using delta so the all of my reduced tescase came exactly > from the file and nothing > > else. > > This is not true. Even if the constants appearing in the data statements in > the > original code are replaced by their values, there will be no line that reads > data mutdefc(...,7) /.../ > as all initializations are of the form > data mutdefc(...,1) /.../ > * mutdefc(...,2) /.../ > ... > So you did more to the testcase. > > Given the error location, I'm inclined to believe that it is indeed a > duplicate, > but your reduced testcase doesn't prove it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23884
[Bug tree-optimization/23946] [4.1 regression] ICE: verify_ssa failed ("definition ... follows the use")
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-07 14:00 --- The one liner which fixes the problem (I am bootstrapping right now): Index: tree-ssa-ccp.c === RCS file: /cvs/gcc/gcc/gcc/tree-ssa-ccp.c,v retrieving revision 2.88 diff -u -p -r2.88 tree-ssa-ccp.c --- tree-ssa-ccp.c 29 Sep 2005 12:24:58 - 2.88 +++ tree-ssa-ccp.c 7 Oct 2005 14:00:13 - @@ -2460,7 +2460,7 @@ execute_fold_all_builtins (void) gcc_assert (ok); } } - update_stmt (*stmtp); + mark_new_vars_to_rename (*stmtp); if (maybe_clean_or_replace_eh_stmt (old_stmt, *stmtp) && tree_purge_dead_eh_edges (bb)) cfg_changed = true; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23946
[Bug rtl-optimization/15242] [3.4 regression] pessimization of "goto *"
--- Comment #34 from steven at gcc dot gnu dot org 2005-10-07 14:09 --- This is basically unfixable without serious hacking that is not appropriate for GCC 3.4, so Gaby, with your permission, I'd like to close this one as WONTFIX... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug target/23980] Bad assembly output in Thumb mode with -O2
--- Comment #4 from czimman at bloomberg dot com 2005-10-07 14:53 --- Created an attachment (id=9927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9927&action=view) mmcsd.s What happens is that a bogus label (.L622) gets created, and is treated as an unresolved symbol at link time. Please find mmcsd.s (arm-elf-objdump -D mmcsd.o) attached. If you still need the entire pre-processed source, I can attach that as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
[Bug rtl-optimization/24257] New: ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fgcse-sm
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v icefoo.c -dumpbase
icefoo.c -auxbase icefoo -O -version -fgcse -fgcse-sm -o icefoo.s
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129306
Compiler executable checksum: a278381769db4d67bad1ec630ceb45dd
icefoo.c: In function 'oof':
icefoo.c:23: error: unrecognizable insn:
(insn 47 15 19 0 (set (reg:SI 61)
(ashift:SI (mem/s/j:SI (reg/v/f:SI 59 [ s ]) [0 .buf+0 S4
A32])
(subreg:QI (reg/v:SI 60 [ n ]) 0))) -1 (nil)
(expr_list:REG_DEAD (reg/v:SI 60 [ n ])
(nil)))
icefoo.c:23: internal compiler error: in extract_insn, at recog.c:2084
Configured with: ../gcc/configure --prefix=/tmp/gcc41 --enable-languages=c
--disable-nls --enable-checking=assert,rtlflag,misc
typedef struct A {
int buf, left;
} A;
static void flush(A *s, int n)
{
s->buf <<= n;
while (s->left < 32) {
s->buf <<= 8;
s->left += 8;
}
s->buf=0;
}
void oof(A *s, int n)
{
s->buf = n;
s->left = n;
flush(s, n);
}
--
Summary: ICE: in extract_insn, at recog.c:2084 with -O -fgcse -
fgcse-sm
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ferdinandw+gcc at gmail dot com
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=24257
[Bug target/24257] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fgcse-sm
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 15:21 --- Confirmed, 4.0.0 worked. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||3.4.0 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-10-07 15:21:31 date|| Summary|ICE: in extract_insn, at|[4.1 Regression] ICE: in |recog.c:2084 with -O -fgcse |extract_insn, at |-fgcse-sm |recog.c:2084 with -O -fgcse ||-fgcse-sm Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug libgcj/24258] New: add flag to track shared library activity
It would often be convenient to see what libgcj is doing with shared libraries -- which get loaded, which don't, and why. We should add a gij flag like '-Xverbose:libraries' to do this. -- Summary: add flag to track shared library activity Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24258
[Bug target/23980] Bad assembly output in Thumb mode with -O2
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-10-07 15:51 --- Yes we need the preprocessed source code. Unless I can run the compiler under a debugger there's no chance of working out what's going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
[Bug target/23980] Bad assembly output in Thumb mode with -O2
--- Comment #6 from czimman at bloomberg dot com 2005-10-07 15:54 --- Created an attachment (id=9928) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9928&action=view) mmcsd.i This is the pre-processed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
[Bug target/23980] Bad assembly output in Thumb mode with -O2
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-07 15:57:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
[Bug c++/24260] New: stdcall attribute is ignored at static member template functions
GCC 4.0.0 / 4.0.2 seems to ignore the stdcall (and also fastcall)
attributes when used at static member template functions.
The generated code for the function is incorrect.
Also when taking the address of that function, the type is a pointer to
a "normal" function and not a pointer to a stdcall function. (See example
below). So it seems that the stdcall attribute is "lost" during parsing.
This problem only occurs when using a template function. A static stdcall
function without template works as expected.
#define stdcall __attribute__((stdcall))
struct T {
template
static int stdcall func(int arg1, int arg2);
};
// The generated assembly is incorrect. Function is not
// removing arguments, so this is clearly not "stdcall"
// ("ret" instruction at the end instead of "ret 0x8")
template
int stdcall T::func(int arg1, int arg2)
{
return arg1+arg2;
}
struct dummy {};
void xx()
{
int (*ptr)(int,int) = &T::func;// works (although
incorrect)
// int (stdcall *ptr2)(int,int) = &T::func; // generates error
(although correct)
}
--
Summary: stdcall attribute is ignored at static member template
functions
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ahangauer at gmx dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug target/24260] stdcall attribute is ignored at static member template functions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary
When running gfortran on a 64-bit AMD Athlon64 Linux machine, the
Fortran ALLOCATE statement does not align pointers on 16-byte boundaries.
This means that allocated memory cannot be passed to assembly language
routines that rely on 16-byte alignment (e.g. assembly language using
SSE instructions like "movaps").
The demonstration below involves two files, the first one
a Fortran program name try.f which allocates an array x.
It calls a C function, shown in file sub.c, which returns the
address of x, and prints a message saying whether or not the
array is 16-byte aligned.
% gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20050916/irun
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050916 (experimental)
% cat try.f
real, allocatable :: x(:)
integer*8 address, p, sixteen
external address
sixteen = 16
allocate (x(30))
p = address(x)
write (*,99) 'Address of x = ', p
99 format (1x,a,'0x',z16.16)
if (mod(p,sixteen) .eq. 0) then
write (*,*) 'x is aligned on a 16-byte boundary'
else
write (*,*) 'x is not aligned on a 16-byte boundary'
end if
end
% cat sub.c
unsigned long address_(void *x)
{
return (unsigned long)x;
}
% gfortran try.f sub.c
% ./a.out
Address of x = 0x2B1CB028
x is not aligned on a 16-byte boundary
--
Summary: gfortran ALLOCATE statement does not align objects on
16-byte boundary
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mick at nag dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
[Bug c++/24260] [4.0/4.1 Regression] stdcall attribute is ignored at static member template functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 16:55 --- Confirmed, a C++ bug with templates and attributes. a regression from 3.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |c++ Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 |i?86-*-*, x86_64-*-* Keywords||rejects-valid Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-10-07 16:55:56 date|| Summary|stdcall attribute is ignored|[4.0/4.1 Regression] stdcall |at static member template |attribute is ignored at |functions |static member template ||functions Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 17:05 --- Fixed by: 2005-10-01 Jakub Jelinek <[EMAIL PROTECTED]> * runtime/memory.c (malloc_t): Remove. (GFC_MALLOC_MAGIC, HEADER_SIZE, DATA_POINTER, DATA_HEADER): Remove. (mem_root, runtime_cleanup, malloc_with_header): Remove. (internal_malloc_size): Use just get_mem if size != 0, return NULL otherwise. (internal_free): Just free if non-NULL. (internal_realloc_size): Remove debugging stuff. (allocate_size): Use malloc directly, remove debugging stuff. (deallocate): Use free directly, fix error message wording. If it is not then it is a bug in glibc, complain to them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails
--- Comment #14 from pcarlini at suse dot de 2005-10-07 17:05 --- (In reply to comment #13) > Both the simple testcase and the program I am working on work fine with your > patch. Thanks. Actually, I have to think a bit more about the idea. I'm not sure that there are binary compatibility problems, maybe not ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
[Bug rtl-optimization/23980] [3.4 Regression] THUMB basic block reordering incorrectly redirects non-simple cond-jump->fallthru
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-10-07 17:10 --- The problem here is that we have a complex compare-and-jump insn with side effects, so the insn can't be simply removed. cfgrtl is getting confused and is generating code that references a deleted label. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Component|target |rtl-optimization GCC host triplet|i386-unknown-linux | Summary|Bad assembly output in Thumb|[3.4 Regression] THUMB basic |mode with -O2 |block reordering incorrectly ||redirects non-simple cond- ||jump->fallthru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
[Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-07 17:25 --- On amd64-*-freebsd with Jakub's patch, I get troutmask:sgk[206] gfc41 -static -o z try.f sub.c troutmask:sgk[207] ./z Address of x = 0x00554000 x is aligned on a 16-byte boundary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
[Bug c++/24215] [4.0/4.1 Regression] pragma interface in included file with same name
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-07 17:26 --- A regression hunt identified this large patch from Zack Weinberg and Matt Austern: http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00920.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24215
[Bug middle-end/24227] [4.1 Regression] ICE in compare_values, at tree-vrp.c:415
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-07 18:12 --- Subject: Bug 24227 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-07 18:12:11 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr24227.c Log message: 2005-10-07 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/24227 * fold-const.c (fold_binary): Fix operand types during folding of X op (A, Y). Evaluation order of the side-effects of X and A are frontend-defined, so ensure we honour that even for tcc_comparison class operands; eased by removing duplicate code. * gcc.c-torture/compile/pr24227.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10117&r2=2.10118 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.626&r2=1.627 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6150&r2=1.6151 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr24227.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24227
[Bug middle-end/24227] [4.1 Regression] ICE in compare_values, at tree-vrp.c:415
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-10-07 18:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24227
[Bug tree-optimization/24262] New: ICE: verify_ssa failed with -O -msse2 -ftree-vectorize
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase
test.c -msse2 -auxbase-strip test.o -O -version -ftree-vectorize -o test.o
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129306
Compiler executable checksum: a278381769db4d67bad1ec630ceb45dd
test.c: In function 'test':
test.c:4: error: definition in block 1 does not dominate use in block 0
for SSA_NAME: D.1603_5 in statement:
base_off.27_12 = D.1603_5 * 16;
test.c:4: internal compiler error: verify_ssa failed
Configured with: ../gcc/configure --prefix=/tmp/gcc41 --enable-languages=c
--disable-nls --enable-checking=assert,rtlflag,misc
void dSetZero (double *a);
void test()
{
double A[12];
int i;
dSetZero (A);
for (i=0; i<6; i++) A[i+2*(i/2)] = 4;
dSetZero (A);
}
--
Summary: ICE: verify_ssa failed with -O -msse2 -ftree-vectorize
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ferdinandw+gcc at gmail dot com
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=24262
[Bug tree-optimization/24263] New: [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
FAIL: gcc.dg/torture/builtin-convert-1.c -O1 (test for excess errors) FAIL: gcc.dg/torture/builtin-convert-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/builtin-convert-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/builtin-convert-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/builtin-convert-1.c -Os (test for excess errors) appeared on hppa2.0w-hp-hpux11.11 on mainline on 20051006. Errors of the form: /usr/ccs/bin/ld: Unsatisfied symbols: floorl (first referenced in /var/tmp//cce8rnFl.o) (code) link_failure_outer_ceill_ceil_2 (first referenced in /var/tmp//cce8rnFl.o) (code) link_failure_outer_floorl_floor_2 (first referenced in /var/tmp//cce8rnFl.o) (code) ceill (first referenced in /var/tmp//cce8rnFl.o) (code) (Note that this is a target without C99 runtime, but the testcase configuration knows about that and the test passed before.) -- Summary: [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug middle-end/24263] [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:15 --- Hmm, nothing has touched builtin-convert-1.c. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug testsuite/24263] [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 19:18 --- Looks like the testcase is wrong in that it does not test C99 for ceill and floorl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug tree-optimization/24262] [4.1 Regression] ICE: verify_ssa failed with -O -msse2 -ftree-vectorize
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:27 ---
Confirmed, this was always broken in that we got wrong code in 4.0.0 but now we
get an ICE which means this is a regression and a progression.
Adding -W -Wall for 4.0, you get a warning:
t.c: In function test:
t.c:9: warning: ({anonymous}) is used uninitialized in this function
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, wrong-
||code
Last reconfirmed|-00-00 00:00:00 |2005-10-07 19:27:42
date||
Summary|ICE: verify_ssa failed with |[4.1 Regression] ICE:
|-O -msse2 -ftree-vectorize |verify_ssa failed with -O -
||msse2 -ftree-vectorize
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24262
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-07 19:27 --- Subject: Bug 24193 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-07 19:27:37 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.md Log message: Fix libgfortran build failure, stX insns don't allow post_inc addr w/ reg inc. PR target/24193 * config/ia64/ia64.md (movbi, movti_internal, gr_spill_internal, fr_spill): Use destination_operand for operand 0. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10119&r2=2.10120 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&r1=1.159&r2=1.160 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-07 19:36 --- A regression hunt on powerpc-linux using the testcase from comment #4 identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00101.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug preprocessor/24202] [4.1 Regression] Segfault with #pragma once
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-07 19:45 --- The most recent break on mainline was by this patch from jakub: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00974.html The same patch was applied to the 4.0 branch, causing the failure in 4.0.2. That patch from Jakub reverted part of this patch from Zack, which had fixed this bug on mainline: http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00122.html Before that, the failure on mainline started sometime between 2003-07-16 and 2003-09-15. I can identify the patch if it would be useful to anyone. -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[Bug rtl-optimization/24265] New: ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase
test.c -mtune=pentiumpro -auxbase-strip test.o -O -version
-fmove-loop-invariants -fgcse -o test.o
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007 (experimental).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129306
Compiler executable checksum: a278381769db4d67bad1ec630ceb45dd
test.c: In function 'foo':
test.c:14: error: unrecognizable insn:
(insn 21 16 39 0 (set (reg:DF 64)
(const_double:DF -858993460 [0x]
2.00011102230246251565404236316680908e-1 [0x0.dp-2]))
-1 (nil)
(nil))
test.c:14: internal compiler error: in extract_insn, at recog.c:2084
Configured with: ../gcc/configure --prefix=/tmp/gcc41 --enable-languages=c
--disable-nls --enable-checking=assert,rtlflag,misc
void dset (double d1, double d2);
void foo ()
{
int i;
double m, d = 0.2;
dset (m,d);
for (i=1; i<=3; i++) {
dset (m,d);
}
}
d needs to have the same value in both calls to dset for this ICE to occur.
--
Summary: ICE: in extract_insn, at recog.c:2084 with -O -fgcse -
fmove-loop-invariants -mtune=pentiumpro
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ferdinandw+gcc at gmail dot com
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=24265
[Bug preprocessor/24202] [4.0/4.1 Regression] Segfault with #pragma once
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-07 19:50 --- (In reply to comment #4) > Before that, the failure on mainline started sometime between 2003-07-16 and > 2003-09-15. I can identify the patch if it would be useful to anyone. Hmm, can you because in PR 15167, Neil said: >If it was broken back around 5th August 2003 I will look into this, as it was >my >new code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.0 4.1.0 |3.4.0 4.1.0 4.0.2 Known to work|3.3.3 |3.3.3 4.0.1 4.0.0 Summary|[4.1 Regression] Segfault |[4.0/4.1 Regression] |with #pragma once |Segfault with #pragma once Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #10 from wilson at gcc dot gnu dot org 2005-10-07 19:57 --- Mine. IA-64. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-04 18:17:34 |2005-10-07 19:57:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #11 from wilson at gcc dot gnu dot org 2005-10-07 19:58 --- Fixed on mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:58 --- Confirmed, a regression from 4.0.0. I think this is a target bug as you had: (set (mem:DF (plus:SI (reg/f:SI 7 sp) (const_int 8 [0x8])) [0 S8 A32]) (const_double:DF -858993460 [0x] 2.00011102230246251565404236316680908e-1 [0x0.dp-2])) before loop-invariant but after, you have: (insn 21 16 17 0 (set (reg:DF 64) +(const_double:DF -858993460 [0x] 2.00011102230246251565404236316680908e-1 [0x0.dp-2])) -1 (nil) +(nil)) Unless -fmove-loop-invariants is not calling emit_move_insn which might be the issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-10-07 19:58:56 date|| Summary|ICE: in extract_insn, at|[4.1 Regression] ICE: in |recog.c:2084 with -O -fgcse |extract_insn, at |-fmove-loop-invariants -|recog.c:2084 with -O -fgcse |mtune=pentiumpro|-fmove-loop-invariants - ||mtune=pentiumpro Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug rtl-optimization/15242] [3.4 regression] pessimization of "goto *"
--- Comment #35 from gdr at integrable-solutions dot net 2005-10-07 20:00 --- Subject: Re: [3.4 regression] pessimization of "goto *" "steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This is basically unfixable without serious hacking that is not | appropriate for GCC 3.4, so Gaby, with your permission, I'd like to | close this one as WONTFIX... I agree with your analysis. Thanks, -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-07 20:02 --- Subject: Bug 16339 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-07 20:02:28 Modified files: libgfortran: ChangeLog libgfortran/io : io.h unix.c transfer.c Log message: 2005-10-07 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/16339 PR fortran/23363 * io/io.h: Add read and write members to stream, define access macros. * io/transfer.c (read_block_direct): New function. (write_block_direct): New function. (unformatted_read): Change to use read_block_direct. (unformatted_write): Change to use write_block_direct. * io/unix.c: Remove mmap includes and defines. (writen): Remove. (readn): Remove. (reset_stream): New function. (do_read): New function. (do_write): New function. (fd_flush): Change to use do_write() instead of writen(). (fd_alloc_r_at): Change to use do_read(). (fd_seek): Change return type to try, as the prototype. Add check to avoid syscall overhead if possible. (fd_read): New function. (fd_write): New function. (fd_open): Set pointers for new functions. (mem_read): New function. (mem_write): New function. (open_internal): Set pointers for new functions. (is_seekable): Clean up comment. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.319&r2=1.320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.62&r2=1.63 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-07 20:02 --- Subject: Bug 23363 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-07 20:02:28 Modified files: libgfortran: ChangeLog libgfortran/io : io.h unix.c transfer.c Log message: 2005-10-07 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/16339 PR fortran/23363 * io/io.h: Add read and write members to stream, define access macros. * io/transfer.c (read_block_direct): New function. (write_block_direct): New function. (unformatted_read): Change to use read_block_direct. (unformatted_write): Change to use write_block_direct. * io/unix.c: Remove mmap includes and defines. (writen): Remove. (readn): Remove. (reset_stream): New function. (do_read): New function. (do_write): New function. (fd_flush): Change to use do_write() instead of writen(). (fd_alloc_r_at): Change to use do_read(). (fd_seek): Change return type to try, as the prototype. Add check to avoid syscall overhead if possible. (fd_read): New function. (fd_write): New function. (fd_open): Set pointers for new functions. (mem_read): New function. (mem_write): New function. (open_internal): Set pointers for new functions. (is_seekable): Clean up comment. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.319&r2=1.320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.62&r2=1.63 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug rtl-optimization/15242] [3.4 regression] pessimization of "goto *"
--- Comment #36 from steven at gcc dot gnu dot org 2005-10-07 20:06 --- Not really fixable for 3.4. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug libfortran/24174] real(10) array output broken
--- Comment #5 from tkoenig at gcc dot gnu dot org 2005-10-07 20:12 --- > It should be noted that the patch assumes that the padding for real(10) is 10 > bytes data + 2 bytes padding. This works on i686-Linux, might not work on > other > targets (big endian?). Itanium has padding to 16 bytes for 10-byte reals. Using 12 bytes for 10-byte reals on ia686 would mean breaking binary compatibility with Itanium :-( -- 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=24174
[Bug c/24137] __uint128_t missing for ppc32
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-07 20:27 --- I bumped into this PR by accident and happen to have looked into this recently. __uint128_t is supported on a ppc64 system with a powerpc64-linux compiler using "-m32 -mpowerpc64". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24137
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #8 from rth at gcc dot gnu dot org 2005-10-07 21:03 --- Steven's complaining about the solution... -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #9 from rth at gcc dot gnu dot org 2005-10-07 21:04 --- ... so it's his. Revert the patch and do what you like. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |stevenb at suse dot de Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-07 21:05 --- Steven is not the only one who is complaining about it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|stevenb at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-07 21:11 --- I think I have every right to complain after what happened to e.g. the CD-DCE patch, thank you very much. FY. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #12 from steven at gcc dot gnu dot org 2005-10-07 21:12 --- Oh, and for the record, if you don't care about compile time, fine, but SAY SO and say it in public so people know that even the top gcc hacker doesn't give shit about compile time, and so that I can stop wasting my time trying to find places where the compiler is dog slow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Comment #14 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug rtl-optimization/14418] Unnecessary loads and stores for tail call
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14418
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug tree-optimization/21451] Missed constant propagation
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21451
[Bug rtl-optimization/21527] BYTEmark bitmap test: Regression with Profiled Optimization
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527
[Bug target/23488] [4.1 Regression] extra reads from static variable
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 --- I don't have time to work on these (new job), so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug fortran/24266] New: ICE when writing to array of strings that is an elements of a user defined type
Latest CVS version of gfortran segfauls when writing to a an array of strings that is part of a user defined type. The behavior is very similiar to PR 15966 (but not solved by that solution). $ cat bug.f90 program main implicit none type ice character(len=80) :: mess(10) end type ice type(ice) :: tp ! leads to ICE write(tp%mess,*) "message" end program main $ gfortran bug.f90 bug.f90: In function MAIN__: bug.f90:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/xxx/compiler/gcc --enable-version-specific-runtime-libs --with-gcc-version-trigger=/home/xxx/tmp/gcc/gcc/version.c --enable-languages=c,c++,f95 --with-gmp=/home/xxx/compiler/gmp --with-mpfr=/home/xxx/compiler/gmp Thread model: posix gcc version 4.1.0 20051007 (experimental) -- Summary: ICE when writing to array of strings that is an elements of a user defined type Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yosef at phys dot utb dot edu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug tree-optimization/21883] [4.1 Regression] jump threading causing excessive code duplication
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:32 --- The patch has almost no effect except for -Os. For SPEC binaries the effect of the patch is not exactly shocking on AMD64 at least: No effect at all on compile time, no effect on performance, and almost no effect on code size either: param = value of --param max-jump-thread-duplication-insns=... INT = total size of SPECint binaries at -O2 with this param FP = total size of SPECfp binaries value INT FP 10004353510 3349018 500 4353510 3349018 200 4353510 3349018 100 4352614 3348570 75 4352198 3347322 50 4351302 3346874 40 4351046 3346746 30 4350374 3346394 20 4350310 3346170 10 4350150 3341434 5 4346342 3340826 0 4345126 3341034 I don't have time to update the patch for recent changes and do any further testing (e.g. CSiBE) to get this accepted, so unassigning. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21883
[Bug rtl-optimization/23857] [4.1 Regression] ICE: verify_flow_info failed - too many outgoing branch edges
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-07 21:33 --- This is somehow a bug in sched-ebb, but I can't figure out where... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23857
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #1 from yosef at phys dot utb dot edu 2005-10-07 21:36 --- This bug also seems to cause a segfault when writing to a standard array of strings. program main implicit none type ice character(len=80) :: mess(10) end type ice character(len=80) :: smess(10) type(ice) :: tp ! leads to ICE (but only when 2nd write is included) write(smess,*) "message" write(tp%mess,*) "message" end program main $ gfortan bug2.f90 bug2.f90: In function MAIN__: bug2.f90:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-07 21:55 --- I guess something like this should work if Andrew was right in comment #6. Obviously this doesn't fix the the test case from comment #1 because we don't go through this code if a user codes an "attribute regparm". Index: config/i386/i386.c === RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v retrieving revision 1.862 diff -u -3 -p -r1.862 i386.c --- config/i386/i386.c 5 Oct 2005 18:19:25 - 1.862 +++ config/i386/i386.c 7 Oct 2005 21:41:41 - @@ -2171,10 +2171,13 @@ ix86_function_regparm (tree type, tree d if (global_regs[local_regparm]) break; /* We can't use regparm(3) for nested functions as these use -static chain pointer in third argument. */ +static chain pointer in third argument. We also can't use +it when we are producing PIC code because one register is +reserved for the GOT (see e.g. PR21518). */ if (local_regparm == 3 - && decl_function_context (decl) - && !DECL_NO_STATIC_CHAIN (decl)) + && ((decl_function_context (decl) + && !DECL_NO_STATIC_CHAIN (decl)) + || flag_pic)) local_regparm = 2; /* Each global register variable increases register preassure, so the more global reg vars there are, the smaller regparm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Comment #13 from steven at gcc dot gnu dot org 2005-10-07 21:57 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug c/24267] New: Bad DWARF for altivec vectors
The Dwarf2 information for Altvec vectors gave _unknown_ as a base type for the vector instead of, in this case, 'short'. Using the depricated 'attribute' scheme works, but the 'new' __vector does not, so it could be considered a regression. This works correctly in 4.0.0 Here is an exmple of the bad dwarf: <0><19d>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 341 DW_AT_high_pc : 0x1b08 268438280 DW_AT_low_pc : 0x151c 268436764 DW_AT_name: ../../../src/gdb/testsuite/gdb.arch/altivec-abi.c DW_AT_comp_dir: /home/pgilliam/work/gdb-work/read-write/build/gdb/testsuite DW_AT_producer: GNU C 3.4.3 DW_AT_language: 1 (ANSI C) ... <1><29b>: Abbrev Number: 4 (DW_TAG_array_type) DW_AT_sibling : <2c2> DW_AT_name: __vector signed short DW_AT_GNU_vector : 1 DW_AT_type: <2d7> <2><2bb>: Abbrev Number: 5 (DW_TAG_subrange_type) DW_AT_type: <2c2> DW_AT_upper_bound : 7 <1><2c2>: Abbrev Number: 6 (DW_TAG_base_type) DW_AT_name: long unsigned int DW_AT_byte_size : 8 DW_AT_encoding: 7 (unsigned) <1><2d7>: Abbrev Number: 7 (DW_TAG_base_type) DW_AT_name: (indirect string, offset: 0x94): __unknown__ DW_AT_byte_size : 2 DW_AT_encoding: 5 (signed) ... <1><76a>: Abbrev Number: 14 (DW_TAG_variable) DW_AT_name: vshort DW_AT_decl_file : 1 DW_AT_decl_line : 3 DW_AT_type: <29b> DW_AT_external: 1 DW_AT_location: 9 byte block: 3 0 0 0 0 10 1 10 30 (DW_OP_addr: 10011030) -- Summary: Bad DWARF for altivec vectors Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pgilliam at us dot ibm dot com GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-07 21:58 --- I have no time to work on this. Note that there is no test case anymore either, so it's hard to tell whether a fix is doing the right thing. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug c/24267] Bad DWARF for altivec vectors
--- Comment #1 from janis at gcc dot gnu dot org 2005-10-07 22:12 --- I'm testing the backport of a fix for this. -- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-07 22:12:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
[Bug debug/24267] [3.4 only] Bad DWARF for altivec vectors
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |debug Keywords||wrong-debug Summary|Bad DWARF for altivec |[3.4 only] Bad DWARF for |vectors |altivec vectors Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 22:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-10-07 22:39:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug tree-optimization/23946] [4.1 regression] ICE: verify_ssa failed ("definition ... follows the use")
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-07 22:44 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00407.html Sometimes I wonder why a simple one line patch takes this long to create and why only a few developers (and a maybe 1-3 maintainers) are looking into bug reports any more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg00407.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23946
[Bug target/24257] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fgcse-sm
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-07 23:01 --- A regression hunt identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg01082.html -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug target/24257] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fgcse-sm
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-07 23:03 --- Hmm, maybe this is not a target bug after all but a latent bug in gcse store motion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug debug/24267] [3.4 only] Bad DWARF for altivec vectors
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|3.4.5 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-07 23:34 --- Can you do timings with today's compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug c++/24260] [4.0/4.1 Regression] stdcall attribute is ignored at static member template functions
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-07 23:50 --- For all of the 3.4.x and 4.0.x compilers I tried, plus the 3.4 branch, 4.0 branch, and mainline, I get the warning "stdcall attribute directive ignored" and there is no change in the generated code. This is for powerpc64-unknown-linux-gnu. Apparently the compilers that Andreas and Andrew have built are doing something different, or the problem is target related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug target/23644] IA-64 hardware models and configuration options documentation error for 3.4.x and 4.0.x
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-07 23:57 --- Subject: Bug 23644 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-07 23:57:36 Modified files: gcc: ChangeLog gcc/doc: invoke.texi Log message: Fix typo in docs. PR target/23644 * doc/invoke.texi (IA-64 Options, item -mtune): Renamed from -mtune-arch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10120&r2=2.10121 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.684&r2=1.685 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23644
[Bug c++/24260] [4.0/4.1 Regression] stdcall attribute is ignored at static member template functions
--- Comment #3 from janis at gcc dot gnu dot org 2005-10-08 00:00 --- Had I read the documentation for stdcall I'd know it's not used for powerpc. I'm starting a reghunt using an i686-linux cross compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-08 00:03 --- A regression hunt using an i686-linux cross compiler identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00015.html -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hagog at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug target/23644] IA-64 hardware models and configuration options documentation error for 3.4.x and 4.0.x
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-08 00:13 --- Subject: Bug 23644 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-08 00:13:07 Modified files: gcc: ChangeLog gcc/doc: invoke.texi Log message: Fix typo in IA-64 option docs. PR target/23644 * doc/invoke.texi (IA-64 Options, item -mtune): Renamed from -mtune-arch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.452&r2=2.7592.2.453 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.583.2.26&r2=1.583.2.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23644
