--- Comment #19 from bkoz at gcc dot gnu dot org 2005-12-14 07:23 ---
Created an attachment (id=10483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10483&action=view)
libstdc++ patch v5
Config not quite 100% correct, but good enough.
This moves all debug mode stuff to nested wi
--- Comment #8 from jpr at csc dot fi 2005-12-14 06:51 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Working on a patch.
>
> Posted a pacth here: http://gcc.gnu.org/ml/fortran/2005-12/msg00116.html
>
Is anyone considering approving (or disapproving) Eriks patch? It would
The following code produces an ICE in both gcc-3.4.4 and gcc-3.4.5, I've been
told it compiles fine in a 4.x version of the compiler.
int var1 = 0;
template inline void get_data() { int var2; var2 = v; }
int main() {
get_data();
return 0;
}
preprocessed source is as followes:
//
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-14 05:07 ---
gcc.dg/20050620-1.c, gcc.dg/940510-1.c, gcc.dg/c99-flex-array-1.c,
gcc.dg/pr14475.c, and gcc.dg/noncompile/incomplete-1.c all fail the same way:
PASS: gcc.dg/20050620-1.c (test for errors, line 8)
FAIL: gcc.dg/20050
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 05:04 ---
Obviously caused by:
2005-12-12 Alan Modra <[EMAIL PROTECTED]>
PR target/25299
* config/rs6000/rs6000.c (rs6000_special_round_type_align): Increase
alignment to doubleword if the first fiel
/Users/pinskia/src/gcc/combine/trunk/gcc/testsuite/gcc.dg/20030625-1.c:7:
error: field 'moo' has incomplete type^M
/Users/pinskia/src/gcc/combine/trunk/gcc/testsuite/gcc.dg/20030625-1.c:8:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in rs6000_special_
--- Comment #7 from chat95 at mac dot com 2005-12-14 04:06 ---
hi,
I bootstrap with
gmake CFLAGS+="-march=i686 -O2"
and still dumps core.
#1 0x292c80a2 in sigaction () from /usr/lib/libpthread.so.2
#2 0x292c218d in pthread_kill () from /usr/lib/libpthread.so.2
#3 0x292c1b9a in raise
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 03:01 ---
Note (for everyone else): The preprocessing source is in PR 25394.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-12-14 02:50
---
Here is a couple more structs which FSF's GCC gets wrong:
struct f{int c; struct {long long t;}; d;};
---
struct a{int tt; long long t; int i;};
struct f{int tt; struct a d; int t;};
struct a{long long t; int
--- Comment #6 from chat95 at mac dot com 2005-12-14 02:48 ---
Hi,
backtrace, gij bootstrapped with -O2
(gdb) bt
#0 0x292d42b7 in pthread_testcancel () from /usr/lib/libpthread.so.2
#1 0x292c40a2 in sigaction () from /usr/lib/libpthread.so.2
#2 0x292be18d in pthread_kill () from /usr
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-14
02:47 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' struct
> This is an unrelated bug which was introduced yesterday/today. Can you file a
> different
stage1/xgcc -Bstage1/ -B/opt/gnu/gcc/gcc-4.1.0/hppa2.0w-hp-hpux11.11/bin/ -c
-
g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototyp
es -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissin
g-format-attribute -Werror -fno-common -DHAVE_CONFIG_H
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-14 02:31 ---
(In reply to comment #5)
> We got this far with the patch:
> ../../gcc/gcc/c-parser.c:3137: internal compiler error: in rtx_equiv_p, at
> struct-equiv.c:644
This is an unrelated bug which was introduced yesterday/to
--- Comment #6 from danglin at gcc dot gnu dot org 2005-12-14 02:06 ---
Created an attachment (id=10482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10482&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25394
--- Comment #5 from danglin at gcc dot gnu dot org 2005-12-14 02:02 ---
We got this far with the patch:
stage1/xgcc -Bstage1/ -B/opt/gnu/gcc/gcc-4.1.0/hppa2.0w-hp-hpux11.11/bin/ -c
-
g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototyp
es -pedantic -Wno-lon
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-14 01:48 ---
I think it is picking up the wrong QT headers for the 32bit part of libgcj.
so you fix is not fully correct after all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25404
--- Comment #2 from bero at arklinux dot org 2005-12-14 01:44 ---
Created an attachment (id=10481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10481&action=view)
Generated assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25404
--- Comment #1 from bero at arklinux dot org 2005-12-14 01:43 ---
Created an attachment (id=10480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10480&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25404
When compiling libgcj with the Qt peer (after applying the workaround for bug
24403), the compiler barfs on x86_64 with binutils 2.16.91.0.4:
/usr/src/ark/BUILD/gcc-4.1.0/build/./gcc/xgcc -shared-libgcc
-B/usr/src/ark/BUILD/gcc-4.1.0/build/./gcc -nostdinc++
-L/usr/src/ark/BUILD/gcc-4.1.0/build/x86
--- Comment #10 from ian at airs dot com 2005-12-14 01:25 ---
Subject: Re: RFA: fix bootstrap/25397 part 2 (Was: Re: Bootstrap failed)
Joern RENNECKE <[EMAIL PROTECTED]> writes:
> pinskia at gcc dot gnu dot org wrote:
>
> > /* Compile with -O2 -m32 -fPIC */
> >
> ...
>
> Thanks.
--- Comment #5 from tromey at gcc dot gnu dot org 2005-12-14 00:58 ---
I also can't reproduce on x86 FC4.
If we had a gij stack trace we would know whether this was a dup of #25121.
I also suspect it is.
Also see #23602, perhaps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #6 from tromey at gcc dot gnu dot org 2005-12-14 00:51 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from tromey at gcc dot gnu dot org 2005-12-14 00:51 ---
URLs are handled differently.
If you do new File("./").toURI() you will get a URI
with the absolute path name in it -- i.e., a
hierarchical one. The same happens for
new File("./").toURL().toURI()
Caolan -- if we ch
--- Comment #1 from mast at colorado dot edu 2005-12-14 00:47 ---
Created an attachment (id=10479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10479&action=view)
Program with indentation that gives run-time error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
If a format statement is continued onto another line and the continuation
line is indented with more than one tab after the continuation character,
there is
a runtime error such as
Fortran runtime error: Unexpected element in format
(i4,i4,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|--- |4.2.0
http:
While bootstrapping I noticed:
checking for compiler with PCH support... no
checking for enabled PCH... no
And also the following tests fail:
FAIL: g++.dg/pch/empty.C -g (test for excess errors)
FAIL: g++.dg/pch/empty.C -O2 -g (test for excess errors)
FAIL: g++.dg/pch/empty.C -O2 (test for excess
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-14 00:18 ---
*** Bug 25401 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-14 00:18 ---
*** This bug has been marked as a duplicate of 19777 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from cummings at cacr dot caltech dot edu 2005-12-14 00:10
---
Created an attachment (id=10478)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10478&action=view)
test case showing incorrect runtime bounds check failure
Here is a simple code illustrating the problem.
I am compiling a Fortran 77 program with gfortran 4.0.2 and the -fbounds-check
flag. When the program runs, I get a message "Fortran runtime error: Array
reference out of bounds". The same program runs just fine when compiled with
either g77 3.x or g95 4.x and the -fbounds-check flag. The gist o
--- Comment #5 from dalej at gcc dot gnu dot org 2005-12-13 23:19 ---
This slight modification shows another problem: when the message refers to an
inlined copy of a variable, it points to the inlined function body and variable
rather than the place where the problem is. In the followi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-13 23:03 ---
(In reply to comment #3)
> (In the original example) note the bit vectors at beginning and end of blocks
> show 120 as live throughout the loop, although it isn't really. That's why I
> think it affects register pre
--- Comment #9 from joern dot rennecke at st dot com 2005-12-13 23:03
---
Subject: RFA: fix bootstrap/25397 part 2 (Was: Re: Bootstrap failed)
pinskia at gcc dot gnu dot org wrote:
>
>
>/* Compile with -O2 -m32 -fPIC */
>
>
...
Thanks. I have attached a patch.
2005-12-13 J"or
--- Comment #3 from dalej at gcc dot gnu dot org 2005-12-13 22:54 ---
(In the original example) note the bit vectors at beginning and end of blocks
show 120 as live throughout the loop, although it isn't really. That's why I
think it affects register pressure. GRA does do some munging
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-13 22:51 ---
(In reply to comment #7)
> Could you please send me the preprocessed source for this?
/* Compile with -O2 -m32 -fPIC */
typedef float DFtype __attribute__ ((mode (DF)));
typedef _Complex float DCtype __attribute__ ((
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-13 22:42 ---
One more thing If I do:
struct ss { unsigned short a; unsigned short b; };
union uu { unsigned int all; struct ss parts; };
#include
extern void bar(union uu);
extern void baz();
void foo() {
for(;;)
{
u
--- Comment #7 from joern dot rennecke at st dot com 2005-12-13 22:39
---
Subject: Re: Bootstrap failed
pinskia at gcc dot gnu dot org wrote:
>--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-13 21:40
>---
>I get a different error with 108482:
>./xgcc -B./ -B/home
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-13 22:33 ---
Actually reading the RTL, it would not help register pressure at all since the
set is done right before the call to bar and is not pull out of the loop.
What is happening is that u is being assigned a pesdu registe
--- Comment #6 from hjl at lucon dot org 2005-12-13 22:12 ---
Created an attachment (id=10477)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10477&action=view)
A testcase
I got
gnu-13:pts/7[26]> ./xgcc -B./ unwind-dw2.i -S -fPIC -O2
/export/gnu/src/gcc-blended/gcc/gcc/unwind-dw2.
--- Comment #6 from Daniel dot Davies at xerox dot com 2005-12-13 22:12
---
(In reply to comment #0)
> I try to install gcc 4.1; I have
>
> $ svn info
> Path: .
> URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch
> Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
> Revision:
(I don't think this is the same as any of the similar bugs, although I could be
wrong.)
In this case the field assignments cover all of u, so none of it is actually
live across
the call, but dataflow can't figure this out.
While this bogus warning is the only visible effect I know of, fixing thi
--- Comment #4 from mark at gcc dot gnu dot org 2005-12-13 22:01 ---
(In reply to comment #3)
> Exception in thread "main" java.lang.IllegalArgumentException: URI is not
> hierarchical
> at java.io.File.(File.java:344)
> at myfirstprog.main(myfirstprog.java:16)
Interesti
When I examine gij processes running gcj-dbtool managed code
on Linux with lsof, I see that we have two active file
descriptors for every jar file. And strace confirms that we
open each jar file twice (and keep them open). I don't know
why this is happening, but it seems wrong.
--
--- Comment #5 from amylaar at gcc dot gnu dot org 2005-12-13 22:00 ---
(In reply to comment #3)
> I believe so.
>
I didn't have any luck with either x86-64-elf or x86-64-linux, bfd refused to
build. So I looked for the latest x86-64 posting to gcc-testresults, which had
x86_64-suse-l
--- Comment #2 from bje at gcc dot gnu dot org 2005-12-13 21:47 ---
Fixed in revision 1.17 of htdocs/svn.html.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from danglin at gcc dot gnu dot org 2005-12-13 21:43 ---
Reconfirmed in 3.4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19770
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-13 21:40 ---
I get a different error with 108482:
./xgcc -B./ -B/home/pinskia/checkin/x86_64-unknown-linux-gnu/bin/ -isystem
/home/pinskia/checkin/x86_64-unknown-linux-gnu/include -isystem
/home/pinskia/checkin/x86_64-unknown-lin
--- Comment #3 from hjl at lucon dot org 2005-12-13 21:33 ---
I believe so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-13
21:25 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' structRO
> Please give this a try, tell me if it works
The build gets past the point of the ICE. H
--- Comment #2 from amylaar at gcc dot gnu dot org 2005-12-13 21:21 ---
Is building a cross-compiler configured with --target=x86-64-elf likely to
work up to this point and reproduce the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
--- Comment #26 from tkoenig at gcc dot gnu dot org 2005-12-13 21:11
---
Subject: Bug 23815
Author: tkoenig
Date: Tue Dec 13 21:11:23 2005
New Revision: 108483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108483
Log:
2005-12-13 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #1 from hjl at lucon dot org 2005-12-13 21:03 ---
Backout
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00899.html
seems to fix this failure.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #18 from bkoz at gcc dot gnu dot org 2005-12-13 20:39 ---
Created an attachment (id=10476)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10476&action=view)
test case for second fail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #17 from bkoz at gcc dot gnu dot org 2005-12-13 20:38 ---
Created an attachment (id=10475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10475&action=view)
test case for first fail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
With gcc 4.2 revision 108480 on x86-64, I got
./xgcc -B./ -B/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/bin/ -isystem
/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/include -isystem
/usr/gcc-4.2-blended/x86_64-unknown-linux-gnu/sys-include
-L/export/build/gnu/gcc-blended/build-x86_64-linux/gcc/..
--- Comment #16 from bkoz at gcc dot gnu dot org 2005-12-13 20:27 ---
Two extra fails with both versioning and debug associations active.
FAIL: 20_util/memory/16505.cc (test for excess errors)
FAIL: 25_algorithms/search_n/11400.cc (test for excess errors)
For the first:
#include
//
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-12-13 20:16
---
This is causing a bootstrap failure, the same as in comment #13 in fact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
--- Comment #3 from tromey at gcc dot gnu dot org 2005-12-13 20:07 ---
with the JDK I get this output:
opsy. java myfirstprog
urlObject is file:./
Exception in thread "main" java.lang.IllegalArgumentException: URI is not
hierarchical
at java.io.File.(File.java:344)
at my
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-12-13 20:03
---
One more thing is that this is not documented anywhere (I can find) that
libstdc++ does this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #4 from janis at gcc dot gnu dot org 2005-12-13 19:08 ---
xfail within a dg-do command other than run has no effect, at least not with
DejaGnu 1.4.4 used with GCC at least as far back as 3.0. The DejaGnu
documentation doesn't mention the dg-* directives. The comments in
dej
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-13 18:59 ---
This should be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00218.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24572
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-13
18:48 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' structure, have 'name_memory_tag'
Attached .i.
Dave
--- Comment #3 from dave at hiauly1 dot h
--- Comment #1 from dberlin at gcc dot gnu dot org 2005-12-13 18:14 ---
Created an attachment (id=10473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10473&action=view)
Patch
Please give this a try, tell me if it works
--
dberlin at gcc dot gnu dot org changed:
Wh
Consider the following testcase:
module geometry
implicit none
interface operator(.cross.)
module procedure cross
end interface
contains
! Cross product between two 3d vectors.
pure function cross(a, b)
real, dimension(3), intent(in) :: a,b
real, dimension(3) ::
The following code shows the problem:
program test
common /abc/ mwkx(80)
dimensionlistpr(20),lisbit(10),lispat(8)
* This is badly compiled
* ==
equivalence (listpr(10),lisbit(1),mwkx(10))
+, (listpr(10),lispat(1))
do i
,ada --enable-checking=all
Thread model: posix
gcc version 4.2.0 20051213 (experimental)
--
Summary: libgcc2.c:2033: ICE: tree check: expected tree that
contains 'decl common' structure, have 'name_memory_tag'
Product: gcc
--- Comment #2 from jb at gcc dot gnu dot org 2005-12-13 16:13 ---
Unfortunately the goto blas library where I noticed this error is not free
software. But here is a simple testcase that shows the same problem.
File hello.c:
#include
#include
#include
#define NUM_THREADS 2
void
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-13 15:37 ---
Forgot to say this worked with 3.3.5 so it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-13 15:37 ---
I can reproduce it with 3.4.5, 4.0.2, 4.0.3, 4.1.0 and 4.2.0. But I cannot
reduce it right now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dir at lanl dot gov 2005-12-13 15:21 ---
Removing the constraint of no read after write gives a slightly shorter one -
[dranta:~/tests/gfortran-D] dir% gfortran -o write11 write11.f
[dranta:~/tests/gfortran-D] dir% write11
At line 14 of file write11.f
Fortran runti
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-12-13 15:10
---
*** Bug 25393 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-13 15:10 ---
*** This bug has been marked as a duplicate of 24982 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-13 15:09 ---
encoder/analyse.c:940: internal compiler error: in
refers_to_regno_for_reload_p, at reload.c:6226
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25393
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-12-13 15:02
---
*** Bug 25390 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-13 15:02 ---
This is a dup of bug 20681.
The problem is the break following the return. GCC does not remove it before
lowering.
*** This bug has been marked as a duplicate of 20681 ***
--
pinskia at gcc dot gnu dot org cha
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-13 14:57 ---
GCC 4.1 is correct, friend does not inject into the current scope at all.
And it does fail with Comeau-C++ in strict mode.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from philb at filmlight dot ltd dot uk 2005-12-13 14:41
---
Disagree with known to work 4.0.2 - original report was from 4.0.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25364
--- Comment #9 from dir at lanl dot gov 2005-12-13 14:39 ---
I generated random I/O sequences doing 100,000 tests at each I/O operation
count staring at five here is the shortest one to fail (somewhere in the
eights) -
[dranta:~/tests/gfortran-D] dir% gfortran -o write10 write10.f
[dran
--- Comment #1 from klaue at dresearch dot de 2005-12-13 14:39 ---
Created an attachment (id=10472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10472&action=view)
bug.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25393
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2005-12-13 14:37
---
Created an attachment (id=10471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10471&action=view)
doc patch for -fomit-frame-pointer
Meanwhile, please fix the documentation to match what it does
(and state
/* gcc -v */
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/jklaue/local
Thread model: posix
gcc version 4.2.0 20051205 (experimental)
/* command line */
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MALLOC_H -DHAVE_MMXEXT
-DHAVE_SSE2 -DARCH_X86 -DSYS
--- Comment #1 from jv244 at cam dot ac dot uk 2005-12-13 14:32 ---
(In reply to comment #0)
this is currently also discussed in
http://gcc.gnu.org/ml/gcc/2005-12/msg00300.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25198
real function foo (x, y)
real x, y
foo = y - x
do while (foo .gt. 180.)
foo = foo - 360.
enddo
do while (foo .le. -180.)
foo = foo + 360.
enddo
end
ICEs in various places depending on the exact -O level and target.
The problem is that __result_foo variable is given type not cor
--- Comment #2 from mark at gcc dot gnu dot org 2005-12-13 13:47 ---
Added a test to mauve that exposes this bug:
gnu/testlet/java/io/File/newFileURI.java
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from amylaar at gcc dot gnu dot org 2005-12-13 13:41
---
(In reply to comment #20)
> Created an attachment (id=10463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10463&action=view) [edit]
> a full set of debugging dumps
>
> Re. comment #16, sorry, I didn't read
module mod1
type t1
real :: f1
end type t1
type t2
type(t1), pointer :: f2(:)
real, pointer :: f3(:,:)
end type t2
end module mod1
module mod2
use mod1
type(t1), pointer, save :: v(:)
contains
subroutine foo (x)
use mod1
implicit none
type(t2) :: x
integer
--- Comment #21 from amylaar at gcc dot gnu dot org 2005-12-13 13:16
---
(In reply to comment #17)
> Created an attachment (id=10461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10461&action=view) [edit]
> Instruction stream (stripped) before scheduling
>
(insn/s 24 0 (set (su
--- Comment #17 from jakub at gcc dot gnu dot org 2005-12-13 13:14 ---
Should be fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #1 from jakub at gcc dot gnu dot org 2005-12-13 13:10 ---
Can you attach a testcase?
The gdb session doesn't really provide any useful info.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pmladek at suse dot cz 2005-12-13 13:08 ---
First, I am sorry for the first empty message. I pressed enter too fast.
Well, I have got an invalid warning: control reaches end of non-void function
with gcc-4.1.0-pre
The reduced testcase looks like:
--- cut ---
namesp
--- Comment #23 from amylaar at gcc dot gnu dot org 2005-12-13 13:04
---
Subject: Bug 20070
Author: amylaar
Date: Tue Dec 13 13:04:18 2005
New Revision: 108480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108480
Log:
PR rtl-optimization/20070 / part1
* flow.c
--- Comment #4 from jakub at gcc dot gnu dot org 2005-12-13 13:00 ---
The problem isn't present on gomp-20050608-branch (where pragma handling has
been revamped).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25294
--
Summary: gcc-4.1.0: Invalid warning: control reaches end of non-
void function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassi
--- Comment #13 from paul dot richard dot thomas at cea dot fr 2005-12-13
12:50 ---
I am just now posting a patch for this bug.
Andrew,
I ignored your advice, "All of the above need to be fixed in the front-end and
not in the middle-end where fold_convert resides." by doing the fixing
--- Comment #4 from peter dot soetens at fmtc dot be 2005-12-13 12:09
---
Created an attachment (id=10470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10470&action=view)
Minimal change to Failure testcase to cause success
$ g++ test_undefined_symb4_ok.ii -o test_undefined_symb
--- Comment #3 from peter dot soetens at fmtc dot be 2005-12-13 12:06
---
Created an attachment (id=10469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10469&action=view)
Failure testcase
$ g++ test_undefined_symb4_fail.ii -o test_undefined_symb4_fail
/tmp/ccSLyh1a.o: In functio
--- Comment #1 from mark at gcc dot gnu dot org 2005-12-13 11:46 ---
Confirmed. URI.getPath() may return null and we don't check for that in the
File(URI) constructor. A simple fix might be:
diff -u -r1.59 File.java
--- java/io/File.java 6 Nov 2005 20:28:00 - 1.59
+++ java/i
1 - 100 of 126 matches
Mail list logo
