--- Comment #2 from r dot leitgeb at x-pin dot com 2006-10-24 07:31 ---
Here's an excerpt of the assembly code obtained with -Os -S
with some comments from me:
setpin:
/* prologue: frame size=0 */
/* prologue end (size=0) */
m
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29321
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29284
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 29322
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 25091
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06
---
Subject: Bug 25092
Author: fxcoudert
Date: Tue Oct 24 08:05:55 2006
New Revision: 117996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996
Log:
A bunch of backports:
PR fortran/29284
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-24 08:12 ---
Subject: Bug 29567
Author: rguenth
Date: Tue Oct 24 08:12:04 2006
New Revision: 117997
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117997
Log:
2006-10-24 Richard Guenther <[EMAIL PROTECTED]>
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.2.0
ht
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-10-24 08:19
---
This works for me and many many other people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-24 08:20 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from h dot b dot furuseth at usit dot uio dot no 2006-10-24
08:20 ---
Subject: Re: Issues with -Wchar-subscripts
gdr at integrable-solutions dot net writes:
> The absence of warning in C is OK -- literal characters have type int
> in C.
Yes, but see previous comments.
--- Comment #17 from nathan at gcc dot gnu dot org 2006-10-24 08:38 ---
Subject: Bug 20647
Author: nathan
Date: Tue Oct 24 08:38:26 2006
New Revision: 117999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117999
Log:
cp/
PR c++/20647
* rtti.c (tinfo_base_init): T
--- Comment #18 from nathan at gcc dot gnu dot org 2006-10-24 08:38 ---
fixed on mainline, 4.1 & 4.2
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-24 09:15
---
Subject: Bug 28796
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001
Log:
2006-10-24 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-24 09:19
---
This is now nearly fixed. What is remaining is that specifying the
-mno-ieee-fp
target option does not set flag_finite_math_only, but I am not sure if it
should so. This causes
[ollmia:/tmp] iano% gcc main3.c -W
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-10-24 09:23
---
Ah well, this seems to be documented as such:
-mieee-fp
-mno-ieee-fp
Control whether or not the compiler uses IEEE floating point comparisons.
These handle correctly the case where the result of a comparison i
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-24 09:48
---
Adjust target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-10-24 12:16
---
Still bogus at the tree level as in comment #11, but fixed by RTL optimizers:
_Z1xv:
.LFB5:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$24, %esp
.LCFI2:
movl$_Z1fv,
Inquire returns for formatted "YES" for the following cases:
- not opened file, which is not readable. How should gfortran know?
- opened or unopend, finite-size unformatted file. This is clearly wrong.
Test program attached
--
Summary: inquire(...) returns formatted=="YES" for unr
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-24 12:27 ---
Created an attachment (id=12482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12482&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-24 12:34
---
We now get
:
# param_2 = V_MAY_DEF ;
param.f1 = 0;
# param_6 = V_MAY_DEF ;
# SFT.0_7 = V_MAY_DEF ;
# NONLOCAL.6_8 = V_MAY_DEF ;
# NONLOCAL.12_13 = V_MAY_DEF ;
# NONLOCAL.18_16 = V_MAY_DEF
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-24 12:55
---
This PR is only about a non-optimal tree-representation for __builtin_sincos.
See also http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01151.html for an
alternative and some discussion.
(The other patch was rejected,
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:07 ---
We should at least fold
b->bit = () (unsigned char) ((signed char) b->bit | 1);
to
b->bit = () ((signed char) b->bit | 1);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:14 ---
Tree if-conversion is now converting one jump. Andrew, I guess you are not
working on this anymore? ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
The below referenced preprocessed code cannot be compiled due to invalid
asm statements:
... Making thread-io.o
/tmp/cc1rd17V.s: Assembler messages:
/tmp/cc1rd17V.s:788: Error: bad register name `%sil'
/tmp/cc1rd17V.s:829: Error: bad register name `%sil'
make[2]: *** [thread-io.o] Error 1$
http:
--- Comment #1 from adam at os dot inf dot tu-dresden dot de 2006-10-24
13:23 ---
Created an attachment (id=12483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12483&action=view)
preprocessed files which cannot be compiled
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29579
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-24 13:28 ---
With more registers (x86_64) the stack moves are gone, but: (!)
[EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> ./xgcc -B. -O2 -o t t.c
-mfpmath=387
[EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> /usr/bin/time ./
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-24 13:31 ---
I'm actually not any more sure what is meant by "formatted" in
inquire(). The Fortran 2003 standard says:
"The scalar-default-char-variable in the FORMATTED= specifier is
assigned the value YES if
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-10-24 13:50 ---
(In reply to comment #8)
> Hmm, This is one of the language hooks which really need to go away
> for LTO as I understand it. Also I the real problem comes from the
> inliner or the gimplifier (I am betting the gimpl
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-24 13:56
---
So, where do we want to go?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
--- Comment #21 from rakdver at gcc dot gnu dot org 2006-10-24 13:58
---
(In reply to comment #20)
> So, where do we want to go?
>
Unless the basic patch is approved (which did not happen so far, despite of
several pings), I do not know. I will try to resend the patch, perhaps that
w
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-24 13:59
---
Subject: Bug 29494
Author: ebotcazou
Date: Tue Oct 24 13:59:06 2006
New Revision: 118004
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118004
Log:
PR libgomp/29494
* configure.tgt: Use po
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-10-24 13:59
---
Subject: Bug 29494
Author: ebotcazou
Date: Tue Oct 24 13:59:39 2006
New Revision: 118005
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118005
Log:
PR libgomp/29494
* configure.tgt: Use po
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-10-24 14:01
---
Fixed everywhere. My latest results on SPARC/Solaris 2.6 are:
=== libgomp tests ===
Running target unix
WARNING: program timed out.
FAIL: libgomp.c/appendix-a/a.18.1.c execution test
WARNING: p
--- Comment #2 from adam at os dot inf dot tu-dresden dot de 2006-10-24
14:04 ---
The problem happens with 4.0 and 4.1 but not with 4.2 or trunk (all 20061022
versions). -O2 is needed. Does not happen with -O1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29579
--- Comment #6 from happydeer at gmail dot com 2006-10-24 14:05 ---
Fortran runtime error: Bad real number in item 1 of list input
My READ statement is:
READ(2,*)(JM(I,IQ),IQ=0,MQ)
JM(I,IQ) got from an input file.
JM(I,IQ) defined :DOUBLE PRECISION JM(NSDMAX,0:MQ),JB(0:LMAX,0:MB)
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-24 14:10 ---
Fixed in 4.2. Numbers are reasonable now:
[EMAIL PROTECTED]:/space/rguenther/tramp3d> /usr/bin/time ~/bin/maxmem.sh
./install/bin/g++ -O2 -S -o /dev/null tramp3d-v4.cpp -Dleafify=flatten
total: 903456 kB
159.28user
In the gfortran version of 20060914 it was still legal to use the integer value
-2147483648 for 4 byte (kind=4) integers.
In the gfortran version of 20061023 this seems no longer possible, I get the
compilation error:
Error: Integer too big for its kind at (1)
Does this mean the integer numbers
--- Comment #22 from dberlin at gcc dot gnu dot org 2006-10-24 14:23
---
(In reply to comment #19)
> So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the
> loop
> is not in do-while form, and we won't hoist the loop header copies until the
> loads are PREd. As to
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-24 14:47 ---
It is not a bug. "i = - 2147483648" is a unary minus operation on the
number 2147483648. This number overflows the range. If you want
the most negative number for an integer use "i = - huge(i) - 1".
I've already po
--- Comment #2 from kloedej at knmi dot nl 2006-10-24 15:04 ---
In my simple view as a physicist the minus sign is an integral part of the
number and not an operation on it, but then I didn't have a formal computer
science education. As a gfortran programmer you have a choice here I woul
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-24 15:07 ---
Actually folding (i0 > i1 + 1) || (i1 < i0 - 1) is not possible, but I have a
patch that is able to fold (i0 < i1 + 1) || (i1 > i0 - 1) to i1 >= i0.
The original one is not possible due to overflow issues.
--
rg
SUBROUTINE FOO (K)
INTEGER I, J, K, A(5,5), B
COMMON A
A(1,1) = 1
10 B = 0
DO 30 I = 1, K
DO 20 J = 1, K
B = B + A(I,J)
20 CONTINUE
A(I,I) = A(I,I) * 2
30 CONTINUE
IF (B.GE.3) RETURN
GO TO 10
END SUBROUTINE
PROGRA
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-24 15:25 ---
(In reply to comment #2)
> In my simple view as a physicist the minus sign is an integral part of the
> number and not an operation on it, but then I didn't have a formal computer
> science education. As a gfortran pro
Given class COtherClass having methods
class COtherClass
{
...
inline COtherClass(unsigned int uiParam1, const char *pszParam2, const
char *pszParam3, unsigned long ulParam4, const char *pszParam5)
{...}
~COtherClass();
COtherClass &Method1();
COtherClass &Me
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-24 15:57 ---
You should note that C has the same issue really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
--- Comment #1 from schwab at suse dot de 2006-10-24 16:02 ---
The evaluation order of function arguments is not specified. If you depend on
side effects to be carried out at a specific point you must make sure there is
a sequence point at the appropriate place.
--
schwab at suse do
--- Comment #2 from oder at eleks dot lviv dot ua 2006-10-24 16:09 ---
(In reply to comment #1)
> The evaluation order of function arguments is not specified. If you depend on
> side effects to be carried out at a specific point you must make sure there is
> a sequence point at the appr
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-24 16:14 ---
*** This bug has been marked as a duplicate of 10153 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-24 16:14 ---
*** Bug 29579 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
fill_simple_delay_slots, in reorg.c, scans backwards for instructions to put in
delay slots. It fills the slots in reverse order, i.e. if it finds an
instruction A it first puts it in slot 1, if it finds a second one B then A is
bumped down to slot 2, and B in slot 1; etc. However, the check
eligib
--- Comment #1 from ersmith at hfx dot eastlink dot ca 2006-10-24 16:30
---
Created an attachment (id=12484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12484&action=view)
proposed patch to fix delay slot scheduling problems
Here is my proposed patch. It checks the existing ins
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-10-24 17:01
---
Subject: Bug 29393
Author: eedelman
Date: Tue Oct 24 17:01:30 2006
New Revision: 118008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118008
Log:
fortran/
2006-10-24 Erik Edelmann <[EMAIL PROTECTED]>
Internal compiler error when optimization is enabled(not -O0):
arm-linux-uclibcgnueabi-gcc -O1 -c test.c
include/asm/arch/io.h: In function 'imu_dev_init':
include/asm/arch/io.h:43: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #1 from k dot shutemov at gmail dot com 2006-10-24 17:17
---
Created an attachment (id=12485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12485&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
--- Comment #14 from ghazi at gcc dot gnu dot org 2006-10-24 17:44 ---
Subject: Bug 29335
Author: ghazi
Date: Tue Oct 24 17:44:36 2006
New Revision: 118009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118009
Log:
PR middle-end/29335
* builtins.c (fold_builtin_s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-10-24 18:31
---
(In reply to comment #13)
> We now get
>
> :
> # param_2 = V_MAY_DEF ;
> param.f1 = 0;
> # param_6 = V_MAY_DEF ;
> # SFT.0_7 = V_MAY_DEF ;
> # NONLOCAL.6_8 = V_MAY_DEF ;
> # NONLOCAL.12_13 =
--- Comment #2 from tbm at gcc dot gnu dot org 2006-10-24 18:56 ---
This also happens on amd64. Segfaults with 4.0 and 4.1, works with 3.4 and
4.2.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tbm at gcc dot gnu dot org 2006-10-24 18:56 ---
Created an attachment (id=12486)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12486&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
--- Comment #4 from tbm at gcc dot gnu dot org 2006-10-24 19:02 ---
(gdb) where
#0 expand_case (exp=Variable "exp" is not available.
) at /home/tbm/scratch/gcc-4.1/gcc/stmt.c:2106
#1 0x00533ee7 in expand_expr_real_1 (exp=Variable "exp" is not
available.
) at /home/tbm/scratch/g
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-10-24 19:03
---
Sorry for missing that bug. The proposed patch is OK -- thanks for
catching this.
As to the general problem, I think you're right that we need to further
constrain the range of accepted offsets. However, DISP_I
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-24 19:04 ---
0x8000UL ... (0x8000UL + 0x3a00UL - 1):
I think this is a case of an overflow.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
This didn't happen with 4.2 20061015. It happens with mainline but I cannot
check the 4.2 branch right now.
(sid)978:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c pasmo-asm.cc
pasmo-asm.cc:77: warning: 'Asm::In' has a field 'Asm::In::nullout' whose type
uses the anonymous namespace
(sid)
--- Comment #1 from tbm at cyrius dot com 2006-10-24 19:12 ---
Created an attachment (id=12487)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12487&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
$ cat blah.c
#warning (that's not C?)
$ gcc-4.1 -c -o blah.o blah.c
blah.c:1:2: warning: #warning (that's not C?)
$ gcc-4.3-HEAD -c -o blah.o blah.c
blah.c:1:2: warning: #warning (thatblah.c:1:15: warning: missing terminating '
character
's not C?)
Fails with:
gcc ve
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-24 20:26 ---
No this is not valid and in fact was rejected in GCC before 3.4.0. In fact
this is undefined behavior at compile time. SEE PR 12743 for more discussion
about this.
*** This bug has been marked as a duplicate of 14
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-24 20:26
---
*** Bug 29586 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-10-24 20:40
---
Subject: Bug 29393
Author: eedelman
Date: Tue Oct 24 20:40:19 2006
New Revision: 118010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118010
Log:
fortran/
2006-10-24 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #12 from aldot at gcc dot gnu dot org 2006-10-24 20:41 ---
(In reply to comment #11)
> *** Bug 29586 has been marked as a duplicate of this bug. ***
>
Fair enough.
Still pr29586 seems to be a diagnostic bug since the warning is mangled:
$ cat blah.c
#warning (that's not
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-10-24 20:45
---
Subject: Bug 29393
Author: eedelman
Date: Tue Oct 24 20:45:29 2006
New Revision: 118011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118011
Log:
fortran/
2006-10-24 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-24 22:51
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
/mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/
-B/mnt/gnu/gcc/objdir/gcc/ -fclasspath=
-fbootclasspath=/mnt/gnu/gcc/objdir/hpp
a2.0w-hp-hpux11.11/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated
-fboot
strap-classes -g -O2 -fjni -findirect-dispatch -fno-indi
Because /usr/local/include is in the default include path, the include path and
the library path are not consistent. The consequence is that (unless the user
has modified the search paths with environment variables or switches) when some
version of a library is installed in /usr (e.g., provided by
We add an optimization phase in GCC, and our changes trigger GCC generates
incorrect code during the combine phase. GCC incorrectly combine three
instructions into two intructions:
from:
insn_1set (SI reg_a) (plus:SI (SI: reg_b) (const_int -1))
insn_2set (SI reg_c) (ashiftrt:
--- Comment #1 from dje at transmeta dot com 2006-10-25 02:23 ---
Re: "We think may be what wanted is:" ...
That's just off the cuff speculation. The curious things are:
- op1 is shifted outside the mode of the operation (0x3c << 31) (HOST_WIDE_INT
is 64 bits) and this value is the va
--- Comment #2 from dje at transmeta dot com 2006-10-25 02:41 ---
Thinking about it some more, disregard this (I think):
- nonzero_bits returns bits that may be one, not bits that are one, so it's not
clear this optimization is valid regardless of anything else
I _think_ this is the cu
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-25 03:07 ---
Revision 1.169 / (download) - annotate - [select for diffs] , Fri May 6
16:42:40 1994 UTC (12 years, 5 months ago) by kenner
Branch: MAIN
Changes since 1.168: +123 -91 lines
Diff to previous 1.168 (colored)
(simplif
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 03:08 ---
Actually it is a bug that the library is not picking up and not a GCC bug.
The library path is consistent with GCC's include path by default unless you
messed up something.
So this sounds like a bug in your installat
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-25 04:55 ---
Here is a more reduced (and cleaned up) testcase:
class ios_base{};
struct basic_ostream : virtual ios_base{};
namespace
{
struct Nullostream : basic_ostream{};
}
class In
{
In ();
Nullostream nullout;
};
In
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking
Summary|[4.3 Regression] tree check:|[4.2/4.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-25 05:09 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-25 05:17
---
I have isolated the problem in list_read.c and am working on a patch. It will
be a day or two.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 ---
_ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream
# _ZTI13basic_ostream = V_MAY_DEF <_ZTI13basic_ostream_16>;
# _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF
<_ZTIN33_G
--- Comment #9 from daney at gcc dot gnu dot org 2006-10-25 05:49 ---
Subject: Bug 29519
Author: daney
Date: Wed Oct 25 05:49:43 2006
New Revision: 118023
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118023
Log:
PR middle-end/29519
* rtlanal.c (nonzero_address_
89 matches
Mail list logo
