--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-03 09:08
---
(In reply to comment #0)
> I'm guessing that the latter was defined for compatibility with compilers like
> MSVC that would let you use the two synonymously.
Nope. In the code there is a comment mentioning Ann
I think this is a bug (and know it's annoying). Thanks for investigating.
In the libstdc++ included with gcc-4.2.6 (apparently also in trunk),
bits/ios_base.h defines two "open mode" types: std::ios_base::openmode is a
typedef of _Ios_Openmode, whereas std::ios_base::open_mode is a typedef of int.
The standard defines headers such as , , , etc. When using
std::tr1::array the developer must include . It seems like
this is not consistent with the standard which would indicate that is
the correct include path.
When writing a cross project for GCC / DevStudio the developer is forced to do
some
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-03 09:13 ---
The short testcase reproduces also on the trunk.
I see at least 3 problems with -fasynchronous-unwind-tables
-mno-accumulate-outgoing-args -fno-omit-frame-pointer:
1) expand_resx_expr doesn't do pending stack adjust:
-
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-03 09:17
---
This is known. At the right time we debated this issue and in fact some people
commented that probably TR1 (n1836) should have more conveniently specified
. In any case, also given the status of TR1 of technica
--- Comment #49 from paolo dot carlini at oracle dot com 2008-06-03 09:52
---
(In reply to comment #48)
> FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
> in the C++ front end:
FWIW, I find your suggestion very sensible and probably have already vaguely
hin
--- Comment #50 from rguenther at suse dot de 2008-06-03 10:00 ---
Subject: Re: exception_defines.h #defines try/catch
On Tue, 3 Jun 2008, paolo dot carlini at oracle dot com wrote:
> --- Comment #49 from paolo dot carlini at oracle dot com 2008-06-03
> 09:52 ---
> (In reply
--- Comment #51 from paolo dot carlini at oracle dot com 2008-06-03 10:03
---
(In reply to comment #50)
> Well, can't we simply remove the libstdc++ #defines then and declare
> libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?
>
> IMHO the libstdc++ #defines are
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-03 15:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
template struct A { int i; A() { i = *V; } };
template struct B { int i; B() { i = V; } };
int i;
A< &i > ai; //OK
B< i > bi; //OK
struct S { int j, k; } s;
A< &s.j > aj; //OK
B< s.j > bj; //ERROR
A< &s.k > ak; //ERROR
B< s.k > bk; //ERROR
int x[2];
A< &x[0] > a0; //OK
B< x[0] > b0; //ERROR
--- Comment #10 from phil at phord dot com 2008-06-03 16:26 ---
Gabriel's PDF can now be found here:
http://www-sop.inria.fr/galaad/personnel/gdr/C++/talks/type-of-toupper.pdf
All the other links referenced in this comment section are dead.
Quick fix from the PDF (in case it goes away
--- Comment #8 from sje at cup dot hp dot com 2008-06-03 17:59 ---
I looked at this bug and I can reproduce it using the precompiled archives from
the link. I have not tried to get the CERN sources to create a small 'real'
test case. I noticed that the bug does not happen on ToT and fo
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-06-03 18:30
---
OK, I know what is going on here.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-03 18:33
---
Thanks Tobias, that example threw me off course. Thats why I thought I had to
go read the standard again, because i had never seen an A0 before. :) I will
go ahead and fix this one while I am at it unless you a
struct Foo {
operator Foo & () { return *this; }
};
void frobnicate(Foo &) {
/* in reality, the Foo is changed here and returned */
}
int main () {
frobnicate (Foo());
}
temporary.cpp:8: error: invalid initialization of non-const reference of type
Foo& from a temporary of type Foo
temp
--- Comment #7 from patrick133t at yahoo dot com 2008-06-03 18:19 ---
I see this on AIX 5.3 also. I tracked it down by creating a simple program that
just does a #include and then saw that it worked when compiled as:
g++ -c -o bar.o bar.cc
However, it fails to compile when I do
g++ -
--- Comment #11 from sebor at roguewave dot com 2008-06-03 19:16 ---
(In reply to comment #10)
[...]
> Quick fix from the PDF (in case it goes away again):
> Provide a manual cast for toupper to explicitly declare "which toupper" we
> mean.
>
> std::transform(&s[0], &s[0] + 5, &s[0],
>
--
aaronavay62 at aaronwl dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #5 from aaronavay62 at aaronwl dot com 2008-06-03 19:32 ---
Apparently not related to PR35493, because its still present. I'll give
debugging this another shot later.
--
aaronavay62 at aaronwl dot com changed:
What|Removed |Added
-
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-06-03 19:57
---
> Apparently not related to PR35493, because its still present.
I think it's actually the same problem, the patch that has fixed it on other
platforms probably doesn't behave the same everywhere.
--
http://g
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2008-06-03 23:52
---
Fixed 4.4
Revision: 136344
Author: hutchinsonandy
Date: 7:46:07 PM, Tuesday, June 03, 2008
Message:
PR/34880
* gcc.c-torture/execute/float-floor.c: Adjust test for 4 byte doubles.
Modified : /trunk/gcc/t
While looking into a performance issue in 4.1.1 on PowerPC, I noticed that the
C++ front-end produces a NOP_EXPR for a vector type. This caused the following
performance testcase to fail:
/* { dg-do compile { target powerpc*-*-* } } */
/* { dg-options "-O2" } */
// We should not produce any addi
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-04 00:19 ---
Fix for this bug which I am testing right now:
Index: cp/cvt.c
==
=
--- cp/cvt.c(revision 2504)
+++ cp/cvt.c(working copy)
@@ -642,6 +642,9 @@
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-04 00:49
---
In reply to your question in 36421:
Where do you think one should modify in order to get g0 working (PR36420 /
F2008)?
We have to fix this in two places, fortran/io.c for compile time and, in the
case of a compu
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-04 01:57
---
Fixed 4.4.
Needs backport to 4.3 sometime.
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
---
According to gcc warnings, a pointer to int[] can be assigned the address of an
int[3], but not if the variable is a struct member:
int main() {
int array[3];
int (*ptr)[];
struct { int (*ptr)[]; } st;
ptr = &array; // fine
st.ptr = &array; // warning: assignment from inc
--- Comment #4 from sabre at nondot dot org 2008-06-04 03:21 ---
This would not be legal, there is no reason operator new can't return a pointer
that already exists in the program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #5 from xinliangli at gmail dot com 2008-06-04 04:15 ---
(In reply to comment #4)
> This would not be legal, there is no reason operator new can't return a
> pointer
> that already exists in the program.
>
This is certainly a flaw in the C++ standard (it requires p return
--- Comment #6 from sabre at nondot dot org 2008-06-04 04:32 ---
This has been extensively discussed on the C++ reflector. They decided
(informally, on the reflector) that people should be able to globally override
operator new to do logging, etc, which can make malloc have arbitrary si
--- Comment #7 from sabre at nondot dot org 2008-06-04 04:32 ---
That said, it would be fine to add support for this under a non-standards-mode
option of some sort of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #8 from xinliangli at gmail dot com 2008-06-04 04:46 ---
(In reply to comment #6)
> This has been extensively discussed on the C++ reflector. They decided
> (informally, on the reflector) that people should be able to globally override
> operator new to do logging, etc, whic
--- Comment #9 from sabre at nondot dot org 2008-06-04 04:48 ---
This isn't possible. The user can override operator new at the very last
minute: e.g. by interposing a shared object with LD_PRELOAD. There is no way
that a compiler or even LTO optimizing linker can know about this. A s
--- Comment #10 from xinliangli at gmail dot com 2008-06-04 05:23 ---
(In reply to comment #9)
> This isn't possible. The user can override operator new at the very last
> minute: e.g. by interposing a shared object with LD_PRELOAD. There is no way
> that a compiler or even LTO optimiz
--- Comment #11 from sabre at nondot dot org 2008-06-04 05:34 ---
Expecting people to modify their source is bad news.
LLVM's LTO does nothing for operator new, it treats it as any other external
function with undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #2 from firda at seznam dot cz 2008-06-04 06:31 ---
Can you help me, what is wrong? I'd like to verify it as resolved ;)
g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --ena
37 matches
Mail list logo
