--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** This bug has been marked as a duplicate of 44186 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** Bug 44187 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--- Comment #1 from pinskia at gmail dot com 2010-05-18 03:50 ---
Subject: Re: New: Wrong code generated with -O2 and above
Sent from my iPhone
On May 17, 2010, at 8:37 PM, "eyakubovich at gmail dot com"
wrote:
> This is a stripped down code from proposed Boost.Move library.
>
Sent from my iPhone
On May 17, 2010, at 8:37 PM, "eyakubovich at gmail dot com" > wrote:
This is a stripped down code from proposed Boost.Move library.
Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include
template
class rv : public T
{
rv();
~rv();
rv(rv const&);
This is a stripped down code from proposed Boost.Move library. Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include
template
class rv : public T
{
rv();
~rv();
rv(rv const&);
void operator=(rv const&);
};
template
rv& move(T& x)
{
return *static_cast* >(&x);
}
This is a stripped down code from proposed Boost.Move library. Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include
template
class rv : public T
{
rv();
~rv();
rv(rv const&);
void operator=(rv const&);
};
template
rv& move(T& x)
{
return *static_cast* >(&x);
}
On Linux/ia32, revision 159516 gave:
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-assembler-times prefetcht 5
FAIL: gcc.dg/tree-ssa/prefetch-6.c scan-tree-dump-times aprefetch "Issued
prefetch" 5
FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-assembler-times mfence 2
FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-as
Consider this file:
#include
int x = 1;
int main ()
{
asm goto ("decl %0; jnz %l[a]" :: "m"(x) : "memory" : a);
printf ("Hello world\n");
a:
return 0;
}
It compiles and links correctly without LTO.
But with LTO, "gcc-4.5.0 -flto a.c", there is an error:
In file included from :0:0:
--- Comment #16 from iains at gcc dot gnu dot org 2010-05-18 01:40 ---
the patch below helps...
I also suspect we might have to check for emutls vars twice - because they can
be introduced by profiling code
just for the sake of a trial - I've put the emutls_final into toplev.c twice:
For
---
#define N 16
float b[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float a[N];
void
test (void)
{
int i;
for (i = 0; i < N/2; i++)
a[i] = b[2*i+1] * c[2*i+1];
}
---
vectorizer generates:
test ()
{
unsigned int ivtmp.30;
--- Comment #1 from zsojka at seznam dot cz 2010-05-18 00:41 ---
Created an attachment (id=20692)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20692&action=view)
reduced testcase
$ g++ -O1 -fcompare-debug pr44182.C
g++: pr44182.C: -fcompare-debug failure (length)
--
http://g
Command line:
g++ -O[123] -fcompare-debug testcase.C
Tested revisions:
r159511 - fail
--
Summary: -fcompare-debug failure (length) with -O1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
--- Comment #2 from zackw at panix dot com 2010-05-17 23:59 ---
So it has to be a little smarter than the obvious, so what else is new.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-17 23:49 ---
(In reply to comment #6)
> I already explained what dot_product is doing in comment #2.
> dot_product(a,b) is equivalent to
>
>s = 0
>do n = 1, m
> s = s + a(n) * b(n)
>end do
>(return s)
>
>
--- Comment #1 from hjl at gcc dot gnu dot org 2010-05-17 23:48 ---
Subject: Bug 44180
Author: hjl
Date: Mon May 17 23:47:44 2010
New Revision: 159519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159519
Log:
Properly implement extract even/odd elements for V8SF.
gcc/
2010-05
--- Comment #1 from zsojka at seznam dot cz 2010-05-17 23:45 ---
Created an attachment (id=20691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20691&action=view)
reduced testcase (from gcc.c-torture/compile/pr43415.c)
$ /mnt/svn/gcc-trunk/binary-158095-lto-fortran/bin/g++ -Os -fg
Compiler flags:
g++ -Os -fgraphite-identity -fcompare-debug testcase.c
Tested revisions:
r159511 - fail
r159045 - fail
r158095 - fail
--
Summary: -fcompare-debug failure (length) with -Os -fgraphite-
identity
Product: gcc
Version: 4.6.0
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-17 23:18 ---
(In reply to comment #5)
> (In reply to comment #4)
> > We have complete control of whether to print the negative sign with
> > -fno-sign-zero. I am tempted to say this is a no-never-mind situation.
>
> Using the tes
[...@gnu-6 gcc]$ cat z.c
#define N 16
float b[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
float a[N];
void
test (void)
{
int i;
for (i = 0; i < N/2; i++)
a[i] = b[2*i+1] * c[2*i+1];
}
[...@gnu-6 gcc]$ ./xgcc -B./ -O2 -ftree-vectorize
--- Comment #5 from potswa at mac dot com 2010-05-17 22:56 ---
Created an attachment (id=20690)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20690&action=view)
regression test using G++ typeof
Here is a version that doesn't require C++0x. It uses the typeof extension.
It compile
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-17 22:23 ---
(In reply to comment #4)
> We have complete control of whether to print the negative sign with
> -fno-sign-zero. I am tempted to say this is a no-never-mind situation.
Using the testcase shown in comment #3:
$> gf
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 22:10 ---
I can see a case involving templates or macros where the warning does not make
sense and involving the new C1x/C++0x static_assert too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
sizeof(char) is defined to be 1, and is therefore almost always unnecessary.
It would be nice if the C and C++ front ends could complain about it.
--
Summary: warn about sizeof(char)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
--- Comment #1 from zsojka at seznam dot cz 2010-05-17 21:47 ---
Created an attachment (id=20689)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20689&action=view)
reduced testcase
$ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ -O1 -fgcse
-fsched-pressure -funroll-loops -fs
--- Comment #37 from kargl at gcc dot gnu dot org 2010-05-17 21:46 ---
*** Bug 44177 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from kargl at gcc dot gnu dot org 2010-05-17 21:46 ---
Pull the trigger for Daniel and mark this as a duplicate.
Harry, thanks for the report. The bug is fixed in gcc
trunk, which will become 4.6.0 someday. If you can't
fix the code (which is recommended), then you'll
Compiler flags:
$ g++ -O1 -fsched-pressure -funroll-loops -fschedule-insns -fcompare-debug
testcase.C
Tested revisions:
r159305 - fail
r159045 - fail
r158095 - fail
r153685 - OK
--
Summary: -fcompare-debug failure with -O1 -fgcse -fsched-pressure
-funroll-loops -f
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-17 21:10 ---
The PR(In reply to comment #3)
> I think the ICE has been fixed by the recent constructor work by Daniel.
That was PR24978. Given that this PR was opened against 4.1 in 2005 and a
simple workaround exists (fix your
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 21:02 ---
Another slight variation:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
contains
subrou
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-05-17 20:51
---
We have complete control of whether to print the negative sign with
-fno-sign-zero. I am tempted to say this is a no-never-mind situation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
--- Comment #4 from potswa at mac dot com 2010-05-17 20:44 ---
The crash may have something to do with using a dependent type in a particular
context. This shorter code still crashes despite resolution failing no
recursion
#include
template< int x >
typename std::enable_if< x*0 >::
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-17 20:39 ---
I can confirm the issue with GCC 4.3.4, 4.4.4, and 4.5.0; however, using 4.6 it
works. I think the ICE has been fixed by the recent constructor work by Daniel.
Thus, one solution is to close the bug as WONTFIX; altern
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 20:35 ---
(In reply to comment #7)
> If one adds "b = ALLOCATED(x)" one finds:
Where do you add this? I don't see a test case where this fits into. Can you
give a complete example?
Btw, after the recent patch for PR43969, this
--- Comment #15 from iains at gcc dot gnu dot org 2010-05-17 20:31 ---
the libgomp fails with comment #14 are pretty much:
/i686-apple-darwin9/./libgomp/.libs:/Volumes/ScratchCS/gcc-4-6-trunk-build/gcc
atomic-4.exe(94763) malloc: *** error for object 0x800180: pointer being
reallocated w
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-17 20:31 ---
BTW, one should consider elimination of the ...
troutmask:sgk[210] gfc4x -o z -Wall -std=f95 t.f90
t.f90:1.13:
real foo(2) /2*0.0/
1
Error: Extension: Old-style initialization at (1)
t.f90:2.4:
from one
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-17 20:29 ---
Given this code
real foo(2) /2*0.0/
data foo/0.0, 0.0/
print *, foo
end
Trunk compiles the code. Gfortran 4.5 has the ICE.
troutmask:sgk[211] gfc4x -o z -Wall t.f90
troutmask:sgk[212] ./z
0.000
--- Comment #8 from ro at gcc dot gnu dot org 2010-05-17 20:29 ---
Subject: Bug 44074
Author: ro
Date: Mon May 17 20:28:56 2010
New Revision: 159512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159512
Log:
PR target/44074
* configure.ac (HAVE_AS_IX86_REP_LOCK_P
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-17 20:24 ---
A little more debugging. I traced through the true_dependence call that is
returning 0 when it should return 1.
We end up calling rtx_refs_may_alias_p at the end. This calls
refs_may_alias_p_1, which calls indirect
--- Comment #7 from burnus at gcc dot gnu dot org 2010-05-17 20:22 ---
Propagate comment from PR 43990:
There seems to be an inconsistency with CLASS with POINTER
or ALLOCATABLE attribute: Is "class.$DATA" or "class" the pointer variable. If
one adds "b = ALLOCATED(x)" one finds:
x.a
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-17 20:22 ---
Created an attachment (id=20688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20688&action=view)
Work-In-Progress...
here is a modification of comment #7 which gets us a bit further .. but I'm a
bit stumped in
System info: uname -a
CYGWIN_NT-5.1 harryr-pc 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
gfortran -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure
--srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/s
--- Comment #9 from pdimov at gmail dot com 2010-05-17 20:12 ---
But the standard says in [basic.types] that "For any trivially copyable type T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes
--- Comment #3 from potswa at mac dot com 2010-05-17 20:10 ---
Created an attachment (id=20687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20687&action=view)
recursive decltype crashes g++
fix minor error (no change in behavior)
--
potswa at mac dot com changed:
--- Comment #9 from pedzsan at gmail dot com 2010-05-17 20:05 ---
The general reply to this was "your GCC was not compiled for your system".
That isn't the case. I have two compiles on two different systems. One if
version 4.5.0 and the other version is 4.3.1 compiled on AIX 5.3 TL05
--- Comment #9 from janus at gcc dot gnu dot org 2010-05-17 20:05 ---
Fixed with r159511. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 19:59 ---
Subject: Bug 43990
Author: janus
Date: Mon May 17 19:58:48 2010
New Revision: 159511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159511
Log:
2010-05-17 Janus Weil
PR fortran/43990
* tran
contrib/dg-cmp-results.sh contains several unportabilities:
* sort -s seems to be specific to GNU sort, neither POSIX.1 nor the vendor
tools
on Solaris 2, IRIX 6 or Tru64 UNIX have it.
* sed support for EREs (via -r or -E) isn't present on those platforms either.
--
Summary: dg-cm
--- Comment #1 from jason at gcc dot gnu dot org 2010-05-17 19:54 ---
Subject: Bug 44157
Author: jason
Date: Mon May 17 19:53:55 2010
New Revision: 159509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159509
Log:
PR c++/44157
* call.c (build_over_call): Limit in
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-17 19:54 ---
Subject: Bug 44158
Author: jason
Date: Mon May 17 19:53:45 2010
New Revision: 159508
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159508
Log:
PR c++/44158
* call.c (build_over_call): Don't do
--- Comment #6 from dodji at gcc dot gnu dot org 2010-05-17 19:45 ---
This should be fixed in trunk (4.6)
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-17 19:40
---
Many thanks. Let's add Jason in CC.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from potswa at mac dot com 2010-05-17 19:38 ---
Created an attachment (id=20686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20686&action=view)
recursive decltype crashes g++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
See attached testcase.
Several things can happen when decltype is used in a function template's return
type to refer to another specialization of the same template.
- The right thing (not easily produced from the current code, but see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162)
- Non-produ
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-17 19:29
---
DJ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
/* { dg-do compile } */
/* { dg-options "-O2 -fpic" { target fpic } } */
int f0 (int, int, int, int, int);
int f1 (void);
void
f2 (void)
{
unsigned v1, v2, v3, v4;
__asm__ ("" : "=a" (v1), "=d" (v2), "=c" (v3), "=r" (v4));
f0 (f1 (), f1 (), f1 (), f1 (), (v4 >> 8) & 0xff);
}
used to compile
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-05-17 19:17 ---
The first example I think does as there is no way to "transfer" the dynamic
type via the struct copy. The second one does not as the union still has a
field that is float and it is only unspecified behavior if you a
--- Comment #7 from pdimov at gmail dot com 2010-05-17 19:10 ---
(In reply to comment #6)
> Basically the middle-end sees this the same as
> int i = 1, j;
> float *p = new (&i) float(0.0);
> j = i;
> return *reinterpret_cast(&j);
> and you expect to return 0.0.
The int/float exa
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 18:53 ---
I don't think this can ever work except when you know 100% that the headers
don't need to be fix included. Only newer glibc don't need it and newlib
either. But the majority of the other OS's need it really.
--
/src/gcc-4.5.0/configure -verbose -disable-shared -enable-static -disable-bo
otstrap -disable-fixincludes -prefix=$HOME
/bin/sh /src/gcc-4.5.0/gcc/../move-if-change tmp-fixinc_list fixinc_list
echo timestamp > s-fixinc_list
make[2]: *** No rule to make target
`../build-i686-pc-linux-gnu/fixinclu
--- Comment #10 from siarhei dot siamashka at gmail dot com 2010-05-17
18:48 ---
Maybe I'm too impatient, but is there anything that prevents this patch from
getting committed to SVN?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
--- Comment #3 from zsojka at seznam dot cz 2010-05-17 18:45 ---
Stil appears in r159500, x86_64-linux.
Uninitialised read is at gcc/haifa-sched.c:1589, more exactly it is read of
BLOCK_FOR_INSN (insn)
When gcc/haifa-sched.c:1589 is changed to:
insn != NULL_RTX && (printf("%p %p\n", (v
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-17 18:32
---
Ok.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|U
--- Comment #7 from ro at gcc dot gnu dot org 2010-05-17 18:29 ---
Posted new patch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-17 18:28 ---
Consensus seems to be that this is indeed "how it's meant to work", but that
figuring out which are the externally visible functions and marking them
automatically would be a nice enhancement that would make the -fwhol
--
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 #10 from davek at gcc dot gnu dot org 2010-05-17 18:25 ---
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but as auto-export gets disabled i
--- Comment #2 from rmsalinas at uco dot es 2010-05-17 17:50 ---
Subject: Re: Compiling never ends
My god! you work really fast!
Yes, I've found the error just few seconds ago.
Great work!
dougsemler at gmail dot com escribió:
> --- Comment #1 from dougsemler at gmail dot com
--- Comment #1 from dougsemler at gmail dot com 2010-05-17 17:46 ---
This is the offender:
Node(const T& v,Node Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the *> (it should be the following, right?
Node(const T& v,Node* Tparent=NULL) {_parent=Tparent;_d
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 17:41 ---
(In reply to comment #6)
> but it does not fix PR43895 (see comments #3 and #4).
... which I take as an indication that the two are indeed not so much related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-17 17:34 ---
On branches/gcc-4_5-branch fixed by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-17 17:33 ---
The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
commit was actually for PR44102.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #26 from jakub at gcc dot gnu dot org 2010-05-17 17:31 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:30:54 2010
New Revision: 159500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159500
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
I was trying to create a tree. I have realized that the following code makes
the g++ compiler to never stop compilation.
#include
#include
#include
#include
using namespace std;
namespace gumocap{
namespace core{
namespace tree{
template
class Node: public vector< Node* >
{
public:
In testing patches to support Solaris 9/x86 with Sun as on Solaris 11/x86, I
noticed that several testcases with -gdwarf-2 -dA failed, producing invalid
assembler output. I could trace this down to dwarf2asm.c
(dw2_asm_output_nstring)
unconditionally emitting .ascii, which the Solaris 8/x86 as doe
--- Comment #25 from jakub at gcc dot gnu dot org 2010-05-17 17:26 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:26:22 2010
New Revision: 159499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-17 17:25 ---
Subject: Bug 44108
Author: jakub
Date: Mon May 17 17:24:32 2010
New Revision: 159497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159497
Log:
PR c++/44108
* decl.c (compute_array_index_type):
--- Comment #24 from jakub at gcc dot gnu dot org 2010-05-17 17:20 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:19:46 2010
New Revision: 159496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159496
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-17 17:18 ---
Subject: Bug 44102
Author: jakub
Date: Mon May 17 17:18:24 2010
New Revision: 159495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159495
Log:
PR middle-end/44102
* cfgcleanup.c (try_optimize_
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-17 17:09 ---
The patch in comment #5 fixes the ICE without side effects (AFAICT!-), but it
does not fix PR43895 (see comments #3 and #4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-17 17:02 ---
Yes, it certainly does, in fact it omits to compile any definition for 'foo'
whatsoever!
But isn't this the expected behaviour of using '-fwhole-program' on something
that is not the whole program? I'm not sure if th
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 16:34 ---
4.1.1 is no longer maintained. This doesn't cause an ICE with 4.4.3 or 4.5.0
pr44170.cc:29: error: specialization of 'VEXPR::~VEXPR() [with T =
VECTOR_PAIR]' after instantiation
--
redi at gcc dot gnu dot org chang
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-17 15:57 ---
Basically the middle-end sees this the same as
int i = 1, j;
float *p = new (&i) float(0.0);
j = i;
return *reinterpret_cast(&j);
and you expect to return 0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.c
The following code crashes the compiler with this message:
> g++ gccbug.cpp
gccbug.cpp: In destructor 'VEXPR::~VEXPR() [with T = VECTOR_PAIR]':
gccbug.cpp:32: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-17 15:50 ---
(In reply to comment #4)
> (In reply to comment #3)
> > The boost folks may be able to tell if they at any place copy a
> > function_buffer object via the assignment operator.
>
> It seems so. From Peter Dimov :
>
--- Comment #3 from gcc at breakpoint dot cc 2010-05-17 15:45 ---
Created an attachment (id=20685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20685&action=view)
rtl pass 186r.dce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #2 from gcc at breakpoint dot cc 2010-05-17 15:44 ---
Created an attachment (id=20684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20684&action=view)
rtl pass 185r.cprop_hardreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #1 from gcc at breakpoint dot cc 2010-05-17 15:44 ---
Created an attachment (id=20683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20683&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
libgomp testsuite fails with a segfault. It segfaults in
gomp_resolve_num_threads(), accessing the second TLS value.
The first access:
.LBB28:
.file 2 "../../../src/libgomp/libgomp.h"
.loc 2 380 0
bcl 20,31,$+8
.long _GLOBAL_OFFSET_TABLE_-$
mflr 9
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-05-17 14:28
---
The problem from comment #12 seems to be back.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
--- Comment #5 from redi at gcc dot gnu dot org 2010-05-17 14:03 ---
(In reply to comment #4)
>
> possibly a dup of bug 43382
actually I don't think it is a dup, because 43382 crashes with 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-17 14:00 ---
4.5 doesn't ICE
pr44167.cc: In function 'int main()':
pr44167.cc:7:44: sorry, unimplemented: use of 'type_pack_expansion' in template
pr44167.cc:41:35: error: no matching function for call to 'apply(int (&)(int,
double
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 13:55 ---
*** This bug has been marked as a duplicate of 44167 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from marc dot hofmann at gmail dot com 2010-05-17 13:55
---
Created an attachment (id=20682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20682&action=view)
Preprocessed file.
Created with:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
--
http://g
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-17 13:55 ---
*** Bug 44168 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
--- Comment #4 from dodji at gcc dot gnu dot org 2010-05-17 13:54 ---
Created an attachment (id=20681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20681&action=view)
Don't warn for integral constants
Jakub, this one line patch implements the first idea which is to not warn for
i
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preproce
--- Comment #1 from marc dot hofmann at gmail dot com 2010-05-17 13:51
---
Created an attachment (id=20680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20680&action=view)
Testcase source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preproce
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-05-17 13:49 ---
*** Bug 44166 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
1 - 100 of 135 matches
Mail list logo
