--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-03-30 07:58
---
> Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR
> for this type of Unchecked_Conversion. So already on my plate.
I think it's worse, the problematic function reads:
function c
On bootstrapping, fix-header segfaults while processing
/usr/include/bits/stdio-ldbl.h which is from glibc-2.4.
This problem does not appear on i386-linux host because 'use_fixproto' is set
to 'no' in gcc/config.gcc.
Reduced problematic header contents:
f()
Reproduce:
cd /gcc
make stmp-f
--- Comment #30 from mckinlay at redhat dot com 2006-03-30 07:00 ---
Created an attachment (id=11161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11161&action=view)
patch implementing GC_register_my_thread
Here's a patch that fixes this by adding functions to the GC that allow t
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:39
---
Jeff, please put PR numbers in your ChangeLog entries, thanks.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:20
---
> Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3.
Thanks. Victory, at last something obviously broken. :-) The file reads:
integer, parameter :: c = 0
type (int_info), paramet
--- Comment #6 from malitzke at metronets dot com 2006-03-30 03:54 ---
Yep, it just passed that stage and seems to be well on its way. Thanks, you do
the paperwork.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #5 from malitzke at metronets dot com 2006-03-30 03:48 ---
I just did an svn update and there is an rs6000/constraints.md updated. So, let
us keep our fingers crossed while I do new bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #1 from sayle at gcc dot gnu dot org 2006-03-30 01:35 ---
Subject: Bug 22494
Author: sayle
Date: Thu Mar 30 01:35:22 2006
New Revision: 112529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112529
Log:
PR c++/22494
* init.c (build_vec_delete_1): Conv
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 01:10 ---
I just was able to build this without any troubles ;).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-30 01:07 ---
The patch that Lee checked in removed checks for extra_warnings before the
calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are
restored then the five test cases listed in this PR and in 2611
--- Comment #3 from malitzke at metronets dot com 2006-03-30 01:07 ---
Using an older version of gcc-4.2.0 gave essentially the same error message as
in the original description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
--- Comment #7 from janis at gcc dot gnu dot org 2006-03-30 01:06 ---
The patch that Lee checked in removed checks for extra_warnings before the
calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are
restored then the five test cases listed in this PR and in 2611
werpc-slackware-linux-gnu --target=powerpc-slackware-linux-gnu
--build=powerpc-slackware-linux-gnu --enable-languages=c,c++,fortran,java
--with-cpu=7450 --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 20060329 (prerelease)
/usr/libexec/gcc/powerpc-slackware-linux-gnu/4.1.1/collect2 --eh-fram
--- Comment #4 from rankincj at yahoo dot com 2006-03-29 23:44 ---
Subject: Re: Compile/link failure with -frepo and g++ 4.1
--- pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote:
> Can you try a GCC which was released by the FSF and not a redhat modified one?
> If it works ther
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-29 23:22 ---
Can you try a GCC which was released by the FSF and not a redhat modified one?
If it works there, please report this to Redhat. Note this should have been
reported first to redhat and not here since you are using a
--- Comment #1 from dje at gcc dot gnu dot org 2006-03-29 23:15 ---
in progress
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dje at gcc dot gnu dot org
GCC build triplet|powerpc-slackware-linux
build/genpeep ../../gcc-4.2.0/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-peep.c
../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: error: undefined
machine-specific constraint at this point: "W"
../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: note: in operand 1
..previous 2
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-29 22:39 ---
I tried this today with svn head.
The test program still prints 'false' no matter how I run it:
gij, compiled, or compiled with the BC ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
--- Comment #11 from malitzke at metronets dot com 2006-03-29 22:24 ---
Maybe I should keep my mouth shut.
However, gcc-4.2.0 2006329 again compiles pari-2.1.7 OK. 2nd However,
pari-2.2.12.beta uses a different approch, which does not give any problems
with various gcc-4.2.0. At least th
--- Comment #28 from quanah at stanford dot edu 2006-03-29 22:12 ---
Created an attachment (id=11160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11160&action=view)
selected_int_kind.inc
Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3.
--
http://
--- Comment #5 from quanah at stanford dot edu 2006-03-29 21:49 ---
Yep. That's how f951 was getting linked to gmp. I'm going to make gmp only be
static, however, and see if that changes things.
I'm going to have to defer further work on both these bugs until next week. I
had a very
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 21:48 ---
Really mark as fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 21:45 ---
This was fixed by the patch for PR 26901.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 21:42 ---
Fix checked in, please give it a try.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-29 21:33 ---
Subject: Bug 26901
Author: tromey
Date: Wed Mar 29 21:33:08 2006
New Revision: 112510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112510
Log:
PR gcc/26901:
* Makefile.in: Rebuilt.
*
--- Comment #1 from ivan at vmfacility dot fr 2006-03-29 21:18 ---
Created an attachment (id=11158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11158&action=view)
Runnable program demonstrating the problem
This program, once compiled for powerpc64 and run on powerpc64 demonstrat
--- Comment #14 from bsdfan3 at users dot sourceforge dot net 2006-03-29
21:14 ---
GCC 3.4.4 on Cygwin actually breaks. The .ii file looks normal, however, it
seems to be segfaulting...I'll try the testcase with mainline shortly.
$ gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-29 21:14
---
> Actually, the problem has nothing to do with using /bin/sh, because I get the
> same failure using /bin/ksh, too:
OK, but given that you're the first who reports that kind of problems, we're
pretty much in the
This actually occurs on 3.3.3 and 4.0.3 (haven't tried others).
When a structure contains a 32 bit int, and because of alignement, it is not
located on a 64 bit boundary *and* (apparently) the compiler aligns a bitfield
int on the first fullword, operations on that bitfield implicitly access the
v
--- Comment #2 from rankincj at yahoo dot com 2006-03-29 21:10 ---
The sample code works OK with the following compilers:
$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--enable-share
--- Comment #2 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:42 ---
Fixed on autovect.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
---
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:40 ---
Fixed on autovect.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
---
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
20:39 ---
Fixed by the recent changes.
--
sebastian dot pop at cri dot ensmp dot fr changed:
What|Removed |Added
-
--- Comment #3 from cvs-commit at developer dot classpath dot org
2006-03-29 20:28 ---
Subject: Bug 26901
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Tom Tromey <[EMAIL PROTECTED]>06/03/29 20:24:37
Modified files:
.
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-29 20:22 ---
In order to do this we should avoid building tools.zip
and instead directly build executables.
(If we need a java archive for some reason, it should be a
jar, anyway.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-29
19:53 ---
Subject: Re:
../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1:
fatal error
> There are 2 parts to this bug.
>
> First, there's no reason to build tools.zip in
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 19:43 ---
There are 2 parts to this bug.
First, there's no reason to build tools.zip in the gcj build (yet).
Second, upstream classpath should pass an explicit -encoding when
invoking the java compiler.
I'm working on these.
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-03-29 19:39
---
Btw, the testcase crashes when compiles with "g++ -O":
PR26919.cc:119: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:106
Please submit a full bug report, [etc.]
--
http://gc
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-03-29 19:38
---
Created an attachment (id=11157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11157&action=view)
Reduced testcase
Reduced testcase.
--
reichelt at gcc dot gnu dot org changed:
What|Remov
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-29 19:37
---
Confirmed.
The testcase still involves long template parameter lists, but that seems
to be part of the problem: I removed some of them, but then the testcase
compiles.
--
reichelt at gcc dot gnu dot org change
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:35 ---
It also works with "4.2.0 20060321".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26928
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:34 ---
t.c:9: warning: implicit declaration of function 'log2'
t.c:9: warning: incompatible implicit declaration of built-in function 'log2'
Please next time use -W -Wall before reporting a bug report as requested by:
http
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-03-29 19:31 ---
Fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-03-29 19:30
---
Really closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-03-29 19:29 ---
Fixed on 4.1. Closing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
--- Comment #66 from pinskia at gcc dot gnu dot org 2006-03-29 19:26
---
*** Bug 26923 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 2006-03-29 19:26 ---
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-29 19:25 ---
The warning mess has been corrected:
t.c: In function 'main':
t.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has
type 'long long int:33'
This is not a bug, GCC is correct in warning.
--- Comment #1 from pluto at agmk dot net 2006-03-29 19:23 ---
...and the current 4.2.0 ICEs on this testcase:
$ ./xgcc -B. 26915.c -m32 -march=i686
26915.c: In function ‘minus1’:
26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block
26915.c:1: error: bb_for_stmt (stmt) is
gcc-4.2.0-20060323 / rev.112317
$ testcase:
void test(double x) { if (x > 0.0); }
$ ./xgcc -B. bug.c -c -m32 -march=i686
bug.c: In function 'test':
bug.c:7: internal compiler error: in bsi_last, at tree-flow-inline.h:760
it works with 4.1.1.
--
Summary: ICE in in bsi_last, at tree
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-29 19:15 ---
This is correct behavior.
The template is the only thing the first template sees when it calls add_field
as there are no dependent arguments.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #8 from mckinlay at redhat dot com 2006-03-29 19:00 ---
Created an attachment (id=11156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11156&action=view)
Test Case
New version of the test case, which tests both public and private method
invocation.
--
http://gcc.g
--- Comment #7 from mckinlay at redhat dot com 2006-03-29 18:59 ---
With a public call, as in the current test case, it is "only" about 2.5X slower
than HotSpot for me:
$ ./a.out
public call: 499 ms
private call: 7344 ms
$ java RefTest3
public call: 182 ms
private call: 808 ms
Private
Most likely this bug was reported before; but I couldn't seem to find it in
this database. So, just in case. The bug is with gcc 3.3.5; I know 3.4.4 works
fine.
=== test
#include
#include
int main() {
int g_size = 8;
int dim;
double dd;
dd = log2(g_siz
--- Comment #1 from pluto at agmk dot net 2006-03-29 18:51 ---
It's not a gcc bug. The code relies on the results of intermediate
subexpressions. According to Stroustrup, The C++ Programming Language, section
6.2.2, "The order of evaluation of subexpressions within
an expression is unde
--- Comment #3 from quanah at stanford dot edu 2006-03-29 18:45 ---
Actually, the problem has nothing to do with using /bin/sh, because I get the
same failure using /bin/ksh, too:
/bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-srk-inc.sh
'/afs/ir.stanford.edu/src/pubsw/languages/gcc-buil
While working on the long double 128 bits with Jakub, it was pointed out that
some of the libmath work in libstdc++ is incorrect.
In particular, platforms like ppc32 are doing some bogus exports. Mostly, this
is because on certain platforms,
sizeof(double) == sizeof(long double)
and so, there
--- Comment #6 from mark at gcc dot gnu dot org 2006-03-29 18:14 ---
TYhis bug is now closed but I wanted to add the following link for the
archives. A couple of these denial of service attacks by taking locks were in
the examples of Sascha's GNU Classpath Security talk at Fosdem 2004:
h
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 18:12 ---
Things look even worse with svn head (4.2 atm)...
either with gij or precompiled, the test case shows
invocations about an order of magnitude slower than the JDK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 17:52 ---
I now agree with comment #4.
I don't think this is a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from pbrook at gcc dot gnu dot org 2006-03-29 17:44 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-29 17:40 ---
Excellent job Paolo! Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
--- Comment #10 from spop at gcc dot gnu dot org 2006-03-29 17:20 ---
Subject: Bug 26859
Author: spop
Date: Wed Mar 29 17:20:24 2006
New Revision: 112502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112502
Log:
PR tree-optimization/26859
* tree-ssa-loop-niter.c
--- Comment #4 from janis at gcc dot gnu dot org 2006-03-29 17:12 ---
The gfortran torture tests also need to support dg- options, starting with
dg-final to allow cleaning up module files from the testsuite temporary
directory.
--
janis at gcc dot gnu dot org changed:
Wha
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-29 17:03
---
Created an attachment (id=11155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11155&action=view)
Smaller testcase
Will continue reducing if nobody beats me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 16:44 ---
Note that we need more mauve tests in this area before fixing the problem.
The current tests don't catch the bug(s).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-29 16:36 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
A peace of my code uses the two next macros (SWAP and InvSwap) to swap bytes,
it worked for a long time under gcc-3.3 but not under gcc-4.0.3
under gcc-3.3:
InvWord(0xABCD) = 0xCDAB
under gcc-4-0.3:
InvWord(0xABCD) = 0xCD00
FILE STARTS HERE ##
#define SWAP(x
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-29 16:32 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 29 16:31:53 2006
New Revision: 112499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112499
Log:
gcc/java
PR java/26390:
* parse.y (find_most_s
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-29 16:05
---
Reducing.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-29 15:45 ---
Created an attachment (id=11154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11154&action=view)
patch
I have a simple patch for # iterations analysis to check whether either cond1
follows from cond2 or !cond
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-29 15:44
---
Confirmed.
Reduced testcase (compile with "g++ -fopenmp"):
===
struct A
{
~A() throw();
};
void foo(A);
A bar() throw();
void baz()
{
#pragma omp parallel
{ A a; foo(ba
--- Comment #1 from rankincj at yahoo dot com 2006-03-29 15:36 ---
Created an attachment (id=11153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11153&action=view)
Source code to demonstrate -frepo failure.
My host machine is a i686-pc-linux-gnu machine; g++-3.4.4 compiles this j
--- Comment #2 from kreckel at ginac dot de 2006-03-29 15:36 ---
Created an attachment (id=11152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11152&action=view)
program causing ICE preprocessed with -P -E
I now see that this is not vanilla boost 1.33.1 but one which contains an
Executable fails to compile with -frepo using g++ 4.1
g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--- Comment #9 from pbrook at gcc dot gnu dot org 2006-03-29 15:21 ---
Subject: Bug 23623
Author: pbrook
Date: Wed Mar 29 15:21:13 2006
New Revision: 112493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112493
Log:
2006-03-29 Paul Brook <[EMAIL PROTECTED]>
PR middle-
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 15:12 ---
The first time we lay out the type, we have the fields reversed.
See parse.y:java_reorder_fields. I don't know why this happens.
(We construct the field list in reverse order, presumably for
efficiency. What is uncl
--- Comment #3 from bugzilla at hburch dot com 2006-03-29 14:59 ---
#include
struct s {
long long int a : 33;
};
struct s foo = {0};
int main(void) {
printf ("%lld\n", foo.a);
return 0;
}
produces the following output using "gcc -Wall -o a a.c" for same syste
--- Comment #2 from bugzilla at hburch dot com 2006-03-29 14:54 ---
Created an attachment (id=11151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11151&action=view)
Bundle for Mac OS X
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
--- Comment #1 from bugzilla at hburch dot com 2006-03-29 14:54 ---
Created an attachment (id=11150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11150&action=view)
Bundle for Linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
When compiled under Linux, at least, gcc 3.2.3 appears to pass a long long bit
field to a variadic function as a long. In particular, if you say "printf
("%lld", s.a)", where s.a is a long long bit field, s.a appears to only pass a
long.
The resulting assembly reads (for a 3 bit long long field):
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:19 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:13 ---
Can you attach preprocessed source please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
--- Comment #12 from uros at kss-loka dot si 2006-03-29 14:08 ---
(In reply to comment #11)
> it looks like 4.1.1 and 4.2.0 still produce unoptimal code.
> test: pushl %ebp
> movl%esp, %ebp
> fldl8(%ebp)
> fldz
> fcomip %st(1), %st
>
When I try to build a program using static libraries, I get errors -
[dranta:~/tests] dir% gfortran -o print print.f
[dranta:~/tests] dir% gfortran -o print print.f -Wl,-static
/usr/bin/ld: only one of -static or -dynamic can be specified
[dranta:~/tests] dir% gfortran -static -o print print.f
/us
The following piece of code causes an ICE at ipa-inline.c:106 as soon as
optimization is turned on. I can reproduce it using BOOST 1.32.0 and 1.33.1. It
used to work previously (at least as of GCC 3.4.3).
#include
#include
#include "boost/lambda/lambda.hpp"
#include "boost/lambda/bind.hpp"
str
Compiling a valid C++ file with -frepo and then editing the file
introducing bugs and then recompiling the file causes trouble:
For example:
Create the file "bug.cc" with the contents
===
int i;
===
Compile this file with "g++ -frepo -c bug.cc".
Then change the file to
=
It seems that template function overloading/argument dependent lookup now
depends on declaration order. If this is right or not I don't know yet, but it
changed without notice. consider this small piece of code:
#include
#include
#include
template void add_field(T const & value) {
static in
double minus1() { return -1.0; }
.LC0:.long 3212836864
minus1: flds.LC0
ret
for -Os gcc should use `fld1;fchs'.
--
Summary: missed optimization / returning -1.0
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity:
--- Comment #5 from zerocool at modemsoft dot it 2006-03-29 10:30 ---
(In reply to comment #4)
OK now i try this and after i tell you the resul, hoping in the lucky :-)
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
flags: -O2 -ffast-math -march=i686 -fomit-frame-pointer
double signum_dbl_gcc( double x )
{
if ( x < 0.0 )
return -1.0;
if ( x > 0.0 )
return 1.0;
return 0.0;
}
.LC1: .long 3212836864
signum_dbl_gcc:
fldz
fldl4(%esp)
fcomip %st(1), %st
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-03-29 10:06 ---
It would be difficult for those of us without alpha-linux boxes to track
this problem down. If you're willing, you can try to track the failure
to a certain bit yourself.
Let's stick with the GCC 4.2 snapshot as tha
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 09:32 ---
Confirmed.
struct Foo {
template int func() ;
};
class Bar {
friend int Foo::func() const ; // line 6
};
is also invalidly accepted.
--
rguenth at gcc dot gnu dot org changed:
What|Remove
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:11 ---
Subject: Re: Number of iterations not know for simple loop
> > I thought if we know that we are looking at the loop header copy condition
> > that
> > we _know_ that the loop runs at least on
I get a ICE in g++ for the following code when compiled with -fopenmp and -O2:
#include
int foo()
{
int x1;
#pragma omp parallel
{
for (int i = 0; i < 5; ++i) {
std::string xxx;
}
}
return 0;
}
Note that thi
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-29 09:01 ---
Subject: Re: Number of iterations not know for simple loop
> I thought if we know that we are looking at the loop header copy condition
> that
> we _know_ that the loop runs at least once, so
--- Comment #3 from zerocool at modemsoft dot it 2006-03-29 08:17 ---
Premising that I have unloaded the last available snapshots on the site and
that is:
gcc-4.2-20060325.tar.bz2,gcc-4.1-20060324.tar.bz2,gcc-4.0-20060323.tar.bz2
Well i make two test yesterday with this result :
First r
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-29 08:05 ---
I'm unable to produce a testcase where we "regress" from 4.0 or earlier, so
closing as fixed in 4.2.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 101 matches
Mail list logo
