--- Comment #15 from davek at gcc dot gnu dot org 2010-01-11 08:16 ---
just waiting to see if this can be reproduced with clean sources.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from stevenb dot gcc at gmail dot com 2010-01-11 08:22
---
Subject: Re: redundant memory load
On Mon, Jan 11, 2010 at 7:47 AM, carrot at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3,
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-11 08:35 ---
See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c11 for one of the
possible reasons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
--- Comment #12 from gerald at pfeifer dot com 2010-01-11 08:36 ---
Closing per previous comment.
Yuri, is it possible a different (older) run-time library was picked
up during your original tests?
--
gerald at pfeifer dot com changed:
What|Removed
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-11 08:50 ---
Looks similar to pr42677. The patch in comment#3 fixes these PRs, but misses
also really(?) ambiguous interfaces, see:
gcc/testsuite/gfortran.dg/defined_operators_1.f90
gcc/testsuite/gfortran.dg/generic_7.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2010-01-11 08:51 ---
Similar to pr42677 (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684#c4 ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-11 08:52 ---
Similar to pr42677
Wrong window!-( Similar to pr42684.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42677
--- Comment #12 from carrot at google dot com 2010-01-11 08:55 ---
(In reply to comment #11)
Yes, I would have expected the block starting with .L4 to be *after*
the block starting with .L5, something like so:
iterate:
push{lr}
ldr r3, [r1]
.L6:
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-11 09:25 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pzhao at gcc dot gnu dot org 2010-01-11 09:33 ---
Fixed for 4.5.0
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pzhao at gcc dot gnu dot org 2010-01-11 09:34 ---
Fixed for 4.5.0
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-11 09:35 ---
Re. comment #5 -- rth, any suggestions what an algorithm would look like to
minimize the number of branches, or the total size of all of the branch
instructions? And what do you mean with some clever changes to the
--- Comment #5 from jzhang918 at gmail dot com 2010-01-11 09:36 ---
I just submitted a patch several days ago:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00130.html
I think it might be able to fix this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42662
g++ doesn't accept correct code:
namespace N
{
struct S { };
void f(const S ) { }
}
void f(const N::S ) { }
int main()
{
N::S v;
(f)(v); // no ambiguity: ADL is prevented with (), only ::f is considered
}
--
References:
1)
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-11 09:46 ---
Created an attachment (id=19537)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19537action=view)
gcc45-pr42662.patch
Fix.
Regarding the above mentioned patch, it looks like a big hammer, which will
create a lot
--- Comment #7 from jzhang918 at gmail dot com 2010-01-11 10:11 ---
Sorry, I should have checked my patch with the test code you posted before I
added that comment. My patch does not fix this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42662
--- Comment #7 from dominiq at lps dot ens dot fr 2010-01-11 10:27 ---
(In reply to comment #6)
This patch, reverting only the change to interface.c, appears to fix the
problem. No other regressions in testsuite.
The patch reintroduces pr42353 for the test in
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-11 10:31 ---
The problem here are different holes in SSA_NAMEs - with
-fvar-tracking-assignments most of the SSA_NAME_VERSION values are one larger
than without it. -fcompare-debug dumps include these versions in some MEMs, so
it
--- Comment #3 from zsojka at seznam dot cz 2010-01-11 10:45 ---
Created an attachment (id=19538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19538action=view)
different reduced testcase
$ /mnt/svn/gcc-trunk/binary-155777-lto/bin/g++ -O1 -fcompare-debug -c
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:27
---
Jan, are you there?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-11 11:28 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:30
---
I think we should consider that x86_64-apple-darwin is not supported in 4.4 and
make sure that it will be in 4.5, in particular fix PR middle-end/42068.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:31
---
Still present?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-11 12:12 ---
Created an attachment (id=19539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19539action=view)
gcc45-pr42645.patch
Fix I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42645
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-11 12:18 ---
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00430.html
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00431.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42657
--- Comment #18 from dominiq at lps dot ens dot fr 2010-01-11 12:20 ---
Still present?
Yes!-(If it has not been fixed meanwhile, it still fails at revision 155621).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #20 from dominiq at lps dot ens dot fr 2010-01-11 12:29 ---
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
pr41478_1.f90:7:0: internal compiler error: Segmentation
--- Comment #32 from rahul at icerasemi dot com 2010-01-11 12:34 ---
I will re-test on our port and report my findings, cheers!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-11 12:38
---
Subject: Bug 41569
Author: rguenth
Date: Mon Jan 11 12:38:09 2010
New Revision: 155809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155809
Log:
2010-01-11 Richard Guenther rguent...@suse.de
PR
--- Comment #21 from pault at gcc dot gnu dot org 2010-01-11 12:50 ---
(In reply to comment #20)
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
Oh, that's weird! Does the
--- Comment #22 from burnus at gcc dot gnu dot org 2010-01-11 13:06 ---
(In reply to comment #20)
The patch in comment #19, passes all my tests, but (otherwise you'ld be
disappointed;-) compiling the reduced test in comment #8 gives a Segmentation
fault
[...]
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-01-11
13:08 ---
Fixed in r155800.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
--- Comment #23 from dominiq at lps dot ens dot fr 2010-01-11 13:50 ---
(In reply to comment #21)
Oh, that's weird! Does the original testcase and the one supplied with the
patch work?
Yes, it was under all my tests.
(In reply to comment #22)
Because of that line: Dominique, do
--- Comment #24 from dominiq at lps dot ens dot fr 2010-01-11 14:04 ---
(In reply to comment #23)
Because of that line: Dominique, do you have the draft patch for PR 42647
installed? If so, it might be the reason for the problem. Just to add
another
possibility for the failure.
When you build sqlite using GCC and -O2 parameter you get the following
warning. During runtime EXPR_FULLSIZE-nSize is mostly non-zero so it seems
that the GCC optimizer makes some assumptions that doesn't not always hold
true.
In function memset,
inlined from exprDup at sqlite3.c:61011:
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from abel at gcc dot gnu dot org 2010-01-11 14:35 ---
(In reply to comment #2)
This is the other bug in our region walk iterator that happens when pipelining
outer loops. When looking for loop exits from an inner loop that is contained
in the outer loop currently being
Various diagnostics produced from specs with %e and %n are badly formatted.
There should be no \n or other whitespace at the end of these diagnostics,
since the driver inserts a newline at the end automatically.
A single diagnostic should not be split across multiple messages, for
the sake of
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-01-11 15:04 ---
Correction: the newlines get removed before the messages are printed.
But they don't get removed by exgettext either before or after the patch
for bug 39521. As they are unnecessary (at least once the message pairs
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-01-11 15:04
---
Our previous patch (http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01215.html)
failed to correctly fix the problem, and the new testcase uncovers a flaw in
that implementation.
We 'forgot' to recompute topological
--
Summary: Undefined reference errors with -flto -fuse-linker-
plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-11
15:25 ---
Created an attachment (id=19541)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19541action=view)
testcase
GCC 4.5.0 20100107.
gcc -flto -fuse-linker-plugin pr42690.c -DBUG
--
--- Comment #7 from jjcogliati-r1 at yahoo dot com 2010-01-11 15:50 ---
(In reply to comment #6)
Try
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155739)
+++ gcc/gimple.c(working copy)
@@
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #8 from rguenther at suse dot de 2010-01-11 15:54 ---
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #7 from jjcogliati-r1 at yahoo dot
--- Comment #6 from law at redhat dot com 2010-01-11 17:14 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/10/10 01:22, irar at il dot ibm dot com wrote:
--- Comment #5 from irar at il dot ibm dot com 2010-01-10 08:22 ---
In vector_alignment_reachable_p()
--- Comment #9 from jjcogliati-r1 at yahoo dot com 2010-01-11 17:15 ---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that
--- Comment #7 from law at redhat dot com 2010-01-11 17:16 ---
Subject: Re: vectorizer created unaligned vector
insns
On 01/08/10 10:25, rguenth at gcc dot gnu dot org wrote:
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-08 17:25
---
Well, indeed we have a
--- Comment #10 from rguenther at suse dot de 2010-01-11 17:22 ---
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
--- Comment #9 from jjcogliati-r1 at yahoo dot
--- Comment #18 from goeran at uddeborg dot se 2010-01-11 17:27 ---
I did try it out as you suggested, and it seems to work just fine.
(I.e. messages from fortran/arith.c were said to come from fortraarith.c in the
pot file. But I didn't bother to investigate that, it wasn't what I
--- Comment #16 from davek at gcc dot gnu dot org 2010-01-11 17:39 ---
Confirmed that it was just a glitch of some kind.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from dominiq at lps dot ens dot fr 2010-01-11 17:50 ---
I have applied the patch in comment #19 to a clean fortran-exp and I still see
the segmentation fault when compiling the test in comment #8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #3 from manu at gcc dot gnu dot org 2010-01-11 18:17 ---
There must be some reason why this:
if (warn_return_type
TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
!current_function_returns_value !current_function_returns_null
/* Don't complain
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-11 18:23 ---
I've looked briefly at the #c4 testcase, and the problem seems to be extremely
long loc_chains. var-tracking e.g. stops for huge amount of time (many
minutes) on one bb, EH pad with 162 incoming EH edges (and no
--- Comment #26 from pault at gcc dot gnu dot org 2010-01-11 18:23 ---
(In reply to comment #25)
I have applied the patch in comment #19 to a clean fortran-exp and I still see
the segmentation fault when compiling the test in comment #8.
A that's because allocatable scalars
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-11 18:37
---
This was changed by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#705 and didn't
appear in the working draft until November.
It's hardly surprising that a compiler released in October doesn't
--- Comment #13 from manu at gcc dot gnu dot org 2010-01-11 18:39 ---
If this doesn't occur in GCC 4.5, the best we can do is to put the testcases in
the testsuite and close this. Many things changed from 4.4. to 4.5 that may
have cause the bug to disappear and that won't be backported,
--- Comment #10 from manu at gcc dot gnu dot org 2010-01-11 18:46 ---
(From update of attachment 19531)
This file has nothing to do with this bug.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2010-01-11 18:52 ---
(In reply to comment #9)
Please recategorize this report as diagnostic quality, confirm, and assign
it.
Bugs are not assigned, they are taken. But confirmed it is. Patches welcome.
--
manu at gcc dot gnu dot
--- Comment #12 from manu at gcc dot gnu dot org 2010-01-11 18:54 ---
Comeau rejects it. Is this accepts-invalid, then?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jjcogliati-r1 at yahoo dot com 2010-01-11 18:58
---
(In reply to comment #10)
Subject: Re: Internal compiler exception in with gfortran
when using -fwhole-program -flto -fopenmp
On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
---
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-11
19:05 ---
Subject: Re: [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-06
11:55 ---
[...]
I'm now
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-11 19:07 ---
(In reply to comment #3)
(even without the __noreturn__?)
Yes, even without.
I think this may be actually two bugs, one is the noreturn which should set
current_function_returns_abnormally to true, so no
--- Comment #18 from manu at gcc dot gnu dot org 2010-01-11 19:23 ---
(In reply to comment #17)
Fixed.
Richard, since this is a new feature of GCC 4.5, shouldn't we mention it in the
GCC 4.5 changes.html?
Even something short would be welcome by users, such as:
Better
A wrong REG_EQUAL is attached to SUBREG during forward propagation.
Before fwprop1
(insn 56 55 57 3 double.cpp:12 (set (reg/v:DI 180 [ _D_inf ])
(const_int 0 [0x0])) 164 {*thumb1_movdi_insn} (nil))
(insn 60 59 61 3 double.cpp:12 (set (reg:SI 189)
(const_int 2146435072
--- Comment #1 from jingyu at google dot com 2010-01-11 19:59 ---
I forgot to paste the wrong assembly code.
arm-eabi-g++ -Os -mthumb double.cpp --save-temps -c -o double.o
The assembly for the following part
_D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }};
if (*entry == _D_inf.val)
--- Comment #19 from burnus at gcc dot gnu dot org 2010-01-11 20:21 ---
(In reply to comment #1)
One detail I happened to see: The messages defined in gfc_arith_error doesn't
get any gcc-internal-format marker, though they do contain %L. Do you want a
separate bugzilla about that?
The bug is: if a class definition has a nested template class, then whenever a
code refers to a name in the nested class, gcc searches it not in the nested
template class, but it the outer class.
The bug results in gcc accepting a source text that should not be compiled, and
incorrectly compiling
--- Comment #5 from janis at gcc dot gnu dot org 2010-01-11 20:29 ---
Subject: Bug 42416
Author: janis
Date: Mon Jan 11 20:29:40 2010
New Revision: 155816
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155816
Log:
PR target/42416
* config/rs6000/rs6000.c
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-11 20:59
---
Mainline is fine.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
The strings returned from gfc_arith_error in gcc/fortran/arith.h contain the
location marker %L. But as noticed in bug 36161, they are not marked
gcc-internal-format. This marking is valuable to avoid mistakes in the
translation.
--
Summary: Missing gcc-internal-format on messages
--- Comment #20 from goeran at uddeborg dot se 2010-01-11 21:02 ---
(In reply to comment #19)
Yes please.
I've filed bug 42693 about that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
--- Comment #14 from simon at pushface dot org 2010-01-11 21:35 ---
Concur with Eric.
Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
of procedure here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
Right now, the compiler has no special code to optimize pow (x, 0.75) into
something like sqrt (x) * sqrt (sqrt (x)) under -ffast-math, nor pow (x, 0.25)
into sqrt (sqrt (x)). On machines with a builtin sqrt instruction, it is often
times faster to do the calculations using sqrt than calling the
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2010-01-11 21:41
---
Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
of procedure here.
You'd need to go through the full testing procedure described here:
http://gcc.gnu.org/contribute.html
--
--- Comment #1 from meissner at gcc dot gnu dot org 2010-01-11 21:42
---
Created an attachment (id=19542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19542action=view)
Program to demonstrate the slowdown
This program calculates the speed of various pow arguments.
--
The build fails with
../../gcc-trunk-svn/gcc/config/vxworks.c: In function
vxworks_emutls_var_fields:
../../gcc-trunk-svn/gcc/config/vxworks.c:73:27: error: macro build_decl
requires 4 arguments, but only 3 given
../../gcc-trunk-svn/gcc/config/vxworks.c:72:11: error: build_decl undeclared
--- Comment #1 from simon at pushface dot org 2010-01-11 21:47 ---
Created an attachment (id=19543)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19543action=view)
Patch to gcc/config/vxworks.c
Adds new parameter required by change to gcc/tree.
--
--- Comment #9 from danglin at gcc dot gnu dot org 2010-01-11 21:51 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00066.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-11 22:00
---
The REG_EQUAL note is correct after fwprop but not after combine, so the
problem lies in combine. The note should have been removed by
adjust_for_new_dest since the destination of I3 has changed.
--
--- Comment #8 from janis at gcc dot gnu dot org 2010-01-11 22:10 ---
I bootstrapped on powerpc64-linux c,c++,fortran with the earlier big
selective-scheduling patch plus the patch in comment #7 of this PR and the
patch in comment #4 of PR42246. The resulting GCC gets no failures for
--- Comment #10 from simon at pushface dot org 2010-01-11 22:12 ---
I have (locally!) rolled back the change to ipa.c in r154121 as suggested and
successfully built a compiler which successfully compiles the test case in
p.txt. Will that be an adequate basis for a patch to resolve this
--- Comment #1 from burnus at gcc dot gnu dot org 2010-01-11 22:29 ---
Confirm. One possibility would be to modify
gcc/po/exgettext
to recognize %L -- while a simple hack would be to use:
--- arith.c (Revision 155812)
+++ arith.c
@@ -91,6 +91,7 @@
switch (code)
{
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2010-01-11 23:21
---
Due to target defining linker name.
Fixed 4.5 HEAD
Author: hutchinsonandy
Date: Mon Jan 11 23:12:14 2010
New Revision: 155819
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155819
Log:
2010-01-11
--- Comment #21 from sje at cup dot hp dot com 2010-01-11 23:32 ---
Created an attachment (id=19544)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19544action=view)
ia64 patch (fixes int, not short or char)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
--- Comment #22 from sje at cup dot hp dot com 2010-01-11 23:33 ---
I am looking at this on IA64 and fixing it for V2SI seems simple enough.
I will attach a patch. But I am not sure what to do for V4HI and V8QI.
The current code uses an 'unsigned saturating subtraction' and that
--- Comment #23 from hjl dot tools at gmail dot com 2010-01-12 00:41
---
(In reply to comment #22)
I am looking at this on IA64 and fixing it for V2SI seems simple enough.
I will attach a patch. But I am not sure what to do for V4HI and V8QI.
The current code uses an 'unsigned
SPEC CPU2006 tests 464.h264ref and 482.sphinx3 fail to build on powerpc64-linux
with -m64 -lto -fsigned-char. For some reason we've added the option
-fsigned-char to the SPEC config files for those two tests; without it both
tests fail at runtime for -m64, but it doesn't affect the results for
--- Comment #11 from redi at gcc dot gnu dot org 2010-01-12 00:54 ---
Subject: Bug 35569
Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #17 from redi at gcc dot gnu dot org 2010-01-12 00:54 ---
Subject: Bug 42593
Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #18 from redi at gcc dot gnu dot org 2010-01-12 00:54 ---
Subject: Bug 24803
Author: redi
Date: Tue Jan 12 00:53:30 2010
New Revision: 155826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155826
Log:
2010-01-12 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #12 from redi at gcc dot gnu dot org 2010-01-12 00:54 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from redi at gcc dot gnu dot org 2010-01-12 00:55 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from sje at cup dot hp dot com 2010-01-12 00:58 ---
Never mind, when I copied (and modified) the x86 tests for ia64 I forgot to put
a 'return 0' at the end of the main program so I was getting a non-zero exit.
I will test my patch tonight and if all looks good submit it
--- Comment #13 from redi at gcc dot gnu dot org 2010-01-12 01:00 ---
(In reply to comment #12)
Comeau rejects it. Is this accepts-invalid, then?
I think so, as I suggested in comment 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
--- Comment #14 from redi at gcc dot gnu dot org 2010-01-12 01:08 ---
(In reply to comment #9)
requires six posts from experts to explain.
I'm not sure where you got that number, after my second comment I was
correcting my own typos or your misunderstanding of unnamed namespaces :)
--- Comment #15 from igodard at pacbell dot net 2010-01-12 01:12 ---
Should I submit a second report so there is one for accepts invalid and a
different one for diagnostic quality?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
--- Comment #3 from jingyu at google dot com 2010-01-12 02:45 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Mon, Jan 11, 2010 at 2:00 PM, ebotcazou at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #2 from ebotcazou at gcc dot gnu dot
--- Comment #13 from foom at fuhm dot net 2010-01-12 06:27 ---
The crash is still present for my code. I'm using:
g++ (Debian 20091228-2) 4.5.0 20091228 (experimental) [trunk revision 155486]
on AMD64.
Passing -fno-ipa-cp also makes the bug disappear for me. But apparently r154673
did
1 - 100 of 104 matches
Mail list logo
