given the following code:
int main(void) {
switch(0)
for(struct T {
void f() {
case 1: ;
}
};; );
}
/tmp % g++ test11.c++ -O4 -W -Wall -Wextra --pedantic
test11.c++: In member function 'void main()::T::f()':
test11.c++:5: internal compiler error: Se
gcc-4.3.1/gcc/makefile contains one very long line, via substitution of
gtfiles.
This is "inconvenient" and "annoying" but works.
I have a patch for it. It has been seen to work on Cygwin, but not work on
Linux. Waiting for Autoconf >=2.60 (currently using 2.59) will make this
easier, so maybe just
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #60 from bonzini at gnu dot org 2008-08-01 08:26 ---
There is no need for additional patches: a trunk bootstrap is now building gcc
stage2, so it's fixed there. I'll backport to 4.3 the patch from comment #36.
--
bonzini at gnu dot org changed:
What|Remov
--- Comment #2 from bonzini at gnu dot org 2008-08-01 08:44 ---
not really a duplicate
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from dodji at gcc dot gnu dot org 2008-08-01 08:54 ---
Created an attachment (id=15988)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15988&action=view)
first fix attempt.
This patch fixes the problem for me on gcc-4_3-branch.
Regtested for x86_64 on gcc-4_3-branch
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #3 from rwild at gcc dot gnu dot org 2008-08-01 09:05 ---
Have you tried configuring like this?
CONFIG_SHELL='C:/msys/1.0/bin/sh.exe' C:/msys/1.0/bin/sh.exe \
../gcc-4.3XX/configure [OPTIONS...]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503
--- Comment #6 from paolo dot carlini at oracle dot com 2008-08-01 09:07
---
Typo in dg-options: you mean c++0x
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
trunk binutils needs the sha1 implementation from libiberty, but it's not on
4.3 branch. does the rule that gcc files should override the corresponding src
files hold for release branches? if so, should i backport revision 133503 from
trunk to 4.3 branch? it is safe and only adds the relevant fi
--- Comment #7 from dodji at gcc dot gnu dot org 2008-08-01 09:33 ---
Created an attachment (id=15989)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15989&action=view)
fixed a typo.
Woops, thanks Paolo. I have Updated the patch.
--
dodji at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-01 09:37 ---
typedef struct {
unsigned char mbxCommand;
} MAILBOX_t;
void lpfc_sli_brdrestart(void)
{
volatile unsigned int word0;
MAILBOX_t *mb;
mb = (MAILBOX_t *) &word0;
mb->mbxCommand = 0x1A;
__writel((*(unsigne
--- Comment #61 from bonzini at gnu dot org 2008-08-01 09:52 ---
Subject: Bug 35752
Author: bonzini
Date: Fri Aug 1 09:51:03 2008
New Revision: 138504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138504
Log:
2008-08-01 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap
--- Comment #8 from bonzini at gnu dot org 2008-08-01 09:54 ---
backported
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from bonzini at gnu dot org 2008-08-01 09:55 ---
Subject: Bug 35542
Author: bonzini
Date: Fri Aug 1 09:54:04 2008
New Revision: 138505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138505
Log:
2008-08-01 Paolo Bonzini <[EMAIL PROTECTED]>
Backport from
When the program below is compiled with -O2, it goes into an endless loop.
#include
int main (void)
{
int mask;
for (mask = 0; (mask & 7) != 4; mask += 0x) {
printf ("%x\n", mask & 7);
}
}
The output of gcc -v is
Using built-in specs.
Target: i486-linux-gnu
Configured with: .
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-01 10:08 ---
Could you provide a testcase that does not need -std=c++0x ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35852
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-01 10:22
---
If you just comment out the andnot(T&, T&&) overload, and compile without
-std=c++0x, I think the warnings at issue are all still there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35852
--- Comment #1 from schwab at suse dot de 2008-08-01 10:59 ---
This depends on undefined behaviour when mask + 0x overflows. Change
mask to unsigned to get defined behaviour.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 11:15 ---
Confirmed. Reduced testcase:
typedef float v4sf __attribute__ ((vector_size(16)));
typedef v4sf v4;
typedef union {
v4sf v[4][4];
} m4v4;
void skew3(const v4 _v, m4v4 *dV2_dv)
{
float *v = ((float *) &_v);
if
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 11:19 ---
Subject: Bug 36988
Author: rguenth
Date: Fri Aug 1 11:18:36 2008
New Revision: 138512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138512
Log:
2008-08-01 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-01 11:21 ---
After gimplification we have
D.1560 = {D.1558, D.1559, 0.0, 0.0};
dV2_dv->v[0][1] = D.1560;
D.1561 = dV2_dv->v[0][1];
dV2_dv->v[1][0] = D.1561;
but
dV2_dv->v[0][1] = D.1560
seems to be sti
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-01 11:22 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-01 11:36 ---
Actually the 4.4 ICE is different.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
__m64
_mm_add_si64 (__m64 __m1, __m64 __m2)
{
return (__m64) __builtin_ia32_paddq ((long long)__m1, (long long)__m2);
}
0x009d7b13 in tree_ssa_useless_type_conversion (expr=0x0)
at /space/rguenth
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-01 11:48 ---
GCC 3.3 accepts the code with
t.C: In function `int main()':
t.C:3: warning: unreachable code at beginning of switch statement
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-01 11:49 ---
gimplify_call_expr sets *expr_p to NULL_TREE on GS_ERROR. Setting it to
error_mark_node instead fixes the problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-08-01 11:55 ---
Thanks Jakub, Dodji for working on this. Some comments:
Some nits:
- the error message we give in this case is pretty poor. Here we have an
empty initializer, but the error message we get back is "void value not
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-01 11:58 ---
It's very (un-)useful that
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_move_epi64 (__m128i __A)
{
return _mm_set_epi64 ((__m64)0LL, _mm_movepi64_pi64 (__A));
}
i
--- Comment #1 from joseph at codesourcery dot com 2008-08-01 12:01 ---
Subject: Re: New: [4.3 Regression] cannot build combined
tree from 4.3 branch + trunk binutils
On Fri, 1 Aug 2008, bonzini at gnu dot org wrote:
> trunk binutils needs the sha1 implementation from libiberty, but
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-01 12:04 ---
Google leads me to VC++ reference which says "Moves the lower 64 bits of the
lower 64 bits of the result, zeroing the upper bits.
I guess inlining and type fixing messes this up very early.
--
http://gcc.gnu.or
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 12:06 ---
Btw, 4.3 generates
test:
.LFB518:
movhps .LC0(%rip), %xmm0
ret
Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611. And current trunk.
So ... why are you exactly complaining about the code generate
--- Comment #1 from jakub at gcc dot gnu dot org 2008-08-01 12:45 ---
Created an attachment (id=15990)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15990&action=view)
gcc44-pr36904.patch
Partial fix, which fixes the testcase from this PR, but still other cases
in the made up test
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-01 12:53 ---
(In reply to comment #2)
> Google leads me to VC++ reference which says "Moves the lower 64 bits of the
> lower 64 bits of the result, zeroing the upper bits.
>
> I guess inlining and type fixing messes this up very
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-01 12:55 ---
(In reply to comment #3)
> Btw, 4.3 generates
>
> test:
> .LFB518:
> movhps .LC0(%rip), %xmm0
> ret
>
> Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611. And current trunk.
It should be
movq %x
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-01 13:08 ---
Looking into this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-01 13:14 ---
Subject: Bug 36997
Author: rguenth
Date: Fri Aug 1 13:12:38 2008
New Revision: 138515
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138515
Log:
2008-08-01 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 13:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-08-01 13:21 ---
with -march=core2 it uses
movd%xmm0, %rax
movq%rax, %xmm0
with -march=opteron (and -march=generic) it uses
movhps .LC0(%rip), %xmm0
ISTR there is some penalty for using movq on op
--- Comment #7 from hjl dot tools at gmail dot com 2008-08-01 13:25 ---
(In reply to comment #6)
> with -march=core2 it uses
>
> movd%xmm0, %rax
> movq%rax, %xmm0
>
Even this isn't necessary. We should just use
movq %xmm0,%xmm0
> with -march=opteron (and -marc
. -Iada
-I/home/eric/svn/gcc-4_3-branch/gcc/ada
/home/eric/svn/gcc-4_3-branch/gcc/ada/uname.adb -o ada/uname.o
+===GNAT BUG DETECTED==+
| 4.3.2 20080801 (prerelease) [gcc-4_3-branch revision 138516]
(i586-suse-linux-gnu) GCC error:|
| in
--- Comment #9 from dodji at gcc dot gnu dot org 2008-08-01 13:32 ---
Created an attachment (id=15991)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15991&action=view)
updated patch
> - the error message we give in this case is pretty poor. Here we have an
>empty initializer, but
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-01 13:55 ---
Missing tree_to_gimple_tuple call in gimplify_init_constructor when want_value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36991
--- Comment #10 from dgregor at gcc dot gnu dot org 2008-08-01 14:05
---
(In reply to comment #9)
> > - the error message we give in this case is pretty poor. Here we have an
> >empty initializer, but the error message we get back is "void value not
> >ignored
> >as it ought to be", w
The following example program produces several unwarranted "declaration ...
does not declare anything" warnings. This problem is also present in gcc 4.3,
since this is when the warning was introduced.
File /tmp/warning.cc:
class C1 {
public: class C2 { };
};
void cf1 (class C1::C2, void*); //
--- Comment #2 from ro at gcc dot gnu dot org 2008-08-01 14:27 ---
Jan,
unfortunately, I haven't heard back from you yet. Any chance to get this fixed
reasonably soon?
Rainer
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
--
shyam_77_2000 at yahoo dot com changed:
What|Removed |Added
CC||shyam_77_2000 at yahoo dot
|
[I can't decide if this should be reported against gcc or classpath. Apologies
if I got it wrong.]
My gcc build is failing when gen-classlist.sh is invoked, in two places:
First place:
top_builddir=..
top_srcdir=../../../../../../gcc-4.2.4/libjava/classpath /bin/sh
./gen-classlist.sh st
--- Comment #1 from jakub at gcc dot gnu dot org 2008-08-01 15:10 ---
Weird, I've bootstrapped/regtested 4.3 branch this morning, including ada, on
{i?86,x86_64,ppc,ppc64}-linux just fine, r138443, so the dwarf2out.c changes
were in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36971
--- Comment #1 from brian at dessent dot net 2008-08-01 15:19 ---
Subject: Re: New: gen-classlist.sh uses unrecognized
'test' arguments
Using /bin/sh with Solaris is documented to fail:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
Have you tried setting CONFIG_SHELL as sug
--- Comment #2 from deisner at gmail dot com 2008-08-01 15:22 ---
(In reply to comment #1)
> Have you tried setting CONFIG_SHELL as suggested?
Apologies, I did not see that. I'll try this next time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37000
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 16:06 ---
If you provide a preprocessed testcase maybe he can. Otherwise patches welcome
I guess.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from amylaar at gcc dot gnu dot org 2008-08-01 16:07
---
(In reply to comment #27)
> (In reply to comment #20)
>
> Ian proposed handling the simple case in which the two constructors ("clones")
> are identical by emitting the code only once, but labelling it with the
>
--- Comment #2 from jakub at gcc dot gnu dot org 2008-08-01 16:13 ---
I've managed to reproduce it, only happens with -mtune=i586 apparently.
Without my patch GCC doesn't ICE, just creates bad unwind info.
In *.greg dump we have (in uname__uname_lt):
(insn:HI 10 9 11 3 uname.adb:615 (par
--- Comment #4 from ro at gcc dot gnu dot org 2008-08-01 16:22 ---
Created an attachment (id=15992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15992&action=view)
preprocessed libstdc++-v3/src/strstream.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2008-08-01
16:24 ---
Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64
UNIX
rguenth at gcc dot gnu dot org writes:
> If you provide a preprocessed testcase maybe he can. Otherwise patches
> welcome
Wireshark's Buildbot system recently uncovered what appears to be a bug in gcc.
The following code:
static guinttap_current=0;
[ ... ]
fprintf(stderr, "dissect_bssmap tap_current: %u\n", tap_current);
produces the following output:
dissect_bssmap tap_current: 28019966
--- Comment #1 from gerald at wireshark dot org 2008-08-01 16:31 ---
Created an attachment (id=15993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15993&action=view)
Add debugging printfs to epan/dissectors/packet-gsm_a.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37001
[EMAIL PROTECTED] gcc]$ cat /tmp/x.c
#include
void
foo (int x, int y, int z)
{
printf ("hello\n");
}
int
main ()
{
foo (3000, 3303, -193);
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -mforce-drap -mstackrealign /tmp/x.c -g
[EMAIL PROTECTED] gcc]$ /usr/bin/gdb a.out
GNU gdb Fedora (6.8-12.fc9
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-01 16:50 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00080.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-01 17:23 ---
GCC 4.1 is no longer maintained, please try a newer version and provide a
smaller testcase (we are _not_ downloading software and debugging it - this
is the obligation of the application developer).
--
http://gc
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-01 17:24 ---
Just as a hint - as this is a static symbol you may want to use a gdb
watchpoint to see what changes it. Just do
gdb> watch tap_current
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37001
gcc-4.2.2 seems to generating wrong/misaligned code for movapd.
I have used the same test case mentione here (for almost the similar bug)
http://gcc.gnu.org/bugzilla/attachment.cgi?id=6012
The relavent information about the version and the files are as follows:
The version of gcc:
gcc -v
Using
--- Comment #1 from gkumar007 at gmail dot com 2008-08-01 17:35 ---
Created an attachment (id=15994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15994&action=view)
the test case exhibiting the wrong code generation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37003
--- Comment #2 from gkumar007 at gmail dot com 2008-08-01 17:36 ---
Created an attachment (id=15995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15995&action=view)
the generated assmebly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37003
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-01 17:54 ---
To be honest, I am not sure what deserves a warning and what not in this
testcase.
FOO is 19, ~FOO is -20. Therefore
ushort x = ~FOO seems to deserve a warning (with -Wsing-conversion at least).
x = x & -20 is handle
--- Comment #11 from dodji at gcc dot gnu dot org 2008-08-01 17:54 ---
Doug, thanks for your comments.
I have submitted the patch to the list
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00082.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-01 18:59 ---
Subject: Bug 36991
Author: jakub
Date: Fri Aug 1 18:58:24 2008
New Revision: 138529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138529
Log:
PR tree-optimization/36991
* gimplify.c (gimplify
--- Comment #9 from jakub at gcc dot gnu dot org 2008-08-01 19:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from jakub at gcc dot gnu dot org 2008-08-01 19:02 ---
Subject: Bug 36991
Author: jakub
Date: Fri Aug 1 19:01:33 2008
New Revision: 138530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138530
Log:
2008-08-01 Jakub Jelinek <[EMAIL PROTECTED]>
PR tree-
--- Comment #4 from gerald at wireshark dot org 2008-08-01 19:05 ---
I am "the application developer" and I've done my job. I'm asking you why gcc
isn't setting a variable to 0 when we've explicitly told it to do so.
Watching tap_current gives me the following:
GNU gdb 6.6-debian
Copyri
--- Comment #8 from ubizjak at gmail dot com 2008-08-01 19:32 ---
(In reply to comment #7)
> But it isn't necessary at all. We should use
>
> movq %xmm0,%xmm0
It looks to me that we should add:
[(set (match_operand:V2DI 0 "register_operand" "=x")
(vec_concat:V2DI
This comes from PR 34389 and it only fails in C++. There is already a testcase:
trunk/gcc/testsuite/g++.dg/warn/Wconversion-pr34389.C
short mask1(short x)
{
short y = 0x7fff;
return x & y; /* { dg-bogus "conversion" "conversion" { xfail *-*-* } 8 } */
}
In C, build_binary_op constructs:
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-01 19:36 ---
I created PR 37004 to cover the issue with C++ front-end. Apart from that, this
bug is FIXED in GCC 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from jason at gcc dot gnu dot org 2008-08-01 20:01 ---
Assuming that (set SP otherreg) resets args_size to 0 seems strictly better
than the current situation, and if it turns out to be wrong we ought to see
another crash like this one, so it seems fair to try. Otherwise w
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37003
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-01 20:15 ---
Well, that only hints at that the bss section is not cleared properly which
is the job of the kernel and/or the dynamic linker.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37001
Did not occur with SVN trunk revision 138315 as reported here
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02920.html
+===GNAT BUG DETECTED==+
| 4.4.0 20080801 (experimental) [trunk revision 138517]
(sparc-unknown-rtems4.9) GCC error:|
| in
--- Comment #10 from zhonghaij at yahoo dot com 2008-08-01 20:32 ---
Subject: Re: Segmentation fault from gfortran compilation
Based on my test, the new version will work.
Thanks
--- On Sun, 7/27/08, dfranke at gcc dot gnu dot org <[EMAIL PROTECTED]>
wrote:
> From: dfranke at gcc do
--- Comment #11 from dfranke at gcc dot gnu dot org 2008-08-01 21:36
---
Closing as WORKSFORME, Reporter can not reproduce the problem.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Hello
Gondoltad volna mennyi minden ingyen van az intereneten?
Ingyen sms , ingyen termékek?
Az oldalunk ezeket a helyeket foglalja össze.
Ha érdekel látogass el cimünkre
http://ingyenviheto.dy.hu/
Oldalunk nemtartalmaz semmilyen (e r o t i k u s) illetve (i l l e g á l i s)
tartalmat.
Üdv
Given the following snip:
template
struct A {
template
bool operator==(const A&) = delete;
operator bool () { return true; }
};
int main()
{
A a1;
A a2;
if(a1 == a2) {}
}
Compilation with g++44 -std=gnu++0x gives:
error: deleted function bool A::operator==(const A&) [with U = void, T
--- Comment #22 from sje at cup dot hp dot com 2008-08-01 23:28 ---
Maxim, have you had time to look at this bug? Given that it is generating bad
code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-01 23:33
---
Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Fortran benchmark gamess from SPEC CPU2006 fails to build with current mainline
on powerpc-linux with "-O2 -ftree-loop-linear" due to the following ICE:
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gfortran -c -O2
-ftree-loop-linear bug.f
bug.f: In function foo:
bug.f:1: internal compiler e
--- Comment #1 from janis at gcc dot gnu dot org 2008-08-02 01:07 ---
Oh good grief, this is a duplicate of 36922; sorry about that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37007
--- Comment #2 from chris dot fairles at gmail dot com 2008-08-02 02:11
---
Also note that the boolean conversion operators aren't required to get the
warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37006
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-02 03:49
---
*** This bug has been marked as a duplicate of 36922 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-02 03:49
---
*** Bug 37007 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from hjl at gcc dot gnu dot org 2008-08-02 04:52 ---
Subject: Bug 37002
Author: hjl
Date: Sat Aug 2 04:51:03 2008
New Revision: 138551
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138551
Log:
2008-08-01 H.J. Lu <[EMAIL PROTECTED]>
PR debug/37002
--
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 kkojima at gcc dot gnu dot org 2008-08-02 05:48 ---
For SH processors with FPU, 4.3 and 4.4 fail to bootstrap during
building libjava with:
../../../../../../ORIG/trunk/libjava/classpath/native/fdlibm/dtoa.c:885:
internal compiler error: in compute_barrier_args_size_
94 matches
Mail list logo
