--- Comment #2 from lothar at tradescape dot biz 2005-10-08 06:07 ---
/opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -fvisibility=hidden
-fvisibility-inlines-hidden -save-temps -W -Wall -Wpointer-arith -m64
-I/opt2/linux/x86_64/include -O3 -g -pipe -m64 -I/opt2/linux/x86_64/include
-D_R
--- Comment #1 from lothar at tradescape dot biz 2005-10-08 06:06 ---
Created an attachment (id=9932)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9932&action=view)
preprocessed file (gziped)
preprocessed file that is mentioned in the linker error as having created the
invalid re
/opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --program-suffix=-4.0.2
--enable-__cxa_atexit --enable-languages=c,c++ --prefix=/opt2/linux/ix86
--target=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu
--with-sys
--- Comment #1 from lothar at tradescape dot biz 2005-10-08 05:59 ---
Created an attachment (id=9931)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9931&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24271
/opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --program-suffix=-4.0.2
--enable-__cxa_atexit --enable-languages=c,c++ --prefix=/opt2/linux/ix86
--target=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu
--with-sys
--- Comment #34 from ian at airs dot com 2005-10-08 05:51 ---
I am able to recreate the problem with a hppa64-hp-hpux11 cross-compiler, in
the sense that combine does lose the REG_DEAD note when compiling the
gcc.c-torture/compile/920501-13.c test case with -O1. In the current compiler,
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-08 05:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-08 05:45
---
*** Bug 24269 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-08 05:45 ---
This is a dup of bug 14251.
I am assuming that you installed a GNU version of coreutils which was "broken".
*** This bug has been marked as a duplicate of 14251 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #33 from ian at airs dot com 2005-10-08 05:04 ---
I found the bug report which led to the patch which is the issue in this PR.
It starts here:
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00796.html
and ends with this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-05/
--- Comment #2 from schnetter at aei dot mpg dot de 2005-10-08 04:46
---
Created an attachment (id=9930)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9930&action=view)
Necessary module source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24270
--- Comment #1 from schnetter at aei dot mpg dot de 2005-10-08 04:45
---
Created an attachment (id=9929)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9929&action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24270
I am using
$ /Users/eschnett/gcc/bin/gfortran --version
GNU Fortran 95 (GCC) 4.1.0 20050925 (experimental)
with the options
/Users/eschnett/gcc/bin/gfortran -mlongcall -g3 -O2 -funroll-loops -Wall
-Wshadow -Wsurprising -c -o $current_wd/AHFinder_exp.F.o
$current_wd/AHFinder_exp.f
which leads to
I checked out gcc from cvs today (2005-10-07). I configured with
~/src/gcc/configure --prefix=$HOME/gcc --with-mpfr=/Users/eschnett
--enable-languages=c,c++,fortran,java,objc,treelang
and then said
make bootstrap
After some time, this fails with many (about 200) lines of
tail: +16c: No such f
--- Comment #7 from kazu at gcc dot gnu dot org 2005-10-08 03:36 ---
I just checked in a fix for PR 23150, which is probably duplicate of this PR.
Could somebody test the current mainline now on powerpc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23090
--- Comment #6 from kazu at gcc dot gnu dot org 2005-10-08 03:34 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-08 03:33
---
Subject: Bug 23150
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-08 03:33:46
Modified files:
gcc: ChangeLog calls.c
Log message:
PR
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-08 03:24
---
Confirmed on latest 4.1 cvs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
Srujan.K.V.S. wrote:
The following is the program to print magic squares.I`m getting
wierd output when i remove the printf statement "printf("a")" from the
code.
Please see
http://gcc.gnu.org/bugs.html
for info on how to submit bug reports.
You did not include enough info for us to do
The following simple program is rejected by gfortran
(commandline: gfortran junk.f)
with this error message:
In file junk.f:6
* 1.4)
1
Error: Period required in format string at (1)
In file junk.f:4
write(6,10) x
1
Error: FORMAT label 10 at (1) not d
--- Comment #4 from janis at gcc dot gnu dot org 2005-10-08 01:08 ---
A regression hunt with an i686-linux cross compiler identified this patch
from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg01078.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
--- Comment #6 from wilson at gcc dot gnu dot org 2005-10-08 00:31 ---
Fixed on the gcc-3.4.x branch, the gcc-4.0.x branch, and mainline (gcc-4.1).
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from wilson at gcc dot gnu dot org 2005-10-08 00:25 ---
Mine. IA-64. Confirmed. A typo in the patch adding docs for this option.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-08 00:22
---
Subject: Bug 23644
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-10-08 00:22:20
Modified files:
gcc: ChangeLog
--- 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
--- 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
--- 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
--- 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.tex
--- 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
powe
--- 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
--
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
--- 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
--- 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 |Adde
--- 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
--- 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|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |debug
Keywords||wrong-debug
--- 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
-
--- 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
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 th
--- 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
--- 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".
I
--- 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(
--- 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
---
--- 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
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
--- 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
-
--- 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
-
--- 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
-
--- 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
-
--- 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
-
--- 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
-
--- 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
--- 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
--- 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
---
--- 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
---
--- 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
--- 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
--- 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
--- 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 1
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
Statu
--- 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|una
--- 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
/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
--- 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 Jak
--- 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.
--- 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
--- 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
--- 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
-
--- 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
---
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 ex
/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
--- 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
--- 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
--- 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
--- 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/b
--- 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.
--
re
--- 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 compatibili
--- 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,
--- 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
---
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 l
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
http:
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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconf
--- 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
--- 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
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
--- 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
/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
--- 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 tim
--- 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:
--- 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 r
--- 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 c
--- 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 filesyste
--- 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
--- 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/rs600
1 - 100 of 124 matches
Mail list logo
