--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-13 14:57 ---
Created an attachment (id=19282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19282action=view)
testcase
Preprocessed source produced on i?86-linux. I'll try to auto-reduce it, the
present one doesn't build
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 15:04 ---
Please update to 4.4.2 at least. Without a testcase we can't do anything
here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 15:19 ---
The type is addressable and we're creating the temporary on behalf of
early SRA through force_gimple_operand_gsi.
VIEW_CONVERT_EXPRstruct PixelARGB(SR.9075)
it's not necessary to do this gimplification as the stmt
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 15:32 ---
Created an attachment (id=19283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19283action=view)
auto-reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-13 15:34 ---
4.4.2 works with the reduced testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-13 16:04 ---
typedef unsigned char uint8;
typedef unsigned int uint32;
class PixelARGB {
public:
~PixelARGB() throw() { }
PixelARGB (const uint32 argb_) throw() : argb (argb_) { }
inline
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-13 16:19 ---
F2008 allows C_SIZEOF in initialization expressions:
The definition for specification inquiry is in Fortran 2008 (7.1.11
Specification expression):
A speci cation inquiry is a reference to
(1) an intrinsic inquiry
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-13 16:22 ---
While looking at this one, I found two oddities:
* There are two similar special-case handlers for ISOCBINDING_NULL_[FUN]PTR,
one in trans-expr.c(gfc_conv_initializer), the other in trans-const.c
$ cat ice-on-onvalid.f90
INTERFACE
PURE INTEGER FUNCTION spec_func()
END FUNCTION
END INTERFACE
INTEGER :: p(spec_func()) = 23 ! scalar initializer, works without
IF (SIZE(p) /= 42) CALL abort()
IF (ANY(p /= 23)) CALL abort()
END
PURE INTEGER FUNCTION spec_func()
$ cat warning.f90
MODULE m
TYPE :: t1
INTEGER :: a = 1 ! component with default initializer first
INTEGER :: b
END TYPE
TYPE :: t2
INTEGER :: a ! component without default initializer first
INTEGER :: b = 2
END TYPE
CONTAINS
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-13 17:36 ---
Subject: Bug 42357
Author: rguenth
Date: Sun Dec 13 17:36:20 2009
New Revision: 155193
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155193
Log:
2009-12-13 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 17:36 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-13 17:52 ---
Re-confirmed with todays trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from skunk at iskunk dot org 2009-12-13 20:09 ---
This bug persists in 4.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39951
This meta bug is for serious bugs (wrong-code, rejects-valid,
ice-on-valid-code) which should be given a high priority.
If the problem is already a Fortran 90/95 problem, please mark as blocking PR
32834 instead.
This PR is here in order prioritize the gfortran work. Adding a huge number of
PRs
--- Comment #9 from hutchinsonandy at gcc dot gnu dot org 2009-12-13 21:03
---
Subject: Bug 23726
Author: hutchinsonandy
Date: Sun Dec 13 21:03:41 2009
New Revision: 155195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155195
Log:
PR target/23726
* config/avr/predicates.md
--- Comment #10 from hutchinsonandy at gcc dot gnu dot org 2009-12-13
21:05 ---
Fixed 4.5
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-13 21:09 ---
One can get rid of this by making the vtypes private:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155182)
+++
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-13 21:41 ---
Btw, here is a reduced/modified test case which gives the same error:
module m0
type :: t
end type
end module
module m1a
use m0
class(t), pointer :: c1
end module
module m1b
use m0
class(t), pointer ::
--- Comment #18 from janus at gcc dot gnu dot org 2009-12-13 21:51 ---
r155024 contains the patch in comment #12, which fixes comment #9, but not the
double free issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:51 ---
Subject: Bug 42027
Author: matz
Date: Sun Dec 13 21:51:34 2009
New Revision: 155196
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155196
Log:
PR tree-optimization/42027
* dojump.c (do_jump
--- Comment #7 from matz at gcc dot gnu dot org 2009-12-13 21:53 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:57 ---
Mark it so.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from burnus at gcc dot gnu dot org 2009-12-13 22:05 ---
Paul what is the status of this PR? I see a commit as last comment. Is this
fixed? Is something missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-13
22:06 ---
This bug has disappeared.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-13 22:18 ---
*** Bug 41264 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-12-13 22:18
---
Mark as dup of a single vartracking is slow with VTA bug.
*** This bug has been marked as a duplicate of 41371 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-13 22:18 ---
Another testcase is attached to PR41264.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-13 22:20 ---
*** This bug has been marked as a duplicate of 42178 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-13 22:20 ---
*** Bug 42211 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The dwarf debug code generated by gcj in gcc trunk is not backward compatible
with the older gdb release used by Apple in darwin10. When compiled as...
gcj WalkerTest.jar -w -bind_at_load -multiply_defined suppress
-Wl,-allow_stack_execute --main=WalkerTest -g -lm -o WalkerTest.exe
The
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-13 22:31 ---
Sounds like this should be reported to Apple really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42362
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:34 ---
Created an attachment (id=19284)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19284action=view)
assembly from WalkerTest.jar in gcc trunk on x86_64-apple-darwin10
Generated with...
gcj
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:34 ---
Created an attachment (id=19285)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19285action=view)
assembly from WalkerTest.jar in gcc 4.4.2 on x86_64-apple-darwin10
Generated using...
gcj
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:36 ---
Created an attachment (id=19286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19286action=view)
diff between assembly from gcc 4.4.2 and gcc trunk on x86_64-apple-darwin10
--
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:37 ---
Using built-in specs.
Reading specs from
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:41 ---
(In reply to comment #1)
Sounds like this should be reported to Apple really.
True except that i recall some discussion of making at least a minimal effort
to be backward compatible with older gdb's.
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-13 22:59 ---
This isn't a gcc bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from doko at gcc dot gnu dot org 2009-12-13 23:45 ---
Subject: Bug 40133
Author: doko
Date: Sun Dec 13 23:45:12 2009
New Revision: 155200
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155200
Log:
2009-12-11 Paolo Carlini paolo.carl...@oracle.com
--- Comment #25 from matz at gcc dot gnu dot org 2009-12-13 23:48 ---
The reason that the testcase still is slow (and that the inner loop isn't
unrolled or vectorized) is still the calculation of countm1. The division
therein stays in the second inner loop, whereas with GCC 4.3 it can
/obj/trunk-g/gcc/xgcc -B/obj/trunk-g/gcc/ -O1 -w -c -g -o pr37913.o
/home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c^M
/home/richard/src/trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c: In
function 'baz':^M
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42363
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 00:06 ---
Happens after copyprop.
(gdb) call debug_bb (bb)
;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 1
;; pred: ENTRY (fallthru,exec)
;; succ:
bb 2:
i_1 = bar ();
# DEBUG i = i_1
we
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-14 00:07 ---
Of course the LHS is never assigned to so the debug stmt is useless and we
should refrain from inserting it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42363
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01178.html
Running target unix/-g
FAIL: g++.dg/charset/function.cc scan-assembler-not foobar
FAIL: g++.dg/cpp0x/variadic31.C (internal compiler error)
FAIL: g++.dg/cpp0x/variadic31.C (test for excess errors)
FAIL: g++.dg/cpp0x/variadic32.C
--- Comment #11 from debian-gcc at lists dot debian dot org 2009-12-14
00:19 ---
fixed on the trunk
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-12-14
00:21 ---
fixed on the trunk
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #2 from igodard at pacbell dot net 2009-12-14 04:51 ---
Well, I see several issues with the diagnostics.
1) The call is not ambiguous, because if it were (only) ambiguous then removing
the base baz would disambiguate. Instead the case without baz gets you:
--- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 ---
And if I fix this problem (so that only one reference to *n_9) remains
I hit the problem that the fortran frontend emits the computation of countm1
after the loop bound test. No pass is moving code in front of that
--- Comment #7 from pault at gcc dot gnu dot org 2009-12-14 05:20 ---
(In reply to comment #6)
Paul what is the status of this PR? I see a commit as last comment. Is this
fixed? Is something missing?
From everything that I can see, it is fixed. Thanks for the reminder.
Paul
--
--- Comment #27 from matz at gcc dot gnu dot org 2009-12-14 05:25 ---
Created an attachment (id=19287)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19287action=view)
three hacks
My current collection of patches and hacks for this problem. Obviously the
if (0) in tree-ssa-pre.c
My cpu is an amd athlon II 240 and My CFLAGS is -O3 -pipe -march=sse
-mfpmath=sse -mveclibabi=svml, All went ok until compile libgomp multilib 32
bit.
the compiling message is :
/bin/sh ./libtool --tag=CC --mode=compile /home/xhs/build/gcc/./gcc/xgcc
-B/home/xhs/build/gcc/./gcc/
--- Comment #1 from linuxl4 at sohu dot com 2009-12-14 05:52 ---
Sorry, My CFLAGS is My CFLAGS is -O3 -pipe -march=native
-mfpmath=sse -mveclibabi=svml
--
linuxl4 at sohu dot com changed:
What|Removed |Added
--- Comment #12 from rwgk at yahoo dot com 2009-12-14 06:05 ---
(In reply to comment #10)
What do you mean by of this type? As I tried already to explain, until the
ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
list::splice.
Sorry, I wasn't looking carefully
54 matches
Mail list logo
