--- Comment #1 from ubizjak at gmail dot com 2009-08-13 06:32 ---
No testcase, please see http://gcc.gnu.org/bugs.html on how to submit proper
bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--- Comment #3 from abel at gcc dot gnu dot org 2009-08-13 06:28 ---
Subject: Bug 41033
Author: abel
Date: Thu Aug 13 06:28:28 2009
New Revision: 150713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150713
Log:
2009-08-12 Andrey Belevantsev
PR rtl-optimization/41033
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-08-13 06:08 ---
(In reply to comment #1)
> Even the target-specific i686-mingw32/bin directory contains host
> applications,
> i.e. the non-$target-prefixed versions of the binutils.
>
> So since these DLLs are never going to be us
--- Comment #8 from irar at il dot ibm dot com 2009-08-13 05:40 ---
(In reply to comment #7)
> Oh. Did you manage to reduce or reproduce with a smaller testcase?
No, I just looked at the vectorized loops. The guilty one is
bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../incl
--- Comment #1 from cthiel at cse dot unl dot edu 2009-08-13 05:37 ---
Created an attachment (id=18349)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18349&action=view)
Testcase
Attaching two files since this bug depends on the -combine flag and multiple
input files.
--
http:
gfortran -c -fdefault-real-8 -O2 -fcray-pointer ./util_p.f -o ./util_p.o
./util_p.f: In function dot_ga:
./util_p.f:204: internal compiler error: in emit_swap_insn, at reg-stack.c:827
make: *** [util_p.o] Error 1
--
Summary: internal compiler error: in emit_swap_insn, at reg-
64-unknown-linux-gnu
Configured with: /home/cthiel/src/gcc/configure --program-suffix=-trunk
--enable-languages=c,c++,fortran --prefix=/opt/gcc-trunk
Thread model: posix
gcc version 4.5.0 20090812 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-
--- Comment #12 from hp at gcc dot gnu dot org 2009-08-13 05:30 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from jack dot q dot word at gmail dot com 2009-08-13 05:14
---
(From update of attachment 18348)
template< class cT, class... vT >
struct VarTypeNav
{
typedef cT T;
typedef VarTypeNav< vT..., void > Next;
struct scT { cT v; };
static const
--- Comment #10 from jack dot q dot word at gmail dot com 2009-08-13 05:05
---
> 'byte Data[VarTypeNav< cT, vT...>::Size];' ...
or 'char Data[VarTypeNav< cT, vT...>::Size];' ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722
--- Comment #9 from jack dot q dot word at gmail dot com 2009-08-13 05:04
---
(In reply to comment #8)
> Created an attachment (id=18348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18348&action=view) [edit]
> tuple & union examples with possibly proper variadic return type case
--- Comment #8 from jack dot q dot word at gmail dot com 2009-08-13 05:01
---
Created an attachment (id=18348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18348&action=view)
tuple & union examples with possibly proper variadic return type case relying
on variadic template expans
--- Comment #3 from wallaces3 at yahoo dot com 2009-08-13 04:02 ---
I totally agree with David Faure, please make this warning controllable:
-Werror=invalid-offsetof
All other warnings have a type that can be ignored, but when using the
-fdiagnostics-show-option option to see what the w
exception ()
(gdb) bt
#0 0x00014164a15d in __gmp_exception ()
#1 0x00014164a17e in __gmp_divide_by_zero ()
#2 0x00014166121f in __gmpz_tdiv_q ()
#3 0x000100518f46 in pbb_number_of_iterations (pbb=0x14275e670,
loop_depth=0, niter=0x7fff5fbfd3d0) at
../../gcc-4.5-20090812/gc
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-08-13
03:05 ---
Interestingly, -O2/-O3 -fgraphite-identity also miscompiles air.f90, however
-O1 -fgraphite-identity results in the ICE...
air.f90: In function state:
air.f90:1034:0: internal compiler error: in scan_tr
NaN
when executed. This is seen with r150709 with the compiler specs of...
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090812/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--- Comment #2 from igodard at pacbell dot net 2009-08-13 02:47 ---
Well, if the call is on foo then surely a foo can call; its own methods,
whereas if the call is on bar then a bar should see the protected methods of
its base class foo. Either way it should be visible.
--
http://gc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-13 02:42 ---
I think this is correct as you are not calling a protected method on this but a
new object that is created from this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41050
--- Comment #9 from spop at gcc dot gnu dot org 2009-08-13 02:37 ---
Subject: Re: aermod.f90 ICEs on -O2 -fgraphite-identity
-floop-strip-mine
Could you please try the attached patch?
Thanks,
Sebastian
--- Comment #10 from spop at gcc dot gnu dot org 2009-08-13 02:37 -
This code:
#include
class foo {
protected:
foo() {}
foo(int) {}
public:
};
class bar : public foo {
public:
bar() : foo() {
new (this) foo(5);
}
};
bar b;
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In construct
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-13
02:25 ---
Interestingly, this benchmark is also the one that shows the best improvement
from -floop-interchange...
Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
Benchmarks : indu
t
#0 0x00014164a15d in __gmp_exception ()
#1 0x00014164a17e in __gmp_divide_by_zero ()
#2 0x00014166121f in __gmpz_tdiv_q ()
#3 0x000100518f46 in pbb_number_of_iterations (pbb=0x14275e670,
loop_depth=0, niter=0x7fff5fbfd3d0) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:734
#
3 0x000100518f46 in pbb_number_of_iterations (pbb=0x1575618c0,
loop_depth=0, niter=0x7fff5fbfd3c0) at
../../gcc-4.5-20090812/gcc/graphite-poly.c:734
#4 0x0001005122ab in scop_do_strip_mine (scop=) at
../../gcc-4.5-20090812/gcc/graphite-blocking.c:169
#5 0x000100517f08 in apply_poly_transforms (scop=0x157
--- Comment #6 from spop at gcc dot gnu dot org 2009-08-13 01:36 ---
Could you please run gdb on f951 and then report a backtrace of where it fails?
Thanks,
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40981
--- Comment #4 from joseph at codesourcery dot com 2009-08-13 01:25 ---
Subject: Re: complex folding inexact
On Wed, 12 Aug 2009, ghazi at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 from ghazi at gcc dot gnu dot org 2009-08-12 22:28 ---
> (In reply to comment #2)
>
>
--- Comment #4 from petteri dot kettunen at nokia dot com 2009-08-13 01:15
---
This is a bit odd but the bug was not reproducible when I tried to compile a
minimal example in a file containing that function only. I shall investigate a
bit more.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-08-13
01:15 ---
These ICEs also occur with...
-O1 -fgraphite-identity -floop-strip-mine
but not...
-O0 -fgraphite-identity -floop-strip-mine
--
howarth at nitro dot med dot uc dot edu changed:
What|R
exception
In case it helps reproduce the problem on x86_64 linux, on
x86_64-apple-darwin10...
touch t.f90
gfortran -fverbose-asm t.f90 -S
more t.s
# GNU Fortran (GCC) version 4.5.0 20090812 (experimental)
(x86_64-apple-darwin10)
# compiled by GNU C version 4.5.0 20090812 (experimental), GMP version
--- Comment #3 from spop at gcc dot gnu dot org 2009-08-13 00:14 ---
On amd64-linux at r150694, I have all the polyhedron bmks compiling fine.
I double checked for aermod.f90 with exactly the same options where you see the
error:
gfortran -O2 -fgraphite-identity -floop-strip-mine aermod.
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-12
23:40 ---
What revision fixed this on trunk? I am still seeing the ICE with r150709 on
x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40981
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-12 22:57 ---
Even the target-specific i686-mingw32/bin directory contains host applications,
i.e. the non-$target-prefixed versions of the binutils.
So since these DLLs are never going to be used on the host, we could put them
in
--- Comment #6 from kkojima at gcc dot gnu dot org 2009-08-12 22:29 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-08-12 22:28 ---
(In reply to comment #2)
Joseph - Thanks for your reply and testvalues.
> There are also cases for exact rounding where you'd expect MPC to produce
> the right results but would *not* expect operations executed at r
--- Comment #5 from kkojima at gcc dot gnu dot org 2009-08-12 22:26 ---
Subject: Bug 41029
Author: kkojima
Date: Wed Aug 12 22:26:13 2009
New Revision: 150709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150709
Log:
PR target/41029
* config/sh/sh.md (reload_out
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #3 from brian dot e dot bliss at intel dot com 2009-08-12
21:29 ---
It doesn't look like the problem is confined to Intel64 code. Here's the IPF
assembly for the GOMP_loop_dynamic_start call:
addp4 r15 = r14, r0
adds r14 = -24, r37
mov r39 = r16
;;
mov r40 = r15
addp4 r41
--- Comment #6 from nemet at gcc dot gnu dot org 2009-08-12 21:27 ---
It fixes the testcase on mips64octeon-linux. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41047
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-12 21:20 ---
Created an attachment (id=18346)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18346&action=view)
good patch
better patch, the old one missed the tree-ssa.c hunk and the testcase was
broken.
--
rguenth at
IEEE 754 says that the preferred exponent of the result of a conversion from an
integer to a decimal float value is zero. In all active branches of GCC a
compile-time conversion discards trailing zeros and then adds one back, and a
runtime conversion for the densely-packed decimal format adds an e
--- Comment #9 from tobi at gcc dot gnu dot org 2009-08-12 20:52 ---
Side remark:
DO i = 1,10
call bar(i)
END DO
wouldn't be valid if bar changed its argument, i.e. the compiler should
generate the same, better code it does for the case where you copy the argument
(bar((i))).
I
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-08-12 20:36 ---
(In reply to comment #7)
> An interesting approach. As long as you don't print array slices in the
> loops this should work around the escaping pointer problem. It comes at
> the risk of creating excessive copie
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|gcc.target/mips/memcpy-1.c |[
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-12 20:10 ---
Created an attachment (id=18345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18345&action=view)
patch
Fix I am testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41047
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-12 19:25 ---
I think this only happens for HWI == 32bits. It works for me with a compiler
for ppc64-linux-gnu but fails with i686-linux-gnu. (Oh it works for
i386-darwin too which has HWI as being 64bits).
One more reason to c
--- Comment #9 from reuter at physik dot uni-freiburg dot de 2009-08-12
19:21 ---
Sorry, false alarm. Had a truncated test file.
--
reuter at physik dot uni-freiburg dot de changed:
What|Removed |Added
-
This example came from the gdb list:
#include "stdio.h"
class Blah
{
public:
Blah(): mFlag(0) {}
void setFlag( int value ) {
mFlag = value;
}
void printFlag() {
printf( "Flag value is %d\n", mFlag );
}
private:
int mHu
--- Comment #9 from cppljevans at suddenlink dot net 2009-08-12 19:15
---
As indicated here:
http://article.gmane.org/gmane.comp.gcc.bugs/254672
the problem occurs because an additional test is needed
in cp_tree_equal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
--- Comment #8 from reuter at physik dot uni-freiburg dot de 2009-08-12
19:09 ---
The fix seems not to work with the test program.
On Linux 32 bit I get the following when compiling:
/tmp/cciQlmr1.o: In function `MAIN__':
foo.f90:(.text+0x1b): undefined reference to `proc_'
collect2: l
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-12 18:54 ---
We used to get
memcpy (&c, &"12345678"[2], 6); [tail call]
memcpy (&c, "123456", 6); [tail call]
for expansion, but now we get
D.2386_1 = (const void * restrict) "123456";
c.1_2 = (void * restrict) &c;
m
--- Comment #2 from crowl at google dot com 2009-08-12 18:42 ---
It looks like the compiler is not properly handling injected class names. The
original example was not the best use of the injected class name, but should be
accepted. Jonathan's example is better code, and still shows th
--- Comment #14 from sezeroz at gmail dot com 2009-08-12 18:20 ---
anything new on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #7 from =?ISO-8859-1?Q?Tobias_Schl=FCter?=
2009-08-12 18:11
---
Subject: Re: Invariant DO loop variables and subroutines
tkoenig at gcc dot gnu dot org wrote:
> --- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-12 17:53
> ---
> We get a dramatic speedu
--- Comment #2 from anemet at caviumnetworks dot com 2009-08-12 18:08
---
Subject: gcc.target/mips/memcpy-1.c failing
rguenth at gcc dot gnu dot org writes:
> Is that a recent regression?
Last 12 days. Guerby has results from 7/30 that don't show this.
Adam
--
http://gcc.gnu.o
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-12 17:56 ---
Subject: Bug 41011
Author: rguenth
Date: Wed Aug 12 17:55:40 2009
New Revision: 150705
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150705
Log:
2009-08-12 Richard Guenther
PR tree-optimization/
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-12 17:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-12 17:54 ---
Is that a recent regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41047
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-12 17:53 ---
We get a dramatic speedup when enclosing the arguments to
print in parentheses:
This is something we can do for
- write and print statements
- intent(in) arguments
- any do variable passed as an argument within the
See http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01279.html
Seems like we losing alignment on string literals again (PR/27226). The
testcase is from dhrystone.
--
Summary: gcc.target/mips/memcpy-1.c failing
Product: gcc
Version: 4.4.0
Status: UN
--- Comment #1 from dje at gcc dot gnu dot org 2009-08-12 17:35 ---
This started failing after I started compiling with MPC library. Is this an
MPC bug or interaction bug?
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
The decNumber package has debugging code with calls to printf. Most of those
calls are protected by DECCHECK or DECTRACE, but a couple of them are not. The
printf calls should not be in the normal build of libgcc.
I'm about to submit a fix but want a PR to keep track of this issue.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-12 16:56 ---
For you example why can you do something like:
static void *bazsection1[] __attribute__((section("baz"), used)) = {
(void*)foo, (void*)(sizeof(foo)), (void*)(bar) };
This seems like a better option than using inline
IÂd like to be able to write toplevel inline assembly with C operands that are
compile-time constants, e.g.
static const char foo[] = "Hello, world!";
enum { bar = 17 };
asm(".pushsection baz; .long %c0, %c1, %c2; .popsection"
: : "i" (foo), "i" (sizeof(foo)), "i" (bar));
However, this curre
--- Comment #24 from bonzini at gnu dot org 2009-08-12 16:29 ---
patch committed as r150700
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #11 from bonzini at gnu dot org 2009-08-12 16:28 ---
Subject: Bug 41031
Author: bonzini
Date: Wed Aug 12 16:28:36 2009
New Revision: 150701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150701
Log:
2009-08-12 Richard Sandiford
PR tree-optimization/41031
--- Comment #9 from spop at gcc dot gnu dot org 2009-08-12 15:14 ---
Subject: Bug 40103
Author: spop
Date: Wed Aug 12 15:13:52 2009
New Revision: 150696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150696
Log:
Remove pragma GCC diagnostic warning "-Wc++-compat".
2009-08-12 S
--- Comment #7 from spop at gcc dot gnu dot org 2009-08-12 15:03 ---
This still fails on rev150694. The problem is in the data dependence analyzer:
Graphite loop transforms: 0.34 ( 0%) usr 0.00 ( 0%) sys 0.29 (0%) wall
2105 kB ( 7%) ggc
Graphite data dep analysis: 107.68 (95%)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-12 15:01 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-12 14:58 ---
Still fails on my machine, on rev150694.
~/gcc/svn/trunk/usr/bin/gfortran -ffast-math -funroll-loops -msse3 -O3
induct.f90 -o induct
time ./induct
real0m16.596s
user0m16.393s
sys 0m0.076s
~/gcc/svn/trunk/u
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-12 14:46 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-12 14:42 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from spop at gcc dot gnu dot org 2009-08-12 14:41 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from spop at gcc dot gnu dot org 2009-08-12 14:33 ---
Subject: Bug 40980
Author: spop
Date: Wed Aug 12 14:32:31 2009
New Revision: 150694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150694
Log:
Prepare expressions to be good phi arguments.
2009-08-11 Sebastia
--- Comment #1 from joel at gcc dot gnu dot org 2009-08-12 14:25 ---
4.3.4 definitely builds.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
Known to wo
--- Comment #39 from rmansfield at qnx dot com 2009-08-12 14:22 ---
I came across a original-tree-changed-by-fold ICE building libsupc++ for a
arm-unknown-linux-gnu target with --enable-checking=fold.
gcc version 4.5.0 20090812 (experimental) [trunk revision 150681] (GCC
On 05/10/09 11:20, cppljevans at suddenlink dot net wrote:
When compile trysto expand:
: seq
< integral_c
< Integral
, Vals
>...
the error diagnostic prints integral_c instead of
integral_c. The integral_constant template
is derived from integral_c and does have T and val arg
--- Comment #10 from hp at gcc dot gnu dot org 2009-08-12 14:11 ---
(In reply to comment #9)
> (In reply to comment #8)
> > The patch is already approved, so I'm going to commit it on behalf of
> > rsandifo.
>
> Oops, I see it's not completely tested yet.
> Ok, I'm doing a test-run on
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-12 13:36 ---
We take a lot of time and memory in
/* Convert (T1)(X * Y) into (T1)X * (T1)Y if T1 is narrower than the
type of X and Y (integer types only). */
if (INTEGRAL_TYPE_P (type)
&& TREE_CO
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-12 13:14 ---
Confirmed. We are doing a very hard job folding a tree generating lots of
garbage during VRP in adjust_range_with_scev (my personal friend).
:
D.1534_2 = (integer(kind=8)) i_1(D);
D.1535_3 = D.1534_2 * D.1534_2;
D.
--- Comment #7 from rguenther at suse dot de 2009-08-12 12:37 ---
Subject: Re: Variate_generator with mt19937
and normal_distribution produces wrong sequence for "-O3".
On Wed, 12 Aug 2009, irar at il dot ibm dot com wrote:
> --- Comment #6 from irar at il dot ibm dot com 2009-0
On *-apple-darwin9 with gfortran 4.5.0 or 4.4.1, the following code gives at
-O2:
! { dg-do compile }
subroutine foo
implicit none
integer :: i
call gee_i(int(i**huge(0_8),kind=kind(i)))
! call gee_i(int(i**(-huge(0_8)-1_8),kind=kind(i)))
end subroutine foo
gives at -O2:
[ibook-dhum] f
--- Comment #6 from irar at il dot ibm dot com 2009-08-12 12:14 ---
Looks like a problem in data-ref analysis:
Creating dr for this_6(D)->_M_x[__k_87]
...
base_address: this_6(D)
offset from base address: 0
constant offset from base address: 0
step: 8
--- Comment #2 from ami_stuff at o2 dot pl 2009-08-12 12:09 ---
The same problem happens with GCC 4.4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
--- Comment #2 from abel at gcc dot gnu dot org 2009-08-12 11:50 ---
Subject: Bug 41033
Author: abel
Date: Wed Aug 12 11:50:22 2009
New Revision: 150680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150680
Log:
2009-08-12 Andrey Belevantsev
PR rtl-optimization/41033
--- Comment #9 from hp at gcc dot gnu dot org 2009-08-12 10:34 ---
(In reply to comment #8)
> The patch is already approved, so I'm going to commit it on behalf of
> rsandifo.
Oops, I see it's not completely tested yet.
Ok, I'm doing a test-run on cris-elf first.
(If someone knows it's
--- Comment #8 from hp at gcc dot gnu dot org 2009-08-12 10:30 ---
(In reply to comment #6)
> From just reading the ChangeLog, a likely candidate:
That's already established by the revision range in the description. :)
The patch is already approved, so I'm going to commit it on behalf o
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-12 09:55 ---
reduced:
struct S
{
int size() const;
};
template
struct Packer
{
int foo() {
return Packer::var.size();
}
const S& var;
};
--
redi at gcc dot gnu dot org changed:
What|Rem
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-12 09:41
---
I think maybe the second example is rejected because of 2) not 3)
2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the
completed scope of S. No diagnostic
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-12 09:28 ---
Use -fpermissive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41039
--- Comment #7 from laurent at guerby dot net 2009-08-12 09:15 ---
There's a patch.
--
laurent at guerby dot net changed:
What|Removed |Added
URL|
--- Comment #6 from laurent at guerby dot net 2009-08-12 09:13 ---
>From just reading the ChangeLog, a likely candidate:
2009-08-09 Richard Sandiford
* tree-out-of-ssa.c (insert_value_copy_on_edge): If the source
and destination have different modes, Use promote_mode t
--- Comment #5 from laurent at guerby dot net 2009-08-12 09:09 ---
Same happens on sparc64 in 64 bits bootstrap in all-stage2-libiberty:
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/
-B/n/62/guerby/inst
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-12 09:07 ---
FIXED on the trunk (4.5)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dodji at gcc dot gnu dot org 2009-08-12 09:06 ---
Fixed in 4.4 and 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-12 09:04 ---
Subject: Bug 41034
Author: burnus
Date: Wed Aug 12 09:03:38 2009
New Revision: 150678
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150678
Log:
2009-08-12 Tobias Burnus
PR fortran/41034
*
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-12 09:02 ---
Subject: Bug 40990
Author: dodji
Date: Wed Aug 12 09:02:17 2009
New Revision: 150677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150677
Log:
Fix PR debug/40990
PR debug/40990
* lang.c (put_
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-08-12 08:55
---
Created an attachment (id=18344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18344&action=view)
compile fstream-inst.cc as c++0x to instantiate new members
i'm testing this patch
--
http://gcc.gnu.or
--- Comment #3 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:46 ---
*** Bug 41042 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:46 ---
*** This bug has been marked as a duplicate of 41041 ***
--
samuel dot thibault at ens-lyon dot org changed:
What|Removed |Added
---
1 - 100 of 108 matches
Mail list logo
