gcc 4.1.0 rc1 failes to bootstrap on my amd64 gentoo-box; the last release
gcc-4.1.0-20060217 bootstraps fine so it seems to be rc1 and not my gentoo
setup.
../gcc-4.1.0-20060219/configure --prefix=/home/xtv --program-prefix=x
--program-suffix=41rc1 --enable-languages=c,c++,objc,obj-c++,fortran
--- Comment #4 from mtodorov at alu dot hr 2006-02-20 08:18 ---
Subject: Re: LROTATE_EXPR/RROTATE_EXPR misexpanded by
middle-end/back-end for bitfields
On Thu, 16 Feb 2006, steven at gcc dot gnu dot org wrote:
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-16
--- Comment #6 from dn dot tlp at gmx dot net 2006-02-20 08:20 ---
(In reply to comment #5)
I got the same problems for gcc-3.4.3. I fixed the iovec error by inserting
struct iovec {
void *iov_base;
size_t iov_len;
};
ssize_t writev (int filedes, const struct iovec
--- Comment #10 from walter dot zimmer at dlr dot de 2006-02-20 08:23
---
(In reply to comment #9)
Negative. The following valid code still fails on i386:
Strange: with gfortran gcc-4.1-20060210+fix x86_64-unknown-linux-gnu
it compiles and runs fine:
bash gfortran gfcbug31.f -Wall
--- Comment #6 from bonzini at gnu dot org 2006-02-20 08:29 ---
Subject: Bug 25476
Author: bonzini
Date: Mon Feb 20 08:29:17 2006
New Revision: 111295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111295
Log:
2006-02-20 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #6 from bonzini at gnu dot org 2006-02-20 08:29 ---
Subject: Bug 25670
Author: bonzini
Date: Mon Feb 20 08:29:17 2006
New Revision: 111295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111295
Log:
2006-02-20 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #5 from bonzini at gnu dot org 2006-02-20 08:35 ---
Fixed by patch for bugs 25670 and 25476
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2006-02-20 08:35 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from bonzini at gnu dot org 2006-02-20 08:36 ---
Please confirm that your usual command-lines work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25670
--- Comment #1 from themis_hv at yahoo dot co dot uk 2006-02-20 09:19
---
GCC here is expecting ld to be located at /home/xtv/bin/xld
Try adding --with-ld=/path/to/ld and --with-as=/path/to/as to configury
See if this makes any difference
--
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-20 09:26 ---
Subject: Bug 26334
Author: jakub
Date: Mon Feb 20 09:26:29 2006
New Revision: 111297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111297
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved
--- Comment #2 from xtv at tveith dot homelinux dot com 2006-02-20 09:52
---
(In reply to comment #1)
GCC here is expecting ld to be located at /home/xtv/bin/xld
Try adding --with-ld=/path/to/ld and --with-as=/path/to/as to configury
See if this makes any difference
The
Description:
We are targetting the compilers for a system-on-chip solution we are
developing based on an ARM 926 which is without an FPU so we have
defaulted on SOFTWARE FLOATING POINT.
#define TARGET_DEFAULT (ARM_FLAG_SOFT_FLOAT | ARM_FLAG_APCS_32 | \
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-02-20 10:51
---
*** This bug has been marked as a duplicate of 26337 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-02-20 10:51
---
*** Bug 26378 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
#include mmintrin.h
void
foo (__m64 *p)
{
__m64 m;
m = p[0];
m = _mm_srli_pi16(m, 2);
m = _mm_slli_pi16(m, 8);
p[0] = m;
_mm_empty();
}
ICEs with both -O2 -m32 and -O2 -m64, in GCC 4.0.2, 4.1rc1 as well as trunk.
--
Summary: ICE on vector shift RTL simplification
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-20 11:01 ---
Obviously with -O2 -m32 -mmmx for 32-bit compiles.
The testcase compiles in GCC 3.2.3 and 3.4.5, so a regression.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-02-20 11:15 ---
... but DR 342 should be also taken into account...
--
pcarlini at suse dot de changed:
What|Removed |Added
Hello,
gcc 3.4.3 compiles and links the following code successfully:
#include iostream
class X
{};
template typename T
void g (const T t)
{
std::cout Function g was called std::endl;
}
template typename T
voidf()
{
T a;
gtypename S(a); //
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
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 #3 from xtv at tveith dot homelinux dot com 2006-02-20 12:33
---
Without --program-prefix it bootstraps fine. So it seems to be a problem with
the configure-machinery.
Shall I close this bug and open a new one regarding configure?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 12:52 ---
It did work at least in 4.1.0 20051026.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 12:57 ---
Fixed in 3.4.5 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 13:06 ---
If this worked with 20060217 and does not with the RC1, this actually does
not make sense as there have been no configuring changes made between that
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #5 from themis_hv at yahoo dot co dot uk 2006-02-20 13:12
---
--program-prefix works fine on i686-pc-linux with GCC 4.1.0 RC 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
gcc-4.1.0-20060219.tar.bz2 won't untar with Solaris native tar.
x gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks, 0
bytes, 0 tape blocks
x
gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks/OneSub.framework,
0 bytes, 0 tape blocks
x
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 13:51 ---
Please read:
http://gcc.gnu.org/install/prerequisites.html
GNU tar version 1.12 (or later)
Necessary (only on some platforms) to untar the source code. Many systems' tar
programs will also work, only try GNU tar if
--- Comment #5 from ben dot midgley at ultra-datel dot com 2006-02-20
14:21 ---
I believe this is the same problem, if not it is a very similar and likely
related problem. I have nested the data types from the first code into an array
and have a similar message.
$ gcc -v
Using
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from pcarlini at suse dot de 2006-02-20 14:24 ---
Suspended, waiting for 342 (now reopened) to reach the final resolution.
--
pcarlini at suse dot de changed:
What|Removed |Added
Hi,
We have found a bug for SuperH when trying for crossjumping and
-fif-conversion2 for gcc-3.4.4 and gcc-3.4.5.
Following is the simple test case,
//xfs2.c
1. void func (void)
2. {
3.if (foo3())
4. {
5.
--- Comment #3 from bonzini at gnu dot org 2006-02-20 14:46 ---
Note for posterity, a better patch for this has been inserted as part as fixing
PR12730, and this patch has been sort of reverted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12512
--- Comment #9 from bonzini at gnu dot org 2006-02-20 14:47 ---
Just for the record, this patch also fixed PR12512 in a better way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12730
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-20 15:05 ---
Subject: Bug 26236
Author: sayle
Date: Mon Feb 20 15:05:15 2006
New Revision: 111305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111305
Log:
PR middle-end/26236
* doc/c-tree.texi
--- Comment #3 from roger at eyesopen dot com 2006-02-20 15:05 ---
Fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-02-20
15:25 ---
(In reply to comment #1)
Confirmed, I think Paul Thomas is looking into this.
Yes, I got sidetracked into it!
Something is awry with the adding of variables to an equivalence segment in
anything other
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
This is indeed a dup of 19543 (at least, it's fixed by the same patch).
*** This bug has been marked as a duplicate of 19543 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
*** Bug 20066 has been marked as a duplicate of this bug. ***
--
Bug 19543 depends on bug 20066, which changed state.
Bug 20066 Summary: Ordering of logical constants determines if they're
correctly emitted
--- Comment #6 from jv244 at cam dot ac dot uk 2006-02-20 16:13 ---
#4 0x006714fb in compensate_edge (e=0x2a959776c0, file=0x0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:2795
this assert was last modified by nathan (from svn ann, revision 87244), who
seems to be
--- Comment #7 from nathan at gcc dot gnu dot org 2006-02-20 16:24 ---
I'm guessing my change was in converting an if () abort () into gcc_assert, and
not directly to blame for whatever's happening here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
--- Comment #8 from jv244 at cam dot ac dot uk 2006-02-20 16:32 ---
(In reply to comment #7)
I'm guessing my change was in converting an if () abort () into gcc_assert,
and
not directly to blame for whatever's happening here.
Looks like you're right... I must have been reading too
gcc version 4.1.0 20060219 (prerelease) produces spurious warnings when
used with -Wall and -O3 together. Previous released versions haven't had this
behaviour. It appears to be issuing multiple warnings when string functions are
inlined using the __builtin_ versions eg __builtin_strcmp. For
--- Comment #1 from andrew dot m dot roberts at tesco dot net 2006-02-20
16:41 ---
Created an attachment (id=10880)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10880action=view)
gcc -v -save-temps -O3 -Wall output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26383
--- Comment #1 from dorit at il dot ibm dot com 2006-02-20 16:45 ---
Looks like the vectorizer detects a strided access in this testcase. Strided
accesses are not entirely supported for SSE right now (work in progress...),
but it is enabled, so currently all strided testcases brake on
--- Comment #2 from dorit at il dot ibm dot com 2006-02-20 17:09 ---
Actually there's this patch by rth that seems to fix this ICE; it's from a
while back, I don't think it was fully tested at the time, and I'm not sure it
provides all the missing bits/fixes for SSE support.
===
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 17:17 ---
This is really a glibc bug as far as I can tell.
Lets look into what glibc exands the string functions to:
i=__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (data)
__builtin_constant_p (s)
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-20 17:35
---
If make all-gcc works, I am happy so this is a dup of bug 25670.
*** This bug has been marked as a duplicate of 25670 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-20 17:35 ---
*** Bug 25455 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from hjl at lucon dot org 2006-02-20 17:46 ---
A testcase patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01391.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Subject: Bug 25879
Author: pinskia
Date: Mon Feb 20 17:47:34 2006
New Revision: 111308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111308
Log:
2006-02-20 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/libgomp/testsuite/libgomp.c/appendix-a/a.18.1.c
-B/mnt/
gnu/gcc-3.3/objdir/hppa64-hp-hpux11.11/./libgomp/
-I/mnt/gnu/gcc-3.3/objdir/hppa
64-hp-hpux11.11/./libgomp
--- Comment #4 from janis at gcc dot gnu dot org 2006-02-20 18:12 ---
I got a regression hunt started but lost contact with the system it's running
on; network problem? If I can't get back to that system I'll set up somewhere
else and try again.
The failure also occurs with mainline
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 18:22 ---
There is not enough information here to reproduce really and the directions
were not followed at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jb at gcc dot gnu dot org 2006-02-20 18:34 ---
With this fix, trunk is now once again able to compile VASP. Too bad it seems
to be a bit late to get into 4.1. Maybe 4.1.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-20 18:36
---
(In reply to comment #10)
With this fix, trunk is now once again able to compile VASP. Too bad it seems
to be a bit late to get into 4.1. Maybe 4.1.1?
Actually it looks like it was approved for 4.1 (after RC1
--- Comment #57 from aoliva at gcc dot gnu dot org 2006-02-20 18:37 ---
This should have long been closed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from eedelman at gcc dot gnu dot org 2006-02-20 18:50
---
(In reply to comment #11)
(In reply to comment #10)
With this fix, trunk is now once again able to compile VASP. Too bad it
seems
to be a bit late to get into 4.1. Maybe 4.1.1?
Actually it looks like it
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 19:08 ---
Is there a simple testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gcc-4.1 RC1 (20060219) fails to create libstdc++-symbol.explist on
powerpc-apple-darwin7 with the following error message:
nm -P .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
.libs/debug.o
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 19:31 ---
You don't have the correct nm in your path so this is not a bug. GCC requires
a full install of cctools 590.12 to be install and accessible by just invoking
nm/as/etc.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-20 19:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fang at csl dot cornell dot edu 2006-02-20 19:37
---
Subject: Re: 4.1 RC1 build failure on nm -P command
(darwin7)
You don't have the correct nm in your path so this is
not a bug. GCC requires a full install of cctools 590.12 to be
install and accessible by
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-02-20 19:38 ---
I can't really look into it because it's specific to an OS I don't have access
to.The proposed change looks reasonable. Reverting my change will very
likely break the build on well-behaved OSes.
I suppose it
--- Comment #2 from mckinlay at redhat dot com 2006-02-20 19:47 ---
You must be using a very old GCJ - this was fixed a long time ago.
*** This bug has been marked as a duplicate of 12475 ***
--
mckinlay at redhat dot com changed:
What|Removed
--- Comment #7 from mckinlay at redhat dot com 2006-02-20 19:47 ---
*** Bug 26351 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-20 19:54 ---
I just tried to reproduce this with exactly the options you used and I could
not. I then tried with a different prefix of /home/pinskia (my home directory)
and it still worked.
Is there something special with your
test.c -
#include string.h
#include malloc.h
int main()
{
char *s = strdup( foo );
free( s );
return 0;
}
compile in/out -
$ gcc -Wall -ansi test.c
test.c: In function main:
test.c:6: warning: implicit declaration of
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 20:06 ---
This is not a GCC bug, strdup is not ISO C.
What is happening is that GCC is defining STRICT_ANSI and glibc says then you
cannot use another thing besides ISO C headers which means no strdup.
--
pinskia at gcc
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-02-20 20:06
---
Subject: Bug 26201
Author: eedelman
Date: Mon Feb 20 20:06:49 2006
New Revision: 111311
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111311
Log:
fortran/
2006-02-20 Erik Edelmann [EMAIL PROTECTED]
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 20:07 ---
Ok, either use -D_GNU_SOURCE or don't use -ansi. Use -pedantic-errors instead
of -ansi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26386
--- Comment #7 from xtv at tveith dot homelinux dot com 2006-02-20 20:24
---
Hi..
whenever I use --program-prefix, bootstrap fails / otherwise it works just
perfect. To illustrate, this time i used the following configure:
../gcc-4.1.0-20060219/configure --prefix=/home/xtv
--- Comment #17 from law at redhat dot com 2006-02-20 20:32 ---
Subject: Re: [4.2 regression] bootstrap
failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 05:11 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #16 from
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-02-20 20:34
---
(In reply to comment #17)
No, because if it's marked as varying we will not use it to
refine any other VRP ranges.
But this is an unsigned value which is varrying. [0, +INF] for an unsigned
value is varrying,
--- Comment #19 from law at redhat dot com 2006-02-20 20:38 ---
Subject: Re: [4.2 regression] bootstrap
failure on Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 20:35 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #18 from
--- Comment #20 from law at redhat dot com 2006-02-20 20:39 ---
Subject: Re: [4.2 regression] bootstrap failure on
Alpha: xgcc runs out of memory compiling libiberty/md5.c
On Mon, 2006-02-20 at 03:11 +, roger at eyesopen dot com wrote:
--- Comment #10 from roger at
--- Comment #11 from anlauf at gmx dot de 2006-02-20 20:53 ---
(In reply to comment #10)
Strange: with gfortran gcc-4.1-20060210+fix x86_64-unknown-linux-gnu
it compiles and runs fine:
bash gfortran gfcbug31.f -Wall -O0 -g -fbounds-check ./a.out
In init1: npts = 1
i =
--- Comment #8 from themis_hv at yahoo dot co dot uk 2006-02-20 20:57
---
Do you have any of the following variables set before building GCC:
LD
DEFAULT_LINKER
ORIGINAL_LD_FOR_TARGET
CONFIG_SITE
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #9 from xtv at tveith dot homelinux dot com 2006-02-20 21:05
---
(In reply to comment #8)
Do you have any of the following variables set before building GCC:
LD
DEFAULT_LINKER
ORIGINAL_LD_FOR_TARGET
CONFIG_SITE
No:
[EMAIL PROTECTED] ~/gcc/out $ echo $LD
[EMAIL
--- Comment #21 from roger at eyesopen dot com 2006-02-20 21:07 ---
Created an attachment (id=10881)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10881action=view)
patch
I believe the following patch should resolve the problem. Bootstrap and
regression test in progress. The
--- Comment #22 from roger at eyesopen dot com 2006-02-20 21:33 ---
Created an attachment (id=10882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10882action=view)
revised patch
Doh! Although the previous attachment contained the necessary logic, it had
a few typos which will
--- Comment #23 from roger at eyesopen dot com 2006-02-20 21:37 ---
Created an attachment (id=10883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10883action=view)
really revised patch
Grrr! The previous attachment was identical to the original. Third times a
charm (or I'll
--- Comment #3 from parcour at gmail dot com 2006-02-20 22:04 ---
Subject: Re: strdup implicit declaration warning when using -ansi
I see. Sorry for a needless bug report. But thank you for your
helpful responses. I expect
I really will need to use -ansi (-- STRICT_ANSI), so I'll
void foo(void)
{
int *p = new int;
delete *p;
}
storage allocation should be changed from heap to stack allocation if
possible and of known (low) size. This way allocation can be optimized
away completely in some cases. Such opportunities are often exposed
by inlining of libstdc++ container
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 22:17 ---
Actually this is just dead code, see PR 19831.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26387
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-02-20 22:18 ---
Mine
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 22:18 ---
I should note that even right now operator new is not marked with the malloc
attribute which is PR 23383.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26387
#include vector
void foo(int n)
{
std::vectorint v;
for (int i=0; in; ++i)
v.push_back(i);
}
here the (single) variable storage allocated on the heap can be promoted
to stack allocation, where the (single) object can grow dynamically. This
happens in even more
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 22:21 ---
Actually this is all dead code and should be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-20 22:27 ---
Ok, here's a real example:
template typename T
std::vectorT makeRBlocksFactor(T number)
{
std::vectorT factors;
for (T f=2; fnumber; f++) {
while (number % f == 0) {
factors.push_back(f);
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-20 22:34 ---
make it return the largest prime, factors[factors.size()-1] instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #4 from falk at debian dot org 2006-02-20 22:35 ---
This would be incredibly difficult to detect reliably. But the main
problem is, on most operating systems, stack space is limited,
typically to something tiny compared to main memory like 8M, so this
wouldn't really be a
--- Comment #5 from janis at gcc dot gnu dot org 2006-02-20 22:44 ---
A regression hunt turned up a patch that only affects gfortran, which of course
makes no sense because the test case is written in C. That usually indicates a
Heisenbug, but there are some things I can try.
--
--- Comment #5 from rguenther at suse dot de 2006-02-20 22:52 ---
Subject: Re: Variable sized storage allocation
should be promoted to stack allocation
--- Comment #4 from falk at debian dot org 2006-02-20 22:35 ---
This would be incredibly difficult to detect reliably.
--- Comment #6 from falk at debian dot org 2006-02-20 23:06 ---
(In reply to comment #5)
If this is really not feasible or will not work in any useful cases,
maybe exposing the stack to the user would be a nice thing to have.
Like
foo()
{
int *p = __builtin_stack_top();
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-20 23:37
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 115 matches
Mail list logo
