--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-10 06:59 ---
More reduced testcase:
void baz (char *);
int c;
void
bar (void)
{
char a[2];
int *ip = &c;
char *p = a, *q = (char *) &ip;
const char *r = q + 2;
for (; q != r; p++, q++)
*p = *q;
baz (a);
}
--
h
--- Comment #4 from M dot Froehlich at science-computing dot de 2008-09-10
07:06 ---
Note that the code path in question is called with every
outputstream << std::endl;
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-10 07:10 ---
This is dse1 which turns:
(insn 5 2 7 2 P.c:8 (set (mem/f/c/i:DI (plus:DI (reg/f:DI 20 frame)
(const_int -24 [0xffe8])) [2 ip+0 S8 A64])
(symbol_ref:DI ("c") )) 89 {*movdi_1_rex64}
(
--- Comment #7 from irar at gcc dot gnu dot org 2008-09-10 07:20 ---
Subject: Bug 37385
Author: irar
Date: Wed Sep 10 07:18:52 2008
New Revision: 140195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140195
Log:
PR tree-optimization/37385
* tree-vect-transform.c
I get an ICE on PowerPC with the following code on a gcc svn checkout from this
morning:
gcc version 4.4.0 20080909 (experimental) (GCC)
# /root/gcc-installed/bin/g++ -O -ffast-math -c foo.cpp
foo.cpp: In member function void testcase::foo::doit(double, double, double):
foo.cpp:16: error: con
--- Comment #1 from anton at samba dot org 2008-09-10 07:35 ---
Created an attachment (id=16280)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16280&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
--- Comment #8 from irar at il dot ibm dot com 2008-09-10 07:48 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from grue at diku dot dk 2008-09-10 08:01 ---
Created an attachment (id=16281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16281&action=view)
The source mentioned in the bug description
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #2 from grue at diku dot dk 2008-09-10 08:01 ---
Created an attachment (id=16282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16282&action=view)
The statistics mentioned in the bug description
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-10 08:02 ---
Subject: Bug 37353
Author: jakub
Date: Wed Sep 10 08:00:40 2008
New Revision: 140208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140208
Log:
PR tree-optimization/37353
* tree-call-cdce.c (co
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-10 08:02 ---
It indeed uses about 1.4GB ram and takes 26s (I think that's reasonable) to
build the testcase. It's the DF initialize pass that requires this much
memory. The function in question has 31671 basic blocks. dfinish
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-10 08:04 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
If LANG=C this file (part of Ghostscript source) compiles, but when LANG=PL
compilation of it fails with given error:
W funkcji `imdi_tab,:
w pp_base_format, w pliku pretty-print.c:529
Proszê przes³aæ pe³ny raport o b³êdzie,
wraz z preprocesowanym zród³em, je¶li to odpowiednie.
Po wiêcej informacj
--- Comment #1 from piotr at eps dot gda dot pl 2008-09-10 08:07 ---
Created an attachment (id=16283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16283&action=view)
Preprocessed source which causes error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37457
--- Comment #2 from piotr at eps dot gda dot pl 2008-09-10 08:08 ---
Created an attachment (id=16284)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16284&action=view)
gcc output for test file (when LANG=PL)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37457
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-10 08:10 ---
On the trunk compile-time sky-rocketed there
in building the cgraph. Honza, what's going on there - it doesn't seem to
even finish ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target t
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-10 08:32 ---
*** This bug has been marked as a duplicate of 37095 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-10 08:32 ---
*** Bug 37167 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
The following code fails (worked with gcc 4.1.2)
template struct trait {
static const int level = 0;
};
template struct A {
struct B {
typedef T datatype;
datatype *data;
B *next;
};
B* LIST;
};
template struct trait< A > {
static const int level = 1+t
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-09-10 09:57 ---
With ENABLE_CHECKING we spend ages checking that there are no duplicated edges
in callgraph. Will fix it shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-10 10:02 ---
Now we spend eons in walking lexical blocks, since add_lexical_block called by
inliner walks till end of the chain.
Is the order of blocks important at all? (i.e. we don't insert them to proper
place anyway, just as
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-10 10:10 ---
You need something like:
program largeint
integer,parameter :: k10 = selected_int_kind(10)
integer(kind=k10) :: i10
i10 = 9223372036854775807_k10
write(*,*) huge(i10)==9223372036854775807_k10
end program larg
--- Comment #9 from jamborm at gcc dot gnu dot org 2008-09-10 10:11 ---
I've been away from computer for a rather long time so I could not check
earlier. However, the problem is indeed gone. Thanks Richi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
--- Comment #2 from tbm at gcc dot gnu dot org 2008-09-10 10:26 ---
I get the same on x86_64.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triple
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-10 10:33 ---
Can this be closed now??
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
With revision 140146 these tests passed.
>From revision 140155 and on, these tests have failed as follows:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/objc.dg/dg.exp ...
FAIL: objc.dg/super-class-2.m (internal compiler error)
FAIL: objc.dg/super-class-2.m (test for excess errors)
FAIL: objc.dg/
With current trunk (r140227)
(sid)972:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
linux-2.6-nfs4acl.i
fs/nfsd/nfs4acl.c: In function '_posix_to_nfsv4_one':
fs/nfsd/nfs4acl.c:229: internal compiler error: in find_or_generate_expression,
at tree-ssa-pre.c:2691
Please submit a full bu
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-10 11:32 ---
#0 0x0099c80d in ira_allocno_live_ranges_intersect_p (a1=0x33da8ae0,
a2=0x34395120) at ../../gcc/ira-conflicts.c:535
#1 0x0099ff0e in coalesced_allocno_conflict_p (a1=0x34e221b0,
a2=0x33da8ae0, relo
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-10 11:33 ---
> actually, I rather sure that gfortran gets it wrong. This would be a
> wrong-code
Unless it were accepts-invalid. (Which I don't think, see below.)
Unfortunately, I yesterday somehow completely missed the second CO
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-10 11:39 ---
And at -O0 we still need about 2GB (because of dataflow leaks?), otherwise we
seem fine compilation time wise
garbage collection: 0.92 ( 3%) usr 0.00 ( 0%) sys 0.93 ( 3%) wall
0 kB ( 0%) ggc
callgra
--- Comment #1 from tbm at cyrius dot com 2008-09-10 11:49 ---
Created an attachment (id=16285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16285&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37461
--- Comment #2 from tbm at cyrius dot com 2008-09-10 11:49 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
struct nfs4_ace
{
unsigned int flag;
};
void _posix_to_nfsv4_one (struct nfs4_ace *ace, short deny, int flags)
{
int eflag = (flags ? (0x0001 | 0x0008) : 0);
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-10 11:54 ---
FIXED on the trunk (4.4.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-10 11:55 ---
Subject: Bug 37420
Author: burnus
Date: Wed Sep 10 11:54:08 2008
New Revision: 140229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140229
Log:
2008-09-10 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-10 12:09 ---
> Unfortunately, they got it wrong and are rejecting my claim that the
> test is standard conforming.
See also: http://www.j3-fortran.org/doc/year/08/08-104r1.txt
Let's mark it as "diagnostic". I think the error mes
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-10 12:14 ---
The testcase no longer compiles on mainline for me because of syntax errors.
WOuld be possible to test newer compiler or have updated testcase?
Honza
--
hubicka at gcc dot gnu dot org changed:
What
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-10 12:26 ---
(In reply to comment #3)
> reduced:
>
> MODULE M1
> INTERFACE putaline
> MODULE PROCEDURE S1,S2
> END INTERFACE
> CONTAINS
> SUBROUTINE S1(I)
> END SUBROUTINE
> SUBROUTINE S2(F)
> END SUBROUTINE
> END MODULE
>
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-10 12:33 ---
(In reply to comment #3
resolve.c(check_host_association) explicitly excludes checking the symbol for
the procedure if it is use associated. It might just be that the check should
exclude symbols that are both hos
--- Comment #3 from Gottfried dot Ganssauge at haufe dot de 2008-09-10
12:35 ---
The error doesn't happen anymore with gcc-4.3 - at least not with the original
source file.
I would propose to close this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31811
--- Comment #7 from salam at lpthe dot jussieu dot fr 2008-09-10 13:24
---
That's great. I've tested it with the latest binary snapshot and it works very
nicely.
Thanks a lot for fixing this!
Gavin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
--- Comment #74 from lucier at math dot purdue dot edu 2008-09-10 13:39
---
This need for more memory is a regression from earlier versions of gcc.
Can this bug be marked with
[4.3/4.4 Regression]
in the subject line?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #8 from hjl at gcc dot gnu dot org 2008-09-10 14:15 ---
Subject: Bug 37434
Author: hjl
Date: Wed Sep 10 14:14:28 2008
New Revision: 140231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140231
Log:
gcc/
2008-09-10 H.J. Lu <[EMAIL PROTECTED]>
PR target/374
--- Comment #9 from hjl dot tools at gmail dot com 2008-09-10 14:18 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
Revision 140030 caused >10% 176.gcc performance regression
in SPEC CPU 2000 on Intel Core 2 running Linux/x86-64 with
-O2 -ffast-math.
--
Summary: [4..4 Regression] Revision 140030 caused >10% 176.gcc
regression
Product: gcc
Version: 4.4.0
--- Comment #7 from tbm at cyrius dot com 2008-09-10 14:43 ---
(In reply to comment #6)
> Please close if fixed
The ICE is still there (as of revision 140229).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #2 from spop at gcc dot gnu dot org 2008-09-10 14:48 ---
Subject: Bug 37388
Author: spop
Date: Wed Sep 10 14:46:35 2008
New Revision: 140232
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140232
Log:
2008-09-10 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
--- Comment #4 from dodji at gcc dot gnu dot org 2008-09-10 14:50 ---
At PDF page 115, 5.16.6 (conditional operator), the standard says:
"Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
standard conversions are performed on the second and third operands. Af
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-10 14:54 ---
I see the same problem with the program below:
implicit none
real, parameter :: r = 0.0
real(kind=8), parameter :: rd = real(b'&
&0100
--- Comment #8 from hjl dot tools at gmail dot com 2008-09-10 14:58 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Please close if fixed
>
> The ICE is still there (as of revision 140229).
>
Do you have a testcase for x86? The one in comment #1 works for me.
--
http:
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-10 14:59 ---
Honza suggested that
---
This mostl likely mean that your glibc has slow memset implementation.
I saw similar drop on SPEC2000 GCC and Debian machines used by
compilation farm. I was told that FSF glibc was finally
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-10 15:08 ---
Subject: Bug 37432
Author: rguenth
Date: Wed Sep 10 15:07:04 2008
New Revision: 140233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140233
Log:
2008-09-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-10 15:10 ---
Fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-10 15:10 ---
I think primarily we want to agree on what is and is not valid lvalue when
bitfields are involved.
int a;
int b;
struct A { int i:8; int j:8; int k:16; int l:32; } c;
void
foo (int x, int y)
{
(x ? a : b) = y;
(x
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-10 15:11 ---
Created an attachment (id=16286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16286&action=view)
a different patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-10 15:12 ---
Still happens.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2
--- Comment #9 from tbm at cyrius dot com 2008-09-10 15:13 ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> Do you have a testcase for x86? The one in comment #1 works for me.
Sure:
(sid)2206:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -
--- Comment #4 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
Sorry, ignore my Comment #3. It should have been posted to a different
bugzilla entry. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
--- Comment #10 from tbm at cyrius dot com 2008-09-10 15:14 ---
Created an attachment (id=16287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16287&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #2 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
With a mainline from today, it fails for me at -O2. Looking into it, it's
foo() that is miscompiled (I broke the 3 functions into their own files and
recompiled them), It's also the last element of results (ie, res
--- Comment #31 from paolo dot carlini at oracle dot com 2008-09-10 15:16
---
*** Bug 37453 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-10 15:16
---
Gentoo, right?
Note that the issue definitely does not affect widespread linux distributions,
as you can see from the successful build / testing results posted daily on the
testresults mailing list.
*** This
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-10 15:21 ---
If the whole testcase is supposed to be valid, we could have COND_EXPRs with
mismatching types in the FE and fix them up only during cp_genericize_r.
The ugly thing is that we'd violate:
Operand 1 must have the same
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-10 15:23
---
Yes, but frankly it's unlikely that in 4.4.0 timeframe, also given the ABI
constraints, we can change the libstdc++ implementation, which admittedly has
too much code inline in this area, enough to solve this p
--- Comment #12 from bangerth at dealii dot org 2008-09-10 15:26 ---
Still happens with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #7 from bangerth at dealii dot org 2008-09-10 15:30 ---
Still the same with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #6 from M dot Froehlich at science-computing dot de 2008-09-10
15:38 ---
(In reply to comment #5)
> Yes, but frankly it's unlikely that in 4.4.0 timeframe, also given the ABI
> constraints, we can change the libstdc++ implementation, which admittedly has
> too much code inli
--- Comment #5 from kargl at gcc dot gnu dot org 2008-09-10 15:42 ---
Daniel,
I looked at this briefly last week. Here's another test case that might be
easier to trace.
implicit none
real(4) r
real(8) rd
complex(8) z
rd =
dble(b'0100
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-10 15:54
---
I have a patch in testing which changes -O3 to be the same as -O2, essentially
I moved _M_narrow_init and _M_widen_init out of line. For further tweaks,
really after 4.4.0.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from spop at gcc dot gnu dot org 2008-09-10 16:06 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-10 16:08 ---
> -fdump-parse-tree gives
> ASSIGN MAIN__:rd 5.31837115e-315_8
> ASSIGN MAIN__:z (complex 5.3183711317956924e-315_8 0_8)
> ASSIGN MAIN__:r 0
> IF (/= MAIN__:z __convert_r8_c8[[((MAIN__:rd))]])
>
Now that i386-pc-solaris2.10 bootstraps again after the IRA merge, the first
testsuite run revealed that all eh tests fail, affecting at least the g++
tests,
ada/acats and libjava. The symptom is always the same; I take
FAIL: g++.dg/eh/alias1.C execution test
as an example.
Running alias1.exe u
--- Comment #8 from M dot Froehlich at science-computing dot de 2008-09-10
16:13 ---
Fine!
Thanks!
Mathias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455
--- Comment #1 from hp at gcc dot gnu dot org 2008-09-10 16:19 ---
Oops, pinskia is libobjc maintainer, not objc maintainer...
CC:ed the listed maintainers.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from paolo dot carlini at oracle dot com 2008-09-10 16:20
---
This is a regression, not horribly serious still a regression.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-10 16:25 ---
These constraints are supposed to be valid when in gimple, not generic. Maybe
the documentation in tree.def should reflect that (there is no generic type
system, if there was, it would be the much stricter that fold
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-10 16:48 ---
I verified that on Fedora 9 there is no regression between
revision 140029 and 140030 on Intel Core 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37462
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-10 16:48 ---
Works on Fedora 9.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Stat
--- Comment #10 from paolo at gcc dot gnu dot org 2008-09-10 16:49 ---
Subject: Bug 37455
Author: paolo
Date: Wed Sep 10 16:48:47 2008
New Revision: 140238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140238
Log:
2008-09-10 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #11 from paolo dot carlini at oracle dot com 2008-09-10 16:51
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #11 from hjl dot tools at gmail dot com 2008-09-10 17:16
---
(In reply to comment #10)
> Created an attachment (id=16287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16287&action=view) [edit]
> Preprocessed source
>
I can't reproduce it:
[EMAIL PROTECTED] gcc]$ ./
This is with revision 140005, on gcc30.fsffrance-gnu.org.
Just when I thought I had a big-endian machine :-)
make[4]: quittant le répertoire «
/home/tkoenig/gcc-bin/alphaev56-unknown-linux-gnu/libgcc »
make[3]: quittant le répertoire «
/home/tkoenig/gcc-bin/alphaev56-unknown-linux-gnu/libgcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-10 17:37 ---
THis part of the bootstrap failure was fixed by:
2008-09-02 Jakub Jelinek <[EMAIL PROTECTED]>
* config/alpha/alpha.c (va_list_skip_additions,
alpha_stdarg_optimize_hook, alpha_gimplify_va_arg_1): T
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-10 17:38 ---
Most likely related to PR 37426.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-10 17:51
---
It also works for me on i386-darwin with revision 140239 where it failed with
revision 139912. I will reduce the testcase that Martin added and then commit
it to the testsuite since I see there was no testcase ad
--- Comment #5 from janis at gcc dot gnu dot org 2008-09-10 17:52 ---
I made some mistakes in my previous comments; -ftree-fre is part of -O1, and
what I meant to say is that calculix gets wrong results for "-O1 -ffast-math"
but correct results for "-O1 -fno-tree-fre -ffast-math.h". The
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-10 17:58
---
> This is with revision 140005, on gcc30.fsffrance-gnu.org.
> Just when I thought I had a big-endian machine :-)
Even if it bootstrapped, you wouldn't have one. :-) Try SPARC instead.
--
ebotcazou at gcc dot
: internal compiler error: in set_mem_alias_set, at
emit-rtl.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
gcc version 4.4.0 20080909 (experimental) [trunk revision 127646] (Debian
20080910-1)
--
tbm at cyrius dot com changed:
What
class A {
virtual int B() { return 0; }
};
class B: A {
B() { }
};
gives an error, but should compile (as gross as it is). I'm hoping there is a
prohibition against it, but didn't find one.
--
Summary: ctors never override virtual functions
Product: gcc
Vers
--- Comment #10 from tbm at cyrius dot com 2008-09-10 18:03 ---
Err, wait a sec.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
--- Comment #11 from tbm at cyrius dot com 2008-09-10 18:06 ---
Sorry, my "20080910" build really was 20080909. I can confirm it's fixed.
--
tbm at cyrius dot com changed:
What|Removed
--- Comment #13 from tbm at cyrius dot com 2008-09-10 18:09 ---
Sorry, I made a mistake. I used a tar ball from yesterday instead of the
new tar ball from today I prepared...
Yes, it's fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-10 18:12
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2008-09-10
18:18 ---
Indeed, can be closed - thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
--- Comment #1 from mrs at apple dot com 2008-09-10 18:28 ---
radr://6202462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37465
1 - 100 of 132 matches
Mail list logo
