--- Comment #2 from kargl at gcc dot gnu dot org 2010-07-09 06:02 ---
Is there a testsuite program to check this?
Perhaps, your code should be added so the
correct behavior doesn't get unfixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44879
--- 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=21156action=view)
gcc/testsuite/gcc.dg/tree-ssa/vrp50-PR28632.c
--
aldot at gcc dot gnu dot org changed:
What
--
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
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-09 08:33 ---
So we have
array_ref 0x77f0c240
type real_type 0x77ef1000 real(kind=4) SF
size integer_cst 0x77ed2708 constant 32
unit size integer_cst 0x77ed2410 constant 4
align 32
--- 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
--- 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
--- 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=gccview=revrev=161988
Log:
PR target/40657
* config/arm/arm.c
--- 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=gccview=revrev=161989
Log:
2010-07-09 Jonathan Wakely jwakely@gmail.com
PR
--- 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=gccview=revrev=161990
Log:
2010-07-09 Richard Guenther rguent...@suse.de
PR
--- 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
--- 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=gccview=revrev=161994
Log:
2010-07-09 Richard Guenther rguent...@suse.de
PR
--- 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=21157action=view)
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see differences regarding the labels
--- 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
--- 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=21157action=view) [edit]
combined ptch for 44832/44874 - WIP
For the unreduced testcase, I see
--- 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
--- 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
--- 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
--- 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
type_decl 0x75b2be60 X
type record_type
--- 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)
@@
--- 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
--- 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=gccview=revrev=161971
Log:
2010-07-08
--- 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
--- 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
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
--- 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)]
# 1 irq.c
# 1 built-in
# 1 command-line
# 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
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
--- 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=21158action=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=21159action=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
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.
function_type 0x75164b28
type record_type
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 gcc-bugzi...@gcc.gnu.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
--- 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();
--- 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=21160action=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
--- 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=gccview=revrev=162000
Log:
2010-07-09 Richard Guenther rguent...@suse.de
PR
--- 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=21161action=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
--- 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
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
--- 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=gccview=revrev=162002
Log:
PR 44877
Modified:
trunk/gcc/ChangeLog
--- 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.
--
--- 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
--- 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
--- 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)
ssa_name 0x45112e8
type integer_type 0x441 long unsigned int public unsigned sizetype
DI
size integer_cst 0x4310780 constant 64
unit size integer_cst
--- 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
--- 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
--- 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
--- 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
assembly
--- 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=21162action=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=21163action=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 rguent...@suse.de
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=gccview=revrev=162005
Log:
2010-07-09 Richard Guenther rguent...@suse.de
PR
--- 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=21164action=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),
--- 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
--- 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=21165action=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=21166action=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=21167action=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
--- 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=21168action=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
--- 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=gccview=revrev=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=gccview=revrev=162009
Log:
PR tree-optimization/28632
* tree-vrp.c
1 - 100 of 143 matches
Mail list logo
