--- Comment #1 from abel at gcc dot gnu dot org 2009-08-12 07:40 ---
Confirmed on trunk. As we discussed on IRC, the below obvious patch makes
nonoverlapping_component_refs_p punt when !flag_strict_aliasing and thus fixes
the testcase. I have looked at the other rtl alias oracle functi
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-12 08:06 ---
If one looks at the failing test case one finds:
!gcc$ attributes cdecl :: cdecl
!gcc$ attributes stdcall :: stdcall
procedure(), pointer :: ptr
procedure(), pointer :: cdecl
procedure(), pointer :: stdcall
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-12 08:42 ---
r150620 implements simple parsing and resolution of CLASS statements, without
actual polymorphism. Some things missing for full polymorphism:
* CLASS(*)
* SELECT_TYPE
* EXTENDS_TYPE_OF
* SAME_TYPE_AS
--
http:
Hello, the manual page says `Set the wide execution character set, used for
wide string and character constants. The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".' This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-
Hello, the manual page says `Set the wide execution character set, used for
wide string and character constants. The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".' This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:45 ---
Created an attachment (id=18342)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18342&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2009-08-12
08:45 ---
Created an attachment (id=18343)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18343&action=view)
fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
Hello, the manual page says `Set the wide execution character set, used for
wide string and character constants. The default is UTF-32 or UTF-16,
whichever corresponds to the width of "wchar_t".' This should read UCS-4 or
UCS-2 instead. See attached program behavior when compiled without
-fwide-
--- 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
---
--- 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 #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
--
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 #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_
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
--
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 #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
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 #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
--- 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 #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 #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 #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 #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: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 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 #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 #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 #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 #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
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 #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
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 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
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 #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
--- 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 #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 #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 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 #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 #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 #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 #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 #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
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 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
-
--- 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 #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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|gcc.target/mips/memcpy-1.c |[
--- 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
--- 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
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 #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
--- 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 #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
--
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 #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
--- 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 #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 #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 #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 #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.
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 #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
--- 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 #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 #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
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
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
#
--- 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
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 #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 -
--- 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 #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
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 #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
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 #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
--- 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 #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 #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 #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
1 - 100 of 108 matches
Mail list logo
