--- Additional Comments From kazu at cs dot umass dot edu 2005-04-28 05:45
---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ka
program b
write(6,8000)
8000 format(72(1H!))
end
kargl[213] gfc41 -o b b.f
In file b.f:3
8000 format(72(1H!))
1
Error: Unexpected end of format string in forma
--- Additional Comments From bothner at gcc dot gnu dot org 2005-04-28
05:12 ---
Not sure what the right solution is.
We should be consistent as to whether definitions in
have line 0 and line 1, and it wasn't before my change.
One option is to fix gas.
Another if to suppress the # 0 li
--
What|Removed |Added
CC||mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18288
--- Additional Comments From eschenb at informatik dot uni-frankfurt dot de
2005-04-28 03:58 ---
Subject: Re: [4.0 only] segfault in INQUIRE asking
for SEQUENTIAL status
Was heißt hier Nutte, man muß ja sehen, wo man bleibt, da wird man ja wohl mal
quer durch dei Stadt rumhuren
--- Additional Comments From mrs at apple dot com 2005-04-28 03:48 ---
I can always reproduce this by touch zlib/configure && make all-target-zlib
The work around, would be to rm /*/config.cache
Also, I posted a patch for this in:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02836.html
--
Bug 20912 depends on bug 21089, which changed state.
Bug 21089 Summary: [4.0/4.1 Regression] C++ front-end does not "inline" the
static const double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
What|Old Value |New Value
--- Additional Comments From matz at suse dot de 2005-04-28 02:46 ---
Uhm, wait. Perhaps the optimization would be invalid for your changed example
from comment #5, but see below. But it will not be invalid for my initial
testcase,
where it missed to propagate 20.0 into setPosition.
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-28 02:34 ---
*** Bug 21248 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-04-28 02:34 ---
// reduced testcase, compile with -O1 -free-pre
template inline T klamp (T a, T l, T h)
{
return (a < l)? l : ((a > h)? h : a);
}
int foo (char);
int f (void)
{
float r;
return foo (klam
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:23 ---
Fixed on the mainline by:
2005-04-27 Sven de Marothy <[EMAIL PROTECTED]>
* java/nio/charset/Charset.java: Cached encoders shouldn't be static.
2005-04-27 Sven de Marothy <[EMAIL PROTECT
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:11 ---
(In reply to comment #2)
> In this case, I need to know whether there is a fucntion that I can use to
> check
> whether a mutex is currently locked.
That is a pthread question and not in anyway a bug in any
--
Bug 20912 depends on bug 21089, which changed state.
Bug 21089 Summary: [4.0/4.1 Regression] C++ front-end does not "inline" the
static const double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:09 ---
*** Bug 21089 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:09 ---
(In reply to comment #11)
> Is this optimization valid? Note that it will change the behavior of this c++
> program:
You are correct Chris, this was an invalid optimization.
This is a dup of bug 19320. T
--- Additional Comments From szehau at gmail dot com 2005-04-28 02:06
---
(In reply to comment #1)
> Do you have a testcase?
> On second thought pthreads and mutex lockes and signals are out of the scope
of a compiler, If this is
> a bug, this is a glibc bug but I really doubt it.
In t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:04 ---
*** Bug 15839 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:04 ---
Mark as a dup of bug 14404.
*** This bug has been marked as a duplicate of 14404 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:03 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|UNCO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:03 ---
*** Bug 13051 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:03 ---
Mark as a dup of bug 14404.
*** This bug has been marked as a duplicate of 14404 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
02:02 ---
reopening to
--
What|Removed |Added
Status|RESOLVED|UNC
Compiler gets a segfault if the following code is tried on gcc 3.4.3
the same works fine on gcc4.0 and mainline
static void foo ( int arg){
unsigned long long int __attribute__ ((aligned (4))) aligned_array[arg];
unsigned long long int *bak = aligned_array;
}
--
Summary: ICE on as
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
01:44 ---
(In reply to comment #4)
> However, as before, my approach depends on being able to place and share C++
> objects through shared memory. Its that still possible?
>
> Am I missing some esoteric compiler fl
--- Additional Comments From mronell at alumni dot upenn dot edu
2005-04-28 01:32 ---
"Plain Old Data" unfortunately is not a good solution in my case. I maintain
http://allocator.sourceforge.net which provides an open-source shared memory
allocator for the C++ Standard Template Library
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-28
01:15 ---
Confirmed.
The patch is OK for both mainline and the gcc-4.0 branch, assuming it passes the
regtest, in case anyone was waiting for approval.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
00:52 ---
On the mainline, (on x86) we use about 300 megs which is an improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
00:36 ---
Confirmed, in a way PR 20514 is related.
--
What|Removed |Added
Status|UNCONFIRM
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From pcarlini at suse dot de 2005-04-28 00:08
---
Ok, let's reopen the PR as "enhancement": actually, it's easy to produce a
testcase that leads to __secondChild growing beyond __len and the latter
can be equal to the biggest representable _Distance.
--
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-28 00:07
---
There are other SPEC CPU2000 comparison failures on powerpc64-linux
with "-m64 -O2 -fmodulo-sched" that resist attempts to minimize the
testcases. apsi has been failing since:
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-27
23:54 ---
Can someone comment on the status of this bug?
--
What|Removed |Added
CC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
21:49 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
21:47 ---
Subject: Bug 21159
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-27 21:47:31
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
21:41 ---
Subject: Bug 21159
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-27 21:41:15
Modified files:
gcc: ChangeLog c-typeck.c
gcc/tes
>
> Hello.
>
> I dont know if I am to write here, but I think I found a bug that I know
> is not related to my hardware or my system. Problem is that I don't know
> how to report it or if it allready been reported(Kind of hard to search
> for a bug when you dont know how to describe it.).
>
>
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
21:03 ---
Subject: Bug 11285
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-27 21:03:00
Modified files:
libjava: ChangeLog
libjava/gnu/java/n
Hello.
I dont know if I am to write here, but I think I found a bug that I know
is not related to my hardware or my system. Problem is that I don't know
how to report it or if it allready been reported(Kind of hard to search
for a bug when you dont know how to describe it.).
Backstory : I am a
--- Additional Comments From sje at cup dot hp dot com 2005-04-27 19:44
---
It looks like most of the compat tests have been fixed but I still get two
failures. They are tmpdir-gcc.dg-struct-layout-1/t002 and
tmpdir-gcc.dg-struct-layout-1/t027. I cut down t002 and wound up with
void *
--- Additional Comments From dnovillo at redhat dot com 2005-04-27 19:43
---
Subject: Re: New: Teach VRP to pick up a constant from case label.
On Wed, Apr 27, 2005 at 07:38:04PM -, kazu at cs dot umass dot edu wrote:
> I think Diego already knows about this, but I think it's wort
Consider:
void bar (void);
void
foo (int a)
{
switch (a)
{
case 4:
if (a >= 3
&& a <= 5)
bar ();
}
}
Note that we could remove the "if" statement, VRP does not catch this.
I think Diego already knows about this, but I think it's worth a PR so that
we don't
--- Additional Comments From pcarlini at suse dot de 2005-04-27 19:26
---
Please, either provide an analysis that the problem really happens, *given the
specific algorithm*, or provide a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
--- Additional Comments From pete_a90 at yahoo dot com 2005-04-27 19:09
---
I know there are no practical risks to this (heap isn't that popular and it's
practically impossible to allocate an array that large) but it won't work if
the user made a custom iterator with unsigned char as t
Consider the following program:
program f
integer i
loop: do i = 1, 5
print *, i
end do loop
loop: do i = 1, 5
print *, i
end do loop
end program f
Gfortran compiles the program and it executes both loops.
NAG's compiler claim
Gfortran is not checking if an assumed sized array is used correctly
in an array expression. Gfortran compiles the following without an
error or warning
subroutine e(a)
real, intent(out) :: a(*)
a = 1.e0
end subroutine
NAG's compiler issues
kargl[210] f95 -c e.f90
Error: e.f90, line 3: Inv
%R and %S should consider the special endianness of floaitng point registers,
and when they find an unexpected argument, they should emit an error rather
than abort.
--
Summary: %R and %S are not safe to use from asms
Product: gcc
Version: 4.1.0
Status
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27
18:16 ---
Patch commited to 4.0. Fixed.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
18:15 ---
Subject: Bug 20950
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-27 18:15:39
Modified files:
gcc/testsuite : Change
--- Additional Comments From blime at cox dot net 2005-04-27 17:58 ---
Subject: Re: Bounds Check
Sorry, I do not have a simple test case, but might be able to construct
one if part 1 is solved.
blime
pinskia at gcc dot gnu dot org wrote:
>--- Additional Comments From pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
17:44 ---
The tree level does not change with -funroll-loops.
--
What|Removed |Added
Componen
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
17:06 ---
For part 2: might be PR 19777, do you have a simple testcase which shows the
problem.
For part 1, I will file a seperate bug (later today) about the enhancing the
error message
--
What|Re
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-27
16:15 ---
This works for me (3.4.0, 3.4.1, 3.4.3), too.
I even downloaded Mandrake's versions (3.4.1 and 3.4.3).
No problem.
Can you reproduce the bug with the preprocessed file?
Are you sure that this is not a hard
The following C++, when compiled with g++-4.0.0, produces incorrect code when
compiled with -O1 -funroll-loops on both sparc-sun-solaris2.8 and i686-pc-linux-
gnu. This is a bare-bones simplification of real code from an application
using
the Boost.Spirit library. If compiled without -funroll-
Compiled with the bounds checker on and program terminated early with
the following message: "Fortran runtime error: Array reference out of bounds"
1. Need a clue of some kind, e.g., line number, array identity, etc.
2. G77 does not indicate an out of bounds.
--
Summary: Bounds Check
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-27
16:03 ---
This is a bug for the following reasons:
A] From the standard, we have:
12.3.1.1 Explicit interface
A procedure other than a statement function shall have an explicit interface if
..
(2) The procedure ha
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
16:03 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28
Modified files:
libstdc++-v3 : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
16:03 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28
Modified files:
libstdc++-v3 : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
15:59 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-27 15:59:09
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27
15:44 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
15:43 ---
Subject: Bug 21177
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-27 15:42:54
Modified files:
gcc/fortran: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
15:38 ---
Subject: Bug 21177
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-27 15:37:55
Modified files:
gcc/fortran: ChangeLog interface.c
gcc/te
--- Additional Comments From pcarlini at suse dot de 2005-04-27 15:01
---
(POD ("Plain Old Data") is a technical term, defined in the standard, basically
something you can copy bit by bit, via memcpy)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
--- Additional Comments From mronell at alumni dot upenn dot edu
2005-04-27 14:56 ---
I believe that the pointer points to a component within the vtable,
but I do not want to jump to that conclusion. When the object is
instantiated in shared memory, the first element seems to be a poin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
14:54 ---
*** Bug 21252 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
14:54 ---
On the mainline (and I think 4.0 also), we get:
mp4property.h:61: error: invalid pure specifier (only `= 0' is allowed) before
';' token
mp4property.h:77: error: invalid pure specifier (only `= 0' is allowe
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27
14:46 ---
Created an attachment (id=8756)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8756&action=view)
This preprocessed file causes an ice.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
14:42 ---
Can you please re-attach the preprocessed source and not encode the file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27
14:35 ---
Created an attachment (id=8755)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8755&action=view)
This preprocessed file causes an ice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
--
What|Removed |Added
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
I got the following ice:
/usr/local/bin/g++ -save-temps -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include
-Wall -O9 -march=athlon -MT atom_co64.lo -MD -MP -MF .deps/atom_co64.Tpo -c
atom_co64.cpp -fPIC -DPIC
In file included from mp4common.h:36,
from atom_co64.cpp:22:
mp4property.h
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27
14:28 ---
Subject: Bug 21171
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-27 14:28:12
Modified files:
gcc: ChangeLog tree-ssa-loop-ivopts.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
14:18 ---
Confirmed, I thought I saw something about this before, maybe it was on IRC or
on the mailing lists.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
14:03 ---
Are you talking about the vtable being at two different locations, well there
is no way since the struct is
a non-POD which means it cannot do many things with.
If you want to share data, try with a POD i
--
What|Removed |Added
GCC build triplet||i686-pc-linux-gnu
GCC host triplet||i686-pc-linux-gnu
GCC target triplet|
--- Additional Comments From rgrosseboerger at dspace dot de 2005-04-27
14:00 ---
Subject: RE: [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target
> -Original Message-
> From: gdr at integrable-solutions dot net
>
> Did you apply the patch?
>
> -- Gaby
No, Rog
Maybe there is something funny about your environment, like an
auto-mounted NFS src directory which got auto-unmounted during the build?
No, it's all local.
However ... it must have been some craziness left over from a previous
build, even though I did make distclean in srcdir and remove
I would like to use placement to instantiate a C++ object into a
shared memory segment and access that object from a second process.
When I test with an integer, the integer is accessible from the second
process. But when I instantiate a C++ class object, it seems a memory
pointer, which
--
What|Removed |Added
Summary|line number 0 for |[4.1 Regression] line number
|causes GAS to complain |0 for causes GAS
|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
13:41 ---
(In reply to comment #8)
> (In reply to comment #4)
> > There are both primary and secondary platforms among the AUTO_INC_DEC
> > targets.
> > So it is probably good to gain some wider test coverage about
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-27
13:37 ---
(In reply to comment #4)
> There are both primary and secondary platforms among the AUTO_INC_DEC
> targets.
> So it is probably good to gain some wider test coverage about the compile-
> time/run-time impa
--- Additional Comments From gdr at integrable-solutions dot net
2005-04-27 13:37 ---
Subject: Re: [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu
target
"rgrosseboerger at dspace dot de" <[EMAIL PROTECTED]> writes:
| The proposed patch fixes the reduced testcase and m
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-27
13:35 ---
ICE in gcc/expr.c:3087
emit_move_insn is called with y == NULL.
#0 emit_move_insn (x=0x42dbc170, y=0x0)
at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:3087
#1 0x081d2ddc in convert_modes (mode
--
What|Removed |Added
CC||bothner at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
13:32 ---
(In reply to comment #3)
> If =A is for using edx:eax in 32 bits mode, what is it doing exactly in 64
> bits
> then? rdx:rax?
Just rax.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:30
---
Thanks for the code, it's working.
The inline rdtsc code was from an IBM article; and after reading the GCC doc on
=A, I must admit I was expecting it to work on x86_64 too.
"ASpecifies the `a' or `d' regis
powerpc64-linux-gcc -c -o any-file.o any-file.S
results in
any-file.S: Assembler messages:
any-file.S:1: Warning: line numbers must be positive; line number 0 rejected
as the pre-processed file looks like
# 1 "any-file.S"
# 0 ""
# 1 ""
# 1 "any-file.S"
...
This regression is cau
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
13:25 ---
I cannot reproduce this on the mainline or "4.0.0 20050410", I will build a
4.0.0 release later today,
this might also be already fixed on the 4.0 branch too.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
13:11 ---
What do you mean, it is generating wrong code?
Actually you are using inline-asm wrong, try the following instead:
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
This com
--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:08
---
Created an attachment (id=8754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8754&action=view)
Small test program that exibits the problem.
The problem becomes more obvious when the program is compiled wi
The following inline assembly is generating correct code on x86 but not on
x86_64 (Counter is a uint64_t):
asm volatile ( "rdtsc" : "=A" (Counter) );
--
Summary: incorrect code generation for rdtsc on x86_64
Product: gcc
Version: 4.0.0
Status: UNCONFI
--- Additional Comments From pcarlini at suse dot de 2005-04-27 12:12
---
Thanks for the testcase. The issue is subtle and the typedef is only the tip of
the iceberg: num_get (involved in >>(int)) uses the caching facilities provided
by the primary numpunct, which a specialization simply
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
12:09 ---
This ICE is caused by more checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21241
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
12:06 ---
Do you have a testcase?
On second thought pthreads and mutex lockes and signals are out of the scope of
a compiler, If this is
a bug, this is a glibc bug but I really doubt it.
--
What|Rem
--- Additional Comments From giovannibajo at libero dot it 2005-04-27
11:40 ---
*** Bug 21246 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-04-27
11:40 ---
This is not a bug, the order of evaluation is unspecified.
Read about this here:
http://gcc.gnu.org/bugs.html
section "Increment/decrement operator (++/--) not working as expected"
*** This bug has been mark
--- Additional Comments From bduerner at gmx dot de 2005-04-27 11:33
---
This testcase gives the following error:
numpunct_test.cpp:106: instantiated from here
/usr/lib/gcc/i586-ark-linux/3.4.4/../../../../include/c++/3.4.4/bits/locale_facets.tcc:435:
error: no type named `__cache_
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pete at flooble dot net 2005-04-27 10:46
---
Created an attachment (id=8753)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8753&action=view)
preprocessed file (gzipped due to size - *.ii.gz) as required by bug-submit
guidelines
Note: gzipped due to unc
--- Additional Comments From pete at flooble dot net 2005-04-27 10:39
---
Created an attachment (id=8752)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8752&action=view)
Output as generated from command line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
1 - 100 of 121 matches
Mail list logo
