--- Comment #20 from steven at gcc dot gnu dot org 2009-02-13 07:44 ---
Re: "Moving loop invariants out of this loop might help if it detected as a
loop, but I don't know how to check whether it is." (Comment #19):
It's not like there will not be any loop invariant code motion (LICM) at
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090212 (experimental) [trunk revision 144128] (GCC)
# gmake
...
mkdir -p ada/bldtools/sinfo
rm -f ada/bldtools/sinfo
--- Comment #7 from kamaraju at gmail dot com 2009-02-13 04:53 ---
> So, can we close this PR as fixed?
I thought it was marked as fixed long time back (2009-01-15) by Joost. Anyway,
the answer is yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38853
--- Comment #3 from ajrobb at bigfoot dot com 2009-02-13 04:05 ---
Many apologies. The bug was in line 66 of my code: should read:
while (src < end && dst < lim) {
This was polluting the stack - hardly surprising it crashed!
--
ajrobb at bigfoot dot com changed:
What
--- Comment #6 from kargl at gcc dot gnu dot org 2009-02-13 03:39 ---
(In reply to comment #5)
> For those reading the archives, this problem is specific to Solaris 8. The
> backtrace from this ICE (http://gcc.gnu.org/ml/fortran/2009-01/msg00321.html)
> is similar to another problem I en
--
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 #6 from hjl dot tools at gmail dot com 2009-02-13 02:37 ---
It is caused by revision 143422:
http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00435.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-13 01:00 ---
Subject: Bug 35444
Author: jsm28
Date: Fri Feb 13 01:00:24 2009
New Revision: 144149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144149
Log:
PR c/35444
* c-parser.c (c_parser_parms_list_decl
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-13 00:19
---
... and by the way, ICEs also with __decltype...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
--- Comment #4 from bangerth at gmail dot com 2009-02-13 00:12 ---
Confirmed, it also ICEs on mainline.
That's a much more serious case. I'm not entirely sure whether the code
is valid: you do
template static Z& y();
template static char test(typeof(y())*);
with Y=int, i.e. the
--- Comment #5 from kamaraju at gmail dot com 2009-02-12 23:59 ---
For those reading the archives, this problem is specific to Solaris 8. The
backtrace from this ICE (http://gcc.gnu.org/ml/fortran/2009-01/msg00321.html)
is similar to another problem I encountered with a C program as well
--- Comment #3 from kononov at ftml dot net 2009-02-12 23:49 ---
$ cat t.cc
template struct junk {
template static Z& y();
template static int test(...);
template static char test(typeof(y())*);
static int const value=sizeof(test(0));
};
typedef char type[junk::value==sizeof
--- Comment #4 from bangerth at gmail dot com 2009-02-12 23:21 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #2 from bangerth at gmail dot com 2009-02-12 23:23 ---
I think the code is invalid. The name 'i' is non-dependent, so shouldn't
it be bound to the member variable at the point of definition?
W.
--
bangerth at gmail dot com changed:
What|Removed
--- Comment #2 from bangerth at gmail dot com 2009-02-12 23:21 ---
I do get an ICE:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -c x.cc
x.cc: In instantiation of 'const int junk::value':
x.cc:6: instantiated from here
x.cc:4: internal compiler error: Segmentation fault
Please sub
--- Comment #1 from bangerth at gmail dot com 2009-02-12 23:17 ---
Confirmed:
g/x> /home/bangerth/bin/x86/gcc-mainline/bin/c++ -c x.cc
x.cc: In function 'int main()':
x.cc:3: internal compiler error: in write_builtin_type, at cp/mangle.c:1855
Please submit a full bug report,
with prepro
--- Comment #1 from lucier at math dot purdue dot edu 2009-02-12 22:45
---
The test suite has finished (I only built the C compiler), and results are at
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01220.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39173
--- Comment #5 from jason at gcc dot gnu dot org 2009-02-12 22:40 ---
Subject: Bug 38950
Author: jason
Date: Thu Feb 12 22:40:37 2009
New Revision: 144139
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144139
Log:
PR c++/38950
* pt.c (unify)[TEMPLATE_PARM_INDEX]:
--- Comment #10 from manu at gcc dot gnu dot org 2009-02-12 22:05 ---
(In reply to comment #9)
> I do not really understand problem 5 for the case when the only dependancy for
> the code-path check is a local variable. In this case the value cannot be
> change by any other code than exis
--- Comment #11 from sgh at sgh dot dk 2009-02-12 21:58 ---
Since this is not marked to be fixes I assume is hasn't been fixed in 4.3.3.
Wat is wrong with Pauls patch since it hasn't been included ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-12 21:58 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00610.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from corinl at gmx dot de 2009-02-12 21:53 ---
I do not really understand problem 5 for the case when the only dependancy for
the code-path check is a local variable. In this case the value cannot be
change by any other code than existing between the two checks, so this ca
--- Comment #20 from bonzini at gnu dot org 2009-02-12 21:39 ---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- Comment #19 from hjl dot tools at gmail dot com 2009-02-12 21:36
---
(In reply to comment #18)
> Subject: Re: [4.4 regression] Revision 144098 breaks
> 416.gamess in SPEC CPU 2006
>
> > We can't limit it to GENERAL_REGNO_P. See PR 38824. Here is a
> > different patch.
>
--- Comment #18 from jakub at gcc dot gnu dot org 2009-02-12 21:17 ---
In that case people probably wouldn't use -mpreferred-stack-boundary=2
though...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
PR 37739 applies to 4.3.3, as does the fix (applied by hand to my sources).
I'm running "make check" right now with the patched sources.
--
Summary: PR37739 (bootstrap failure) applies to 4.3.3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-12 21:08 ---
Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #18 from bonzini at gnu dot org 2009-02-12 20:59 ---
Subject: Re: [4.4 regression] Revision 144098 breaks
416.gamess in SPEC CPU 2006
> We can't limit it to GENERAL_REGNO_P. See PR 38824. Here is a
> different patch.
H.J., I know, my patch *was* for PR38824. :-)
--- Comment #17 from hjl dot tools at gmail dot com 2009-02-12 20:58
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00605.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #19 from lucier at math dot purdue dot edu 2009-02-12 20:51
---
Subject: Re: Code that compiles fine in 1GB of
memory with 4.1.2 requires > 20GB in 4.2.* and higher
On Thu, 2009-02-12 at 16:52 +, rguenth at gcc dot gnu dot org wrote:
> --- Comment #16 from rguenth
--- Comment #18 from rakdver at gcc dot gnu dot org 2009-02-12 19:58
---
> It "works" once you change the loop exit condition to i < i1. Same effects
> with unsigned variables (adjust the lower bound to sth like 2 to avoid ill
> effects).
There is nothing to fix if unsigned variables
--- Comment #18 from lucier at math dot purdue dot edu 2009-02-12 19:54
---
There is now a file slatex.i at
http://www.math.purdue.edu/~lucier/bugzilla/8/
that compiles in about 650MB of memory with gcc-4.2.3 on x86-64 with the same
options; I don't know if that will help Steven.
--
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-12 19:29 ---
this is on the svn trunk as libada multilib is new since 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
--- Comment #16 from hjl dot tools at gmail dot com 2009-02-12 19:25
---
Subject: Re: [4.4 regression] Revision 144098 breaks
416.gamess in SPEC CPU 2006
On Thu, Feb 12, 2009 at 07:05:27PM -, bonzini at gnu dot org wrote:
> Subject: Re: [4.4 regression] Revision 144098 br
The magic that groks the multilib set in libada is unable to process the
one for the m68k. Maybe someone who is configure/awk proficient can spot
the issue. This works on other targets.
make -C ../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=" "LN_S=ln -s"
"SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wal
--- Comment #15 from bonzini at gnu dot org 2009-02-12 19:07 ---
Subject: Re: [4.4 regression] Revision 144098 breaks
416.gamess in SPEC CPU 2006
The patch is obviously okay, but it seems weird that this is accepted.
I must be missing something on peephole2...
--
http://
--- Comment #14 from bonzini at gnu dot org 2009-02-12 19:05 ---
Subject: Re: [4.4 regression] Revision 144098 breaks
416.gamess in SPEC CPU 2006
> The patch is obviously okay, but it seems weird that this is accepted.
> I must be missing something on peephole2...
By obvious
--
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 #17 from rakdver at kam dot mff dot cuni dot cz 2009-02-12
18:29 ---
Subject: Re: Code that compiles fine in 1GB of memory with 4.1.2 requires >
20GB in 4.2.* and higher
> Zdenek, in this case (and PR26854) can we make sure not to recognize loops
> that involve the single
--- Comment #17 from ubizjak at gmail dot com 2009-02-12 18:23 ---
(In reply to comment #15)
> The DFmode and DImodes are different. Aligning DFmode on stack is very
> performance critical, while DImodes on 32bit machine can quite safely be
> misaligned (if we ignore their possible use i
When compiling code with a zero character-length like this:
character(len=0) :: str
end
gfortran gives no error/warning. But for a negative length:
character(len=-1) :: str
end
one gets the misleading message:
character(len=-1) :: str
1
Warning: CHARACTER variable has zero lengt
--- Comment #2 from tom at atoptech dot com 2009-02-12 18:10 ---
Subject: Re: -Wconversion useless
You miss the point. The only way to assign a non-constant value to a bit
field outside of a struct is using an integral variable i.e.,
struct foo
{
int a : 2;
};
void assign( struct
--- Comment #8 from peter at cordes dot ca 2009-02-12 17:56 ---
Would it cause any problems for g++ to behave more like a C compiler when it
comes to NULL? e.g. I found this bug report after finding that kscope 1.9.1
didn't compile, because it expected NULL to match the void* version of
--- Comment #6 from paolo dot carlini at oracle dot com 2009-02-12 17:53
---
Actually, libstdc++ stores 123456, which is indeed fine, and sets failbit |
eofbit, failbit exactly because of the issue discussed here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-12 17:39 ---
Really -Wconversion is correct to warn about bit-fields because the conversion
will lose bits.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I'm sure this has been reported.
General narrowing of a value (i,e double to int) needs to be reported, but
bit-fields narrowing should not be reported unless asked for. There is nothing
in "C" or "C++" to cast a bit-field, which in theory, would remove the warning.
This is a serious problem and i
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-12 17:05
---
Hi. Maybe the testcases should be amended, but surely when char is signed, just
checking that vec[i] > 0 as an indication of regular group size instead of
vec[i] > 0 && vec[i] != CHAR_MAX cannot be right...
Pl
--- Comment #1 from sebor at roguewave dot com 2009-02-12 17:02 ---
In addition, as the test case below shows, the warning is issued inconsistently
between classes and functions, suggesting that the instance of the warning on
the class declaration on line 2 might be a bug rather than a f
--- Comment #16 from hjl dot tools at gmail dot com 2009-02-12 17:01
---
(In reply to comment #15)
> The DFmode and DImodes are different. Aligning DFmode on stack is very
> performance critical, while DImodes on 32bit machine can quite safely be
> misaligned (if we ignore their possibl
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-12 16:52
---
Actually for PR26854 it is just one loop that is detected, covering all of
the function (with approx. 56000 basic blocks and one basic-block that has
edges to all other basic blocks in the loop). So the default fo
--- Comment #4 from sebor at roguewave dot com 2009-02-12 16:49 ---
(In reply to comment #0)
I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
includes "123,456" This behavior is the
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-12 16:47
---
The DFmode and DImodes are different. Aligning DFmode on stack is very
performance critical, while DImodes on 32bit machine can quite safely be
misaligned (if we ignore their possible use in MMX intrincisc).
I thin
--- Comment #15 from lucier at math dot purdue dot edu 2009-02-12 16:35
---
Some comments (a lot went on while I was sleeping):
1. Yes, this is similar to the test case of PR26854, but the C code generator
has changed significantly since that test case was filed. I don't know if the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-12 15:58
---
Ok, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Assi
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-12 15:57 ---
Created an attachment (id=17291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17291&action=view)
gcc44-pr39157.patch
Patch to add loop-invariant-max-bbs-in-loop parameter.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-02-12 15:47
---
Zdenek, in this case (and PR26854) can we make sure not to recognize loops
that involve the single non-local goto BB? Maybe this would solve the
problem as well.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #26 from hjl at gcc dot gnu dot org 2009-02-12 15:45 ---
Subject: Bug 38824
Author: hjl
Date: Thu Feb 12 15:45:20 2009
New Revision: 144129
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144129
Log:
Mention PR target/38824 in ChangeLog entries.
Modified:
trunk/g
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-12 15:42
---
I think we can consider it for 4.5.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #13 from hjl dot tools at gmail dot com 2009-02-12 15:41
---
This patch:
--- ./i386.md.class 2009-02-12 06:42:42.0 -0800
+++ ./i386.md 2009-02-12 07:39:03.0 -0800
@@ -20736,7 +20736,11 @@
[(match_dup 0)
(mat
--- Comment #6 from doko at ubuntu dot com 2009-02-12 15:40 ---
a build with the suggested change doesn't show any change.
--- gcc/calls.c~2009-02-05 09:30:24.0 +0100
+++ gcc/calls.c 2009-02-12 15:17:08.0 +0100
@@ -530,6 +530,8 @@
}
else if ((tname
--- Comment #2 from tsyvarev at ispras dot ru 2009-02-12 15:33 ---
Created an attachment (id=17290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17290&action=view)
test for money_put<>::put method
When grouping is disabled, money_put<>::put() method for digits should write
these
--- Comment #1 from tsyvarev at ispras dot ru 2009-02-12 15:30 ---
Created an attachment (id=17289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17289&action=view)
test for num_get<>::get() method
When grouping is disabled, thousands separator should not be read by get()
methods.
Description of numpunct<>::do_grouping() (22.2.3.1.2, p3):
Returns: A basic_string vec used as a vector of integer values, in which
each element vec[i] represents the number of digits in the group at position i,
starting with position 0 as the rightmost group. If vec.size() <= i, the number
is th
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-12 15:26
---
We have
(insn 1988 1119 1121 173
/export/gnu/src/gcc-work/gcc/libgomp/testsuite/libgomp.fortran/omp_parse4.f90:28
(set (reg:SI 2 cx [orig:190 D.2207 ] [190])
(reg:SI 21 xmm0)) 47 {*movsi_1} (expr_list:REG_
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-12 15:22
---
Let's see...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Ass
--- Comment #10 from Joey dot ye at intel dot com 2009-02-12 15:20 ---
(In reply to comment #8)
> We still have push and mov. I guess it may be the best we can do.
> But please run full 32 and 64bit testsuite with your patch as well
> as under emx-avx-sim.
full 32/64 bit test pass with n
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-12 15:06 ---
Closed as WONTFIX per Joseph comments. Thanks for the report nonetheless.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-12 15:11 ---
So this is a bug in the C front-end. In any case, it is either a bug or an
enhancement request. So confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from manu at gcc dot gnu dot org 2009-02-12 14:59 ---
Updating the description. Although anyone would agree that not warning is the
right thing to do, there doesn't seem to be any practical solution for this
problem, so I leave it as unconfirmed.
I wonder if clang/llvm ge
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-12 14:34
---
Another regression. But you need -mavx to see it:
./xgcc -B./
/net/gnu-13/export/gnu/src/gcc/gcc/libgomp/testsuite/libgomp.fortran/omp_parse4.f90
-B/export/build/gnu/gcc-avx/build-x86_64-linux/x86_64-unknown-linu
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-12 14:33 ---
I think this is a reasonable request. Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from bonzini at gnu dot org 2009-02-12 14:31 ---
thanks h.j.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from rguenther at suse dot de 2009-02-12 14:23 ---
Subject: Re: Code that compiles fine in 1GB of memory
with 4.1.2 requires > 20GB in 4.2.* and higher
On Thu, 12 Feb 2009, jakub at gcc dot gnu dot org wrote:
> --- Comment #11 from jakub at gcc dot gnu dot org 20
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-12 14:21 ---
Created an attachment (id=17288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17288&action=view)
gcc44-pr39157.patch
Quick hack to avoid loop invariant motion from excessively large loops at -O1.
With this cc1
--- Comment #5 from doko at ubuntu dot com 2009-02-12 14:09 ---
Created an attachment (id=17287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17287&action=view)
thread_pthread.h header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #4 from doko at ubuntu dot com 2009-02-12 14:06 ---
Created an attachment (id=17286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17286&action=view)
thread.c source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #9 from hjl at gcc dot gnu dot org 2009-02-12 14:04 ---
Subject: Bug 39152
Author: hjl
Date: Thu Feb 12 14:04:20 2009
New Revision: 144126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144126
Log:
gcc/
2009-02-12 Paolo Bonzini
PR target/39152
*
--- Comment #5 from rob1weld at aol dot com 2009-02-12 14:04 ---
(In reply to comment #0)
> On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer
> has their own Linker and recommends it be used for all linking.
> ...
> Note that in both of the commonly available compi
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-12 13:59 ---
Can you check if moving the PR38977 fix to special_function_p (handling
plain fork there) fixes it? What is the contents of thread.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #13 from ubizjak at gmail dot com 2009-02-12 13:59 ---
GCC: (GNU) 4.4.0 20090129 (experimental) [trunk revision 143750]:
foo:
movl4(%rdi), %eax #, s
.L2:
movl%eax, %ecx # s, s.29
addl(%rsi), %ecx#* d, s.29
addq$4, %r
--- Comment #9 from rob1weld at aol dot com 2009-02-12 13:44 ---
(In reply to comment #8)
> ...
> This patch is tested for i386-pc-solaris2.11 (OpenSolaris 2008.11 snv_101b)
> when booted in 32-bit mode (on VirtualBox, on WinXP) using gcc revision 143992
> using Sun's Linker (and GNU ass
--- Comment #34 from ubizjak at gmail dot com 2009-02-12 13:43 ---
(In reply to comment #33)
> I can give it another run on 32bit tester.
Yes, please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #23 from doko at ubuntu dot com 2009-02-12 13:40 ---
PR38292 is still seen with trunk 20090211 on amd64, works for i486.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
--- Comment #2 from rob1weld at aol dot com 2009-02-12 13:36 ---
(In reply to comment #1)
> How is this major, this is an enhancement to the build system. i386-solaris
> is
> a multi arch target so it includes the x86_64 solaris target also.
It could be called an "enhancement to the b
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|[4.3/4.4] corrupted profile |[4.3/4.4 Regression]
|info with -O[23] -fprofile- |corrup
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-12 13:16 ---
Most of the memory is allocated in df_chain->block_pool:
p *df->problems_by_index[4]->block_pool
$37 = {name = 0xbc3114 "df_chain_block pool", id = 475, elts_per_block = 50,
returned_free_list = 0x0,
virgin_free_li
--- Comment #2 from doko at ubuntu dot com 2009-02-12 13:04 ---
still seen with a backport of the patch to the 4.3 branch and with trunk
20090211 on amd64. works on i486.
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fprofile-use -I. -IInclude
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-12 12:58 ---
PR26854 is "fixed" as well with -fno-move-loop-invariants. It has a little
less peak memory requirement than the testcase here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #8 from bonzini at gnu dot org 2009-02-12 12:55 ---
Subject: Re: [4.4 regression] Revision 144098 breaks
416.gamess in SPEC CPU 2006
I think you can commit it as obvious. I can only do so tonight or
tomorrow morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-12 12:49 ---
If there is a test case that compiles in less than 4GB, I'll take this bug (I
have no access to machines with more memory than that ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-12 12:33 ---
Jakub and Richard proposed on #gcc that this feature should still go into 4.4,
I agree.
(In reply to comment #2)
> Created an attachment (id=16867)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16867&action=vie
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-12 12:16 ---
Adding -fno-move-loop-invariants to the x86_64 mentioned options results in
VIRT memory topping around 1224m (only because of IRA, before RA it never went
above 1GB). Seems it is really the loop2_invariant pass that a
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-12 12:01 ---
In the past, we did not unfactor them (see e.g. Bug 15242).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from manu at gcc dot gnu dot org 2009-02-12 11:45 ---
I added this as Problem 5 in the wiki:
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-02-12 11:40
---
> Even for code with lots of computed gotos, the CFG should not be fully
> connected. We factorize computed gotos to avoid exactly that. At least we
> used
> to. Maybe the factorizing is broken, or it is undone
--- Comment #6 from matz at gcc dot gnu dot org 2009-02-12 11:32 ---
I don't think it's __builtin_apply which is wrong. It's rather how it is
used in libobjc. In particular register parameters are handled wrongly.
libobjc objc_msg_sendv() simply tries to overwrite the first two argumen
--- Comment #2 from ajrobb at bigfoot dot com 2009-02-12 11:26 ---
I have tested the assembler outputs from the two compilers. Both assembler
files were generated with:
gcc -g soundex.c -S -o soundex.s
I then compiled both on the failing platform:
gcc -g soundex.s -o soundex
If I compi
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-12 11:26 ---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we used
to. Maybe the factorizing is broken, or it is undone somewhere to
1 - 100 of 122 matches
Mail list logo
