--- Comment #1 from nemokingdom at gmail dot com 2009-12-05 07:04 ---
The polyhedral benchmark is available in:
http://www.polyhedron.com/web_images/documents/pb05.zip
> One fail (of 40 checkings) in mdbx in polyhedral benchmark with option -O2
> -fno-loop-block -fno-loop-strip-mine.
>
1342b in _Jv_Throw (value=0x10483e6c0) at
../../../gcc-4.5-20091204/libjava/exception.cc:128
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
One fail (of 40 checkings) in mdbx in polyhedral benchmark with option -O2
-fno-loop-block -fno-loop-strip-mine.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr...@155007
$ ../configure --prefix=/home/li/source/gcc.trunk/install --disable-bootstrap
--enable-languages=c,fortran,c++ --with-cloog=/u
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:56
---
It looks like this is fixed. I could not reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:36
---
No comments for a while, closing as won't fix.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:29
---
This is a glibc issue with software sin function. It does not use the FPU.
Just try with -m32. Changing n=5
$ gfc -m64 untitled.f90
$ time ./a.out
-1781878.9
real0m3.060s
user0m3.050s
sys
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:17
---
Works on 4.4 and current trunk,
closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from davek at gcc dot gnu dot org 2009-12-05 06:16 ---
boh! Forgot to reference the pr in the changelog. I'll fix it if anyone asks
me to but not otherwise, I don't think it's likely to be critical for such a
transient bug.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #11 from davek at gcc dot gnu dot org 2009-12-05 06:14 ---
Committed revision 155008.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:04
---
According to a note I spotted on clf , reading and writing reals with BOZ is
invalid, so what we are doing here is an extension. I am tempted to just close
this one and do no more.
Any opinions?
--
http://
template < typename T >
class SMART
{ T * data ;
public :
T * Get() {return(data); } ;
SMART( ) : data(__null) {} ;
SMART( T* value ) : data(value) {} ;
SMART(SMART & value) : data(value.Get()) {} ;
template < typename X , typename XT2 = T , typename X2 = typename X :: XT2 >
operator X * ()
template < typename T >
class SMART
{ T * data ;
public :
T * Get() {return(data); } ;
SMART( ) : data(__null) {} ;
SMART( T* value ) : data(value) {} ;
SMART(SMART & value) : data(value.Get()) {} ;
template < typename X , typename XT2 = T , typename X2 = typename X :: XT2 >
operator X * ()
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-12-05 04:17
---
Studying this with a little instrumentation, I see that gfc_expand_constructor
is called only once with some of the test cases for pr20923. This is good.
Also, in the test case for pr41807, the work function con
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-05
03:55 ---
Created an attachment (id=19235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19235&action=view)
Diff file
This allows me to compile it, but quoting from windef.h: /* FIXME: Is there a
good solution
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-05 02:27 ---
(In reply to comment #9)
> The patch fixes the build error. It's ok to install with a ChangeLog
> entry.
Great, thanks for checking and sorry for the inconvience. I'll get it
committed in the next hour or two, m
--- Comment #5 from jason at gcc dot gnu dot org 2009-12-05 01:56 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from zsojka at seznam dot cz 2009-12-05 01:55 ---
Created an attachment (id=19234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19234&action=view)
somehow reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42295
Command line:
for 4.5/trunk:
g++-4.5 -O1 -fschedule-insns -fselective-scheduling -o tmp.o testcase-manual.ii
-c
for 4.4 can be used as well:
g++-4.4 -O1 -fschedule-insns -o tmp.o testcase-manual.ii -c
Gives (trunk r154953):
testcase-manual.ii: In function ‘void testsum(ms*)’:
testcase-manual.ii:20
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-05 01:52 ---
Subject: Bug 42010
Author: jason
Date: Sat Dec 5 01:51:46 2009
New Revision: 155007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155007
Log:
PR c++/42010
* cp-tree.h (DECL_DISCRIMINATOR_SET_
--- Comment #2 from janis at gcc dot gnu dot org 2009-12-05 01:07 ---
The ICE occurs with a compiler built for powerpc64-linux but only for -m32 (the
default for my compiler), not for -m64. It does not occur for a powerpc-linux
compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-05 01:06 ---
/tmp/i686-pc-mingw32/include/windef.h:234:17: error: conflicting types for
'BOOL'
/tmp/gcc-4.5/libobjc/objc/objc.h:42:24: note: previous declaration of 'BOOL'
was here
Hmm, looks like the order of include files coul
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-05 01:06 ---
Created an attachment (id=19233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19233&action=view)
Minimized testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42294
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
416.gamess with "-O2 -fselective-scheduling2 -fsel-sched-pipelining
-funroll-all-loops" on powerpc64-linux, as demonstrated by a minimized testcase
that I'll attach to this PR.
elm3b187% /opt/gcc-nightly/trunk/bin/gfortran -
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-12-05
00:51 ---
Created an attachment (id=19232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19232&action=view)
Compiler error messages
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42293
GCC is configured with --target=i686-pc-mingw32, --enable-languages=objc,
--enable-objc-gc options. Compilation fails with message: conflicting types for
'BOOL'.
--
Summary: Can't build ObjC runtime library with GC for W32 target
Product: gcc
Version: 4.5.0
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-05 00:31 ---
I'd vote for valid (moving the definition of the return type into the
specification part already is accepted).
F95, 5.1 Type declaration statements
"The specification-expr (7.1.6.2) of a char-len-param-value (5.1.1.
--- Comment #3 from zsojka at seznam dot cz 2009-12-05 00:16 ---
C++ mode doesn't seem to be mandatory (it was for the testcase before
reduction), the following command is enough:
g++ -O2 -Wall -o tmp.o testcase-manual.ii -c
--
zsojka at seznam dot cz changed:
What|R
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-05 00:13 ---
The reduced testcase in comment #0 is really PR 29131 which talks about
fundemantal types.
And report's original code is invalid based on the associated namespace is std
there.
So closing as a dup of bug 29131.
**
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-05 00:13 ---
*** Bug 42281 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from uweigand at gcc dot gnu dot org 2009-12-05 00:12
---
Subject: Bug 42224
Author: uweigand
Date: Sat Dec 5 00:11:29 2009
New Revision: 155003
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155003
Log:
2008-12-04 Ulrich Weigand
Backport from mainli
--- Comment #5 from uweigand at gcc dot gnu dot org 2009-12-05 00:12
---
Subject: Bug 41857
Author: uweigand
Date: Sat Dec 5 00:11:29 2009
New Revision: 155003
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155003
Log:
2008-12-04 Ulrich Weigand
Backport from mainli
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-12-05 00:10
---
*** Bug 42292 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-05 00:10 ---
The wrong place is PR 16635.
>ADL doesn't apply.
Or does it? See C++ defect report 225.
The fundamental type issue is PR 29131 (and DR 225 for the C++ defect report).
Closing as a dup of bug 16635.
*** This bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-05 00:05 ---
There are two different issues here, only is the place where we instantiated
foo is wrong but the second issue is even weird and I think there is a
C++ defect report about it (do fundamental types have associated nam
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-05 00:03 ---
This is related to PR 15272 where we look at both dependent and non dependent
base classes when only non dependent should be looked at. Actually I think
this is a dup of that bug but I will leave it to a C++ expert.
The following code shouldn't compile; yet gcc accepts it:
template
int Foo() {
return Bar(T());
}
int x = Foo(); // This shouldn't compile.
int Bar(bool x) {
return 0;
}
The problem is that when Foo() is instantiated, the compiler should
search for Bar() only at the template definition site
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-05 00:01 ---
*** Bug 42291 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-05 00:01 ---
> MethodInBase(Foo());
Since Foo is dependent, it is looked up but base classes should be used to find
MethodInBase which means this is a dup of bug 24163.
*** This bug has been marked as a duplicate of 24163 **
The following code should NOT compile; yet gcc accepts it.
template
class Base {
public:
typedef int Foo;
void MethodInBase(Foo x) {}
};
template
class Derived : public Base {
public:
typedef typename Base::Foo Foo;
Derived() {
// According to C++ standard [14.6.4], the following line
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-04 23:54 ---
ISRA is the name of the variable that gets created by IPA SRA ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from zsojka at seznam dot cz 2009-12-04 23:53 ---
Created an attachment (id=19231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19231&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42290
Command line:
g++ -std=c++0x -O2 -Wall -o tmp.o testcase-manual.ii -c
or
g++ -std=c++0x -O2 -Wall -o tmp.o testcase-manual.ii -c
Gives:
testcase-manual.ii: In function ‘A::~A(A**, char*)’:
testcase-manual.ii:10:17: warning: ‘ISRA.2’ may be used
uninitialized in this function
testcase-manual.ii:10
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
23:45 ---
Subject: Re: FAIL: gnat.dg/null_pointer_deref1.adb
execution test
On Fri, 04 Dec 2009, ebotcazou at gcc dot gnu dot org wrote:
>
>
> --- Comment #10 from ebotcazou at gcc dot gnu dot org 2
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-04 23:42 ---
(In reply to comment #5)
> So perhaps it's not gfortran's fault, but a short-coming in not totally
> up-to-date gdb's
Any news here?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
23:39 ---
Subject: Re: os_defines.h:60:1: error: expected '{'
before '_GLIBCXX_PSEUDO_VISIBILITY'
On Fri, 04 Dec 2009, davek at gcc dot gnu dot org wrote:
>
>
> --- Comment #8 from davek at gcc dot gn
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-04 23:37 ---
PR38507 is closed, no backport to 4.4 seems to be planned.
Shouldn't this PR be closed as INVALID?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-04 23:33 ---
Confirmed and marked as enhancement.
(I'd like to eventually be able to use the attribute DEPRECATED.)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-04 23:28 ---
How about this (somewhat constructed) example:
! interface module, file (a)
MODULE M
PRIVATE :: two
CONTAINS
SUBROUTINE one(a)
integer :: a
END SUBROUTINE one
integer FUNCTION two()
END FUNCTION two
EN
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from viriketo at gmail dot com 2009-12-04 23:20 ---
I think I understand that libiberty must be compiled for the host, and not for
the target.
Then, 'xgcc' wants the system headers, to build the cross compiler, and not
those of the target libc.
In this case it would be my
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-04 23:15 ---
(In reply to comment #2)
> It should not use any standard headers. I don't expect this cross-gcc to build
> any executable. Only to compile code.
libiberty is a library
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #2 from viriketo at gmail dot com 2009-12-04 23:14 ---
It should not use any standard headers. I don't expect this cross-gcc to build
any executable. Only to compile code.
Isn't this a usual stage bootstrapping? Then, when having a libc, with the help
of 'ld' and libc object
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
--- Comment #1 from jason at gcc dot gnu dot org 2009-12-04 22:51 ---
Subject: Bug 42277
Author: jason
Date: Fri Dec 4 22:51:12 2009
New Revision: 155002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155002
Log:
PR c++/42277
* semantics.c (finish_decltype_type)
--- Comment #21 from dominiq at lps dot ens dot fr 2009-12-04 22:47 ---
> Pretty sure.
The following ICE is probably a signature:
[macbook] f90/bug% cat > pr40472_1.f90
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *,
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-12-04 22:47
---
Jakub, do you still plan to bring this to 4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
--- Comment #1 from flameeyes at gentoo dot org 2009-12-04 22:43 ---
Created an attachment (id=19229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19229&action=view)
Patch to fix the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42289
This is the error reported:
libtool: compile:
/var/tmp/cross/arm-carel-linux-gnu/portage/cross-arm-carel-linux-gnu/gcc-4.3.4/work/build/./gcc/xgcc
-B/var/tmp/cross/arm-carel-linux-gnu/portag
e/cross-arm-carel-linux-gnu/gcc-4.3.4/work/build/./gcc/
-B/usr/arm-carel-linux-gnu/bin/ -B/usr/arm-carel-l
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-12-04 22:41
---
> I'm calling the gcc main configure with "--without-headers"
So how do you expect it to know where to look for the standard headers?
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #20 from dfranke at gcc dot gnu dot org 2009-12-04 22:40
---
(In reply to comment #19)
> > Changing to NEW as it (unfortunately) still is.
>
> Are you sure?
Pretty sure. I haven't checked the sources in a while, but I doubt that anyone
got rid of the linear lists (see comm
I have modified gdb to read the .debug_aranges section.
Currently, if this information does not exist for a
particular CU, gdb must scan the CU to find it.
This is necessary because there is no way to differentiate
between a section that is missing because it has no ranges,
and a section that is mi
--- Comment #19 from dominiq at lps dot ens dot fr 2009-12-04 22:35 ---
> Changing to NEW as it (unfortunately) still is.
Are you sure? on a macbook Core2Duo 2.53Ghz I get:
[macbook] f90/bug% time gfc pr40472.f90
0.024u 0.021s 0:00.05 80.0% 0+0k 0+8io 0pf+0w
--
http://gcc.gnu.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-04 22:34 ---
(In reply to comment #2)
> I have tried to simplify the code, but I have created only problem with int
> (not with user structure). In real code we have also something like this:
Your original code is invalid code a
--- Comment #18 from dfranke at gcc dot gnu dot org 2009-12-04 22:33
---
Is this still an issue?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dfranke at gcc dot gnu dot org 2009-12-04 22:30
---
Nothing new in three months. Assuming that an update indeed fixed the problem.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from dfranke at gcc dot gnu dot org 2009-12-04 22:25
---
What is this one waiting for? Changing to NEW as it (unfortunately) still is.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-04 22:20 ---
Nothing new here?! Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-04 22:17 ---
Which would be http://sourceware.org/bugzilla/
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-04 22:15 ---
>xgcc: Internal error: Segmentation fault (program as)
This means your assembler is crashing. The assembler is part of the binutils
project.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--- Comment #20 from dfranke at gcc dot gnu dot org 2009-12-04 22:07
---
Transformational intrinsics, done are:
* all, any, count
* product, sum
* dot_product, matmul, transpose
* pack, unpack, spread
Left:
* maxloc, minloc
* maxval, minval (generic case)
* cshift, eoshift
Whil
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-04 21:56 ---
At revision 154987 I only see:
FAIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test
and the failure is:
1 7 12 127 99: 13 233 134-1 0 12 127 99: 10 226 127FAIL:
libffi.call/nested_struct5.c -O0 -W -Wall e
--- Comment #1 from mark at advancedtechcorp dot com 2009-12-04 21:55
---
Created an attachment (id=19228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19228&action=view)
config log
configuration log where the crash is shown.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Attempting to build GCC for a powerpc-linux-gnu target. Host machine is i686
running Linux 2.6.31.6-145.fc12.i686.PAE
Get the dreaded "checking for suffix of object files... configure: error:
cannot compute suffix of object files: cannot compile See `config.log' for
more details." message. Look
--- Comment #2 from dominiq at lps dot ens dot fr 2009-12-04 21:47 ---
Confirmed on x86_64-apple-darwin10:
[macbook] f90/bug% gcc45 -O2 -floop-interchange -c pr42284.c
pr42284.c:6:14: warning: conflicting types for built-in function 'malloc'
pr42284.c: In function 'inflate_fixed':
pr422
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-04 21:41 ---
Confirmed on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42285
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-04 21:37 ---
With the patch in comment #7 the tests in pr41829 and the following ones
segfault at runtime.
!
module m
type :: t1
integer :: i = 42
contains
procedure, pass :: prod => i
--- Comment #2 from jezz at hkfree dot org 2009-12-04 21:30 ---
I have tried to simplify the code, but I have created only problem with int
(not with user structure). In real code we have also something like this:
Tested with same compilers:
template2.cc: In function ‘bool isEqual(const
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-12-04
21:28 ---
Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc
with -ffast-math
On Fri, Dec 04, 2009 at 09:18:45PM -, rguenth at gcc dot gnu dot org wrote:
>
>
> --- Comment #1
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 21:24 ---
Please send patches to gcc-patc...@gcc.gnu.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-04 21:18 ---
This change merely turns off PRE in cold code regions. So if -fno-tree-pre
breaks calculix for you I'd guess some later optimization manages to
miscompile it (my guess: the vectorizer).
What options do you build ca
The October 23rd, 2009 change to tree-ssa-pre.c breaks calculix on powerpc with
-ffast-math. When you start up the benchmark with reference input, it fails
almost immediately because the calculations don't converge.
At this point, I don't have a narrowed down test case, but the following
change:
--- Comment #16 from tkoenig at gcc dot gnu dot org 2009-12-04 21:03
---
We get this right on assignment, so it is probably "just" a matter
of copying over the logic from there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-04 21:00 ---
> Have you tried r154983 with
> http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html?
The patch does not change anything, I get the same failures with or without it.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
GCC trunk gets an internal compiler error when building SPEC CPU2006 test
416.gamess with "-O2 -floop-interchange" on powerpc-linux, as demonstrated by
this minimized testcase:
SUBROUTINE EFGRDM(NCF,NFRG,G,RTRMS,GM,IOPT,K1)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DIMENSION G(*),RTRMS
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-04 20:39 ---
Created an attachment (id=19227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19227&action=view)
Minimized testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
164.gzip with "-O2 -floop-interchange" on powerpc-linux, as demonstrated by a
minimized testcase that I'll attach to this PR.
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -O2 -floop-interchange
bug.c
bug.c: In fu
--- Comment #15 from tkoenig at gcc dot gnu dot org 2009-12-04 20:36
---
Very probably a dup of PR 40850.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #14 from tkoenig at gcc dot gnu dot org 2009-12-04 20:33
---
The problem is with the allocatable components for
intrinsics, at least.
This has the same problem:
program main
type :: container_t
integer, dimension(:), allocatable :: entry
end type container_t
type(
While bootstrapping trunk from 20091201 on amd64. Crash doesn't happen with GCC
4.4.1-ubuntu8.
The ICE occurs when -ftree-loop-distribution is combined with -O2
-ftree-loop-linear. The commandline below reproduces the issue as well, but can
be reduced to the forementioned options as well.
gcc -c
With 20091201 trunk on Linux/amd64 ICE does not happen with GCC 4.4.1-ubuntu8.
Appears to be bad interaction
between -O2 and -funswitch-loops. Either alone is fine, but together the crash
occurs. The commandline below reproduces the issue, but removing all but -O2
and -funswitch-loops will also re
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-04 19:56 ---
One issue is Koenig lookup does not apply to fundamental types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42281
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-04 19:52 ---
Jerry, this might be involved in PR41165 as well?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
[Code]
template
int doSomething(T const &aT)
{
return aT.a();
}
class A
{
public:
int a() const
{
return 1;
}
};
class B
{
public:
int b() const
{
return 1;
}
};
template
inline bool isOne(T const &aT)
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-04 19:43 ---
(In reply to comment #6)
> I think the problem is that c->tb->ppc is not set correctly for the PPCs
> inside
> vtype.
The following patches fixes it:
Index: gcc/fortran/symbol.c
=
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-12-04 19:22 ---
Janus, I just re-checked the patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478#c12
and found that that is all that's needed.
OK to commit to trunk and, after a few days, to 4.4 with the
testcase from
h
Trying to build a gcc 4.4.2 for 'baremetal' targets, in my case for later libc
building, I find that the libiberty configure script at some stage checks for
some libc headers to be available.
I'm calling the gcc main configure with "--without-headers". The total flags
are:
--prefix=/nix/store/bqya
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-04 18:46 ---
will do
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from viriketo at gmail dot com 2009-12-04 18:44 ---
Created an attachment (id=19226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19226&action=view)
Fix the CPP needed by libmudflap when cross-compiling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
1 - 100 of 173 matches
Mail list logo
