--- Comment #19 from aldot at gcc dot gnu dot org 2010-07-09 07:53 ---
Created an attachment (id=21156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21156&action=view)
gcc/testsuite/gcc.dg/tree-ssa/vrp50-PR28632.c
--
aldot at gcc dot gnu dot org changed:
What|R
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldot at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #9 from rguenther at suse dot de 2010-07-09 08:10 ---
Subject: Re: [4.3 Regression] infinite loop in
maybe_canonicalize_comparison
On Thu, 8 Jul 2010, bergner at gcc dot gnu dot org wrote:
> --- Comment #8 from bergner at gcc dot gnu dot org 2010-07-08 21:50
> -
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-09 08:15 ---
Confirmed on darwin. I also see the same ICE with -O3 for the polyhedron test
mdbx.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 08:23 ---
Mine. If I fix the warning
t.f90:8.21:
COMMON /TRUPAR/ DX(10),V(10,10)
1
Warning: Named COMMON block 'trupar' at (1) shall be of the same size
then th
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-09 08:33 ---
So we have
unit size
align 32 symtab 0 alias set 2 canonical type 0x77ef1000 precision
32
pointer_to_this >
arg 0
type_2 BLK
size
unit size
--- Comment #11 from burnus at gcc dot gnu dot org 2010-07-09 08:38 ---
*** Bug 44814 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-09 08:38 ---
*** This bug has been marked as a duplicate of 37829 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-09 08:39 ---
I'm going to leave the bug open after that because I think the Fortran frontend
should do better than overriding the type of the common in TRUDGE from the
unused variant in TRUSRC.
Sooner or later you'll trip into a
--- Comment #12 from burnus at gcc dot gnu dot org 2010-07-09 08:48 ---
For intrinsic modules, we currently have:
use iso_c_binding, only: c_null_ptr
which use-associates a constant (PARAMETER) of the type "c_ptr" - but "c_ptr"
is not imported directly; to make the type information a
--- Comment #11 from bernds at gcc dot gnu dot org 2010-07-09 09:03 ---
Subject: Bug 40657
Author: bernds
Date: Fri Jul 9 09:03:22 2010
New Revision: 161988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161988
Log:
PR target/40657
* config/arm/arm.c (thumb1_ext
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-09 09:44 ---
Subject: Bug 44875
Author: redi
Date: Fri Jul 9 09:44:14 2010
New Revision: 161989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161989
Log:
2010-07-09 Jonathan Wakely
PR libstdc++/44875
*
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-09 09:46 ---
Fixed version visible at
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/doc/html/manual/status.html?view=co
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #49 from amylaar at gcc dot gnu dot org 2010-07-09 10:02
---
I'm working on a fix for 44874, it it seems we are missing references of
LABEL_DECLs by gotos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-09 10:05 ---
Subject: Bug 44882
Author: rguenth
Date: Fri Jul 9 10:05:27 2010
New Revision: 161990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161990
Log:
2010-07-09 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-09 10:10 ---
ICE fixed. Fortran FE problem remains.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-07-09 10:27
---
.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
There is a regression in gnat.dg visible on various 32-bit platforms:
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00744.html
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00743.html
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00709.html
The problem is that the new code seems to
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-09 11:24 ---
Subject: Bug 44852
Author: rguenth
Date: Fri Jul 9 11:24:09 2010
New Revision: 161994
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161994
Log:
2010-07-09 Richard Guenther
PR tree-optimization/
--- Comment #50 from amylaar at gcc dot gnu dot org 2010-07-09 11:38
---
Created an attachment (id=21157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21157&action=view)
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see differences regarding the labels do_sub
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-09 11:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-09 11:42 ---
Can you elaborate? The relevant type for the MEM_REF is always that of the
base object, which is either a dereference (thus, of sth addressable) or
a decl (which can't be non-aliased as well, no?).
--
rguenth at
--- Comment #51 from rguenth at gcc dot gnu dot org 2010-07-09 11:47
---
(In reply to comment #50)
> Created an attachment (id=21157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21157&action=view) [edit]
> combined ptch for 44832/44874 - WIP
>
> For the unreduced testcase, I se
--- Comment #15 from dominiq at lps dot ens dot fr 2010-07-09 12:02 ---
The patch in comment #10 avoids the extra temporaries and recovers the original
timings. Regstrapped without regression and passed my tests. Note also that it
"fixes" pr44744.
Concerning the test in comment #13 it g
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-09 12:11 ---
> This version fixes the problem with channel.f90 and has cleaned-up/extra
> comments
The patch in comment #3 fixes the problems with channel.f90, regstrapped and
passed my tests.
I have also checked that gfortran be
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-09 12:16 ---
(In reply to comment #5)
> I'm going to leave the bug open after that because I think the Fortran
> frontend should do better than overriding the type of the common in TRUDGE
> from the unused variant in TRUSRC.
Can
--- Comment #9 from rguenther at suse dot de 2010-07-09 12:21 ---
Subject: Re: [4.6 Regression] Bogus types in references
with mismatched commons
On Fri, 9 Jul 2010, burnus at gcc dot gnu dot org wrote:
> --- Comment #8 from burnus at gcc dot gnu dot org 2010-07-09 12:16
>
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-09 12:26 ---
(In reply to comment #13)
> What about
> dudx = ddx(u(:,:,2))
> real function ddx(array)
> real, dimension(:,:) :: array
> call bar(u)
> ddx = array(1,1)
> AFAICS, this is legal and would require a
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-09 12:42 ---
The hard part with changing the C frontend to behave like the C++ frontend
is to preserve the debug info for the typedef.
The C frontend consistently uses DECL_ORIGINAL_TYPE to refer to what a
TYPE_DECL was typedeff
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-09 12:52 ---
The only difference I see for typedef struct { } T1; vs typedef struct X { }
T1;
when looking at its main variant (or recursively DECL_ORIGINAL_TYPE) is
unit size
align 8 symtab 0 alias set -1 can
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-09 13:01 ---
The following seems to work at least for the testcase:
Index: gcc/tree.c
===
--- gcc/tree.c (revision 161994)
+++ gcc/tree.c (working copy)
@@ -4298,
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-07-09 13:05
---
> Can you elaborate? The relevant type for the MEM_REF is always that of the
> base object, which is either a dereference (thus, of sth addressable) or
> a decl (which can't be non-aliased as well, no?).
In 144t
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-09
13:16 ---
Note that the revised version of the patch was applied as...
Author: ktietz
Date: Thu Jul 8 17:53:44 2010
New Revision: 161971
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161971
Log:
2010-07-0
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-09 13:22 ---
(In reply to comment #9)
> And when compilers do not reject such code it will never be fixed ;)
> Does GFortran have something like -fpermissive?
-std=legacy
The problem with fixing: That helps for actively maint
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 13:23 ---
Ah, that makes sense. Confirmed btw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-09 13:28 ---
Btw, can we amend the stmt verifier to check that the address of such
a thing is not taken? I'm thinking of verify_expr here:
case ADDR_EXPR:
{
tree tem;
gcc_assert (is_gimple_address (t)
Compare the results here
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00739.html
and here:
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00740.html
You can notice a large chunk of failures caused with :
FAIL: gcc.dg/vect/pr30771.c (internal compiler error)
FAIL: gcc.dg/vect/pr30771.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-09 13:49 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #11 from hjl dot tools at gmail dot com 2010-07-09 13:51
---
FWIW, the original testcase, vibanl.fppized.f, doesn't
have type mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
Between 20100628 and 20100705, all Objective-C execution tests started to fail
on
Solaris 2/SPARC. E.g,
FAIL: objc.dg/bitfield-1.m -fgnu-runtime execution test
bitfield-1.exe SEGVs with this stacktrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
sel_get
# 1 "irq.c"
# 1 ""
# 1 ""
# 1 "irq.c"
extern void add_irq(int, void (*irq)(void));
extern void do_something(void);
static __attribute__ ((interrupt("IRQ"))) void irq(void)
{
unsigned long ints;
ints = (*(volatile unsigned long *)(0x));
ints &= ~(*(volatile unsigned long *)(0x
j...@evans:/abuild/jh/mozilla-central/build8/layout/build>
/abuild/jh/trunk-install/bin/g++ ~/ns*.ii -O2 -fwhopr -r -nostdlib
In file included from ../../../js/src/xpconnect/src/xpcprivate.h:58:0,
from ../../../js/src/xpconnect/src/xpcmodule.h:41,
from ../../../lay
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-09 14:23 ---
Created an attachment (id=21158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21158&action=view)
first part of testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-09 14:23 ---
Created an attachment (id=21159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21159&action=view)
second part of testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
--- Comment #12 from dominiq at lps dot ens dot fr 2010-07-09 14:35 ---
Reduced test case extracted from the polyhedron test mdbx.f90 that give an ICE
at revision 161959:
[karma] lin/test% cat mdbx_red.f90
!*==MASTER.spg processed by SPAG 6.55Dc at 09:26 on 23 Sep 2005
SUBROUTINE
The pr30388.c test case ICE's on trunk and powerpc64-linux with the following
options: -Os -m64
Looking at a backtrace, we're hitting this assert in tree.c:build2_stat():
if (code == POINTER_PLUS_EXPR && arg0 && arg1 && tt)
gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0)
--- Comment #10 from bergner at gcc dot gnu dot org 2010-07-09 14:37
---
Yes, it ICE's on trunk. I just opened PR44890 for the new ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 14:42 ---
Pointed-to types mismatching.
Field types not compatible.
Pointed-to types mismatching.
Field types not compatible.
Pointed-to types mismatching.
Not compatible.
for two different
http://gcc.gnu.org/bugzilla/
Can you give the full backtrace? Where is the build2 being called from?
On Jul 9, 2010, at 7:36 AM, "bergner at gcc dot gnu dot org" > wrote:
The pr30388.c test case ICE's on trunk and powerpc64-linux with the
following
options: -Os -m64
Looking at a backtrace, we're hitting this assert in
--- Comment #1 from pinskia at gmail dot com 2010-07-09 14:48 ---
Subject: Re: New: Hitting gcc_assert in build2_stat with pr30388.c testsuite
test case
Can you give the full backtrace? Where is the build2 being called from?
On Jul 9, 2010, at 7:36 AM, "bergner at gcc dot gnu dot org
j...@evans:/abuild/jh/mozilla-central/build8/ipc/ipdl>
/abuild/jh/trunk-install/bin/g++ ~/PTestDataStructuresParent.ii -O2 -r -fwhopr
-nostdlib
In file included from :244:0:
PTestDataStructuresParent.cpp: In member function Read:
PTestDataStructuresParent.cpp:1810:1: error: non-trivial conversion
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-09 14:52 ---
Testcase:
t1.c
struct X;
struct Y {
struct X (*fnptr)(void);
};
struct Y foo;
t2.c
struct X { int i; };
struct Y {
struct X (*fnptr)(void);
};
extern struct Y foo;
int main()
{
foo.fnptr();
re
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-09 14:52 ---
Created an attachment (id=21160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21160&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44891
--- Comment #2 from bergner at gcc dot gnu dot org 2010-07-09 14:53 ---
Full backtrace:
(gdb) bt
#0 fancy_abort (file=0x10ab02e0
"/home/bergner/gcc/gcc-mainline-r161924/gcc/tree.c", line=3717,
function=0x10aafb20 "build2_stat")
at /home/bergner/gcc/gcc-mainline-r161924/gcc/diagnost
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-09 15:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 15:01 ---
Subject: Bug 44886
Author: rguenth
Date: Fri Jul 9 15:01:14 2010
New Revision: 162000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162000
Log:
2010-07-09 Richard Guenther
PR tree-optimization/
--- Comment #52 from amylaar at gcc dot gnu dot org 2010-07-09 15:06
---
(In reply to comment #49)
> I'm working on a fix for 44874, it it seems we are missing references of
> LABEL_DECLs by gotos.
Actually, they are marked used when the GIMPLE_LABEL itself is processed.
The problem I
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 15:14 ---
I can't find the testcase pr30388.c in the testsuite. Where is it?
(I can only see get_def_for_expr () returning a non-pointer def)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-09 15:20 ---
Created an attachment (id=21161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21161&action=view)
patch
Patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-07-09 15:59
---
> Eric, you probably know best what should be checked, can you prepare a patch
> (that hopefully passes testing ... huh)?
Yes, will do, but not before addressing the issues caught by the new size check
on VIEW_CO
--- Comment #6 from rguenther at suse dot de 2010-07-09 16:01 ---
Subject: Re: [4.6 regression] miscompilation
of gnat.dg/aliasing3.adb after mem-ref2
On Fri, 9 Jul 2010, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-07-09 15
There is another regression in gnat.dg on SPARC/PA/PPC:
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00699.html
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00722.html
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00709.html
It is caused by the new size check on VIEW_CONVERT_EXPR.
--- Comment #4 from bergner at gcc dot gnu dot org 2010-07-09 16:08 ---
gcc/testsuite/gcc.c-torture/compile/pr30338.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44890
--- Comment #6 from meissner at gcc dot gnu dot org 2010-07-09 16:10
---
Subject: Bug 44877
Author: meissner
Date: Fri Jul 9 16:10:10 2010
New Revision: 162002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162002
Log:
PR 44877
Modified:
trunk/gcc/ChangeLog
trunk/gcc/
--- Comment #2 from sje at cup dot hp dot com 2010-07-09 16:10 ---
Here is a smaller test case:
class e
{
public:
e(void* __e);
e(const e&);
};
void * v() { }
e foo() { return e(v()); }
It only fails on IA64 in 32 bit mode and the problem seems to be related
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-07-09 16:14
---
> Heh - and I specifically restricted it to registers to avoid that ... ;)
Yes, that was very kind of you. :-) But people do appalling things in Ada with
Unchecked_Conversion.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-07-09 16:16
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-09 16:19 ---
Should be fixed by this commit.
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00301.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-09 16:23 ---
With register args we can eventually end up calling convert_move on it which
will choke for different size regs. I hit this myself during mem-ref2
development which is why I added this checking.
--
rguenth at gc
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-09 16:24 ---
Same issue for function args.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44889
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-09 16:25 ---
(gdb) call debug_tree(base)
unit size
align 64 symtab 0 alias set -1 canonical type 0x441 precision
64 min max >
visited var def_stmt D.2060_43 = ivtmp.27_37
+ D.2059_42;
version
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-09 16:28 ---
Does it ICE with
Index: gcc/tree-ssa-address.c
===
--- gcc/tree-ssa-address.c (revision 161994)
+++ gcc/tree-ssa-address.c (working copy)
@@
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-07-09 16:29
---
On Solaris 9:
=== objc Summary ===
# of expected passes767
# of unexpected failures34
# of expected failures 7
# of unsupported tests 28
I wonder if there i
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09
16:34 ---
Subject: Re: [4.6 regression] All Objective-C execution tests fail on Solaris
2/SPARC
> --- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-07-09 16:29
> ---
> On Solaris 9:
>
>
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-09 16:34 ---
Ye, it ICE's there:
/home/bergner/gcc/gcc-mainline-r161924/gcc/testsuite/gcc.c-torture/compile/pr30338.c:5:5:
internal compiler error: in create_mem_ref_raw, at tree-ssa-address.c:363
Please submit a full bug report
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-09 16:35 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #29 from ian dot bolton at arm dot com 2010-07-09 17:02 ---
(In reply to comment #7)
> When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0.
SP is actually the destination here, not the source.
> This can be done by the
>
> tmrc sp, wCGR0
>
> assemb
--- Comment #7 from hubicka at ucw dot cz 2010-07-09 17:09 ---
Subject: Re: =?iso-8859-2?Q?Bogus_?=
=?iso-8859-2?Q?=22type_of_=91nsLayoutModule=5FNSModule=92_doe?=
=?iso-8859-2?Q?s?= not match original declaration" waning compiling
Mozilla
Hi,
with the patch all
--- Comment #20 from jakub at gcc dot gnu dot org 2010-07-09 17:12 ---
Created an attachment (id=21162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21162&action=view)
gcc46-pr28632.patch
Sorry, I haven't been aware of this PR. The attached patch brings in some of
the ideas from
j...@evans:/abuild/jh/mozilla-central/build9/dom/src/threads>
/abuild/jh/trunk-install/bin/g++ -fwhopr -r -nostdlib -O2 ~/nsDOMWorker*
In file included from ../../../../dom/src/threads/nsDOMWorker.cpp:39:0:
../../../dist/include/jscntxt.h: In function JSContext*
js_ContextFromLinkField(JSCList*):
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-09 18:05 ---
Created an attachment (id=21163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21163&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44893
--- Comment #3 from mikpe at it dot uu dot se 2010-07-09 18:27 ---
These new objc failures are also seen on sparc64-linux btw.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
---
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09
18:30 ---
Subject: Re: [4.6 regression] All Objective-C execution tests fail on Solaris
2/SPARC
The reghunt revealed Richard's mem-ref2 patch as the culprit:
2010-07-01 Richard Guenther
PR middle-end/42
j...@evans:/abuild/jh/mozilla-central/build9/content/base/src>
/abuild/jh/trunk-install/bin/g++ -flto -r -nostdlib tc/*.ii
In file included from ../../../../content/base/src/nsContentUtils.cpp:45:0:
../../../dist/include/jscntxt.h: In function ÂJSContext*
js_ContextFromLinkField(JSCList*)Â:
../..
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-09 18:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-09 18:32
---
Subject: Bug 44890
Author: rguenth
Date: Fri Jul 9 18:32:29 2010
New Revision: 162005
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162005
Log:
2010-07-09 Richard Guenther
PR middle-end/44890
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-09 18:35 ---
Created an attachment (id=21164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21164&action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44894
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-09 19:02 ---
Reduced test case:
type :: test_case
end type
type :: test_suite
type(test_case) :: list
end type
contains
subroutine sub(self)
class(test_suite), intent(inout) :: self
type(test_case), poin
--- Comment #5 from ro at gcc dot gnu dot org 2010-07-09 19:04 ---
I've found that sarray.o is miscompiled. The only code changes are in
sarray_at_put and sarray_put_safe, where sarray_at_put is inlined. I've not
yet found what is broken. I'm attaching the good and bad .s files and th
--- Comment #6 from ro at gcc dot gnu dot org 2010-07-09 19:05 ---
Created an attachment (id=21165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21165&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
--- Comment #7 from ro at gcc dot gnu dot org 2010-07-09 19:06 ---
Created an attachment (id=21166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21166&action=view)
good assembler output pre-patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
--- Comment #8 from ro at gcc dot gnu dot org 2010-07-09 19:07 ---
Created an attachment (id=21167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21167&action=view)
bad assembler output with patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-09 19:15 ---
Created an attachment (id=21168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21168&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44891
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-09
19:17 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
May I backport the patch to the 4.4 and 4.5 branches, too?
Thanks.
Rainer
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-09 19:18 ---
Fails w/o LTO, at -O1, after early-SRA.
gcc> /abuild/rguenther/trunk-g/gcc/g++ -B /abuild/rguenther/trunk-g/gcc -O -S
PTestDataStructuresParent.3.ii
PTestDataStructuresParent.3.ii: In member function 'bool
PTestDat
--- Comment #10 from jason at gcc dot gnu dot org 2010-07-09 19:36 ---
Subject: Bug 43120
Author: jason
Date: Fri Jul 9 19:36:19 2010
New Revision: 162008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162008
Log:
PR c++/43120
* cp-tree.h (BV_LOST_PRIMARY): New
--- Comment #21 from jakub at gcc dot gnu dot org 2010-07-09 19:40 ---
Subject: Bug 28632
Author: jakub
Date: Fri Jul 9 19:40:03 2010
New Revision: 162009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162009
Log:
PR tree-optimization/28632
* tree-vrp.c (zero_no
Compiling the gcc.c-torture/compile/2009-2.c test case on powerpc64-linux,
we get the following ICE with today's trunk:
berg...@granola3p01:~/gcc/BUGS>
/data3/bergner/gcc/build/gcc-mainline-r161924-debug/gcc/xgcc
-B/data3/bergner/gcc/build/gcc-mainline-r161924-debug/gcc/ -O2 -flto -w -S
-m3
1 - 100 of 143 matches
Mail list logo
