--- Additional Comments From chaac at nic dot fi 2005-05-10 08:00 ---
Andrew,
Here is a pointer to the mailing list:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
Topic started on May 08, 2005 with subject "WinAVR 20050214 (gcc 3.4.3) and
optimizer bug."
--
http://gcc.gnu.org/
--- Additional Comments From chaac at nic dot fi 2005-05-10 08:06 ---
In AVR's reading memory address 0 is valid thing though. In a way I can
understand why to optimization in x86 but shouldn't this be disabled by default
on AVR's?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=214
Is it just me or what?
===nested_defs.cpp===
template
struct A
{
typedef T value_type;
};
template
struct B : A
{
using typename A::value_type;
value_type x;
};
int main()
{
B b;
b.x = 0;
return 0;
}
===
[EMAIL PROTECTED] tmp]$ g++ -g -
--- Additional Comments From schlie at comcast dot net 2005-05-10 08:31
---
(In reply to comment #5)
> see comment #1 ...
>
> you already derefenced the pointer in ppv (in the line
> unsigned long lv = *lvp;
> )
>
> so the compiler assumes that anohter NULL ptr check is not n
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
08:32 ---
Subject: Bug 20788
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 08:31:50
Modified files:
libgfortran: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
08:35 ---
Subject: Bug 20788
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 08:34:58
Modified files:
libgfortran: ChangeLog
libgfortran/io : r
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10
08:36 ---
This one is fixed. Thanks for the bug report!
--
What|Removed |Added
Status|NE
--- Additional Comments From chaac at nic dot fi 2005-05-10 08:41 ---
Sorry about wrong mailing list pointer :)
http://lists.gnu.org/archive/html/avr-gcc-list/2005-05/index.html
Here is correct URL :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
I've found a major performance regression in gcc 4.0.0's optimization of the
BYTEmark numsort benchmark. I've boiled it down to a testcase that I think will
suit you... it outputs a single number representing the number of iterations run
(higher is better). On my machine I get 900ish under 4.0.0
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-10
09:05 ---
Created an attachment (id=8851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8851&action=view)
Test case (preprocessed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-10
09:10 ---
Oops, I should add that my pertinent options were: -O3 -fomit-frame-pointer
-march=athlon-xp -static
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
09:14 ---
Confirmed on x86 (with and without frame pointer) and on amd64.
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-10
09:27 ---
mainline drops even lower - looks like poor choice of addressing modes and thus
more register pressure for 4.0 and 4.1. Note that using profile-feedback
improves numbers a lot (but still we regress).
--
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
09:42 ---
Thanks Paolo!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
09:45 ---
Jason: thanks for this! Even better would be to let the testcase do a fixed
number of iterations (like 1000 or so), and then we'll be using "time"
externally to measure performance. Maybe you can do this fo
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
09:46 ---
This is the function (reindented) where we spend almost all of our time:
void
NumSift (long *array, unsigned long i, unsigned long j)
{
unsigned long k;
long temp;
while ((i + i) <= j)
{
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
09:50 ---
If Richard is right in comment #4, it would be interesting to see what
happens if one tries this with Zdenek's TARGET_MEM_REF patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
10:22 ---
On AMD64 with GCC 4.0.1 (CVS 4.0 branch) I go from ~580 at -O3
to ~930 at -O3 -fno-tree-pre.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10
10:26 ---
Confirmed. Library does not use this APPEND parameter.
Patch here: http://gcc.gnu.org/ml/fortran/2005-05/msg00095.html
--
What|Removed |Added
-
This simple source code:
#include
main()
{
char *p;
p+21;
return 1;
}
does NOT cause the gcc compiler to warn or signal any error. Pointer p remains
the same, before and after the 'strange' increment.
If the compiler does not signal anything about that, in a large source c
--- Additional Comments From schwab at suse dot de 2005-05-10 12:04 ---
$ gcc -Wall simple.c
simple.c:4: warning: return type defaults to ‘int’
simple.c: In function ‘main’:
simple.c:7: warning: statement with no effect
--
What|Removed |Added
---
what follows (version, command line, source and .ii) seems to be a bug.
if you need something else -> [EMAIL PROTECTED]
"bravo et merci quand même pour votre bon boulot !"
seb.
--Command lines : -
seb$ g++ --version
g++ (GCC) 3.3.6 (Debian 1:3.3.6-4)
Copyright (C) 2003 Free S
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
12:38 ---
Subject: Bug 21342
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 12:38:35
Modified files:
gcc: ChangeLog c-decl.c
gcc/tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
12:41 ---
Subject: Bug 21342
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 12:41:28
Modified files:
gcc: Change
---
void bar (unsigned int);
unsigned int
foo (void)
{
unsigned int i, j;
for (i = 1; i < 30; i++)
{
j = 2 + 3*i;
bar (j);
}
return j;
}
---
--> .optimized:
foo ()
{
unsigned intD.3
--- Additional Comments From drew dot johnson at andrew dot com 2005-05-10
12:57 ---
Subject: RE: optimized code seg faults due to double load on sparcV9
OK, I see your point. Sorry for inconvenience. I see that the status
in bugzilla has been updated accordingly. Is there anything
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-10
12:58 ---
Looks like a register pressure problem... but yes, TARGET_MEM_REF may help as
well.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
13:12 ---
This is how C++ works, you can actually fall through case statements. This is
invalid code and G++
rejects it correctly.
--
What|Removed |Added
---
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
13:16 ---
So what about this, in C:
---
struct A
{
int a;
};
struct B
{
struct A sa;
int b;
};
void foo1(void* ptr)
{
((struct A*)ptr)->a = 0;
}
void foo2(void* ptr)
{
((struct
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
13:17 ---
Ehm, bar should obviously be:
---
void bar(void)
{
struct B sb;
foo1(&sb);
foo1(&sb.sa);
foo2(&sb);
foo2(&sb.sa);
}
---
that is, I'm trying
/memtrack.o
+===GNAT BUG DETECTED==+
| 3.4.4 20050510 (prerelease) (ia64-suse-linux-gnu) GCC error: |
| in fixup_var_refs_1, at function.c:1876 |
| Error detected at a-exexda.adb:252:65
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
13:24 ---
Subject: Bug 21436
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 13:23:40
Modified files:
libjava: ChangeLog
libjava/testsuite/
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
13:29 ---
Actually, GCC 4.0 has this problem also.
GCC 3.3:
foo:
pushq %rbp
movl$1, %ebp
pushq %rbx
movl$5, %ebx
subq$8, %rsp
.p2align 4,,7
.L6
--
Bug 12536 depends on bug 19203, which changed state.
Bug 19203 Summary: [3.4/4.0 Regression] [DR 214] Partial ordering failure
between function reference and generic const reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
What|Old Value |New Value
--- Additional Comments From nathan at gcc dot gnu dot org 2005-05-10
13:29 ---
fixed on 4.0 branch
2005-05-10 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/20723
* pt.c (more_specialized_fn): Member functions are unordered wrt
non-members. Conversion operators ar
--
Bug 4672 depends on bug 19203, which changed state.
Bug 19203 Summary: [3.4/4.0 Regression] [DR 214] Partial ordering failure
between function reference and generic const reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
What|Old Value |New Value
--
Bug 15674 depends on bug 19203, which changed state.
Bug 19203 Summary: [3.4/4.0 Regression] [DR 214] Partial ordering failure
between function reference and generic const reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
What|Old Value |New Value
--- Additional Comments From schwab at suse dot de 2005-05-10 13:30 ---
Actually the command line was this:
stage1/xgcc -Bstage1/ -B/usr/local/ia64-suse-linux/bin/ -c -g -O2 -gnatpg
-gnata -g -O1 -fno-inline \
-I- -I. -Iada -I../../gcc/ada ../../gcc/ada/a-except.adb -o ada/a-ex
(From the Debian BTS):
-- fails in 3.15p, 3.4, and 4.0
-- RM 6.4.1(13)
-- RM 9.5.1(3)
-- RM 9.5.3(8)
with text_io; use text_io;
procedure Test_306834 is
type intp is access all integer;
i: aliased integer := 3;
x1: intp;
procedure p1(x: out intp) is
begin
null;
end;
pr
--
What|Removed |Added
BugsThisDependsOn||19038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21488
--
What|Removed |Added
Summary|Wrong code generated with -O|Wrong code generated for
|-fPIC |legal program, RM 6.4.1(13),
(From the Debian BTS):
procedure Test_306835 is
generic
type T1 is private;
package pak1 is
type T2 is array(1..10) of aliased T1;
end pak1;
type T3 (b: Boolean := False) is null record;
package new_pak1 is new pak1 (T1 => T3); --ERROR: T3 unconstrained
begin
null;
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
13:47 ---
Subject: Bug 17913
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 13:47:05
Modified files:
gcc: ChangeLog c-typeck.c fold-const.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
13:48 ---
Subject: Bug 19203
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 13:48:00
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
13:48 ---
Subject: Bug 20723
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 13:48:00
Modified files:
gcc/testsuite : Change
--- Additional Comments From loki at gcc dot gnu dot org 2005-05-10 13:50
---
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 13:47:05
Modified files:
gcc: ChangeLog c-typeck.c fold-const.c
gcc/testsuite : Cha
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-10
13:55 ---
Patch committed.
--
What|Removed |Added
Status|ASSIGNED|RESO
--
Bug 21418 depends on bug 21436, which changed state.
Bug 21436 Summary: imports not remembered for previously compiled files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21436
What|Old Value |New Value
-
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-10
14:14 ---
This is IVopts producing unresolvable overlapping live ranges again:
t.c.t56.cunroll:
foo ()
{
unsigned int pretmp.1;
unsigned int pretmp.0;
unsigned int j;
unsigned int i;
unsigned int D.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-10
14:24 ---
> OK, I see your point. Sorry for inconvenience. I see that the status
> in bugzilla has been updated accordingly. Is there anything else I
> should do to close this?
No, the status has already been se
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-10
14:29 ---
SPARC 32-bit:
opt-9.c: In function 'foo':
opt-9.c:7: error: unrecognizable insn:
(insn 8 6 9 1 (set (reg/f:SI 109)
(high:SI (const:SI (plus:SI (symbol_ref:SI ("s") [flags 0x58]
)
--- Additional Comments From sebmaestro at hotmail dot com 2005-05-10
14:37 ---
Subject: RE: new object affectation in a switch
So, I don't understand why :
switch (truc) {
case 0:
break;
case 1:
Thing *th;
th = new Thing();
break;
case 2:
break;
case 3:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
14:51 ---
(In reply to comment #4)
> void foo1(void* ptr)
> {
> ((struct A*)ptr)->a = 0;
> }
Because you just violated C aliasing. This is unlike C++ where upcasting is
okay.
--
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
14:51 ---
(In reply to comment #2)
> Subject: RE: new object affectation in a switch
>
> So, I don't understand why :
...
> is OK for g++.
Because there is no initialization of a variable in the declaration.
>
The following is invalid C++ and should be rejected:
struct Thing {
Thing(){}
};
int f (int i)
{
switch (i)
{
case 1:
Thing *str = new Thing;
case 2:
case 3:
;
}
return 0;
}
Previous versions before 4.0.0 rejected with the following message:
t.cc:11: error: jump to case la
--- Additional Comments From joseph at codesourcery dot com 2005-05-10
14:59 ---
Subject: Re: [4.1 Regression] wrong code with
upcast in C++
On Tue, 10 May 2005, giovannibajo at libero dot it wrote:
> So what about this, in C:
Seems valid to me. "A pointer to a structure object, su
--
What|Removed |Added
Target Milestone|--- |4.0.1
Version|unknown |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21491
// { dg-do compile }
// { dg-options "-Os -fPIC" }
extern char *bar (const char *, const char *);
extern char *baz (char *, const char *);
extern unsigned int fn (const char *);
static const struct C { int i; } k = { 0};
struct S
{
S (const C &x, unsigned int *y) : a (x), b (y) {}
const C &a;
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-10
15:09 ---
And this would still work with the code i've written, because it's at offset 0
(which is why it's valid in C).
It would have worked before the fix, too.
It's only when you cast back *down* to the derived c
--- Additional Comments From mark at codesourcery dot com 2005-05-10 15:20
---
Subject: Re: [3.4 regression] Infinite memory
allocation on -O3
schwab at suse dot de wrote:
> --- Additional Comments From schwab at suse dot de 2005-05-10 13:23
> ---
> This is causing a regress
I cannot compile VTK using gcc 4.1.0 (at least the one shipped in gcc-snapshot).
Step to reproduce (on debian testing system):
1. sudo apt-get install gcc-snapshot (as of today)
2. Get VTK source (CVS)
3. Compile line is:
/usr/lib/gcc-snapshot/bin/g++ -save-temps -o vtkLargeInteger.o
-DvtkCommon
--- Additional Comments From mmalater at nycap dot rr dot com 2005-05-10
15:25 ---
$ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (GCC) 4.1.0 20050508 (experimental)
Copyright (C) 2005 Free Sof
--- Additional Comments From mmalater at nycap dot rr dot com 2005-05-10
15:27 ---
Created an attachment (id=8852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8852&action=view)
/usr/lib/gcc-snapshot/bin/g++ -save-temps ...
Adding save-temps
--
http://gcc.gnu.org/bugzilla/sho
Instead of
namespace __gnu_cxx
{
namespace detail
{
}
}
would like to experiment with the form
namespace __gnu_cxx::detail
{
}
See N1524 from pre-Kona. Will attach for reference
--
Summary: condensed nested namespaces
Product: gcc
Version: 4.1.0
S
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-10 15:44
---
Created an attachment (id=8853)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8853&action=view)
proposal
At Kona, this seemed uncontraversial.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
15:48 ---
In my example, B is a (sort-of) derived class and A is a (sort-of) base class.
The C++ frontend should use a subobject at offset 0 to represent the base
class. When you downcast through dynamic_cast, you ar
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10
15:51 ---
Yes, there is a bug with reshape and complex numbers (PR21127). It should be
fixed soon (a patch has been proposed).
*** This bug has been marked as a duplicate of 21127 ***
--
What|Remov
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-10
15:51 ---
*** Bug 21480 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
The following code segfaults g++
class A {
extern
void* copy ( void* p ) {
return( p );
}
};
My settings are
gcc> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/pkg/gcc-4.0.0/usr
Thread model: posix
gcc version 4.0.0
--
--- Additional Comments From giovannibajo at libero dot it 2005-05-10
16:01 ---
In fact, the salias dump for the C++ testcase says:
---
;; Function void bar() (_Z3barv)
structure field tag SFT.2 created for var sb offset 0 siz
http://gcc.gnu.org/ml/libstdc++/2005-05/msg00098.html
In general, what happens is that current negative compile tests have different
line numbers and or message text, depending on various command line defines.
Ie, 23_containers/map/operators/1_neg.cc when run in normal mode (-g -O2) and in
debug
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-10
16:07 ---
Subject: Re: [4.1 Regression] wrong code with
downcast in C++
On Tue, 2005-05-10 at 16:01 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot i
seen on {i486,powerpc,amd64,ia64}-linux with 4.0 CVS 20050509, works with 3.4.4
and 4.1 CVS, works with -O1
preprocessed source taken from the libggi-2.0.5 source
$ gcc -save-temps -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include
-I/usr/include/glide -I/usr/include -I/usr/include/glide -g -Wall -O
--- Additional Comments From doko at debian dot org 2005-05-10 16:12
---
Created an attachment (id=8854)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8854&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21497
--
What|Removed |Added
CC||debian-gcc at lists dot
||debian dot org
Keywords|
The following code should be rejected, but is accepted by g++:
template < typename T >
class identity {
public:
typedef T me;
};
template < typename T >
class my_friend {
private:
friend class identity< T >::me;
char x;
};
class The_T {
public:
static
char & peek_friend ( my_fri
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:27 ---
*** This bug has been marked as a duplicate of 21293 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:27 ---
*** Bug 21497 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:31 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:35 ---
Your first example is valid code.
And the second.
And the third.
But the fourth is invalid code and ICC in strict mode also rejects it.
Confirmed, based on the first example, this comes down to using sema
--
What|Removed |Added
Keywords||missed-optimization
Known to fail||4.0.0 4.1.0
Known to work|
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-05-10
16:38 ---
As the bug reporter, I'm fine with that, although I can't really change the bug
to "VERIFIED" since I haven't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:41 ---
Fixed for 4.0.1.
--
What|Removed |Added
Status|UNCONFIRMED |RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:41 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
16:57 ---
Here is the backtrace:
#0 compare_values (val1=0x0, val2=0xb7bf1a08) at
/home/peshtigo/pinskia/src/gnu/gcc/src/gcc/
tree-vrp.c:300
#1 0x084db1ae in extract_range_from_unary_expr (vr=0xbfe9b994, expr=0xb69
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:02 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
CC|dberlin at gcc dot gnu dot |dnovillo at gcc dot gnu dot
|org |org
http://gcc.gnu.org/bugzilla/s
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:20 ---
Confirmed, reduced testcase:
class vtkLargeInteger
{
vtkLargeInteger& operator<<=(int n);
vtkLargeInteger& operator>>=(int n);
};
vtkLargeInteger& vtkLargeInteger::operator<<=(int n)
{
int i;
if (n
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:28 ---
Is this fixed now?
--
What|Removed |Added
Keywords||bu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:32 ---
*** This bug has been marked as a duplicate of 21173 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:32 ---
*** Bug 21482 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:36 ---
*** Bug 21483 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:36 ---
*** This bug has been marked as a duplicate of 19699 ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
The following code doesn't emit an error:
class Curious {
public:
static const float c5 = 7.0;
};
The above code is illegal according to the following references. The compiler
does not emit an error (instead the error is caught at link-time if the member
consta
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:42 ---
*** Bug 21484 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:42 ---
And I was right, there was a bug about this already, see PR 14258 which I am
going to mark this bug as
a dup of.
*** This bug has been marked as a duplicate of 14258 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
17:44 ---
> It's a good idea to flag this error to avoid errors that are more difficult to
> catch at link-time. Apparently GCC does not require integral member constants
> to
> be defined, but it does require other
1 - 100 of 178 matches
Mail list logo
