[Bug c++/42256] [4.5 Regression] 483.xalancbmk fails to link
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-03 08:03 --- Subject: Bug 42256 Author: jakub Date: Thu Dec 3 08:03:36 2009 New Revision: 154937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154937 Log: PR c++/42256 * optimize.c (maybe_clone_body): Call emit_associated_thunks after expand_or_defer_fn_1. * g++.dg/inherit/thunk11.C: New test. * g++.dg/inherit/thunk11.h: New file. * g++.dg/inherit/thunk11-aux.cc: New file. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk11-aux.cc trunk/gcc/testsuite/g++.dg/inherit/thunk11.C trunk/gcc/testsuite/g++.dg/inherit/thunk11.h Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/optimize.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42256
[Bug c++/42260] New: [4.3/4.4/4.5 Regression] ICE looking up template conversion operator
The following invalid code snippet triggers an ICE since GCC 3.2.3:
=
struct A
{
template operator T*();
};
int i = *A();
=
bug.cc:6:12: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2431
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4/4.5 Regression] ICE looking up template
conversion operator
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42260
[Bug c++/42260] [4.3/4.4/4.5 Regression] ICE looking up template conversion operator
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42260
[Bug c++/42217] [4.5 Regression] ICE with zero-length bit-field
--- Comment #3 from dodji at gcc dot gnu dot org 2009-12-03 08:33 --- Subject: Bug 42217 Author: dodji Date: Thu Dec 3 08:33:03 2009 New Revision: 154938 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154938 Log: Fix PR c++/42217 gcc/cp/ChangeLog PR c++/42217 * class.c (remove_zero_width_bit_fields): The width of the bit field is in DECL_SIZE, not in DECL_INITIAL. gcc/testsuite/ChangeLog PR c++/42217 * g++.dg/other/bitfield4.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/bitfield4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
[Bug c++/42256] [4.5 Regression] 483.xalancbmk fails to link
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-03 09:12 --- Should be fixed. -- 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=42256
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #9 from shailen dot n dot jain at gmail dot com 2009-12-03 09:37 --- what is the new version in which these changes can be found? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug c++/42217] [4.5 Regression] ICE with zero-length bit-field
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-03 09:44 --- Fixed in 4.5 -- 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=42217
[Bug c++/42232] [4.4 Regression] ICE in cleanup_omp_return
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-03 09:48 --- This is fixed, I've mistakenly typed PR42234 in the commit (and testcase name), so the commit message went to that PR instead. -- 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=42232
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #10 from dominiq at lps dot ens dot fr 2009-12-03 09:50 --- Revision 154855 (comment #5) has broken bootstrap on ppc-darwin (pr42243). This is now fixed, but there are now ~60 new failures (see comment #2 of pr42243). What is the best strategy to keep track of the problem: (1) continue to use pr42243, (2) use this pr and close pr42243 as fixed, (3) open a new pr and close pr42243 as fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c
--- Comment #7 from dominiq at lps dot ens dot fr 2009-12-03 09:51 --- See also pr35484. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-03 10:03 --- Testing a fix. That said, hope you are aware that strcpy of arbitrary program arguments into a fixed length buffer on the stack without checking the length means anyone can overflow it, and in some cases even execute arbitrary code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
-- 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|NEW |ASSIGNED Last reconfirmed|2009-11-15 14:32:24 |2009-12-03 10:14:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug libstdc++/42261] New: infinite recursion from string(string::size_type(6), string::size_type('f'))
Attempting to construct a string from two size_type parameters causes infinite
recursion. Test code, badstring.cc:
#include
using namespace std;
int main() {
string s(string::size_type(6), string::size_type('f'));
}
Compiled with:
g++ -O2 -o badstring badstring.cc
Loops infinitely when called. If compiled with -O0, segfaults when it runs out
of stack.
Analysis:
It appears that this ctor is used (with _InputIterator being string::size_type)
template
template
basic_string<_CharT, _Traits, _Alloc>::
basic_string(_InputIterator __beg, _InputIterator __end, const _Alloc& __a)
: _M_dataplus(_S_construct(__beg, __end, __a), __a)
{ }
This leads to an infinite recursion between these two methods:
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 438. Ambiguity in the "do the right thing" clause
template
static _CharT*
_S_construct_aux(_Integer __beg, _Integer __end,
const _Alloc& __a, __true_type)
{ return _S_construct(static_cast(__beg), __end, __a); }
template
static _CharT*
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a)
{
typedef typename std::__is_integer<_InIterator>::__type _Integral;
return _S_construct_aux(__beg, __end, __a, _Integral());
}
The infinite recursion also happens with GCC 4.3.2. GCC 4.1.3 constructs a
string containing "ff".
I'm not familiar enough with the standard to know whether GCC 4.1.3 is correct,
or whether 4.3.2 and 4.4.1 are (or whether neither behaviour is right), but
generating an infinite loop for seemingly innocent looking code seems
unhelpful.
FWIW, the Comeau online compiler accepts the code, but I can't tell how it
interprets it.
--
Summary: infinite recursion from string(string::size_type(6),
string::size_type('f'))
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olly at survex dot com
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=42261
[Bug libffi/40467] FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is %.1f res: 5
--- Comment #1 from ubizjak at gmail dot com 2009-12-03 11:17 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00182.html. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg00182.html Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40467
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-03 11:34 ---
(In reply to comment #0)
> This leads to an infinite recursion between these two methods:
>
> // _GLIBCXX_RESOLVE_LIB_DEFECTS
> // 438. Ambiguity in the "do the right thing" clause
> template
> static _CharT*
> _S_construct_aux(_Integer __beg, _Integer __end,
> const _Alloc& __a, __true_type)
> { return _S_construct(static_cast(__beg), __end, __a); }
GCC 4.1 also cast __end to static_cast(__end) which prevents the
recursion. I'm not sure why that was removed as part of resolving DR 438, it
looks necessary to me, but Paolo will know better
>
> template
> static _CharT*
> _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a)
> {
> typedef typename std::__is_integer<_InIterator>::__type _Integral;
> return _S_construct_aux(__beg, __end, __a, _Integral());
> }
>
> The infinite recursion also happens with GCC 4.3.2. GCC 4.1.3 constructs a
> string containing "ff".
>
> I'm not familiar enough with the standard to know whether GCC 4.1.3 is
> correct,
> or whether 4.3.2 and 4.4.1 are (or whether neither behaviour is right), but
> generating an infinite loop for seemingly innocent looking code seems
> unhelpful.
>
> FWIW, the Comeau online compiler accepts the code, but I can't tell how it
> interprets it.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug c++/42260] [4.3/4.4/4.5 Regression] ICE looking up template conversion operator
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42260
[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-03 11:38 --- Bootstrap is fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug target/41621] [4.4 regression] powerpc-linux-gnu 32bit testsuite regressions with -Os
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-03 12:05 --- Can anyone reproduce this (with current 4.4 branch)? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41621
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-03 12:42 --- Funny, after so many years... Let me look into it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-03 12:42:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug middle-end/42202] [4.5 regression] Revision 154688 caused many gfortran failures
--- Comment #3 from bernds at gcc dot gnu dot org 2009-12-03 12:58 --- Subject: Bug 42202 Author: bernds Date: Thu Dec 3 12:58:30 2009 New Revision: 154944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154944 Log: PR middle-end/42202 * regrename.c (live_in_chains): New variable. (verify_reg_tracked): New static function. (scan_rtx_reg): Update live_in_chains. (scan_rtx): Only promote sets in COND_EXEC to OP_INOUT if we're already tracking the reg. (build_def_use): Likewise. Initialize live_in_chains. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42202
[Bug c++/42260] [4.3/4.4/4.5 Regression] ICE looking up template conversion operator
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-03 13:04 --- Note, however, that this happens only with checking enabled... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42260
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-03 13:15 --- Richard Guenther has closed pr42243 as fixed which only the (b) and (c) options. After a clean bootstrap at revision 154924 and an update to 154943, I still have the following failures: === libffi tests === Running target unix FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O0 -W -Wall execution test FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/float.c -O0 -W -Wall execution test FAIL: libffi.call/float4.c -O0 -W -Wall execution test FAIL: libffi.call/many.c -O0 -W -Wall execution test FAIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test FAIL: libffi.call/return_dbl.c -O0 -W -Wall execution test FAIL: libffi.call/return_dbl1.c -O0 -W -Wall execution test FAIL: libffi.call/return_dbl2.c -O0 -W -Wall execution test FAIL: libffi.call/return_fl.c -O0 -W -Wall execution test FAIL: libffi.call/return_fl1.c -O0 -W -Wall execution test FAIL: libffi.call/return_fl2.c -O0 -W -Wall execution test FAIL: libffi.call/return_fl3.c -O0 -W -Wall execution test FAIL: libffi.call/return_ldl.c -O0 -W -Wall execution test FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O2 execution test FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/float.c -O2 execution test FAIL: libffi.call/float4.c -O2 execution test FAIL: libffi.call/many.c -O2 execution test FAIL: libffi.call/return_dbl.c -O2 execution test FAIL: libffi.call/return_dbl1.c -O2 execution test FAIL: libffi.call/return_dbl2.c -O2 execution test FAIL: libffi.call/return_fl.c -O2 execution test FAIL: libffi.call/return_fl1.c -O2 execution test FAIL: libffi.call/return_fl2.c -O2 execution test FAIL: libffi.call/return_fl3.c -O2 execution test FAIL: libffi.call/return_ldl.c -O2 execution test FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O3 execution test FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/float.c -O3 execution test FAIL: libffi.call/float4.c -O3 execution test FAIL: libffi.call/many.c -O3 execution test FAIL: libffi.call/return_dbl.c -O3 execution test FAIL: libffi.call/return_dbl1.c -O3 execution test FAIL: libffi.call/return_dbl2.c -O3 execution test FAIL: libffi.call/return_fl.c -O3 execution test FAIL: libffi.call/return_fl1.c -O3 execution test FAIL: libffi.call/return_fl2.c -O3 execution test FAIL: libffi.call/return_fl3.c -O3 execution test FAIL: libffi.call/return_ldl.c -O3 execution test FAIL: libffi.call/cls_double_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -Os execution test FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/float.c -Os execution test FAIL: libffi.call/float4.c -Os execution test FAIL: libffi.call/many.c -Os execution test FAIL: libffi.call/return_dbl.c -Os execution test FAIL: libffi.call/return_dbl1.c -Os execution test FAIL: libffi.call/return_dbl2.c -Os execution test FAIL: libffi.call/return_fl.c -Os execution test FAIL: libffi.call/return_fl1.c -Os execution test FAIL: libffi.call/return_fl2.c -Os execution test FAIL: libffi.call/return_fl3.c -Os execution test FAIL: libffi.call/return_ldl.c -Os execution test FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 FAIL: libffi.call/float.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/float4.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/many.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_dbl.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_dbl1.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_dbl2.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_fl.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_fl1.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_fl2.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_fl3.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/return_ldl.c -O2 -fomit-frame-pointer execution test === libffi Summary for unix === # of expected passes1532 # of unexpected failures71 # of expected failures 10 # of unsupported tests 15 Running target unix/-m64 FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test ... FAIL: libffi.special/unwindtest_ffi_call.cc -shared-libgcc -lstdc++ execution test === libffi Summary for unix/-m64 === # of expected passes593 # of unexpected failures583 # of expected failures 10 # of unsupported te
[Bug c/42262] New: internal compiler error: in set_designator, at c-typeck.c:5771
This code triggers ICE:
int a[] = {[0 ... 1] = "", [0] = ""};
GCC version info:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.2-2ubuntu1'
--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-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.2 (Ubuntu 4.4.2-2ubuntu1)
Exact command line: gcc test.c
GCC output:
test.c:1: internal compiler error: in set_designator, at c-typeck.c:5771
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: internal compiler error: in set_designator, at c-
typeck.c:5771
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abacabadabacaba at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42262
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #91 from dominiq at lps dot ens dot fr 2009-12-03 13:27 --- Is there any reason why the patch in commen #85 has not been commited? As stressed by Jack Howarth in http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00096.html, it is critical for darwin and probably good for other platforms as well. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug middle-end/38474] [Meta] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #42 from matz at gcc dot gnu dot org 2009-12-03 13:36 --- Subject: Bug 38474 Author: matz Date: Thu Dec 3 13:36:32 2009 New Revision: 154945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154945 Log: PR middle-end/38474 * cfgexpand.c (struct stack_var): Add conflicts member. (stack_vars_conflict, stack_vars_conflict_alloc, n_stack_vars_conflict): Remove. (add_stack_var): Initialize conflicts member. (triangular_index, resize_stack_vars_conflict): Remove. (add_stack_var_conflict, stack_var_conflict_p): Rewrite in terms of new member. (union_stack_vars): Only run over the conflicts. (partition_stack_vars): Remove special case. (expand_used_vars_for_block): Don't call resize_stack_vars_conflict, don't create self-conflicts. (account_used_vars_for_block): Don't create any conflicts. (fini_vars_expansion): Free bitmaps, don't free or clear removed globals. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #9 from dje at gcc dot gnu dot org 2009-12-03 13:46 --- Bootstrap is fixed, but mysterious libffi failures remain. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Component|bootstrap |libffi Resolution|FIXED | Summary|[4.5 Regression] powerpc- |[4.5 Regression] powerpc- |apple-darwin9 bootstrap |apple-darwin9 libffi |broken at ffi_darwin.c |failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #10 from dje at gcc dot gnu dot org 2009-12-03 13:56 --- The only unique change was in ffitarget.h: #elif defined (POWERPC_DARWIN) && defined (__ppc64__) /* Darwin */ #define POWERPC64 Does Darwin define __ppc64__ in 32 bit mode on 64 bit systems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #5 from dodji at gcc dot gnu dot org 2009-12-03 14:07 --- A patch was submitted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00194.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-03 14:12 ---
> Does Darwin define __ppc64__ in 32 bit mode on 64 bit systems?
I cannot answer the question, but I see
gcc/config/rs6000/darwin.h: if (TARGET_64BIT) builtin_define
("__ppc64__");\
Assuming powerpc-apple-darwin9 is a 32 bit target, __ppc64__ should not be
defined (?).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
CC||howarth at bromo dot med dot
||uc dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug fortran/35423] Implement OpenMP workshare
--- Comment #7 from burnus at gcc dot gnu dot org 2009-12-03 14:16 ---
Items left to do:
* worksharing of other stuff (say FORALL)
[I have not check the patch, but possibly assignments in WHERE blocks could
also profit from more work]
* dependency analysis ("the goal of dependency checking is to avoid unnecessary
barriers by inserting NOWAIT clauses when safe. Hopefully the functionality
provided in dependency.c will be useful here")
(cf. http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01598.html)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #3 from paolo at gcc dot gnu dot org 2009-12-03 14:21 --- Subject: Bug 42261 Author: paolo Date: Thu Dec 3 14:20:56 2009 New Revision: 154948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154948 Log: 2009-12-03 Paolo Carlini PR libstdc++/42261 * include/bits/basic_string.h (_S_construct_aux(_Integer, _Integer, const _Alloc&, __true_type)): Cast the second argument to value_type. * include/ext/sso_string_base.h (_M_construct_aux(_Integer, _Integer, std::__true_type)): Likewise. * include/ext/rc_string_base.h (_S_construct_aux(_Integer, _Integer, const _Alloc&, std::__true_type)): Likewise. * testsuite/21_strings/basic_string/cons/char/42261.cc: New. * testsuite/21_strings/basic_string/cons/wchar_t/42261.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/42261.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/42261.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/ext/rc_string_base.h trunk/libstdc++-v3/include/ext/sso_string_base.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-03 14:22 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug target/42263] New: Wrong code bugs in SMP support
There are two subtle wrong code bugs in the __sync_... primitives that severely affect code generation for linux. Both of these have been fixed on trunk. http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00198.html http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html but need back-porting to 4.4 -- Summary: Wrong code bugs in SMP support Product: gcc Version: 4.4.3 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug target/42263] Wrong code bugs in SMP support
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug target/42263] Wrong code bugs in SMP support
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-03 14:57:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug target/42263] Wrong code bugs in SMP support
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-12-03 14:57:59 |2009-12-03 14:59:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
[Bug debug/42244] [4.5 Regression] var-tracking ICE for 300.twolf
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-03 15:00 --- Created an attachment (id=19216) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19216&action=view) gcc45-pr42444.patch Patch that fixes the ICE (and that testcase works even with -fcompare-debug). It shouldn't regress anything, as the only cases it changes is where there would be assertion failures previously. I'm not 100% sure it is the right thing to do though, and perhaps it would be better to just drop the asserts and instead silently override d_t to ANTI_DEP if from->insn or to->insn is DEBUG_INSN. Then one wouldn't need to adjust all the callers... Alex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42244
[Bug debug/42244] [4.5 Regression] var-tracking ICE for 300.twolf
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-03 15:03 --- Isn't adding any dependency based on DEBUG_INSNs going to cause problems with same code -g vs. -g0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42244
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-12-03 15:17 --- On powerpc-apple-darwin9 using a dual G5, for Apple's gcc 4.0 and 4.2 compilers as well as FSF gcc 4.4.2's, one gets... howarth% gcc -m32 -E -dM -x c /dev/null | grep LP64 howarth% only at -m64 do all of the compilers define LP64... howarth% gcc -m64 -E -dM -x c /dev/null | grep LP64 #define __LP64__ 1 #define _LP64 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #13 from dje at gcc dot gnu dot org 2009-12-03 15:20 --- One would assume ... I do not see any differences that should cause the 11 FPR return value tests to fail on Darwin but not AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-12-03 15:20 --- Same is true for __ppc64__. For the Apple gcc-4.0 and 4.2 compilers as well as FSF gcc-4.4.2, __ppc64__ is only defined at -m64 and not -m32 as would be expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-12-03 15:33 --- Possible fix which is untested... Index: libjava/configure.ac === --- libjava/configure.ac(revision 154950) +++ libjava/configure.ac(working copy) @@ -889,6 +889,9 @@ SYSTEMSPEC="-lunicows $SYSTEMSPEC" fi ;; +*darwin*) + SYSTEMSPEC="-Wl,-allow_stack_execute" +;; *) SYSTEMSPEC= ;; Index: libjava/configure === --- libjava/configure (revision 154950) +++ libjava/configure (working copy) @@ -19595,6 +19595,9 @@ SYSTEMSPEC="-lunicows $SYSTEMSPEC" fi ;; +*darwin*) + SYSTEMSPEC="-Wl,-allow_stack_execute" +;; *) SYSTEMSPEC= ;; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-03 15:33 --- Subject: Bug 42049 Author: jakub Date: Thu Dec 3 15:33:18 2009 New Revision: 154951 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154951 Log: PR middle-end/42049 * builtins.c (expand_builtin_strcpy_args): Handle COMPOUND_EXPRs potentially returned from folding strcpy. * gcc.c-torture/compile/pr42049.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42049.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/builtins.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug debug/42244] [4.5 Regression] var-tracking ICE for 300.twolf
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-12-03 15:34 --- @richi it would, if we didn't have code to deal with that in sched-deps. now, depl_on_debug_p() are accepted, ignored for purposes of scheduling decisions, and used only to reset debug stmts that were rendered invalid when insns that anti-dependent on them were scheduled ahead of them @jakub thanks, the patch is good. making the change at the assert rather than at the caller would work, but then it wouldn't help catch situations that don't deal with debug insns but that might have to. explicitly dealing with them is kind of a way of saying yeah, I thought this through, even if that's all it takes. Now, this used to be far more important, before we dealt with dep-on-debug the way we do now. Maybe we could make this simplification in 4.6 or so? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42244
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-03 15:35 --- Subject: Bug 42049 Author: jakub Date: Thu Dec 3 15:34:56 2009 New Revision: 154952 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154952 Log: PR middle-end/42049 * builtins.c (expand_builtin_strcpy_args): Handle COMPOUND_EXPRs potentially returned from folding strcpy. * gcc.c-torture/compile/pr42049.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42049.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-03 15:42 --- Fixed. -- 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=42049
[Bug middle-end/41183] [4.4 Regression] ICE compiling chromium
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-03 15:59 --- This happens during mangling something from within the middle-end, and at that point cfun is a T.0 clone, which has cfun->language = NULL. Not sure what's the best solution, whether to change current_class_ptr etc. macros from cfun ? cp_function_chain->* : NULL to (cfun && cp_function_chain) ? cp_function_chain->* : NULL, allocate a dummy cfun->language somewhere when we are going to call FE functions that might need it, something else? -- jakub 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=41183
[Bug middle-end/41183] [4.4 Regression] ICE compiling chromium
--- Comment #7 from jakub at gcc dot gnu dot org 2009-12-03 16:31 --- Created an attachment (id=19217) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19217&action=view) gcc44-pr41183.patch Very ugly hack that fixes this. Checking for NULL cp_function_chain might be even uglier though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41183
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #15 from dje at gcc dot gnu dot org 2009-12-03 16:32 --- One would not expect __ppc64__ to be defined for -m32. Thanks for the confirmation. I do not have access to a darwin system. Do either of you have enough PPC assembly knowledge to step through libffi/testsuite/libffi.call/return_fl1.c in a debugger? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug c++/42218] [4.5 Regression] Broken diagnostic: 'tree_vec' not supported by pp_c_expression
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-29 15:42:20 |2009-12-03 17:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #16 from dje at gcc dot gnu dot org 2009-12-03 17:42 --- I found a system and backported the libffi changes. For some reason, Darwin is calculating the stack location of FP arguments wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug middle-end/38474] [Meta] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #43 from jv244 at cam dot ac dot uk 2009-12-03 17:47 --- (In reply to comment #42) > Subject: Bug 38474 > > Author: matz > Date: Thu Dec 3 13:36:32 2009 > New Revision: 154945 looks like the initial testcase now runs with 1.3Gb, and with the following timings (so mem/time both better by a factor of two): expand: 386.46 (89%) usr 0.81 (48%) sys 387.21 (89%) wall 309554 kB (56%) ggc integrated RA : 17.97 ( 4%) usr 0.26 (15%) sys 18.28 ( 4%) wall 8696 kB ( 2%) ggc reload: 7.78 ( 2%) usr 0.25 (15%) sys 8.07 ( 2%) wall 123546 kB (22%) ggc thread pro- & epilogue: 0.74 ( 0%) usr 0.00 ( 0%) sys 0.76 ( 0%) wall 239 kB ( 0%) ggc final : 2.84 ( 1%) usr 0.12 ( 7%) sys 2.95 ( 1%) wall 20 kB ( 0%) ggc TOTAL : 434.29 1.70 436.00 553866 kB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug c/42264] New: adress passing with unsigned long pointer increments
gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) . . unsigned long lay_sav . . #ifdef GCC_NEED /* this is what gcc handles correctly: f_bar[] is expanded into a larger * array proj_res_corr[] */ pred_expand( n1_sml, n2_sml, f_bar, n1_lrg, n2_lrg, &proj_res_corr[ lay_sav]); /* pointer- * convntn */ #else GCC_NEED /* GNU compiler goes wrong on this one - looks like lay_sav * screws something up -> needs lay_sav to be "long" NOT "unsigned long" * interestingly the computed result inside the proj_res_corr[] is wrong * for a given f_bar[]. Actually fbar is simply copied into * proj_res_corr[] as if n1_lrg and n1_sml etc. are the same. */ pred_expand( n1_sml, n2_sml, f_bar, n1_lrg, n2_lrg, proj_res_corr + lay_sav);/* pointer- * convntn */ #endif GCC_NEED . . . /* GNU compiler goes STILL RIGHT on this one */ write_image( proj_res_corr + lay_sav, (I_8)sizeof( *proj_res_corr), (I_8)NO, (I_8)NO, "PROJ_exp_res_corr..bmp"); the compile otpion is "gcc -O -fpic -m64 -lm -lc" I have the impression that this should not happen in dependency on the type of lay_sav. It looks like lay_sav is ignored and the variables n1_lrg etc. are changed. Possibly there should be a warning. -- Summary: adress passing with unsigned long pointer increments Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wolfram at cyber-inc dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42264
[Bug c++/42265] New: LONG_MAX is 9223372036854775807 rather than 2147483647 on macintosh 10.6
Hi, It appears that on macintosh 10.6 LONG_MAX has the same value as LLONG_MAX.
Below is a program that demonstrates the problem
$ cat long_max.cpp
#include
int main()
{
std::cout << "LONG_MAX="
[Bug c/42264] adress passing with unsigned long pointer increments
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-03 17:59 --- >gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) You should report this to Red Hat as we don't support this version of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42264
[Bug target/42265] LONG_MAX is 9223372036854775807 rather than 2147483647 on macintosh 10.6
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-03 18:00 --- And what is the sizeof(long) ? I think the default is to compile 64bit programs by default with Apple's supplied compiler. Also we don't support Apple's supplied GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c++ |target Summary|LONG_MAX is |LONG_MAX is |9223372036854775807 rather |9223372036854775807 rather |than 2147483647 on macintosh|than 2147483647 on macintosh |10.6|10.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42265
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-12-03 18:02 --- Can you verify that powerpc darwin calculates the stack location of FP arguments correctly before your patch to see if it was a latent problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #10 from tromey at gcc dot gnu dot org 2009-12-03 18:08 --- Created an attachment (id=19218) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19218&action=view) updated gcc patch to put the CU's language in the new section -- tromey at gcc dot gnu dot org changed: What|Removed |Added Attachment #19055|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #11 from tromey at gcc dot gnu dot org 2009-12-03 18:09 --- Created an attachment (id=19219) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19219&action=view) updated binutils patch to account for language in new index -- tromey at gcc dot gnu dot org changed: What|Removed |Added Attachment #19214|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug c++/42266] New: [C++0x] ICE with decltype and variadic templates
I tried to reduce as much as possible (maybe too much, we'll see...) an issue
which is blocking our work on std::bind. Note, the problem disappears if I
simplify the testcase further to not use variadic templates while keeping the
rest unchanged.
Jason, can you help us?
//
template
class tuple;
template
class _Mu;
template
struct _Bind;
template
class _Bind<_Functor(_Bound_args...)>
{
template()(_Bound_args(),
tuple<_Args...>())...) )>
void __call() { }
};
template
_Bind<_Functor(_Arg)>
bind(_Functor, _Arg) { }
struct State
{
bool ready() { return true; }
void f()
{
bind(&State::ready, this);
}
};
--
Summary: [C++0x] ICE with decltype and variadic templates
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42266
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #12 from tromey at gcc dot gnu dot org 2009-12-03 18:16 --- I compiled a C++ program with a gcc that includes this patch. I see some erroneous entries in the resulting index. E.g.: 0xb8 DW_TAG_structure_type._6 0x3f1 DW_TAG_structure_type basic_string 0x3fc2 DW_TAG_structure_type _Rep -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug c++/34272] ICE with invalid template specialization
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-03 18:19 --- Second try here: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00184.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34272
[Bug c++/42218] [4.5 Regression] Broken diagnostic: 'tree_vec' not supported by pp_c_expression
--- Comment #2 from dodji at gcc dot gnu dot org 2009-12-03 18:25 --- A patch got submitted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00208.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-12-03 18:53 --- Dave, do you happen to have a java-enabled build around? If so, could you attach the assembly generated for libjava.lang/Array_3 since it's very likely the problematic test? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #18 from dje at gcc dot gnu dot org 2009-12-03 19:09 --- Subject: Bug 42243 Author: dje Date: Thu Dec 3 19:09:29 2009 New Revision: 154956 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154956 Log: PR libffi/42243 * src/powerpc/ffi_darwin.c (ffi_prep_args): Remove extra parentheses. Modified: trunk/libffi/ChangeLog trunk/libffi/src/powerpc/ffi_darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug c/42262] internal compiler error: in set_designator, at c-typeck.c:5771
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-03 19:13 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Known to fail||4.3.0 4.4.0 4.5.0 4.1.0 ||3.2.3 Last reconfirmed|-00-00 00:00:00 |2009-12-03 19:13:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42262
[Bug fortran/42267] New: interaction between -finit-local-zero and -fno-automatic
when using both flags, the variables are initialized on every function call. see the example below: bash-3.2$ cat lvar.f REAL A(100) PRINT*,'Expect them to be zero' CALL ONE PRINT*,'Expect them to be 1..10' CALL TWO PRINT*,'Expect them to be 1..10' CALL ONE END SUBROUTINE ONE REAL A(100) INTEGER I PRINT*,"Sub One Loc(a) is ",LOC(A) DO I=1,10 PRINT*,A(I) A(I) = I END DO END SUBROUTINE TWO REAL A(100) INTEGER I PRINT*,"Sub Two Loc(a) is ",LOC(A) DO I = 1,10 A(I) = 0 END DO END bash-3.2$ /usr/local/bin/gfortran -static lvar.f -finit-local-zero -fno-automatic bash-3.2$ /usr/local/bin/gfortran --version GNU Fortran (GCC) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING bash-3.2$ ./a.out Expect them to be zero Sub One Loc(a) is135144832 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 Expect them to be 1..10 Sub Two Loc(a) is135144416 Expect them to be 1..10 Sub One Loc(a) is135144832 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -- Summary: interaction between -finit-local-zero and -fno-automatic Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #1 from bdavis at gcc dot gnu dot org 2009-12-03 19:16 ---
here is a patch against 4.4.1
diff --context --recursive gcc-4.4.1/gcc/fortran/gfortran.h
gcc-4.4.1_bud/gcc/fortran/gfortran.h
*** gcc-4.4.1/gcc/fortran/gfortran.h2009-02-21 16:25:06.0 -0600
--- gcc-4.4.1_bud/gcc/fortran/gfortran.h2009-12-03 09:24:11.0
-0600
***
*** 2024,2029
--- 2024,2030
int flag_init_character;
char flag_init_character_value;
int flag_align_commons;
+ int flag_no_automatic;
int fpe;
diff --context --recursive gcc-4.4.1/gcc/fortran/options.c
gcc-4.4.1_bud/gcc/fortran/options.c
*** gcc-4.4.1/gcc/fortran/options.c 2008-11-03 01:20:24.0 -0600
--- gcc-4.4.1_bud/gcc/fortran/options.c 2009-12-03 09:24:54.0 -0600
***
*** 346,352
/* Implement -fno-automatic as -fmax-stack-var-size=0. */
if (!gfc_option.flag_automatic)
! gfc_option.flag_max_stack_var_size = 0;
if (pedantic)
{
--- 346,355
/* Implement -fno-automatic as -fmax-stack-var-size=0. */
if (!gfc_option.flag_automatic)
! {
! gfc_option.flag_no_automatic = 1;
! gfc_option.flag_max_stack_var_size = 0;
! }
if (pedantic)
{
diff --context --recursive gcc-4.4.1/gcc/fortran/resolve.c
gcc-4.4.1_bud/gcc/fortran/resolve.c
*** gcc-4.4.1/gcc/fortran/resolve.c 2009-06-20 04:21:06.0 -0500
--- gcc-4.4.1_bud/gcc/fortran/resolve.c 2009-12-03 09:49:52.0 -0600
***
*** 7486,7492
/* For saved variables, we don't want to add an initializer at
function entry, so we just add a static initializer. */
! if (sym->attr.save || sym->ns->save_all)
{
/* Don't clobber an existing initializer! */
gcc_assert (sym->value == NULL);
--- 7486,7492
/* For saved variables, we don't want to add an initializer at
function entry, so we just add a static initializer. */
! if (sym->attr.save || sym->ns->save_all || gfc_option.flag_no_automatic )
{
/* Don't clobber an existing initializer! */
gcc_assert (sym->value == NULL);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-03 19:30 --- Subject: Re: FAIL: gnat.dg/null_pointer_deref1.adb execution test > Dave, do you happen to have a java-enabled build around? If so, could you > attach the assembly generated for libjava.lang/Array_3 since it's very likely > the problematic test? I don't have one handy. I was trying to debug this fail but started a new build this morning. I'll attach the assembly when available. The catch for the first null pointer exception in libjava.lang/Array_3 is not caught but I don't know why. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-03 20:06 --- That's already fixed for 4.5.0, see PR 41860. Do you think it makes sense to backport the patch to 4.4.x? (Note: 4.5.0 is currently in Stage4 (regression fixes only) - thus the question is how many fixed 4.4.x would be used.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Known to fail||4.3.4 4.4.2 Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug ada/4945] Rewriting '-gant' as '-gnat' is failing
--- Comment #9 from bosch at gcc dot gnu dot org 2009-12-03 20:10 --- I think the current behavior of ignoring the option with a warning is fine. I agree with Wolfgang that If anything, we should remove any processing for this misspelling. A patch to that effect is welcomed, but this is obviously a very low priority. -- bosch at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4945
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-12-03 20:21 --- silly me. glad to see we both fixed it the same way :) close with no more action taken ? --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/42268] New: [4.4/4.5 Regression] derived type segfault with pack and unpack
This is a clone of bug 41478, because this part is a regression (incidentally, introduced by me). The problem was analyzed by Janus: not checking for the presence of vector when trying to access vector->data. -- Summary: [4.4/4.5 Regression] derived type segfault with pack and unpack Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 41478 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42268
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #5 from ubizjak at gmail dot com 2009-12-03 20:39 --- I have a patch. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-30 07:49:04 |2009-12-03 20:39:54 date|| Target Milestone|--- |4.5.0 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug fortran/42268] [4.4/4.5 Regression] derived type segfault with pack and unpack
--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-12-03 20:43 --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478#c11 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-03 20:43:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42268
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #4 from burnus at gcc dot gnu dot org 2009-12-03 20:47 --- (In reply to comment #3) > silly me. glad to see we both fixed it the same way :) > close with no more action taken ? I am fine with closing it as won't fix, but one could also mark it as duplicate. (Or backport the fix and keep it open.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #19 from dominiq at lps dot ens dot fr 2009-12-03 20:57 --- At revision 154956 the results are: === libffi tests === Running target unix FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O0 -W -Wall execution test FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O2 execution test FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O3 execution test FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -Os execution test FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 === libffi Summary === # of expected passes1587 # of unexpected failures16 # of expected failures 10 # of unsupported tests 15 So the libffi.call/cls_longdouble.c test is still failing while it was not before revision 154855. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-03 20:58 --- Subject: Re: FAIL: gnat.dg/null_pointer_deref1.adb execution test Attached .s from hppa-unknown-linux-gnu target. --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-03 20:58 --- Created an attachment (id=19220) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19220&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-03 21:02 --- Quote from the standard: "12.3.2 Specification of the procedure interface" [...] "A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions." Currently, one gets the message: "Error: DERIVED attribute of 'foo' conflicts with PROCEDURE attribute at (1)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug middle-end/38474] [Meta] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #44 from matz at gcc dot gnu dot org 2009-12-03 21:05 --- I'm glad. I plan to work on also the other slow part of expand, which is the temp slot goo, but a full solution requires touching very old and stable parts of GCC, hence is IMO nothing for stage 3. I have an obvious band aid patch giving at least some further improvements that I plan to submit for 4.5. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-16 16:26:45 |2009-12-03 21:05:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #6 from ubizjak at gmail dot com 2009-12-03 21:05 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00216.html. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg00216.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug fortran/42268] [4.4/4.5 Regression] derived type segfault with pack and unpack
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42268
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-03 21:14 --- If it's not a regression close it as fixed in 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug target/42265] LONG_MAX is 9223372036854775807 rather than 2147483647 on macintosh 10.6
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-03 21:16 --- And 4.2 is no longer supported. Please re-try with FSF 4.3.4 at least and re-open if you think that is still broken. Or file the bug with apple. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42265
[Bug c/42264] adress passing with unsigned long pointer increments
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-03 21:18 --- Indeed. (4.1 is no longer supported, 4.3.4 is the olded supported release. For a proper bugreport we need a testcase that allows us to reproduce the issue) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42264
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #6 from burnus at gcc dot gnu dot org 2009-12-03 21:19 --- *** This bug has been marked as a duplicate of 41860 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
--- Comment #3 from burnus at gcc dot gnu dot org 2009-12-03 21:19 --- *** Bug 42267 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||bdavis at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #3 from pault at gcc dot gnu dot org 2009-12-03 21:28 ---
The smaller testcase of comment #1 is fixed with
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 154935)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2446,12 +2446,14 @@
ss = gfc_walk_expr (e);
if (ss == gfc_ss_terminator)
{
+ parmse->ss = NULL;
gfc_conv_expr_reference (parmse, e);
tmp = fold_convert (TREE_TYPE (ctree), parmse->expr);
gfc_add_modify (&parmse->pre, ctree, tmp);
}
else
{
+ parmse->ss = ss;
gfc_conv_expr (parmse, e);
gfc_add_modify (&parmse->pre, ctree, parmse->expr);
}
The original fails because the vtable cannot be found. THis is due to:
use grid_module, only : grid
Removing the ",only : grid" restores correct linkage.
I knew that we would hit this before long, so now is as good a time as any to
fix it:-)
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-03 21:28:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-03 21:46 --- (In reply to comment #3) > The original fails because the vtable cannot be found. This is due to: > use grid_module, only : grid This is true of trunk: /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/ccwercw1.o: In function `__field_module_MOD_output': pr42051.f03:(.text+0x84): undefined reference to `vtab$grid.1611' collect2: ld returned 1 exit status fortran-dev ICEs at line 372 in trans-array.c. *sigh* The reduced testcase is fine with both. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-03 21:56 --- Would it be a solution (at least for -w64- targets) to remove the /mingw part and default to /include & /lib instead. At least for the -w64- targets there is no real need of this /mingw subfolder. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug c++/42266] [C++0x] ICE with decltype and variadic templates
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-03 22:09:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42266
[Bug c++/42266] [C++0x] ICE with decltype and variadic templates
--- Comment #1 from jason at gcc dot gnu dot org 2009-12-04 00:26 --- Subject: Bug 42266 Author: jason Date: Fri Dec 4 00:26:27 2009 New Revision: 154964 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154964 Log: PR c++/42266 * cvt.c (convert_from_reference): Do nothing if TREE_TYPE is null. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic97.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42266
[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't
--- Comment #11 from jason at gcc dot gnu dot org 2009-12-04 00:26 --- Subject: Bug 41611 Author: jason Date: Fri Dec 4 00:26:35 2009 New Revision: 154965 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154965 Log: PR c++/41611 * decl2.c (get_guard): Don't use the same comdat group as the decl. Added: trunk/gcc/testsuite/g++.dg/abi/guard2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41611
[Bug rtl-optimization/42269] New: [4.4/4.5 Regression] Extra sign extension instructions generated
In reference to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27469#c3 This bug to track the regression since 4.2, not the enhancement in the original PR. -- Summary: [4.4/4.5 Regression] Extra sign extension instructions generated Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org GCC target triplet: alphaev68-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42269
[Bug rtl-optimization/42269] [4.4/4.5 Regression] Extra sign extension instructions generated
--- Comment #1 from rth at gcc dot gnu dot org 2009-12-04 01:24 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00225.html -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 01:24:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42269
[Bug other/42270] New: manual's sections are ordered counter intuitively
E.g. from http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/ 5.27 Declaring Attributes of Functions 5.28 Attribute Syntax ... some stuff that isn't about attributes ... 5.34 Specifying Attributes of Variables 5.35 Specifying Attributes of Type -- Summary: manual's sections are ordered counter intuitively Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: graham dot gower at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42270
[Bug bootstrap/42271] New: os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc
-nos
tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gn
u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.5
.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/lib
/ -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gn
u/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include-x c++-header -g -O2
-I/tes
t/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.1
1 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/
gcc/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/test/gnu/gcc/gcc/libstdc++-v
3/include/precompiled/stdc++.h \
-o hppa2.0w-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/hppa2.0w-hp-hpux11.11/bits/c++config.h:275:0,
from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/cctype:43,
from
/test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.
h:36:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux
11.11/bits/os_defines.h:60:1: error: expected '{' before
'_GLIBCXX_PSEUDO_VISIBI
LITY'
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux
11.11/bits/os_defines.h:60:1: error: expected constructor, destructor, or type
c
onversion before '(' token
...
-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.5.0
--with-gmp=/opt/gnu/gcc/gcc-4.5.0 --enable-threads=posix --enable-debug=no
--disable-nls --without-cloog --without-ppl
--enable-languages=c,c++,objc,fortran,java,ada,obj-c++
Thread model: posix
gcc version 4.5.0 20091203 (experimental) [trunk revision 154954] (GCC)
--
Summary: os_defines.h:60:1: error: expected '{' before
'_GLIBCXX_PSEUDO_VISIBILITY'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
03:50 ---
Subject: Re: New: os_defines.h:60:1: error: expected
'{' before '_GLIBCXX_PSEUDO_VISIBILITY'
Attached os_defines.h.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
03:50 ---
Created an attachment (id=19221)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19221&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug c++/42272] New: derived template deafult argument
hello ,
i have a problem on default template argument , for statement "SMART b(a) ;"
the good constructor is not in constructor choice for G++ .
thanks for help
template < typename T >
class SMART
{ T * data ;
public :
T * Get() {return(data); } ;
SMART( T* value ) : data(value) {} ;
SMART(SMART & value) : data(value.Get()) {} ;
template < typename X , typename X2 = typename X :: T > X2 * CastUp()
{return(dynamic_cast(data)); } ;
template < typename X , typename XT2 = T , typename X2 = typename XT2 :: X >
SMART(SMART & value) : data(value.CastUp()) {} ;
~SMART() {} ;
} ;
class A
{
public :
A() {} ;
~A() {} ;
} ;
class B : virtual public A
{
public :
B() {} ;
~B() {} ;
} ;
int method()
{SMART a();
SMART b(a) ;
} ;
cat configure.shl
#!/bin/sh
export GCC_DIR=`pwd`
echo GCC_DIR
./configure --prefix=$GCC_DIR --exec-prefix=$GCC_DIR --libdir=$GCC_DIR/lib
--disable-multilib --enable-checking=release --with-tune=generic --enable-mpfr
--enable-libstdcxx-debug --enable-clocale=gnu --enable-nls
--enable-threads=posix --without-included-gettext --with-system-zlib
--enable-linker-build-id --enable-multiarch
make
make install
gcc-4.5-20091126/bin/g++ -std=c++0x -c main.cc
main.cc: In function int method():
main.cc:43:13: erreur: no matching function for call to
SMART::SMART(SMART (&)())
main.cc:11:1: note: candidats sont: SMART::SMART(SMART&) [with T = B]
main.cc:9:1: note: SMART::SMART(T*) [with T = B]
gcc-4.5-20091126/bin/g++ -v -save-temps -std=c++0x -c main.cc
Utilisation des specs internes.
COLLECT_GCC=gcc-4.5-20091126/bin/g++
COLLECT_LTO_WRAPPER=/home/admin/webTmp/gcc/gcc-4.5-20091126/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configuré avec: ./configure --prefix=/home/admin/webTmp/gcc/gcc-4.5-20091126
--exec-prefix=/home/admin/webTmp/gcc/gcc-4.5-20091126
--libdir=/home/admin/webTmp/gcc/gcc-4.5-20091126/lib --disable-multilib
--enable-checking=release --with-tune=generic --enable-mpfr
--enable-libstdcxx-debug --enable-clocale=gnu --enable-nls
--enable-threads=posix --without-included-gettext --with-system-zlib
--enable-linker-build-id --enable-multiarch
Modèle de thread: posix
gcc version 4.5.0 20091126 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-c' '-shared-libgcc'
'-mtune=generic'
/home/admin/webTmp/gcc/gcc-4.5-20091126/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-E -quiet -v -D_GNU_SOURCE main.cc -mtune=generic -std=c++0x -fpch-preprocess
-o main.ii
le répertoire «
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include
» est ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/x86_64-unknown-linux-gnu
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward
/usr/local/include
/home/admin/webTmp/gcc/gcc-4.5-20091126/include
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include
/home/admin/webTmp/gcc/gcc-4.5-20091126/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed
/usr/include
Fin de la liste de recherche.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-c' '-shared-libgcc'
'-mtune=generic'
/home/admin/webTmp/gcc/gcc-4.5-20091126/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed main.ii -quiet -dumpbase main.cc -mtune=generic -auxbase main
-std=c++0x -version -o main.s
GNU C++ (GCC) version 4.5.0 20091126 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091126 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p2
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.0 20091126 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091126 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p2
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 55f055424d661ccac322b63c97c280de
main.cc: In function int method():
main.cc:43:13: erreur: no matching function for call to
SMART::SMART(SMART (&)())
main.cc:11:1: note: candidats sont: SMART::SMART(SMART&) [with T = B]
main.cc:9:1: note: SMART::SMART(T*) [with T = B]
--
Summary: derived template deafult argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian dot templier at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
