--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-19 07:31 ---
(In reply to comment #1)
Here is a preliminary patch which fixes the test case:
if (fsym e-expr_type != EXPR_NULL
((fsym-attr.pointer
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-19 07:32 ---
Patch by Janus: http://gcc.gnu.org/ml/fortran/2009-06/msg00177.html
(I try to get it reviewed soon.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40427
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-19 08:11 ---
Subject: Bug 40450
Author: janus
Date: Fri Jun 19 08:11:21 2009
New Revision: 148690
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148690
Log:
2009-06-19 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-19 08:16 ---
Fixed with r148690. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||39627
nThis||
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2009-06-16 10:03:48 |2009-06-19
I just tried to compile the Suse Linux package koffice-1.6.3-214.23
with the G++ compiler version 4.5 snapshot 20090618.
The compiler said
KoAutoFormatDia.moc: In member function 'void
KoAutoFormatDia::changeAutoformatLanguage(const QString)':
KoAutoFormatDia.moc:380:93: internal compiler error:
--- Comment #1 from dcb314 at hotmail dot com 2009-06-19 11:28 ---
Created an attachment (id=18023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18023action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40492
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-19 11:35 ---
What are the excess errors?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40491
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-19 11:47 ---
Jakub, ping? Given that we now have PR40485?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
--- Comment #8 from dragan at plusplus dot co dot yu 2009-06-19 12:05
---
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2837.pdf
page 40 - clause 8.5.3
page 41 - clauses 12.1, 12.4, 12.8
My vote goes to the first option.
Guess we'll wait and see...
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-19 12:23 ---
Subject: Bug 39855
Author: rguenth
Date: Fri Jun 19 12:23:16 2009
New Revision: 148700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148700
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-06-19 12:23
---
Subject: Bug 39013
Author: rguenth
Date: Fri Jun 19 12:23:16 2009
New Revision: 148700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148700
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-06-19 12:24
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-19 12:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-19 12:37 ---
Confirmed. Caused by new SRA - we are creating a temporary with
TREE_ADDRESSABLE
type.
typedef unsigned short ushort;
class QChar {
public:
QChar( const QChar c );
ushort ucs;
};
inline QChar::QChar( const
--- Comment #10 from hjl dot tools at gmail dot com 2009-06-19 12:55
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.4 4.4.1 4.5.0 |4.3.3 4.4.0
Known to work||4.3.4
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-19 13:14 ---
(In reply to comment #2)
Confirmed. Caused by new SRA - we are creating a temporary with
TREE_ADDRESSABLE
type.
Again? Well, let me see where...
--
jamborm at gcc dot gnu dot org changed:
--- Comment #2 from ubizjak at gmail dot com 2009-06-19 13:58 ---
(In reply to comment #1)
What are the excess errors?
Executing on host: /home/uros/gcc-build/gcc/xgcc -B/home/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/20080522-1.c-ansi
-pedantic-errors -S
--- Comment #3 from ubizjak at gmail dot com 2009-06-19 14:09 ---
Ah, they are truncated instead of removed:
r148664 | razya | 2009-06-18 18:08:00 +0200 (Thu, 18 Jun 2009) | 2 lines
see removal
I'll take
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-19 14:18 ---
Ah, they are truncated instead of removed:
The same is true for at least gcc/see.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40491
--- Comment #5 from uros at gcc dot gnu dot org 2009-06-19 14:22 ---
Subject: Bug 40491
Author: uros
Date: Fri Jun 19 14:22:16 2009
New Revision: 148705
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148705
Log:
* optabs.h (enum optab_index): Add new OTI_significand.
--- Comment #6 from ubizjak at gmail dot com 2009-06-19 14:27 ---
(In reply to comment #4)
Ah, they are truncated instead of removed:
The same is true for at least gcc/see.c.
I have removed this file as well in a follow-up commit.
Fixed.
--
ubizjak at gmail dot com changed:
--- Comment #2 from pthaugen at gcc dot gnu dot org 2009-06-19 14:41
---
Created an attachment (id=18024)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18024action=view)
testcase
The attatched testcase is from cpu2006 component 464.h264ref and appears to
fail in the same manner
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-06-19 15:31
---
I've just noticed this bit of install.texi:
The build process works more smoothly with the legacy Sun tools so, if you
have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend that you place
@file{/usr/bin}
New SRA, revision 147980:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
miscompiled binutils in CVS on Linux/x86-64:
FAIL: CFI on x86-64
FAIL: CFI on i386
FAIL: i386 general
FAIL: i386 naked reg
FAIL: i386 opcodes
FAIL: i386 opcodes (Intel disassembly)
FAIL: i386 opcodes (w/ suffix)
FAIL:
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-19 16:14 ---
Subject: Bug 39240
Author: rguenth
Date: Fri Jun 19 16:13:53 2009
New Revision: 148717
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148717
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-19 16:14
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following loop, which seems valid according to the OpenMP specification
v2.5 and 3.0 fails to terminate:
int x;
#pragma omp parallel for schedule(guided)
for(x = 3; x 478; x += 2) {
...
}
I've tested with two and eight threads and different chunksizes, with the same
non-termination
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-19 16:51
---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-19 16:51 ---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-19 17:11 ---
Fixed by the backports for PRs39455 and 40087.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-19 17:17 ---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-06-19 17:18
---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-19 17:18
---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-19 17:27 ---
Created an attachment (id=18025)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18025action=view)
Fix
The offset we pass to build_ref_for_offset in sra_modify_assign does not make
any sense. I am about to
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-06-19 18:09 ---
I will look into this next week. However, I have never compiled binutils
before, so unless it is obvious, please describe how to reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-19 18:24 ---
(In reply to comment #1)
I will look into this next week. However, I have never compiled binutils
before, so unless it is obvious, please describe how to reproduce the problem.
Just download the current Linux
--- Comment #4 from edmar at freescale dot com 2009-06-19 20:16 ---
Folks here at Freescale are requesting me this very same fix.
But the proposed patch were never committed. Any particular reason why not ?
--
edmar at freescale dot com changed:
What|Removed
On Linux/ia32, revision 148718 gave
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task-4.C -O (test for excess errors)
Revision 148711 is OK. Revision 148718:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00701.html
may be the cause.
--
Summary: [4.5
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-19 20:37 ---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-19 21:22 ---
Subject: Bug 40482
Author: ramana
Date: Fri Jun 19 21:22:44 2009
New Revision: 148728
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148728
Log:
Fix PR 40482
2009-06-19 Ramana Radhakrishnan
Current trunk ICE's as follows when -fprefetch-loop-arrays is specified. The
testcase that will be attatched is trimmed down from cpu2006 benchmark
483.xalancbmk.
work/spec_err /home/pthaugen/install/gcc/trunk/bin/g++ -c -m64 -O2
-fprefetch-loop-arrays DOMString.cpp
DOMString.cpp: In static
--- Comment #1 from pthaugen at gcc dot gnu dot org 2009-06-19 21:32
---
Created an attachment (id=18026)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18026action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40496
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-06-19 21:44
---
Subject: Bug 35318
Author: rguenth
Date: Fri Jun 19 21:44:24 2009
New Revision: 148730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148730
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-19 21:44
---
Subject: Bug 36607
Author: rguenth
Date: Fri Jun 19 21:44:24 2009
New Revision: 148730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148730
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-19 21:44 ---
Subject: Bug 40204
Author: rguenth
Date: Fri Jun 19 21:44:24 2009
New Revision: 148730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148730
Log:
2009-06-19 Richard Guenther rguent...@suse.de
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-19 21:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-19 21:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-06-19 21:46
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pault at gcc dot gnu dot org 2009-06-19 21:58 ---
Subject: Bug 40440
Author: pault
Date: Fri Jun 19 21:58:27 2009
New Revision: 148731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148731
Log:
2009-06-19 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #5 from pault at gcc dot gnu dot org 2009-06-19 22:10 ---
Subject: Bug 40402
Author: pault
Date: Fri Jun 19 22:10:45 2009
New Revision: 148732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148732
Log:
2009-06-20 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #6 from pault at gcc dot gnu dot org 2009-06-19 22:11 ---
Fixed on trunk and 4.4.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-19 22:20 ---
Hence fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-19 22:55 ---
Confirmed, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-19 23:14 ---
The difference essentially is because all functions getting inlined into
BZ2_Compress_Block with the newer heuristics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #3 from amodra at bigpond dot net dot au 2009-06-19 23:38
---
With 148536 and current mainline cvs binutils I see no failures in the gas
testsuite. I do see a bunch of failures in the ld testsuite, which are all
because /usr/bin/ld is being run despite a -B option being
Hello
using gcc 4.4 with -std=c++0x and libstdc++ off the trunk, I get several errors
on old code.
When calling next(X) with a user defined class type X, adl does not seem to
prefer the next function defined in the namespace of X.
Testcase from boost:
I'm trying to profile DOSEMU using -pg, but I have a problem: the mcount()
implementation here depends on GS being set to the value that libc (or the
kernel) initialized it to. (Presumably, mcount() needs access to thread local
state.)
However, DOSEMU has some signal handlers that might be called
--
naesten at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40498
--- Comment #4 from hjl dot tools at gmail dot com 2009-06-20 01:11 ---
(In reply to comment #3)
With 148536 and current mainline cvs binutils I see no failures in the gas
testsuite. I do see a bunch of failures in the ld testsuite, which are all
because /usr/bin/ld is being run
--- Comment #1 from doko at ubuntu dot com 2009-06-20 01:21 ---
The SH port does use a linker script to link with both -lgcc_s and -lgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
--- Comment #5 from amodra at bigpond dot net dot au 2009-06-20 03:26
---
Oops, you're correct. I wan't using the compiler I thought I was. make CC=...
wasn't passing $CC down to the bfd dir for some reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
If the function epilogue has only one return instruction, then the branch to
return can be replaced by the return instruction directly.
--
Summary: [missed optimization] branch to return
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--- Comment #1 from carrot at google dot com 2009-06-20 03:56 ---
Created an attachment (id=18027)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18027action=view)
test case
The command line options are: -march=armv5te -mthumb -Os
At the end of the function we can see
b
[...@gnu-16 148734]$ cat foo.c
int
foo (int x)
{
if (x == 0)
goto l1;
else
{
int y = x + 1;
if (y == -3)
{
l1:
goto l2;
}
return y + 3;
}
l2:
return -1;
}
[...@gnu-16 148734]$ ./usr/bin/gcc -O2 foo.c -Wall -c -Werror
cc1: warnings
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-20 04:09 ---
Revision 148512:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00492.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-20 04:11 ---
Revision 148512 failed to build binutils. You may need to remove -Werror
from CFLAGS in Makefile by hand when building binutils. See PR 40500.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-20 04:19 ---
This is expected behavior, y's variable initialization is skipped.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-20 04:21 ---
(In reply to comment #2)
This is expected behavior, y's variable initialization is skipped.
y is never used by goto l1. The code is perfectly deterministic.
--
hjl dot tools at gmail dot com changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-20 04:29 ---
(In reply to comment #3)
(In reply to comment #2)
This is expected behavior, y's variable initialization is skipped.
y is never used by goto l1. The code is perfectly deterministic.
And should note this
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-20 04:33 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
This is expected behavior, y's variable initialization is skipped.
y is never used by goto l1. The code is perfectly
--- Comment #6 from ian at airs dot com 2009-06-20 05:10 ---
I added the warning to -Wall because it seemed to me to be a dubious usage
which was easily fixed. However, we can take it out of -Wall. I will ask for
opinions on g...@.
--
ian at airs dot com changed:
What
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-20 05:56 ---
There is an optimization that does this (thread prologue/epilogue insns) but it
is not always a profitable transformation, see e.g. PR40361.
You should analyze why this transformation doesn't happen for your case.
76 matches
Mail list logo
