--- Comment #13 from tammer at tammer dot net 2009-02-08 09:39 ---
Hello,
OK, I will try with an extended heap.
Bye
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38606
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:09
---
Confirmed on Solaris 8, but neither on Solaris 9 nor on Solaris 10.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:11
---
Btw, the default extension for preprocessed sources is .i, just pass
-save-temps
to the compiler to get the file.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-08 10:23 ---
Confirmed. Even spelling out basic-block here isn't going to be too useful
to the occasional programmer. I know that it is sometimes even just a
non-empty latch block that triggers this, so even control flow in
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-08 10:25 ---
From the comments I suggest the code does floating point equality compares,
which is a dangerous thing to do if you are not knowing what you do. A fix
is to instead of x == y use fabs(x - y) = epsilon.
--
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:26
---
This is a bug in the qsort implementation on Solaris 8:
Breakpoint 1, sort_coalesce_list (cl=0x1ce4b80)
at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-coalesce.c:434
434 qsort (cl-sorted, num,
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:58
---
This is a bug in the qsort implementation on Solaris 8:
Browsing the Sun database shows several related tickets, but most have been
closed as not a defect on the ground that the comparator function fails to
--- Comment #33 from hubicka at gcc dot gnu dot org 2009-02-08 11:32
---
Partial memory issues are fixed, but I think related to register pressure
awareness of invariant motion we did not change much. Steven, what do you
think?
I can give it another run on 32bit tester.
--
--- Comment #46 from hubicka at gcc dot gnu dot org 2009-02-08 11:50
---
With new-RA we seem to do better on this testcase now:
hubi...@occam:~$ time ./a.out-3.4
real0m5.448s
user0m5.440s
sys 0m0.012s
hubi...@occam:~$ time ./a.out
real0m5.834s
user0m5.836s
sys
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 12:33
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-08 12:36
---
I tested the patch on SPECfp and core and there is not much difference. I
guess without somehow tweaking regalloc there is not much to do about this
problem. Xuepeng, if the testcase is core2-variant sensitive,
--- Comment #16 from hubicka at gcc dot gnu dot org 2009-02-08 12:40
---
Since the splitting peep2 don't seem to be win in general (it wins only when
copy propagation takes place afterwards) and we don't seem to understand what
really makes the testcase faster I am unassigning myself
--- Comment #4 from amylaar at gcc dot gnu dot org 2009-02-08 12:49 ---
(In reply to comment #2)
This is related to some work done in the past for auto-increment addressing
modes
Actually, the problem with constants that are loaded into registers -
and in the same basic block, at
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01
---
Reproducible with every compiler I tried...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|Unaligned memory access with|unaligned
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-08 14:13 ---
This is a really old bug. Since 2005, a lot has happened in GCC. Could
someone interested in AVR please check whether this is still an issue?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-08 14:15 ---
This is a really old bug with no changes for a long time. Could someone check
whether there still is an issue here, and if so, confirm the bug?
Uros, I added you because you seem to be interested in Alpha lately...
--- Comment #16 from steven at gcc dot gnu dot org 2009-02-08 14:17 ---
No news for almost three years. Where are we with this one today?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-08 14:20 ---
No news since almost two years ago. Is this still a problem?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-08 14:45
---
The situation is still worse than originally reported. Even without PRE we
have
Analyzing # of iterations of loop 2
exit condition [1, + , 1] = i1_6(D)
bounds on difference of bases: -1 ... 2147483646
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-08 14:47 ---
No, it's now possible to implement this optimization (but yes, nobody has
done so sofar). It's on my TODO (with tons of other stuff, of course).
As this is an easy task for beginners ... whoever feels like doing
The following, compiled with no further options (g++ t.cc), results in an
ICE:
#include typeinfo
int main() {
typeid( 0.dd );
}
Also, documentation on DFPs is not very good. When trying to use DFPs with C++,
constants are recognised, while _Decimal[32|64|128] are rejected. I'd
appreciate some
--- Comment #14 from manu at gcc dot gnu dot org 2009-02-08 15:46 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00285.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-08 15:51 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00806.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-08 15:54 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01118.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-08 15:56 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00875.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 17:59
---
Still present on SPARC 32-bit on the mainline:
FAIL: gcc.c-torture/execute/pr38819.c execution, -O2
FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -fomit-frame-pointer
FAIL:
--- Comment #2 from hjl at gcc dot gnu dot org 2009-02-08 18:04 ---
Subject: Bug 39119
Author: hjl
Date: Sun Feb 8 18:03:58 2009
New Revision: 144017
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144017
Log:
gcc/
2009-02-08 H.J. Lu hongjiu...@intel.com
PR
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-08 19:02 ---
Subject: Bug 36432
Author: jsm28
Date: Sun Feb 8 19:01:57 2009
New Revision: 144018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144018
Log:
PR c/36432
* c-decl.c (grokdeclarator): Don't
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-08 19:03 ---
Subject: Bug 35434
Author: jsm28
Date: Sun Feb 8 19:02:56 2009
New Revision: 144019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144019
Log:
PR c/35434
* c-common.c (handle_alias_attribute):
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-08 19:04 ---
Fixed for 4.3.4 and 4.4.0. Not planning to work on a backport to 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-08 19:05 ---
Fixed for 4.3.4 and 4.4.0. Not planning to work on a backport to 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
The following testcase calls abort when it is compiled with
-O3 -ftree-loop-distribution.
/* Derived from gcc.c-torture/execute/20010910-1.c. */
extern void abort(void);
struct epic_private
{
unsigned int *rx_ring;
unsigned int rx_skbuff[5];
};
int
main (void)
{
struct epic_private ep;
--- Comment #1 from joseph at codesourcery dot com 2009-02-08 19:16 ---
Subject: Re: New: trunk revision 143992 - Too many Testsuite
FAILs = email 400K = bounce
On Sat, 7 Feb 2009, rob1weld at aol dot com wrote:
This causes a bounce reply message which _might_ mean that
tests
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-02-08 20:53
---
Paolo --
I didn't realize that something like __real__ 3 was valid GNU C; I thought
that the argument had to have complex type. But, it looks like that is not the
case.
Given that, yes, I think the test case
--- Comment #8 from ubizjak at gmail dot com 2009-02-08 21:00 ---
We should plug this for 4.3 and 4.4, so due to comment 6 I think this is a
regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
piece of code inside contained in class methode (starting line 263):
---
char *buf;
if (!strncmp(in-loc.path,/translators/,strlen(/translators/)))
{
translator_c *xl = translator_from_path(in-loc.path);
if (xl)
{
char *loc =
--- Comment #1 from corinl at gmx dot de 2009-02-08 22:07 ---
Oh sorry, I just see that buf could be used uninitialized for sure (if
xl==NULL). but well, shouldn't this warning then be issued all the times? so
the bug is now reversed - missing warning instead of false warning ;)
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-08 22:18 ---
The warning should be there at -O0 starting with G++ 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hp at gcc dot gnu dot org 2009-02-08 22:19 ---
Sorry, not yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
--- Comment #21 from mmitchel at gcc dot gnu dot org 2009-02-08 22:35
---
Paolo --
My earlier suggestion to try grok_array_decl may indeed have been misguided.
Some of the grok_* functions do more parser-style analysis than we want when
processing templates.
In theory, the way
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-08 22:40
---
Many thanks Mark for your detailed feedback on this PR and the other one. I'll
try to work along the lines you suggested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-08 23:07 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00308.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
The following:
#include stddef.h
void test(void)
{
size_t s1 = sizeof(test);
size_t s2 = sizeof(void (void));
}
should not compile with -std=c99. According to the C99 standard section
6.5.3.4.1 The sizeof operator shall not be applied to an expression that has
function type or
std::mem_fun_ref fails to accept a member function whose second argument can be
bound to a default value. In this example, I use vector::resize.
Test case:
#include vector
#include functional
#include algorithm
using std::vector;
using std::mem_fun_ref;
using std::bind2nd;
using
--- Comment #1 from fang at csl dot cornell dot edu 2009-02-09 07:39
---
also Fails: 4.2.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136
48 matches
Mail list logo
