--- 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
--- 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 #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 #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 #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
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 #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
--- 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 #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
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 #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:
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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);
101 - 148 of 148 matches
Mail list logo
