[Bug c++/36429] structure/array member reference/pointer as template argument
--- 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 --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
g++ xx.c
xx.c:9: error: template argument 1 is invalid
xx.c:9: error: invalid type in declaration before ; token
xx.c:10: error: s cannot appear in a constant-expression
xx.c:10: error: `.' cannot appear in a constant-expression
xx.c:10: error: template argument 1 is invalid
xx.c:10: error: invalid type in declaration before ; token
xx.c:11: error: template argument 1 is invalid
xx.c:11: error: invalid type in declaration before ; token
xx.c:12: error: s cannot appear in a constant-expression
xx.c:12: error: `.' cannot appear in a constant-expression
xx.c:12: error: template argument 1 is invalid
xx.c:12: error: invalid type in declaration before ; token
xx.c:15: error: template argument 1 is invalid
xx.c:15: error: invalid type in declaration before ; token
xx.c:16: error: x cannot appear in a constant-expression
xx.c:16: error: an array reference cannot appear in a constant-expression
xx.c:16: error: template argument 1 is invalid
xx.c:16: error: invalid type in declaration before ; token
xx.c:17: error: template argument 1 is invalid
xx.c:17: error: invalid type in declaration before ; token
xx.c:18: error: x cannot appear in a constant-expression
xx.c:18: error: an array reference cannot appear in a constant-expression
xx.c:18: error: template argument 1 is invalid
xx.c:18: error: invalid type in declaration before ; token
What I really want to do is this (static inside the struct solves my problem
just fine - also in 3.3.1):
extern struct Now {
/*static*/ volatile uint centi;
/*static*/ uint synced;
/*static*/ uint seconds; }
now;
template
class TTimer {
public:
TIME from;
public:
void start() {
from = NOW; }
TIME elapsed() {
return NOW - from; }
bool reached(TIME timeout) {
return NOW - from >= timeout; }};
typedef TTimer Timer;
typedef TTimerCsTimer;
typedef TTimer SecTimer;
(I use my own preprocessor, I do not write the code like that)
--
firda at seznam dot cz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36429
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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 optimizing linker can know about this. A special > non-standard compiler flag is required. > Then runtime override would be illegal (in theory) (if builtin operator is assumed), though the program may still run fine. so LLVM's LTO completely gives up when seeing operator new or there is a special flag? David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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 special non-standard compiler flag is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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, which can make malloc have arbitrary side > effects. > yes, things like saving pointers to user visible locations are bad. In this kind of situation, optimizer people's voice seems not loud enough :(. One way to solve this problem is to require user who override the default definition to always provide a declaration (before any use of operator new) -- if such declaration is not seen, the operator new will be treated as builtin (the default) implementation which has the nice property. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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 side effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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 returned from operator new to be different from previous calls to the operator unless the previous call's return is passed to operator delete -- but it does not require the pointer returned to be not pointing to any known location) -- and I do not see a reason this is intentional. For compiler optimization, it would better to assume the aggressive default, and provide an option to turn it off in case user provided definition violates the aliasing assumption. Someone in the language committee might need to bring this up. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
--- 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
[Bug c/36432] New: �incompatible pointer type� with pointer to array as a struct member
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 incompatible pointer type
}
--
Summary: Âincompatible pointer type with pointer to array as a
struct member
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anders at kaseorg dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432
[Bug testsuite/34889] gcc.c-torture/execute/builtins/pr23484-chk.c fails on 16 bit integer platforms
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34889
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- 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 computed or embedded string for the format, in libgfortran/io/format.c Patch is in the works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug c++/36431] The C++ front-end produces some NOP_EXPR for vector types
-- 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 |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36431
[Bug c++/36431] The C++ front-end produces some NOP_EXPR for vector types
--- 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 @@ ocp_convert (tree type, tree expr, int c
conversion. */
else if (TREE_CODE (type) == COMPLEX_TYPE)
return fold_if_not_in_template (convert_to_complex (type, e));
+ /* For vector data types, we need to produce a VIEW_CONVERT_EXPR. */
+ else if (TREE_CODE (type) == VECTOR_TYPE)
+ return fold_if_not_in_template (convert_to_vector (type, e));
else if (TREE_CODE (e) == TARGET_EXPR)
{
/* Don't build a NOP_EXPR of class type. Instead, change the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-06-04 00:19:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36431
[Bug c++/36431] New: The C++ front-end produces some NOP_EXPR for vector types
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 but instead use li for this function as
// the two address expressions should be done correctly.
/* { dg-final { scan-assembler-not "addi" } } */
#include
typedef vector float SIMD_Vector;
struct g
{
vector float l[2];
};
vector float f(const struct g &a, const struct g &a1)
{
SIMD_Vector g0 = vec_splat (a.l[1], 0);
SIMD_Vector g1 = vec_splat (a.l[1], 1);
SIMD_Vector g2 = vec_splat (a1.l[1], 1);
SIMD_Vector g3 = vec_splat (a1.l[1], 2);
return g0 + g1 + g2 + g3;
}
CUT ---
Note on the trunk it works correctly as we prop the &a->l[1] into the indirect
reference during forwprop but the C++ front-end is still produce the weird IR.
--
Summary: The C++ front-end produces some NOP_EXPR for vector
types
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36431
[Bug testsuite/34880] gcc.c-torture/execute/float-floor.c fails for targets with no 64-bit double type
--- 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/testsuite/ChangeLog Modified : /trunk/gcc/testsuite/gcc.c-torture/execute/float-floor.c -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34880
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- 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 Last reconfirmed|2008-05-13 13:50:21 |2008-06-03 19:32:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug bootstrap/36216] [meta-bug] Bootstrap problems on mingw32
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 19:30:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36216
[Bug libstdc++/11108] causes transform() to not compile with tolower()
--- 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], > static_cast(std::toupper)); Unfortunately, this is also incorrect because std::toupper(int) typically has C linkage while (int (*)(int)) has C++ linkage and pointers to functions with different language linkages are incompatible. That gcc accepts this form is due to bug 2316. Other compilers diagnose the cast. Ironically, using a type with C linkage in the cast isn't guaranteed to be correct either (where correct is defined as 100% portable) because the C++ standard doesn't specify the linkage of C functions such as toupper(int). Although it will work with the majority of implementations. extern "C" typedef int cfun_t (int); char s [] = "abcd"; std::transform(&s[0], &s[0] + 5, &s[0], static_cast(std::toupper)); The kicker, though, is that extern "C" declarations cannot appear at local or class scope so the typedef above cannot appear near the call where it's used but way above the definition of the function where the call is made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11108
[Bug c++/36430] New: Cannot convert a temporary to a non-const reference even with conversion operator
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
temporary.cpp:4: error: in passing argument 1 of void frobnicate(Foo&)
This works with g++ 4.1, but does not work with 4.2 and 4.3.
--
Summary: Cannot convert a temporary to a non-const reference even
with conversion operator
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gbrammer at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36430
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- 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 are finished with it already. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 18:33:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/36422] Misleading error message for (a0) edit descriptor
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 18:30:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug c++/13682] Compile error with cstdio: fgetpos not declared on AIX
--- 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++ -c -D_LARGE_FILES -o bar.o bar.cc I then grepped all the files that get included in the preprocessed output and found only these two reference _LARGE_FILES: /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.2/include/stdio.h /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.2/include/sys/types.h The problem appears to be that stdio.h makes the following definitions that then get #undef'ed in cstdio: #define fseeko fseeko64 #define ftello ftello64 #define fgetpos fgetpos64 #define fsetpos fsetpos64 #define fopen fopen64 #define freopen freopen64 Because of these defitions, the prototypes in the preprocessed output have a 64 on the end but the using ::fsetpos do not have them, and we get the error. I really think this is GCC's problem and not caused by AIX headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13682
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- 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 found that the test started working correctly with version 133081. The patch submitted in this version is for PR 34677 which claims to be a missed optimization issue as opposed to a codegen bug fix so I am not sure if the bug is really fixed by that change or if that change just masks the problem like -funroll-loops does. 2008-03-10 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34677 * tree-ssa-pre.c (modify_expr_node_pool): Remove. (poolify_tree): Likewise. (modify_expr_template): Likewise. (poolify_modify_stmt): Likewise. (insert_fake_stores): Handle all component-ref style stores in addition to INDIRECT_REF. Also handle complex types. Do not poolify the inserted load. (realify_fake_stores): Do not rebuild the tree but only make it a SSA_NAME copy. (init_pre): Remove initialzation of modify_expr_template. Do not allocate modify_expr_node_pool. (fini_pre): Do not free modify_expr_node_pool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug libstdc++/11108] causes transform() to not compile with tolower()
--- 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 again): Provide a manual cast for toupper to explicitly declare "which toupper" we mean. std::transform(&s[0], &s[0] + 5, &s[0], static_cast(std::toupper)); (This solution is rejected in the PDF. Read the whole thing if you want to know why.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11108
[Bug c++/36429] structure/array member reference/pointer as template argument
--- 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|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Known to fail||3.4.6 Known to work||4.0.0 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36429
[Bug c++/36429] New: structure/array member reference/pointer as template argument
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
A< &x[1] > a1; //ERROR
B< x[1] > b1; //ERROR
int main() { return 0; }
c:\devel\work>arm-uclibc-gcc -v
Reading specs from
/cygdrive/c/cygwin/arm-tools/bin/../lib/gcc-lib/arm-thumb-elf
/3.3.1/specs
Configured with: /home/Unknown/toolchain/build/gcc-3.3.1/configure
--target=arm-
thumb-elf --host=i686-pc-cygwin --build=i686-pc-cygwin --prefix=/arm-tools
--exe
c-prefix=/arm-tools --bindir=/arm-tools/bin --sbindir=/arm-tools/sbin
--sysconfd
ir=/arm-tools/etc --datadir=/arm-tools/share --localstatedir=/arm-tools/var
--ma
ndir=/arm-tools/man --infodir=/arm-tools/info --libdir=/arm-tools/lib
--included
ir=/arm-tools/include --with-local-prefix=/arm-tools/usr/local
--with-gxx-includ
e-dir=/arm-tools/include/c++ --enable-target-optspace --disable-nls
--with-gnu-a
s --with-gnu-ld --disable-__cxa_atexit --enable-languages=c,c++ --enable-shared
--program-prefix=arm-uclibc-
Thread model: single
gcc version 3.3.1
c:\devel\work>arm-uclibc-gcc -c -mcpu=arm7tdmi -mthumb -gdwarf-2 -MD -Wa
ll -Os -mapcs-frame -mthumb-interwork main.cpp
main.cpp:9: error: `s.S::j' is not a valid template argument
main.cpp:9: error: ISO C++ forbids declaration of `bj' with no type
main.cpp:11: error: `s.S::k' is not a valid template argument
main.cpp:11: error: ISO C++ forbids declaration of `bk' with no type
main.cpp:12: error: `((&s) + 4)' is not a valid template argument
main.cpp:12: error: it must be the address of an object with external linkage
main.cpp:12: error: ISO C++ forbids declaration of `ak' with no type
main.cpp:15: error: `x[0]' is not a valid template argument
main.cpp:15: error: ISO C++ forbids declaration of `b0' with no type
main.cpp:17: error: `x[1]' is not a valid template argument
main.cpp:17: error: ISO C++ forbids declaration of `b1' with no type
main.cpp:18: error: `((&x) + 4)' is not a valid template argument
main.cpp:18: error: it must be the address of an object with external linkage
main.cpp:18: error: ISO C++ forbids declaration of `a1' with no type
main.cpp:2: confused by earlier errors, bailing out
--
Summary: structure/array member reference/pointer as template
argument
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: firda at seznam dot cz
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-thumb-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36429
[Bug rtl-optimization/36419] [4.1/4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-06-03 12:26:37 date|| Summary|[4.3/4.4 Regression] Wrong |[4.1/4.3/4.4 Regression] |unwind info with -Os - |Wrong unwind info with -Os - |fasynchronous-unwind-tables |fasynchronous-unwind-tables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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 clearly a bug. Maybe, but a very, very old one ;) That said, if the other library maintainers want that, I do not object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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 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 > hinted to something along these lines in the past. Then the PR is less and > less > a library one and I'm afraid we have to strong arm a solid C++-front-end > hacker > if we want to see progress in the near future... 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 clearly a bug. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- 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 hinted to something along these lines in the past. Then the PR is less and less a library one and I'm afraid we have to strong arm a solid C++-front-end hacker if we want to see progress in the near future... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/36428] std::tr1 Header Location
--- 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 technical report (*not* standard) on the way of the next (so called C++0x) standard, which is the main focus now, while TR1 is in regression fixes-only mode, we are not going to change the paths now, breaking all *our* existing users. By the way, in C++0x mode, the path is . per the current working drafts. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||WONTFIX Summary|std::tr1 Header Location|std::tr1 Header Location http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36428
[Bug rtl-optimization/36419] [4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- 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:
--- except.c.jj2008-04-28 11:35:55.0 +0200
+++ except.c2008-06-03 10:27:04.0 +0200
@@ -540,6 +540,7 @@ expand_resx_expr (tree exp)
cfun->eh->region_array, region_nr);
gcc_assert (!reg->resume);
+ do_pending_stack_adjust ();
reg->resume = emit_jump_insn (gen_rtx_RESX (VOIDmode, region_nr));
emit_barrier ();
}
The problem with this change is that it is probably completely unnecessary
if we end up calling Dwarf2 _Unwind_Resume, it is certainly needed when
it is being changed into a jump.
2) as shown on the short testcases, CSA merges stack adjustments between
a prologue stack adjustment and post-prologue stack adjustment.
(insn/f 547 546 548 2 rhp.C:171 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -76 [0xffb4])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) -1 (nil))
...
(insn:HI 9 5 10 2 rhp.C:173 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) 283 {*addsi_1} (nil))
becomes after CSA:
(insn/f 547 546 548 2 rhp.C:171 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -88 [0xffa8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) 868 {pro_epilogue_adjust_stack_1} (expr_list:REG_UNUSED (reg:CC 17
flags)
(nil)))
As dwarf2out_stack_adjust ignores prologue insns, without CSA it would
properly set DW_CFA_GNU_args_size to 12 after that post-prologue adjustment
but as it has been merged into a prologue stack adjustment, it is ignored
and so DW_CFA_GNU_args_size is off-by-12 until first barrier.
3) As can be also seen on the short testcases, the assumption that after
BARRIER
we should reset DW_CFA_GNU_args_size back to 0 is wrong. While it holds
(resp. should hold) during expansion and perhaps shortly after that, e.g.
outof_cfglayout happily moves things around such that we have unconditional
jumps and BARRIERs too, with different level of stack pushing than level
DW_CFA_GNU_args_size 0.
Any ideas about this? Do you think it is ok to just apply 1) or should we e.g.
try to remove unnecessary stack adjustments before _Unwind_Resume (though,
_Unwind_Resume is a call, so we probably need to guarantee correct stack
alignment at least).
For 2) and 3), we might just walk the whole function, noting the level of stack
pushing for all labels, verify at CALLs that it matches their second operand
and
verify that all jumps to labels have the same level of stack pushing.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at libertysurf dot
||fr, hubicka at gcc dot gnu
||dot org
Summary|[4.3 Regression] Wrong |[4.3/4.4 Regression] Wrong
|unwind info with -Os - |unwind info with -Os -
|fasynchronous-unwind-tables |fasynchronous-unwind-tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug libstdc++/36427] std::ios_base::open_mode is defined but useless
--- 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 Annex D.6 in the C++ Standard, and that is what we are implementing. In any case, because of ABI stability, certainly the underlying type of openmode is not going to change in the near future. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36427
[Bug c++/36428] New: std::tr1 Header Location
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 something like this: #if defined(_MSC_VER) #include #elif defined(__GNUC__) #include #endif It's ugly! And I suspect that GCC might actually have the wrong include location for std::tr1 headers. The community does not want this kind of difference. Furthermore it is unacceptable to extend the compiler include path with some sort of a -I command line argument because this would simply lead to non-portable build mechanisms. Rather, the problem should be resolved by changing the compiler's internal include path. Thank you. Sincerely, Chris. -- Summary: std::tr1 Header Location Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christopher dot kormanyos at al-lighting dot com GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36428
[Bug libstdc++/36427] New: std::ios_base::open_mode is defined but useless
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.
I'm guessing that the latter was defined for compatibility with compilers like
MSVC that would let you use the two synonymously. However, it doesn't work:
~ $ cat > test.cpp < #include
> int main()
> {
> std::ios_base::open_mode m = std::ios_base::in;
> std::fstream f(__FILE__, m);
> }
> EOF
~ $ g++ -v test.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.2.4/work/gcc-4.2.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --disable-libgcj --with-arch=i686
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.4 (Gentoo 4.2.4 p1.0)
/usr/libexec/gcc/i686-pc-linux-gnu/4.2.4/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=i686 -auxbase test
-version -o /tmp/ccgqbb9I.s
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include/g++-v4
/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include/g++-v4/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include/g++-v4/backward
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.2.4/include
/usr/include
End of search list.
GNU C++ version 4.2.4 (Gentoo 4.2.4 p1.0) (i686-pc-linux-gnu)
compiled by GNU C version 4.2.4 (Gentoo 4.2.4 p1.0).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128021
Compiler executable checksum: 38f256a84cbf67f10c0ecc41dbb48f1d
test.cpp: In function âint main()â:
test.cpp:5: error: invalid conversion from âintâ to
âstd::_Ios_Openmodeâ
test.cpp:5: error: initializing argument 2 of âstd::basic_fstream<_CharT,
_Traits>::basic_fstream(const char*, std::_Ios_Openmode) [with _CharT = char,
_Traits = std::char_traits]â
~ $ # Of course, the code works fine if openmode is used instead:
~ $ sed -i 's/open_mode/openmode/' test.cpp
~ $ g++ test.cpp
~ $ echo $?
0
--
Summary: std::ios_base::open_mode is defined but useless
Product: gcc
Version: 4.2.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: justinb at math dot berkeley dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36427
