--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 06:17 ---
embedded ia64, that is a new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27051
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-06 06:14 ---
Yes this is just a stack overflow, I don't know if there is anything that cane
be done here since this is one of the reasons why -ftemplate-depth was added.
I don't know what the standard says about how this limit h
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-06 04:22 ---
32M is not a lot any more. So yes this is too little to compile this one
source so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from ian at airs dot com 2006-04-06 02:46 ---
Yes, true. I can get constant code by not producing BIT_FIELD_REF so early.
But that disables other worthy optimizations. I don't have a coherent patch
yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-06 01:33
---
(In reply to comment #9)
> FYI, this code looks OK to me on mainline, entering the loop at .L18:
Except for the fact the bit-fields that are looked at are constant :).
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from fitzsim at redhat dot com 2006-04-05 23:09 ---
There is another problem with how the AWT peer code is installed that we've run
into in Fedora Core. We sometimes want to ship multiple versions of GCJ. The
unversioned lib-java-awt-peer-gtk.so is installed in /usr/lib
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-05
23:08 ---
Subject: Re: g++ (3.3): ...Error: Field out of range (optimisation pb)
>What|Removed |Added
> ---
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from jason at gcc dot gnu dot org 2006-04-05 22:48 ---
Connected with PR 25915.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26612
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-05 22:48 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-05 22:47 ---
Subject: Bug 26625
Author: tromey
Date: Wed Apr 5 22:47:51 2006
New Revision: 112724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112724
Log:
libjava/classpath:
PR libgcj/26625:
* lib/Makef
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26612
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-05 22:43 ---
Subject: Bug 26625
Author: tromey
Date: Wed Apr 5 22:43:19 2006
New Revision: 112723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112723
Log:
libjava/classpath:
PR libgcj/26625:
* lib/Makef
--- Comment #7 from jason at gcc dot gnu dot org 2006-04-05 22:27 ---
I've changed the summary for 10591 such that this is no longer a duplicate.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from jason at gcc dot gnu dot org 2006-04-05 22:26 ---
The PCH problem with get_file_function_name is independent of the question of
giving anonymous namespace members internal linkage. We still need to give
them distinct names; we are giving up on address comparison of
--- Comment #16 from jason at gcc dot gnu dot org 2006-04-05 22:20 ---
Can't fix until more basic problems are resolved.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from cvs-commit at developer dot classpath dot org
2006-04-05 22:12 ---
Subject: Bug 26625
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Tom Tromey <[EMAIL PROTECTED]>06/04/05 22:12:01
Modified files:
.
--- Comment #4 from dol at reedcat dot net 2006-04-05 21:48 ---
Subject: RE: error during kernel FreeBSD 5.4 compilation
Maybe you are right.
This particular computer has only 32M of RAM.
Maybe this could be the reason of this issue?
dol@
> -Original Message-
> From: rguent
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-05 21:42 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-05 21:38 ---
One possible problem I see here is that the 'interestOps' of
a SelectionKeyImpl can change while getFDsAsArray is running.
There are a few possible fixes here, the simplest would be to
avoid having two loops in getFDs
--- Comment #3 from kargl at gcc dot gnu dot org 2006-04-05 21:25 ---
(In reply to comment #1)
>
> The other thing you should be doing is also trying to update the GCC version
> you have because 3.4.2 is over a year old now.
>
Andrew, he's using the version of gcc bundled with FreeBSD
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-05 21:16 ---
Actually what is happening here is that the stack is overflowing before hitting
the limit you set :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-05 21:14 ---
Created an attachment (id=11214)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11214&action=view)
Recursive template for error triggering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
When compiling foo.C using the command line g++ -ftemplate-depth-2 foo.C
the result is
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
instead of the expected
foo.C:3: error: template instantiation
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-05 21:11 ---
This:
cc: Internal error: Killed (program cc1)
hints at a out-of-memory condition or someone killing cc1. So I guess this is
invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27050
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 21:06 ---
Can you attach the preprocessed source?
reading http://gcc.gnu.org/bugs.html tells you how to get the preprocessed
source.
The other thing you should be doing is also trying to update the GCC version
you have becaus
--- Comment #2 from kargl at gcc dot gnu dot org 2006-04-05 20:50 ---
I sent a preliminary patch for this problem to fortran@
http://gcc.gnu.org/ml/fortran/2006-04/msg00084.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Given the following code:
float
abc(float a, float b)
{
return ((a - b) * 0.1);
}
Compiled with the -mno-sdata flag, the compiler still defines an .sdata item
for the floating constant 0.1, which causes problems for embedded systems
that rely on -mno-sdata meaning NO .sdata
This bug can be c
--- Comment #8 from bjkeen at super dot org 2006-04-05 20:11 ---
(In reply to comment #6)
> Can either one of you try the patch in PR 26015?
>
Putting
#define FRAME_POINTER_CFA_OFFSET(FNDECL) 0
as indicated in that patch, into config/avr.h seems to work, but it is also
necessary to s
U,N,S,U,B,S,C,R,I,,B,E
cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include
/usr/src/sys/i386/compile/SPIKE/opt_global.h -I. -I@ -I@/contrib/altq
-I/usr/include -finline-limit=8000 -fno-common
-I/usr/src/sys/i386/compile/SPIKE -mno-align-long-strings
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mn
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-05 19:14 ---
Always do a make check, this is the correct thing to do when checking the
compiler anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-05 18:55 ---
I checked in a fix to the 4.1 branch.
For svn trunk I am looking at a more complete merge with Classpath.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
Novita' assoluta!Nuovissimi occhiali da sole con lettore/registratore
MP3 incorporato ed i fantastici occhiali con BLUETOOTH incorporato!
Per ascoltare la Vs. musica preferita e per telefonare a mani libere
completamente SENZA CAVI!!!Per vedere questi gioielli tecnologici clicchi su;
http://1go.it
--- Comment #8 from mckinlay at redhat dot com 2006-04-05 18:43 ---
Fix checked in to Classpath HEAD and gcc-4_1_branch
--
mckinlay at redhat dot com changed:
What|Removed |Added
-
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-05 18:43 ---
Subject: Bug 27024
Author: tromey
Date: Wed Apr 5 18:43:15 2006
New Revision: 112715
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112715
Log:
libjava/classpath:
PR libgcj/27024:
* java/net/
--- Comment #7 from bryce at gcc dot gnu dot org 2006-04-05 18:41 ---
Subject: Bug 27028
Author: bryce
Date: Wed Apr 5 18:41:17 2006
New Revision: 112714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112714
Log:
2006-04-05 Bryce McKinlay <[EMAIL PROTECTED]>
PR class
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-04-05 18:38
---
*** Bug 26948 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 2006-04-05 18:38 ---
Yes this is a dup of bug 26197.
*** This bug has been marked as a duplicate of 26197 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 Regression] Insane |[4.1/4.2 Regression] Insane
|amount of memory neede
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-05 18:27 ---
Can you try 4.0.3? Otherwise just report this to Apple instead as you are
using Apple's hacked up Compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 ---
*** Bug 27022 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 ---
This was fixed by the patch which fixed PR 26992 so closing as a dup of that
bug.
*** This bug has been marked as a duplicate of 26992 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-05 17:29 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-05 17:25 ---
Subject: Bug 26996
Author: spop
Date: Wed Apr 5 17:25:26 2006
New Revision: 112711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112711
Log:
PR tree-optimization/26996
* tree-scalar-evolution.
--- Comment #90 from pinskia at gcc dot gnu dot org 2006-04-05 16:13
---
*** Bug 27045 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 16:13 ---
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-04-05 16:11
---
The main difference is the TYPE_DEPENDENT_P_VALID valid lang-type flag. So
this looks like a frontend problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-05 16:08 ---
This was fixed for the non windows case for sure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-05 16:05
---
Because they are not the same:
(gdb) call debug_generic_expr(0xb7e31c94)
struct noop_tD.2008
(gdb) call debug_generic_expr(0xb7e3505c)
struct noop_tD.2008
generated by
#0 build1_stat (code=NOP_EXPR, type=0xb7e3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 ---
*** Bug 27047 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 ---
*** This bug has been marked as a duplicate of 27046 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from graham dot stott at btinternet dot com 2006-04-05
16:00 ---
Subject: Re: c++ is generating incorrect optimized code for xor operations on
long long
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--- Comment #4 from graham dot stott at btinternet dot com 2006-04-05
16:00 ---
Subject: Re: c++ is generating incorrect optimized code for xor operations on
long long
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
p
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-04-05 15:47
---
> The bootstrap then completes successfully.
Wunderbar. :-)
> So: "make" fails, "make bootstrap" works, but the commands
> invoked are identical. Could it be that gcc 2.8.1 silently
> miscompiled cc1plus in the
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-05 15:44
---
Fixed on the mainline. Let's wait if the changed inlining causes regressions
before backporting.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-05 15:41
---
Subject: Bug 26919
Author: rguenth
Date: Wed Apr 5 15:41:18 2006
New Revision: 112709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112709
Log:
2006-04-05 Richard Guenther <[EMAIL PROTECTED]>
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
p
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** Bug 24632 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
---
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** This bug has been marked as a duplicate of 27028 ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--
--- Comment #4 from ludovic at ludovic-brenta dot org 2006-04-05 15:21
---
--enable-bootstrap=no + "make bootstrap" cause a successful build:
...
/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc/xgcc -shared-libgcc
-B/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc -nostdinc++
-L/export/
--
mckinlay at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com
|dot org
--- Comment #5 from mckinlay at redhat dot com 2006-04-05 15:19 ---
(In reply to comment #4)
> I would argue that Sun's implementation is correct in this case in the
> sense that hasNext() doesn't actually modify anything, only next() does.
Yeah, I agree - although you might get a bogus
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-04-05 15:18
---
After compilation:
g++ test.cpp req.cpp -O0
program works fine. After compilation with:
g++ test.cpp req.cpp -O2
it breaks with SIGABRT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
--- Comment #2 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17
---
Created an attachment (id=11213)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11213&action=view)
Implementation of RequestId
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17
---
Created an attachment (id=11212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11212&action=view)
File containing hash specifications
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
c++ is generating incorrect optimized code for xor operations on long long.
Version which is affected is:
g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Following (proper) code is inlined into bad assembly when optimization is
turned on:
namespace __gnu_cxx
{
/**
hash special
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-05 14:26 ---
It's hard to verify with this big (non-executable) testcase. Is there a chance
you can strengthen your claim?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
--- Comment #1 from ned at bike-nomad dot com 2006-04-05 14:17 ---
Created an attachment (id=11211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11211&action=view)
Preprocessed source demonstrating bug
Bug is at line 2585/2586 of attached file
--
http://gcc.gnu.org/bugzilla/
In the following code, in the loop at line 381 of jtagmkII.c (line 2586 of the
attached jtagmkII.i), msglen (and l, as I recall) contain incorrect values.
This only happens when optimization is turned on (-O2); it does not happen with
-O1. The code runs correctly when compiled with gcc-3.3 using op
--- Comment #6 from aph at gcc dot gnu dot org 2006-04-05 14:12 ---
As far as I can see this bug is in every version of gcj that has ever existed.
There is special code (in merge_string_cste()) to convert an integer constant
to a constant string for concatenation. However, there isn't
Building on Windows XPSP2, NTFS file system using MSYS 1.0.10.
If I don't specify --with-as to configure, the compilers (all) build well until
stage3. Only when the stage3 compiler starts building the Ada run time system,
it cannot find 'as' anymore:
rm -f ../stamp-gnatlib
touch ../stamp-gnatlib
--- Comment #12 from patchapp at dberlin dot org 2006-04-05 14:00 ---
Subject: Bug number PR26565
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00192.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:57
---
> (that's from GNAT 3.15p, binary distribution from AdaCore; but the
> compiler used to build strstream.cc is ./xgcc, i.e. GCC 4.1.0
> built in stage1. And, as I said, the same errors occur with
> --enable-bootst
root: gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
root: uname -a
FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD
6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/IB
--- Comment #5 from patchapp at dberlin dot org 2006-04-05 13:50 ---
Subject: Bug number PR26898
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00190.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-05 13:49 ---
I'm no longer working on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:48
---
I'm not working on this. Re-closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from ludovic at ludovic-brenta dot org 2006-04-05 13:47
---
$ make --version
GNU Make 3.80
Copyright (C) 2002 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
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-05 13:47 ---
This is mine. And I have a patch posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-05 13:42 ---
Fixed on the mainline - this problem is latent in 4.1, can you commit this
obviously safe patch there, too (though techically it might not be a
regression)?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:35
---
> As can be seen from the configure options, this is with GNU
> binutils 2.16.1.
What's the configure shell? What's the version of GNU make? What's the
bootstrap compiler?
> I also tried the Sun assembler and
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:29
---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #6 from hjl at gcc dot gnu dot org 2006-04-05 13:23 ---
Subject: Bug 26891
Author: hjl
Date: Wed Apr 5 13:23:35 2006
New Revision: 112701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112701
Log:
Correct PR number in ChangeLogs.
gcc/fortran/
2006-04-03 Paul Thom
--- Comment #5 from aph at gcc dot gnu dot org 2006-04-05 13:19 ---
I don't think this is a regression.
[EMAIL PROTECTED] ~]$ ~/gcc/install-4.0/bin/gcj -C z.java
z.java: In class 'z':
z.java: In method 'z.main(java.lang.String[])':
z.java:9: internal compiler error: Segmentation fault
P
$ ../gcc-4.1.0/configure --prefix=$HOME/opt/gcc-4.1.0.tmp
--enable-languages=ada,c,c++ --with-as=$HOME/opt/binutils-2.16.1/bin/as
--with-gnu-as --with-ld=$HOME/opt/binutils-2.16.1/bin/ld --with-gnu-ld
--enable-bootstrap=no
...
$ make
...
/export/home/lbre/src/gcc-4.1.0.o/./gcc/xgcc -shared-libg
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-05 13:01
---
Reduced testcase, compile with --param inline-call-cost=0
struct A
{
A() {}
};
struct B
{
A a;
B(A, int) {}
};
void foo()
{
B b(A(), 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
--- Comment #2 from spop at gcc dot gnu dot org 2006-04-05 12:33 ---
Subject: Bug 26996
Author: spop
Date: Wed Apr 5 12:33:06 2006
New Revision: 112700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112700
Log:
PR tree-optimization/26996
* tree-scalar-evolution.
--- Comment #7 from rguenther at suse dot de 2006-04-05 10:47 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
> > would be much better here. The question is of course, if the programmer
> > is allowed to write
> >
> > x + (size_t)-1
> >
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:39 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
> would be much better here. The question is of course, if the programmer
> is allowed to write
>
> x
--- Comment #5 from rguenther at suse dot de 2006-04-05 10:28 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > Umm. Correct :/ I guess the only way to "fix"
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:20 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
> > > Confirmed. That gives us a testcase at least.
> > >
> > > Now, back to the folding problem of
>
--- Comment #3 from rguenther at suse dot de 2006-04-05 10:13 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> Subject: Re: Unable to determine # of iterations
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:05 ---
Subject: Re: Unable to determine # of iterations for a simple loop
> Confirmed. That gives us a testcase at least.
>
> Now, back to the folding problem of
>
> PTR +- CST CMP PTR +- CST
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-05 09:57 ---
Confirmed. That gives us a testcase at least.
Now, back to the folding problem of
PTR +- CST CMP PTR +- CST
where all of PTR / CST are of pointer type naturally and unsigned usually.
The problem was that the
1 - 100 of 117 matches
Mail list logo
