[Bug ada/37309] tasking is not implemented on NetBSD
--- Comment #12 from laurent at guerby dot net 2009-11-17 08:15 --- This patch was simply not reviewed/discussed at all, Arnaud could you have a look? gcc-patches submission URL: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01510.html -- laurent at guerby dot net changed: What|Removed |Added CC||charlet at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
Re: [Bug ada/37309] tasking is not implemented on NetBSD
This patch was simply not reviewed/discussed at all, Arnaud could you have a look? gcc-patches submission URL: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01510.html Well, this submission does not include a visible changelog and requires saving the attachment and unzip to review the patch. Very inconvenient. I'd suggest reposting the patch with the changelog in the email body, and the patch attached with no compression, that'll make it far easier and more likely to be reviewed. Arno
[Bug ada/37309] tasking is not implemented on NetBSD
--- Comment #13 from charlet at adacore dot com 2009-11-17 08:19 --- Subject: Re: tasking is not implemented on NetBSD This patch was simply not reviewed/discussed at all, Arnaud could you have a look? gcc-patches submission URL: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01510.html Well, this submission does not include a visible changelog and requires saving the attachment and unzip to review the patch. Very inconvenient. I'd suggest reposting the patch with the changelog in the email body, and the patch attached with no compression, that'll make it far easier and more likely to be reviewed. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug c/42076] New: regression on float representation
Hello,
#include stdio.h
#include stdint.h
int main(void)
{
double ratio = 0.21;
printf(ration=%f ratio*1000=%llu\n, ratio, (uint64_t)(1000*ratio));
return 0;
}
I compile its code and have 2 different result with 2 different gcc version.
with 4.4.1 :
$ gcc-4.4 -Wall y.c -o y-4.4
$ ./y-4.4
ration=0.21 ratio*1000=209
with 4.3.4 (I have same result with gcc 4.2.4/4.1.3/4.0.4)
$ gcc-4.3 -Wall y.c -o y-4.3
$ ./y-4.3
ration=0.21 ratio*1000=210
version info :
$ gcc-4.3 --version
gcc-4.3 (Ubuntu 4.3.4-5ubuntu1) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-4.4 --version
gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux pouet 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
GNU/Linux
--
Summary: regression on float representation
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vaillant dot etienne at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42076
[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-17 10:01 --- Also, please note that n2960 is not a standard, it's only a draft, and it's not even the latest draft. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-11-17 10:27 --- The following project file is known to work on alpha-gnu-linux with GCC 4.3.4: project Build_XMLAda is for Source_Dirs use (dom, input_sources, sax, schema, unicode); for Library_Name use xmlada; for Library_Dir use .; for Library_Kind use External (kind); for Library_Version use External (soname); for Object_Dir use External (obj); for Library_ALI_Dir use ali- External (obj); package Compiler is for Default_Switches (Ada) use (-g, -O2, -gnatafno, -gnatVa, -gnatwa); end Compiler; end Build_XMLAda; Since this project file is not noticeably different from GNADE_Common_Build, I think the bug is actually a regression in 4.4. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Known to fail||4.4.2 Known to work||4.3.4 Summary|Infinite loop when parsing a|[4.4 regression] Infinite |project file, alpha only|loop when parsing a project ||file, alpha only http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug c++/42058] [4.3/4.4/4.5 Regression] Trouble with invalid array initialization
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-17 11:01 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00783.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug middle-end/42077] New: std::set: dereferencing pointer '__x.15' does break strict-aliasing rules
With gcc-4.4.2 the following code generates warnings about strict aliasing:
=| bug.cpp |===
#include set
#ifdef SHOW_BUG
struct foo {
int i;
bool operator(foo const o) const { return i o.i; }
};
#else
typedef int foo;
#endif
int main() { std::setfoo().insert((foo) {0}); }
=| bug.cpp |===
$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.2-src/configure --prefix=/home/rjo/apps/gcc-4.4.2
--with-gmp=/home/rjo/apps --with-mpfr=/home/rjo/apps --disable-nls
--disable-multilib
Thread model: posix
gcc version 4.4.2 (GCC)
$ gcc -Wall -O3 -DSHOW_BUG bug.cpp
bug.cpp: In function 'int main()':
bug.cpp:5: warning: dereferencing pointer '__x.15' does break strict-aliasing
rules
/home/rjo/apps/gcc-4.4.2/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../include/c++/4.4.2/bits/stl_tree.h:525:
note: initialized from here
/home/rjo/experiments/scratch.cpp:5: warning: dereferencing pointer '__x.15'
does break strict-aliasing rules
/home/rjo/apps/gcc-4.4.2/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../include/c++/4.4.2/bits/stl_tree.h:525:
note: initialized from here
In addition to the problem of the STL (appearing to?) break strict-aliasing
rules, it looks like bug #38477 is back
Below is the (hopefully) relevant snippet of CFG. It looks exactly like the
issue described in bug #38477, with static cast voodoo:
static const _Val std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare,
_Alloc::_S_value(const std::_Rb_tree_node_base*) [with _Key = foo, _Val = foo,
_KeyOfValue = std::_Identityfoo, _Compare = std::lessfoo, _All
oc = std::allocatorfoo] (const struct _Rb_tree_node_base * __x)
{
const struct _Rb_tree_node * __x.15;
const struct foo D.8747;
bb 2:
__x.15 = (const struct _Rb_tree_node *) __x;
D.8747 = __x.15-_M_value_field;
return D.8747;
}
Also, is there a particular reason the diagnostic says does break instead of
breaks ? The former may be technically correct English but sounds strange,
even if there's a corresponding may break diagnostic.
--
Summary: std::set: dereferencing pointer '__x.15' does break
strict-aliasing rules
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42077
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #69 from baldrick at free dot fr 2009-11-17 11:04 --- It seems that variables produced by the Ada front-end no longer have any non-trivial range information associated with them. Without knowing the range information type S is range 0 .. 100; type T is range 10 .. 20; it is impossible for the optimizers to eliminate most of the range checks in this testcase. With the range information all of the checks can in theory be removed. This is an example of how range information is potentially very helpful for optimizing Ada programs. Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug middle-end/42077] std::set: dereferencing pointer '__x.15' does break strict-aliasing rules
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-17 11:09 --- *** This bug has been marked as a duplicate of 39390 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42077
[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-17 11:09 --- *** Bug 42077 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||scovich at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug c/42078] New: ice in gimple_assign_set_rhs_code
I just tried to compile Suse Linux package fontforge-20090622-4.1 with gcc version 4.5 snapshot 20091112 and the build said nowakowskittfinstr.c: In function 'InterpolateAlongDiag': nowakowskittfinstr.c:4440:15: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_debug() in gimple_assign_set_rhs_code, at gimple.h:1830 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flags -g -O2 -ffast-math required. -- Summary: ice in gimple_assign_set_rhs_code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug c/42078] ice in gimple_assign_set_rhs_code
--- Comment #1 from dcb314 at hotmail dot com 2009-11-17 11:11 --- Created an attachment (id=19028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19028action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set
--- Comment #10 from scovich at gmail dot com 2009-11-17 11:16 --- (In reply to comment #3) the warning is for dead code. Thus this is not a wrong-code problem. Just to verify, does this (and comment #7) mean that the warning is harmless and can be ignored? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #70 from ebotcazou at gcc dot gnu dot org 2009-11-17 11:19 --- It seems that variables produced by the Ada front-end no longer have any non-trivial range information associated with them. Without knowing the range information type S is range 0 .. 100; type T is range 10 .. 20; it is impossible for the optimizers to eliminate most of the range checks in this testcase. With the range information all of the checks can in theory be removed. This is an example of how range information is potentially very helpful for optimizing Ada programs. Theoretically, but this never really worked in practice; and experiments showed that we get better code without it, especially in loops. Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? Yes, it's essentially impossible to use because of the need to support invalid values. There might be means to get the info back, e.g. using ASSERT_EXPRs, but this hasn't been tried yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/41827] [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-17 11:47 ---
Since all regressions are OpenMP related, the following patch works without any
testsuite failures:
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 154189)
+++ gcc/fortran/trans.c (working copy)
@@ -1281,7 +1281,7 @@ gfc_trans_code (gfc_code * code)
if (res != NULL_TREE ! IS_EMPTY_STMT (res))
{
- if (TREE_CODE (res) != STATEMENT_LIST)
+ if (TREE_CODE (res) != STATEMENT_LIST gfc_option.flag_openmp)
SET_EXPR_LOCATION (res, input_location);
/* Add the new statement to the block. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-17 12:00 ---
(In reply to comment #3)
So inside MAIN__ we have:
static void setpointer (integer(kind=4) (*T3af) (integer(kind=4)));
setpointer (ptype);
That is wrong, unless I am missing a reference type somewhere.
Yes, indeed the 'static' line is wrong. However, it does not seem to have any
consequences.
Plus inside setpointer I think:
p = (integer(kind=4) (*T3af) (integer(kind=4)) *) funpointer;
is incorrect, it should be:
*p = funpointer;
Right, this is corrected by my patch in comment #2. With that patch, the dump
shows:
setpointer (integer(kind=4) (*T3d4) (integer(kind=4)) * p)
{
*p = (integer(kind=4) (*T3d4) (integer(kind=4))) funpointer;
}
MAIN__ ()
{
extern void (*T62) (void) funpointer;
integer(kind=4) (*T3d4) (integer(kind=4)) ptype;
integer(kind=4) (*T3d4) (integer(kind=4)) ptype2;
static void setpointer (integer(kind=4) (*T3d4) (integer(kind=4)));
Here the 'setpointer' routine is ok, but again the static declaration is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug c/42078] ice in gimple_assign_set_rhs_code
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-17 12:42
---
Confirmed. Reduced testcase (crashes with -O -ffast-math -g):
==
double sqrt (double x);
float foo(float x)
{
float y = sqrt(x);
return x/y;
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-17 12:42:48
date||
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug c/42079] New: missing unitialized warning on simple testcase
This code should warn that foo is used uninitialized, but it doesn't.. gcc 4.3
and gcc 4.4 both fail to report a warning
extern void do_something(void **foo);
extern int cond(void);
int main(int argc, char *argv[])
{
void *foo;
if (cond())
do_something(foo);
*argv = foo;
return 0;
}
--
Summary: missing unitialized warning on simple testcase
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #15 from yipiha2008 at gmail dot com 2009-11-17 13:04 --- Is it feasible to disable the affected instruction in the meantime, so that gcc stops crashing? Or, if this comes from Thumb-2 support, maybe it's possible to disable Thumb-2 support? I'm basically looking for a workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #5 from olga at il dot ibm dot com 2009-11-17 13:47 --- This patch should solve the problem. Please confirm for your platforms. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00849.html Thanks, Olga -- olga at il dot ibm dot com changed: What|Removed |Added CC||olga at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug middle-end/42080] New: [4.5 regression] Revision 154242 caused testsuite error
On Linux/ia32, revision 154242: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00463.html caused: FAIL: gcc.dg/struct/w_prof_global_var.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all (internal compiler error) FAIL: gcc.dg/struct/w_prof_local_var.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all (internal compiler error) FAIL: gcc.dg/struct/w_prof_two_strs.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all (internal compiler error) FAIL: gcc.dg/struct/wo_prof_array_field.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_array_field.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_global_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_global_var.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_local_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_local_var.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c (test for excess errors) FAIL: gcc.dg/struct/wo_prof_two_strs.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_two_strs.c (test for excess errors) -- Summary: [4.5 regression] Revision 154242 caused testsuite error Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42080
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #71 from rguenther at suse dot de 2009-11-17 15:07 --- Subject: Re: VRP fails to eliminate range checks in Ada code On Tue, 17 Nov 2009, baldrick at free dot fr wrote: --- Comment #69 from baldrick at free dot fr 2009-11-17 11:04 --- It seems that variables produced by the Ada front-end no longer have any non-trivial range information associated with them. Without knowing the range information type S is range 0 .. 100; type T is range 10 .. 20; it is impossible for the optimizers to eliminate most of the range checks in this testcase. With the range information all of the checks can in theory be removed. This is an example of how range information is potentially very helpful for optimizing Ada programs. Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? It was removed because it was impossible to use it correctly. The fix is to derive range information from existing range checks, possibly inter-procedurally. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-17 15:15 --- Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug c++/561] std:unclear about Overloaded Function Pointer resolution
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-17 15:46 --- This is core issue 794: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#794 The core group decided not to take any action on this issue in Santa Cruz, but Switzerland may raise it again after CD2. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=561
[Bug other/42081] New: big-endian arm MULTILIB_DEFAULTS hard-coded to little-endian
To whom it may concern:
In general, the logic of the gcc/config/arm/linux-elf.h file dictates that if
the target is big-endian arm, gcc will use big-endian defaults (like
-mbig_endian); otherwise, gcc will use little-endian defaults. However, there
is apparently one exception to this rule. MUTLILIB_DEFAULTS is hard-coded to
little-endian for both big-endian and little-endian arm:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ marm, mlittle-endian, mhard-float, mno-thumb-interwork }
To be to consistent with the rest of the header file, shouldn't this read:
#undef MULTILIB_DEFAULTS
#if TARGET_BIG_ENDIAN_DEFAULT
#define MULTILIB_DEFAULTS \
{ marm, mbig-endian, mhard-float, mno-thumb-interwork }
#else
#define MULTILIB_DEFAULTS \
{ marm, mlittle-endian, mhard-float, mno-thumb-interwork }
#endif
or better yet:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ marm, TARGET_ENDIAN_OPTION, mhard-float, mno-thumb-interwork }
Otherwise, on a big-endian arm target in which multi-lib is enabled,
potentially some options would be set by default to big-endian, others to
little-endian, and the compiler would get confused. At least that's how it
appears to me.
If this is by design rather than a minor bug that fell through the cracks (I
know that arm is natively little-endian, and thus there may be a reason to
always default it to little-endian in certain cases) please disregard this
message and close this bug report. Thanks.
Regards,
Tom
--
Summary: big-endian arm MULTILIB_DEFAULTS hard-coded to little-
endian
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at giftssoft dot com
GCC target triplet: arm*b-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
Re: [Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? It was removed because it was impossible to use it correctly. The fix is to derive range information from existing range checks, possibly inter-procedurally. Right, as soon as you have one range check, the compiler can make more precise assumptions/conclusions about the actual range. Arno
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #72 from charlet at adacore dot com 2009-11-17 15:50 --- Subject: Re: VRP fails to eliminate range checks in Ada code Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? It was removed because it was impossible to use it correctly. The fix is to derive range information from existing range checks, possibly inter-procedurally. Right, as soon as you have one range check, the compiler can make more precise assumptions/conclusions about the actual range. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug bootstrap/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c/42076] regression on float representation
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-17 16:17 --- You are likely running into excess precision issues of i?86. Try using -mpc64 or -mfpmath=sse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42076
[Bug c/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-17 16:17 --- VTA issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug c/42079] missing unitialized warning on simple testcase
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-17 16:18 --- It would give too many false positives. Also we do not warn for non-registers very consistently (due to the same reason). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
[Bug middle-end/42080] [4.5 regression] Revision 154242 caused testsuite error
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42080
[Bug tree-optimization/41857] Loop optimizer breaks __ea pointers with -mea64
--- Comment #4 from uweigand at gcc dot gnu dot org 2009-11-17 16:22 --- Subject: Bug 41857 Author: uweigand Date: Tue Nov 17 16:21:56 2009 New Revision: 154255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154255 Log: PR tree-optimization/41857 * tree-ssa-address.c (move_hint_to_base): Use void pointer to TYPE's address space instead of pointer to TYPE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-address.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #73 from baldrick at free dot fr 2009-11-17 16:56 --- Can someone please close this bug as WONTFIX then (I don't know how to do this myself). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #74 from charlet at gcc dot gnu dot org 2009-11-17 17:03 --- Marking as WONTFIX, as requested -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #2 from ubizjak at gmail dot com 2009-11-17 17:47 --- (In reply to comment #0) I have access to an alpha-linux-gnu machine, please tell me if I can help narrow this problem down. A debug trace from gdb would be a nice starting point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug rtl-optimization/41862] valgrind warns about using uninitialized variable with -fgcse-sm
--- Comment #5 from zsojka at seznam dot cz 2009-11-17 18:34 --- Created an attachment (id=19029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19029action=view) reduced testcase BINARY=/mnt/svn/gcc-trunk/binary-154190-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 valgrind --malloc-fill=0x00 $BINARY -O1 -fgcse-sm -fPIC -m32 -o malloc-00.S pr41862.i valgrind --malloc-fill=0xff $BINARY -O1 -fgcse-sm -fPIC -m32 -o malloc-ff.S pr41862.i diff malloc-00.S malloc-ff.S Gives: 13a14 movl%esi, g...@gotoff(%ebx) 21,22c22,23 leal1(%esi), %eax movl%eax, g...@gotoff(%ebx) --- addl$1, %esi movl%esi, g...@gotoff(%ebx) The first store is redundant, caused by using uninitialised memory by gcc. -- zsojka at seznam dot cz changed: What|Removed |Added Attachment #18928|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #3 from alanpae at ilkda dot com 2009-11-17 19:18 --- I'm getting the except same error message. /build/new-gcc/./gcc/xgcc -shared-libgcc -B/build/new-gcc/./gcc -nostdinc++ -L/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/src -L/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/src/.libs -B/opt/gcc/i386-pc-solaris2.11/bin/ -B/opt/gcc/i386-pc-solaris2.11/lib/ -isystem /opt/gcc/i386-pc-solaris2.11/include -isystem /opt/gcc/i386-pc-solaris2.11/sys-include -x c++-header -g -O2 -I/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11 -I/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include -I/build/gcc-4.4.2/libstdc++-v3/libsupc++ -O0 -g /build/gcc-4.4.2/libstdc++-v3/include/precompiled/stdc++.h -o i386-pc-solaris2.11/bits/stdc++.h.gch/O0g.gch In file included from /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr.h:162, from /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/ext/atomicity.h:34, from /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/basic_string.h:41, from /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/string:53, from /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/bitset:49, from /build/gcc-4.4.2/libstdc++-v3/include/precompiled/stdc++.h:64: /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr-default.h: In function int __gthread_mutex_destroy(__gthread_mutex_t*): /build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr-default.h:466: error: __mutex was not declared in this scope gmake[4]: *** [i386-pc-solaris2.11/bits/stdc++.h.gch/O0g.gch] Error 1 gmake[4]: Leaving directory `/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3/include' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/build/new-gcc/i386-pc-solaris2.11/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/build/new-gcc' gmake: *** [bootstrap] Error 2 Will try building it again with threads=none or the equivalent. alan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug c/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-17 19:39 --- Caused by PR41963. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-11-17 19:43 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope --- Comment #3 from alanpae at ilkda dot com 2009-11-17 19:18 --- [...] Will try building it again with threads=none or the equivalent. Why are you building with --enable-threads=solaris in the first place? Just omit --enable-threads (defaulting to posix); the implementation of both on Solaris 2 is the same, anyway. It is beyond me why anyone would want to program to the old UI Threads interface. That said, I'm testing the obvious fix: Index: gcc/gthr-solaris.h === --- gcc/gthr-solaris.h (revision 154216) +++ gcc/gthr-solaris.h (working copy) @@ -37,7 +37,7 @@ #include errno.h #ifdef __cplusplus -#define UNUSED(x) +#define UNUSED(x) x #else #define UNUSED(x) x __attribute__((unused)) #endif I've now idea what other problems with --enable-threads=solaris might exist, though. This isn't regularly tested. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug c++/42082] New: [C++0x] ICE on probably invalid with canonical types differ for identical types
The attached code causes an ICE with gcc 4.5 20091112. I'm somewhat certain but not positive that it is not valid code. $ g++-4.5-20091112 -std=c++0x decl.cpp -o decl decl.cpp: In function 'std::unique_future_Res async(F) [with T = int, F = main()::lambda()]': decl.cpp:16:30: instantiated from here decl.cpp:7:46: internal compiler error: canonical types differ for identical types int() and int() Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [C++0x] ICE on probably invalid with canonical types differ for identical types Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lloyd at randombit dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
[Bug c++/42082] [C++0x] ICE on probably invalid with canonical types differ for identical types
--- Comment #1 from lloyd at randombit dot net 2009-11-17 19:48 --- Created an attachment (id=19030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19030action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
[Bug c/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-17 19:50 --- Either we should just drop the debug stmts, or replace the ARG1 uses in the debug stmts with 1/ARG1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #3 from ludovic at ludovic-brenta dot org 2009-11-17 19:56 --- Even an empty project file triggers the bug: $ cat p.gpr EOF project p is end p; EOF $ gdb gnatmake (gdb) run -vP2 -Pp Starting program: /usr/bin/gnatmake -vP2 -Pp GPR_PROJECT_PATH=.:/usr/share/ada/adainclude/ Project_Path_Name_Of (p, /home/lbrenta/); Trying /home/lbrenta//p.gpr Project_Name_From (/home/lbrenta/p.gpr) ^C Program received signal SIGINT, Interrupt. 0x0286f344 in prj__tree__tree_private_part__projects_htable__get_next () from /usr/lib/libgnatprj.so.4.4 (gdb) bt #0 0x0286f344 in prj__tree__tree_private_part__projects_htable__get_next () from /usr/lib/libgnatprj.so.4.4 #1 0x02853dd8 in ?? () from /usr/lib/libgnatprj.so.4.4 #2 0x02856abc in prj__part__parse () from /usr/lib/libgnatprj.so.4.4 #3 0x0284df7c in prj__pars__parse () from /usr/lib/libgnatprj.so.4.4 #4 0x0001200635d4 in ?? () #5 0x0001200450c4 in ?? () #6 0x00012000cf60 in ?? () #7 0x0001200ad114 in ?? () #8 0x02bd650c in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=0x1200ad190, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x11fcbd730) at libc-start.c:222 #9 0x00012000b958 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Note: this gnatmake is built with -O2 and without -g. (gdb) disassemble Dump of assembler code for function prj__tree__tree_private_part__projects_htable__tab__get_next: 0x0286f290 prj__tree__tree_private_part__projects_htable__tab__get_next+0:ldah gp,6(t12) 0x0286f294 prj__tree__tree_private_part__projects_htable__tab__get_next+4:lda gp,-12016(gp) 0x0286f298 prj__tree__tree_private_part__projects_htable__tab__get_next+8:lda sp,-32(sp) 0x0286f29c prj__tree__tree_private_part__projects_htable__tab__get_next+12: stq s0,8(sp) 0x0286f2a0 prj__tree__tree_private_part__projects_htable__tab__get_next+16: mov a0,s0 0x0286f2a4 prj__tree__tree_private_part__projects_htable__tab__get_next+20: stq ra,0(sp) 0x0286f2a8 prj__tree__tree_private_part__projects_htable__tab__get_next+24: stq s1,16(sp) 0x0286f2ac prj__tree__tree_private_part__projects_htable__tab__get_next+28: bne a0,0x286f2d0 prj__tree__tree_private_part__projects_htable__tab__get_next+64 0x0286f2b0 prj__tree__tree_private_part__projects_htable__tab__get_next+32: clr v0 0x0286f2b4 prj__tree__tree_private_part__projects_htable__tab__get_next+36: ldq ra,0(sp) 0x0286f2b8 prj__tree__tree_private_part__projects_htable__tab__get_next+40: ldq s0,8(sp) 0x0286f2bc prj__tree__tree_private_part__projects_htable__tab__get_next+44: ldq s1,16(sp) 0x0286f2c0 prj__tree__tree_private_part__projects_htable__tab__get_next+48: lda sp,32(sp) 0x0286f2c4 prj__tree__tree_private_part__projects_htable__tab__get_next+52: ret 0x0286f2c8 prj__tree__tree_private_part__projects_htable__tab__get_next+56: nop 0x0286f2cc prj__tree__tree_private_part__projects_htable__tab__get_next+60: unop 0x0286f2d0 prj__tree__tree_private_part__projects_htable__tab__get_next+64: ldah s1,1(a0) 0x0286f2d4 prj__tree__tree_private_part__projects_htable__tab__get_next+68: ldl t0,-16312(s1) 0x0286f2d8 prj__tree__tree_private_part__projects_htable__tab__get_next+72: and t0,0xff,t0 0x0286f2dc prj__tree__tree_private_part__projects_htable__tab__get_next+76: beq t0,0x286f2b0 prj__tree__tree_private_part__projects_htable__tab__get_next+32 0x0286f2e0 prj__tree__tree_private_part__projects_htable__tab__get_next+80: ldq a0,-16320(s1) 0x0286f2e4 prj__tree__tree_private_part__projects_htable__tab__get_next+84: ldq t12,-32248(gp) 0x0286f2e8 prj__tree__tree_private_part__projects_htable__tab__get_next+88: jsr ra,(t12),0x286f2ec prj__tree__tree_private_part__projects_htable__tab__get_next+92 0x0286f2ec prj__tree__tree_private_part__projects_htable__tab__get_next+92: ldah gp,6(ra) 0x0286f2f0 prj__tree__tree_private_part__projects_htable__tab__get_next+96: mov s0,a0 0x0286f2f4 prj__tree__tree_private_part__projects_htable__tab__get_next+100: lda gp,-12108(gp) 0x0286f2f8 prj__tree__tree_private_part__projects_htable__tab__get_next+104: stq v0,-16320(s1) 0x0286f2fc prj__tree__tree_private_part__projects_htable__tab__get_next+108: ldq t12,-28536(gp) 0x0286f300 prj__tree__tree_private_part__projects_htable__tab__get_next+112: jsr ra,(t12),0x286f304 prj__tree__tree_private_part__projects_htable__tab__get_next+116 0x0286f304 prj__tree__tree_private_part__projects_htable__tab__get_next+116: ldah gp,6(ra) 0x0286f308
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #4 from ludovic at ludovic-brenta dot org 2009-11-17 19:59 --- Actually the disassembly above was that of Tab.Get_Next. The source for Tab.Get_Next is: function Get_Next (T : Instance) return Elmt_Ptr is begin if T = null or else not T.Iterator_Started then return Null_Ptr; end if; T.Iterator_Ptr := Next (T.Iterator_Ptr); return Get_Non_Null (T); end Get_Next; The disassembly of Simple_HTable.Get_Next is: (gdb) up #1 0x0286f344 in prj__tree__tree_private_part__projects_htable__get_next () from /usr/lib/libgnatprj.so.4.4 (gdb) disassemble Dump of assembler code for function prj__tree__tree_private_part__projects_htable__get_next: 0x0286f320 prj__tree__tree_private_part__projects_htable__get_next+0: ldahgp,6(t12) 0x0286f324 prj__tree__tree_private_part__projects_htable__get_next+4: lda gp,-12160(gp) 0x0286f328 prj__tree__tree_private_part__projects_htable__get_next+8: lda sp,-16(sp) 0x0286f32c prj__tree__tree_private_part__projects_htable__get_next+12:ldq t12,-27200(gp) 0x0286f330 prj__tree__tree_private_part__projects_htable__get_next+16:stq s0,8(sp) 0x0286f334 prj__tree__tree_private_part__projects_htable__get_next+20:mov a0,s0 0x0286f338 prj__tree__tree_private_part__projects_htable__get_next+24:stq ra,0(sp) 0x0286f33c prj__tree__tree_private_part__projects_htable__get_next+28:mov a1,a0 0x0286f340 prj__tree__tree_private_part__projects_htable__get_next+32:jsr ra,(t12),0x286f344 prj__tree__tree_private_part__projects_htable__get_next+36 0x0286f344 prj__tree__tree_private_part__projects_htable__get_next+36:ldah gp,6(ra) 0x0286f348 prj__tree__tree_private_part__projects_htable__get_next+40:lda gp,-12196(gp) 0x0286f34c prj__tree__tree_private_part__projects_htable__get_next+44:beq v0,0x286f390 prj__tree__tree_private_part__projects_htable__get_next+112 0x0286f350 prj__tree__tree_private_part__projects_htable__get_next+48:ldl t0,16(v0) 0x0286f354 prj__tree__tree_private_part__projects_htable__get_next+52:ldl t3,4(v0) 0x0286f358 prj__tree__tree_private_part__projects_htable__get_next+56:ldl t2,8(v0) 0x0286f35c prj__tree__tree_private_part__projects_htable__get_next+60:ldl t1,12(v0) 0x0286f360 prj__tree__tree_private_part__projects_htable__get_next+64:stl t3,0(s0) 0x0286f364 prj__tree__tree_private_part__projects_htable__get_next+68:stl t2,4(s0) 0x0286f368 prj__tree__tree_private_part__projects_htable__get_next+72:stl t1,8(s0) 0x0286f36c prj__tree__tree_private_part__projects_htable__get_next+76:stl t0,12(s0) 0x0286f370 prj__tree__tree_private_part__projects_htable__get_next+80:mov s0,v0 0x0286f374 prj__tree__tree_private_part__projects_htable__get_next+84:ldq ra,0(sp) 0x0286f378 prj__tree__tree_private_part__projects_htable__get_next+88:ldq s0,8(sp) 0x0286f37c prj__tree__tree_private_part__projects_htable__get_next+92:lda sp,16(sp) 0x0286f380 prj__tree__tree_private_part__projects_htable__get_next+96:ret 0x0286f384 prj__tree__tree_private_part__projects_htable__get_next+100: unop 0x0286f388 prj__tree__tree_private_part__projects_htable__get_next+104: nop 0x0286f38c prj__tree__tree_private_part__projects_htable__get_next+108: unop 0x0286f390 prj__tree__tree_private_part__projects_htable__get_next+112: ldah t1,-4(gp) 0x0286f394 prj__tree__tree_private_part__projects_htable__get_next+116: lda t0,20296(t1) 0x0286f398 prj__tree__tree_private_part__projects_htable__get_next+120: ldl t3,20296(t1) 0x0286f39c prj__tree__tree_private_part__projects_htable__get_next+124: ldl t2,4(t0) 0x0286f3a0 prj__tree__tree_private_part__projects_htable__get_next+128: ldl t1,12(t0) 0x0286f3a4 prj__tree__tree_private_part__projects_htable__get_next+132: ldl t0,8(t0) 0x0286f3a8 prj__tree__tree_private_part__projects_htable__get_next+136: stl t3,0(s0) 0x0286f3ac prj__tree__tree_private_part__projects_htable__get_next+140: stl t2,4(s0) 0x0286f3b0 prj__tree__tree_private_part__projects_htable__get_next+144: stl t0,8(s0) 0x0286f3b4 prj__tree__tree_private_part__projects_htable__get_next+148: stl t1,12(s0) 0x0286f3b8 prj__tree__tree_private_part__projects_htable__get_next+152: mov s0,v0 0x0286f3bc prj__tree__tree_private_part__projects_htable__get_next+156: ldq ra,0(sp) 0x0286f3c0
[Bug c++/42083] New: [C++0x] ICE on invalid with tree check: expected aggr_init_expr, have error_mark in build_value_init
This code (in includes needed) ICEs with GCC 4.5 20091112
templatetypename F
decltype(F()) run(F f)
{
return f();
}
int main()
{
auto l = []() { return 5; };
run(l);
}
Compiler output:
$ g++-4.5-20091112 -std=c++0x decl.cpp -o decl
decl.cpp: In function 'int main()':
decl.cpp:14:9: error: no matching function for call to
'main()::lambda()::__lambda0()'
decl.cpp:12:11: note: candidates are: main()::lambda()::lambda(const
main()::lambda())
decl.cpp:12:11: note:
main()::lambda()::lambda(main()::lambda())
decl.cpp:14:9: internal compiler error: tree check: expected aggr_init_expr,
have error_mark in build_value_init, at cp/init.c:319
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [C++0x] ICE on invalid with tree check: expected
aggr_init_expr, have error_mark in build_value_init
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083
[Bug c++/42058] [4.3/4.4/4.5 Regression] Trouble with invalid array initialization
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-17 20:03 --- Subject: Bug 42058 Author: paolo Date: Tue Nov 17 20:03:03 2009 New Revision: 154267 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154267 Log: cp/ 2009-11-17 Paolo Carlini paolo.carl...@oracle.com PR c++/42058 * typeck2.c (digest_init_r): Check init for error_operand_p. * decl.c (reshape_init_class): Check return value of reshape_init_r for error_mark_node. testsuite/ 2009-11-17 Paolo Carlini paolo.carl...@oracle.com PR c++/42058 * testsuite/g++.dg/init/array26.C: New. * testsuite/g++.dg/init/array27.C: Likewise. * testsuite/g++.old-deja/g++.benjamin/13478.C: Adjust dg-errors. Added: trunk/gcc/testsuite/g++.dg/init/array26.C trunk/gcc/testsuite/g++.dg/init/array27.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.benjamin/13478.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug c++/42058] [4.3/4.4 Regression] Trouble with invalid array initialization
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-17 20:05 --- Fixed in mainline, I'm not planning work on a backport. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] Trouble |Trouble with invalid array |with invalid array |initialization |initialization Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug c/42084] New: Wrong result with -Os -fno-delete-null-pointer-checks
We found an inconsistent result when we were testing the options used to build
Linux kernels. See the code below. BTW, I am using r154188.
y...@yang-working:~$ svngcc -O1 -o small_1 small.c
y...@yang-working:~$ ./small_1
g = 2
y...@yang-working:~$ svngcc -Os -fno-delete-null-pointer-checks -o small_s
small.c
y...@yang-working:~$ ./small_s
g = 1
y...@yang-working:~$ cat small.c
#include stdio.h
int g = 0;
static int
foo(int ui1, int ui2)
{
if (ui2 == 0)
return ui1;
else
return ui1 + ui2;
}
void func_2(long long p);
void func_2(long long p)
{
if ((g p) == (g = foo(8, (g != 0
{
g = 1;
}
else
{
g = 2;
}
}
int main(void)
{
func_2(1);
printf(g = %d\n, g);
return 0;
}
y...@yang-working:~$ svngcc -v
Using built-in specs.
COLLECT_GCC=svngcc
COLLECT_LTO_WRAPPER=/home/yang/compilers/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-lto --prefix=/home/yang/compilers
--program-prefix=svn --enable-languages=c,c++
--with-libelf=/home/yang/compilers : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,lto,c++ --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion
Thread model: posix
gcc version 4.5.0 20091115 (experimental) (GCC)
--
Summary: Wrong result with -Os -fno-delete-null-pointer-checks
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chenyang at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
[Bug c/42084] Wrong result with -Os -fno-delete-null-pointer-checks
--- Comment #1 from chenyang at cs dot utah dot edu 2009-11-17 21:13 --- The inconsistent results also show up with the following combinations: -O3 -fno-delete-null-pointer-checks -O2 -fno-delete-null-pointer-checks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
[Bug middle-end/42080] [4.5 regression] Revision 154242 caused testsuite error
--- Comment #1 from hp at gcc dot gnu dot org 2009-11-17 21:19 --- Yah, seen for cris-elf too... -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-17 21:19:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42080
[Bug c/42084] Wrong result with -Os -fno-delete-null-pointer-checks
--- Comment #2 from chenyang at cs dot utah dot edu 2009-11-17 21:21 --- I am sorry I should also mention that the code works with -Os, or -O3 or -O2, but not with the extra flag -fno-delete-null-pointer-checks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
Re: [Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
#1 0x02853dd8 in ?? () from /usr/lib/libgnatprj.so.4.4 #2 0x02856abc in prj__part__parse () from /usr/lib/libgnatprj.so.4.4 #3 0x0284df7c in prj__pars__parse () from /usr/lib/libgnatprj.so.4.4 Well, there's no such thing as libgnatprj.so in GCC sources/Makefiles. Can you please retry with a stock GCC and build with -O0 -g to get a more complete info/debug session? TIA. Arno
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #5 from charlet at adacore dot com 2009-11-17 21:45 --- Subject: Re: [4.4 regression] Infinite loop when parsing a project file, alpha only #1 0x02853dd8 in ?? () from /usr/lib/libgnatprj.so.4.4 #2 0x02856abc in prj__part__parse () from /usr/lib/libgnatprj.so.4.4 #3 0x0284df7c in prj__pars__parse () from /usr/lib/libgnatprj.so.4.4 Well, there's no such thing as libgnatprj.so in GCC sources/Makefiles. Can you please retry with a stock GCC and build with -O0 -g to get a more complete info/debug session? TIA. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-11-17 22:24 --- Thanks for testing. On second thought, the patch in #1 doesn't the right thing and it's too intrusive if the issue happens only with -O0 for a bit problematic feature. Some better idea will be needed, though it seems there is no easy way to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
[Bug middle-end/42080] [4.5 regression] Revision 154242 caused testsuite error
--- Comment #2 from hp at gcc dot gnu dot org 2009-11-18 00:25 --- Fixed, apparently as per r154271. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42080
[Bug c++/42085] New: Typedef templates
First of all, sorry if I seem redundant, for you may get a lot of requests like
this one, but couldn't you implement an extension (accessible with, for
example, -ftypedef-templates or something) that would allow the code below to
compile as it logically should :
templateclass _T
typedef _T Storage; // a template typedef declaration
class I { // an abstract class
virtual void foo() const=0;
};
template
typedef const I StorageI; // a partial specialisation for the abstract class
templateclass _T
class Foo {
Storage_T m_data;
/* obviously the class does something else ;) */
};
int main(/* etc. */) {
FooA test;
Fooint test2;
return 0;
}
Thanks a bunch if you can, and thanks anyway otherwise :D
PS: I know the standard doesn't allow for typedef templates (and that's why I'm
asking for an extension) but this one would be so darn helpful I couldn't help
but ask anyway.
PS2: I know there is a workaround to do this, but it's ugly and it's impact on
readability and design is disastrous, whereas the syntax above is pretty
readable and well in accordance with the whole of template declaration and
specialisation, since its syntax is the same as when I declare a class or a
function template.
--
Summary: Typedef templates
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot coiffier at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42085
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-11-18 01:04 --- One oddity in the libgcj.dylib build on darwin is that this only shared library in libjava which doesn't get a .dSYM directory built for it. All the other shared libs have one... ls -R libjava | grep dSYM | grep DWARF libjava/.libs/ecjx.dSYM/Contents/Resources/DWARF: libjava/.libs/gappletviewer.dSYM/Contents/Resources/DWARF: libjava/.libs/gc-analyze.dSYM/Contents/Resources/DWARF: libjava/.libs/gcj-dbtool.dSYM/Contents/Resources/DWARF: libjava/.libs/gcjh.dSYM/Contents/Resources/DWARF: libjava/.libs/gjar.dSYM/Contents/Resources/DWARF: libjava/.libs/gjarsigner.dSYM/Contents/Resources/DWARF: libjava/.libs/gjavah.dSYM/Contents/Resources/DWARF: libjava/.libs/gkeytool.dSYM/Contents/Resources/DWARF: libjava/.libs/gnative2ascii.dSYM/Contents/Resources/DWARF: libjava/.libs/gorbd.dSYM/Contents/Resources/DWARF: libjava/.libs/grmic.dSYM/Contents/Resources/DWARF: libjava/.libs/grmid.dSYM/Contents/Resources/DWARF: libjava/.libs/grmiregistry.dSYM/Contents/Resources/DWARF: libjava/.libs/gserialver.dSYM/Contents/Resources/DWARF: libjava/.libs/gtnameserv.dSYM/Contents/Resources/DWARF: libjava/.libs/jv-convert.dSYM/Contents/Resources/DWARF: libjava/.libs/libgcj-tools.11.dylib.dSYM/Contents/Resources/DWARF: libjava/.libs/libgij.11.dylib.dSYM/Contents/Resources/DWARF: libjava/.libs/libjvm.dylib.dSYM/Contents/Resources/DWARF: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-11-18
01:19 ---
The missing .dSYM for libgcj is a blocker for debugging this issue on darwin...
(gdb) break _Jv_Throw
Breakpoint 1 at 0x20c49ba3dcddf8: file
../../../gcc-4.5-20091116/libjava/exception.cc, line 100.
(gdb) break Unwind_RaiseException
Function Unwind_RaiseException not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (Unwind_RaiseException) pending.
(gdb) r testme.java
-fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5
-ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccnFt6vF.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccrNgp0M.jar
Starting program:
/sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/ecjx
testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccnFt6vF.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccrNgp0M.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries .+. done
Breakpoint 1 at 0x10001adf8: file
../../../gcc-4.5-20091116/libjava/exception.cc, line 100.
Breakpoint 1, _Jv_Throw (value=0x104d656c0) at
../../../gcc-4.5-20091116/libjava/exception.cc:100
100 {
(gdb) c
Continuing.
Current language: auto; currently c++
Program received signal SIGABRT, Aborted.
0x7fff810c3f16 in __kill () at .././libjava/../gcc/unwind-pe.h:285
285 }
There might be an off chance that this is somehow related to the problem
itself. That is, if we fix the build to have a proper dSYM for libgcj, it might
resolve the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug testsuite/42086] New: Too small .bss stack
After the linker bug: http://www.sourceware.org/bugzilla/show_bug.cgi?id=10955 is fixed, I got: FAIL: gcc.target/ia64/fptr-1.c execution test since GP is no longer _GLOBAL_OFFSET_TABLE_. In fact, GP is the same as _GLOBAL_OFFSET_TABLE_ is by accident. I don't know how to make this testcase to work with the new linker. -- Summary: Too small .bss stack Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-linux-gnu BugsThisDependsOn: 41567 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42086
[Bug libstdc++/42019] shared_ptr can not be used with -fno-rtti
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-18 01:30 --- Created an attachment (id=19031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19031action=view) proposed patch I'm testing this, with and without -fno-rtti Without rtti 20_util/shared_ptr/cons/unique_ptr_deleter_ref_2.cc fails as expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-11-18 01:39 --- Argh, the dSYM issue looks like another variation of the current dsymutil issues... libtool: link: /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src -L/sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin10.2.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libgcj.11.dylib .libs/prims.o .libs/jni.o .libs/exception.o .libs/stacktrace.o .libs/link.o .libs/defineclass.o .libs/verify.o .libs/jvmti.o .libs/interpret.o gnu/classpath/jdwp/.libs/natVMFrame.o gnu/classpath/jdwp/.libs/natVMMethod.o gnu/classpath/jdwp/.libs/natVMVirtualMachine.o gnu/classpath/.libs/natConfiguration.o gnu/classpath/.libs/natSystemProperties.o gnu/classpath/.libs/natVMStackWalker.o gnu/gcj/.libs/natCore.o gnu/gcj/convert/.libs/JIS0208_to_Unicode.o gnu/gcj/convert/.libs/JIS0212_to_Unicode.o gnu/gcj/convert/.libs/Unicode_to_JIS.o gnu/gcj/convert/.libs/natIconv.o gnu/gcj/convert/.libs/natInput_EUCJIS.o gnu/gcj/convert/.libs/natInput_SJIS.o gnu/gcj/convert/.libs/natOutput_EUCJIS.o gnu/gcj/convert/.libs/natOutput_SJIS.o gnu/gcj/io/.libs/natSimpleSHSStream.o gnu/gcj/io/.libs/shs.o gnu/gcj/jvmti/.libs/natBreakpoint.o gnu/gcj/jvmti/.libs/natNormalBreakpoint.o gnu/gcj/runtime/.libs/natFinalizerThread.o gnu/gcj/runtime/.libs/natSharedLibLoader.o gnu/gcj/runtime/.libs/natSystemClassLoader.o gnu/gcj/runtime/.libs/natStringBuffer.o gnu/gcj/util/.libs/natDebug.o gnu/gcj/util/.libs/natGCInfo.o gnu/java/lang/.libs/natMainThread.o gnu/java/lang/management/.libs/natVMClassLoadingMXBeanImpl.o gnu/java/lang/management/.libs/natVMCompilationMXBeanImpl.o gnu/java/lang/management/.libs/natVMGarbageCollectorMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryManagerMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryPoolMXBeanImpl.o gnu/java/lang/management/.libs/natVMOperatingSystemMXBeanImpl.o gnu/java/lang/management/.libs/natVMRuntimeMXBeanImpl.o gnu/java/lang/management/.libs/natVMThreadMXBeanImpl.o gnu/java/net/.libs/natPlainDatagramSocketImpl.o gnu/java/net/.libs/natPlainSocketImpl.o gnu/java/net/protocol/core/.libs/natCoreInputStream.o gnu/java/nio/.libs/natVMPipe.o gnu/java/nio/.libs/natVMSelector.o gnu/java/nio/.libs/natNIOServerSocket.o gnu/java/nio/.libs/natVMChannel.o gnu/java/nio/channels/.libs/natFileChannelImpl.o gnu/java/security/jce/prng/.libs/natVMSecureRandom.o java/io/.libs/natFile.o java/io/.libs/natVMObjectInputStream.o java/io/.libs/natVMObjectStreamClass.o java/lang/.libs/natCharacter.o java/lang/.libs/natClass.o java/lang/.libs/natClassLoader.o java/lang/.libs/natConcreteProcess.o java/lang/.libs/natVMDouble.o java/lang/.libs/natVMFloat.o java/lang/.libs/natMath.o java/lang/.libs/natObject.o java/lang/.libs/natRuntime.o java/lang/.libs/natString.o java/lang/.libs/natAbstractStringBuffer.o java/lang/.libs/natSystem.o java/lang/.libs/natThread.o java/lang/.libs/natThreadLocal.o java/lang/.libs/natVMClassLoader.o java/lang/.libs/natVMProcess.o java/lang/.libs/natVMThrowable.o java/lang/ref/.libs/natReference.o java/lang/reflect/.libs/natArray.o java/lang/reflect/.libs/natConstructor.o java/lang/reflect/.libs/natField.o java/lang/reflect/.libs/natMethod.o java/lang/reflect/.libs/natVMProxy.o java/net/.libs/natVMInetAddress.o java/net/.libs/natVMNetworkInterface.o java/net/.libs/natVMURLConnection.o java/nio/channels/.libs/natVMChannels.o java/nio/.libs/natVMDirectByteBufferImpl.o java/security/.libs/natVMAccessController.o java/security/.libs/natVMAccessControlState.o java/text/.libs/natCollator.o java/util/.libs/natVMTimeZone.o java/util/concurrent/atomic/.libs/natAtomicLong.o java/util/logging/.libs/natLogger.o java/util/zip/.libs/natDeflater.o java/util/zip/.libs/natInflater.o sun/misc/.libs/natUnsafe.o .libs/boehm.o .libs/posix.o .libs/darwin.o .libs/posix-threads.o java/lang/.libs/Object.o java/lang/.libs/Class.o java/.libs/process-Posix.o gnu/.libs/awt.o gnu/awt/.libs/j2d.o gnu/.libs/classpath.o gnu/classpath/.libs/debug.o gnu/classpath/.libs/toolkit.o gnu/.libs/gcj.o gnu/gcj/.libs/convert.o gnu/gcj/.libs/io.o gnu/gcj/.libs/runtime.o gnu/gcj/.libs/util.o gnu/java/.libs/awt.o gnu/java/awt/.libs/color.o gnu/java/awt/.libs/dnd.o gnu/java/awt/.libs/font.o gnu/java/awt/font/.libs/autofit.o gnu/java/awt/font/.libs/opentype.o gnu/java/awt/font/opentype/.libs/truetype.o gnu/java/awt/.libs/image.o gnu/java/awt/.libs/java2d.o gnu/java/awt/.libs/peer.o gnu/java/awt/peer/.libs/headless.o gnu/java/awt/.libs/print.o
[Bug c++/42085] Typedef templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 02:10 --- I think C++0x (well renamed to C++1x) has something like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42085
[Bug c++/42085] Typedef templates
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-18 02:13 --- (In reply to comment #1) I think C++0x (well renamed to C++1x) has something like this. Called template aliases: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf Note GCC does not implement them yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42085
[Bug c++/42087] New: stl::map breaks strict-aliasing rules
The attached short snippet fails to compile on GCC 4.4.1 and 4.4.2 (latest
release), due to aliasing issues in stl::map. Ignore the logic as it has been
contorted to reduce the test code fragment size.
First bug submit, so I hope this is close to proper procedure.
==
g++ -O2 -Wall -Werror -c tst5.cxx
-*- mode: compilation; default-directory: ~/ -*-
Compilation started at Tue Nov 17 21:37:41
g++ -v -save-temps -O2 -Wall -Werror -c tst5.cxx
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wall' '-Werror' '-c'
'-shared-libgcc' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1plus -E -quiet -v -D_GNU_SOURCE
tst5.cxx -mtune=generic -Wall -Werror -O2 -fpch-preprocess -o tst5.ii
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-suse-linux
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.4/include
/usr/lib64/gcc/x86_64-suse-linux/4.4/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wall' '-Werror' '-c'
'-shared-libgcc' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1plus -fpreprocessed tst5.ii -quiet
-dumpbase tst5.cxx -mtune=generic -auxbase tst5 -O2 -Wall -Werror -version -o
tst5.s
GNU C++ (SUSE Linux) version 4.4.1 [gcc-4_4-branch revision 150839]
(x86_64-suse-linux)
compiled by GNU C version 4.4.1 [gcc-4_4-branch revision 150839], GMP
version 4.3.1, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9324fd3305365d6cc397a0043b4bc055
cc1plus: warnings being treated as errors
tst5.cxx: In function 'int main()':
tst5.cxx:23: error: dereferencing pointer 'anonymous' does break
strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:179: note: initialized from here
Compilation exited abnormally with code 1 at Tue Nov 17 21:37:41
==
SOURCE FOLLOWS:
//
// Compile with: g++ -O2 -Wall -Werror -c tst.cxx
//
#include map
class C
{
typedef std::map C *, C * CloneList;
static CloneList clone_list;
public:
C() {}
C *clone()
{
clone_list.clear();
C *res = 0;
CloneList::iterator ptr = clone_list.find( this );
if ( ptr != clone_list.end() )
res = ptr - second;
else
{
res = new C;
clone_list[ this ] = res;
}
return res ;
}
} ;
int main()
{
C *c = new C;
return c - clone() != 0;
}
//
--
Summary: stl::map breaks strict-aliasing rules
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: riddikulus at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087
[Bug c++/42087] stl::map breaks strict-aliasing rules
--- Comment #1 from riddikulus at verizon dot net 2009-11-18 03:43 --- Created an attachment (id=19032) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19032action=view) Test code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087
[Bug c++/42087] stl::map breaks strict-aliasing rules
--- Comment #2 from riddikulus at verizon dot net 2009-11-18 03:44 --- Created an attachment (id=19033) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19033action=view) gcc -v -save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087
[Bug c++/42087] stl::map breaks strict-aliasing rules
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-18 04:02 --- *** This bug has been marked as a duplicate of 39390 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42087
[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-11-18 04:02 --- *** Bug 42087 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||riddikulus at verizon dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-10 15:26:47 |2009-11-18 05:24:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-18 05:43 ---
5.3.1 [expr.unary.op] paragraph 3:
...If the member is a non-static member of class C of type T, the type of the
result is pointer to member of class C of type T. [ Example:
struct A { int i; };
struct B : A { };
// has type int A::*
... B::i ...
end example ]
So, the type of D::a is the same as the type of B::a, and this is not a bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug debug/41888] [4.5 Regression] ICE from '-O -ftree-loop-distribution -fgraphite-identity -g'
--- Comment #7 from aoliva at gcc dot gnu dot org 2009-11-18 06:02 --- Subject: Bug 41888 Author: aoliva Date: Wed Nov 18 06:02:26 2009 New Revision: 154279 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154279 Log: PR debug/41888 PR debug/41886 * graphite-scop-detection.c (stmt_simple_for_scop_p): Debug stmts are ok. * graphite-sese-to-poly.c (graphite_stmt_p): Likewise. (try_generate_gimple_bb): Skip debug stmts when finding data refs. * sese.c (sese_build_liveouts_bb): Skip debug stmts. (sese_bad_liveouts_use): New. (sese_reset_debug_liveouts_bb): New. (sese_build_liveouts): Use it. (rename_variables_in_stmt): Reset debug stmts rather than creating new vars for them. (expand_scalar_variable_stmt): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/graphite-sese-to-poly.c trunk/gcc/sese.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41888
[Bug debug/41886] [4.5 Regression] ICE from '-O -ftree-loop-distribution -ftree-vectorize -g'
--- Comment #2 from aoliva at gcc dot gnu dot org 2009-11-18 06:02 --- Subject: Bug 41886 Author: aoliva Date: Wed Nov 18 06:02:26 2009 New Revision: 154279 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154279 Log: PR debug/41888 PR debug/41886 * graphite-scop-detection.c (stmt_simple_for_scop_p): Debug stmts are ok. * graphite-sese-to-poly.c (graphite_stmt_p): Likewise. (try_generate_gimple_bb): Skip debug stmts when finding data refs. * sese.c (sese_build_liveouts_bb): Skip debug stmts. (sese_bad_liveouts_use): New. (sese_reset_debug_liveouts_bb): New. (sese_build_liveouts): Use it. (rename_variables_in_stmt): Reset debug stmts rather than creating new vars for them. (expand_scalar_variable_stmt): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/graphite-sese-to-poly.c trunk/gcc/sese.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41886
[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
--- Comment #4 from aoliva at gcc dot gnu dot org 2009-11-18 06:03 --- Subject: Bug 41926 Author: aoliva Date: Wed Nov 18 06:02:58 2009 New Revision: 154281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154281 Log: gcc/ChangeLog: PR debug/41926 * tree-vect-loop.c (vect_loop_kill_debug_uses): New. (vect_transform_loop): Call it. gcc/testsuite/ChangeLog: PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
--- Comment #5 from aoliva at gcc dot gnu dot org 2009-11-18 06:15 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug debug/41888] [4.5 Regression] ICE from '-O -ftree-loop-distribution -fgraphite-identity -g'
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-11-18 06:22 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41888
[Bug lto/42088] New: flag_gtoggle in free_lang_data hides -fcompare-debug errors
The codegen differences introduced by free_alng_data can be promptly exposed using -fcompare-debug=-g0. Two such errors are known to me, on x86_64-linux-gnu native bootstrap: ada/einfo.adb fails -fcompare-debug=-g0 because boolean_type_node is modified. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00414.html has details. tree.c fails -fcompare-debug=-g0 because declaration UIDs go out of sync when local declarations of types are removed in free_lang_data_in_block(). http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00457.html has details. -- Summary: flag_gtoggle in free_lang_data hides -fcompare-debug errors Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aoliva at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #5 from YLitvinenko at astana dot oilfield dot slb dot com 2009-11-18 07:03 --- (In reply to comment #4) Why are you building with --enable-threads=solaris in the first place? Just omit --enable-threads (defaulting to posix); the implementation of both on Solaris 2 is the same, anyway. It is beyond me why anyone would want to program to the old UI Threads interface. Is it better to let configure guess about thread model on OpenSolaris x86 32bit build = snv_126? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- Comment #17 from reichelt at gcc dot gnu dot org 2009-11-18 07:07 --- *** Bug 13052 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||3 dot 14159 at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/13052] error in looking up template super classes in different namespace
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-11-18 07:07 --- This is the same problem as PR 189 which was fixed yesterday. *** This bug has been marked as a duplicate of 189 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13052
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #61 from andreast at gcc dot gnu dot org 2009-11-18 07:36 --- Subject: Bug 39888 Author: andreast Date: Wed Nov 18 07:36:12 2009 New Revision: 154282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154282 Log: 2009-11-18 Iain Sandoe iain.san...@sandoe-acoustics.co.uk PR other/39888 * config/t-slibgcc-darwin: Fix embedded rpaths for --enable-version-specific-runtime-libs, build extension stub libs exposing features available from current libgcc_s. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/t-slibgcc-darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #62 from andreast at gcc dot gnu dot org 2009-11-18 07:37 --- Subject: Bug 39888 Author: andreast Date: Wed Nov 18 07:37:04 2009 New Revision: 154283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154283 Log: 2009-11-18 Iain Sandoe iain.san...@sandoe-acoustics.co.uk PR other/39888 * config/darwin.h: Use the extension stub libraries to access current libgcc_s features. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
