[Bug libgcj/43279] New: Constructor java.lang.String(int[], int, int) missing
In the java.lang.String implementation in libjava, there is no constructor java.lang.String(int[], int, int). This constructor was added by Sun in 1.5, but since gij claims to be 1.5 it should be there. The String class in Classpath has the constructor, but it is not used by gij. -- Summary: Constructor java.lang.String(int[], int, int) missing Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at mc dot pp dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43279
[Bug tree-optimization/43280] New: gcc4.5 -m32 -O2: misoptimizes sha256!
gcc-4.5 -O2 -m32 misoptimizes sha256: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O2 -m32 $ ./a.out sha256 test vector #1 failed sha256 test vector #2 failed sha256 test vector #3 failed Aborted Without -m32 it works: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib64 -O2 $ ./a.out $ And -m32 -O1 works too: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O1 -m32 $ ./a.out $ gcc version: ~/gcc/install/bin/gcc-4.5 -v Using built-in specs. COLLECT_GCC=/home/edwin/gcc/install/bin/gcc-4.5 COLLECT_LTO_WRAPPER=/home/edwin/gcc/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap : (reconfigured) ../gcc-trunk/configure --prefix=/home/edwin/gcc/install --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap Thread model: posix gcc version 4.5.0 20100307 (experimental) (GCC) Bug initially reported against openSUSE 11.3 factory's gcc-4.5, but I reproduced with upstream gcc-4.5 SVN r157262. See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1862 for the original report. -- Summary: gcc4.5 -m32 -O2: misoptimizes sha256! Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail 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=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #1 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20038action=view) sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #2 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20039action=view) preprocessed sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug libgcj/43279] Constructor java.lang.String(int[], int, int) missing
--- Comment #1 from marcus at mc dot pp dot se 2010-03-07 12:39 --- Here is a reproduction recipe using Jython 2.5.1, by the way: chiyo:~/jython2.5.1% gij-4.4 -jar jython.jar Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) [GNU libgcj (Free Software Foundation, Inc.)] on java1.5.0 Type help, copyright, credits or license for more information. u'A'[0] Traceback (most recent call last): File stdin, line 1, in module java.lang.NoSuchMethodError: method java.lang.String.init with signature ([III)V was not found. at org.python.core.PyUnicode.init(PyUnicode.java:62) at org.python.core.Py.makeCharacter(Py.java:1476) at org.python.core.PyUnicode.pyget(PyUnicode.java:300) at org.python.core.PySequence$1.getItem(PySequence.java:452) at org.python.core.SequenceIndexDelegate.checkIdxAndFindItem(SequenceIndexDelegate.java:88) at org.python.core.SequenceIndexDelegate.checkIdxAndFindItem(SequenceIndexDelegate.java:70) at org.python.core.SequenceIndexDelegate.checkIdxAndGetItem(SequenceIndexDelegate.java:61) at org.python.core.PySequence.seq___getitem__(PySequence.java:305) at org.python.core.PySequence.__getitem__(PySequence.java:301) at org.python.pycode._pyx1.f$0(stdin:1) at org.python.pycode._pyx1.call_function(stdin) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1204) at org.python.core.Py.exec(Py.java:1248) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:181) at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java:89) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:70) at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:46) at org.python.util.InteractiveConsole.push(InteractiveConsole.java:110) at org.python.util.InteractiveConsole.interact(InteractiveConsole.java:90) at org.python.util.jython.run(jython.java:316) at org.python.util.jython.main(jython.java:129) java.lang.NoSuchMethodError: java.lang.NoSuchMethodError: method java.lang.String.init with signature ([III)V was not found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43279
[Bug c++/43281] New: [c++0x] ICE in nested lambda functions, in a special case
it resembles Bug 41896 but with the addition of line: auto val = val;
The code is legal but doesn't make any sense. In some rare cases which I
couldn't replicate simply, it went into an infinite mallo, consuming the whole
memory, instead of segfault.
float nested_lambda()
{
float val;
[val]()
{
auto val = val;
[val]()
{
};
};
}
g++: Internal error: Segmentation Fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/rakadam/streamplusplus/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --program-suffix=-4.5
--prefix=/home/rakadam/streamplusplus/src/third_party/gcc-trunk/build_gcc/../../../../local
--enable-lto --disable-bootstrap --enable-gold
Thread model: posix
gcc version 4.5.0 20100306 (experimental) (GCC)
--
Summary: [c++0x] ICE in nested lambda functions, in a special
case
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam dot rak at streamnovation dot com
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43281
[Bug libgcj/43279] Constructor java.lang.String(int[], int, int) missing
--- Comment #2 from mark at gcc dot gnu dot org 2010-03-07 13:48 --- GNU Classpath java.lang.String does have the String(int[] codePoints, int offset, int count) constructor. But libgcj still has a separate String implementation that doesn't have this constructor merged. -- mark 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-03-07 13:48:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43279
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #8 from janus at gcc dot gnu dot org 2010-03-07 14:07 ---
(In reply to comment #7)
This leaves us with the following regressions:
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_6.f03 -O0 (test for excess errors)
due to the error
Error: Type mismatch in argument '...' at (1); passed CLASS(...) to CLASS(...)
These are resolved when adding to the patches in comment #3 and #7 the
following one:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157262)
+++ gcc/fortran/resolve.c (working copy)
@@ -5178,18 +5178,17 @@ check_class_members (gfc_symbol *derived)
return;
}
- if (tbp-n.tb-is_generic)
+ /* If we have to match a passed class member, force the actual
+ expression to have the correct type. */
+ if (!tbp-n.tb-nopass)
{
- /* If we have to match a passed class member, force the actual
-expression to have the correct type. */
- if (!tbp-n.tb-nopass)
- {
- if (e-value.compcall.base_object == NULL)
- e-value.compcall.base_object =
- extract_compcall_passed_object (e);
+ if (e-value.compcall.base_object == NULL)
+ e-value.compcall.base_object = extract_compcall_passed_object (e);
- e-value.compcall.base_object-ts.type = BT_DERIVED;
- e-value.compcall.base_object-ts.u.derived = derived;
+ if (!derived-attr.abstract)
+ {
+ e-value.compcall.base_object-ts.type = BT_DERIVED;
+ e-value.compcall.base_object-ts.u.derived = derived;
}
}
I hope that's it now. I'll do another regtest to make sure ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug tree-optimization/42326] [4.5 Regression][graphite] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #17 from p dot vanhoof at oma dot be 2010-03-07 14:12 --- The test case in comment #9 has only been fixed on the graphite branch, but still crashes on the trunk as of r157255. Please reopen and fix this problem on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug tree-optimization/42326] [4.5 Regression][graphite] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-07 14:43 --- Confirmed. This patch: Fix PR42326: handle default definitions. 2010-03-02 Sebastian Pop sebastian@amd.com PR middle-end/42326 * sese.c (name_defined_in_loop_p): Return false for default definitions. * gcc.dg/graphite/pr42326.c: New. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42326.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/sese.c isn't in trunk. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #47 from bernds at gcc dot gnu dot org 2010-03-07 15:20 --- Subject: Bug 42220 Author: bernds Date: Sun Mar 7 15:20:12 2010 New Revision: 157263 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157263 Log: PR rtl-optimization/42220 * regrename.c (scan_rtx) case STRICT_LOW_PART, ZERO_EXTRACT: Use verify_reg_tracked to determine if we should use OP_OUT rather than OP_INOUT. (build_def_use): If we see an in-out operand for a register that we know nothing about, treat is an output if possible, fail the block if not. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #48 from rguenth at gcc dot gnu dot org 2010-03-07 15:35 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43176] var-tracking fails to notice a value change
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-07 15:44 --- Subject: Bug 43176 Author: jakub Date: Sun Mar 7 15:44:11 2010 New Revision: 157264 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157264 Log: PR debug/43176 * Makefile.in (var-tracking.o): Depend on pointer-set.h. * cselib.c (struct expand_value_data): Add dummy field. (cselib_expand_value_rtx, cselib_expand_value_rtx_cb): Initialize dummy to false. (cselib_dummy_expand_value_rtx_cb): New function. (cselib_expand_value_rtx_1): If evd-dummy is true, don't allocate any rtl. * cselib.h (cselib_dummy_expand_value_rtx_cb): New prototype. * var-tracking.c: Include pointer-set.h. (variable): Change n_var_parts to char from int. Add cur_loc_changed and in_changed_variables fields. (variable_canonicalize): Remove. (shared_var_p): New inline function. (unshare_variable): Maintain cur_loc_changed and in_changed_variables fields. If var was in changed_variables, replace it there with new_var. Just copy cur_loc instead of resetting it to something else. (variable_union): Don't recompute cur_loc. Use shared_var_p. (dataflow_set_union): Don't call variable_canonicalize. (loc_cmp): If both x and y are DEBUG_EXPRs, compare uids of their DEBUG_EXPR_TREE_DECLs. (canonicalize_loc_order_check): Verify that cur_loc is NULL and in_changed_variables and cur_loc_changed is false. (variable_merge_over_cur): Clear cur_loc, in_changed_variables and cur_loc_changed. Don't update cur_loc here. (variable_merge_over_src): Don't call variable_canonicalize. (dataflow_set_preserve_mem_locs): Use shared_var_p. When removing loc that is equal to cur_loc, clear cur_loc, set cur_loc_changed and ensure variable_was_changed is called. (dataflow_set_remove_mem_locs): Use shared_var_p. Only compare pointers in cur_loc check, if it is equal to loc, clear cur_loc and set cur_loc_changed. Don't recompute cur_loc here. (variable_different_p): Remove compare_current_location argument, don't compare cur_loc. (dataflow_set_different_1): Adjust variable_different_p caller. (variable_was_changed): If dv had some var in changed_variables already, reset in_changed_variables flag for it and propagate cur_loc_changed over to the new variable. On empty var always set cur_loc_changed. Set in_changed_variables on whatever var is added to changed_variables. (set_slot_part): Clear cur_loc_changed and in_changed_variables. Use shared_var_p. When removing loc that is equal to cur_loc, clear cur_loc and set cur_loc_changed. If cur_loc is NULL at the end, don't set it to something else, just call variable_was_changed. (delete_slot_part): Use shared_var_p. When cur_loc equals to loc being removed, clear cur_loc and set cur_loc_changed. Set cur_loc_changed if all locations have been removed. (struct expand_loc_callback_data): New type. (vt_expand_loc_callback): Add dummy mode in which no rtxes are allocated. Always create SUBREGs if simplify_subreg failed. Prefer to use cur_loc, when that fails and still in changed_variables (and seen first time) recompute it. Set cur_loc_changed of variables which had to change cur_loc and compute elcd-cur_loc_changed if any of the subexpressions used had to change cur_loc. (vt_expand_loc): Adjust to pass arguments in expand_loc_callback_data structure. (vt_expand_loc_dummy): New function. (emitted_notes): New variable. (emit_note_insn_var_location): For VALUEs and DEBUG_EXPR_DECLs that weren't used for any other decl in current emit_notes_for_changes call call vt_expand_loc_dummy to update cur_loc. For -fno-var-tracking-assignments, set cur_loc to first loc_chain location if NULL before. Always use just cur_loc instead of first loc_chain location. When cur_loc_changed is false, when not --enable-checking=rtl just don't emit any note. When rtl checking, compute the note and assert it is the same as previous note. Clear cur_loc_changed and in_changed_variables at the end before removing from changed_variables. (check_changed_vars_3): New function. (emit_notes_for_changes): Traverse changed_vars to call check_changed_vars_3 on each changed var. (emit_notes_for_differences_1): Clear cur_loc_changed and in_changed_variables. Recompute cur_loc of new_var. (emit_notes_for_differences_2): Clear cur_loc if new variable appears. (vt_emit_notes): Initialize and destroy emitted_notes. Modified: trunk/gcc/ChangeLog
[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-07 15:47 --- Confirmed. This is exposed by the new bswap pass. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||krebbel1 at de dot ibm dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-07 15:47:23 date|| Summary|gcc4.5 -m32 -O2:|[4.5 Regression] gcc4.5 -m32 |misoptimizes sha256!|-O2: misoptimizes sha256! Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug fortran/43256] [OOP] TBP with missing optional arg
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-07 15:59 --- For the record, the patch in comment #8 does not apply on fortran-dev. AFAICT the patches in comments #2 and 7 are enough for the branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
[Bug c/43009] segmentation fault with -O3 when accessing byte-aligned array as dwords
--- Comment #10 from manu at gcc dot gnu dot org 2010-03-07 16:17 --- Cannot we warn for this? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-07 16:56 --- It is caused by revision 148848: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00831.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug fortran/40850] double free in nested types with allocatable components
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-07 17:24 --- I just noticed that using -Warray-temporaries gives the warning twice. For the test in comment #8, I get [macbook] f90/bug% gfc -Warray-temporaries -fcheck=all pr40850_3.f90 pr40850_3.f90:11.13: CALL test ((/ lines /)) 1 Warning: Creating array temporary at (1) pr40850_3.f90:11.13: CALL test ((/ lines /)) 1 Warning: Creating array temporary at (1) [macbook] f90/bug% a.out a.out(35149) malloc: *** error for object 0x100201010: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850
[Bug c/43009] segmentation fault with -O3 when accessing byte-aligned array as dwords
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-07 17:36 --- (In reply to comment #10) Cannot we warn for this? As usual, if we knew the data is not aligned we'd not miscompile it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
[Bug tree-optimization/42341] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:228
--- Comment #4 from danglin at gcc dot gnu dot org 2010-03-07 17:52 --- gcc.dg/lto/20090116 fails on hppa64-hp-hpux11.11 as shown in #1. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-07 17:52:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42341
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #17 from mjtruog at fastmail dot ca 2010-03-07 17:53 --- I have found this doesn't fix the problem. It may fix the problem in the example, but not in all cases. I have a few new crash dumps: Core was generated by `_release/lib/cloud-0.0.9/priv/cloud_worker_port'. Program terminated with signal 6, Aborted. [New process 10276] [New process 10273] [New process 10277] #0 0x2b766a9a7015 in raise () from /lib/libc.so.6 (gdb) back #0 0x2b766a9a7015 in raise () from /lib/libc.so.6 #1 0x2b766a9a8b83 in abort () from /lib/libc.so.6 #2 0x2b766a9e80c8 in __libc_message () from /lib/libc.so.6 #3 0x2b766a9eda58 in malloc_printerr () from /lib/libc.so.6 #4 0x2b766a9f00a6 in free () from /lib/libc.so.6 #5 0x2b766ad8758e in std::string::_M_mutate (this=0x407f0ea0, __pos=0, __len1=0, __len2=32) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:231 #6 0x2b766ad875dc in std::string::_M_replace_safe (this=0x2821, __pos1=10276, __n1=6, __s=0x407f0741 243f6a8885a308d313198a2e03707344, __n2=47787595689792) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:662 #7 0x2aab2445 in bbp_pi (abortTask=value optimized out, digitIndex=value optimized out, digitStep=value optimized out, piSequence=value optimized out) at lib/cloud_job_tests/src/piqpr8_gmp.cpp:241 #8 0x2aab05db in do_work (abortta...@0x12387a2, workInstance=value optimized out, id=value optimized out, taskda...@0x1226ca0, taskDataSize=10, querieso...@0x407f0f70) at lib/cloud_job_tests/src/cloud_job_tests.cpp:145 #9 0x0041390d in WorkerController::WorkerExecution::ThreadPool::ThreadFunctionObject::operator() (this=0x407f1040, stopp...@0x12387a2, allocator=value optimized out) at lib/cloud_worker/src/worker_execution.cpp:501 warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) #10 0x00419055 in boost::detail::thread_dataWorkerController::WorkerExecution::ThreadPool::ThreadObject::run (this=value optimized out) at lib/cloud_worker/src/worker_execution.cpp:236 warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x418fa0 in read in psymtab, but not in symtab.) #11 0x2b7669b05870 in thread_proxy () from /home/.../src/lib/boost/releases/boost_1_42_0_install/lib/libboost_thread.so.1.42.0 #12 0x2b766b27a3ea in start_thread () from /lib/libpthread.so.0 #13 0x2b766aa5acbd in clone () from /lib/libc.so.6 #14 0x in ?? () (gdb) I also continue to reproduce the same stderr problem (in debug mode): Core was generated by `_release/lib/cloud-0.0.9/priv/cloud_worker_port'. Program terminated with signal 11, Segmentation fault. [New process 11089] [New process 11090] #0 sentry (this=0x7fff4a32a8d0, __...@0x2abb61e70c20) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51 51if (__os.tie() __os.good()) (gdb) back #0 sentry (this=0x7fff4a32a8d0, __...@0x2abb61e70c20) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51 #1 0x2abb61c15048 in std::__ostream_insertchar, std::char_traitschar (__o...@0x2abb61e70c20, __s=value optimized out, __n=47) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:80 #2 0x2abb61c1544f in operator std::char_traitschar ( __o...@0x2abb61e70c20, __s=0x2aab7360 cloud_job_tests global/static data initialize()) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ostream:510 #3 0x2aab30d6 in initialize () at lib/cloud_job_tests/src/cloud_job_tests.cpp:100 #4 0x2aab7326 in __do_global_ctors_aux () from _release/lib/cloud-0.0.9/priv/work_types/libcloud_job_tests.so #5 0x2aab2423 in _init () from _release/lib/cloud-0.0.9/priv/work_types/libcloud_job_tests.so #6 0x2abb in ?? () #7 0x2abb60781a20 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #8 0x2abb6078649a in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #9 0x2abb60781676 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #10 0x2abb60785b2b in _dl_open () from /lib64/ld-linux-x86-64.so.2 #11 0x2abb611e8f5b in dlopen_doit () from /lib/libdl.so.2 #12 0x2abb60781676 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #13 0x2abb611e92cc in _dlerror_run () from /lib/libdl.so.2 #14 0x2abb611e8ec1 in dlopen@@GLIBC_2.2.5 () from /lib/libdl.so.2 #15 0x00425f17 in library (this=0x172a970, na...@0x7fff4a32ae60) at lib/cloud_worker/src/library.cpp:68 #16 0x00417cec in
[Bug testsuite/41671] Unsatisfied symbol __sync_fetch_and_add_4
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 18:58 --- How should this test be xfailed? The lto test options don't seem to provide an xfail mechanism. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41671
[Bug c++/43282] New: GCC looks into dependent bases during unqualified lookup
GCC does not accept this code, but is supposed to. foo is looked up using
unqualified name lookup, during which dependent base classes are ignored. The
fact that foo is dependent must not influence this.
templatetypename T
struct HasFoo {
void foo() { }
};
// dependent HasFooT should be ignored during
// lookup of foo
templatetypename T
struct Bar : HasFooT {
void bar() { foo(T()); }
};
namespace A {
struct Baz { };
void foo(Baz); // should be found!
}
int main() { BarA::Baz b; b.bar(); }
--
Summary: GCC looks into dependent bases during unqualified lookup
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug lto/43283] New: ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
PASS: gcc.dg/lto/20091027-1 c_lto_20091027-1_0.o-c_lto_20091027-1_1.o link Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -O 0 -fwhopr -c -o c_lto_20091216-1_0.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lt o/20091216-1_0.c(timeout = 300) PASS: gcc.dg/lto/20091216-1 c_lto_20091216-1_0.o assemble, -O0 -fwhopr Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_l to_20091216-1_0.o -O0 -fwhopr -o gcc-dg-lto-20091216-1-01(timeout = 3 00) ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o 1 errors. collect2: ld returned 1 exit status compiler exited with status 1 output is: ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o 1 errors. collect2: ld returned 1 exit status FAIL: gcc.dg/lto/20091216-1 c_lto_20091216-1_0.o-c_lto_20091216-1_0.o link UNRESOLVED: gcc.dg/lto/20091216-1 c_lto_20091216-1_0.o-c_lto_20091216-1_0.o exec ute -O0 -fwhopr Problem is asm: asm (.globl start; start: nop); Semicolon starts a comment. Labels must start a line on hpux. -- Summary: ld: Unsatisfied symbol start in file c_lto_20091216- 1_0.o Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
[Bug middle-end/39690] ld: An unknown relocation type 8
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 19:52 --- I think -freorder-blocks-and-partition should be suppressed on hppa due to the way branches are handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690
[Bug middle-end/42718] FAIL: gcc.c-torture/compile/pr42559.c at -O1 and above
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 20:13 --- Unfortunately, we still get the following after back porting the above change: Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ -O1 -w -c -o pr42559.o /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c(timeout = 300)/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c: In function 'jumpfunc':^M /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c:5: internal compiler error: in emit_block_move_hints, at expr.c:1208^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42718
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #15 from hubicka at gcc dot gnu dot org 2010-03-07 20:37 --- I've been discussing this on IRC a while ago with Richard Guenther, but forgot to add a record. It seems that for 4.5, it is best to leave inlining heruistics as it is. THe code size regression come mainly from bzip that is excercising kind of typical bad luck scenario. Other known problem in 4.5 inlining is tramp3d where we now deliver worse than best known performance, but still not worse than one of 4.4. I spent some time playing with this and only way to get 4.5 inliner to solve these faults is to add new parameter that allows early inlining to inline forwarder functions that do increase code size estimates by small amount. This helps to solve both tramp3d and bzip problems but also cause code size issues in some benchmarks (mostly not regressions over 4.4) and is quite ugly. Since re-tunning heuristics needs significant amount of effort and it was done earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better to leave as it is now. Also after LTO merge it seems, according to results posted by Vladimir Marakov, that the inliner is actually perfomring very well compared to other compilers. For 4.6 I do have number of plans. With FRE in early optimization queue we invalidate need for some of early inlining and also IPA stuff should be making us less dependent on inling overall. But I would propose this PR to be wontfix for 4.5. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #34 from hubicka at gcc dot gnu dot org 2010-03-07 20:49 --- Hi, since this is blocker for a release and I can't reproduce the problem myself, if there any hope to get a backtrace? We can also just silence the sanity check for 4.5 for time being, but the proposed patch should solve the problem in proper way. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/43284] New: Explicit casting of double to long long causes value to overflow
When casting a double to a long long causes GCC to overflow the output value.
Imagine;
#include iostream
double foo() { return 9223372036854775807.0; }
int main() {
std::wcout (long long)foo(); // Prints -9223372036854775808
}
Additionally, std::pow(double, int) and std::pow(double, double) seem to behave
differently, presumably for the same reason;
#include iostream
#include cmath
int main() {
std::wcout (long long)std::pow(2.0, 64); // -9223372036854775808
std::wcout (long long)std::pow(2.0, 64.0); // 9223372036854775807
}
Note that this behaviour is not the same if the return value of foo(),
std::pow() (in both cases) are stored in variables first.
Compiling with g++ -Wall -ansi -std=gnu++0x -pedantic test.cpp, with GCC
4.4.1. Note that compiling with g++ -Wall -ansi -std=gnu++0x -pedantic -O3
test.cpp does NOT exhibit this behaviour; foo() and both std::pow() results in
9223372036854775807.
Note that (unsigned long long)std::pow(2.0, 64) == 0, and (unsigned long
long)std::pow(2.0, 64.0) == 18446744073709551615.
--
Summary: Explicit casting of double to long long causes value to
overflow
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ullner at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43284
[Bug middle-end/42718] FAIL: gcc.c-torture/compile/pr42559.c at -O1 and above
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-07 21:44 --- Breakpoint 1, get_object_alignment (exp=0x7afb80f0, align=8, max_align=64) at ../../gcc/gcc/builtins.c:320 320 if (TREE_CODE (exp) == CONST_DECL) (gdb) p debug_tree (exp) label_decl 7afb80f0 jumplabel type void_type 7af43270 void VOID align 8 symtab 0 alias set -1 canonical type 7af43270 pointer_to_this pointer_type 7af432d8 side-effects VOID file /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr42559.c line 6 col 1 align 1 alias set 2 context function_decl 7afad500 jumpfunc initial error_mark 7af2f340 (code_label/s 8 7 9 3 (jumplabel) [0 uses]) (note 9 8 0 [bb 3] NOTE_INSN_BASIC_BLOCK) $5 = void -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42718
[Bug c++/43284] Explicit casting of double to long long causes value to overflow
--- Comment #1 from schwab at linux-m68k dot org 2010-03-07 22:07 --- 9223372036854775807 has more significant bits than what fits in a double, it is rounded to 9223372036854775808.0, which then overflows when converted to long long. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43284
[Bug c++/43284] Explicit casting of double to long long causes value to overflow
--- Comment #2 from ullner at gmail dot com 2010-03-07 22:10 --- Hm? How does calling std::pow with different types behave differently? The value can be stored fine if one does double dValue = std::pow(2.0, 64);long long llValue = dValue; // OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43284
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #1 from bangerth at gmail dot com 2010-03-07 23:41 --- The error message I get is this: g/x c++ -c x.cc x.cc: In member function 'void BarT::bar() [with T = A::Baz]': x.cc:18: instantiated from here x.cc:10: error: no matching function for call to 'BarA::Baz::foo(A::Baz)' x.cc:3: note: candidates are: void HasFooT::foo() [with T = A::Baz] This error message is given upon instantiation time since the call was (correctly) considered dependent. At instantiation time, gcc finds the function in the base class but decides that the arguments don't match -- producing the error. Note that the first scope in which a function is found terminates the search for possible other candidates, even if the functions in the first scope in which functions are found don't match. Consequently the code is rejected. Why do you think this is not the correct behavior? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #2 from schaub-johannes at web dot de 2010-03-08 00:01 --- The point is that the scope of the base class is not examined even during instantiation, so you cannot find the class member function and ADL finds A::foo instead. The Standard says at 14.6.2/3: In the definition of a class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member *or during an instantiation of the class template or member*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #3 from bangerth at gmail dot com 2010-03-08 00:19 ---
But that would mean that the following code should be invalid
because the compiler should never find HasFooT::foo even at
instantiation time:
-
templatetypename T
struct HasFoo {
void foo(T) { }
};
templatetypename T
struct Bar : HasFooT {
void bar() { foo(T()); }
};
int main() { Barint b; b.bar(); }
-
I don't think the intent is to make this invalid.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #4 from schaub-johannes at web dot de 2010-03-08 00:26 --- Yes, this is the consequence. You have to add this- or Bar:: to use another form of lookup (qualified or class-member access) or use a using-declaration to bring the name in scope (using HasFooT::foo;). I can't say anything about the intent, but comeau rejects this code, and clang too (it's actually a well known pit-fall in C++). See my article here: http://stackoverflow.com/questions/2396019/c-templates-hides-parent-members/2398186#2398186 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #5 from bangerth at gmail dot com 2010-03-08 00:36 --- OK, so the question is whether the testcase in comment #3 should be rejected based on the wording of 14.6.2/3. Jason, as our resident language lawyer, would you mind commenting? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 01:06 --- Dup of bug 15272. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43281] [c++0x] ICE in nested lambda functions with invalid auto
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-08 02:37 --- The code is ill-formed; specifically, the line auto val = val; violates 7.1.6.4/3: The name of the object being declared shall not appear in the initializer expression. -- 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 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2010-03-08 02:37:20 date|| Summary|[c++0x] ICE in nested lambda|[c++0x] ICE in nested lambda |functions, in a special case|functions with invalid auto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43281
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-03-08 02:53 --- Kai, Patch in Comment #8 is OK to commit. Thanks! (I also regression tested on x86-64-linux-gnu.) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-08 02:53:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #4 from erh+gcc at nimenees dot com 2010-03-08 04:02 --- (In reply to comment #3) (In reply to comment #2) So does this mean bug #13687 is going to be reopened? Or is there some workaround that hasn't been mentioned? No. I think the issue has been discussed at length there. W. I see a few comments that don't at all explain why you would not want to have this warning available in c++. The argument there seems to be that is is unnecesary b/c you can't call a function without a prior prototype, but to my mind that fact is an argument FOR having the warning. You need a prototype when use call a function and, more importantly, due to the fact that c++ mangles function names based on the exact types of the parameters that prototype NEEDS to be completely in sync with the function definition, otherwise it's effectively prototyping a non-existent function. Yes, you'll get an error at link time if the function actually gets called somewhere, but I don't understand why you *wouldn't* want to point out the discrepancy between the header file and the cpp file early. i.e. at a point during a build where a developer will be able to fix it more easily because the warning is telling him at least one of the files that he has to look at. Are you really saying that this isn't a useful piece of information to provide to the developer? Is there some problem that I'm not seeing that turning on this warning will cause? Is enabling it for c++ code difficult due to how gcc is implemented? I'm confused as to why there is such opposition to this and I feel like there's some key point here that I'm missing. (btw, I tried the trivial change in c.opt (gcc 4.1.3) of just allowing the command line option, but no warning appeared when I compiled with -Wmissing-prototypes. I guess there's something else that needs to be done, but I have no idea what) -- erh+gcc at nimenees dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug c++/13687] -Wmissing-prototypes should not be ignored for C++
--- Comment #19 from bangerth at gmail dot com 2010-03-08 04:26 --- *** Bug 43272 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13687
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #5 from bangerth at gmail dot com 2010-03-08 04:26 --- What I'm saying is that this entire discussion is already present in PR13687 and that there is nothing more to say. The warning exists in C because it can lead to hard-to-find bugs in C code because you can call a function without a prototype in C. You can't do that in C++, and on top of that you can overload functions in C++ which makes it impossible to determine for a compiler whether a prototype matches a definition. Warnings are not generally meant to make programming simpler (as in the case you are making) but to warn about cases that can lead the compiler to generate code that may not have been intended that way but that compiles cleanly anyway. This isn't the case here, and the community has decided in PR 13687 that it doesn't want to support this feature in C++. W. *** This bug has been marked as a duplicate of 13687 *** -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug c++/43281] [c++0x] ICE with invalid auto
--- Comment #2 from jason at gcc dot gnu dot org 2010-03-08 04:27 ---
and indeed this testcase gets the same crash:
void f()
{
auto val = val;
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[c++0x] ICE in nested lambda|[c++0x] ICE with invalid
|functions with invalid auto |auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43281
[Bug target/39223] volatile bug on AVR
--- Comment #7 from abnikant at gmail dot com 2010-03-08 05:22 --- (In reply to comment #6) An observation - the same file when compiled with -O1 for i386 target also appears to load g_54 using movl instruction. _func_45: ... L11: testw %bx, %bx je L7 movl_g_54, %eax L7: movl$1, 4(%esp) It loads g_54 conditionally with gcc-4.4.0 and higher version in -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug target/39223] volatile bug on AVR
--- Comment #8 from abnikant at gmail dot com 2010-03-08 05:26 --- avr-gcc-4.4.0 -S -O1 small.c code snippet version avr-gcc-4.4.0 .L__stack_usage = 0 rcall func_15 sbiw r24,0 breq .L4 lds r24,g_54 lds r25,g_54+1 lds r26,g_54+2 lds r27,g_54+3 .L4: sts g_8,__zero_reg__ sts g_8+1,__zero_reg__ sts g_8+2,__zero_reg__ sts g_8+3,__zero_reg__ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug target/39223] volatile bug on AVR
--- Comment #9 from anitha dot boyapati at atmel dot com 2010-03-08 06:04 --- (In reply to comment #5) Fails with gcc 4.4.3 and gcc 4.5 with -O1. Correction : The bug passes with 4.4.2 and above versions. Code generated can be seen below. func_45: ... rcall func_15 mov r28,r24 mov r29,r25 ldi r22,lo8(1) ldi r23,hi8(1) ldi r24,hlo8(1) ldi r25,hhi8(1) .L9: sbiw r28,0 breq .L8 lds r18,g_54 lds r19,(g_54)+1 lds r20,(g_54)+2 lds r21,(g_54)+3 .L8: ldi r18,lo8(1) -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug c++/43285] New: typeof doesn't act like a type in ::
This code:
struct foo { typedef int f; };
int main() {
foo g;
typeof(g)::f bar;
typedef
typeof(g) h;
h::f baz;
return 0;
}
gets:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:4: error: expected initializer before bar
--
Summary: typeof doesn't act like a type in ::
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43285
