--- Comment #8 from hjl at lucon dot org 2005-12-08 07:32 ---
Revert
@@ -293,7 +292,7 @@ write_block (int length)
{
char *dest;
- if (!is_internal_unit() && current_unit->bytes_left < length)
+ if (current_unit->bytes_left < length)
{
generate_error (ERROR_EOR, NULL);
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-12-08 07:20
---
I am looking into this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
--- Comment #7 from hjl at lucon dot org 2005-12-08 06:55 ---
I have verified that
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00874.html
is the cause. Since gcc 4.1 and 4.2 are OK, the problem may be in the backport.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #2 from tausq at debian dot org 2005-12-08 05:26 ---
Some discussion about this PR is here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01563.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-08 03:36
---
Subject: Re: New: fill_n, generate_n assume Size is modifiable
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| I came across this while gathering background for my post in
| c++std-lib-16112. I
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-08 03:32
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| FWIW, I think Andrew makes a good point in comment #1. The algorithms really
| should
--- Comment #6 from hjl at lucon dot org 2005-12-08 03:30 ---
Gcc 4.0.3 20051113 is bad. So this regression was introduced between 2005
and 20051113.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #5 from hjl at lucon dot org 2005-12-08 03:28 ---
Gcc 4.0.3 2005 is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #4 from hjl at lucon dot org 2005-12-08 03:16 ---
Gcc 4.0.3 20051108 is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
I came across this while gathering background for my post in c++std-lib-16112.
I thgought I might as well let you know in case you think it's important enough
to worry about (Size is only required to be convertible to an integral type
which doesn't mean it needs to have the predecrement operator de
--- Comment #3 from hjl at lucon dot org 2005-12-08 02:11 ---
Gcc 4.0.3 20051103 is also OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #2 from hjl at lucon dot org 2005-12-08 02:04 ---
Gcc 4.0.3 20051007 is also OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #1 from hjl at lucon dot org 2005-12-08 01:56 ---
It looks like a regression. Gcc 4.0.2 20050912 works fine.
--
hjl at lucon dot org changed:
What|Removed |Added
--
--- Comment #80 from pinskia at gcc dot gnu dot org 2005-12-08 01:47
---
*** Bug 25303 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-08 01:47 ---
Then this is a dup of 323, closing as such.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from hjl at lucon dot org 2005-12-08 01:46 ---
-ffloat-store fixed eon for gcc 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
Gcc 4.0.3 20051207 miscompiles fma3d in SPEC CPU 2K when -O2 on i686 and
x86-64.
I got
Running Benchmarks
Running 191.fma3d ref base o2 default
Child returned with invalid return code(0)
*** Miscompare of fma3d.out, see
/export/spec/src/2000/spec/benchspec/CFP2000/191.fma3d/run/0002
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-08 00:49 ---
Can you try -ffloat-store or do the following:
On Linux/ix86 we use long double precision for evaluation of floating point
variables. This can lead to different values than the expected values. I'm
experimenting on t
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-12-08 00:27
---
This was fixed by the patch for PR19004.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pcarlini at suse dot de 2005-12-08 00:20 ---
(In reply to comment #7)
> FWIW, I think Andrew makes a good point in comment #1. The algorithms really
> should return the iterator, otherwise the caller may not be able to find out
> the state of the iterator after the al
--- Comment #7 from sebor at roguewave dot com 2005-12-08 00:08 ---
FWIW, I think Andrew makes a good point in comment #1. The algorithms really
should return the iterator, otherwise the caller may not be able to find out
the state of the iterator after the algorithm returns (e.g., when
--- Comment #6 from pcarlini at suse dot de 2005-12-08 00:01 ---
Agreed.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-07 23:42
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Related to PR 16505. This is the same issue as PR 16505.
|
| Can someone close t
--- Comment #4 from pcarlini at suse dot de 2005-12-07 23:39 ---
In any case, it's a bug. I'm only not sure whether, similarly to the story of
16505, we want to fix it and break user code relying on non standard conforming
behavior. I'm in favor of fixing this problem too, for 4.2 only o
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-12-07 22:31
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 22:26 ---
Related to PR 16505. This is the same issue as PR 16505.
Can someone close to the standard answer the question why did they change the
return type for these functions?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 22:23 ---
http://www.sgi.com/tech/stl/generate_n.html
http://www.sgi.com/tech/stl/fill_n.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 22:21 ---
Hmm, SGI's stl had them returning a value. This is really weird it changed
from returning a value to not to returning a value. Maybe this was a mistake
in the standard to do that or maybe libstdc++ is just wrong.
--- Comment #3 from hjl at lucon dot org 2005-12-07 21:49 ---
It could be. After adding -ffast-math to gcc 4.1, eon is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-12-07 21:23
---
Subject: Bug 19397
Author: reichelt
Date: Wed Dec 7 21:23:14 2005
New Revision: 108189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108189
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-07 21:23
---
Subject: Bug 19764
Author: reichelt
Date: Wed Dec 7 21:23:14 2005
New Revision: 108189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108189
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-12-07 21:23
---
Subject: Bug 19762
Author: reichelt
Date: Wed Dec 7 21:23:14 2005
New Revision: 108189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108189
Log:
PR c++/19397
* g++.dg/template/typedef3.C
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-12-07 21:20
---
Subject: Bug 19762
Author: reichelt
Date: Wed Dec 7 21:20:25 2005
New Revision: 108188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108188
Log:
PR c++/19397
* g++.dg/template/typedef3.C
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-12-07 21:20
---
Subject: Bug 19397
Author: reichelt
Date: Wed Dec 7 21:20:25 2005
New Revision: 108188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108188
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-12-07 21:20
---
Subject: Bug 19764
Author: reichelt
Date: Wed Dec 7 21:20:25 2005
New Revision: 108188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108188
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-12-07 21:16
---
Subject: Bug 19397
Author: reichelt
Date: Wed Dec 7 21:16:21 2005
New Revision: 108187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108187
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
--- Comment #10 from reichelt at gcc dot gnu dot org 2005-12-07 21:16
---
Subject: Bug 19762
Author: reichelt
Date: Wed Dec 7 21:16:21 2005
New Revision: 108187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108187
Log:
PR c++/19397
* g++.dg/template/typedef3.C
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-12-07 21:16
---
Subject: Bug 19764
Author: reichelt
Date: Wed Dec 7 21:16:21 2005
New Revision: 108187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108187
Log:
PR c++/19397
* g++.dg/template/typedef3.C:
Both template functions are required to return void.
$ cat u.cpp && g++ -c u.cpp
#include
template void std::fill_n (int*, int, const int&);
template void std::generate_n (int*, int, int (*)());
int main () { }
u.cpp:3: error: template-id 'fill_n<>' for 'void std::fill_n(int*, int, const
int&)'
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-07 21:05
---
Stupid me. Must have looked at the wrong branch.
Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25302
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 21:00 ---
Also I should note that it would fail the same way for 3.4, 3.3, and many older
compilers.
And if that is the case this is a dup of bug 323.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 20:59 ---
The last time I looked at eon failing on x86, it was due to excessive
precission for fp. Yes FP in an int test but what ever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25303
Gcc 4.0 20051113 and 4.120051207 miscompiled eon in SPEC CPU 2K with -O2. I got
Running Benchmarks
Running 252.eon ref base o2 default
*** Miscompare of pixels_out.kajiya, see
/export/spec/src/2000/spec/benchspec/CINT2000/252.eon/run/0002/pixels_out.kajiya.mis
x86-64 seems OK. Gcc 4.2 20051
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 20:58 ---
Fixed for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from joseph at codesourcery dot com 2005-12-07 20:54 ---
Subject: Re: New: gcc.dg/noncompile/920923-1.c needs fixing
On Wed, 7 Dec 2005, reichelt at gcc dot gnu dot org wrote:
> The comment on top of the testcase gcc.dg/noncompile/920923-1.c reads:
Not since:
2005-03
--- Comment #7 from dorit at il dot ibm dot com 2005-12-07 20:49 ---
(In reply to comment #6)
Can you test the attached patch?
Unfortunrately it's relative to autovect-branch, but hopefully it would easily
apply to mainline/4.1. Unbootstrapped, hardly tested...
Index: tree-vect-transfo
--- Comment #3 from reichelt at igpm dot rwth-aachen dot de 2005-12-07
20:47 ---
Subject: Re: [3.4 regression] ICE for sizofe of incomplete type
On 7 Dec, gdr at integrable-solutions dot net wrote:
> In general, there is a "type" problem in both C and C++ front ends.
> The documenta
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-07 20:40
---
Subject: Re: New: [3.4 regression] ICE for sizofe of incomplete type
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
| A reduced testcase is:
|
| ===
| typedef struct A B;
| int i = sizeof(B);
| ===
|
| bug.c:2: error: invalid applica
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-12-07 20:38
---
The PR for the testcase in the testsuite is PR 25302.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301
The comment on top of the testcase gcc.dg/noncompile/920923-1.c reads:
/* This test case contains a large number of syntactic errors. We
believe the intent of the test is that the compiler simply not
crash. The set of error messages reported is different when the C
parser is gen
The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
A reduced testcase is:
===
typedef struct A B;
int i = sizeof(B);
===
bug.c:2: error: invalid application of `sizeof' to incomplete type `
Internal compiler error: Error reporting ro
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |other
Summary|ld segmentation fault |[4.1/4.2 Regres
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 20:26 ---
>From the sound of it, AIX has the same issue. I have the simple fix but I
cannot test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25299
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 20:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
The testcase g++.dg/template/inherit.C causes an ICE on the 4.1 branch
and mainline:
=
template
struct X { void f() { } };
struct Z : X { };
int main()
{
Z z;
z.X::f(); // { dg-error ".*" "" }
}
The following source should compile on powerpc-darwin with no errors:
struct a { double a[2]; int i; };
struct b { double a; double b; int i; };
int g[sizeof(struct a) == sizeof(struct b)?1:-1];
But currently it does not because we don't take into account that the type of
the array.
--
--- Comment #2 from berndtrog at yahoo dot com 2005-12-07 19:55 ---
patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01887.html
--
berndtrog at yahoo dot com changed:
What|Removed |Added
-
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-12-07 19:44
---
Fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from reichelt at gcc dot gnu dot org 2005-12-07 19:43
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2005-12-07 19:42
---
Fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19762
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #4 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19764
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-07 19:40
---
Subject: Bug 19397
Author: reichelt
Date: Wed Dec 7 19:40:24 2005
New Revision: 108174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108174
Log:
PR c++/19397
PR c++/19762
PR c++/1
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-12-07 19:34
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-12-07 19:32
---
Subject: Bug 22618
Author: reichelt
Date: Wed Dec 7 19:32:17 2005
New Revision: 108173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108173
Log:
Backport:
2005-10-20 Mark Mitchell <[EM
--- Comment #20 from bkoz at gcc dot gnu dot org 2005-12-07 19:01 ---
> I have customers using Obj C++ who want to turn off C++
> exception support, but retain Obj C exception support. [snip]
What does this even mean? Can you detail or explain how this is supposed to
work?
> They are
--- Comment #10 from jakub at gcc dot gnu dot org 2005-12-07 18:27 ---
The stack is misaligned, though not at any call insn:
subl$2, %esp
movl40(%esp), %eax
pushl %eax
movl40(%esp), %eax
pushl %eax
movl40(%esp), %eax
--- Comment #3 from eweddington at cso dot atmel dot com 2005-12-07 18:24
---
Thanks for pointing this(In reply to comment #2)
> This is invalid C and in fact we removed the extension for 4.0.x.
> See http://gcc.gnu.org/gcc-4.0/changes.html
> And http://gcc.gnu.org/gcc-3.4/changes.html
--- Comment #9 from rth at gcc dot gnu dot org 2005-12-07 18:21 ---
Indeed we shouldn't be mis-aligning the stack pointer. And if you look at
the actual assembly, we aren't. Therefore the problem is bogus debug info.
I had been looking at this PR for a while, but got sidetracked. I s
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-12-07 18:18
---
[Thanks for the very detailed plan.]
> You can assign this to me, but I won't be able to get to this for the next
> week, so maybe I better have it assigned to me when I actually have time to
> work on this (in a
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 18:16 ---
This is invalid C and in fact we removed the extension for 4.0.x.
See http://gcc.gnu.org/gcc-4.0/changes.html
And http://gcc.gnu.org/gcc-3.4/changes.html
which talks about this extension.
--
pinskia at gcc dot gn
--- Comment #8 from jakub at gcc dot gnu dot org 2005-12-07 18:12 ---
I believe negative CFA offsets that aren't a multiple of 4 aren't representable
in DWARF 3, so either we'd have to lie in the unwind info, or we shouldn't
be misaligning the stack pointer ever.
--
http://gcc.gnu.o
--- Comment #1 from eweddington at cso dot atmel dot com 2005-12-07 18:01
---
Created an attachment (id=10438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10438&action=view)
Preprocessed test case.
Attaching a preprocessed testcase using 4.0.2.
--
http://gcc.gnu.org/bugzil
Compiling the source below with avr-gcc 4.0.2 gives an "invalid lvalue in
assignment":
--
#include
int main(void)
{
(unsigned char)DDRD |= (unsigned char)(1 << 7);
return 0;
}
--
The same code above builds fine for avr-gcc 3.4.3. The issue has to do with
--- Comment #2 from martinol at nrlssc dot navy dot mil 2005-12-07 17:37
---
I require a library that is not under my control to change (I have the source,
but am not the primary developer) and it was written using the SGI f77
compiler. I would like to see this construct added to gfort
--- Comment #9 from krebbel at gcc dot gnu dot org 2005-12-07 17:33 ---
(In reply to comment #8)
> Ok (not sure if it really is a good idea to make the *_operand names that
> long),
Mmmh you are right but I couldn't think of a better name that moment.
just I'm afraid ashrdi3_cc_64_and,
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-07 17:19 ---
Why can't you use the standard Fortran 90/95 derived types?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25297
>From an old SGI Fortran-77 Language Reference Manual:
"The RECORD statement creates a record in the format specified by a previously
declared STRUCTURE statement. The effect of a RECORD statement is comparable
to that of an ordinary type declaration."
"The STRUCTURE statement defines a record s
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-12-07 17:12
---
*** Bug 8262 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:12 ---
To close as a dup of bug 14557.
*** This bug has been marked as a duplicate of 14557 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:12 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-07 17:10 ---
*** Bug 20230 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-12-07 17:10
---
To close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-12-07 17:10
---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-07 17:09 ---
*** Bug 24727 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 2005-12-07 17:09 ---
To Close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
Reoepening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
*** Bug 25296 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-07 17:08 ---
To close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
*** Bug 19866 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Close as a dup of bug 16895.
*** This bug has been marked as a duplicate of 16895 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 17:07 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-07 17:06 ---
The warning is correct as the const "promotion" only applies to the outer most
type. so that const int * const is imcompatible with int *.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from jakub at gcc dot gnu dot org 2005-12-07 16:52 ---
Created an attachment (id=10437)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10437&action=view)
gcc41-pr25268.patch
Ok (not sure if it really is a good idea to make the *_operand names that
long), just I'm afr
--- Comment #4 from tobi at gcc dot gnu dot org 2005-12-07 16:49 ---
These all amount to the same problem. Being a bit more descriptive would also
make searching for duplicates easier.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 20859 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** This bug has been marked as a duplicate of 20857 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2005-12-07 16:47 ---
*** Bug 25074 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
1 - 100 of 148 matches
Mail list logo
