--- Comment #1 from dougkwan at google dot com 2009-05-15 07:08 ---
This is caused by a typo in arm.md.
(define_insn "cstoresi_nltu_thumb1"
[(set (match_operand:SI 0 "s_register_operand" "=l,l")
(neg:SI (gtu:SI (match_operand:SI 1 "s_register_operand" "l,*h")
--- Comment #37 from jakub at gcc dot gnu dot org 2009-05-15 07:56 ---
This patch looks very wrong. It assumes that min_insn_size gives exact insn
sizes (current min_insn_size is very far from that, but even get_attr_length
isn't exact), doesn't take into account label alignments nor br
I'm getting the following warning when compiling wesnoth. I'm not sure if
this is a bug in the code or in GCC but Andrew Pinski said I should file a
bug so someone can take a look at it.
This happens with gcc 4.4, but not with 4.3.
(sid)700:t...@em64t: ~/src/wesnoth-1.6.2/src] g++-4.4 -c -O1 -Wa
--- Comment #1 from tbm at cyrius dot com 2009-05-15 08:10 ---
Created an attachment (id=17872)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17872&action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-15 08:26 ---
(In reply to comment #1)
> This is caused by a typo in arm.md.
>
> (define_insn "cstoresi_nltu_thumb1"
> [(set (match_operand:SI 0 "s_register_operand" "=l,l")
> (neg:SI (gtu:SI (match_operand:SI 1 "s_regis
--- Comment #3 from dougkwan at google dot com 2009-05-15 08:28 ---
Subject: Re: Long long comparison optimized away
incorrectly in Thumb code.
I am running regression tests and will submit a patch tomorrow morning
after that.
-Doug
2009/5/15 ramana at gcc dot gnu dot org :
--- Comment #4 from rguenther at suse dot de 2009-05-15 08:39 ---
Subject: Re: ICE assert aliasing in
vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64,
works at 32
On Thu, 14 May 2009, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #3 from ebotcazou
Hi,
With this simple testcase:
int buffer[256*256];
int main(void)
{
int *dest = buffer;
int x, y;
for(x = 0; x < 256; x++)
for(y = 0; y < 256; y++)
*dest++ = 0;
return 0;
}
We get an ICE:
% gcc-4.4 -O1 -floop-block foo.c -o foo
foo.c: In function main:
foo
--- Comment #7 from rguenther at suse dot de 2009-05-15 08:44 ---
Subject: Re: [4.3/4.4/4.5 Regression] Number
of iterations analysis wrong
On Fri, 15 May 2009, rakdver at gcc dot gnu dot org wrote:
> --- Comment #6 from rakdver at gcc dot gnu dot org 2009-05-15 00:34
> ---
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-15 09:02
---
Definitely bogus, maybe we already have something open about this issue, CC-ing
Richard, to be sure...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-15 09:11 ---
Does it happen on trunk?
The testcase is too big.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-05-15 09:14
---
Confirmed on x86-64.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-15 09:17 ---
It is an uninitialized use in an exception handler.
;; basic block 132, loop depth 0, count 0
;; prev block 131, next block 133
;; pred: 131 (ab,eh,exec)
;; succ: 135 [100.0%] (fallthru,exec)
:
save_fil
--- Comment #11 from billingd at gcc dot gnu dot org 2009-05-15 09:24
---
Subject: Bug 36211
Author: billingd
Date: Fri May 15 09:23:58 2009
New Revision: 147565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147565
Log:
2009-05-15 David Billinghurst
PR libstdc++/362
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-15 10:06 ---
Particularly the dependent_type_p -> dependent_scope_p change in
finish_id_expression makes the difference here. BIT_NOT_EXPR of a RECORD_TYPE
makes it through till tsubsting and isn't errored as invalid use of destru
--- Comment #12 from bonzini at gnu dot org 2009-05-15 10:08 ---
Andrew, any news?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #84 from bonzini at gnu dot org 2009-05-15 10:35 ---
Ok, I am working on a patch to add a multiple-definitions DF problem and use
that together with a domwalk to find the single definitions (instead of
reaching-definitions, which is the remaining slow part). The new problem
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-15 10:32 ---
Proc-pointer fun as written by Malcolm Cohen,
http://j3-fortran.org/pipermail/j3/2009-May/002755.html
If I understood his arguments correctly, even the following Fortran 90 program
might be affected:
module m
IM
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-15 11:03 ---
Confirmed with
gcc -c -std=gnu99 -O -combine lv2log.i sim-common.i
sim-common.c: In function main_chute:
sim-common.c:88: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:188
Please
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-15 11:04 ---
This is not part of GCC but glibc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-15 11:05 ---
Not a regression, -floop-block is new.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-15 11:09 ---
Created an attachment (id=17873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17873&action=view)
patch
This is a patch backporting the fix and followups necessary to fix the fallout
(and the new testcases).
--- Comment #38 from jakub at gcc dot gnu dot org 2009-05-15 12:11 ---
To extend #c31, I've also built the same tree with another patch which made
sure ix86_avoid_jump_mispredicts is never called (change "&& optimize" into "&&
optimize > 4" in ix86_reorg). cc1plus sizes were then
0x88d6
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-15 12:11 ---
We are vectorizing
:
:
# J1_43 = PHI
J1_36 = J1_43 + 1;
D.2354_35 = (long int) J1_36;
VIEW_CONVERT_EXPR(*_init$P_ARRAY_1)[D.2354_35]{lb: D.2335_26 sz: 8} = 0B;
if (D.2336_6 != J1_36)
goto ;
else
--- Comment #39 from jakub at gcc dot gnu dot org 2009-05-15 12:12 ---
Created an attachment (id=17874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17874&action=view)
test4jmp.sh
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
The following program is rightly rejected. But the problem is not really that
the ranks are different (as the example shows for "i", which is valid). The
issue is that "j" is a scalar. -- A user might also not be that familiar the
concept that a rank-0 array is equivalent to a scalar.
gfortran s
Since r147415 all failures from recursive make calls are ignored and "make all"
always exits successfully.
--
Summary: [4.5 regression] "make all" ignores build failures
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: build
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-15 13:10 ---
Subject: Bug 3
Author: rguenth
Date: Fri May 15 13:09:53 2009
New Revision: 147573
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147573
Log:
2009-05-15 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-15 13:10 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to w
--- Comment #2 from abel at gcc dot gnu dot org 2009-05-15 13:20 ---
The bug happens when we compute a seqno for the newly created bookkeping insn.
Seqnos exist in the algorithm (roughly) to guide the movement of fences so
that, first, all unscheduled insns will be found and scheduled,
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-05-15
13:37 ---
Will this fix be backported for gcc 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #9 from rguenther at suse dot de 2009-05-15 13:47 ---
Subject: Re: [4.4 Regression] gcc 4.4.0 compiles
in infinite loop
On Fri, 15 May 2009, howarth at nitro dot med dot uc dot edu wrote:
> --- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-05-15
> 13:
I get:
$ cat s.cpp
#include
$ g++ -c -fno-rtti -D_GLIBCXX_DEBUG s.cpp
In file included from /usr/include/c++/4.3/debug/debug.h:155,
from /usr/include/c++/4.3/bits/stl_algobase.h:76,
from /usr/include/c++/4.3/bits/char_traits.h:46,
from /usr/inclu
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-15 14:27
---
I get your point, indeed I implemented __GXX_RTTI and put it to good use in
has_facet / use_facet. However, here, what happens to debug mode if typeid is
not available? Is it still largely usable? If not, and I
--- Comment #40 from hjl dot tools at gmail dot com 2009-05-15 14:35
---
(In reply to comment #37)
> This patch looks very wrong. It assumes that min_insn_size gives exact insn
> sizes (current min_insn_size is very far from that, but even get_attr_length
> isn't exact), doesn't take i
--- Comment #2 from jay dot foad at gmail dot com 2009-05-15 14:37 ---
I'm using debug mode to catch problems like v[i] where i >= v.size(). I think
it would be very nice if this worked with -fno-rtti. I don't see why RTTI
should be required to make this work. But then, I have no idea wh
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-15 14:48
---
Ok. In fact, being typeid used in formatter.h only (please confirm, if you
can), I suspect not using it (replacing &typeid with 0) would only lead to
worse error message, not more than that. Are you willing to
Revision 147566 gave:
FAIL: g++.dg/eh/filter2.C execution test
FAIL: gcc.c-torture/compile/pr22379.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/pr22379.c -O3 -fomit-frame-pointer (test for
excess errors)
FAIL: gcc.c-torture/compile/pr22379.c -O3 -fomit-frame-pointer
-funroll-all
Just a reminder PR for me.
The reason why auto-parallelization has TODO_rebuild_alias is that it generates
a .paral_data_store structure where it stores pointers to new address-taken
variables and passes the address of that structure to the new parallel worker
clone. This makes ESCAPED incomplete
--
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 2009-05-15 15:27 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
I just tried to compile the Suse Linux package blocxx-2.1.0.342-124.2
with the GNU g++ version 4.5 snapshot 20090514.
The compiler said
LogAppender.cpp: In constructor 'blocxx6::LogAppender::LogAppender(const
blocxx6::StringArray&, const blocxx6::StringArray&, const blocxx6::String&)':
LogAppende
--- Comment #1 from dcb314 at hotmail dot com 2009-05-15 15:37 ---
Created an attachment (id=17875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17875&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40163
--- Comment #4 from jay dot foad at gmail dot com 2009-05-15 15:39 ---
> typeid used in formatter.h only (please confirm, if you can)
If I replace typeid(...) with 0 in formatter.h then I can at least compile the
following with -fno-rtti -D_GLIBCXX_DEBUG:
#include
#include
#include
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2009-05-15
15:44 ---
Subject: Re: [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
> > > It is number of iteration analysis that gets it wrong (I suppose it might
> > > get
> > > confused by the two exits of the l
--- Comment #7 from laurent at guerby dot net 2009-05-15 16:23 ---
Indeed, at revision 147567 on x86_64-linux:
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01235.html
Running target unix/-m64
FAIL: gnat.dg/loop_optimization1.adb (test for excess errors)
--
http://gcc.gnu.org/b
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #41 from jakub at gcc dot gnu dot org 2009-05-15 16:24 ---
The 34 resp. 51 4 branches in 16 byte page with the 3 patches together made me
look at one of the cases which was wrong and the problem is that cmp $0x1d, %al
has too large get_attr_lenght (insn) returned, 3 instead o
--- Comment #2 from spop at gcc dot gnu dot org 2009-05-15 17:49 ---
This problem is fixed in the Graphite branch. I guess that the
problem comes from the fact that in GCC4.4 we did not handled
INDIRECT_REF in expand_scalar_variables_expr.
Should I back-port that code?
Thanks,
Sebas
--- Comment #42 from jakub at gcc dot gnu dot org 2009-05-15 18:18 ---
Sizes with the #c41 patch together with the 3 patches mentioned in #c31 are:
0x890038 (64-bit) and 0x8ce08c (32-bit), 44 bad 16-byte pages in 64-bit, 35 in
32-bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
PROGRAM test_prog
TYPE ProcPointerArray
PROCEDURE(add), POINTER, NOPASS :: f
END TYPE ProcPointerArray
TYPE (ProcPointerArray) :: f_array(1)
PROCEDURE(add), POINTER :: f
f_array(1)%f => add
f => f_array(1)%f
PRINT*, f(2.,4.)
CONTAINS
FUNCTION add(a,b) RESULT(sum)
REAL, INTENT(in)
--- Comment #43 from jakub at gcc dot gnu dot org 2009-05-15 18:23 ---
Some code size growth is from enlarged get_attr_modrm though, 292 bytes for
64-bit, 1338 bytes for 32-bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
do real_var = 0.0, 10.0, 0.1
print *, real_var
end do
is valid Fortran 77 (not in 66) but it was deleted from newer Fortran
standards. gfortran barks if it finds one, but instead of printing one error
message it prints four (loop variable, start, end and increment), which is a
bit too much.
Ex
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-15 18:51 ---
I disagree with you as does the F95 standard (if I'm
not misreading the standard).
1.5 Conformance
(3) It contains the capability to detect and report the use within
a submitted program unit of an additional fo
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-15 19:34
---
Ok, thanks. I'll fix it as I said earlier today.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-15 20:08 ---
Subject: Bug 16302
Author: manu
Date: Fri May 15 20:08:21 2009
New Revision: 147596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147596
Log:
2009-05-15 Manuel López-Ibáñez
PR 16302
* fo
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-15 20:10 ---
FIXED for GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-15 20:13 ---
Benjamin, note that -Wlogical-op will be enabled by -Wextra in GCC 4.5.
I am willing to give it a try to fix this before 4.5 is released. However, I
cannot reproduce this problem, so please, provide a preprocessed tes
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-15 20:23 ---
(In reply to comment #1)
> I disagree with you as does the F95 standard
Sorry, I cannot find anywhere in the standard that one has to emit four
warnings. First, I think that one warning for a real loop variable is en
--- Comment #3 from kargl at gcc dot gnu dot org 2009-05-15 20:40 ---
(In reply to comment #2)
> (In reply to comment #1)
> > I disagree with you as does the F95 standard
>
> Sorry, I cannot find anywhere in the standard that one has to emit four
> warnings.
I quoted the relevant text
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-05-15 21:48
---
> The issue here is that for
>
> VIEW_CONVERT_EXPR *[D.2335:D.2339]>(*_init$P_ARRAY_1)[D.2354_35]
>
> we use the alias set of *_init$P_ARRAY_1 because the array elements are
> non-aliased. As the vectorizer now
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-15 21:51 ---
Here is a small patch which fixes the test case:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 147527)
+++ gcc/fortran/prima
--- Comment #8 from lucier at math dot purdue dot edu 2009-05-15 21:55
---
Created an attachment (id=17876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17876&action=view)
patch to use HOST_WIDEST_INT for bitmap statistics
Here's a hack to use HOST_WIDEST_INT for bitmap statisti
s=c
--enable-gather-detailed-mem-stats --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
--- Comment #6 from paolo at gcc dot gnu dot org 2009-05-15 22:25 ---
Subject: Bug 40160
Author: paolo
Date: Fri May 15 22:25:24 2009
New Revision: 147599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147599
Log:
2009-05-15 Paolo Carlini
PR libstdc++/40160
*
--- Comment #7 from paolo dot carlini at oracle dot com 2009-05-15 22:27
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-15 22:29
---
The patch is good enough.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-05-15 22:53
---
Confirmed. Reduced testcase (crahses already with "-O"):
===
struct A
{
void foo(int*, int);
};
struct B
{
B();
~B() { A().foo(p, q - p); }
int *p, *q;
};
--- Comment #44 from hjl dot tools at gmail dot com 2009-05-15 23:05
---
(In reply to comment #41)
> The 34 resp. 51 4 branches in 16 byte page with the 3 patches together made me
> look at one of the cases which was wrong and the problem is that cmp $0x1d,
> %al
> has too large get_at
--- Comment #5 from jb at gcc dot gnu dot org 2009-05-15 23:45 ---
Subject: Bug 39872
Author: jb
Date: Fri May 15 23:45:08 2009
New Revision: 147601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147601
Log:
Backport fix for PR libfortran/39872 from trunk.
Modified:
branche
--- Comment #11 from jb at gcc dot gnu dot org 2009-05-15 23:50 ---
Backported to 4.4 branch as r147601.
Backporting to 4.3 caused regressions, so I'm tempted to just skip that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-05-16 00:08 ---
I've tried to see what is going on with -da.
.expand rtl dump shows that t *= 10 is compiled to
a sequence of insns and the last two insns are:
(insn 87 86 88 ice.i:6 (parallel [
(set (subreg:SI
--- Comment #85 from lucier at math dot purdue dot edu 2009-05-16 00:20
---
Created an attachment (id=17878)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17878&action=view)
Large test file for testing time and memory usage
This is the file compiler.i used in the previous tests.
--- Comment #86 from lucier at math dot purdue dot edu 2009-05-16 00:29
---
Created an attachment (id=17879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17879&action=view)
Time and memory report for compiler.i
This is the time and memory report after the hack from
http://gcc.g
--- Comment #87 from lucier at math dot purdue dot edu 2009-05-16 00:33
---
The compiler options for the previous report:
/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv
gs: --prefix=/pkgs/gcc-mainline --enable-gather-detailed-mem-stats
Results for 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC)
testsuite on x86_64-unknown-linux-gnu
I don't have check-in privileges.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
--- Comment #45 from jakub at gcc dot gnu dot org 2009-05-16 06:37 ---
cmpl $1, %eax does have the modrm byte:
83 f8 01 cmp$0x1,%eax
compared to cmpl $0xdeadbeef, $eax which doesn't have it:
3d ef be ad de cmp$0xdeadbeef,%eax
So I think what I wrote is more prec
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-05-16 06:52 ---
FWIW, there are lots of failures like this building gnat in stage2, during a
bootstrap with BUILD_CONFIG=bootstrap-O3
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Add
78 matches
Mail list logo
