--- Comment #3 from swapnil dot tiwari1979 at gmail dot com 2010-07-23
06:33 ---
this problem is not occuring with gcc-4.2 using any arm toolchain
but this occurs with the latest gcc version 4.4.1 why is so.
(In reply to comment #1)
> Can you reproduce this with GCC built using sources
--- Comment #6 from ak at gcc dot gnu dot org 2010-07-23 05:34 ---
Subject: Bug 44992
Author: ak
Date: Fri Jul 23 05:33:51 2010
New Revision: 162443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162443
Log:
gcc:
2010-07-10 Andi Kleen
PR lto/44992
* lto-opts
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-23 04:14 ---
It is triggered by revision 121254:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00960.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Compile following code with options -march=armv7-a -mthumb -Os
char* tq(char* p, char c1, char c2)
{
*p++ = c1;
*p++ = c2;
return p;
}
GCC 4.6 generates
strbr1, [r0, #0]
strbr2, [r0, #1]
addsr0, r0, #2
bx lr
It can be simplified to:
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-23 03:14 ---
+ /* Cast the double precision constants. This is needed when single
+ precision constants are specified or when pragma FLOAT_CONST_DECIMAL64
+ is used. The correct result is computed by the compiler when
My code use DBL_MIN with warning option "-Wold-style-cast -Werror".
But I found DBL_MIN definition has changed in gcc4.5.0
When use "./cpp -dM /dev/null", I got :
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
Why gcc use old style cast in macro?
--
Summary: __DBL_MIN__
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-07-23 03:05
---
With 4.5 about to pop a release it would be good to get this fixed for it, with
release manager approval
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
--- Comment #7 from drow at gcc dot gnu dot org 2010-07-23 02:49 ---
FYI, confirmed to fail for ColdFire.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-23 02:32 ---
It is caused by revision 162430:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00784.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #15 from sandra at gcc dot gnu dot org 2010-07-23 02:18 ---
Subject: Bug 39839
Author: sandra
Date: Fri Jul 23 02:18:07 2010
New Revision: 162438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162438
Log:
2010-07-22 Sandra Loosemore
PR tree-optimization/3
symbols for shared libraries .. done
GNU GIMPLE (GCC) version 4.6.0 20100722 (experimental)
(x86_64-apple-darwin10.4.0)
compiled by GNU C version 4.6.0 20100722 (experimental), GMP version
4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-23
01:57 ---
Created an attachment (id=21291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21291&action=view)
reduced testcase of lto1 crash when linking cns_solve.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
Current gcc trunk (but not gcc 4.5.1) ICEs when linking cns_solve using -O2
-fwhopr -fwholeprogram. The reduced test case is attached and crashes as...
[MacPro:~/badlinkdir] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr
-fwhole-program --save-temps array_reduced.f
[MacPro:~/badlinkdir] h
--- Comment #71 from pinskia at gcc dot gnu dot org 2010-07-23 01:50
---
*** Bug 45036 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-23 01:50 ---
*** This bug has been marked as a duplicate of 37216 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Source:
int main(void) {
static int foo[4];
int bar[4];
int i;
for (i = 0; i < 4; i++)
foo[i] = bar[i];
return 0;
}
Compile and run:
gcc -O3 -march=native foobar.c
a.exe
Segmentation fault (core dumped)
The loop is compiled as:
movdqu -20(%ebp), %xmm0
On Linux/ia32, revision 162431 gave
FAIL: gcc.dg/guality/pr36728-2.c -O1 line 12 y == 2
FAIL: gcc.dg/guality/pr36728-2.c -O1 line 14 y == 2
Revision 162427 is OK.
--
Summary: [4.6 Regression] FAIL: gcc.dg/guality/pr36728-2.c
Product: gcc
Version: 4.6.0
--- Comment #46 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-22
22:57 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> Did the failing bootstrap include the function.c fix in r162391, or was it an
> earlier revision?
I believe that it did. It was done a
--- Comment #45 from bernds at gcc dot gnu dot org 2010-07-22 22:54 ---
(In reply to comment #44)
> I had a success bootstrap with revision 162414 and function.c reverted
> to 162239.
Did the failing bootstrap include the function.c fix in r162391, or was it an
earlier revision?
--
--- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-22
22:46 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> > HJ, Dave, can you retest with mainline?
>
> Still same problem. I'm trying with function.c reverted to 162239.
I had a success boot
--- Comment #4 from sje at cup dot hp dot com 2010-07-22 22:29 ---
Fixed, I can now bootstrap GCC *with partial inlining turned off*. Partial
inlining still doesn't work on IA64 HP-UX, that problem is PR 44716.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #3 from rth at gcc dot gnu dot org 2010-07-22 22:04 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-22 21:44 ---
Here is an even more elementary example which shows that there is a problem for
allocatable scalars, already without any polymorphic variables:
implicit none
integer, allocatable :: afab1,afab2
allocate(afab1)
--- Comment #2 from rth at gcc dot gnu dot org 2010-07-22 21:40 ---
Subject: Bug 45027
Author: rth
Date: Thu Jul 22 21:40:41 2010
New Revision: 162429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162429
Log:
PR target/45027
* config/i386/i386.c (setup_incoming_
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-22 21:26 ---
IV-OPTS is causing it. It also fails in 4.3.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-22 21:21 ---
Reduced test case with the same output:
program bug18
type foo
integer :: i
end type foo
type bar
class(foo), allocatable :: bf
end type bar
class(foo), allocatable :: afab
type(bar) :: bb
al
--- Comment #3 from rakdver at kam dot mff dot cuni dot cz 2010-07-22
21:17 ---
Subject: Re: No prefetch for the vectorized
loop
> --- Comment #2 from changpeng dot fang at amd dot com 2010-07-22 20:52
> ---
> (In reply to comment #1)
> > The misaligned indirect-refs
--- Comment #1 from mikpe at it dot uu dot se 2010-07-22 21:13 ---
Created an attachment (id=21290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21290&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
The following program (which I'll also attach later) gives unexpected results,
where signed char values are passed as non properly sign-extended ints:
> cat char-neg.c
#include
#include
#include
static void fixnum_neg(signed char x, signed char *py, int *pv)
{
unsigned char ux, uy;
ux
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-07-22 21:08 ---
How much does this bug apply now after the changes to how aliasing happens
before inlining and such?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34416
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-22 21:05 ---
I think this is the same as PR 13563.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45032
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-22 20:58 ---
Looks related to bug 20070.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45032
--- Comment #14 from siarhei dot siamashka at gmail dot com 2010-07-22
20:54 ---
Thanks, this final variant of fix seems to work fine. Can this patch be
backported to 4.5 branch and released with gcc 4.5.1 too?
As I see it, the risk should be minimal because current gcc 4.5 branch is s
--- Comment #2 from changpeng dot fang at amd dot com 2010-07-22 20:52
---
(In reply to comment #1)
> The misaligned indirect-refs will vanish soon.
>
>From the prefetching point of view, is there any reason that we can not
prefetch
for mis-aligned or indirect refs?
--
http://g
--- Comment #22 from jakub at gcc dot gnu dot org 2010-07-22 20:49 ---
Subject: Bug 45028
Author: jakub
Date: Thu Jul 22 20:48:42 2010
New Revision: 162427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162427
Log:
PR bootstrap/45028
* recgprop.c (copyprop_hardre
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-22 20:17 ---
Fixed by revision 162390:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00744.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from jframos45 at hotmail dot com 2010-07-22 20:15 ---
Sorry. The solution is valid.
--
jframos45 at hotmail dot com changed:
What|Removed |Added
--- Comment #3 from jframos45 at hotmail dot com 2010-07-22 20:10 ---
Exactly, I was doing that.
I have put out the namespace "#include " and building was correct.
#include
#include
namespace ns3
{
...
}
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45031
The Standard requires GCC to not accept this snippet. Its description of
"delete" does not dictate overload resolution, but requires a single conversion
function to pointer type. This was handled correctly by GCC4.4, but fails with
4.6 and 4.5 (regression?)
struct A {
operator int*() { return 0;
--- Comment #17 from kargl at gcc dot gnu dot org 2010-07-22 20:03 ---
Unassign myself. I don't have the smarts to trace through
the derive type handling.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from bernds at gcc dot gnu dot org 2010-07-22 20:02 ---
Huh, I thought I'd replied to this weeks ago - probably wasn't logged in.
Reload can't determine the required structure of a memory address from a
predicate name, so it ignores predicates and only looks at constrain
--- Comment #16 from kargl at gcc dot gnu dot org 2010-07-22 20:02 ---
Created an attachment (id=21289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21289&action=view)
Updated diff that handles intrinsics type
The attached patch handles intrinsic types in match_type_spec better.
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-07-22 19:36
---
.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-22 19:33 ---
Fixed as of revision 162396.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-07-22 19:28
---
Subject: Bug 44892
Author: ebotcazou
Date: Thu Jul 22 19:28:21 2010
New Revision: 162425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162425
Log:
PR ada/44892
* gcc-interface/utils.c (co
--
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
int f(int x, int y);
int g(int x, int z)
{
int r;
if (z == 0)
r = f(x, 1);
else
r = f(x, 0);
return r + 1;
}
could be optimized to
r = f(x, (z == 0 ? 1 : 0));
which would reduce the size of the generated code, and for
most targets allow further simplifications on the COND_EXPR
--- Comment #4 from jason at gcc dot gnu dot org 2010-07-22 18:41 ---
(In reply to comment #3)
> Is there a plan for more complete C++0x/C1x atomics support?
http://gcc.gnu.org/wiki/Atomic
--
jason at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-07-22 18:29
---
OK, I have finally reached this one, I will have a look at it tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-07-22 18:22 ---
We should not be attempting indirect inlining at -O0. I'll make sure we don't.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #43 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-22
18:16 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> HJ, Dave, can you retest with mainline?
Still same problem. I'm trying with function.c reverted to 162239.
Dave
--
http://gcc.gn
--- Comment #3 from sje at gcc dot gnu dot org 2010-07-22 18:15 ---
Subject: Bug 44878
Author: sje
Date: Thu Jul 22 18:14:27 2010
New Revision: 162423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162423
Log:
2010-07-22 Steve Ellcey
PR middle-end/44878
* stm
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-07-22 18:07 ---
I have submitted a proposed fix to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01760.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44914
--- Comment #3 from Hans dot Boehm at hp dot com 2010-07-22 18:03 ---
Is there a plan for more complete C++0x/C1x atomics support? Something
eventually needs to implement the memory_order_acquire/memory_order_release
versions of these primitives? Nptl also seems to be in need of these.
--- Comment #2 from spop at gcc dot gnu dot org 2010-07-22 17:02 ---
Mine.
On trunk I am able to reproduce the ICE.
This is fixed in the Graphite branch, probably by the cleanup of the IV
canonicalization.
I will investigate a little bit more what happens in trunk, and if this is
really
--- Comment #42 from hjl dot tools at gmail dot com 2010-07-22 16:47
---
(In reply to comment #40)
> (In reply to comment #39)
> > HJ, Dave, can you retest with mainline?
> >
>
> Mainline bootstrap is OK on ia32 and Intel64
> as of revision 162408. Test is in progress
> on ia64.
>
R
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-22 16:46 ---
Fixed as of revision 162399.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from dodji at gcc dot gnu dot org 2010-07-22 16:25 ---
Subject: Bug 45024
Author: dodji
Date: Thu Jul 22 16:25:17 2010
New Revision: 162420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162420
Log:
Fix PR debug/45024
gcc/ChangeLog:
PR debug/45024
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
15:54 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
> --- Comment #20 from jakub at gcc dot gnu dot org 2010-07-22 15:32
> ---
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-22 15:36 ---
(In reply to comment #13)
> (In reply to comment #12)
> IPA-CP can do that for quite some time please try with -fno-ipa-cp.
As expected: It works with -fno-ipa-cp.
> (I don't have a trunk built with enabled fortra
--- Comment #20 from jakub at gcc dot gnu dot org 2010-07-22 15:32 ---
Created an attachment (id=21288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21288&action=view)
gcc46-pr45028.patch
I wonder if the attached (untested) patch wouldn't fix this problem.
--
http://gcc.gnu.
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-07-22 15:25 ---
I have a fix.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
15:04 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
> --- Comment #18 from jakub at gcc dot gnu dot org 2010-07-22 14:58
> ---
--- Comment #18 from jakub at gcc dot gnu dot org 2010-07-22 14:58 ---
Sounds like a cprop_hardreg bug. Before that pass we have (after a call_insn):
(insn 264 263 266 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(set
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-22 14:52 ---
Works for me now, so no way of getting a reduced testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-22 14:48 ---
This invalid program reproduces your error, so I assume that's what you've
done.
Don't do that.
#include
namespace ns3
{
#include
}
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-22 14:47 ---
Confirmed. We ICE in the vectorizer SLPing.
Somewhat reduced testcase:
SUBROUTINE XSHOW(MAASY,MBASY,MCASY,NAASY,NBASY,NCASY,
& XRMREF,XRNSYM2,XRSYMM2,XRITSY2,MBINS)
INTEGER HEAPDM
PARAM
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-22 14:44 ---
(In reply to comment #0)
> I have OpenSuse with ia64 architecture and GCC 4.3.3 (I tried also with GCC
> 4.4.0 and 4.4.4)
> I am trying building a file that include the cxxabi.h header, but the compiler
> displays follo
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-22 14:37 ---
Hi,
Patches should be sent to gcc-patc...@gcc.gnu.org rather than put in bugzilla
entries.
Even though the number of registers is theoretically 16 you are never going to
have num_saves = 16 . It's at the maximum g
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-22 14:34 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
14:29 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
> in *.expand looks correct, that var_location is %o0 instead of %g1 though. So
--- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-22
14:26 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> HJ, Dave, can you retest with mainline?
Testing.
With the previous versions, hash table lookups were somehow broken,
resulting in NULL
I have OpenSuse with ia64 architecture and GCC 4.3.3 (I tried also with GCC
4.4.0 and 4.4.4)
I am trying building a file that include the cxxabi.h header, but the compiler
displays following error:
In file included from ../src/core/callback.cc:41:
/bin/gcc/gcc-4.3.3/lib/gcc/ia64-suse-linux/4.3.3/.
--- Comment #16 from jakub at gcc dot gnu dot org 2010-07-22 14:20 ---
(insn 264 263 265 3
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:123
(set (reg/f:DI 332)
(reg:DI 8 %o0)) -1 (expr_list:REG_NOALIAS (reg/f:DI 332)
to/43850
* g++.dg/lto/20100722-1_0.C: New testcase.
Added:
trunk/gcc/testsuite/g++.dg/lto/20100722-1_0.C
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-22 14:19 ---
Fixed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-22 14:14 ---
This is a dup of PR43157.
*** This bug has been marked as a duplicate of 43157 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-22 14:14 ---
*** Bug 43658 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-22 14:10 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #40 from hjl dot tools at gmail dot com 2010-07-22 14:07
---
(In reply to comment #39)
> HJ, Dave, can you retest with mainline?
>
Mainline bootstrap is OK on ia32 and Intel64
as of revision 162408. Test is in progress
on ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #15 from ro at gcc dot gnu dot org 2010-07-22 14:07 ---
Created an attachment (id=21287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21287&action=view)
-fdump-tree-optimized output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #14 from ro at gcc dot gnu dot org 2010-07-22 14:06 ---
Created an attachment (id=21286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21286&action=view)
-fdump-rtl-expand output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #13 from jakub at gcc dot gnu dot org 2010-07-22 14:03 ---
So it is wrong already in *.split4:
(insn 256 255 258 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:117
(set (reg:DI 1 %g1 [328])
(ashift:DI (re
--- Comment #12 from ro at gcc dot gnu dot org 2010-07-22 13:54 ---
Created an attachment (id=21285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21285&action=view)
split4 dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-22 13:52 ---
Can I ask for the immediately preceeding dump too? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #10 from ro at gcc dot gnu dot org 2010-07-22 13:51 ---
Created an attachment (id=21284)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21284&action=view)
sched2 dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
13:50 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
> Can you compile with -da and find out in which dump D#71 has been introduced?
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-22 13:49
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-22 13:47
---
Subject: Bug 42451
Author: rguenth
Date: Thu Jul 22 13:47:32 2010
New Revision: 162415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162415
Log:
2010-07-22 Richard Guenther
PR lto/42451
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-22 13:42 ---
Another test case is: libgomp.fortran/retval1.f90
(Found via "cd $BUILD/*/libgomp; make check")
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45030
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 13:34 ---
So it is wrong already before *.alignments, as it has stuff like:
(insn:TI 256 255 1556 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:117
(set (reg:D
I 1
This is a bug which needs to be fixed before -fwhole-file can be enabled by
default. Otherwise, the test results look fine. (Note: I tested with
-fwhole-file enabled by default and including the patch for PR 44945.)
Extended test case: gfortran.fortran-torture/execute/entry_4.f90
real,exter
--- Comment #7 from ro at gcc dot gnu dot org 2010-07-22 13:09 ---
Created an attachment (id=21283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21283&action=view)
-fdump-rtl-alignments output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-22 13:02 ---
Thanks, can I also ask for -fdump-rtl-aligments dump (i.e. one immediately
before *.vartrack)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #6 from schwab at linux-m68k dot org 2010-07-22 12:59 ---
> Huh? This is one byte, how does endianess come into play?
By the use of bitfields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
=gcc&view=rev&rev=162414
Log:
2010-07-22 Richard Guenther
* lib/target-supports-dg.exp (dg-require-linker-plugin): New proc.
* lib/target-supports.exp (check_linker_plugin_available): Likewise.
PR lto/43373
* gcc.dg/lto/20100722-1_0.c: New testcase
=gcc&view=rev&rev=162414
Log:
2010-07-22 Richard Guenther
* lib/target-supports-dg.exp (dg-require-linker-plugin): New proc.
* lib/target-supports.exp (check_linker_plugin_available): Likewise.
PR lto/43373
* gcc.dg/lto/20100722-1_0.c: New testcase
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-07-22 12:54
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from John dot Tytgat at aaug dot net 2010-07-22 12:53
---
Created an attachment (id=21282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21282&action=view)
Proposed patch to fix the buffer overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45029
1 - 100 of 159 matches
Mail list logo
