[Bug debug/43478] Missing DW_AT_location for a variable
--- Comment #14 from jakub at gcc dot gnu dot org 2010-05-17 06:04 --- The #c6 patch is now in, but #c3 not yet. Unfortunately that one needs more work, see comment #c8. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43478
[Bug c++/44162] [C++0x] cannot match function ref argument to dependent std::enable_if::type
--- Comment #2 from potswa at mac dot com 2010-05-17 06:06 ---
Sorry, that was completely wrong. I thought I'd isolated a testcase with the
above code plus int main() { return rcv_fdecltype(f)(f); }, but that actually
does work.
It seems the problem is completely different. The testcase below suggests that
decltype somehow cannot recurse in the presence of a reference to function
type.
#include tuple
#include type_traits // aside: std::result_of belongs in type_traits
#include functional // not functional.
template class T, class F,
size_t tuple_index0 = std::tuple_sizeT::value,
size_t... tuple_indexes
typename std::result_of typename std::enable_if tuple_index0 == 0,
F( typename std::tuple_element tuple_indexes - 1, T ::type... )
::type ::type
apply( T const t, F f ) {
return f( std::get tuple_indexes - 1 ( t )... );
}
template class T, class F,
size_t tuple_index0 = std::tuple_sizeT::value,
size_t... tuple_indexes
decltype( apply typename std::enable_if tuple_index0 != 0, T ::type,
F, tuple_index0 - 1, tuple_index0, tuple_indexes...
( std::declvalT(), std::declvalF() ) )
apply( T const t, F f ) {
return apply T, F, tuple_index0 - 1, tuple_index0, tuple_indexes...
( t, f );
}
void f() {}
void g( int ) {}
void h( int, int ) {}
struct a { void operator()( int, int ) {} };
int main() {
// these cases work:
apply( std::make_tuple(), f );
apply( std::make_tuple( 0 ), g );
apply std::tuple int, int , void ()(int, int), 1, 2 ( std::make_tuple(
0, 0 ), h );
apply( std::make_tuple( 0, 0 ), a() );
// this does not:
apply( std::make_tuple( 0, 0 ), h );
}
Either the subject of this bug should be changed or I should open a new bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162
[Bug target/44163] New: [4.6 Regression] Multiple failures in the objc and libgomp test suites
Since revision 159443, there are multiple failures in the objc and libgomp test suites (see http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg01478.html ). They are all of the form: /var/tmp//ccIspVYP.s:816:non-relocatable subtraction expression, ___emutls_v.baz.1169 minus L002$pb^M /var/tmp//ccIspVYP.s:816:symbol: ___emutls_v.baz.1169 can't be undefined in a subtraction expression^M Reverting revision 159371 fixes these failures. This is probably related to pr44146. -- Summary: [4.6 Regression] Multiple failures in the objc and libgomp test suites Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #22 from dominiq at lps dot ens dot fr 2010-05-17 07:21 --- I have open pr44163 for the testsuite failures on ppc-darwin. Since they are fixed by reverting revision 159371, I think pr44163 is related to this one (if not a duplicate). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-17 07:25 --- Although it may be unrelated, pr44163 reports intermittent bootstrap failures related to TLS found or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-17 07:43 --- @159462 on powerpc64 with: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html (and needed for m32, but not to solve the tls problem) http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01125.html ObjC/C++ tls fails are limited to LTO-related === libgomp Summary === # of expected passes4980 # of unsupported tests 4 still working on better ways to solve the TLS issues (monitor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132 for that) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #18 from siarhei dot siamashka at gmail dot com 2010-05-17 07:53 --- Created an attachment (id=20676) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20676action=view) powerpc64-broken-unreachable.i With the attached file (and '-O2 -c' options): 1. powerpc64 crosscompiler running on x86 box - always works fine 2. powerpc64 crosscompiler built with gcc 4.3.4 and running on powerpc64 box - works fine 3. powerpc64 crosscompiler built with gcc 4.5.0 and running on powerpc64 box - ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug middle-end/44078] [4.6 regression] FAIL: gcc.dg/tree-ssa/prefetch-7.c
--- Comment #4 from krebbel at gcc dot gnu dot org 2010-05-17 07:54 --- Subject: Bug 44078 Author: krebbel Date: Mon May 17 07:53:20 2010 New Revision: 159475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159475 Log: 2010-05-17 Christian Borntraeger borntrae...@de.ibm.com PR 44078 * gcc.dg/tree-ssa/prefetch-7.c: Change pattern to match only the old debug messages but not the newly introduced one. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-7.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44078
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 08:25 --- Subject: Bug 44044 Author: janus Date: Mon May 17 08:25:06 2010 New Revision: 159476 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159476 Log: 2010-05-17 Janus Weil ja...@gcc.gnu.org PR fortran/44044 * resolve.c (resolve_fl_var_and_proc): Move error messages here from ... (resolve_fl_variable_derived): ... this place. (resolve_symbol): Make sure function symbols (and their result variables) are not resolved twice. 2010-05-17 Janus Weil ja...@gcc.gnu.org PR fortran/44044 * gfortran.dg/class_20.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_20.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug middle-end/44164] New: [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function
Using Boost.Bind/Boost.Function triggers what seems to be an aliasing bug with G++ 4.5.0. The minimal test case (including Boost.Bind and Boost.Function) is attached. It works and no errors are detected by valgrind with either flags : -O0 -O1 -O2 -fno-inline -O2 -fno-strict-aliasing -Os It crashes whith either flags and valgrind detects invalid reads : -02 -O3 Everything works fine with gcc version 4.4.3 20100316. There are no warnings using '-W -Wall -Wextra'. Original bug report to boost mailing list : http://lists.boost.org/boost-users/2010/05/59020.php -- Summary: [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: maxime at altribe dot org GCC build triplet: ../configure --prefix=/usr --enable- languages=c,c++,fortran,objc 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=44164
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 08:31 --- Comment #0 and #1 are fixed at this point. I think the runtime checking in comment #2 one can ignore for the moment, since most usage cases of ordinary pointers are also not checked for. So the only ToDo item left here is comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug middle-end/44164] [4.5.0] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #1 from maxime at altribe dot org 2010-05-17 08:31 --- Created an attachment (id=20677) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20677action=view) Test case including Boost.Bind and Boost.Function. I had to gzip the .ii file because of size limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-17 08:45 --- Reverting revision 159371 fixes these failures. I had to revert revision 159371 at revision 159429 with the patch inhttp://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-17 08:54 --- (In reply to comment #2) Reverting revision 159371 fixes these failures. I had to revert revision 159371 at revision 159429 with the patch inhttp://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html . You had to revert 159371 in addition to the patch: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html or instead of that patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #14 from sebastian dot huber at embedded-brains dot de 2010-05-17 09:04 --- This bug is present since r130052 which is related to: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html If this is a generic bug or not is quite irrelevant since this is a very serious bug on ARM/Thumb. I am a bit irritated why this bug survived the 4.4.0 and 4.5.0 release. In a multi threaded environment it is pretty hard to find these kind of problems. The time frame in which an interrupt can corrupt the stack frame lies between two instructions. Is -fno-schedule-insns2 a workaround for this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #19 from siarhei dot siamashka at gmail dot com 2010-05-17 09:06 --- Can anybody knowledgeable verify whether it was commit r151790 ( http://repo.or.cz/w/official-gcc.git/commit/9dbb96fec5e08762f97dda771522283f1fe9710f ) that is causing troubles when __builtin_unreachable() is used in the default switch case? Unfortunately I could not add Andreas Krebbel to CC for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #20 from jakub at gcc dot gnu dot org 2010-05-17 09:08 --- Perhaps dup of PR44071 that got fixed recently? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #4 from dominiq at lps dot ens dot fr 2010-05-17 09:08 --- You had to revert 159371 in addition to the patch: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html or instead of that patch? Sorry for the confusion. In my powerpc-apple-darwin9 tree I have the patch in http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a quite long time (and I guess it is not applied in the native tree of regress). With revision 159371, I see the same failures as regress. These failures disappear if I revert revision 159371 without any other change in my tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-17 09:10 --- (In reply to comment #3) It might be useful to compare the two decls that invoke the mismatch that triggers the gcc_assert: prevailing-decl is: function_decl 0x7fb0f574f900 convect_satmixratio type function_type 0x7fb0f5786b28 type void_type 0x7fb0f584cd20 VOID align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20 pointer_to_this pointer_type 0x7fb0f584cdc8 QI size integer_cst 0x7fb0f583d758 constant 8 unit size integer_cst 0x7fb0f583d780 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fb0f5786b28 public external QI file bkfconv.f90 line 517 col 0 align 8 whereas e-decl is: function_decl 0x7fb0f574f600 convect_satmixratio type function_type 0x7fb0f5763b28 type void_type 0x7fb0f584cd20 VOID align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20 pointer_to_this pointer_type 0x7fb0f584cdc8 QI size integer_cst 0x7fb0f583d758 constant 8 unit size integer_cst 0x7fb0f583d780 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fb0f5763b28 arg-types tree_list 0x7fb0f5754bb8 value reference_type 0x7fb0f5750738 chain tree_list 0x7fb0f5754be0 value pointer_type 0x7fb0f5763bd0 chain tree_list 0x7fb0f5754c08 value pointer_type 0x7fb0f5764000 chain tree_list 0x7fb0f5754c30 value pointer_type 0x7fb0f57643f0 chain tree_list 0x7fb0f5754c58 value pointer_type 0x7fb0f57647e0 chain tree_list 0x7fb0f5754c80 nothrow public static QI file bkfconv.f90 line 400 col 0 align 8 arguments parm_decl 0x7fb0f5760660 klon type reference_type 0x7fb0f5750738 type integer_type 0x7fb0f584c498 unsigned restrict DI size integer_cst 0x7fb0f583da50 constant 64 unit size integer_cst 0x7fb0f583da78 constant 8 align 64 symtab 0 alias set -1 canonical type 0x7fb0f5750738 readonly used unsigned DI passed-by-reference file bkfconv.f90 line 400 col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst 0x7fb0f583da78 8 align 64 context function_decl 0x7fb0f574f600 convect_satmixratio arg-type reference_type 0x7fb0f5750738 chain parm_decl 0x7fb0f57606e8 ppres type pointer_type 0x7fb0f57653f0 readonly used unsigned DI passed-by-reference file bkfconv.f90 line 400 col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst 0x7fb0f583da78 8 align 64 context function_decl 0x7fb0f574f600 convect_satmixratio arg-type pointer_type 0x7fb0f5763bd0 chain parm_decl 0x7fb0f5760770 pt result result_decl 0x7fb0f5752180 D.2157 type void_type 0x7fb0f584cd20 ignored VOID file bkfconv.f90 line 400 col 0 align 8 context function_decl 0x7fb0f574f600 convect_satmixratio This is found by adding the following to lto-symtab.c: It's obvious that somehow the prevailing one is the wrong one. function_decl 0x7fb0f574f900 convect_satmixratio type function_type 0x7fb0f5786b28 type void_type 0x7fb0f584cd20 VOID align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20 pointer_to_this pointer_type 0x7fb0f584cdc8 QI size integer_cst 0x7fb0f583d758 constant 8 unit size integer_cst 0x7fb0f583d780 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fb0f5786b28 public external QI file bkfconv.f90 line 517 col 0 align 8 isn't prevailing at all. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 09:10:19 date|| Summary|lto1: internal compiler |-fuse-linker-plugin lto1: |error: in |internal compiler error: in |lto_symtab_merge_decls_1, at|lto_symtab_merge_decls_1, at |lto-symtab.c:610|lto-symtab.c:610 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug c++/44162] [C++0x] cannot match function ref argument to dependent std::enable_if::type
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-17 09:35 --- Ok, then please open a new PR including a *minimal* testcase. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-17 09:39 --- It's not a dup of PR42834 (but it might be the same issue as PR42832 which was a libstdc++ bug or a frontend bug). It happens to work on trunk, so it might also be a dup of PR43987 (though unlikely), rather different inlining might have made the bug latent. I can confirm the observed effect. I didn't investigate on whether this is a bug in boost or not (we're changing our minds on what is valid and what not all the time anyway). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 Known to work||4.4.3 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-17 09:39:31 date|| Summary|[4.5.0] Aliasing bug|[4.5 Regression] Aliasing |triggered by|bug triggered by |Boost.Bind/Boost.Function |Boost.Bind/Boost.Function Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-17 09:44 --- The boost folks may be able to tell if they at any place copy a function_buffer object via the assignment operator. I see they also have funny stuff like get_vtable() and are playing with typeinfos. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #21 from siarhei dot siamashka at gmail dot com 2010-05-17 10:07 --- (In reply to comment #18) Created an attachment (id=20676) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20676action=view) [edit] powerpc64-broken-unreachable.i With the attached file (and '-O2 -c' options): 1. powerpc64 crosscompiler running on x86 box - always works fine 2. powerpc64 crosscompiler built with gcc 4.3.4 and running on powerpc64 box - works fine Hmm, that was happening because I compiled it with --disable-checking. When built with --enable-checking=release, the ICE reproduces just fine on x86 box with powerpc64-unknown-linux-gnu crosscompiler. Well, getting ssh access to a fast powerpc64 box really did miracles :) Even though the problem does not seem to be that complex after all, painfully long compile times discouraged running more tests earlier, so even a small mistake easily could (and apparently did) lead to wrong track. I'm going to check current 4.5 SVN branch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #22 from siarhei dot siamashka at gmail dot com 2010-05-17 11:31 --- (In reply to comment #20) Perhaps dup of PR44071 that got fixed recently? The problem is still reproducible with SVN rev 159480 in 'branches/gcc-4_5-branch', so the fix from PR44071 does not seem to help here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug bootstrap/43715] [4.5] configure option --enable-plugin fails on darwin
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 12:00:06 date|| Summary|configure option --enable- |[4.5] configure option -- |plugin fails on darwin |enable-plugin fails on ||darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug ada/42554] Can't build GNAT tools
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-05-17 12:07 --- Appears to be fixed. Please reopen if that's not the case. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-17 12:30 --- Created an attachment (id=20678) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20678action=view) Candidate patch On Fri, May 14, 2010 at 07:25:18AM -, jakub at gcc dot gnu dot org wrote: That said, it would be good to find out why we don't warn in that case; for [M_CONST + 6] we do warn. I think we don't warn in that case because M_CONST in the expression M_CONST + 6, M_CONST is an rvalue use and we recognize it as such via default_conversion that should be called on the arguments of the + expression. We fail to recognize the use of [M_CONST], because M_CONST gets folded into it's value without us marking that folding as an rvalue use. I am thus testing the attached patch. The reason why the patch seems convoluted is that I don't want to mark a dependant value as a rvalue use. I believe only full instantiations should be marked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug middle-end/44133] [4.5/4.6 Regression] Uninit warning regression with new SRA
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-05-17 12:48 --- Subject: Bug 44133 Author: jamborm Date: Mon May 17 12:48:34 2010 New Revision: 159482 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159482 Log: 2010-05-17 Martin Jambor mjam...@suse.cz PR middle-end/44133 * tree-sra.c (create_access_replacement): New parameter rename, mark the replaement for renaming only when it is true. (get_access_replacement): Pass true in the rename parameter of create_access_replacement. (get_unrenamed_access_replacement): New function. (replace_uses_with_default_def_ssa_name): New parameter racc, get the replacement declaration from it. * testsuite/gcc.dg/tree-ssa/pr44133.c: New test. * testsuite/gcc.dg/tree-ssa/sra-9.c: Make the scan regular expression more precise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44133.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-9.c trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-05-17 12:53
---
On Mac OS X (all versions), the correct fix is to use _NSGetEnviron() instead
of extern variable environ, and to include crt_externs.h. Example of use:
#include stdlib.h
#include string.h
#include crt_externs.h
int main (void)
{
// Instead of: extern char **environ;
#define environ (*_NSGetEnviron())
char **env = malloc (3 * sizeof(char *));
env[0] = strdup (VAR1=this is variable one);
env[1] = strdup (PATH=/dev/null);
env[2] = NULL;
environ = env;
system (/usr/bin/env);
return 0;
}
(see http://www.gnu.org/software/gnulib/manual/html_node/environ.html)
So, a possible patch (protecting target-specific code with #idef's; I don't
know if that's the style libjava maintainers would like best) is:
Index: java/lang/natPosixProcess.cc
===
--- java/lang/natPosixProcess.cc(revision 159481)
+++ java/lang/natPosixProcess.cc(working copy)
@@ -54,7 +54,12 @@
using gnu::java::nio::channels::FileChannelImpl;
using namespace java::lang;
+#ifdef __APPLE__
+#include crt_externs.h
+#define environ (*_NSGetEnviron())
+#else
extern char **environ;
+#endif
static char *
new_string (jstring string)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org, tromey at redhat dot
||com, aph at redhat dot com
Last reconfirmed|2009-01-13 01:03:10 |2010-05-17 12:53:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812
[Bug c/44165] New: 5/15/2010 snapshot build failure on hppa Linux
When I attempt to compile the snapshot of 5/15/2010 on an HPPA workstation under Debian Linux 5.0 I get the following messages: checking whether the C compiler works... configure: error: in `/home/mrichmon/gcc-4.6-20100515/g95/hppa1.1-unknown-linux-gnu/libgomp': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-stage1-target-libgomp] Error 1 make[2]: Leaving directory `/home/mrichmon/gcc-4.6-20100515/g95' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/mrichmon/gcc-4.6-20100515/g95' make: *** [all] Error 2 Error running make -- Summary: 5/15/2010 snapshot build failure on hppa Linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov GCC build triplet: hppa1.1-unknown-linux-gnu GCC host triplet: hppa1.1-unknown-linux-gnu GCC target triplet: hppa1.1-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44165
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #4 from maxime at altribe dot org 2010-05-17 13:10 --- (In reply to comment #3) The boost folks may be able to tell if they at any place copy a function_buffer object via the assignment operator. It seems so. From Peter Dimov : [...] after stepping through the code, it turns out that function_buffer is indeed assigned directly, due to the fact that __has_trivial_copy and __has_trivial_destructor report true for the stored function object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #23 from jakub at gcc dot gnu dot org 2010-05-17 13:24 --- Created an attachment (id=20679) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20679action=view) gcc46-pr42347.patch Ah, I see. returnjump_p is considered onlyjump_p, yet it has side-effect that prevent it from being optimized away into a normal return or jump to return. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug target/44075] __builtin_eh_return miscompiled
--- Comment #2 from bergner at gcc dot gnu dot org 2010-05-17 13:41 --- Subject: Bug 44075 Author: bergner Date: Mon May 17 13:41:22 2010 New Revision: 159487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159487 Log: Backport from mainline: 2010-05-14 Alan Modra amo...@gmail.com PR target/44075 * config/rs6000/rs6000.c (struct machine_function): Reorder fields for better packing. Add lr_save_state. (rs6000_ra_ever_killed): Return lr_save_state if set. (rs6000_emit_eh_reg_restore): Set lr_save_state. Modified: branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44075
[Bug c/44166] New: -fvisibility=protected doesn't work?
-fvisibility=protected doesn't work?
a...@xlin2:~$ cat 1.c
void F1() { }
void* F2() { return F1; }
j...@xlin2:~$ $HOME/bin/gcc 1.c -fPIC -shared -fvisibility=protected
/usr/bin/ld: /tmp/cc0d6EQ3.o: relocation R_386_GOTOFF against protected
function `F1' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
j...@xlin2:~$ $HOME/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/jay/bin/gcc
COLLECT_LTO_WRAPPER=/home/jay/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /src/gcc-4.5.0/configure -verbose -prefix=/home/jay
-disable-bootstrap -disable-multilibs
Thread model: posix
gcc version 4.5.0 (GCC)
--
Summary: -fvisibility=protected doesn't work?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell 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=44166
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-17 13:43 --- (In reply to comment #4) In my powerpc-apple-darwin9 tree I have the patch in http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a quite long time OK, might be worth double-checking - both parts are needed. (and I guess it is not applied in the native tree of regress). nope. that's just trunk. With revision 159371, I see the same failures as regress. These failures disappear if I revert revision 159371 without any other change in my tree. I have clean libgomp results and only LTO FE fails, on powerpc-apple-darwin9 @159476 with http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html but... *without* changing varpool.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug target/44166] -fvisibility=protected doesn't work?
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 13:47 --- Can you give the output of ld --version ? There might have been a binutils bug about this before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44166
[Bug target/44166] -fvisibility=protected doesn't work?
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-17 13:49 --- *** This bug has been marked as a duplicate of 37611 *** -- 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=44166
[Bug target/37611] invalid relocation R_386_GOTOFF when using protected function pointers
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-05-17 13:49 --- *** Bug 44166 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jay dot krell at cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug c++/44167] New: ICE in tsubst_copy at cp/pt.c:10077
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
Code:
// file: testcase.cc
#include tuple
templateunsigned int N
struct Apply_aux
{
templatetypename F, typename T, typename... X
static auto apply(F f, const T t, X... x)
- decltype(Apply_auxN-1::apply(f, t, std::getN-1(t), x...))
{
return Apply_auxN-1::apply(f, t, std::getN-1(t), x...);
}
};
template
struct Apply_aux0
{
templatetypename F, typename T, typename... X
static auto apply(F f, const T, X... x)
- decltype(f(x...))
{
return f(x...);
}
};
templatetypename F, typename T
auto apply(F f, const T t)
- decltype(Apply_auxstd::tuple_sizeT::value::apply(f, t))
{
return Apply_auxstd::tuple_sizeT::value::apply(f, t);
}
int f(int p1, double p2)
{
return 0;
}
int main()
{
apply(f, std::make_tuple(1, 2.0));
}
// end file: testcase.cc
Output of 'gcc -v':
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
Output of 'uname -a':
Linux wwz-comamh-166 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC
2010 i686 GNU/Linux
Thanks,
Marc
--
Summary: ICE in tsubst_copy at cp/pt.c:10077
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot hofmann at gmail dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug c++/44167] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #1 from marc dot hofmann at gmail dot com 2010-05-17 13:51 --- Created an attachment (id=20680) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20680action=view) Testcase source file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug c++/44168] New: ICE in tsubst_copy at cp/pt.c:10077
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.
Code:
// file: testcase.cc
#include tuple
templateunsigned int N
struct Apply_aux
{
templatetypename F, typename T, typename... X
static auto apply(F f, const T t, X... x)
- decltype(Apply_auxN-1::apply(f, t, std::getN-1(t), x...))
{
return Apply_auxN-1::apply(f, t, std::getN-1(t), x...);
}
};
template
struct Apply_aux0
{
templatetypename F, typename T, typename... X
static auto apply(F f, const T, X... x)
- decltype(f(x...))
{
return f(x...);
}
};
templatetypename F, typename T
auto apply(F f, const T t)
- decltype(Apply_auxstd::tuple_sizeT::value::apply(f, t))
{
return Apply_auxstd::tuple_sizeT::value::apply(f, t);
}
int f(int p1, double p2)
{
return 0;
}
int main()
{
apply(f, std::make_tuple(1, 2.0));
}
// end file: testcase.cc
Output of 'gcc -v':
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
Output of 'uname -a':
Linux wwz-comamh-166 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC
2010 i686 GNU/Linux
Thanks,
Marc
--
Summary: ICE in tsubst_copy at cp/pt.c:10077
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot hofmann at gmail dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44168
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #4 from dodji at gcc dot gnu dot org 2010-05-17 13:54 --- Created an attachment (id=20681) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20681action=view) Don't warn for integral constants Jakub, this one line patch implements the first idea which is to not warn for integral constants, as far as Wunused_but_set_variable is concerned. I have tested it only for the reported error case. I haven't regtested it yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug c++/44167] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-17 13:55 --- *** Bug 44168 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug c++/44167] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #3 from marc dot hofmann at gmail dot com 2010-05-17 13:55 --- Created an attachment (id=20682) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20682action=view) Preprocessed file. Created with: g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug c++/44168] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 13:55 --- *** This bug has been marked as a duplicate of 44167 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44168
[Bug c++/44167] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-17 14:00 --- 4.5 doesn't ICE pr44167.cc: In function 'int main()': pr44167.cc:7:44: sorry, unimplemented: use of 'type_pack_expansion' in template pr44167.cc:41:35: error: no matching function for call to 'apply(int ()(int, double), std::tupleint, double)' possibly a dup of bug 43382 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug c++/44167] ICE in tsubst_copy at cp/pt.c:10077
--- Comment #5 from redi at gcc dot gnu dot org 2010-05-17 14:03 --- (In reply to comment #4) possibly a dup of bug 43382 actually I don't think it is a dup, because 43382 crashes with 4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-05-17 14:28 --- The problem from comment #12 seems to be back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug testsuite/44159] CPU options cause testsuite failures
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 14:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug rtl-optimization/44169] New: Wrong code while generating TLS offsets
libgomp testsuite fails with a segfault. It segfaults in gomp_resolve_num_threads(), accessing the second TLS value. The first access: .LBB28: .file 2 ../../../src/libgomp/libgomp.h .loc 2 380 0 bcl 20,31,$+8 .long _GLOBAL_OFFSET_TABLE_-$ mflr 9 lwz 0,0(9) add 9,9,0 lwz 9,gomp_tls_d...@got@tprel(9) add 9,9,gomp_tls_d...@tls lwz 9,40(9) The second: .LBE27: .loc 1 47 0 cmpwi 7,3,1 beq- 7,.L37 .LVL32: .loc 1 49 0 bcl 20,31,$+8 .long _GLOBAL_OFFSET_TABLE_-$ mflr 9 add 9,9,0 lwz 9,gomp_tls_d...@got@tprel(9) add 9,9,gomp_tls_d...@tls lwz 0,28(9) After mflr, the lwz is missing. r0 has the offset from last lr which is wrong here. The RTL in tc.c.185r.cprop_hardreg has the lwz included, the next pass tc.c.186r.dce does not anymore. lwz gets not killed if I used -mcpu=power or -mcpu=e300c3. I used -mcpu=8540 which is default for powerpc-linux-gnuspe. -O1 was used in the test case. The complete cmd line: /build/bigeasy/gcc-4.4-4.4.4/build/./gcc/xgcc \ -B/build/bigeasy/gcc-4.4-4.4.4/build/./gcc/ \ -B/usr/powerpc-linux-gnuspe/bin/ \ -B/usr/powerpc-linux-gnuspe/lib/ \ -isystem \ /usr/powerpc-linux-gnuspe/include \ -isystem \ /usr/powerpc-linux-gnuspe/sys-include \ -Werror \ -pthread \ -ftls-model=initial-exec \ -O2 \ -pthread \ -fPIC \ -DPIC \ tc.c \ -o \ tc.S \ -S \ -mcpu=8540 \ -O1 \ -fdump-rtl-all \ -c \ A side note: the complete file (parallel.c from libgomp) was compiled with -O2 and the lwz was killed between parallel.c.174r.postreload and parallel.c.176r.split2. -- Summary: Wrong code while generating TLS offsets Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #1 from gcc at breakpoint dot cc 2010-05-17 15:44 --- Created an attachment (id=20683) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20683action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #2 from gcc at breakpoint dot cc 2010-05-17 15:44 --- Created an attachment (id=20684) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20684action=view) rtl pass 185r.cprop_hardreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #3 from gcc at breakpoint dot cc 2010-05-17 15:45 --- Created an attachment (id=20685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20685action=view) rtl pass 186r.dce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-17 15:50 --- (In reply to comment #4) (In reply to comment #3) The boost folks may be able to tell if they at any place copy a function_buffer object via the assignment operator. It seems so. From Peter Dimov : [...] after stepping through the code, it turns out that function_buffer is indeed assigned directly, due to the fact that __has_trivial_copy and __has_trivial_destructor report true for the stored function object. Which means that it is either a C++ frontend bug not protecting this aggregate assignment properly or a bug in Boost as the functor type stored to function_buffer is not a member of the union. The functor types are for example seen in const functor_type* in_functor = reinterpret_castconst functor_type*(in_buffer.data); new ((void*)out_buffer.data) functor_type(*in_functor); but functor_type (a template param) is not a member of said union. People were arguing that the char member in the union should make this valid, but nothing in the C++ frontend communicates that to the alias analysis stage. People also were arguing only a character array member would qualify, possibly covering the whole union in size. A workaround for boost can be constructed following the fix for PR42832. Due to an unrelated bug using memcpy for the assingment won't work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2010-05-17 09:39:31 |2010-05-17 15:50:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug c++/44170] New: compiler segfaults in specialization of template destructor
The following code crashes the compiler with this message:
g++ gccbug.cpp
gccbug.cpp: In destructor 'VEXPRT::~VEXPR() [with T = VECTOR_PAIR]':
gccbug.cpp:32: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
struct VECTOR {};
struct VECTOR_PAIR
{
VECTOR_PAIR(VECTOR v1, VECTOR v2) : first(v1), second(v2) {}
VECTOR first;
VECTOR second;
};
template class T
struct VEXPR
{
VEXPR(T leaf) : obj(leaf) {}
~VEXPR() {}
T obj;
};
VEXPRVECTOR_PAIR operator,(VEXPRVECTOR v1, VEXPRVECTOR v2)
{
VECTOR_PAIR* vp = new VECTOR_PAIR(v1.obj, v2.obj);
return VEXPRVECTOR_PAIR(*vp);
}
template
VEXPRVECTOR_PAIR::~VEXPRVECTOR_PAIR()
{
VECTOR_PAIR *vp = obj;
delete vp;
}
--
Summary: compiler segfaults in specialization of template
destructor
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adavis at ti dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44170
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-17 15:57 --- Basically the middle-end sees this the same as int i = 1, j; float *p = new (i) float(0.0); j = i; return *reinterpret_castfloat *(j); and you expect to return 0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug c++/44170] compiler segfaults in specialization of template destructor
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 16:34 --- 4.1.1 is no longer maintained. This doesn't cause an ICE with 4.4.3 or 4.5.0 pr44170.cc:29: error: specialization of 'VEXPRT::~VEXPR() [with T = VECTOR_PAIR]' after instantiation -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44170
[Bug target/42904] Attribute dllexport should imply externally_visible
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-17 17:02 --- Yes, it certainly does, in fact it omits to compile any definition for 'foo' whatsoever! But isn't this the expected behaviour of using '-fwhole-program' on something that is not the whole program? I'm not sure if the option is supposed to be suitable for use when building a shared library, I'll ask on the mailing list. -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org Known to work||4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42904
[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-17 17:09 --- The patch in comment #5 fixes the ICE without side effects (AFAICT!-), but it does not fix PR43895 (see comments #3 and #4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug middle-end/44102] ICE with asm goto + __builtin_unreachable () in C++
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-17 17:18 --- Subject: Bug 44102 Author: jakub Date: Mon May 17 17:18:24 2010 New Revision: 159495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159495 Log: PR middle-end/44102 * cfgcleanup.c (try_optimize_cfg): When removing trivially empty bb with no successors, move footer whenever in IR_RTL_CFGLAYOUT mode, not just when CLEANUP_CFGLAYOUT, and when in IR_RTL_CFGRTL add BARRIER after previous bb if needed. * g++.dg/ext/asmgoto1.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/asmgoto1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44102
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #24 from jakub at gcc dot gnu dot org 2010-05-17 17:20 --- Subject: Bug 42347 Author: jakub Date: Mon May 17 17:19:46 2010 New Revision: 159496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159496 Log: PR bootstrap/42347 * cfglayout.c (fixup_reorder_chain): Allow returnjump_p to have no fallthru edge. * gcc.c-torture/compile/pr42347.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42347.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfglayout.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-17 17:25 --- Subject: Bug 44108 Author: jakub Date: Mon May 17 17:24:32 2010 New Revision: 159497 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159497 Log: PR c++/44108 * decl.c (compute_array_index_type): Call mark_rvalue_use. * c-c++-common/Wunused-var-8.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wunused-var-8.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #25 from jakub at gcc dot gnu dot org 2010-05-17 17:26 --- Subject: Bug 42347 Author: jakub Date: Mon May 17 17:26:22 2010 New Revision: 159499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159499 Log: PR bootstrap/42347 * cfglayout.c (fixup_reorder_chain): Allow returnjump_p to have no fallthru edge. * gcc.c-torture/compile/pr42347.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/asmgoto1.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cfgcleanup.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug debug/44171] New: gcc -gdwarf-2 -dA unconditionally emits .ascii
In testing patches to support Solaris 9/x86 with Sun as on Solaris 11/x86, I noticed that several testcases with -gdwarf-2 -dA failed, producing invalid assembler output. I could trace this down to dwarf2asm.c (dw2_asm_output_nstring) unconditionally emitting .ascii, which the Solaris 8/x86 as doesn't understand. This dates back to the initial version of dwarf2asm.c ASM_OUTPUT_ASCII cannot be used as is since w2_asm_output_nstring adds a comment after the string without a preceding newline. My current solution is to add a variant of ASM_OUTPUT_ASCII, ASM_OUTPUT_ASCII_NONL, with an additional fourth arg NONL which controls whether or not the newline is printed. I still have to disentangle the different versions of ASM_OUTPUT_ASCII since the initial version (which changed config/i386/sysv4.h) ysed .byte directives to emit the string, which breaks the corresponding testcases, and didn't emit empty strings at all. -- Summary: gcc -gdwarf-2 -dA unconditionally emits .ascii Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2* GCC host triplet: i386-pc-solaris2* GCC target triplet: i386-pc-solaris2* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44171
[Bug c++/44172] New: Compiling never ends
I was trying to create a tree. I have realized that the following code makes
the g++ compiler to never stop compilation.
#include iostream
#include fstream
#include vector
#include cassert
using namespace std;
namespace gumocap{
namespace core{
namespace tree{
templateclass T
class Node: public vector NodeT*
{
public:
/**
*/
Node(){_parent=NULL;}
/**
*/
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
/**
*/
~Node(){
for(unsigned int i=0;ithis-size();i++) delete (*this)[i];
}
/**
*/
Node(const Node TN) {
_parent=TN._parent;
_data=TN._data;
for(unsigned int i=0;iTN.size();i++){
NodeT *n=new NodeT( *TN[i]);
n-parent=this;
}
}
/**Adds a new child and returns it
*/
NodeT * addChild(T val){
NodeT* n=new NodeT(val,this);
push_back(n);
return n;
}
unsigned int getNChildren()const{
unsigned int nChildren=0;
for(unsigned int i=0;ithis-size();i++)
nChildren+=(*this)[i].getNChildren();
return nChildren+this-size();
}
/**
*/
Toperator ()(){return _data;}
/**
*/
T getVal(){return _data;}
/**
*/
bool isLeaf(){return this-size()==0;}
/**
*/
unsigned int getDepth()const{
if (_parent==NULL) return 0;
else return _parent-getDepth()+1;
}
/**
*/
NodeT* getParent() {return _parent;}
/**
*/
friend ostream operator(ostream str,const NodeT N)
{
unsigned int depth=N.getDepth();
strlll -depthendl;
// if (N.parent!=NULL)
strthis =N PARENT=N._parentendl;
for(unsigned int i=0;idepth;i++) str ;
str( N.size() N._data ;
for(unsigned int i=0;iN.size();i++)
str *N[i];
for(unsigned int i=0;idepth;i++) str ;
str ) endl;
return str;
}
/**Saves in a binary streeam
*/
void toStream(ostream str)
{
int s=this-size();
str.write((char*)s,sizeof(int));
for(unsigned int i=0;ithis-size();i++)
(*this)[i]-toStream(str);
str.write((char*)_data,sizeof(T));
}
/**
*/
void fromStream(istream str)
{
int s;
str.read((char*)s,sizeof(int));
this-resize(s);
for(unsigned int i=0;ithis-size();i++){
(*this)[i]=new NodeT();
(*this)[i]-parent=this;
(*this)[i]-fromStream(str);
}
str.read((char*)_data,sizeof(T));
}
private:
Node *_parent;
T _data;
};
templateclass T
class Iterator: public vector NodeT*
{
public:
/**
*/
Iterator(){ }
/**
*/
Iterator(const Iterator it): vector NodeT* (it) { }
/**
*/
T operator()(unsigned int i){return (*this)[i]-getVal();}
};
/**\brief Simple tree
*/
templateclass T
class Tree
{
public:
/**
*/
Tree();
/**
*/
~Tree();
/**
*/
Tree(const Tree Tr);
/**
*/
Tree operator =(const Tree Tr);
/**
*/
IteratorT getIterator( )const;
/**
*/
NodeT* setRoot(const T v);
/**
*/
unsigned int size()const;
/**
*/
void clear();
/**
*/
void toStream(ostream str)
{
if (_root==NULL){
int w=0;
str.write((char*)w,sizeof(int));
}
else{
int w=1;
str.write((char*)w,sizeof(int));
_root-toStream(str);
}
}
/**
*/
void fromStream(istream str)
{
clear();
int w=0;
str.read((char*)w,sizeof(int));
if (w==1){
_root=new NodeT();
_root-fromStream(str);
}
}
/**
*/
friend ostream operator(ostream str,const Tree Tr)
{
if (Tr._root!=NULL) str 1 *(Tr._root)endl;
else str 0 endl;
return str;
}
/**
*/
friend istream operator(istream str,Tree Tr)
{
string parn;
strparn;
Tr.clear();
if (parn==1) strTr;
return str;
}
private:
/**
*/
NodeT * _root;
void getIteratorInDepth_subtree(NodeT *n,IteratorT It)const;
};
/**
*/
templateclass T
TreeT::Tree()
{
_root=NULL;
}
/**
*/
templateclass T
TreeT::~Tree()
{
if (_root!=NULL) delete _root;
}
/**
*/
templateclass T
TreeT::Tree(const Tree Tr)
{
if (Tr._root!=NULL) _root=new NodeT( *Tr._root);
else _root=NULL;
}
/**
*/
templateclass T
TreeT TreeT::operator =(const Tree Tr)
{
clear();
if (Tr._root!=NULL)
_root=new NodeT(*Tr._root);
return *this;
}
/**
*/
templateclass T
NodeT * TreeT::setRoot(const T v)
{
if (_root==NULL) _root=new NodeT( v);
else (*_root)()=v;
return _root;
}
/**
*/
templateclass T
IteratorT TreeT::getIterator( )const
{
IteratorT ret;
getIteratorInDepth_subtree(_root,ret);
return ret;
}
/**
*/
templateclass T
void TreeT::getIteratorInDepth_subtree(NodeT *n,IteratorT It)const
{
if( n==NULL) return;
It.push_back(n);
for(unsigned int i=0;in-size();i++)
getIteratorInDepth_subtree(
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #26 from jakub at gcc dot gnu dot org 2010-05-17 17:31 --- Subject: Bug 42347 Author: jakub Date: Mon May 17 17:30:54 2010 New Revision: 159500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159500 Log: PR bootstrap/42347 * cfglayout.c (fixup_reorder_chain): Allow returnjump_p to have no fallthru edge. * gcc.c-torture/compile/pr42347.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr42347.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cfglayout.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-17 17:33 --- The http://gcc.gnu.org/viewcvs?root=gccview=revrev=159499 commit was actually for PR44102. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug middle-end/44102] ICE with asm goto + __builtin_unreachable () in C++
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-17 17:34 --- On branches/gcc-4_5-branch fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159499 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44102
[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 17:41 --- (In reply to comment #6) but it does not fix PR43895 (see comments #3 and #4). ... which I take as an indication that the two are indeed not so much related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug c++/44172] Compiling never ends
--- Comment #1 from dougsemler at gmail dot com 2010-05-17 17:46 ---
This is the offender:
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the * (it should be the following, right?
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
Every iteration of this is producing a new template instantiation attempt
(recursively).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug c++/44172] Compiling never ends
--- Comment #2 from rmsalinas at uco dot es 2010-05-17 17:50 ---
Subject: Re: Compiling never ends
My god! you work really fast!
Yes, I've found the error just few seconds ago.
Great work!
dougsemler at gmail dot com escribió:
--- Comment #1 from dougsemler at gmail dot com 2010-05-17 17:46 ---
This is the offender:
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the * (it should be the following, right?
Node(const T v,NodeT* Tparent=NULL) {_parent=Tparent;_data=v;}
Every iteration of this is producing a new template instantiation attempt
(recursively).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #10 from davek at gcc dot gnu dot org 2010-05-17 18:25 --- Re-opening. It turns out that GCC fails to actually apply the dllexport attribute to TLS control vars. So solving the binutils problem allows auto-export of a TLS variable to work, but as auto-export gets disabled in the presence of any explicit dllexport directives, this isn't an effective solution. I believe the problem needs to be addressed in config/i386/winnt.c#i386_pe_encode_section_info() -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 18:25:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/42904] Attribute dllexport should imply externally_visible
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-17 18:28 --- Consensus seems to be that this is indeed how it's meant to work, but that figuring out which are the externally visible functions and marking them automatically would be a nice enhancement that would make the -fwhole-program option work on libraries, so I think we should do it. -- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 18:28:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42904
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #7 from ro at gcc dot gnu dot org 2010-05-17 18:29 --- Posted new patch. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||05/msg01260.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug c++/44172] Compiling never ends
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-17 18:32 --- Ok. -- 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=44172
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #3 from zsojka at seznam dot cz 2010-05-17 18:45 --- Stil appears in r159500, x86_64-linux. Uninitialised read is at gcc/haifa-sched.c:1589, more exactly it is read of BLOCK_FOR_INSN (insn) When gcc/haifa-sched.c:1589 is changed to: insn != NULL_RTX (printf(%p %p\n, (void *)BLOCK_FOR_INSN (insn), (void *)BLOCK_FOR_INSN (after)), BLOCK_FOR_INSN (insn) == BLOCK_FOR_INSN (after)); it outputs (for original testcase): $ /mnt/sda1/build-159500-test/gcc/cc1 -fschedule-insns -fsched-pressure testcase.c -quiet 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0xafafafafafafafaf 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0xafafafafafafafaf 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0x7fcc29e98270 0xafafafafafafafaf 0x7fcc29e98270 However, I wasn't able to cause any difference in generated code even for more complex testcases, when the condition is true for BLOCK_FOR_INSN (insn) == 0xafafafafafafafaf - that is, the uninitialised value is the same as BLOCK_FOR_INSN (after) by luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations
--- Comment #10 from siarhei dot siamashka at gmail dot com 2010-05-17 18:48 --- Maybe I'm too impatient, but is there anything that prevents this patch from getting committed to SVN? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug c/44173] New: configure -disable-fixincludes doesn't work
/src/gcc-4.5.0/configure -verbose -disable-shared -enable-static -disable-bo otstrap -disable-fixincludes -prefix=$HOME /bin/sh /src/gcc-4.5.0/gcc/../move-if-change tmp-fixinc_list fixinc_list echo timestamp s-fixinc_list make[2]: *** No rule to make target `../build-i686-pc-linux-gnu/fixincludes/fixinc.sh', needed by `stmp-fixinc'. Stop. make[2]: Leaving directory `/home/jay/obj/gcc2/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/jay/obj/gcc2' make: *** [all] Error 2 j -- Summary: configure -disable-fixincludes doesn't work Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44173
[Bug bootstrap/44173] configure -disable-fixincludes doesn't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 18:53 --- I don't think this can ever work except when you know 100% that the headers don't need to be fix included. Only newer glibc don't need it and newlib either. But the majority of the other OS's need it really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44173
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #7 from pdimov at gmail dot com 2010-05-17 19:10 ---
(In reply to comment #6)
Basically the middle-end sees this the same as
int i = 1, j;
float *p = new (i) float(0.0);
j = i;
return *reinterpret_castfloat *(j);
and you expect to return 0.0.
The int/float example does violate the aliasing rules, but I don't think that
it properly describes what's happening.
I see it more like a combination of the following two examples:
#include iostream
struct X
{
char data[ sizeof( float ) ];
};
int main()
{
X x1;
new( x1.data ) float( 3.14f );
X x2 = x1;
std::cout *(float const*)x2.data std::endl;
}
and
#include iostream
union Y
{
int i;
float f;
};
int main()
{
Y y1;
y1.f = 3.14f;
Y y2 = y1;
std::cout y2.f std::endl;
}
I don't think either of them violates the standard.
--
pdimov at gmail dot com changed:
What|Removed |Added
CC||pdimov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-05-17 19:17 --- The first example I think does as there is no way to transfer the dynamic type via the struct copy. The second one does not as the union still has a field that is float and it is only unspecified behavior if you access the other field in the union (IIRC). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug rtl-optimization/44174] New: [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
/* { dg-do compile } */
/* { dg-options -O2 -fpic { target fpic } } */
int f0 (int, int, int, int, int);
int f1 (void);
void
f2 (void)
{
unsigned v1, v2, v3, v4;
__asm__ ( : =a (v1), =d (v2), =c (v3), =r (v4));
f0 (f1 (), f1 (), f1 (), f1 (), (v4 8) 0xff);
}
used to compile with -m32 -O2 -fpic in 4.3, but starting with 4.4 fails with:
/tmp/u.c: In function 'void f2()':
/tmp/u.c:11:60: error: can't find a register in class 'CLOBBERED_REGS' while
reloading 'asm'
/tmp/u.c:11:60: error: 'asm' operand has impossible constraints
while it should be fine to use esi or edi for that.
--
Summary: [4.4/4.5/4.6 Regression] can't find a register in class
'CLOBBERED_REGS' while reloading 'asm'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-17 19:29 --- DJ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
[Bug c++/44175] New: [C++0x] decltype sometimes cannot recurse
See attached testcase. Several things can happen when decltype is used in a function template's return type to refer to another specialization of the same template. - The right thing (not easily produced from the current code, but see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162) - Non-production of a candidate, a la SFINAE - g++: Internal error: Segmentation fault (program cc1plus). This happens for me with the given testcase. As the recursive type must be dependent, it should be evaluated at the point of instantiation. Using the template's identifier even before it has been defined shouldn't be an issue. The behavior seems to depend on what types are passed to the template in question. Type deduction doesn't seem to matter. Types involving only primitives are likely to quietly fail. Types involving classes may succeed or crash. For example, if I adjust fta,2 to ftint,2, no crash. -- Summary: [C++0x] decltype sometimes cannot recurse Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: potswa at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
--- Comment #1 from potswa at mac dot com 2010-05-17 19:38 --- Created an attachment (id=20686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20686action=view) recursive decltype crashes g++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-17 19:40 --- Many thanks. Let's add Jason in CC. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 19:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
[Bug c++/44108] [4.6 Regression] -Wunused-but-set-variable does not consider array sizing use of a const variable
--- Comment #6 from dodji at gcc dot gnu dot org 2010-05-17 19:45 --- This should be fixed in trunk (4.6) -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44108
[Bug c++/44158] [C++0x] wrong overload resolution for copy-initialization from an rvalue
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-17 19:54 --- Subject: Bug 44158 Author: jason Date: Mon May 17 19:53:45 2010 New Revision: 159508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159508 Log: PR c++/44158 * call.c (build_over_call): Don't do bitwise copy for move ctor. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/rv-trivial-bug.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
[Bug c++/44157] [C++0x] GCC wrongly takes a std::initializer_list argument as non-deduced context
--- Comment #1 from jason at gcc dot gnu dot org 2010-05-17 19:54 --- Subject: Bug 44157 Author: jason Date: Mon May 17 19:53:55 2010 New Revision: 159509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159509 Log: PR c++/44157 * call.c (build_over_call): Limit init-list deduction warning to cases where the argument is actually an init-list. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist34.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44157
[Bug testsuite/44176] New: dg-cmp-results.sh contains several unportabilities
contrib/dg-cmp-results.sh contains several unportabilities: * sort -s seems to be specific to GNU sort, neither POSIX.1 nor the vendor tools on Solaris 2, IRIX 6 or Tru64 UNIX have it. * sed support for EREs (via -r or -E) isn't present on those platforms either. -- Summary: dg-cmp-results.sh contains several unportabilities Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44176
[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 19:59 --- Subject: Bug 43990 Author: janus Date: Mon May 17 19:58:48 2010 New Revision: 159511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159511 Log: 2010-05-17 Janus Weil ja...@gcc.gnu.org PR fortran/43990 * trans-expr.c (gfc_conv_structure): Remove unneeded and buggy code. This is now handled via 'gfc_class_null_initializer'. 2010-05-17 Janus Weil ja...@gcc.gnu.org PR fortran/43990 * gfortran.dg/class_21.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_21.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug fortran/43990] [OOP] ICE in output_constructor_regular_field, at varasm.c:4995
--- Comment #9 from janus at gcc dot gnu dot org 2010-05-17 20:05 --- Fixed with r159511. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
[Bug c++/13682] Compile error with cstdio: fgetpos not declared on AIX
--- Comment #9 from pedzsan at gmail dot com 2010-05-17 20:05 --- The general reply to this was your GCC was not compiled for your system. That isn't the case. I have two compiles on two different systems. One if version 4.5.0 and the other version is 4.3.1 compiled on AIX 5.3 TL05 CSP. The 4.5.0 version I just finished compiling and it still has the problem. -- pedzsan at gmail dot com changed: What|Removed |Added CC||pedzsan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13682
[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
--- Comment #3 from potswa at mac dot com 2010-05-17 20:10 --- Created an attachment (id=20687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20687action=view) recursive decltype crashes g++ fix minor error (no change in behavior) -- potswa at mac dot com changed: What|Removed |Added Attachment #20686|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #9 from pdimov at gmail dot com 2010-05-17 20:12 --- But the standard says in [basic.types] that For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as obj1. float is a trivially copyable type. Copying X results in copying the bytes of X::data (because the default copy constructor of a class does a memberwise copy, and the default copy constructor of an array does an elementwise copy). Therefore, the underlying bytes of the object of type float, initialized at x1.data, are copied into x2.data, which then must, if interpreted as a float, hold the same value as the original object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug fortran/44177] New: gfortran internal data assignment error cause found
System info: uname -a CYGWIN_NT-5.1 harryr-pc 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin gfortran -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure --srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.3.4 20090804 (release) 1 (GCC) When compiling a fortran module where an array was declared twice, e.g. real foo(2) /2*0.0/ and then data foo /0.0, 0.0/ I got this error: f951: internal compiler error: in gfc_assign_data_value_range, at fortran/data.c:562 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Removing the first data declaration fixed the problem. I presume you will agree a better error message should be given? -- Summary: gfortran internal data assignment error cause found Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: harry dot rockefeller at flightsafety dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44177
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-17 20:22 --- Created an attachment (id=20688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20688action=view) Work-In-Progress... here is a modification of comment #7 which gets us a bit further .. but I'm a bit stumped in some areas. There are a couple of extra test-cases that I'm using locally to help testing (probably not for a final patch). === A. this checks for emutls vars in VAR/PARAM cases in gimplify. B. This moves the creation of the init template out of assemble_variable into emutls_decl () - as soon as we see a DECL_INITIAL we do it .. and then we mark the original decl with DECL_INITIAL=error_mark so that we still get a parse error if the user tries to init twice. C. emutls_final () carries out a pass through the emutls control vars finalizing them if they are not already done. D. the substitution of the control var is removed from gcc/expr.c. Mostly - this is working for tls.exp=* unfortunately -lto/-whopr are still killing the control vars (even @ O0) Problems : 1/ It doesn't work with the race condition patch applied to tree-profile.c -- this is because tree-profile is emitting gimple directly and assuming that it doesn't need gimplification (and I've not been able to figure out how to fix that yet). 2/ It breaks libgomp quite a bit ... I'm guessing that there's another spot in gimplify.c that we need to apply the substitution but - can't see it yet .. ;) anyway ... Honza .. I'm sure you will see the solutions 10^6 times quicker than me... *** this is experimental *** (some way from a complete solution) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #7 from burnus at gcc dot gnu dot org 2010-05-17 20:22 --- Propagate comment from PR 43990: There seems to be an inconsistency with CLASS with POINTER or ALLOCATABLE attribute: Is class.$DATA or class the pointer variable. If one adds b = ALLOCATED(x) one finds: x.a.$data = 0B; ! Default initialization sets class.$data to NULL D.1577 = x-a; ! ALLOCATED check looks at (class != NULL) b = D.1577 != 0B; Which does not make sense. [This might be unrelated to the ICE.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-17 20:24 --- A little more debugging. I traced through the true_dependence call that is returning 0 when it should return 1. We end up calling rtx_refs_may_alias_p at the end. This calls refs_may_alias_p_1, which calls indirect_ref_may_alias_decl_p which discovers that we have different non-overlapping alias sets, and it declares that there is no aliasing here. This is last-resort TBAA being used here. We have different alias sets, because one reference is to ... arg 0 var_decl 0xb7d4eba0 vtab$s_bar type record_type 0xb7d4ea80 vtype$s_bar BLK ... and the other is to ... arg 0 indirect_ref 0xb7d74c94 type record_type 0xb7d4e060 vtype$foo BLK ... It appears that the Fortran front end is deliberately confusing the types here, because in the .003t.original dump file I see a.$vptr = (struct vtype$foo *) vtab$s_bar; a.$data = (struct foo *) c; a.$vptr-doit (a); So either the fortran front end needs to get the types right, or else the fortran front end needs to explain to the alias code that these apparently unrelated types do alias. Or maybe the alias code needs to be extended to recognize Fortran OOP types that can alias each other. I didn't look at this. Along the way, I did discover another place where it appears that we can solve the problem. After the get_addr calls in true_dependence, we have mem_addr (if_then_else:DI (eq (value:BI 58:4011 @0x8b22b50/0x8b360e0) (const_int 0 [0])) (plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c) (const_int 24 [0x18])) (value:DI 57:57 @0x8b22b44/0x8b360c4)) insn 103 x_addr (plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c) (const_int 24 [0x18])) These addresses obviously conflict. Unfortunately, neither memrefs_conflict_p nor rtx_equal_for_memref_p have any support for if_then_else inside an address. If one of them was modified to check for an if_then_else and then recursively compare against both arms of the if_then_else, then that would solve the problem too. This would prevent us from falling through to the last-resort TBAA code that isn't work as desired here. I'm not planning to do any other work on this in the short term, as I have other IA-64 problems I need to try to fix first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
