--- 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
--- 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 #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 #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 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
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 #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
--- 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 #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 #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
--
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
--
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
--- 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
--- 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 #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
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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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
---
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- 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
--- 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 #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 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
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 #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
==
--- 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
--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 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
--- 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 #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
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.6.0
http://gcc
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
note this is later bootstrap stages so shouldn't matter what the bootstrap
compiler was (assuming it compiled the compiler reasonably correctly)
For the missing prototypes, I suggest you just put them right there:
void Foo(void);
void Foo(void)
{
...
}
for the uninitialized I suggest just ini
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:52
---
In general, only if it's a regression. And nobody said that explicitly so far.
If you want to argue for having it anyway in 4_5-branch, please speak on the
mailing list and ask permission to the release manager
--- Comment #7 from raj dot khem at gmail dot com 2010-06-09 15:48 ---
thanks Paolo, we would need this patch on 4.5 branch as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 15:46
---
I see. Looks like Matt essentially followed in the reference implementation the
legacy HP / SGI, linear, way of computing begin(). I'm asking his opinion on
this, whether we are also going to use caching or so
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 15:36
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #5 from paolo at gcc dot gnu dot org 2010-06-09 15:35 ---
Subject: Bug 44461
Author: paolo
Date: Wed Jun 9 15:34:45 2010
New Revision: 160488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160488
Log:
2010-06-09 Khem Raj
PR libstdc++/44461
* libs
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
CC|mikestump at comcast dot net|
Target Milestone|--- |4.6.0
http://gcc.gnu.o
--- Comment #6 from ian at rhymneyconsulting dot co dot uk 2010-06-09
15:20 ---
Subject: RE: [OOP] ICE with polymorphic object oriented example
Thanks very much for fixing it.
Cheers
Ian
> -Original Message-
> From: burnus at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:13
---
I gave this more thought, and to be honest, focusing on 64-bit targets - I
think that for 32-bit targets what we have is already good enough - I have no
idea how to substantively improve the code, given that th
--- Comment #9 from jason at gcc dot gnu dot org 2010-06-09 15:12 ---
Subject: Bug 44366
Author: jason
Date: Wed Jun 9 15:11:42 2010
New Revision: 160483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160483
Log:
PR c++/44366
* g++.dg/cpp0x/decltype23.C: Move to
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-09 15:07 ---
With the patch for PR 44211 (just committed to the 4.6 trunk), the program
compiles and the output is:
shape
In generic_shape_assign
x = 10
y = 20
circle
In generic_shape_assign
x =
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 14:43
---
OK, I have found the bug and I admit it is rather embarrassing. I'll
submit a patch soon.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from dodji at gcc dot gnu dot org 2010-06-09 14:32 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
"manu at gcc dot gnu dot org" writes:
>>
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expandi
"manu at gcc dot gnu dot org" writes:
>>
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'dou
--- Comment #27 from dodji at gcc dot gnu dot org 2010-06-09 14:23 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
"manu at gcc dot gnu dot org" writes:
> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/
"manu at gcc dot gnu dot org" writes:
> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.
I guess you are talking about the "automatic macro expansion" section of
that link?
>
> In fact, clang's output actually follows more closely what
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add->lea optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-09 14:16 ---
Fixed with r160478. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from bergner at gcc dot gnu dot org 2010-06-09 14:15
---
Subject: Bug 44067
Author: bergner
Date: Wed Jun 9 14:15:11 2010
New Revision: 160479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160479
Log:
Backport from mainline:
2010-06-09 Edmar
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 14:15 ---
Subject: Bug 44211
Author: janus
Date: Wed Jun 9 14:14:08 2010
New Revision: 160478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160478
Log:
2010-06-09 Janus Weil
PR fortran/44211
* reso
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
> (In reply to comment #1)
> > It may be broken by revision 160394:
> >
> > http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
>
> The add->lea transformation doesn't even trigger in this
--- Comment #43 from mark dot workman at acm dot org 2010-06-09 14:07
---
(In reply to comment #39)
> Hi, Kyle Moffett,
> in testall.c, r9 is used by a register variable, however, in E500ABI
> guide,
> r9 should be used for parameter passing, this test case seems not reasonable.
>
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-09 14:02 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 14:02:03 2010
New Revision: 160476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160476
Log:
2010-06-09 Paolo Carlini
Revert:
2010-06-
When compiling the following program with -O2, gcc gives an ICE "internal
compiler error: in trunc_int_for_mode, at explow.c:56".
Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)
static inline unsi
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-09 13:55 ---
There are more issues:
1) cleanup_barriers seems to do weird things with these empty bbs from
__builtin_unreachable (), I guess it shouldn't reorder anything if prev is a
LABEL_P
2) the reason why this compiles fine on
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55
---
Ok seems it does not do what I want:
FIXME lto. Currently the scheme is limited in that only the
options saved on the first object file (f1.o) are read back during
the link step. This means that the opt
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 ---
(In reply to comment #41)
> The ICE in #38 is due to a bug in caller-save.c
Thank you for the very quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 13:50 ---
> 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 currently r
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-09 13:43 ---
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.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42
---
I found this code in lto.c which seems to disagree:
/* Read the options saved from each file in the command line. Called
from lang_hooks.post_options which is called by process_options
right before all the
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-09 13:39 ---
The following patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
should fix the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
The current implementation of begin() for unordered associative containers is
linear (a search for the first non-empty bucket is executed each time begin()
is called), yet the C++0x drafts specifiy that this should be constant (23.3.1,
table 93). Boost.Unordered, for instance, caches the first non-
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35
---
What happens then when some files need different options that other files?
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles
--
http://gcc.gnu.org/bugz
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 ---
Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view)
e500.h and caller-save.c patch
The ICE in #38 is due to a bug in caller-save.c
--
http://gcc.gnu.org/bugzilla/sh
1 - 100 of 166 matches
Mail list logo
