--- Comment #5 from bonzini at gnu dot org 2009-05-11 07:02 ---
I have a patch. It's just that TREE_OPERAND (*expr, 1) must be changed to
new_ctor.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-11 08:07 ---
Without heavily thinking about it:
> print *,public_var_with_private_type%i
Seems to be valid in Fortran 2003 (but not in 2003). The components are not
PRIVATE and thus accessibly, even if the TYPE declaration is no
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-11 08:23 ---
> Thus I would reason that g95, ifort and NAG (assuming Juergen Reuter is using
> it) are correct in accepting it.
NAG indeed accepts it with -f2003. With -f95 it reports
Extension: c0.f90, line 32: Dummy ARG of PUB
--- Comment #6 from bonzini at gnu dot org 2009-05-11 09:04 ---
Created an attachment (id=17850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17850&action=view)
patch to fix the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-11 09:17 ---
The patch caused a regression, see PR 40061
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39791
I just tried to compile the Suse Linux package djvulibre-3.5.21-1.85
with the GNU g++ version 4.5 snapshot 20090507.
The compiler said
DjVuDocEditor.cpp:596: error: EH edge 283->1258 is missing
DjVuDocEditor.cpp:596: error: unnecessary EH edge 283->982
DjVuDocEditor.cpp:596: error: EH edge 285->1
--- Comment #1 from dcb314 at hotmail dot com 2009-05-11 09:23 ---
Created an attachment (id=17851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17851&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40100
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-11 09:55 ---
Actually gfortran even has the same check as NAG that rejects a private type as
component of a public type with -std=f95. And it happens that the bug which
leads to the bogus error message lies just in this check. Thus
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #4 from bonzini at gnu dot org 2009-05-11 10:15 ---
I meant my fwprop patch. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-11 10:20 ---
> && !gfc_check_access (c->ts.derived->attr.access,
> c->ts.derived->ns->default_access))
> {
> - gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-05-11 11:15
---
I can reproduce this on x86_64-unknown-linux-gnu at -O2 with 4.3.2 and
4.5-20090402 snapshot, and at -O3 with 4.2.2
I can't reproduce it with 4.1.2
--
jwakely dot gcc at gmail dot com changed:
Wha
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-05-11 11:23
---
I was using Boost 1.37.0 with:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20090402/configure
--prefix=/dev/shm/wakelyjo/insroot/4.5-20090402 --enable-languages=c,c++
--disa
--- Comment #16 from irar at gcc dot gnu dot org 2009-05-11 11:54 ---
Subject: Bug 40074
Author: irar
Date: Mon May 11 11:54:02 2009
New Revision: 147370
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147370
Log:
PR tree-optimization/40074
* tree-vect-analyze.c (
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-11 12:03 ---
Created an attachment (id=17852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17852&action=view)
unincluded testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-11 12:04 ---
4.1 and 4.2 cannot compile the testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-11 12:23 ---
Ok, I simply consider this fixed for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-11 12:23
---
Did I say fixed?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from bonzini at gnu dot org 2009-05-11 12:28 ---
It's a latent bug somewhere, possibly in delayed branch scheduling? fwprop1
does a single copy propagation which is trivially valid.
Analyzing -O1 -fno-delayed-branch vs. -O1 -fno-delayed-branch
-fno-forward-propagate, I'm
--- Comment #17 from irar at gcc dot gnu dot org 2009-05-11 12:33 ---
Subject: Bug 40074
Author: irar
Date: Mon May 11 12:33:13 2009
New Revision: 147372
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147372
Log:
PR tree-optimization/40074
* tree-vect-data-refs.c
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-05-11 12:42
---
The testcase will have included lots of code from Boost headers conditionally
based on __GNUC__ etc. so it's not surprising it doesn't compile with 4.1 or
4.2
If wanted I can produce an unincluded version using 4
--- Comment #10 from rguenther at suse dot de 2009-05-11 12:44 ---
Subject: Re: bad optimization(?) pure virtual function
call with -O2
On Mon, 11 May 2009, jwakely dot gcc at gmail dot com wrote:
> --- Comment #9 from jwakely dot gcc at gmail dot com 2009-05-11 12:42
> ---
--- Comment #18 from irar at il dot ibm dot com 2009-05-11 12:45 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jwakely dot gcc at gmail dot com 2009-05-11 13:09
---
It does seem to be a regression. I preprocessed the program in comment 4 with
GCC version 4.1.2 20071124 (Red Hat 4.1.2-42), then ran uninclude to produce a
standalone testcase and compiled it with different ver
--- Comment #12 from rguenther at suse dot de 2009-05-11 13:10 ---
Subject: Re: bad optimization(?) pure virtual function
call with -O2
On Mon, 11 May 2009, jwakely dot gcc at gmail dot com wrote:
> --- Comment #11 from jwakely dot gcc at gmail dot com 2009-05-11 13:09
> --
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.3 |4.2.4 4.3.3 4.4.0
Known to work||4.1
/gcc/spec/sb-terbium-head-64/ia64/install-200905081754/bin/gfortran -c -o
daten.o -O3 daten.f
daten.f: In function 'daten':
daten.f:1850: internal compiler error: in get_seqno_by_preds, at
sel-sched-ir.c:3752
Please submit a full bug report,
with preprocessed source if appropriate.
Se
--
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=40101
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-11 14:14 ---
Subject: Bug 40089
Author: janus
Date: Mon May 11 14:14:38 2009
New Revision: 147379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147379
Log:
2009-05-11 Janus Weil
PR fortran/40089
* reso
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-11 14:19 ---
Fixed with r147379. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
The following testcase triggers an ICE on trunk when compiled with "-O2":
bool foo0(int) { return true; }
bool foo1();
void foo2(bool);
template inline void bar1(T f)
{
if (f(0))
foo1();
}
template void bar2(T f)
{
while (foo1())
{
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
--- Comment #7 from bonzini at gnu dot org 2009-05-11 16:06 ---
Subject: Bug 40026
Author: bonzini
Date: Mon May 11 16:05:45 2009
New Revision: 147386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147386
Log:
2009-05-11 Paolo Bonzini
PR tree-optimization/40026
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-11 16:27 ---
This patch:
--- cp/decl.c.foo 2009-05-08 13:54:31.0 -0700
+++ cp/decl.c 2009-05-11 09:26:21.0 -0700
@@ -8065,6 +8065,9 @@ grokdeclarator (const cp_declarator *dec
type = cp_build_qualified
--- Comment #5 from hjl at gcc dot gnu dot org 2009-05-11 16:37 ---
Subject: Bug 40080
Author: hjl
Date: Mon May 11 16:37:07 2009
New Revision: 147389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147389
Log:
2009-05-11 H.J. Lu
PR middle-end/40080
* gcc.c-to
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-11 16:39 ---
Fixed by revision 147320:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00294.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-11 16:40 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from hjl at gcc dot gnu dot org 2009-05-11 16:49 ---
Subject: Bug 40043
Author: hjl
Date: Mon May 11 16:49:17 2009
New Revision: 147390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147390
Log:
2009-05-11 H.J. Lu
Backport from mainline:
2009-0
--- Comment #7 from hjl at gcc dot gnu dot org 2009-05-11 16:49 ---
Subject: Bug 40080
Author: hjl
Date: Mon May 11 16:49:17 2009
New Revision: 147390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147390
Log:
2009-05-11 H.J. Lu
Backport from mainline:
2009-0
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-11 16:56 ---
It is caused by revision 147294:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
Bootstrap is broken again at revision 147380 (147349 worked):
...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-q
upc-4.2.3.6/gcc/upc/upc-cmd.c contains the line:
char *all_exec_args[ARG_MAX];
That is erroneous, because ARG_MAX is not set on a system where it is variable
and exceeds the maximum, as under SUSE 11.1. But the failure is generic to all
POSIX systems.
--
Summary: ARG_MAX errone
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-11 17:12 ---
UPC is not part of the FSF GCC at all, report this issue to the UPC folks.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||ian at gcc dot gnu dot org
Severity|normal
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-05-11 17:16 ---
It compiles for me at -O2 and x86_64-linux. I fixed bug with similar symptoms
last week, does it still reproduce?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40100
--- Comment #2 from nmm1 at cam dot ac dot uk 2009-05-11 17:17 ---
I have now found a SECOND set of instructions on how to report a bug in gcc
upc.
I will copy this to http://www.intrepid.com/upc/bugs.html. Please just cancel
this report if this is the wrong place.
--
http://gcc.gn
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-11 17:22 ---
*** This bug has been marked as a duplicate of 40043 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-11 17:22 ---
*** Bug 40100 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-11 17:23 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
Since gcc-4.3 I'm unable to rebuild gcc, please check the downstream bug:
http://bugs.gentoo.org/show_bug.cgi?id=267247
As pointed out there, it compiles with gcc-4.1.2, but after upgrading to
gcc-4.3, switching to that compiler, and recompiling itself, it segfaults.
sh4-unknown-linux-gnu-gcc -
--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com 2009-05-11
18:04 ---
Good asm code for a hot loop in swim's "calc1" function
10001e10: lfd f12,-10672(r11)
10001e14: lfd f9,-10672(r9)
10001e18: addir21,r21,16
10001e1c: lfd f7,-10680(
The run time of air.f90 of the Polyhedron test suite takes ~15% more time when
compiled with -fwhole-file than without the option. I have checked that the
subroutines DERIV(X|Y) are inlined with -finline-limit=100, but not with
-finline-limit=50 (for the later I recover the timing without -fwhole-
+FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution, -O1
+FAIL: gcc.c-torture/execute/builtins/memmove.c execution, -O1
These testcases used to work in 4.4.0.
--
Summary: [4.5 Regression] gcc.c-
torture/execute/builtins/memmove.c and gcc.c-
--- Comment #10 from jakub at gcc dot gnu dot org 2009-05-11 17:30 ---
Testcase:
subroutine f1 (a)
character(len=1) :: a(7:)
character(len=12) :: b
character(len=1) :: c(2:10)
write (b, a) 'Hell', 'o wo', 'rld!'
if (b .ne. 'Hello world!') call abort
write (b, a(:)) 'Hell', '
Most of the gcc.dg/torture/complex-* tests fail on spu-elf. This is due to
signed zeros are never produced except when doing a negation so the tests most
likely should be disabled for spu-elf.
--
Summary: gcc.dg/torture/complex-* tests fail on spu-elf
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-11 18:10 ---
I forgot to say this fails with:
LAST_UPDATED: Fri May 8 15:49:15 UTC 2009 (revision 147292)
But passed with:
LAST_UPDATED: Wed Feb 11 17:03:51 UTC 2009 (revision 144107)
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from Andrey dot Martchovsky at gmail dot com 2009-05-11
18:22 ---
(In reply to comment #2)
> Why is that a problem? C and C++ are different languages. Compiling with g++
> means you are compiling the C code as C++ (see documentation).
>
My problem is that the error for
The following program:
namespace A{
class B{
};
typedef A::B AB;
}
int main(){
A::AB ab;
return 0;
}
compiled with gcc generates the following debug info:
...
<1><43>: Abbrev Number: 5 (DW_TAG_subprogram)
<44> DW_AT_external: 1
<45> DW_AT_name: (indi
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-11 18:27 ---
For C++98 and C90, integer constants can only fit into the long type. You need
to use LL if you want a 64bit integer constant.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dodji at gcc dot gnu dot org 2009-05-11 18:29 ---
Created an attachment (id=17853)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17853&action=view)
Candidate fix
I have tested this patch. It bootstraps and passes regtest on trunk.
I need to test it on the bran
--- Comment #5 from Andrey dot Martchovsky at gmail dot com 2009-05-11
19:04 ---
(In reply to comment #4)
> For C++98 and C90, integer constants can only fit into the long type. You need
> to use LL if you want a 64bit integer constant.
>
Thank you for clarifying this.
--
http://
--- Comment #6 from hp at gcc dot gnu dot org 2009-05-11 19:40 ---
(In reply to comment #4)
> I meant my fwprop patch. :-)
That's the patch in that revision range, yes... (FWIW, $SRP is the subroutine
return pointer, valid to use as data storage if saved.)
It's a bit unclear whether L1
--- Comment #7 from hp at gcc dot gnu dot org 2009-05-11 20:47 ---
(In reply to comment #5)
> It's a latent bug somewhere, possibly in delayed branch scheduling?
With vs. without -fno-delayed-branch at 147274 seems to justify this blame.
Ugh.
I'll see if I can nail it. But, for the rec
--- Comment #1 from ian at airs dot com 2009-05-11 20:53 ---
I have posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00587.html
The patch is to CLooG.
--
ian at airs dot com changed:
What|Removed |Added
--
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-05-11 20:57
---
The bug disappeared on the trunk between 2009-04-24 and 2009-05-04.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-11 21:07 ---
We shouldn't close a bug without a testcase. Otherwise, it may
come back again.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #8 from hp at gcc dot gnu dot org 2009-05-11 21:14 ---
I see at least one invalid dbr transformation. Assuming you can read m68k
assembler, I'm sure you'll have no problem gripping the important parts of:
subq 25,$r13
test.b [$r13+$r9.b]
- beq .L6
-
--- Comment #9 from hp at gcc dot gnu dot org 2009-05-11 21:19 ---
(In reply to comment #8)
> dbr moves an increment of $r9 *over a use*
Actually, "copies", not "moves", which is even worse (sort of; like "how could
it be worse"). I'll take it.
--
hp at gcc dot gnu dot org changed:
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-11 22:56 ---
Now tracked as official Interpretation Request.
Request: http://www.j3-fortran.org/doc/year/09/09-236.txt (answer = proposed
answer by me).
Submitted for: J3 MEETING 189 LAS VEGAS, NEVADA, August 10 - 14, 2009
http:
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-12 00:00 ---
It is fixed by revision 146776:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01418.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38632
--- Comment #5 from hjl at gcc dot gnu dot org 2009-05-12 00:09 ---
Subject: Bug 38632
Author: hjl
Date: Tue May 12 00:09:17 2009
New Revision: 147401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147401
Log:
2009-05-11 H.J. Lu
PR tree-optimization/38632
* g
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-12 00:10 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-05-12 00:43 ---
Your compilers are the gentoo special versions, aren't they?
If so, you should try the original FSF compiler sources for both
build/target compilers. See http://gcc.gnu.org/bugs.html#dontwant.
FSF 4.3/4.4 release co
--- Comment #2 from ian at gcc dot gnu dot org 2009-05-12 01:26 ---
Subject: Bug 40103
Author: ian
Date: Tue May 12 01:26:45 2009
New Revision: 147407
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147407
Log:
PR bootstrap/40103
* graphite.c: Force -Wc++-compat t
--- Comment #3 from ian at airs dot com 2009-05-12 01:30 ---
The bootstrap problem has been fixed by adding a #pragma. When and if the
CLooG header files are made -Wc++-compat compatible, that #pragma should be
removed.
--
ian at airs dot com changed:
What|Removed
--- Comment #4 from ian at airs dot com 2009-05-12 01:31 ---
Suspending until CLooG is fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSIG
--- Comment #7 from aoliva at gcc dot gnu dot org 2009-05-12 05:49 ---
Subject: Bug 37137
Author: aoliva
Date: Tue May 12 05:49:28 2009
New Revision: 147415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147415
Log:
ChangeLog:
PR target/37137
* Makefile.def (flags_to_pass): Remo
--- Comment #10 from bonzini at gnu dot org 2009-05-12 05:58 ---
Thanks H-P.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #9 from pault at gcc dot gnu dot org 2009-05-12 06:07 ---
Since I am working on it, I had better take it :-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
The following program is formally valid though the use of of C_CHAR as INTEGER
kind is doubtful and will not work on all systems. (C_CHAR is for CHARACTERS;
there is C_SIGNED_CHAR for INTEGERS, which may or may not have the same kind
number; in gfortran is has.)
However, it is simply a PARAMETER (
80 matches
Mail list logo
