--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-09 16:36 ---
cross-ref:
http://sourceware.org/bugzilla/show_bug.cgi?id=5780
http://sourceware.org/bugzilla/show_bug.cgi?id=5784
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-09 16:39 ---
Patch has been committed to 4.4, 4.5, and trunk.
Closing.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 16:56 ---
It is caused by revision 142799:
http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00498.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-09 17:05
---
Thanks HJ.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
--- Comment #29 from dodji at gcc dot gnu dot org 2010-06-09 17:09 ---
Created an attachment (id=20878)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view)
Refreshed version. Fully Bootstraps the C FE and passes regression tests.
This fixes a annoying bug that were ma
--- Comment #11 from mrs at gcc dot gnu dot org 2010-06-09 17:21 ---
Fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-09 17:24 ---
Can be reproduced also with
c++filt
_ZN5boost6tuples5tupleIN23abcdefgxyzzzabb3AaaENS2_4klmn16BaaaENS0_9null_typeES6_S6_S6_S6_S6_S6_S6_EE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-09 17:39
---
Exact same errors building gc (not gcc) using gcc 4.3.5 on OSF/1 5.1.
I haven't tried building java/libjava. Will probably do that.
Please reopen.
make[2]: Entering directory `/home/jayk/obj/gc'
gcc -DPACKAGE_NA
ins --prefix=/afs/mpa/data/martin/ugcc
--with-ppl=/afs/mpa/data/martin/numlibs64
--with-cloog=/afs/mpa/data/martin/numlibs64
--with-libelf=/afs/mpa/data/martin/numlibs64 --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 4.6.0 20100609 (experimen
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-09 17:42
---
Created an attachment (id=20879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20879&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
--- Comment #7 from hp at gcc dot gnu dot org 2010-06-09 17:53 ---
(In reply to comment #5)
> The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
> It definitly avoids the ICE, but it would be nice to know if libstdc++
> testsuite passes.
When applied to r160481, it so
--- Comment #30 from manu at gcc dot gnu dot org 2010-06-09 17:57 ---
(In reply to comment #29)
> Created an attachment (id=20878)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view) [edit]
> Refreshed version. Fully Bootstraps the C FE and passes regression tests.
>
--- Comment #12 from jakub at gcc dot gnu dot org 2010-06-09 18:09 ---
I see the bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-09 18:38 ---
Subject: Bug 44430
Author: janus
Date: Wed Jun 9 18:38:11 2010
New Revision: 160504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160504
Log:
2010-06-09 Janus Weil
PR fortran/44430
* dump
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-09 18:39 ---
> > The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
> > It definitly avoids the ICE, but it would be nice to know if libstdc++
> > testsuite passes.
>
> It does fix the bootstrap failure. I am cu
--- Comment #2 from falk at debian dot org 2010-06-09 19:11 ---
Confirmed, seems to be in if-conv. Here's a smaller test case:
int ffesum (void) {
int ch[4], ii, jj, kk;
char asc[32];
for (ii = 0; ii < 4; ii++)
{
for (jj = 0; jj < 4; jj++)
ch[jj] = ii;
for
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-09
19:19 ---
Subject: Re: bunch of warnings of "second definition" on osf
I've regularly seen those warnings, but ignored them since I've found no
ill effect and the testsuite largely passes (which doesn't use the
stat
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-06-09 19:24
---
As I read this, the test case is invalid since it does not have a rewind or
backspace before the write?
If we want to change this to be an intended extension, I suppose we should
issue a warning or error for -std
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:41 ---
Subject: Bug 44359
Author: dfranke
Date: Wed Jun 9 19:40:58 2010
New Revision: 160505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160505
Log:
gcc/fortran/:
2010-06-09 Daniel Franke
PR fortran
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 19:41 ---
(In reply to comment #1)
> As I read this, the test case is invalid since it does not have a rewind or
> backspace before the write?
Yes - I expect that gfortran should issue an EOR error instead of happily
accepting
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-09 19:42 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:45 ---
I believe this is a dupe of PR33341.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-09 20:11 ---
Confirmed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #5 from joseph at codesourcery dot com 2010-06-09 20:14 ---
Subject: Re: iterators already defined for std::vector when
using std::decimal
On Wed, 9 Jun 2010, paolo dot carlini at oracle dot com wrote:
> Janis, this doesn't make sense to me, and for sure happens only with
--- Comment #9 from bernds at gcc dot gnu dot org 2010-06-09 20:20 ---
Created an attachment (id=20880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20880&action=view)
A new version of Jim's patch
Here's what I've done with it so far. I've changed the new tree code to be a
prope
--- Comment #1 from eric dot weddington at atmel dot com 2010-06-09 20:21
---
This is not a bug.
Please see the avr-libc documentation for here:
http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
which gives the method to disable the watchdog.
--
eric dot weddingt
Between gcc-4.6-20100529 and gcc-4.6-20100605 a number of new testsuite FAILs
appeared on sparc64-linux:
=== gfortran tests ===
FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL: gfortran.fortran-tortur
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 20:30 ---
(In reply to comment #6)
> Following patch is also needed to fix conditional splitting (it does not fix
> original uncovered problem where BLOCK_FOR_INSN returns null):
>
>
I am not sure this is correct. The code p
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.6.0
http://gcc
--- Comment #2 from joaquin at tid dot es 2010-06-09 20:34 ---
Caching can also have undesired consequences: for additional context on the
problem, see
https://svn.boost.org/trac/boost/ticket/4264
Note that *two* problems are discussed there, one is LWG issue #579 and the
other the one
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
*** Bug 2 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
-
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
(In reply to comment #2)
> This is a known limitation of array constructors handling by gfortran.
I was about to ask if this pr is a duplicate. From comment #3, it is; so I am
closing it as such.
For the record the o
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r160490-install
--program-prefix=r160490- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100609 (experimental) (GCC)
[reg...@gamow tmp414]$ current-gcc -c -O small.c
small.c: In function 'fu
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 21:17 ---
Here's a quick shot at fixing the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160503)
+++ gcc/fortran/resolve.c
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-09 21:19 ---
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Index: interface.c
==
The "S::f()" text reads as though S were a template. I suspect the
text is simply missing a space between the S and but I wonder if
the bit could actually be replaced by something less ambiguous
in C++ (such as /* unnamed */ or perhaps better still, /* anonymous */).
Btw., since glibc uses __PRE
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-06-09 21:36 ---
Subject: Bug 44347
Author: dfranke
Date: Wed Jun 9 21:36:33 2010
New Revision: 160506
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160506
Log:
gcc/fortran/:
2010-06-09 Daniel Franke
PR fortran
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-09 21:40 ---
It is caused by revision 160124:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 21:48
---
Oops, thanks Joseph.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-06-09 21:50
---
Subject: Bug 42461
Author: ebotcazou
Date: Wed Jun 9 21:49:44 2010
New Revision: 160507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160507
Log:
PR rtl-optimization/42461
* dce.c (delet
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-09 22:02 ---
I'm VERY much in favour of using something that is not valid C++ syntax, rather
than ""
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 22:06 ---
It is caused by revision 159886:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:10
---
Another one that fails:
subroutine func (x)
use demo
integer :: x
x = 999
end subroutine func
subroutine foo
interface
subroutine func(x)
integer :: x
end subroutine func
end interface
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:11
---
(In reply to comment #16)
> Re-confirmed with current trunk, testcase from (comment #8).
I think it now passes.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from spop at gcc dot gnu dot org 2010-06-09 22:13 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 00:26
---
As far as we can see can't be substantively improved. See also the thread
starting at: http://gcc.gnu.org/ml/libstdc++/2010-06/msg00073.html
--
paolo dot carlini at oracle dot com changed:
What
This program doesn't compile with g++-4.5 -std=c++0x -c test.cpp
I'm using:
g++-4.5 (Debian 4.5.0-5) 4.5.1 20100602 (prerelease)
I also verified the same behavior on:
g++ (Debian 20100530-1) 4.6.0 20100530 (experimental) [trunk revision 160047]
#include
int x, y;
std::pair foo() {
std::pa
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 00:43 ---
I think this is because C++0x introduces rvalue references and those cannot
bind to lvalues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 00:48 ---
What I mean is that the C++ front-end is correct to reject the code that
libstdc++ provides to it. If there is a bug it is a problem with libstdc++ (or
maybe even the in flux C++0x STL :) ).
--
http://gcc.gnu.o
succeed:
Executing on host: /user/inria/fsf/bld-20100609/gcc/xgcc
-B/user/inria/fsf/bld-20100609/gcc/
/user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m -fnext-runtime
-B/user/inria/fsf/bld-20100609/i686-pc-linux-gnu/./libobjc/.libs
-L/user/inria/fsf/bld-20100609/i686-pc-linux-gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 01:04 ---
-fnext-runtime should fail on x86-linux-gnu anyways. Why it is not failing is
a good question. If this is failing without --enable-build-with-cxx there is
a bug somewhere.
--
pinskia at gcc dot gnu dot org cha
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 01:06 ---
On x86_64-linux-gnu it does the correct thing:
Executing on host: /home/pinskia/src/local/gcc/objdir/gcc/xgcc
-B/home/pinskia/src/local/gcc/objdir/gcc/
/home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/trivial.m
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-10 01:07
---
The constructor at issue is trivially conforming to the most recent specs
(n3092) (*), thus, in my opinion, either this is a compiler issue, or a defect
in c++0x or a feature in c++0x itself, can't be a library
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
This one was posted at gfortran.org
program f90_test
implicit none
integer :: ii8,ii4
ii4=0
ii8=522405223
print'(z4)',ii4
print'(z12)',ii8
print *, "z=", z'1000'
print *, transfer(ii8,z'1000')
print *, transfer(ii8,z'1000')
ii4=30292 !=z'7654'
print'(z4)',ii4
--- Comment #2 from bangerth at gmail dot com 2010-06-10 03:27 ---
This is a regression:
2.95: struct S {anonymous}::f()
3.4: S ::f()
4.0: S::f()
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-10 03:28 ---
Created an attachment (id=20881)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20881&action=view)
patch
This patch fixes it for me. I'm not entirely sure this is a proper use of
forward, but it seems appropriat
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 04:24 ---
This is probably a bogus PR.
The BOZ literal constants are INTEGER(16) entities
(at least of x86_64). ii8 is an INTEGER(4) item.
The transfer() in the print statement is returning
a INTEGER(16) entity where only INTEG
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-06-10 04:37
---
Interesting!
print *, "kind=", kind(transfer(ii4,z'1000'))
On my system this gives kind = 8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
Since x86 zero extends when passing argument,
we get memory mismatch stall:
[...@gnu-6 899]$ cat call-1.c
short
__attribute__((noinline))
foo (short x, short y, short z)
{
return x + y + z;
}
short
bar (short z, short x, short y)
{
return foo (x, y, z);
}
[...@gnu-6 899]$ gcc -O2 -m32 call-1
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-06-10 05:21
---
The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
depending on the system. Maybe we should add some documentation in the manual
on this. Thanks Steve for pointing this out.
--
jvdel
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 05:23 ---
This patch
---
iff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index a33d3af..6f569cc 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -820,7 +820,10 @@
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-10 05:41 ---
I see the same problem now with revision 160389.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
--- Comment #10 from ubizjak at gmail dot com 2010-06-10 06:18 ---
(In reply to comment #9)
> > Following patch is also needed to fix conditional splitting (it does not fix
> > original uncovered problem where BLOCK_FOR_INSN returns null):
>
> I am not sure this is correct. The code pr
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 ---
(In reply to comment #3)
> The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
> depending on the system. Maybe we should add some documentation in the manual
> on this. Thanks Steve for point
101 - 166 of 166 matches
Mail list logo
