--- Comment #3 from spop at gcc dot gnu dot org 2009-12-09 04:56 ---
Fixed in the Graphite branch, I will commit this to trunk once it passes
regtest on the branch.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-09 04:55 ---
Subject: Bug 42285
Author: spop
Date: Wed Dec 9 04:54:54 2009
New Revision: 155100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155100
Log:
Fix PR42285.
2009-12-08 Sebastian Pop
PR middle-end/42
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-09
04:21 ---
(In reply to comment #6)
> I have this problem of MacOSX 10.3
> $ gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. bui
--- Comment #1 from carrot at google dot com 2009-12-09 02:27 ---
Gcc 4.4 doesn't have this problem. It is a new regression caused by patch
152533.
--
carrot at google dot com changed:
What|Removed |Added
---
--- Comment #6 from 3dw4rd at verizon dot net 2009-12-09 02:00 ---
I have this problem of MacOSX 10.3
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)
When I do a make on an empty directory i
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-12-09
01:11 ---
Actually, I found this file which is quite interesting in the darwin10 libgcc
open source release...
http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c
--
http://gcc.gnu.org/bugzilla/show
--- Comment #6 from danglin at gcc dot gnu dot org 2009-12-09 00:36 ---
I see the same fails as HJL on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from ghazi at gcc dot gnu dot org 2009-12-09 00:34 ---
(In reply to comment #15)
> (In reply to comment #13)
> > You can try filing a bug report at Apple, but I think a better route would
> > be
> > to see if we can avoid linking in the system ___divdc3 from FSF GCC.
>
--- Comment #5 from w6ws at earthlink dot net 2009-12-09 00:27 ---
(In reply to comment #4)
> ... it dawns on me that the crucial point is, that variables with
> initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE
> components. Correct?
I am not sure why they p
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-12-09
00:19 ---
I can confirm that the gcc.dg/torture/builtin-math-7.c testcases still fail
under darwin10 if the libgcc_ext changes are regressed out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-12-09
00:12 ---
(In reply to comment #13)
> You can try filing a bug report at Apple, but I think a better route would be
> to see if we can avoid linking in the system ___divdc3 from FSF GCC.
>
This may be impossible
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-12-09 00:06 ---
(In reply to comment #11)
> I think I understand why apple gcc42 does not show the problem: it does not
> call ___divdc3:
It is possible that some versions of GCC (Apple's and/or FSF's) inline the
assembly code to do
--- Comment #2 from dje at gcc dot gnu dot org 2009-12-09 00:03 ---
libmpfr must be a shared object because libmpc relies on hidden, global state
in libmpfr. If libmpfr is linked statically with libmpc and with GCC, each
receives different instances of the global variables.
--
dje a
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-08 23:58 ---
(In reply to comment #12)
> .. seems likely that there are two things here: 1. we seem to be generating
> (probably) less efficient code than older versions of the compiler ... and 2.
> possibly the ___divdc3 in /usr/
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-08 23:54 ---
[temp.class.spec]/1
"A partial specialization shall be declared before the first use of a
class template specialization that would make use of the partial specialization
as the result of an implicit or explicit instantia
--- Comment #12 from developer at sandoe-acoustics dot co dot uk
2009-12-08 23:40 ---
(In reply to comment #11)
> I think I understand why apple gcc42 does not show the problem: it does not
> call ___divdc3:
>
> [macbook] f90/bug% diff -up pr42333_42.s pr42333_45.s
> --- pr42333_42.s
The following code causes an ICE with segmentation fault:
--
#include
#include
template< typename T1 >
void vadd(const std::vector< T1 > &a, decltype(a[0]) t) {
std::cout << "-> ICE \n";
}
void vadd(const std::vector< int >
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 23:29 ---
(In reply to comment #0)
> Could the warning message below be revised to include a warning that NULL will
> evaluate to false or zero?
What else would it evaluate to?
N.B. with recent versions of GCC -Wconversion is n
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 23:11 ---
Confirmed, the friend declaration appears to be declaring f in namespace A,
despite the :: qualifier
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from xinliangli at gmail dot com 2009-12-08 23:10 ---
Created an attachment (id=19263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19263&action=view)
bug test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42337
--- Comment #3 from viriketo at gmail dot com 2009-12-08 23:07 ---
I already sent the patch to the mailing list mentioned.
I noticed this problem also affects gcc 4.4.2. The same patch can be applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
Compiling the attached test case, trunk gcc ICEs (or run out of memory without
the checking). The symptom is similar to the one before PR/41101
The root cause of the problem is the result of an expr's phi_translate depends
on the context it is done -- it may return NULL if it is translated as a
su
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-12-08 22:56 ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00458.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42231
The following reduced program produces an ICE when compiled with
-std=c++0x -O2 -g.
=
struct X {
void func() {}
};
template
void b(T) {}
int main() {
b(X()); /* line 9 */
X().func();
return 0;
}
--- Comment #6 from laurent at guerby dot net 2009-12-08 22:41 ---
Note: armv7l 4.4.2 also fails:
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00749.html
Discussions on the topic.
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01495.html
Doug?
--
laurent at guerby dot net chang
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-08 22:28 ---
C::dflt has type const int by pd->d[i] has type int, so they do not have the
same type and the warning is correct. This is DR 587 which was just changed in
the latest draft
http://www.open-std.org/jtc1/sc22/wg21/docs/c
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-08 22:13 ---
I think I understand why apple gcc42 does not show the problem: it does not
call ___divdc3:
[macbook] f90/bug% diff -up pr42333_42.s pr42333_45.s
--- pr42333_42.s2009-12-08 23:00:29.0 +0100
+++ pr423
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-08 22:02 ---
> void* is a pointer to fundamental type so has no associated namespaces
Well there is a still open defect report that says this might not be true :).
*** This bug has been marked as a duplicate of 29131 ***
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-12-08 22:02 ---
*** Bug 34886 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-12-08 22:01 ---
Actually
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|RE
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 21:58 ---
In resolving dependent names, names from the following sources are considered:
Declarations that are visible at the point of definition of the
template.
Declarations from namespaces associated with the types of the f
Hi,
the following (invalid) code gives an ICE:
module gfcbug95
implicit none
type, abstract :: vector_class
end type vector_class
type, extends(vector_class) :: trivial_vector_type
real :: elements(100)
end type trivial_vector_type
contains
subroutine bar (this,v)
class(trivi
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-12-08 21:41 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in
> > the
> > example (figure 12.3, p243) for allocatable components... So, where's th
--- Comment #3 from w6ws at earthlink dot net 2009-12-08 21:34 ---
(In reply to comment #2)
> I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
> example (figure 12.3, p243) for allocatable components... So, where's the
> actual problem?
The example on p243
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-08 21:30 ---
(In reply to comment #2)
> I am not sure this is such a good idea. A casting typically means "I want to
> really do this". GCC normally suppress warnings when casting is added. A
> warning when you assign when enum type
--- Comment #10 from dominiq at lps dot ens dot fr 2009-12-08 21:29 ---
> For Darwin 9 there is no "system provided ___divdc3" (AFAICT) .. it is
> supplied
> from libgcc_s.1.dylib.
I see:
[ibook-dhum] f90/bug% nm /usr/lib/libm.dylib | grep divdc3
00131270 t ___divdc3
> if this is a r
--- Comment #3 from viriketo at gmail dot com 2009-12-08 21:28 ---
I found the (proper?) way of getting -Bxxx flags to the target libraries, even
if they use libtool: make FLAGS_FOR_TARGET
Any -Bxxx in CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET gets ignored, but those in
FLAGS_FOR_TARGET pa
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-08 21:17 ---
All three cases are flagged by current 4.5.0 20091208.
The first one gives
$> gfortran-svn pr35918.f90
pr35918.f90:2.8:
real foo
1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in '
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 21:06 ---
Assuming that's an accurate reduction of the original code, comment 4 is
correct. I didn't look at the preprocessed source, it includes Boost code that
will be very specific to the GCC 4.0.2 version it was compiled wit
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 21:04 ---
*** Bug 38733 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 21:04 ---
*** This bug has been marked as a duplicate of 37398 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
ppened at some point. Current 4.5.0 20091208 gives:
$> gfortran-svn pr37412.f90
pr37412.f90:3.17:
character(1) st
1
Error: Symbol 'st' at (1) already has basic type of CHARACTER
I believe this is correct. Closing.
--
dfranke at gcc dot gnu dot org changed:
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-08 20:58 ---
Marking as dupe, discussion happened in PR37412.
*** This bug has been marked as a duplicate of 37412 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-08 20:58 ---
*** Bug 34527 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-12-08
20:51 ---
> version 125.0.0)
> /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0,
> current version 315.0.0)
> [macbook] f90/bug% nm /usr/lib/libSystem.B.dylib | grep divdc3
> 0019fa1e S
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:45 ---
diagnosing this would be useful and shouldn't require instantiation, it should
be detectable during phase 1
reduced:
struct foo {
template foo(int);
};
--
redi at gcc dot gnu dot org changed:
What
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 20:33 ---
(In reply to comment #0)
> ! The following is illegal!
> type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )
I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
example (figure 12.3
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-12-08 20:32
---
This really is not a duplicate of PR20923. In fact the gfortran frontend makes
it through the fft257.f90 test case in a few seconds. The memory hogging and
cycling is happening in middle-end.
With a simple vari
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:32 ---
reduced:
void f() {
unsigned short i = 0;
void* p = (void*)i;
}
this warns in 32-bit or 64-bit mode using the C compiler, and is controlled by
this option that g++ doesn't support:
-Wno-int-to-pointer-cast (C and O
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-08
20:27 ---
(In reply to comment #6)
A *Very* quick look following a prompt from Jack...
> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there. Try re
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-12-08 20:24 ---
(In reply to comment #6)
> Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
> unclear what that test should do there.
Jack - Focusing on builtin-math-7.c (which tests multiple things) misses t
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-08 20:24 ---
*** Bug 31956 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-08 20:24 ---
*** This bug has been marked as a duplicate of 18770 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:21 ---
There's been an XFAIL about this in g++.old-deja/g++.jason/cond.C for ages, but
it doesn't test the switch case.
Self-contained testcase:
void f() {
if (int foo = 0)
int foo = 1;
switch (int foo = 0)
{
de
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:59 ---
Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
unclear what that test should do there. Try reverting out the libgcc_ext
changes from gcc trunk on darwin10 instead.
--
http://g
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-08 19:51 ---
I think this comes down to an alignment issue. On darwin, the stack has to be
aligned to 16bytes so something inside i386.c is deciding that we to allocate
the stack frame as there was something on the stack and we h
--- Comment #5 from dominiq at lps dot ens dot fr 2009-12-08 19:34 ---
Additional information:
(1) I don't see the problem on (i686|x86_64)-apple-darwin9.
(2) I also see it gcc version 4.4.2 (GCC).
(3) I don't see it with gcc version 4.2.1 (Apple Inc. build 5646) (dot 1).
(3) If I co
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:30 ---
Dominique,
It would be interesting to know what happens with a build of gcc trunk
under darwin10 if you regress out the r154282 and r154283 that introduced the
libgcc_ext feature . I suspect this regres
GCC trunk gets a segmentation fault when building SPEC CPU2000 test
200.sixtrack with "-floop-interchange -ftree-loop-distribution" on
powerpc-linux, as demonstrated by this minimized testcase:
subroutine blockdis(bl1eg,bl2eg)
implicit real*8 (a-h,o-z)
parameter(nblo=300)
c
--- Comment #3 from dominiq at lps dot ens dot fr 2009-12-08 18:31 ---
(In reply to comment #2)
> I don't think that's the right approach, that would only mask the bug in the
> testsuite but leave it in userland. ...
You are right, but from what follows I think the problem comes from th
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-08 18:26 ---
Both icc and gcc generate:
[...@gnu-26 pr42324]$ cat b4.c
extern unsigned int bartmp;
void foo(_Bool bar)
{
bartmp = bar;
}
[...@gnu-26 pr42324]$ objdump -dw b4.o
b4.o: file format elf64-x86-64
Disassembly
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-08 18:17 ---
Another testcase:
[...@gnu-26 pr42324]$ cat b3.c
void foo (unsigned long, unsigned int, unsigned long,
unsigned int, unsigned int, unsigned int, unsigned int,
unsigned long, unsigned int);
void
--- Comment #5 from tromey at gcc dot gnu dot org 2009-12-08 17:58 ---
FWIW, I know that this patch will not affect the CVS gdb,
because that gdb never reads the .debug_aranges section.
I'll try this out using my branch today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288
--- Comment #5 from daney at gcc dot gnu dot org 2009-12-08 17:34 ---
(In reply to comment #4)
> Mike Stump says that the frame can be optimized away on darwin. However,
> Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...
That compiler doesn't implement __buil
--- Comment #26 from jsm28 at gcc dot gnu dot org 2009-12-08 17:08 ---
List of remaining target OSes without stdint.h type information added
to 4.5 release notes:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00441.html
NetBSD, VxWorks, VMS, SymbianOS, WinCE, LynxOS, Netware, QNX, Interi
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-12-08 16:46 ---
(In reply to comment #1)
> > As such, it isn't necessarily a bug in GCC, however
> > this PR will help track if there is a possible workaround.
> As far as I understand the use of the gcc compilers on darwin, I do not
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-12-08 16:36
---
Testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-12-08 16:35 ---
(In reply to comment #10)
> I had a look at the problem and found that it is due to the -lm flag used in
> the test suite. [...]
> and tgcc.dg/torture/builtin-math-7.c passes when it is compiled manually
> without -lm
--- Comment #10 from hubicka at ucw dot cz 2009-12-08 16:35 ---
Subject: Re: [4.5 Regression] ICE with inlining
> I assumed it is special vtable handling (that likely doesn't cause the
> addressable flag to be set?) - I simply stopped debugging at the point
> where I noticed the node g
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-08 16:33 ---
> As such, it isn't necessarily a bug in GCC, however
> this PR will help track if there is a possible workaround.
As far as I understand the use of the gcc compilers on darwin, I do not see
when I should use -lm.
So
As noted in PR42074, linking with the math library on darwin10 allows overflow
to occur during complex division. It was originally reported as a failure in
testcase gcc.dg/torture/builtin-math-7.c at all optimization levels. However
as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4207
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-12-08 16:01 ---
I assumed it is special vtable handling (that likely doesn't cause the
addressable flag to be set?) - I simply stopped debugging at the point
where I noticed the node gets removed even though there are still
indirect
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-12-08 15:57 ---
So we have new direct call appearing to function that has been previously
eliminated as unreachable (after inlining) as a result of devirtualization?
In general if function have address taken, we should not remove i
--- Comment #6 from dodji at gcc dot gnu dot org 2009-12-08 15:52 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00438.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #5 from igodard at pacbell dot net 2009-12-08 15:20 ---
Both proposals befriend more than the minimum actually needed by program
semantics. The former befriends any member of freeList, not just foo;
the latter any member of any freeList at all. In addition, the former require
--- Comment #5 from dodji at gcc dot gnu dot org 2009-12-08 14:45 ---
Created an attachment (id=19262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19262&action=view)
Candidate patch
I am testing this patch currently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-08 14:44 ---
A shorter reproducer is:
struct foo
{
static const bool b = false;
};
template
struct S1
{
};
template
struct S2
: S1
{
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42251
--- Comment #4 from pbdr at uea dot ac dot uk 2009-12-08 14:35 ---
Mmmhh ... indeed ... I really though my processor for sse4, but it doesn't seem
to be. Sorry about such a bad mistake.
--
pbdr at uea dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-08 14:30 ---
Is your CPU SSE4 capable? cat /proc/cpuinfo would reveal this.
Can you post disassembly at the point of SIGILL (run it under gdb,
p/x $pc
disas $pc-64 $pc+64
info reg
when it crashes?
--
jakub at gcc dot gnu dot or
--- Comment #25 from burnus at gcc dot gnu dot org 2009-12-08 14:25 ---
STATUS:
* Writing large-kind real/complex numbers works (cf. comment 10)
* Reading large-kind real/complex numbers works on systems which have
INTEGER(16) (cf. comment 24, which added REAL(10) support)
* For the s
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-12-08 14:16
---
After removing a couple of lines from the preprocessed code I end up with the
same problem as in PR41290. Apparently this bug hasn't been fixed and still
haunts us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-08 14:15
---
Since you have specializations for A, you also need, in general, the
corresponding definitions:
const int A<0>::i;
const int A<1>::i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42330
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
14:13 ---
Mike Stump says that the frame can be optimized away on darwin. However,
Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...
[MacPro:~/bug] howarth% gcc-4.2 -O2 -fomit-frame-point
--- Comment #24 from burnus at gcc dot gnu dot org 2009-12-08 14:12 ---
Subject: Bug 41711
Author: burnus
Date: Tue Dec 8 14:12:06 2009
New Revision: 155088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155088
Log:
2009-12-08 Tobias Burnus
PR fortran/41711
--- Comment #9 from aijunbai at gmail dot com 2009-12-08 14:06 ---
(In reply to comment #8)
> Then show here exactly what you are trying to compile. Note: this is *not*
> gcc-help.
>
alright, take the flowing code as an example:
template
struct A {
static const int i = -1;
};
tem
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--
pbdr at uea dot ac dot uk changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--- Comment #2 from pbdr at uea dot ac dot uk 2009-12-08 14:00 ---
Created an attachment (id=19261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19261&action=view)
preprocessed file for the main program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
--- Comment #1 from pbdr at uea dot ac dot uk 2009-12-08 14:00 ---
Created an attachment (id=19260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19260&action=view)
preprocessed file for the library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42332
While compiling a simple class containing a std::tr1::unordered_map member as a
library, linking to the library and creating an object generate illegal
hardware instruction. Or at least, running the code raise a SIGILL. The library
file is lib.cc and the main program is test_lib.cc. The commands us
--- Comment #45 from matz at gcc dot gnu dot org 2009-12-08 13:56 ---
Subject: Bug 38474
Author: matz
Date: Tue Dec 8 13:56:06 2009
New Revision: 155087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155087
Log:
PR middle-end/38474
* function.c (free_temp_slots)
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-08 13:12
---
Then show here exactly what you are trying to compile. Note: this is *not*
gcc-help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42330
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-08 13:11
---
Likely a duplicate of PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #7 from aijunbai at gmail dot com 2009-12-08 13:02 ---
(In reply to comment #6)
> (In reply to comment #5)
> > >
> > > template const A::i;
> > >
> >
> > I tried so, but it seems do not work, could you please explain more
> > detailedly?
> > thx~
>
> I missed the "int" o
--- Comment #6 from debian-gcc at lists dot debian dot org 2009-12-08
12:37 ---
*** Bug 42323 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42317
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-12-08
12:37 ---
*** This bug has been marked as a duplicate of 42317 ***
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
-
--- Comment #5 from doko at ubuntu dot com 2009-12-08 12:36 ---
yes, re-testing with the version from the ML. currently passed the libstdc++
build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42317
--- Comment #6 from redi at gcc dot gnu dot org 2009-12-08 12:23 ---
(In reply to comment #5)
> >
> > template const A::i;
> >
>
> I tried so, but it seems do not work, could you please explain more
> detailedly?
> thx~
I missed the "int" out:
template const int A::i;
--
http:
--- Comment #2 from zsojka at seznam dot cz 2009-12-08 12:19 ---
Created an attachment (id=19259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19259&action=view)
reduced testcase
pr42325-reduced.cpp:2:27: error: template parameters not used in partial
specialization:
pr42325-redu
1 - 100 of 145 matches
Mail list logo
